Почему документы снимаются с проведения после синхронизации 1С:УТ и 1С:БП и как это исправить

В процессе работы со связкой конфигураций «1С:Управление торговлей 11» и «1С:Бухгалтерия предприятия 3.0» специалисты часто сталкиваются с неприятной ситуацией: документы, успешно проведенные в одной или обеих базах, после очередного сеанса синхронизации становятся непроведенными. Особенно это критично для документа Приобретение товаров и услуг, так как от него зависит корректность формирования затрат и записей по НДС. Рассмотрим подробно причины этого поведения и разберем пошаговый алгоритм решения проблемы.

Анализ первопричины: поиск «виновника» в журнале регистрации

Прежде всего, нам необходимо понять, что документ не «слетает» с проведения сам по себе. Это всегда результат действия либо пользователя, либо программного кода (регламентного задания). Проанализируем ситуацию с помощью системных инструментов. Первым делом мы должны обратиться к Журналу регистрации в информационной базе, где документ стал непроведенным.

В Журнале регистрации следует установить отбор по метаданным (конкретный документ) и событию «Данные. Изменение». Если снятие с проведения произошло в момент обмена, в колонке «Пользователь» вы увидите имя учетной записи, под которой настроен запуск синхронизации (например, ОбменСУТ). Это будет прямым доказательством того, что «пустая» или измененная версия документа пришла из источника и перезаписала текущие данные. Для удобства анализа подобных инцидентов можно использовать выгрузку журнала регистрации в Excel — для этого подойдёт регистрация недостающих документов в БП после обмена.

Работа с предупреждениями синхронизации данных

Часто ответ лежит на поверхности, в стандартном интерфейсе обмена. Разберем по шагам, где искать подсказки:

1. Перейдем в раздел Администрирование — Синхронизация данных.
2. Откроем ссылку Предупреждения при синхронизации данных.
3. Проанализируем вкладку «Ошибки проведения». Если документ Приобретение товаров и услуг загрузился, но не смог провестись, система зафиксирует здесь конкретную причину (например, «Не заполнен счет учета» или «Не указана статья прочих доходов и расходов»).
4. Особое внимание уделим вкладке «Конфликты». Именно здесь фиксируется ошибка «Данные были одновременно изменены в этой и другой программе».

Механизм разрешения коллизий (версионность данных)

Выясним причину возникновения конфликтов. Механизм синхронизации через универсальный формат (Enterprise Data) использует поле ВерсияДанных. Проанализируем ситуацию: если после последней выгрузки бухгалтер изменил документ в БП (например, уточнил счета), а менеджер в УТ в это же время перевыбрал склад или подразделение, система при следующем обмене увидит, что объект изменился в обеих базах. Это и называется коллизией.

По умолчанию система может быть настроена на автоматическое разрешение коллизий в пользу одной из баз (обычно УТ считается приоритетной). Если в УТ документ по какой-то причине не проведен, он придет в БП и снимет проведение там, так как его версия будет признана «эталонной».

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

Взаимозависимость со «Списанием безналичных денежных средств»

Рассмотрим подробнее ситуацию, когда Приобретение товаров и услуг связано с платежными документами. Часто в 1С:БП настроена автоматическая загрузка из Директ-Банка. Это приводит к следующей цепочке событий:

1. Банк загружает Списание безналичных денежных средств напрямую в БП.
2. В УТ этот же платеж создается вручную или загружается позже.
3. При синхронизации система пытается сопоставить эти документы. Если в БП платеж уже проведен и привязан к приобретению, а из УТ приходит «своя» версия платежа, возникает перекрестная ссылка.
4. В результате обновления связанных цепочек Приобретение товаров и услуг может быть переоткрыто для записи и потерять статус проведения, если синхронизация споткнется на блокировке одного из объектов.

Проверка аналитики и фонового проведения

Выясним еще одну важную техническую причину. В 1С:БП для успешного проведения Приобретения требуются заполненные счета учета (60.01, 60.02) и счета учета НДС (19.03). Важно также помнить, что сам формат обмена может требовать доработок (см. готовые правила синхронизации через EnterpriseData без доработок), например, при синхронизации данных для новых ставок НДС. В 1С:УТ этих данных в явном виде может не быть (там используются Группы финансового учета — ГФУ). Если правила сопоставления настроены некорректно, документ в БП загружается с пустыми счетами.

Программа при загрузке всегда пытается выполнить фоновое проведение. Если счета не заполнены, метод Записать(РежимЗаписиДокумента.Проведение) вернет отказ, и документ останется в статусе «Записан». Бухгалтер проводит его вручную, заполняя счета, но при следующем обмене из УТ снова прилетает объект без счетов (или с отличными данными), и ситуация повторяется.

Использование обработки «Регистрация изменений для обмена»

Если проблема сохраняется и документ продолжает сниматься с проведения без видимых причин в журнале, проанализируем план обмена. Рассмотрим использование стандартной обработки «Регистрация изменений для обмена данными» (поможет универсальная регистрация объектов в планах обмена 1С) или универсальных инструментов, позволяющих выполнить регистрацию объектов для обмена по организации:

1. Найдем узел обмена с УТ.
2. В дереве объектов найдем Приобретение товаров и услуг.
3. Проверим, не зарегистрирован ли проблемный документ на выгрузку.
4. Если мы уверены, что в БП данные верны, мы можем принудительно снять документ с регистрации в обеих базах. Это разорвет «порочный круг» постоянной перезаписи объекта при каждом сеансе связи. Более гибким решением может стать доработка, позволяющая выполнять выборочный перенос документов из УТ, просто устанавливая для них специальный флаг запрета выгрузки.

Техническое решение: принудительное заполнение реквизитов

Для программиста решением может стать вмешательство в логику сопоставления. Если мы видим, что счета учета не подтягиваются автоматически, можно использовать расширение и в процедурах обработки загрузки (в модуле менеджера или в правилах обработки данных XDTO) прописать заполнение по умолчанию. Посмотрим на логику, которую можно реализовать:

// Пример логики в обработчике загрузки (псевдокод)
Если Объект.СчетУчетаРасчетовСПоставщиком.Пустой() Тогда
    Объект.СчетУчетаРасчетовСПоставщиком = ПланыСчетов.Хозрасчетный.РасчетыСПоставщиками;
КонецЕсли;

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

Рекомендации по настройке даты запрета

Чтобы избежать «шевеления» старых документов, проанализируем настройки Даты запрета изменения данных. Крайне важно, чтобы в обеих базах (УТ и БП) дата запрета была установлена одинаково. Если в УТ дата запрета позволяет менять документы «задним числом» (например, при восстановлении последовательности или закрытии месяца), а в БП период уже закрыт, обмен будет постоянно выдавать ошибки. Если же в БП дата запрета не стоит, то любое случайное перепроведение старого документа в УТ приведет к тому, что он прилетит в БП и снимет проведение с уже выверенного периода.

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