«Движок проводок» (Accounting Engine)

Подсистема «Движок проводок» (AccountingEngine)

1. Введение: Проблема легаси-кода и переход к прозрачности

Любая крупная учетная подсистема, обеспечивающая специфическую деятельность (например, сложный залоговый, кредитный или ломбардный учет), живет и развивается годами. В течение многих лет в неё непрерывно вносятся изменения: меняется законодательство, добавляются новые финансовые продукты, переписываются алгоритмы проведения.

Со временем это неизбежно приводит к двум критическим проблемам:

• Запутанный монолит: Код проведения документов становится перегруженным и трудночитаемым. Логика формирования проводок размазывается по многочисленным общим модулям, подпискам на события и условиям. Найти первопричину конкретной цифры в регистре становится сложнейшим квестом.
• Слепой учет («Черный ящик»): Бухгалтер видит лишь финальный результат проведения и полностью теряет понимание внутренних механизмов системы. Из-за этого коммуникация с разработчиками заходит в тупик: бухгалтер констатирует проблему («цифра не та»), но не может объяснить, в какой именно логической ветке произошел сбой. Программист же тратит часы в отладчике, чтобы просто раскопать старый код.

Первоочередная задача нашей подсистемы - не просто дать инструмент для создания новых проводок, а описать и оцифровать уже существующую сложную реальность.

Используя отладчик, программист шаг за шагом «вытягивает» запутавшуюся за много лет логику и переносит её в прозрачную структуру выражений и правил нашего конструктора. Это позволяет мгновенно отсечь накопленный годами программный мусор и перевести учет на рельсы абсолютной прозрачности.

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

2. Настройка операции и встроенный сервис отладки конкретной проводки

Чтобы распутать многолетний легаси-код и перевести логику в управляемое русло, подсистема переносит настройки из конфигуратора в пользовательский режим. Главным рабочим местом, где программист и бухгалтер ведут совместную работу, является справочник «Бухгалтерские операции».

Каждый элемент этого справочника (шаблон операции) создается под конкретный «Вид документа» (например, залоговый билет или акт начисления процентов). Внутри карточки расположена табличная часть «Проводки», где построчно описываются правила: формулы счетов, расчеты сумм и заполнение аналитики.

🛠Встроенный сервис атомарной отладки формул

Главная фишка карточки - это встроенная интерактивная «песочница». Чтобы настроить проводки, программисту, бухгалтеру, аналитику не нужно писать код «вслепую». Прямо в шапке карточки они выбирают конкретный тестовый документ из базы данных. Этот документ дает системе необходимый контекст живых данных для моментальной проверки.

Рисунок 1. Форма карточки

Внутри карточки реализован интеллектуальный механизм отладки конкретной проводки с помощью кнопки «Проверить формулу»:

Рисунок 2. Проверка формул

1. Проверка Выражения (Приоритет 1): Пользователь выделяет тот реквизит в строке табличной части, для которого написано расчетное выражение (например, формула Суммы или аналитики). При нажатии кнопки система подставляет живые данные тестового документа и мгновенно выводит на экран готовый результат вычисления.
2. Проверка Условия (Приоритет 2): Если у реквизита в строке нет явного выражения, или пользователь выделил поле валидации правила, подсистема выполняет проверку Условия. На экран мгновенно выводится логический статус: «ИСТИНА» (условие выполняется, проводка активна) или «ЛОЖЬ» (условие не выполнено, проводка будет отсечена).
3. Контекст табличных частей (Правило первой строки): Если настраиваемая формула или условие обращаются к табличной части документа (где может быть множество строк), подсистема для теста безопасно производит расчет строго по первой строке ТЧ. Это позволяет моментально оценить корректность синтаксиса.

Результат локальной настройки: Используя этот сервис, тандем построчно настраивает и доводит до идеала логику для одного конкретного документа. Как только встроенная экспресс-сверка внутри формы показывает полное совпадение с историческим учетом, локальная задача выполнена - проводки для конкретного документа полностью настроены и верифицированы.

📝 Область применения и источники данных в строке проводки

Каждая строка в табличной части «Проводки» справочника «Бухгалтерские операции» представляет собой законченное правило для генерации бухгалтерской записи. Чтобы подсистема понимала, в каком контексте вычислять выражения счетов, условий, аналитики и сумм, для всей проводки целиком в строке настройки жестко определяется её «Область применения».

Пользователь выбирает один из трёх фундаментальных режимов (источников данных) для всей строки проводки:

Рисунок 3 Область применения

• 1. Шапка:
  Проводка формируется на основании общих реквизитов документа (например, Организация, Склад, Договор). Выражения для этой проводки вычисляются ровно один раз при проведении объекта, так как параметры шапки статичны.
• 2. Табличная часть:
  Проводка привязывается к конкретной многострочной части документа (например, к ТЧ «Товары», «Услуги» или «Залоги»). В этом режиме подсистема генерирует проводки в цикле - по одной записи на каждую строку ТЧ. Соответственно, при интерактивной отладке этой проводки с помощью кнопки «Проверить формулу», подсистема автоматически берёт для экспресс-анализа строго первую строку выбранной табличной части.
