← На главную

При настройке синхронизации между конфигурациями «Зарплата и управление персоналом, ред. 3.1» (ЗУП) и «Бухгалтерия предприятия, ред. 3.0» (БП) пользователи часто сталкиваются с ситуацией, когда справочник ФизическиеЛица не мигрирует в бухгалтерскую базу. Вы регистрируете объекты к обмену вручную, запускаете синхронизацию, она проходит без ошибок, но новые элементы в справочнике БП так и не появляются. Разберем детально, почему так происходит и как добиться корректного переноса данных.

Выясняем причину: логика формата EnterpriseData

Для начала проанализируем, как работает типовой механизм обмена. В современных версиях 1С используется формат EnterpriseData. В этом формате физические лица не рассматриваются системой как «самостоятельные» объекты, которые должны копироваться просто по факту своего существования. Их перенос жестко привязан к документам, в которых они задействованы.

Основным «транспортом» для данных о сотрудниках является документ ОтражениеЗарплатыВБухучете. Рассмотрим, как настройки этого документа влияют на состав выгрузки:

1. Сводный учет: Если в настройках синхронизации или в параметрах учета 1С:Бухгалтерии установлено значение «Сводно по всем сотрудникам», то при формировании пакета выгрузки система игнорирует персональные данные. Программа «считает», что раз в бухгалтерии не нужна аналитика по каждому работнику на 70 счете, то и переносить справочник ФизическиеЛица избыточно.
2. Детальный учет: Если выбран вариант «По каждому работнику», то в документе отражения заполняется информация о сотрудниках, и правила обмена автоматически включают этих физических лиц в файл выгрузки.

Таким образом, если у вас ведется сводный учет, стандартный обмен просто «вырезает» физических лиц из пакета данных для оптимизации объема передачи.

Способ 1. Изменение настроек детализации учета

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

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

Важно: После смены этой настройки на стороне БП необходимо заново перегрузить документы ОтражениеЗарплатыВБухучете из ЗУП. Только тогда вместе с документами в базу «приедут» и физические лица.

Способ 2. Использование «лайфхака» со счетами удержаний

Бывают ситуации, когда бухгалтерии принципиально важно вести учет на 70 счете сводно, но при этом необходимо, чтобы справочник физических лиц все же пополнялся (например, для учета исполнительных листов или прочих расчетов). В этом случае можно воспользоваться особенностью работы счетов 71, 73 и 76.

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

1. В документе ОтражениеЗарплатыВБухучете на стороне ЗУП убедимся, что присутствуют записи по счетам, отличным от 70 (например, удержания по алиментам на счет 76.41 или расчеты по займам на счет 73).
2. Поскольку счета 76.41 или 73 в 1С:Бухгалтерии требуют субконто ФизическиеЛица (или Контрагенты), программа принудительно включит данные этих лиц в обмен, чтобы не нарушить целостность проводки.
3. Практический совет: Если вам нужно перенести конкретное лицо, а движений по «особым» счетам нет, можно временно включить этого человека в раздел удержаний в документе отражения (даже с нулевой или минимальной суммой), что спровоцирует механизм выгрузки.

Способ 3. Принудительная регистрация и поиск дублей

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

Проверим корректность заполнения ключевых полей в ЗУП перед обменом. Поиск и сопоставление в типовом обмене происходят по следующим приоритетам:

• СНИЛС: Самый надежный идентификатор. Если СНИЛС совпадает, объекты «склеятся» даже при разных GUID.
• ИНН: Используется, если СНИЛС не заполнен.
• ФИО + Дата рождения: Используется как последний вариант. Любая лишняя точка в имени или лишний пробел приведут к созданию дубля.

Способ 4. Универсальный обмен данными (XML)

Если типовая синхронизация EnterpriseData категорически не подходит из-за архитектурных ограничений (сводный учет), рассмотрим вариант разового или периодического переноса справочника через обработку Универсальный обмен данными в формате XML.

Разберем этот процесс по шагам:

1. Найдем или выгрузим правила обмена для вашей пары конфигураций (обычно они входят в состав дистрибутива или могут быть извлечены из самой обработки синхронизации).
2. В обработке выберем только справочник ФизическиеЛица.
3. Снимем флаги выгрузки документов.
4. Выполним выгрузку в файл из ЗУП и загрузку из файла в БП.

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

Резюме и рекомендации

Подводя итог, можно сказать, что проблема «невидимого» переноса физлиц — это не ошибка программы, а особенность логики обмена EnterpriseData. Чтобы решить её максимально эффективно, рекомендуем:

• Если это допустимо, включите в БП детальный учет по сотрудникам. Это решит 99% проблем с синхронизацией справочников.
• Если учет должен быть сводным, используйте «лайфхак» с задействованием счетов 76 или 73 в документе отражения.
• Всегда следите за заполнением СНИЛС — это залог отсутствия дублей при любых настройках обмена.
• Используйте помощник интерактивной синхронизации для ручного сопоставления объектов, если они уже были заведены в обеих базах вручную.