Битрикс24, 1С и Финтабло: один маршрут для каждой оплаты

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

Что в этом опасного

Пока объектов мало, финансист держит все в голове. Когда их становится больше, начинаются три проблемы:

• Одни и те же деньги обещаны дважды. Две заявки по одному объекту согласованы в разных чатах, каждая укладывается в бюджет, а вместе - нет.
• Бюджет узнает о расходе задним числом. Пока платеж не разнесли, остаток по объекту выглядит больше, чем он есть.
• Нельзя быстро ответить "сколько можно потратить". Ответ собирается вручную из трех систем, и к вечеру он уже устарел.

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

Этап, который застрял

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

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

Что взяли в работу

Мы предложили четыре этапа, каждый с понятным результатом:

• Перенести контур в рабочий Битрикс24: смарт-процессы, роли, права, маршрут заявки, уведомления.
• Научить контур считать: проверки по бюджету и резерв суммы делает сервис, а не человек.
• Связать одобренную заявку с Финтабло: она сама появляется в платежном календаре.
• Замкнуть цикл фактом оплаты: платеж закрывает заявку, снимает резерв и обновляет бюджет.

Оплата - после приемки каждого этапа. Сервер, аккаунты и доступы оформлены на заказчика, нам доступ выдавали временно на срок работ.

Шесть связанных разделов в Битрикс24

Весь контур живет в Битрикс24, в шести смарт-процессах, связанных между собой:

• Статьи ДДС - единый справочник расходов, 58 статей;
• Нормативные расценки - справочник для расчетов по объекту;
• Паспорт объекта - производственные данные по объекту;
• Бюджет объекта - бюджет, связанный с паспортом;
• Бюджетные строки - лимиты по направлениям и статьям: сколько выделено, сколько зарезервировано, сколько освоено, сколько доступно;
• Заявка на оплату - сумма, счет, договор, статья, объект, решение и отметка об оплате.

Любая заявка привязана к объекту и к строке его бюджета. Поэтому на вопрос "сколько еще можно потратить по этому объекту" Битрикс24 отвечает сам.

Маршрут по ролям

В маршруте пять ролей, у каждой свои права и свои уведомления:

• Инициатор создает заявку, прикладывает счет и отправляет на проверку;
• Сметчик ведет бюджет и расценки по объекту;
• Финконтролер проверяет документы и решает спорные случаи;
• Руководитель одобряет или отклоняет оплату;
• Казначей проводит оплату.

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

Проверки до того, как заявка попадет к руководителю

Главное, ради чего все строилось: руководитель получает заявку уже проверенной. Отдельный сервис на сервере заказчика за секунды проверяет ее по пяти условиям:

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

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

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

Одобренная заявка сама попадает в Финтабло

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

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

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

Инструкции и видео для каждой роли

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

Первый этап проверял сам заказчик

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

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

Где разошлись и как договорились

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

Что сделали для заказчика сверху

Заказчик попросил отдельно оформить безакцептные платежи - налоги, зарплату, лизинг, комиссии банка. Для них завели технический объект "Администрация" с техническими бюджетными строками и лимитами, посчитанными по фактическим расходам прошлых месяцев. Обязательные платежи тоже идут через маршрут, но не тормозят на проверке лимитов там, где их нельзя не заплатить.

Результаты

Цифр вроде "согласование стало быстрее на столько-то" здесь нет: время согласования до запуска никто не засекал, а доступа к рабочему порталу после передачи у нас нет. Есть другое: с 20 октября 2026 года заявки на оплату в компании идут через эту систему.

Вот как это описала финансовый консультант заказчика в отзыве:

Отдельный сервис за секунду проверяет каждую заявку по смете, авансу и остатку денег. Одобренная заявка сама попадает в платежный календарь Финтабло, а после оплаты система закрывает ее и обновляет бюджет.

Финансовый консультант заказчика

Сколько времени это заняло

Что не получилось с первого раза

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

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

Что происходит сейчас

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

Что можно перенести в другие компании

1. Привязывайте заявку к строке бюджета, а не к "объекту вообще". Тогда остаток считается сам.
2. Резервируйте деньги в момент проверки, а не после оплаты. Иначе две заявки поделят одни и те же деньги.
3. Показывайте руководителю цифры, а не только "одобрено системой". Решение принимается быстрее, если видно, почему.
4. Пишите в карточку, какие были остатки на момент решения. Через месяц это единственный способ объяснить, почему оплату одобрили.
5. Крупные суммы без договора - в ручной разбор. Автоматика не должна принимать решения, которые требуют документа.
6. Обязательные платежи - отдельным техническим объектом. Налоги и зарплата не должны застревать на лимитах.
7. Спор об объеме решайте по документам. Коммерческое предложение и техническое задание - лучший арбитр.
8. Сервер и аккаунты - на заказчика. Подрядчику достаточно временного доступа.

Частые вопросы