Сверка данных между 1С:ERP и 1С:Бухгалтерией

В 1С:ERP продаж проведено на 5 000 000 рублей. После синхронизации в 1С:Бухгалтерии по тому же периоду отражено 4 800 000: 200 тысяч рублей потеряно в учете. 
И бухгалтер вынужден делать сверку данных вручную между двумя системами, пытаясь выявить те документы, которые не перенеслись с обменом из одной 1С в другую. 
Проблема не в разнице как таковой. Проблема в том, что пока неясно, какие именно документы не дошли, где изменились реквизиты и какая база содержит корректное состояние операции. 

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

Поэтому сверка ERP и Бухгалтерии - не поиск одной «неправильной цифры». В сложном ERP-контуре нужно восстановить весь путь хозяйственной операции: 



И только после этого исправлять причину.

Почему ERP-контур сложнее и дороже в сопровождении 

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

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

Поэтому такой интеграционный проект обычно дороже не из-за «ненадежности ERP», а из-за масштаба контура. Ошибка в одном реквизите может затронуть цепочку связанных объектов и проявиться уже на закрытии периода, в себестоимости, взаиморасчетах или регламентированной отчетности. 

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

Почему данные между ERP и Бухгалтерией расходятся 

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

Документ не попал в обмен 

Документ есть в ERP, но по каким-то причинам не был зарегистрирован или обработан при очередной синхронизации. 
Тогда в источнике операция существует, а в Бухгалтерии ее нет. 

Первый вопрос при диагностике: Документ вообще был зарегистрирован к передаче? 
Если нет, искать ошибку в базе-приемнике рано. 

Синхронизация завершилась с ошибкой 

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

Изменились структуры или правила сопоставления 

Совместное использование 1С:ERP 2.5 и 1С:Бухгалтерии 3.0 поддерживается 1С. Для такого контура предусмотрены правила синхронизации, выборочная выгрузка, таблицы соответствия объектов и отдельные ограничения обмена. 

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

Поэтому при ERP ↔ БП недостаточно проверить только факт передачи документа. Нужно проверять, как сопоставились связанные справочники, аналитики и реквизиты и что именно появилось в приемнике. 

В одной из баз документ исправили вручную, а регистрации к обмену не произошло 

Например, документ сначала пришел из ERP в БП, а затем бухгалтер изменил сумму, контрагента или аналитику непосредственно в Бухгалтерии. 

С этого момента базы содержат две версии одного события. 
Технический обмен здесь может работать совершенно исправно. 
Расходится уже бизнес-состояние данных. 
Поэтому для интеграции нужно заранее определить: какая система является источником истины для каждого типа объекта? 

Сработала дата запрета изменения 

В конфигурациях 1С существует механизм запрета изменения данных закрытого периода. Он применяется в ERP, КА и других решениях. 

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

Поэтому закрытый период действительно может стать причиной отказа записи. 

Но правильная реакция - не автоматически «открыть месяц», а сначала понять: 

• какой объект меняется; 
• почему изменение пришло задним числом; 
• допустимо ли изменение с точки зрения учетной политики; 
• после согласования выполнить повторную загрузку.

Почему стоимость ошибки в ERP выше 

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

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

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

Чем расхождения опасны для бизнеса 

Самая очевидная проблема - некорректная отчетность. 
Но последствия шире. 

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

Коммерческий отдел смотрит одну сумму продаж. Бухгалтерия - другую. 
Возникают ручные сверки, Excel-файлы и обсуждения: «У кого правильная цифра?» 
Если проблема затрагивает НДС, ФНС может обнаружить противоречия между декларацией и данными по операциям или данными контрагента. Это может привести к автотребованию от Налоговой о пояснениях в рамках камеральной проверки. 
Поэтому ключевая задача - не просто периодически «поправлять цифры», а сделать сбой (ошибки в обмене) наблюдаемыми.

С чего начать сверку ERP и БП 

Я бы не начинал с повторной отправки всех документов. Сначала нужно локализовать расхождение. Возьмите конкретный период и конкретный тип объекта, например: 

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

Дальше проверяйте последовательно: 

• есть ли документ в ERP; 
• должен ли он передаваться по текущим правилам; 
• зарегистрировано ли его изменение; 
• был ли объект отправлен; 
• чем завершилась обработка в БП; 
• создан ли соответствующий документ; 
• совпадают ли критичные реквизиты; 
• проведен ли документ; 
• не изменялся ли он затем вручную. 

Этот маршрут гораздо эффективнее вопроса: «Почему опять не сходится бухгалтерия?» 

Зачем отдельная Бухгалтерия, если 1С:ERP умеет вести регламентированный учет 

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

Нужно ли заменять типовую синхронизацию

Не обязательно. 

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

