Синхронизация данных между конфигурациями «1С:Зарплата и Управление Персоналом» (ЗУП) и «1С:Бухгалтерия предприятия» (БП) — это критически важный процесс для корректного ведения учета. Долгое время стандартом был обмен через правила конвертации (обмен по правилам обмена — XML), однако современный стандарт 1С подразумевает использование универсального формата EnterpriseData (ED). В этой статье мы подробно разберем, как правильно осуществить переход на этот формат, с какими подводными камнями можно столкнуться и как решить проблему появления битых ссылок («Объект не найден»).
Прежде чем мы перейдем к технической реализации, давайте разберемся в сути изменений. В старом формате обмен строился на жестких правилах конвертации (файлы правил XML), которые описывали трансформацию каждого реквизита объекта источника в реквизит приемника. Это часто вызывало ошибки при обновлении релизов, когда метаданные менялись, а правила устаревали.
Формат EnterpriseData работает иначе. Это универсальный стандарт, не зависящий от внутренней структуры конкретной базы. ЗУП выгружает данные в «нейтральном» виде, а БП сама «знает», как разложить этот пакет по своим регистрам. Основные преимущества:
Многие пользователи ошибочно полагают, что переключение на новый формат происходит путем установки некой «галочки» в настройках. Это не так. Как справедливо замечено в обсуждении, изменить формат существующей настройки «на лету» невозможно. Механизмы транспорта и сериализации данных слишком разные. Перед началом работ рекомендуется провести аудит текущего состояния данных; для этого отлично подойдет простая сверка документов между конфигурациями через http-сервис.
Для корректного перехода нам необходимо выполнить следующие действия:
Нельзя держать две активные настройки обмена между одними и теми же узлами, это приведет к дублированию данных и коллизиям. Старую настройку синхронизации необходимо пометить на удаление и удалить (либо просто отключить регламентные задания и переименовать её в «НЕ ИСПОЛЬЗОВАТЬ», если вы хотите сохранить историю, но лучше удалить настройку полностью, чтобы очистить таблицы регистрации изменений).
После удаления старой настройки мы приступаем к созданию новой. Рассмотрим этот процесс по шагам:
Важный нюанс: При настройке обязательно обратите внимание на префиксы баз. Они должны совпадать с тем, что было раньше, чтобы документы не начали нумероваться заново с другим префиксом.
Это самый ответственный момент, о котором часто забывают. При первом обмене система попытается сопоставить объекты (Организации, Сотрудников, Физических лиц, Подразделения) между двумя базами.
Давайте проанализируем, почему это важно. В старом обмене сопоставление могло идти по полям поиска (ИНН, КПП, Наименование). В EnterpriseData приоритет отдается уникальным идентификаторам (UID). Если автоматическое сопоставление пройдет некорректно, вы получите:
Рекомендация: При первом запуске синхронизации выберите режим с остановкой для настройки сопоставления. В окне помощника вручную проверьте, что «ЗУП: Иванов» сопоставлен с «БП: Иванов». Если система не нашла пару, укажите её вручную.
В теме поднимался вопрос о том, что при переходе на новый формат сотрудники в удержанной зарплате приходят как <Объект не найден>. Давайте разберем причины и методы устранения этой ошибки.
Ошибка возникает из-за нарушения ссылочной целостности или разницы в идентификации объектов. В старом формате сотрудник мог быть идентифицирован по набору полей (ФИО + Дата рождения и т.д.), а новый формат жестко требует соответствия UID или корректного прохождения процедуры сопоставления (см. Этап 3).
Если в базе БП сотрудник был создан вручную или пришел по старому обмену с UID, отличным от того, который генерирует ED, то при выгрузке документа «Отражение зарплаты» в поле «Сотрудник» прилетит ссылка на объект, который БП «не узнает».
Если вы столкнулись с «битыми» ссылками на сотрудников или физических лиц, выполните следующие действия:
Способ 1. Принудительная перевыгрузка справочников.
Нам нужно заставить ЗУП заново отправить информацию о сотрудниках, чтобы БП могла их «узнать» или создать корректно. Для этого может быть использована как стандартная обработка, так и более удобная универсальная регистрация объектов для обмена по организации.
Сотрудники и ФизическиеЛица.Способ 2. Настройка состава отправляемых данных.
В настройках синхронизации (в самом узле) проверьте настройки выгрузки. Иногда помогает временное переключение тумблера выгрузки сотрудников. Если стоит «Только используемые в документах», попробуйте временно включить полную выгрузку, чтобы синхронизировать справочную массу.
При переходе важно понимать, что логика документа ОтражениеЗарплатыВБухучете изменилась. Рассмотрим ключевые отличия:
Еще один критический момент, который мы обязаны рассмотреть. При смене формата обмена существует риск, что старые документы (прошлых лет) будут перевыгружены и изменены. Это может привести к «поплывшему» балансу в закрытых периодах. В случае если данные всё же были искажены, вам может потребоваться редактирование движений в регистрах документа «Перенос данных» для точечного исправления значений.
Чтобы этого избежать, выполните настройку дат запрета:
Это гарантирует, что даже если ЗУП попытается отправить старые документы в новом формате, БП их проигнорирует, и ваша отчетность останется в безопасности.
Переход на EnterpriseData — это правильный шаг для стабилизации обмена, но он требует аккуратности. Давайте подведем итог:
<Объект не найден>, используйте обработку Регистрация изменений для обмена данными для принудительной регистрации справочников.