Введение
Крупный хостинг-провайдер вёл учёт денежных операций в 1С:Управление нашей фирмой (УНФ), а первичные данные о движении средств формировались во внешней биллинговой платформе. Между биллингом и 1С не было никакой интеграции — каждую операцию бухгалтерия вносила и разносила вручную, что занимало время и повышало риск ошибок.
Специалисты ООО «ММ7» спроектировали и внедрили двухуровневый механизм: интеграционное расширение принимает выписку по HTTP и создаёт документы, а расширение «Обработка выписки» автоматически заполняет реквизиты и проводит документы по правилам, настроенным в учётной системе.
С какой проблемой столкнулись клиенты?
На момент начала работы над проектом у заказчика существовали следующие трудности:- Операции из биллинга вообще не попадали в 1С — не было ни автоматической загрузки, ни готового обмена; каждую выписку и каждую транзакцию вносили вручную;
- При ручном вводе один и тот же платёж мог быть учтён дважды — контроля дублей не было;
- Нельзя было проверить, все ли операции из выписки отражены в учёте — сверка выполнялась вручную.
Какие результаты после внедрения?
По итогам внедрения механизма заказчик получил:
Для бухгалтерии и учёта
- Впервые организован автоматический приём кассовых операций из биллинга: выписка передаётся по HTTP и разносится в документы УНФ без ручного ввода и промежуточных файлов;
- Сокращено время отражения платежа в учёте — после приёма XML создаются и проводятся кассовые документы (поступление, расход, перемещение ДС) по настроенным правилам;
- Снижен риск ошибок при сопоставлении организаций, касс, контрагентов и статей: внешние идентификаторы хранятся в едином регистре соответствий;
- Защита от двойного учёта одной транзакции — повторная загрузка фиксируется как дубликат и не создаёт второй документ.
Для биллинговой системы и ИТ
- Прозрачный обмен со статусами: внешняя система запрашивает GetStatus и получает completed, partial_error, processing и сводку по каждой транзакции;
- Обратная связь при ошибках без ручных уточнений: в ответе доступны summary (успешно / ошибки / дубликаты) и errors_detail с описанием причины;
- Полный журнал обработки в регистре БС_Логирование с привязкой к statement_id и transaction_id — удобно для разбора инцидентов и аудита.
Для сопровождения и развития
- Гибкая настройка разнесения через регистр правил обработки выписки — изменение логики заполнения и проведения без доработки HTTP-сервиса;
- Разделение ответственности в архитектуре: транспорт и интеграция (HTTP, XML, маппинг) отделены от учётной логики (правила, алгоритмы) — проще сопровождать при изменении форматов биллинга или регламентов.
| Было | Стало |
|---|---|
| Нет интеграции с биллингом — полностью ручной ввод операций в 1С | Автоматическая передача XML по API |
| При ручном вводе один платёж мог быть учтён дважды | Контроль дублей на уровне транзакции |
| Нельзя было автоматически сверить выписку с учётом | Статус выписки и сводка по каждой транзакции |
| Разнесение по внутреннему регламенту, без единых правил в системе | Настройка правил в учётной системе |
Этапы работы
- Обследование формата XML-выписок и целевых документов УНФ
- Проектирование HTTP-сервиса и регистров статусов, логов, сопоставлений
- Согласование сценариев: поступление, расход, перемещение ДС
Рис. 1 — Публикация HTTP-сервиса с методами UploadStatement и GetStatus
- HTTP-сервис: методы UploadStatement (POST, XML) и GetStatus (GET, JSON)
- Доступ защищён HTTP Basic Authentication на уровне публикации веб-сервисов 1С
Рис. 2 — Приём XML-выписки и ответ accepted
Рис. 3 — Запрос статуса обработки и сводка summary
Рис. 4 — Регистр статусов: completed, partial_error, processing
Рис. 5 — Сопоставление внешних ID с объектами 1С
Рис. 6 — Связь внешнего ID транзакции с документом 1С
Каждая операция фиксируется в регистре БС_Логирование с типом события (INFO, SUCCESS, WARNING, ERROR), привязкой к statement_id и transaction_id. Сводка и детализация ошибок отдаются наружу через GetStatus → summary и errors_detail.
Рис. 7 — Журнал событий обработки выписки
Рис. 8 — Обратная связь при ошибке
Рис. 9 — Фиксация дубликата в summary
Рис. 10 — Документ, созданный автоматически из выписки
Рис. 11 — Настраиваемые правила разнесения без изменения кода
Результат
Сформирован сквозной механизм обмена кассовыми выписками, который:- Принимает XML по HTTP, валидирует структуру и ведёт статусы обработки;
- Сопоставляет внешние идентификаторы с данными УНФ и создаёт кассовые документы нужного вида;
- Применяет настраиваемые правила заполнения и проведения;
- Фиксирует каждый шаг в логе и отдаёт сводку и ошибки по запросу GetStatus.
Архитектура разделяет транспорт и интеграцию (HTTP, XML, маппинг, дубли) и учётную логику (правила, алгоритмы, проведение) — это упрощает сопровождение при изменении форматов биллинга или регламентов учёта.
Статья подготовлена на основе анализа реализованного кода расширений. Все наименования компаний, учётные данные и идентификаторы на скриншотах обезличены.