• конфигурации поддерживают нужный сценарий; 
• устраивает состав передаваемых объектов; 
• правила обмена соответствуют бизнес-процессу; 
• хватает штатной диагностики; 
• нестандартных преобразований немного. 

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

Когда нужен управляемый контур Экстрактор 1С + Инжектор 1С 

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

Тогда архитектура становится другой: 



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

Что делает Экстрактор 1С в такой схеме 

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

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

При этом реальная нагрузка и частота обмена зависят от объема, конфигурации и инфраструктуры, поэтому обещать «нулевую нагрузку» некорректно. 

Что делает Инжектор 1С 

Инжектор получает данные из PostgreSQL, MS SQL, ClickHouse или Kafka, преобразует их и записывает в объекты 1С. 
Для типовых сценариев предусмотрена low-code настройка. 

При загрузке можно: 

• найти существующий объект; 
• обновить его; 
• создать новый; 
• работать с связанными объектами и табличными частями; 
• выполнить постобработку; 
• запускать загрузки автоматически. 

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

Можно ли сравнить две базы до записи 

Да, и здесь есть собственная практика Денвик Аналитики: 

• Для сопоставления использовали “отчетный режим” Инжектора 1С: запросы из двух баз сопоставлялись и проверялись на различия без непосредственной записи объектов, после чего несопоставленные элементы можно было дополнить идентификаторами.Так был построен управляемый обмен через промежуточную СУБД. 
• Для сценария ERP ↔ БП принцип тот же: сначала сравнить и понять различие, затем принимать решение о записи. Это безопаснее, чем автоматически переписывать данные в базе-приемнике. 

Когда нужен Трансформер (ETL) 

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

Например: 
ERP -> Экстрактор -> DVT -> PostgreSQL / ClickHouse -> Инжектор -> БП 

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

Что делать с потерянным документом 

Термин «потерянный» лучше разложить на конкретный статус. 

Документ может: 

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

Для каждого сценария требуется свое действие. 

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

А если используется Kafka (как промежуточный слой выгрузки из 1С в Базу данных) 

Kafka можно использовать как транспорт между компонентами интеграции. Что важно - Инжектор 1С от Денвик поддерживает чтение данных из Kafka. 
Apache Kafka - как промежуточный слой полезен, если источник и приемник работают с разной скоростью или обмен нельзя жестко связывать по времени, а также если из 1С идет большой поток данных. 

Но сама Kafka не отменяет

• необходимость: 
• идемпотентной записи; 
• контроля повторов; 
• статусов; 
• обработки ошибок; 
• retry logic. 
  
  

Надежность создается архитектурой целиком. 

Как внедрить сверку данных и синхронизацию этих данных между базами 1С 

Для пилота я бы взял один документ или один справочник. И отследил бы весь путь этого документа между всеми системами. 

К примеру: 

Шаг 1. Определить source of truth (Источник истины) 

Решить, какая база 1С отвечает за исходные данные документа и какие поля бухгалтер имеет право изменять самостоятельно. 

Шаг 2. Выделить поля для контроля 

Например: 

• организация; 
• контрагент; 
• договор; 
• дата; 
• номер; 
• сумма; 
• НДС; 
• валюта; 
• GUID / идентификатор соответствия. 

Шаг 3. Снять baseline 

До автоматизации зафиксировать: 

• число расхождений за месяц; 
• число документов, не дошедших до БП;
• время ручной сверки; 
• число повторных исправлений. 
  
  

Без baseline невозможно честно посчитать эффект. 

Шаг 4. Настроить получение данных 

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

Шаг 5. Настроить сопоставление 

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

Шаг 6. Выполнить dry-run сверку 

До записи сравнить источник и приемник и получить список: совпало / отсутствует / отличается. 

Шаг 7. Настроить загрузку 

Инжектор создает или обновляет объекты в БП по согласованным правилам. 

Шаг 8. Контролировать историю 

Для каждой загрузки должен быть понятен результат: 
успешно / ошибка / пропущено / требуется разбор. 

Как измерять эффект после внедрения 

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

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

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

Пример промышленного интеграционного контура 

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

Подробное описание кейса 
https://denvic.tech/case/kak-krupnaya-logisticheskaya-kompaniya-vosstanovila-obmen-dannymi-mezhdu-wm... 

Данный клиент использует связку: WMS ↔ 1С, где обмен обрабатывает десятки тысяч строк данных ежедневно, а Инжектор 1С - использован как управляемый low-code слой загрузки с валидацией и логированием. 

Это подтверждает применимость архитектуры на промышленном объеме, но не является прямым доказательством эффекта именно для ERP ↔ БП.

Что выбрать: штатную синхронизацию или Экстрактор + Инжектор

Главный критерий - не «типовой обмен плохой или хороший». 
Вопрос другой: хватает ли его возможностей для конкретной архитектуры и требований к контролю?