00 · КЕЙС ЗА 30 СЕКУНД
Кейс за 30 секунд
Управленческая отчётность сдавалась поздно, данные собирались из разных источников, часть операций вносилась вручную, а связь между операцией, P&L, балансом и платёжным календарем была непрозрачной. Производство и розница смешивались в общей экономике, из-за чего было сложно понять, где именно формируется добавленная стоимость.
Спроектировал и реализовал учётный контур на Google Sheets + Apps Script: загрузку банковских выписок из почты, дедупликацию, валидацию, единый реестр операций, распределение операций по счетам активов/пассивов, статьям ДДС и P&L, управленческий баланс, платёжный календарь, FIFO и производственный учёт по партиям.
Какие листы являются вводом, справочниками, расчётами, отчётом, архивом и журналом аудита?
P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели
- Управленческая отчётность сдавалась поздно, данные собирались из разных источников, часть операций вносилась вручную, а связь между ...
- решение зависело от ручных сверок, чатов и отдельных файлов
- владельцы исключений и критерии приёмки были неочевидны
- P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели
- артефакты: Реестр операций · Управленческий баланс · P&L · Платёжный календарь
- Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.
Build & Transfer
Сборка и передача системы: правила, модель, сверки, экран решения, регламент и владельцы.
4-6 недель · когда нужен рабочий контур, который команда сможет вести без личной зависимости от архитектора- Вклад клиента
- дать источники, согласовать правила, назначить владельцев и принять критерии
- Критерий выхода
- контур обновляется, сверяется и используется владельцами в регулярном ритме
01 · Что увидел руководитель
P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели
Какое решение стало возможным
Какие листы являются вводом, справочниками, расчётами, отчётом, архивом и журналом аудита?
- Какие листы являются вводом, справочниками, расчётами, отчётом, архивом и журналом аудита?
- Какие диапазоны защищены и кто владелец изменения справочников?
- Какие Apps Script-проверки должны пройти до закрытия периода?
- Где Google Sheets достаточно как первый управленческий контур, а где уже нужна ERP?
05A · ТРЕБОВАНИЯ К КОНТУРУ
Почему архитектура выбрана так
Архитектура не выбирается заранее. Сначала фиксируются требования к решению, ограничения данных и критерии приёмки — из них следует инструмент, модель и проверки.
Для тех, кто хочет вникнуть в реализациюконтекст, правила, архитектура, модель данных, методология и выводы
00B · ПРОЕКТНЫЙ ПАКЕТ
Такой проект можно адаптировать под ваш бизнес
Точный объём зависит от источников, качества справочников, количества владельцев и глубины приёмки.
- единый лист операций с идентификатором источника, Дт/Кт, ДДС, P&L, партией и статусом
- P&L, управленческий баланс, БДДС и платёжный календарь из одного реестра
- Apps Script import: банк из почты, заказы, сделки, дедупликация и проверки
- FIFO, партии, себестоимость, производство vs розница
- разбор текущих Google Sheets и ручных закрытий
- проектирование структуры input / reference / calculation / report / archive
- регламент закрытия периода, защищённые диапазоны, владельцы и журнал аудита
01 · КОНТЕКСТ
Бизнес-контекст
Система нужна для бизнеса, где тяжелая ERP избыточна на первом этапе, но уже требуется достоверный управленческий учёт: банки, продажи, заказы, сделки, производство, розница, партии, себестоимость и платежи должны сходиться в едином контуре.
02 · ПРОБЛЕМА
Проблема
Управленческая отчётность сдавалась поздно, данные собирались из разных источников, часть операций вносилась вручную, а связь между операцией, P&L, балансом и платёжным календарем была непрозрачной. Производство и розница смешивались в общей экономике, из-за чего было сложно понять, где именно формируется добавленная стоимость.
03 · РОЛЬ
Что я сделал
Спроектировал и реализовал учётный контур на Google Sheets + Apps Script: загрузку банковских выписок из почты, дедупликацию, валидацию, единый реестр операций, распределение операций по счетам активов/пассивов, статьям ДДС и P&L, управленческий баланс, платёжный календарь, FIFO и производственный учёт по партиям.
Спроектировал и реализовал учётный контур на Google Sheets + Apps Script: загрузку банковских выписок из почты, дедупликацию, валидацию, единый реестр операций, распределение операций по счетам активов/пассивов, статьям ДДС и P&L, управленческий баланс, платёжный календарь, FIFO и производственный учёт по партиям.
Дать доступ к источникам или обезличенным выгрузкам, подтвердить правила, назначить владельцев данных и принять критерии результата.
не раскрываются клиентские счета, контрагенты и суммы; показана архитектура управления
04 · БИЗНЕС-ПРАВИЛА
Бизнес-логика и правила
- Единый лист операций является источником P&L, управленческого баланса и платёжного календаря.
- Каждая операция распределяется по управленческим счетам Дт/Кт, статьям ДДС и статьям P&L.
- Банковские выписки загружаются автоматически из почты через Apps Script, проходят дедупликацию и валидацию.
- Статьи операций распределяются на базе исторических правил и подтверждённых классификаций.
- Производство и розница разделены как два управленческих направления с внутренней передачей продукции.
- Себестоимость производства рассчитывается по FIFO с учётом партий, сырья, плотности, электроэнергии, воды и технологических коэффициентов.
- Заказы из Taplink автоматически попадают в учёт, списывают себестоимость по партии и отражаются в P&L.
05B · АРХИТЕКТУРА
Архитектура данных
Что показывает эта схема
- разделяю input, references, ledger, calculation, report, archive и журнал изменений
- связываю P&L, баланс, БДДС и платёжный календарь с единым реестром операций
- подключаю Apps Script как слой загрузки, дедупликации, проверки и готовности отчётов
- закрываю период через регламент, владельцев и контрольные проверки
Management Accounting System (inputs → ledger → rules → statements → decisions)
Раскрывай уровни как матрешку: L0 показывает контур, L1 открывает слой, L2/L3 дают подпроцессы, проверки и решение.
L0Источники и загрузкаsources → intake → raw layer
L0Бизнес-модель и правилаfacts / views / marts
L0Управленческий слойэкран / владелец / решение
Все уровни свёрнуты
Открой L0-этап, затем L1-блок. Детали не занимают экран, пока они не нужны.
Как операция проходит через учётный контур
операция приходит из банка, почты, Taplink, Bitrix или ручной корректировки
загрузка, нормализация полей, идентификатор источника и refresh status
проверка дублей, обязательных полей, суммы, даты, счета и контрагента
операция получает счет Дт, счет Кт, статью ДДС, статью P&L и статус проверки
отчёты собираются из одного реестра, поэтому цифра трассируется до операции
ошибка получает владельца, срок исправления и статус готовности закрытия
Слои подробнее
Источники
- банковские выписки из почты
- Taplink заказы
- Bitrix
- Домопланер
- API-источники
- ручной ввод корректировок
Загрузка
- Apps Script email parser
- API integrations
- deduplication
- validation
- historical classification rules
Хранилище
- операции
- справочники
- начальные остатки
- партии / FIFO
- реестр сделок
Витрина
- P&L
- управленческий баланс
- БДДС
- платёжный календарь
- производственная себестоимость
Инструмент и модель выбраны из требований к решению: Объём и команда.
не раскрываются клиентские счета, контрагенты и суммы; показана архитектура управления
Архитектуру нужно пересматривать, когда меняются объём, свежесть, цена ошибки, роли доступа или требования к аудиту.
06 · МОДЕЛЬ ДАННЫХ
Модель данных / витрины
07 · МЕТОДОЛОГИЯ
Методология, процедуры, модель и эффект
Методология
- Сначала была спроектирована учётная модель: операции, счета активов/пассивов, статьи ДДС, статьи P&L, начальные остатки и правила движения между счетами.
- Далее построен минимальный набор листов: операции, справочники, начальные остатки, P&L, управленческий баланс и платёжный календарь.
- Apps Script используется как интеграционный и контрольный слой: загрузка выписок, API-интеграции, дедупликация, валидация, классификация и обновление отчётов.
- Для производства добавлены партии, FIFO, справочник плотности сырья, тарифы ресурсов и расчёт внутренней себестоимости.
Что перенесено в систему
- Управленческий учёт перестал быть набором таблиц: появился единый реестр операций, Дт/Кт, P&L, баланс, БДДС, платёжный календарь и проверки.
- Банковские операции больше не переносятся вручную: выписки забираются из почты и загружаются в операции автоматически.
- P&L, баланс и платёжный календарь пересчитываются из единого реестра операций, что даёт полную трассировку показателей.
- Ошибки учёта выявляются через несхождение управленческого баланса и статусы валидации операций.
- Списания активов после продажи и связь с реестром сделок добавлены как дополнительные точки контроля.
Модель и критерии
- Управленческий баланс строится на Дт/Кт-логике: активы, обязательства, капитал и контроль равенства баланса.
- P&L строится по операциям с привязкой к статьям доходов, COGS, OPEX, EBITDA и чистой прибыли.
- БДДС и платёжный календарь строятся по датам фактических и плановых денежных операций.
- FIFO-модель списывает сырье и себестоимость по партиям.
- Внутренний transfer price разделяет экономику производства и розницы, показывая добавленную стоимость на каждом этапе.
Измеримый эффект
- Demo-сценарий показывает, как регламент закрытия может сдвинуться к началу месяца при автоматической загрузке банка, заказов и проверок.
- Данные попадают из достоверных источников: банки, почта, API, Taplink, Bitrix, Домопланер.
- Дедупликация и валидация снижают риск ручных ошибок и повторной загрузки операций.
- Каждая цифра в P&L, балансе и платёжном календаре трассируется до операции.
- Производственная и розничная экономика разделены, что позволяет видеть маржу каждого этапа.
10 · ВЫВОДЫ
Выводы и улучшения
- Google Sheets может быть полноценным управленческим контуром, если построен вокруг операций, правил учёта и автоматизации.
- Главная ценность Apps Script — не ускорение ручного ввода, а получение достоверных данных из источников, валидация, дедупликация и контроль учёта.
- P&L, баланс и платёжный календарь должны собираться из одного реестра операций, иначе невозможно быстро находить ошибки.
- Разделение производства и розницы показывает добавленную стоимость каждого этапа, а не только общий результат компании.
08 · ДОКАЗАТЕЛЬСТВА
Артефакты, валидация и эффект
Decision Trace ключевой цифры
банковские выписки из почты
Единый лист операций является источником P&L, управленческого баланса и платёжного календаря.
Управленческий баланс строится на Дт/Кт-логике: активы, обязательства, капитал и контроль равенства баланса.
проверки обязательных полей, баланса, FIFO, ID источника и готовности отчётности
Реестр операций
Какие листы являются вводом, справочниками, расчётами, отчётом, архивом и журналом аудита?
Цепочка доказательности
Дт/Кт, обязательные поля, источник, статусP&L, баланс и БДДС трассируются до операцииdedup, refresh status, validation errorsзакрытие периода идёт по регламенту, а не через ручную сборкубаланс, формулы, позднее обновление, владелецпериод можно закрывать по регламентуАртефакты
Единый реестр операций: источник, сумма, Дт, Кт, статья ДДС/P&L, партия, сделка и статус проверки.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Управленческий баланс с Дт/Кт-контролем и проверкой расхождений до закрытия периода.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Рабочий артефакт проекта: постановка, логика, проверка или демонстрационный слой.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Платёжный календарь: фактические и плановые движения, остатки, кассовый разрыв и очередь решений.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Модель партий и FIFO-списания себестоимости сырья/готовой продукции.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Реестр партий: сырье, плотность, тарифы, себестоимость и связь с заказами.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Интеграционный слой: загрузка выписок, API/Taplink-заказов, дедупликация, classification и validation.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Правила блокировки дублей по ID источника, дате, сумме, счету и назначению платежа.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Контроль обязательных полей операции, баланса, FIFO, ID источника и готовности отчётности.
Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.Валидация
- Дедупликация банковских операций по идентификатору источника, дате, сумме, счету и назначению платежа.
- Проверка обязательных полей операции: счет Дт, счет Кт, статья ДДС, статья P&L, источник и статус.
- Контроль равенства управленческого баланса.
- Проверка трассировки P&L, баланса и платёжного календаря до операций.
- Проверка списания себестоимости по партии после продажи.
- Проверка FIFO-расчёта и корректности справочников плотности, тарифов и сырья.
Бизнес-импакт
P&L, баланс и БДДС стали рабочим контуром закрытия: операции, Дт/Кт, проверки и владельцы исключений связаны в одной модели
- Demo-сценарий показывает, как регламент закрытия может сдвинуться к началу месяца при автоматической загрузке банка, заказов и проверок.
- Данные попадают из достоверных источников: банки, почта, API, Taplink, Bitrix, Домопланер.
- Дедупликация и валидация снижают риск ручных ошибок и повторной загрузки операций.
- Каждая цифра в P&L, балансе и платёжном календаре трассируется до операции.
- Производственная и розничная экономика разделены, что позволяет видеть маржу каждого этапа.
Что продолжает работать после передачи
У каждого ключевого исключения и решения есть владелец, срок и ожидаемое действие.
Контур рассчитан на регулярное обновление: день, неделя или закрытие периода — в зависимости от кейса.
проверки обязательных полей, баланса, FIFO, ID источника и готовности отчётности
Изменение правил, новый источник, спорная методология или миграция на другой уровень сложности.