Между БДР и БДДС

Договор согласован, а оплата всё равно стоит: где ломается цепочка

Типовая условная картина. Договор прошёл юриста, все визы стоят, инициатор считает вопрос закрытым. Через неделю поставщик спрашивает про деньги, а казначейство про этот платёж ничего не знает 🤷‍♂️

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

Условная цепочка:
1. Договор согласован. Владелец: юрист. Передача: согласованная версия доступна заказчику и финансисту.
2. Заявка на оплату. Владелец: заказчик. Передача: заявка ссылается на договор, сумма и срок соответствуют условиям.
3. Подтверждающие документы. Владелец: заказчик. Передача: счёт, акт или другой документ, который требует договор, приложен к заявке.
4. Проверка лимита и условий. Владелец: финансист. Передача: статья бюджета определена, лимит есть, условия оплаты сверены.
5. Платёжный календарь. Владелец: казначейство. Передача: платёж стоит на конкретную дату.
6. Исполнение. Владелец: казначейство. Результат: платёж проведён, статус виден заказчику.

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

Что можно сделать: возьмите свой регламент и для каждого шага письменно ответьте на два вопроса. Кто владелец? По какому признаку шаг считается завершённым и передаётся дальше? Если где-то ответ звучит как «ну, обычно...», именно там платёж и будет стоять 📌

А на каком стыке чаще застревают платежи у вас: между заказчиком и финансистом или между финансистом и казначейством?

Утренняя сводка: цифры из разных мест, собранные вместе.

Деньги в банке есть. А что с авансом и выполнением?

У финансового директора строительной компании утром не один вопрос. Сколько денег доступно? Какая часть аванса закрыта? Что выполнено, что подписано, что проведено в учёте? Сколько осталось по лимитам?

Ответы лежат в разных местах: в 1С, таблице сверки КС-2, банке, контрольной ведомости и топливных кабинетах. Просто поставить эти цифры рядом недостаточно. Можно получить красивую сводку, в которой каждый показатель верен, а общий вывод ошибочен.

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

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

Описанный в рабочем задании метод включает чтение 1С, таблицы сверки КС-2, банковского API, контрольной ведомости на Диске и балансов топливных кабинетов. Затем собираются HTML и PDF: итоги, остатки и проценты пересчитываются, версии сверяются между собой, ключевые суммы независимо проверяются по первичным документам 1С.

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

В приложении показан демонстрационный PDF на 9 страниц. Бизнес-задача и описанный метод взяты из рабочего задания. Все названия, даты, суммы и показатели образца вымышлены. Демонстрационные данные связаны между собой и пересчитаны; это не отчёт о реальных финансовых результатах компании.

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

Вывод здесь не про количество графиков. Хорошая утренняя сводка показывает не только число, но и источник, дату и статус подтверждения.

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

Albato: где интеграция экономит время, а где создаёт ещё одну точку отказа

Сервисы вроде Albato хороши там, где сценарий простой: событие в одной системе → запись в другой. Условный пример: оплаченный счёт из CRM попадает в таблицу для казначейства. Руками это тянуть скучно, интеграция снимает рутину 🙂

Но у каждой связки появляется своя точка отказа. Вот что написано в справке Albato:
• ошибки фиксируются в журнале, и их можно переотправить вручную;
• автоматическая переотправка применяется только к ошибкам типа «таймаут»;
• если связка остановилась, запускать её снова нужно вручную.

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

Что сделать до запуска:
1. Назначить владельца контроля. Конкретного человека, а не «отдел».
2. Договориться, как регулярно он смотрит журнал ошибок и статус связки.
3. Перед повтором разбираться с причиной и проверять, что уже дошло до получателя. Повторная отправка может создать дубль записи, а если на неё завязаны дальнейшие шаги, последствия уйдут дальше по цепочке ⚠️
4. Описать ручной резервный путь: кто и как переносит данные, пока связка стоит.

Чем проще сценарий, тем меньше мест, где он тихо сломается 📋

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

