Согласованный P&L, ДДС и баланс
Единый ledger с правилами Дт/Кт, справочниками, проверками и владельцами исключений вместо десятка несвязанных таблиц.
Сделал: Архитектура учёта, правила, автоматизация, регламент закрытия
ВопросОткуда берётся цифра в отчёте и где её проверяют?
Цифра проходит 6 проверок на пути от 6 источников до 5 отчётов
P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели.
Источники
- банковские выписки из почты
- Taplink заказы
- Bitrix
- Домопланер
- API-источники
- ручной ввод корректировок
Загрузка и правила
- Apps Script email parser
- API integrations
- deduplication
- validation
- historical classification rules
Хранение и модель
- операции
- справочники
- начальные остатки
- партии / FIFO
- реестр сделок
Отчёты и решения
- P&L
- управленческий баланс
- БДДС
- платёжный календарь
- производственная себестоимость
Контрольные точки
- Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.
- Проверка обязательных полей операции: счет Дт, счет Кт, статья ДДС, статья P&L, источник и статус.
- Контроль равенства управленческого баланса.
- Проверка трассировки P&L, баланса и платёжного календаря до операций.
- Проверка списания себестоимости по партии после продажи.
- Проверка FIFO-расчёта и корректности справочников плотности, тарифов и сырья.
В заявку попадёт тема Согласованный P&L, ДДС и баланс: откуда берётся цифра и где её проверяют
.
Ситуация
С чего всё начиналось
Система нужна для бизнеса, где тяжелая ERP избыточна на первом этапе, но уже требуется достоверный управленческий учёт: банки, продажи, заказы, сделки, производство, розница, партии, себестоимость и платежи должны сходиться в едином контуре.
Управленческая отчётность сдавалась поздно, данные собирались из разных источников, часть операций вносилась вручную, а связь между операцией, P&L, балансом и платёжным календарем была непрозрачной. Производство и розница смешивались в общей экономике, из-за чего было сложно понять, где именно формируется добавленная стоимость.
Что изменено
Что я сделал
Спроектировал и реализовал учётный контур на Google Sheets + Apps Script: загрузку банковских выписок из почты, дедупликацию, валидацию, единый реестр операций, распределение операций по счетам активов/пассивов, статьям ДДС и P&L, управленческий баланс, платёжный календарь, FIFO и производственный учёт по партиям.
- Единый лист операций является источником P&L, управленческого баланса и платёжного календаря.
- Каждая операция распределяется по управленческим счетам Дт/Кт, статьям ДДС и статьям P&L.
- Банковские выписки загружаются автоматически из почты через Apps Script, проходят дедупликацию и валидацию.
- Статьи операций распределяются на базе исторических правил и подтверждённых классификаций.
- Производство и розница разделены как два управленческих направления с внутренней передачей продукции.
Что получилось
Результат
P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели
- Demo-сценарий показывает, как регламент закрытия может сдвинуться к началу месяца при автоматической загрузке банка, заказов и проверок.
- Данные попадают из достоверных источников: банки, почта, API, Taplink, Bitrix, Домопланер.
- Дедупликация и валидация снижают риск ручных ошибок и повторной загрузки операций.
- Каждая цифра в P&L, балансе и платёжном календаре трассируется до операции.
Как это проверено
Проверка и границы
- Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.
- Проверка обязательных полей операции: счет Дт, счет Кт, статья ДДС, статья P&L, источник и статус.
- Контроль равенства управленческого баланса.
- Проверка трассировки P&L, баланса и платёжного календаря до операций.
структура публичного кейса обезличена; предметные данные заменены. не раскрываются клиентские счета, контрагенты и суммы; показана архитектура управления.
Техническое приложение
Как устроено внутри
Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.
Архитектура, данные и методология
Архитектура
| Источники | банковские выписки из почты · Taplink заказы · Bitrix · Домопланер · API-источники · ручной ввод корректировок |
|---|---|
| Загрузка | Apps Script email parser · API integrations · deduplication · validation · historical classification rules |
| Хранение | операции · справочники · начальные остатки · партии / FIFO · реестр сделок |
| Представление | P&L · управленческий баланс · БДДС · платёжный календарь · производственная себестоимость |
Модель данных
| Объект | Слой | Назначение |
|---|---|---|
| Операции | ledger | единый реестр операций: источник, сумма, Дт, Кт, ДДС, P&L, партия, сделка, статус |
| Справочники | reference | счета учёта, статьи ДДС/P&L, контрагенты, партии, тарифы, плотность сырья, правила классификации |
| Начальные остатки | opening | стартовые остатки денег, активов, обязательств, сырья, партий и счетов |
| P&L | report | управленческий отчёт о прибылях и убытках из операций |
| Balance | report | управленческий баланс с Дт/Кт-контролем |
| Платёжный календарь | report | фактические и плановые денежные движения, остатки и кассовый разрыв |
Методология и правила
- Сначала была спроектирована учётная модель: операции, счета активов/пассивов, статьи ДДС, статьи P&L, начальные остатки и правила движения между счетами.
- Далее построен минимальный набор листов: операции, справочники, начальные остатки, P&L, управленческий баланс и платёжный календарь.
- Apps Script используется как интеграционный и контрольный слой: загрузка выписок, API-интеграции, дедупликация, валидация, классификация и обновление отчётов.
- Для производства добавлены партии, FIFO, справочник плотности сырья, тарифы ресурсов и расчёт внутренней себестоимости.
- Управленческий баланс строится на Дт/Кт-логике: активы, обязательства, капитал и контроль равенства баланса.
- P&L строится по операциям с привязкой к статьям доходов, COGS, OPEX, EBITDA и чистой прибыли.
Артефакты и стек
Operations Ledger · Management Balance · P&L · Payment Calendar · FIFO Model · Batch Register · Apps Script Automation · Deduplication Rules · Validation Rules
Что бы сделал иначе
- Google Sheets может быть полноценным управленческим контуром, если построен вокруг операций, правил учёта и автоматизации.
- Главная ценность Apps Script — не ускорение ручного ввода, а получение достоверных данных из источников, валидация, дедупликация и контроль учёта.
- P&L, баланс и платёжный календарь должны собираться из одного реестра операций, иначе невозможно быстро находить ошибки.
Похожая задача?
Расскажите, где у вас расходятся цифры или не хватает картины. Отвечу, чем это лечится и с чего начать.