Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, как аналитику за неделю понять, где типовая 1С закроет казначейство, а где начнётся доработка — и как оформить этот вывод так, чтобы его нельзя было оспорить на защите бюджета.
Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС. В казначейскую тему я попал со стороны заказчика: участвовал во внедрении казначейского контура в группе компаний, писал требования к интеграции с банком и принимал работу подрядчика. Эта позиция даёт полезный угол зрения — ты видишь не то, что система умеет, а то, за что тебе потом отвечать.
Картина повторяется из проекта в проект. Финансовый директор приносит список «хотелок» — сорок с лишним пунктов вперемешку: от «нужен платёжный календарь» до «чтобы заявка сама отзывалась, если её не согласовали за три дня». Подрядчик смотрит минут пять и говорит: «Типовая почти всё закрывает». Бюджет утверждают как типовое внедрение с небольшой адаптацией. Через два месяца выясняется, что «почти» стоит ещё половину бюджета, и разговор с CFO становится очень неприятным.
Проблема не в том, что кто‑то соврал. Проблема в том, что никто не проверил. Ниже — маршрут из пяти шагов, матрица разрывов, два запроса для проверки гипотез данными и блок про то, где метод не работает. На выходе получается документ, который можно положить на стол финдиректору.
Исходные условия
Метод описан под конкретную рамку. Если ваша отличается — выводы придётся пересчитывать.
Группа компаний из 3–10 юрлиц, централизованное казначейство, 200–2000 исходящих платежей в месяц.
Учёт уже ведётся в 1С, рассматриваются: 1С:Управление холдингом, 1С:ERP Управление холдингом, отраслевые надстройки вроде БИТ.ФИНАНС или WA:Финансист поверх существующей конфигурации.
Актуальность на июль 2026 года. В редакции 1С:ERP Управление холдингом 3.3, вышедшей в конце 2025 года, в казначейском блоке появились настройка индивидуальных платёжных дней для организаций холдинга и автоматическая отмена просроченных заявок на оплату (информационное письмо фирмы «1С» № 33956). Год назад оба пункта уходили в доработку. Сегодня — не уходят. Состав функциональности всегда проверяйте по документации конкретного релиза: в разных конфигурациях и версиях поддержка отличается.
Нет требований к биржевым операциям, деривативам и хеджированию. Это отдельный класс задач.
Ключевая мысль, которую я вынес из своего проекта: gap‑анализ проводится не против «1С», а против конкретной версии конкретной конфигурации на конкретную дату. Всё остальное — гадание.
Дальше я проведу через все пять шагов одно живое требование, чтобы было видно, как оно превращается в строку матрицы. Возьмём формулировку, которую мне принесли ровно в таком виде: «Хотим удобное согласование заявок».
Шаг 1. Разложить требования на атомы
Требование годится для gap‑анализа, только если на него можно ответить «да» или «нет», открыв систему и показав экран. Всё остальное — пожелание, его нельзя ни проверить, ни оценить.
Помню, как мы потратили на то самое «удобное согласование» полтора часа, прежде чем я догадался спросить, что именно сейчас неудобно. Выяснилось: три уровня согласования, и на втором сидит один человек, который бывает в отпуске. Настоящее требование звучало так: «при отсутствии согласующего заявка автоматически уходит его заместителю через 24 часа».
Мой вариант, который я обычно использую — переписать требование по шаблону:
Роль в ситуации должна действие, чтобы результат. Проверка: что именно я открою и покажу.
Наше требование после переписывания:
Заявка при отсутствии реакции согласующего в течение 24 часов должна автоматически переходить на заместителя, чтобы платёж не выпадал из реестра на завтра. Проверка: открываю карточку заявки, вижу в истории маршрута автоматический переход и отметку времени.
Как проверить, что шаг сработал: возьмите любые пять требований и попробуйте по каждому назвать конкретный экран или отчёт, который откроете на демо. Если хотя бы по одному не получается — требование ещё не готово, возвращайтесь к бизнесу.
Шаг 2. Наложить требования на карту типового контура
Дальше нужна карта — иначе непонятно, где искать разрывы. На концептуальном уровне казначейский контур в рассматриваемых конфигурациях выглядит похоже: заявка проходит согласование, проверяется по лимитам, попадает в реестр, уходит в банк, возвращается выпиской и становится фактом. Реализация при этом у ERP УХ, БИТ.ФИНАНС и WA:Финансист разная, и это как раз то, что вы будете сравнивать.
На Рис. 2 я собрал этот контур с точками, где, по моему опыту, разрывы возникают чаще всего.
Главное, что нужно вынести из схемы: по моему опыту, большинство критичных разрывов возникает на границах процесса — на входе (кто и как заводит заявку), на развилке лимита (что происходит с превышением), на стыке с внешним миром (банк) и на возврате факта. Сам по себе платёжный календарь типовой закрывает почти везде. Ломается чаще то, что до него и после.
Зоны с номерами на схеме соответствуют строкам матрицы:
№ | Зона | Требование бизнеса | Типовой механизм | Разрыв | Тип | Цена разрыва |
|---|---|---|---|---|---|---|
1 | Заявка | Автопереход на заместителя через 24 часа | Маршруты согласования, условия перехода | Частичный | Расширение |
|
2 | Лимит | Резерв лимита на момент согласования | Лимиты по статьям ДДС и ЦФО | Нет | — | — |
3 | Календарь | Индивидуальные платёжные дни по юрлицам | Есть в ERP УХ 3.3 | Нет (при версии 3.3+) | — | — |
4 | Банк | Частичное исполнение платежа | Зависит от банка и протокола | Полный | Интеграция |
|
5 | Факт | Автосопоставление выписки с заявкой | Сопоставление по реквизитам | Частичный | Доработка |
|
Наше требование встало в строку 1: механизм маршрутов есть, условие перехода по таймауту настраивается не везде — значит, разрыв частичный. Знаки вопроса в последней колонке закроем на шаге 5.
Шаг 3. Классифицировать разрыв по стоимости закрытия
На шаге 2 вы отметили, где разрыв есть. Само по себе «разрыв есть» — бесполезная формулировка: она пугает CFO и ничего не даёт подрядчику. Теперь каждый отмеченный разрыв нужно отнести к одному из четырёх типов, потому что стоят они принципиально разных денег:
Настройка. Функционал есть, его надо включить и параметризовать. Дни, часы.
Расширение. Механизм есть, но не хватает реквизита, отчёта, условия в маршруте. Расширение конфигурации, дни‑недели.
Интеграция. Функционал есть, но зависит от внешней стороны — банка, ЭДО, платформы. Срок определяете не вы.
Изменение процесса. Функционала нет и не будет, потому что это не задача учётной системы. Меняется регламент, а не код.
Четвёртый тип аналитики упорно пытаются закрыть кодом. Мне как‑то попалось требование «не допускать кассовых разрывов». Учётная система умеет многое: показать разрыв заранее, зарезервировать средства, приоритизировать платежи, заблокировать превышение лимита. Но полностью исключить кассовый разрыв только средствами учётной системы невозможно — в какой‑то момент решение принимает казначей. Я бы предпочёл честно вынести эту часть в регламент, чем закладывать в бюджет доработку, которая не решит проблему.
Как проверить, что шаг сработал: по каждому разрыву назван ответственный за его закрытие. Если ответственный — «команда внедрения», тип определён неправильно. У интеграционного разрыва ответственный сидит в банке. У разрыва, закрываемого изменением процесса, — в финансовой службе.
Шаг 4. Проверить разрывы данными, а не мнением
Вот здесь начинается разница между аналитиком и стенографистом. Бизнес говорит «у нас очень много заявок» и «постоянные превышения лимитов». Это гипотезы, их надо посчитать по действующей базе.
Сразу оговорюсь про оба запроса ниже. Они приведены как иллюстрация подхода, а не как готовый к запуску код. Имена документов и реквизитов в разных конфигурациях отличаются: реквизита с датой утверждения может не быть вовсе, потому что согласование хранится в бизнес‑процессах, задачах или маршрутах. В реальном проекте анализ обычно строят на регистрах, а не на документах, и дата платежа далеко не всегда совпадает с датой документа. Смотрите на логику, а не на синтаксис.
Первый запрос на языке запросов 1С:Предприятие 8 — профиль нагрузки по дням:
// (язык запросов 1С:Предприятие 8) ВЫБРАТЬ НАЧАЛОПЕРИОДА(Заявки.Дата, ДЕНЬ) КАК ДеньПлатежа, Заявки.Организация КАК Организация, КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Заявки.Ссылка) КАК КоличествоЗаявок, СУММА(Заявки.СуммаДокумента) КАК СуммаЗаявок ИЗ Документ.ЗаявкаНаРасходованиеСредств КАК Заявки ГДЕ Заявки.Дата МЕЖДУ &НачалоПериода И &КонецПериода И Заявки.Проведен СГРУППИРОВАТЬ ПО НАЧАЛОПЕРИОДА(Заявки.Дата, ДЕНЬ), Заявки.Организация УПОРЯДОЧИТЬ ПО КоличествоЗаявок УБЫВ
Дальше цифры я привожу как порядок величин, типичный для группы такого размера, — у вас они будут свои, и именно в этом весь смысл упражнения. Скажем, «очень много заявок» превращается в 60 штук в обычный день и 190 в день пиковых выплат, 25-е число. Это уже два разных требования к интерфейсу: при 60 заявках казначей спокойно работает списком, при 190 нужен групповой отбор и массовое утверждение. Пока нет цифры, вы не знаете, какое из двух требований пишете.
Второй запрос — про длительность согласования, чтобы понять, реальна ли наша боль с зависшими заявками:
// (язык запросов 1С:Предприятие 8) ВЫБРАТЬ Заявки.Ссылка КАК Заявка, Заявки.Дата КАК ДатаСоздания, Заявки.ДатаУтверждения КАК ДатаУтверждения, РАЗНОСТЬДАТ(Заявки.Дата, Заявки.ДатаУтверждения, ЧАС) КАК ЧасовВСогласовании ИЗ Документ.ЗаявкаНаРасходованиеСредств КАК Заявки ГДЕ Заявки.Проведен И Заявки.ДатаУтверждения > ДАТАВРЕМЯ(1, 1, 1) И РАЗНОСТЬДАТ(Заявки.Дата, Заявки.ДатаУтверждения, ЧАС) > &ПорогЧасов УПОРЯДОЧИТЬ ПО ЧасовВСогласовании УБЫВ
Допустим, выборка показала: за квартал 214 заявок висели дольше суток, из них 41 — дольше трёх дней. Как и предполагал, картина оказывается резче слов бизнеса. Требование из шага 1 подтверждено цифрой и перестало быть чьим‑то раздражением — теперь его можно нести на защиту.
Смысл не в конкретном запросе, а в привычке: каждое требование, которое звучит как «много», «долго», «постоянно», должно быть подтверждено выборкой до того, как попадёт в оценку.
Как проверить, что шаг сработал: в матрице не осталось строк, где обоснование разрыва — это чьё‑то мнение. Либо цифра, либо ссылка на регламент, либо ссылка на ограничение банка.
Шаг 5. Оценить стоимость и выбрать стратегию закрытия разрыва
Разрыв сам по себе — не повод для доработки. Повод — когда цена разрыва выше цены его закрытия. Цену я считаю грубо, тремя вопросами: сколько человеко‑часов в месяц уходит на обход, какова вероятность денежной ошибки, попадает ли это под требование регулятора.
Третий вопрос в 2026 году стал весомее. Федеральный закон от 23.07.2025 № 248-ФЗ ввёл поэтапный обязательный приём цифрового рубля, и первый этап стартует 1 сентября 2026 года. Под него попадает продавец, у которого выручка за 2025 год превышает 120 млн рублей и который на 1 января 2026 года обслуживался в банке из реестра системно значимых кредитных организаций либо из реестра значимых на рынке платёжных услуг.
Ответственность за необоснованный отказ обеспечить оплату цифровыми рублями установлена частью 4 статьи 14.8 КоАП РФ — для юридических лиц от 30 до 50 тысяч рублей, причём за каждый факт отказа.
Обратите внимание на формулировку: речь именно о приёме оплаты от физических лиц, а не об исходящих платежах. Но если компания подпадает под требования закона, для казначейства это означает новую сущность в контуре — счёт цифрового рубля, поступления по нему, отражение остатка и его попадание в платёжный календарь.
Тогда в матрице стоит завести отдельную строку под операции с цифровым рублём. У большинства команд, с которыми я это обсуждал этим летом, такой строки не было вообще.
По каждому разрыву решение принимается по одной из четырёх веток. Логику собрал на Рис. 3.
Главное, что должно остаться от этой схемы: ветка «есть в новой версии» проверяется раньше, чем ветка «дорабатываем». Индивидуальные платёжные дни — ровно тот случай. Команда, которая не сверилась с составом релиза, спокойно заложит в смету доработку того, что уже поставляется в коробке.
Наше сквозное требование проходит дерево так: обязательным не является, цена обхода — те самые 214 зависших заявок за квартал и ручной обзвон согласующих, регламентом не лечится (проверено на практике: договорённость «отвечать за сутки» живёт две недели), в свежем релизе автоперехода по таймауту на заместителя нет. Итог — расширение, средняя цена. Строка 1 матрицы закрыта.
Как проверить, что шаг сработал: в матрице нет ни одной пустой ячейки в колонке «Цена разрыва», и по каждой строке вы можете за 30 секунд объяснить финдиректору, почему выбрана именно эта ветка. Если объяснение занимает больше — вы ещё не закончили.
Интеграция с банком: зона, где ломается чаще всего
Зона 4 даёт больше половины всех неприятных сюрпризов, поэтому разберу её отдельно.
Сначала протокол. Технология DirectBank позволяет отправлять платёжные документы и получать выписки прямо из 1С, без отдельного клиент‑банка. Но набор возможностей за этим названием меняется. Сбербанк с 15 мая 2026 года начал поэтапное отключение универсального платёжного шлюза, который до этого использовался для обмена в сервисе 1С:ДиректБанк, и планирует полностью вывести его из эксплуатации к третьему кварталу 2026 года.
Вместо него — Sber API. Поддержка нового протокола появлялась в конфигурациях не одновременно: сначала в 1С:Бухгалтерии, УНФ и Рознице, для ERP, УТ, КА и ЗУП — более поздними обновлениями. То есть «работаем через ДиректБанк» в 2026 году уже не описывает вашу интеграцию: проверять надо по каждому банку и по каждой конфигурации отдельно.
Дальше статусная модель. Условный фрагмент отправки платежа (точные имена полей смотрите в документации своего банка):
// (JSON, условный фрагмент запроса к API банка) { "externalId": "e2b1a7c4-5d19-4f0a-9c11-0af31d6b7c82", "documentNumber": "10427", "documentDate": "2026-07-14", "amount": 1450000.00, "currency": "RUB", "payerAccount": "40702810900000001234", "payeeAccount": "40702810400000005678", "payeeInn": "7701234567", "purpose": "Оплата по договору № 118/26 от 03.06.2026, в т.ч. НДС", "urgency": "NORMAL" }
А вот ответ, ради которого стоит затевать весь разговор:
// (JSON, условный фрагмент статуса от банка) { "externalId": "e2b1a7c4-5d19-4f0a-9c11-0af31d6b7c82", "state": "PARTIALLY_EXECUTED", "executedAmount": 900000.00, "reason": "Недостаточно средств на счёте на момент исполнения" }
Вопросы, которые аналитик обязан задать до подписания ТЗ, а не после:
Что происходит с заявкой в 1С при частичном исполнении? Закрывается? Остаётся открытой на разницу? Кто решает — казначей руками или система?
Можно ли отозвать платёж, уже ушедший в банк, и как отзыв возвращается в учёт?
Сколько статусов реально отдаёт банк? У одного их четыре, у другого одиннадцать, и между собой они не совпадают.
Идемпотентен ли обмен, если банк отдал статус, а связь оборвалась до записи в базу? По какому идентификатору ловятся дубли, как устроен retry и какая семантика доставки заявлена — at‑least‑once или что‑то строже?
Могу себе представить возражение: «это же вопросы к разработчику». Нет. Разработчик реализует ту статусную модель, которую опишет аналитик. Не описали — получите ту, которую он придумает сам.
Реальный кейс: с чего начинают крупные внедрения
Это не мой проект, но кейс опубликован и хорошо иллюстрирует мысль — автоматизация казначейства в ФГУП «РФЯЦ‑ВНИИТФ им. академика Е. И. Забабахина». Задача у предприятия была двойная: заместить часть исторических систем и убрать бумажный документооборот в утверждении заявок, кассовых операциях, формировании реестров и ведении платёжного календаря. В качестве целевого решения команда проекта выбрала 1С:ERP Управление холдингом.
Что отсюда стоит взять аналитику: проект начали не с бюджетирования и не с МСФО, а именно с казначейского блока.
Ход логичный: заявки и платежи — это ежедневная операционка, эффект чувствуют все и сразу. И казначейство удобно для gap‑анализа: цикл короткий, обратная связь приходит за дни, а не за квартал.
Где этот метод не сработает
Если решение уже куплено. Тогда gap‑анализ превращается в список доработок, а не в инструмент выбора. Делать всё равно надо — чтобы бюджет доработок был известен заранее.
На горизонте свыше года. Матрица, собранная летом, к следующей весне потребует пересборки как минимум из‑за смены релизов конфигурации.
Если бизнес не готов отвечать. Метод стоит на проверяемых требованиях. Если казначей не может сформулировать, что хочет увидеть на экране, таблица не поможет.
При требованиях к финансовым инструментам. Хеджирование, деривативы, сложные кредитные портфели — там разрыв определяется методологией учёта, а не наличием кнопки.
Чек‑лист перед защитой gap‑анализа
Каждое требование переписано так, что на него можно ответить демонстрацией экрана.
Зафиксированы версия конфигурации и дата, на которую проводилось сравнение.
Проверен состав последних релизов — нет ли в них того, что вы собрались дорабатывать.
Каждый разрыв отнесён к одному из четырёх типов, и у каждого назван ответственный.
Формулировки «много», «долго», «постоянно» подтверждены выборкой из базы.
По интеграции с банком описана статусная модель, включая частичное исполнение и отзыв.
Проверено, попадает ли компания под обязательный приём цифрового рубля.
Для каждого разрыва посчитана цена: часы обхода, риск ошибки, требование регулятора.
Если хотите заодно проверить, насколько уверенно чувствуете себя в задачах бизнес‑аналитика 1С, можно пройти бесплатный короткий вступительный тест. Он поможет понять, какие темы уже хорошо знакомы, а где остались пробелы.
Хороший аналитик на этом этапе экономит компании не месяцы, а деньги — те самые, которые иначе уйдут в доработку функционала, уже лежащего в коробке. Плохой приносит на защиту список из сорока пунктов со словом «частично» напротив каждого.
Когда требования бизнеса уже собраны, дальше начинается более сложная часть работы: выбрать подходящее решение 1С, обосновать его и провести задачу до приёмки. Именно на этом этапе особенно заметны пробелы в системном анализе и знании возможностей платформы.
Эти ситуации можно отдельно разобрать бесплатных занятиях — сверить свой подход с практикой экспертов, задать вопросы и понять, какие навыки стоит усилить.
2 сентября в 20:00. «Как аналитику выбрать решение 1С для автоматизации казначейства: сравниваем 1С, 1С:УХ и 1С.УХ». Записаться
15 сентября в 20:00. «Как аналитик 1С ведет задачу от интервью до приемки: сквозной кейс интеграции с мобильным рабочим местом». Записаться
Полный список бесплатных уроков августа можно найти в дайджесте.