Stormbpmn: зачем рисовать процесс до автоматизации

Прежде чем автоматизировать заявку на оплату, её стоит нарисовать. На схеме развилки видно лучше, чем в переписке ✏️

BPMN нужна, чтобы бизнес и ИТ договорились об одном и том же: последовательности действий, ролях и взаимодействии систем. Описывать процесс так можно и до автоматизации. Для этого есть сервисы, например Stormbpmn.

Условный путь заявки на оплату:
1. Инициатор создаёт заявку и прикладывает документы.
2. Владелец статьи бюджета согласует.
3. Бухгалтерия проверяет документы.
4. Проверка лимита по статье.
5. Казначейство включает платёж в реестр.

Пока это список, всё выглядит гладко. На схеме сразу появляются вопросы 🔍

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

Что происходит при превышении лимита? Отказ, перенос на другой период или отдельное согласование, и у кого?

Кто владелец процесса целиком, а не отдельного шага?

Где граница систем? Какие данные казначейство получает автоматически, а какие кто-то переносит руками?

Каждый такой вопрос, по-моему, это управленческое решение, а не настройка. Схема их подсвечивает, но не принимает 🤝 Сама она ничего не автоматизирует и договорённости не заменяет.

Практический шаг: нарисуйте свой процесс заявки на оплату с дорожками по ролям и отметьте все ветки возврата. Если какую-то ветку никто не может описать, начинать стоит с неё.

Какой шаг в вашем процессе согласования платежей вызывает больше всего возвратов?

Проблема процесса или запрос на доработку

Многие задачи в ИТ-реестре финансовой службы, по-моему, вообще не про ИТ 🙃

Под заявкой «доработать систему» часто прячется неразобранный процесс.

Условный пример. Заявка: «Сделать обязательным поле с договором в заявке на оплату, казначейство получает заявки без договора». Выглядит как доработка. Но стоит спросить: кто должен прикладывать договор, на каком шаге его проверяют и что происходит, если договора нет. Если ответа нет ни у кого, обязательное поле просто научит людей выбирать первый попавшийся договор.

Я бы прогонял каждую задачу через четыре вопроса 📋

Владелец. Кто отвечает за результат в бизнесе, а не за код. Если владельца нет, задача ещё не готова к реестру.

Эффект. Что изменится в деньгах, времени или рисках. «Будет удобнее» тоже эффект, но слабый.

Приоритет. Не громкость инициатора, а эффект плюс срочность. Иначе реестр превращается в очередь самых настойчивых.

Критерий готовности. Как мы поймём, что всё сделано. Например: заявки без договора не доходят до казначейства.

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

Автоматизация хорошо закрепляет договорённости. Создавать их вместо людей она не умеет.

Практический шаг: откройте свой реестр и пометьте задачи без владельца и без критерия готовности. Обычно это и есть кандидаты на разговор, а не на разработку.

Как у вас устроен реестр ИТ-задач: кто решает, что попадает в работу первым?

Почему дорожный объект нельзя оценивать только по БДР

Объект может быть прибыльным в БДР и при этом съедать деньги компании. В дорожном строительстве это особенно заметно 🚧

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

БДР отвечает на вопрос, заработали ли мы. Выручка в нём обычно отражает выполненные и принятые работы, а не поступившие деньги. БДДС отвечает на другой вопрос: хватит ли денег, чтобы дожить до этого заработка.

Условный пример. Подрядчик закрыл объёмы за месяц, акт подписан, в БДР маржа. Но оплата придёт позже, часть суммы по условиям договора удерживается до конца работ, а за материалы и технику уже нужно платить. Прибыль есть, денег нет 💸

Что я бы смотрел по объекту, кроме БДР:
• дебиторку по подписанным актам и реальные сроки оплаты
• авансы полученные и то, сколько из них уже отработано
• незавершённые работы, которые выполнены, но ещё не приняты заказчиком
• исполнение договора: объёмы и сроки против графика

