Как промышленная компания взяла под контроль расхождения между 1С:ERP и 1С:Бухгалтерией

Клиент и задача

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

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

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

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

Почему расхождения было трудно расследовать

Для бизнеса разные технические причины выглядели одинаково:
«ERP и Бухгалтерия не сходятся».

За этой формулировкой могли скрываться совершенно разные сценарии.

Документ изменили в ERP, изменение дошло до БП, но новая версия не записалась из-за запрета изменения закрытого периода.

После обновления одной из систем отдельный реквизит перестал корректно синхронизироваться.

Документ успешно передался, а затем бухгалтер изменил его непосредственно в БП. В ERP сохранилась предыдущая версия.

В распределённом контуре документ мог отсутствовать в центральной базе, и сначала требовалось определить, из какого источника он вообще должен был прийти.

Поэтому общего статуса обмена было недостаточно.

Команде требовалась история конкретного объекта:
что было в ERP → зарегистрировалось ли изменение → что выгрузили → что получил приёмник → выполнилась ли запись → почему итоговые состояния отличаются.

Один документ: как выглядело расхождение

Например, реализация присутствует в обеих системах. GUID, организация, контрагент, договор, номер и дата совпадают.

Но значения отличаются:


Раньше с этой разницы только начиналось расследование.

После внедрения специалист видел хронологию:



Ключевой принцип проекта сформулировали очень просто: «Дошло» ещё не означает «записалось».

Какую задачу поставили перед новым контуром

Команда отказалась от идеи ещё одной сверки итоговых сумм в Excel или BI.

Такая сверка обнаруживает:
1 284 600 ≠ 1 246 200 но не объясняет, где разошёлся путь документа.

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

Базовая архитектура получилась такой:



DVT подключали только в сценариях, где требовались дополнительные преобразования:



То есть DVT не стал обязательным звеном.
Если структуры можно было сопоставить напрямую, архитектуру не усложняли.

Начали с трёх типов документов

Пилот ограничили тремя классами операций:

1. Реализация товаров и услуг.

2. Поступление товаров и услуг.

3. Возврат от клиента.

Для каждого типа определили контрольные поля:
GUID, организацию, контрагента, договор, дату, номер, сумму, НДС, валюту и статус проведения.

После этого объект получал понятное состояние:
совпадает / нет в БП / отличаются реквизиты / ошибка записи / требуется разбор.

Это изменило сам подход к расследованию.
Вместо: «У нас не сходится период» команда получала список конкретных документов с конкретной причиной.

Отдельно определили источник истины

Сам факт расхождения ещё не говорит, какую систему нужно исправлять.

Например, для суммы реализации источником истины может быть ERP, а часть бухгалтерской аналитики принадлежать БП.

Поэтому для критичных объектов и полей зафиксировали правила владения данными.

Это особенно важно для ручных корректировок. Если бухгалтер изменил документ только в БП, алгоритм может обнаружить различие, но не должен автоматически решить, что значение ERP «правильное».

Процесс разделили на два шага:
диагностика → согласованное исправление.

Автоматической перезаписи одной базы значениями другой не делали.

Что дали Экстрактор и Инжектор

Экстрактор стал контрольной точкой источника.
Команда могла видеть, существовал ли объект в ERP и какое состояние было получено при выгрузке.

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

Вместо цепочки из нескольких специалистов расследование стало выглядеть так:
расхождение → объект → ERP → выгрузка → БП → причина → действие.



Дополнительные специалисты подключались только к исключениям.

После пилота контроль расширили

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

Одновременно в единый процесс контроля вошли 12 информационных баз и поток более 78 000 документов и изменений в месяц.

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

Результаты

После стабилизации решения компания сравнила показатели до и после. Значения публичной версии обезличены и синтетически нормализованы.



Главное изменение произошло во времени диагностики.

Раньше специалист сначала искал контекст: где документ, передавался ли он, кто его менял, что произошло на стороне приёмника.

После проекта большая часть этой информации уже была связана с объектом.

Среднее время локализации причины сократилось с 68 до 9 минут.

Ручная сверка снизилась с 52 до 11 часов в месяц, а количество объектов, требующих ручного разбора, – с 312 до 49.

Что изменилось для команды

До проекта типичный инцидент звучал так:
«ERP и Бухгалтерия опять не сходятся».

После:
«Реализация № РТ-18427 дошла до БП, но новая версия не записалась из-за даты запрета изменения».

Раньше:
«Где-то потерялся документ».

После:
«В источнике объект найден, изменение зарегистрировано и выгружено, в приёмнике объекта нет».

Так компания получила воспроизводимый способ разбирать частичные расхождения, которые общий статус обмена не показывает.

Общая фактура решения

Почему не отказались от стандартных механизмов 1С

Задачей проекта не было заменить типовой обмен ради самой замены.

Штатные механизмы продолжили выполнять свои функции.

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

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

Итог

Интеграцию проще контролировать, когда она ломается полностью. Гораздо сложнее найти проблему, если 99% потока проходит штатно, а несколько документов живут в ERP и Бухгалтерии в разных состояниях.

Для таких случаев недостаточно знать, что обмен «успешно завершён».

Нужно видеть путь объекта:
источник → изменение → выгрузка → приёмник → запись → причина.

Связка Экстрактора данных 1С, промежуточного слоя и Инжектора 1С дала компании этот уровень контроля.

В результате сверка ERP и Бухгалтерии превратилась из ручного расследования в управляемый процесс:
объект → этап → причина → действие.