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

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

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

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

Ответы лежат в разных местах: в 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. Казначейство включает платёж в реестр.

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

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

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

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

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

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

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

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