Как мы автоматизировали бухгалтерский учёт для финтех-компании и сделали интеграцию с 1С, которая не ломается при каждом обновлении API

Внешний сервис клиента постоянно менялся — вместе с ним ломалась загрузка данных в 1С. Каждое изменение API, каждая новая комиссия или новая аналитика означали доработку конфигурации, тестирование и деплой. Мы перепроектировали архитектуру интеграции: разделили обработку на независимые шаги, вынесли бизнес-правила из кода в настраиваемый движок и подключили Enterprise Data. Результат — система работает полтора года без доработок, только плановые обновления базы.

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

Мы работаем с этим клиентом с 2018 года. Начинали с базовой 1С: Бухгалтерии и внешних обработок для обмена данными с сервисом. Со временем система росла вместе с клиентом: базовая бухгалтерия сменилась на ПРОФ, обработки переехали в код конфигурации. Потом произошло слияние — клиента приобрела другая компания с аналогичным бизнесом, и мы объединили загрузку данных из обоих сервисов в одну 1С.

Всё это время сервис клиента активно развивался: менялись адреса методов API, способы авторизации, структура данных. Сервис обслуживал много внешних потребителей, и не всегда удавалось заранее синхронизировать изменения со всеми — мы нередко узнавали о них уже по факту. Адаптировали загрузку под каждое изменение, но с каждым разом это давалось всё сложнее.

В какой-то момент клиент перешёл на очередную версию API, и мы решили не просто адаптировать старый код, а переработать архитектуру целиком — чтобы не усугублять накопившиеся проблемы.

Какие именно проблемы?

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

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

Данные терялись при неудачной загрузке. Старый API работал так: 1С запрашивает заявки, сервис отдаёт данные и сразу меняет статус на «Выгружен в 1С» — ещё до того, как 1С подтвердит успешную загрузку. Если загрузка не удалась — заявка уже помечена как выгруженная, повторно запросить её нельзя. Статус приходилось откатывать вручную.

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

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

Техническая суть: перепроектировать архитектуру интеграции: перейти на новые методы API, реализовать пошаговую обработку с промежуточным хранением данных, вынести бизнес-правила из кода конфигурации в настраиваемые правила, использовать Enterprise Data для записи прикладных объектов.

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

Ключевая идея: разбить единую цепочку «получить → обработать → записать» на независимые шаги с сохранением промежуточных результатов. Если что-то ломается на третьем шаге — первые два повторять не нужно.

Заодно решили проблему с потерей заявок. В новом API загрузка данных и смена статуса — это два отдельных запроса. Теперь если загрузка в 1С не удалась, заявка остаётся в исходном статусе на стороне сервиса и приходит повторно.

Разработку вели в Enterprise Development Tools (EDT) со строгой типизацией. Это требует больше усилий, но даёт более качественный и поддерживаемый результат.

Мы создали документ Объект данных API, куда сохраняется сырой JSON из сервиса без какой-либо обработки. К документу подключили встроенное версионирование — можно посмотреть историю изменений. Данные всегда можно обработать повторно, не обращаясь к внешней системе.

Мы отказались от фиксированных реквизитов, привязанных к полям JSON — структура данных на стороне сервиса менялась слишком часто. Вместо этого входящий JSON разбирается в универсальную таблицу «ключ — значение». Новые поля подхватываются автоматически, не ломая загрузку — система сама добавляет их в классификатор. Теперь, даже если поле не нужно сейчас, оно хотя бы уже хранится в 1С.

Данные из таблицы «ключ — значение» нужно привести к виду, пригодному для формирования бухгалтерских документов. Раньше вся эта логика жила в коде конфигурации, и каждое изменение требовало доработки, тестирования и обновления базы у клиента.

Мы вынесли правила вычислений в отдельный механизм. По сути, создали мини-IDE внутри 1С — среду, где разработчик может писать правила на встроенном языке, подбирать доступные реквизиты из дерева свойств объекта API, проверять результат и отлаживать на сохранённых данных. Сами вычисления в каждом правиле простые — арифметика, подстановка значений, проверка условий. Но теперь при изменении бизнес-логики достаточно зайти в правило, поправить его и перезаписать заявку — она обработается автоматически. Не нужно менять конфигурацию и делать деплой.

Сейчас в системе более 400 правил для заполнения документов и справочников. Среднее правило — 3−5 строк кода. Например, правило Creditor_Product выглядит так: проверить, заполнено ли поле api/offerRequestInfo/lenderProductName, и если да — записать его значение в результат. Четыре строки. Правило расчёта комиссии чуть сложнее: взять сумму из одного поля, коэффициент из другого, перемножить. Пять строк. За счёт такого размера правила легко читать, отлаживать и менять — даже спустя год.

Вместо прямых манипуляций с прикладными объектами 1С — контрагентами, договорами, банковскими счетами — мы выбрали загрузку через бэкенд Enterprise Data.

Это стандартный механизм обмена данными от фирмы «1С». Он предоставляет универсальный формат для загрузки прикладных объектов, и 1С гарантирует его обратную совместимость между обновлениями конфигурации. Проще говоря, если мы загружаем данные через Enterprise Data, то при обновлении конфигурации 1С сама обеспечивает совместимость с новой структурой данных.

Почему это важно:

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

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

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

Для сравнения: в старом коде логика обработки одного поля могла быть размазана по нескольким сотням строк вперемешку с запросами к API. В новой системе то же самое — это правило на 3−5 строк с исходным полем, полем-получателем и простой логикой между ними. На весь перенос ушло около двух недель.

Стабильная работа без доработок. Полтора года система работает в штатном режиме — мы только обновляем базу. Обращений стало заметно меньше.

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

Устойчивость к изменениям API. Новое поле в JSON не ломает загрузку, а автоматически попадает в систему. Когда оно понадобится — для него пишется правило.

Защита от потери данных. Входящие данные сохраняются «как есть» и могут быть обработаны повторно в любой момент.

Прозрачная диагностика ошибок. Журнал показывает, какое именно правило на каком документе не сработало и почему. Не нужно лезть в отладку — причина видна сразу.

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

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

По текущему прайсу стоимость такой проект будет стоить от 4 000 000 рублей. Срок от 6 месяцев.

Сталкиваетесь с похожими задачами в интеграции 1С с внешними системами? Давайте обсудим, как мы можем помочь.⬇️