План-факт анализ сравнивает версии плана: агенты сохраняют основания каждого отклонения

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

На 1 сентября 2026 года план был 1 000 000 ₽: десять насосов по 100 000 ₽. На 18 сентября утвердили новую версию: восемь по той же цене, 800 000 ₽. Факт на 30 сентября составил 840 000 ₽, потому что каждый из восьми насосов стоил 105 000 ₽. Все суммы вымышлены, валюта и состав затрат одинаковые.

Отклонение в рублях считаем как факт минус план, в процентах делим эту разницу на положительный план и умножаем на 100. У исходной версии получается −160 000 ₽, или −16 %. У пересмотренной +40 000 ₽, или +5 %. Оба расчёта верны. Они отвечают на разные вопросы: как изменился первоначальный замысел и как исполнено последнее согласование.

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

Почему итог изменился, хотя месяц закрыт? Иногда изменился не бизнес, а набор документов. Сентябрьская поставка попала в систему в октябре. Если отчёт относит её к месяцу загрузки, сентябрь становится дешевле, а октябрь дороже без нового решения о закупке.

Дата операции и дата появления в системе должны храниться отдельно. В отчёте видны период и дата, на которую собраны данные. Тогда можно воспроизвести сентябрьский отчёт, выданный 1 октября, и показать новую редакцию после позднего документа. Переписанный задним числом экран без этой отметки снова уничтожает договорённость.

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

Почему потратили меньше? В учебной закупке исходные −160 000 ₽ состоят из разных вещей. Два насоса перенесли на октябрь: объём сентября уменьшился на 200 000 ₽ по плановой цене. Восемь купленных подорожали на 5 000 ₽ каждый, что добавило 40 000 ₽. Разница сходится, но отложенные насосы компании ещё нужны.

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

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

Если основания нет, отчёт сохраняет сумму и статус «причина не подтверждена». Гипотезу агента можно оставить отдельно, назначив человека, который её проверит. Когда он подтвердит причину, она попадёт в разбор следующего плана. Готовое объяснение без документа закрывает разговор раньше, чем компания выяснила, что случилось.

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

Утверждённый план меняется через новую версию с автором, датой и основанием. Кто вправе её утвердить, решает компания. Запрет перезаписывать исходный план закрепляют правами и проверкой сервера, а порядок работы описывают в правилах для агентов. Запрет менять прошлое, записанный только в чате, сам по себе сохранность не обеспечивает.

Расчёт должен повторяться без языковой модели. ИИ может подготовить пояснение по доступным документам: подключение такого агента уже описывает ПланФакт. Утверждать причину и менять бюджет ему не поручают. Версии кода и правил остаются в репозитории клиента; версии планов, фактов и согласований хранятся в базе системы. Наличие Git у разработчика ещё не даёт историю рабочих данных.

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

На чём основано наше предложение? На vibecoding.ru инженер ведёт машину агентов, решения и разборы сохраняются в документах проекта, а код меняется по этим правилам. Устройство видно на открытой странице машины. Это наш рабочий проект; финансовый план-факт для клиента этой историей мы не доказываем.

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

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

Число коммитов не доказывает, что отчёт верен. На /open общий ряд основной ветки начинается с 1 июля 2026 года, карта регионов со 2 июля 2026 года, а другие счётчики имеют свои срезы. Так же нельзя сводить данные двух отчётов только потому, что у обоих подпись «сентябрь»: сначала сверяют период, состав и дату данных.

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

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

Приёмка должна пытаться испортить отчёт. В учебной закупке сначала сравните факт с обеими версиями, затем поменяйте только новый план. Исходное отклонение обязано остаться прежним. Загрузите один документ повторно и уберите основание переноса. Правильный итог не удваивается, а неподтверждённая причина не превращается в объяснение.

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

Если вести эту работу некому, есть подписка на агентную разработку. На 8 октября 2026 года тариф «Один проект» стоит 250 000 ₽ в месяц: инженер с машиной агентов, одна задача в работе, код в репозитории клиента, пауза в любой месяц. В такой поток можно поставить версии плана, привязку факта к периоду и расшифровку отклонений. Это цена месяца подписки, а не обещание закончить модуль за месяц: состав работ и порядок приёмки согласуются по вашей системе.

Начать можно с разбора задачи компании. Подготовьте исходный план, один пересмотр и пример отклонения без объяснения. По этому набору будет видно, чего не хватает: настройки готового отчёта или кода, который сохранит историю.

1. Сохраняйте исходный план. Пересмотр выпускайте отдельной версией с датой, автором и основанием.

2. Перед сравнением сверяйте период, событие учёта, валюту, состав суммы и дату среза факта.

3. Разделяйте арифметику и причину: перенос объёма не равен экономии, а объяснение без документа остаётся гипотезой.

4. Принимайте разработку на повторном импорте, позднем документе, черновике плана и нулевой базе.

5. Подтверждённую причину доводите до решения о следующем периоде. Затем проверяйте, изменился ли результат.