Отдельная история с авансом. Он улучшает БДДС сегодня, но это ещё не выручка. Пока аванс не закрыт работами, это деньги заказчика, которые ещё предстоит отработать.

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

Мой вывод простой: объект оценивается связкой из трёх взглядов. Прибыль по БДР, деньги по БДДС и физика по объёмам и срокам. Если смотреть только на один, картина обманчива.

Практический шаг: для каждого объекта положите рядом маржу по БДР, сальдо денежного потока с начала работ и процент выполнения объёмов. Расхождения между ними и есть повод для разговора.

Какой из этих трёх показателей у вас на объектах обновляется хуже всего?

Из владельца продукта обратно в пользователи

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

До недавнего времени я руководил проектом внедрения 1С.БитФинанс в крупном девелопере. Сейчас я финансовый директор строительной компании. Роль сменилась, и вместе с ней сменился вопрос, который я задаю результату.

Владелец продукта смотрит на систему изнутри. Настроены ли маршруты, закрыты ли задачи, понятна ли логика справочников, укладываемся ли в план работ. Это правильные вопросы, без них проект не доедет.

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

Мне кажется, на этом стыке теряется много пользы. Задача формально закрыта, а финансист всё равно открывает Excel 📊

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

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

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

А вы сейчас чаще смотрите на систему как владелец или как пользователь?

Какой отчёт вы до сих пор собираете руками?

У каждого финансиста есть отчёт, который живёт на ручной тяге 🙂

Хочу собрать такие истории и разобрать самые частые в следующих постах.

Напишите в комментариях название отчёта и самое ручное действие в нём. Например:
• сверка выгрузок из двух систем
• перенос факта оплат в Excel
• ручная разноска по статьям

Какой отчёт и какое действие у вас?

Зарплату рассчитали правильно. А прибыль по проектам всё равно неправильная. Эти две вещи вполне могут случиться одновременно. 🧩

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

Ошибка не обязательно в расчёте зарплаты. Возможно, никто не определил, как распределять стоимость работы между проектами. 🏗️

Я бы разделил здесь три вопроса.

1. Сколько начислено сотруднику?

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

2. Когда ушли деньги? 💸

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

3. Какому проекту относятся затраты?

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

В ЗУП есть механизмы настройки отражения и распределения зарплаты. Но экономический смысл этих настроек нужно задать людям. Сам обмен между базами не решает, на какой объект относить работу. 🔧

Для сверки я бы взял один месяц: сопоставил начисления, удержания, выплаты, взносы и распределение по проектам. Не заставлял разные суммы совпасть, а объяснил каждую разницу.

Где у вас чаще теряется связь: между начислением и выплатой или между сотрудником и проектом? 💬

Красивый график умеет очень убедительно показывать неправильную цифру. Особенно если она зелёная. 📊

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

Представим: в одном отчёте выручка — это поступления на счёт. В другом — продажи за период. Оба графика подписали «Выручка» и вынесли на совещание. Дальше можно долго обсуждать, кто неправильно выгрузил данные. Хотя сначала нужно договориться о смысле показателя. 🧩

До дашборда я бы составил короткий паспорт каждой ключевой цифры:

— Источник: из каких данных её получаем.
— Период: по какой дате относим операцию к месяцу.
— Формула: что включаем, исключаем и как учитываем возвраты.
— Ответственный: кто объясняет расхождения и исправляет исходные данные.

В DataLens вычисляемое поле можно создать в датасете или в отдельном чарте. Поле датасета доступно всем чартам на его основе, а локальное поле — только своему. Общую логику показателя разумнее не размножать по отдельным графикам. 🔧

И ещё одна проверка: когда данные обновились в последний раз? Красивый экран со вчерашним остатком не отвечает на вопрос, можно ли платить сегодня.

Мой критерий готовности прост: цифру можно объяснить и сверить с источником. Цвет столбиков подождёт. 🔎

А у вас споры вокруг отчётов чаще про данные или про то, как считать показатель? 💬