Биллинг

Биллинг — это не отдельная база, а способ использовать зеркало транзакций в Postgres (см. Где живут данные) для сверки денег между нами и мерчантом. Раз в сутки данные забирает 1С, режет их на периоды, и эти периоды дальше живут своей жизнью: по ним финансисты выставляют счета и платят, по ним мерчанту приходит выгрузка в личном кабинете, по ним у мерчанта работает бухгалтерия.

Как это выглядит целиком

Кто забирает данные и когда

Каждый день в 5:00 по Москве 1С обращается в aggregation-service по GET /billing/excel и забирает успешные операции за прошлые сутки: с 00:00:00 по 23:59:59 по часовому поясу +3, независимо от того, в каком часовом поясе физически стоят наши серверы — таймзону 1С передаёт явно параметром timezone в запросе.

Выборка идёт по endDate — дате, когда операция получила финальный результат, а не по дате создания. Это важно: платёж, созданный вечером 12 марта, но завершённый банком уже 13 марта, попадёт в период 13 марта, а не 12-го.

Что 1С делает с ответом

1С не хранит наши транзакции — он строит из ответа периоды и фиксирует их у себя в реестре. Одна строка реестра выглядит так:

Дата	Мерчант	Счёт	Банк	Сумма	ID первой операции	ID последней операции
12.03.2026	test	test	GreatBank	1200 EUR	...	...

То есть период — это агрегат «мерчант + счёт + банк + дата» с суммой и границами по операциям, которые в этот агрегат попали. Дальше с этими периодами работают три разных потребителя:

• финансисты по периоду решают, запросить ли деньги с мерчанта или выплатить мерчанту;
• личный кабинет мерчанта строит те же выгрузки за те же периоды тем же запросом /billing/excel;
• бухгалтерия мерчанта сверяется по этим же отчётам — то есть мерчант видит ровно те цифры, что легли в реестр 1С.

Почему нельзя менять статус операции, которая уже ушла в биллинг

Реестр 1С — это не отчёт, который можно перестроить: он уже стал основанием для реального движения денег или для документов у мерчанта. Отсюда два жёстких правила для любого кода, трогающего статус транзакции после финализации:

Нельзя менять статус операции, которая уже ушла с терминальным статусом в биллинг. Если успешную операцию, которую 1С уже учла в периоде за одну дату, задним числом передвинуть на другую дату (поменять endDate), она задвоится: старый период её не потеряет, потому что 1С к нему уже не возвращается, а новый период получит её повторно. Суммы в реестре и в выгрузке мерчанта разойдутся, и без ручной сверки это не заметить.

Единственное безопасное направление — из неуспеха в успех, и только если операция ещё никогда не была успешной. Такая операция ещё не попадала в /billing/excel ни в каком периоде, поэтому её появление в следующей выборке ничего не задвоит.

Любое другое изменение статуса — это не просто правка поля, а сторно. Если успешную операцию нужно аннулировать или пересчитать, старое значение нельзя просто перезаписать — по нему уже стоит период в реестре 1С и, возможно, уже прошла выплата или списание. Изменение фиксируется отдельной операцией (сторнирующей записью), которая попадёт в свой собственный будущий период, а не тихо поправит прошлый.