• 3. Источник данных (Запрос):
  Проводка формируется на основании сложной внешней выборки, когда данных внутри самого документа физически не хватает. Этот режим позволяет подключить к расчету проводки запросы к регистрам остатков, курсам валют или историческим срезам данных. Подсистема генерирует пакет проводок по результатам выполнения этого запроса.

Такой подход гарантирует железную логику: одна строка настройки - одна понятная область применения, которая сразу определяет контекст данных для всех формул внутри этой проводки.

Сервисы визуализации кода и верификации запросов

Чтобы сделать систему максимально прозрачной и научить бухгалтера читать алгоритмы «на лету», в интерфейс карточки «Бухгалтерские операции» интегрированы два мощных сервиса визуализации:

1. Сервис мгновенного просмотра технического кода

Если бухгалтеру или технологу необходимо понять, какая именно программная логика скрывается за конкретной строкой настройки, им не нужно открывать конфигуратор. Подсистема позволяет увидеть живой исполняемый код прямо в пользовательском режиме:

• Шаг 1: Пользователь нажимает кнопку «Показать технический текст» и выбирает интересующее выражение для анализа (например, формулу расчета суммы или заполнения аналитики).
• Шаг 2: Переходит на специализированную закладку «Просмотр кода».
• Шаг 3: Нажимает кнопку «Показать код расчета».
  Система мгновенно выводит на экран чистый, удобочитаемый программный скрипт, который будет выполнен при проведении. Бухгалтер видит логику своими глазами, сопоставляет её с правилом и может задать программисту точечный вопрос по модификации.

2. Сервис верификации внешних запросов («Проверка источника данных»)

Когда проводка использует контур «Источник данных» (Контур №3, где данные собираются сложным запросом к базе данных), разработчику необходимо убедиться, что запрос написан без ошибок и выбирает правильные цифры.

• Если в карточке уже выбран тестовый документ (который дает контекст для анализа), пользователю достаточно нажать кнопку «Проверка источника данных».
• Подсистема перехватывает этот запрос, подставляет в него параметры выбранного документа, выполняет его в фоне и мгновенно выводит на экран таблицу с данными, которые сформировал запрос.

Это исключает работу вслепую: программист и бухгалтер сразу видят, какие именно исторические срезы или остатки подтянулись «со стороны» для расчета этой конкретной проводки.

4. Сервис массовой проверки на периоде: Обработка «Администрирование»

Рисунок 4. Администрирование бухгалтерских операций

На одном документе формулы работают идеально. Но в реальной легаси-базе за 10 лет накопились тысячи документов, в которых могут встречаться специфические реквизиты, уникальные сочетания аналитики или крайние математические значения. Локальный успех необходимо масштабировать и проверить на прочность.

Для этого разработан макро-сервис - общая обработка «Администрирование бухгалтерских операций». Работа с ней строится по конвейерному алгоритму:

• Шаг 1. Контур проверки: В обработке выбирается тестируемый Вид документа, соответствующий элемент справочника «Бухгалтерские операции» (источник правил), и задается Период (например, прошлый квартал или год).
• Шаг 2. Массовая фиксация моделей: Нажимается кнопка «Создать моделируемые проводки». Подсистема берёт все документы выбранного вида за указанный период, прогоняет их через новые формулы настроек и фиксирует результаты в служебном регистре «Моделируемые проводки».
• Фиксация триады данных: Чтобы защитить рабочий контур, система делает записи в изолированном регистре, жестко связывая три элемента: [Конкретный документ] + [Элемент справочника (источник правил)] + [Получившиеся проводки]. Живой учет при этом никак не страдает.

4. Список отклонений и конвейерная зачистка

После массового расчета в Сервисе нажимается кнопка «Документы с отклонениями по проводкам». Обработка сопоставляет данные регистра моделирования с реальным регистром бухгалтерии и выдает чистый список «проблемных» документов, по которым новые формулы дали расхождения со старым легаси-кодом.

Тандем начинает итерационный процесс зачистки: берется следующий документ из списка отклонений, и в силу вступает механизм сквозной маркировки.

Сквозная маркировка в комментариях

При расчете модели подсистема автоматически добавляет в строку комментария каждой сформированной проводки порядковый номер строки правила из табличной части - например, (1) или (2).

Это выстраивает железный алгоритм работы бухгалтера-аналитика:

1. Обнаружение: В результатах моделирования по проблемному документу бухгалтер видит расхождение суммы и сразу замечает маркер (2).
2. Чтение кода: Бухгалтер открывает карточку настройки (источник проводок), находит строку (2) и читает код выражения.
3. Точная задача: Поняв, какое условие или математическая формула сработали не так на этих специфических данных, бухгалтер для программиста готовит полное и конкретное задание, или же сам правит настройки проводки.

5. Критерии действия проводки и фильтрация на этапе моделирования

