Почему при синхронизации ЗУП 3.1 и Бухгалтерии 3.0 не возвращается статус отражения в учете?

При настройке регулярного обмена данными между конфигурациями 1С:Зарплата и управление персоналом 3.1 и 1С:Бухгалтерия предприятия 3.0 нередко возникает ситуация: документ Отражение зарплаты в бухучете успешно переносится в бухгалтерию, там помечается флажком Отражено в учете и проводится, однако при обратной синхронизации в ЗУП статус документа не обновляется, а форма не блокируется от изменений (не становится «серой»).

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

Порядок работы и механика миграции статуса

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

1. В программе ЗУП 3.1 создается, заполняется и проводится документ Отражение зарплаты в бухучете.
2. Выполняется сеанс синхронизации данных. Документ выгружается в Бухгалтерию 3.0.
3. В Бухгалтерии 3.0 загруженный документ изначально не формирует проводок. Бухгалтер проверяет данные, устанавливает флаг Отражено в учете, выбирает ответственного в поле Зарплата отражена в учете пользователем и повторно проводит документ. В этот момент формируются проводки по счетам БУ и НУ.
4. При проведении документ в бухгалтерской базе автоматически регистрируется к обмену с планом обмена СинхронизацияДанныхЧерезУниверсальныйФормат.
5. Выполняется сеанс синхронизации из бухгалтерской базы, а затем загрузка в ЗУП. В ЗУП 3.1 заполняется реквизит ЗарплатаОтраженаВУчетеПользователем, и документ блокируется для редактирования расчетчиком.

Если на одном из этапов цепочка прерывается, статус не вернется. Рассмотрим подробнее основные технические проблемы, препятствующие обновлению статуса.

Причина 1. Несовпадение версий конфигураций и правил обмена

Наиболее распространенная техническая проблема — обновление одной из баз при сохранении устаревшего релиза второй. Формат обмена EnterpriseData и встроенные правила конвертации чувствительны к изменению состава метаданных.

Например, в одном из релизов может измениться состав объектов (таких как регистр сведений НаличиеПрисоединенныхФайлов, переименованный в НаличиеФайлов). В этом случае обработка КонвертацияОбъектовИнформационныхБаз при загрузке выдает критическую ошибку:

Тип не определен (РегистрСведенийЗапись.НаличиеПрисоединенныхФайлов)

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

Способ решения:

1. Обновим обе конфигурации до актуальных и взаимно совместимых релизов.
2. Если конфигурация доработана и типовое обновление отложено, выполним перезагрузку правил конвертации из макетов конфигураций по умолчанию.
3. Очистим серверный и клиентский кэш метаданных.

Причина 2. Ошибки в таблицах регистрации изменений и «битые» ссылки

Если документы в бухгалтерской базе удалялись напрямую или сопоставление узлов дало сбой, в таблице регистрации изменений плана обмена могут остаться неразрешенные ссылки вида <Объект не найден> (УИД). При формировании пакета выгрузки это приводит к сбоям сериализации XDTO.

Проверим регистрацию изменений:

1. В информационной базе откроем форму Администрирование — Синхронизация данных — Состав отправляемых данных (обработка РегистрацияИзмененийДляОбмена).
2. Развернем ветку документа Отражение зарплаты в бухучете.
3. Если в списке присутствуют записи <Объект не найден>, удалим их регистрацию с помощью контекстного меню или специализированной команды очистки недействительных ссылок.
4. Выполним перепроведение требуемого документа Отражение зарплаты в бухучете в Бухгалтерии, чтобы он заново корректно зарегистрировался на узле обмена, и запустим синхронизацию.

Причина 3. Настройки фильтрации и параметры синхронизации

Проанализируем параметры самого сценария обмена данными:

1. Проверим дату начала синхронизации данных в настройках подключения узла. Если дата документа раньше границы начала синхронизации, изменения по нему игнорируются планом обмена.
2. Проверим отборы по организациям: если документ оформлен по организации, исключенной из правил отправки узла, миграция данных производиться не будет.
3. Убедимся в отсутствии конфликтов версий. Откроем форму Результаты синхронизации данных и проверим вкладку Предупреждения (Конфликты). Если в настройках включен приоритет данных ЗУП при коллизиях, изменения из Бухгалтерии могут отклоняться автоматически при наличии несохраненных изменений в ЗУП.

Причина 4. Влияние даты запрета загрузки данных

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

Проверим настройки в разделе Администрирование — Настройки пользователей и прав — Даты запрета изменения (вкладка «Даты запрета загрузки») и при необходимости временно сместим границу запрета назад на период закрываемого месяца.

Порядок принудительного обновления статуса единичного документа

Если требуется восстановить статус конкретного документа без полного пересоздания настроек обмена, выполним следующие шаги:

1. В базе 1С:Бухгалтерия снимем проведение документа Отражение зарплаты в бухучете, заново установим флаг Отражено в учете, укажем пользователя и проведем его.
2. Через обработку Регистрация изменений для обмена принудительно зарегистрируем к отправке именно этот проведенный документ на узле обмена с ЗУП.
3. Выполним сеанс синхронизации в Бухгалтерии (дождемся успешного формирования файла сообщения).
4. Выполним синхронизацию в 1С:ЗУП и обновим список документов. Реквизит ЗарплатаОтраженаВУчетеПользователем заполнится, и документ успешно перейдет в статус заблокированного для правок.