Учёт стройки: от выписки до БДДС в одной системе
Спроектирован и реализован учётный контур: операции, счета, депозиты, УПД, проекты и бюджеты переходят из разрозненных таблиц в собственную систему с неизменяемым журналом, парсером выписок и очередью внимания.
Сделал: Финансовое управление и архитектура системы: правила, модель, парсер, приёмка
ВопросОткуда берётся цифра в отчёте и где её проверяют?
Цифра проходит 4 проверки на пути от 5 источников до 3 отчётов
Реализованы механизмы единого контура: неизменяемый журнал, проверки и очередь исключений вместо ручной сборки P&L, ДДС и баланса; переход и сверка со старым контуром продолжаются.
Схема описана по реальному коду рабочей системы; клиентские сущности, суммы и данные обезличены и не публикуются.
Источники
- банковские выписки (PDF/Excel)
- наличные операции
- счета и УПД
- сметы из таблиц
- Telegram-поручения
Загрузка и правила
- парсер выписок и смет (pdfplumber/OCR)
- автоклассификация по категориям
- сопоставление оплат со счетами
- очередь внимания для неоднозначных
Хранение и модель
- PostgreSQL ledger: операции, проводки, документы
- неизменяемые вложения
- справочники проектов, статей, фондов
- журнал событий и аудит
Отчёты и решения
- финансовый рабочий экран: портфель, операции, P&L, ДДС, баланс, БДДС
- очередь внимания
- Telegram-помощник с навыками по расписанию
Контрольные точки
- Контроль равенства баланса на дату; ненулевое расхождение подсвечивается и попадает в разбор.
- Платёж неизменяем после проведения; повтор команды блокируется ключом идемпотентности.
- Зачёт депозита по УПД проверен тестом без повторного движения ДДС; возвраты и конкурентное проведение покрыты приёмочными тестами.
- Переход принимается сверкой: отчёты нового контура сходятся со старым до отключения прежней синхронизации.
Связанный кейс того же направления — и ещё Согласованный P&L, ДДС и баланс.
Ситуация
С чего всё начиналось
Обезличенная строительная компания с несколькими одновременно работающими объектами и проектным управленческим учётом. Система спроектирована как замена связки таблиц и импортов: переход идёт по протоколу сверки, старые данные хранятся как архив без повторного проведения.
Типовая ситуация масштабирования: компания ведёт несколько строительных проектов параллельно, выходит к более крупным заказчикам — а учёт остаётся ручным: нет зафиксированной политики признания, операции разбираются в таблицах, кассовые разрывы и разборы расхождений случаются регулярно и зависят от одного человека.
Что изменено
Что я сделал
Финансовое управление и архитектура системы: правила признания и распределения, модель ledger, требования к парсеру и отчётам, критерии приёмки, переход из прежнего табличного контура в собственную систему на Go/PostgreSQL; миграция и сверка продолжаются.
- Банковский факт неизменяем: распределение операции по проектам, статьям, фондам и документам не меняет исходную строку выписки.
- Счёт и оплата — разные события: согласование счёта, точное сопоставление оплаты и подтверждение неоднозначных оплат идут отдельными шагами.
- Связанный счёт не подтверждает поставку; зачёт депозита и УПД проводится при проведении документа или позднее, с возвратами и корректировками.
- Плановая запись БДДС сама не создаёт расход и банковский платёж; регулярные графики ФОТ и офиса частично сопоставляются с фактом.
- Суммы хранятся в целых копейках, журналы сбалансированы и неизменяемы; исправления сохраняют историю, а закрытые периоды блокируют правку.
Что получилось
Результат
Реализованы механизмы единого контура: неизменяемый журнал, проверки и очередь исключений вместо ручной сборки P&L, ДДС и баланса; переход и сверка со старым контуром продолжаются
- Ключ идемпотентности защищает повтор одной команды; ошибка сервера не отображается как успешное сохранение.
- Приёмочные тесты фиксируют критичные правила: неизменность платежа, зачёт депозита по УПД без повторного ДДС, блокировка неверных итогов, права и закрытые периоды, конкурентное проведение.
- Входящие остатки перенесены по протоколу сверки, новые операции ведутся в системе; старая история сохранена архивом со стабильными ключами.
- Переход зафиксирован в статусе сверки: исторический пакет применён целиком по контрольным суммам; срезы нового контура сверяются со старым до отключения прежнего.
Как это проверено
Проверка и границы
- Контроль равенства баланса на дату; ненулевое расхождение подсвечивается и попадает в разбор.
- Платёж неизменяем после проведения; повтор команды блокируется ключом идемпотентности.
- Зачёт депозита по УПД проверен тестом без повторного движения ДДС; возвраты и конкурентное проведение покрыты приёмочными тестами.
- Переход принимается сверкой: отчёты нового контура сходятся со старым до отключения прежней синхронизации.
кейс описан по реальному коду рабочей системы; клиентские сущности, суммы и выписки обезличены и не публикуются. переход в статусе сверки: результат показан механизмом системы, а не денежным эффектом; живой банковский фид реализован для одного банка, остальные источники — файловые выписки; ЭДО и реготчётность за пределами первой версии.
Техническое приложение
Как устроено внутри
Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.
Архитектура, данные и методология
Схема описана по реальному коду рабочей системы; клиентские сущности, суммы и данные обезличены и не публикуются.
Архитектура
| Источники | банковские выписки (PDF/Excel) · наличные операции · счета и УПД · сметы из таблиц · Telegram-поручения |
|---|---|
| Загрузка | парсер выписок и смет (pdfplumber/OCR) · автоклассификация по категориям · сопоставление оплат со счетами · очередь внимания для неоднозначных |
| Хранение | PostgreSQL ledger: операции, проводки, документы · неизменяемые вложения · справочники проектов, статей, фондов · журнал событий и аудит |
| Представление | финансовый рабочий экран: портфель, операции, P&L, ДДС, баланс, БДДС · очередь внимания · Telegram-помощник с навыками по расписанию |
Модель данных
| Объект | Слой | Назначение |
|---|---|---|
| Операции | fact | банковские и наличные движения как неизменяемый факт с source id |
| Проводки и распределения | ledger | разнесение операции по проектам, статьям, фондам и документам |
| Документы | fact | счета, УПД, депозиты, позиции и файлы-оригиналы |
| Плановые записи | plan | БДДС-календарь, регулярные графики и частичное сопоставление с фактом |
| Журнал и аудит | audit | события изменений, версии, закрытые периоды и права |
Методология и правила
- Сначала зафиксированы источники и правила: выписки, наличные операции, счета, УПД, депозиты, сметы, справочники проектов, статей и фондов.
- Парсер выписок и смет (PDF, Excel, скан через OCR) превращает файл в операции с source id; автоклассификация предлагает статью, неоднозначное уходит в очередь внимания.
- Отчёты строятся из одного журнала: P&L план-факт по месяцам и кварталам с раскрытием до документа, ДДС с ежедневными остатками, баланс на дату с контролем равенства, БДДС-календарь с прогнозом остатка.
- Переход со старого контура оформлен как протокол: входящие остатки, согласование денег, депозитов, запасов, долгов и фондов; история не проводится повторно.
- Ledger-модель: операции, проводки и документы разделены — банковский факт, управленческое распределение и первичка не смешиваются в одной строке.
- P&L считает план-факт по месяцам и кварталам и раскрывается до исходного документа; отсутствующий бюджет остаётся пустым, а не додумывается.
Артефакты и стек
Журнал операций · Модель данных · Парсер выписок · Правила распределения · Критерии приёмки · БДДС-календарь
Что бы сделал иначе
- Распределение операции не должно менять банковский факт — иначе сверка с выпиской перестаёт быть доказательством.
- Счёт и оплата надо разделять с самого начала: смешение превращает долг в ложную выручку.
- Автоматическое подтверждение неоднозначной оплаты опаснее ручной очереди — неоднозначное должно останавливаться на человеке.
Что посмотреть дальше
Связанные кейсы того же направления, центр решений на демо-данных и опыт целиком.