Каждая строка в табличной части «Проводки» справочника «Бухгалтерские операции» - это самостоятельное, независимое правило. Чтобы подсистема понимала, должна ли конкретная строка сгенерировать запись в регистре для текущего документа, применяются первичные критерии действия проводки:

• 1. Период действия проводки (Версионирование):
  В самой строке настройки жестко задаются даты начала и окончания действия правила. Например, в одной карточке операции для документа могут одновременно находиться две строки: одна с периодом действия 01.01.2026 – 31.01.2026, а вторая — с 01.01.2027 и незаполненной датой окончания (под новое законодательство). Система смотрит на дату документа: если она не попадает в указанный интервал конкретной строки, правило игнорируется. Это позволяет хранить всю историю изменений учета прямо в одной табличной части.
• 2. Выражение Условия:
  Это главный инструмент отсечения легаси-мусора. Для каждой проводки пишется логическое выражение. Если при анализе проводки формула Условия возвращает ЛОЖЬ, данная проводка физически не создается и в регистр «Моделируемые проводки» вообще не попадает.
• 3. Критерий значимости суммы (<> 0):
  После того, как проводка успешно прошла фильтр периода и условия, система вычисляет её математическое выражение суммы. Если итоговый расчет дает нулевой результат, подсистема выполняет автоматическую валидацию - такая строка признается системным шумом и отбраковывается. К финальной записи в регистр моделирования (или реальный учет) допускаются только значимые строки, где сумма строго не равна нулю.

Итог работы критериев: Проводка попадает в регистр «Моделируемые проводки» только при одновременном выполнении трех условий: документ попал в период действия строки правила, выражение условия вернуло ИСТИНА, а рассчитанная сумма <> 0. Всё остальное отсекается на этапе предварительного отбора.

6. Перспективы развития подсистемы: интерактивный анализ «Что если?»

Проектируя архитектуру подсистемы и внедряя изолированный регистр «Моделируемые проводки», мы заложили прочный фундамент не только для текущей зачистки легаси-кода, но и для масштабного аналитического развития всей финансовой службы.

Главным вектором дальнейшего развития подсистемы станет создание моделируемого аппарата для интерактивного анализа (What-if analysis) на базе стандартной отчетности:

• Интеграция с типовыми отчетами: В систему планируется встроить механизм сквозной подмены данных для стандартных бухгалтерских отчетов (например, Анализ счета или Оборотно-сальдовая ведомость). Пользователь сможет сформировать привычный отчет, а затем активировать специальный режим симуляции.
• Виртуальная трансформация «на лету»: В режиме симуляции система будет временно подменять реальные исторические движения документов записями из регистра моделирования. Все трансформации будут происходить строго на экране в памяти отчета, гарантируя нулевой риск и абсолютную безопасность для живой исторической базы.
• Стратегическое прогнозирование: Финансовая служба получит «машину времени» для учета. Нажатием одной кнопки главный бухгалтер сможет наглядно оценить последствия планируемых изменений в учетной политике или грядущих реформ в законодательстве до их официального внедрения, защищая прогнозные балансы перед руководством.

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

Архитектурная масштабируемость для сверхсложных задач

Преодоление ограничений: Архитектурный запас прочности

Практика разработки подтверждает: любой, даже самый красивый пользовательский конструктор рушится в тот момент, когда его функционала не хватает для решения нестандартной, сверхсложной задачи. Столкнувшись со специфической проводкой, разработчик обычно «сдается», закрывает конструктор и идет писать код руками в конфигураторе, порождая новый легаси-хаос.

В нашей подсистеме базовые сложные задачи - одновременное использование данных шапки и табличной части документа в рамках одной операции - успешно решены и работают уже сейчас. Пользователю достаточно просто правильно описать правила в табличной части карточки.

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

Решение, заложенное в концепцию развития подсистемы, очевидно и элегантно: мы не пишем код в конфигураторе. Вместо этого подсистема позволяет добавить и подключить еще один связанный элемент для описания таких проводок прямо в пользовательском режиме. Мы масштабируем систему за счет композиции и связывания шаблонов в справочнике. Это дает безграничную гибкость: подсистема способна переварить алгоритм любой космической сложности, всегда оставаясь в рамках прозрачной, визуально понятной модели, открытой для анализа бухгалтеру.

7. Заключение: Эффект для бизнеса

Перенос логики формирования проводок в управляемую пользовательскую среду дает мощный синергетический эффект для всей компании:

• Ликвидация «черного ящика»: Многолетний легаси-код успешно вскрыт, структурирован и оцифрован. Учетные механизмы становятся абсолютно прозрачными.
• Новая культура коммуникации: Код выражений и условий превращается в единый язык общения программиста и бухгалтера. Бухгалтер перестает быть пассивным регистратором - он умеет читать формулы и на основе сквозных маркеров в комментариях формулирует точечные, профессиональные задачи.
• Промышленный конвейер настройки: Связка встроенного сервиса микро-отладки (по первой строке ТЧ) и макро-сервиса массовой верификации (обработка «Администрирование») позволяет быстро, безопасно и итерационно настраивать и проверять десятки видов документов, сводя время на согласование ТЗ к нулю.