Синхронизация данных между 1С:Зарплата и управление персоналом 3.1 и 1С:Бухгалтерия предприятия 3.0 — один из самых ответственных процессов в работе технического специалиста и бухгалтера. Часто возникает ситуация, когда при прямом подключении (SQL-базы) основные данные переносятся корректно, но механизмы «обратной связи» начинают давать сбои. Типичный пример: бухгалтер снимает флаг «Отражено в учете» в конфигурации «Бухгалтерия», рассчитывая, что в «ЗУП» документ разблокируется для редактирования, но этого не происходит автоматически.
Рассмотрим подробно, почему типовые механизмы регистрации изменений могут игнорировать это действие, и разберем по шагам, как настроить систему для корректной работы.
Для начала проанализируем, как 1С «понимает», что документ нужно отправить в другую базу. В основе обмена лежит объект метаданных ПланОбмена. Когда пользователь записывает документ (например, ДокументОбъект.ОтражениеЗарплатыВБухучете), срабатывает подписка на событие, которая добавляет запись в таблицу регистрации изменений для конкретного узла обмена.
Если бухгалтер просто визуально снимает галку и закрывает форму без фактической перезаписи объекта, или если в правилах регистрации прописаны жесткие фильтры, регистрация не происходит. Выясним основные причины, по которым изменения «застревают» в информационной базе.
Одной из часто встречающихся причин является логика работы правил выгрузки данных. В стандартных настройках синхронизации часто установлен приоритет: выгружать только те объекты, которые соответствуют определенным критериям. В случае с документом ОтражениеЗарплатыВБухучете, система может игнорировать документ, если:
Посмотрим на ситуацию со стороны кода. Если мы хотим проверить, зарегистрирован ли документ к обмену, мы можем использовать стандартную обработку Регистрация изменений для обмена. Если после снятия галки в Бухгалтерии документ не появился в списке зарегистрированных для узла ЗУП, значит, событие записи не инициировало регистрацию.
Чтобы автоматизировать процесс и избавить бухгалтера от необходимости ручной регистрации документов через консоль, выполним следующие действия.
Выясним важный технический нюанс: простое снятие флага в форме может не вызывать метод Записать() для всего объекта, если форма настроена специфическим образом. Попросим бухгалтера использовать следующий алгоритм:
Помимо привычной даты запрета редактирования, в 1С существует механизм «Дата запрета загрузки». Рассмотрим подробнее: если в настройках синхронизации (в узле обмена) установлена дата запрета загрузки, то любые изменения, внесенные в документы старого периода, будут игнорироваться принимающей стороной (в нашем случае — ЗУП). Если вы правите 2016 год, обязательно убедитесь, что в ЗУП в настройках синхронизации эта дата не ограничивает прием данных.
Проанализируем правила разрешения коллизий. По умолчанию 1С считает ЗУП «мастер-системой» для кадровых и расчетных данных. Если в момент синхронизации документ был изменен и в ЗУП, и в Бухгалтерии, система может принять версию из ЗУП, где галка все еще стоит. Чтобы изменения из БП гарантированно ушли в ЗУП, убедитесь, что в ЗУП документ не открыт и не заблокирован в этот момент.
Если вы используете расширения конфигурации, проверьте, не перекрывают ли они стандартную логику работы документа. Иногда программисты создают собственные процедуры в расширениях, забывая вызвать ПродолжитьВызов(), что блокирует работу типовой подписки ОбменДаннымиЗарплатаКадрыПередачаДанныхВБухгалтериюПредприятия.
Для программной проверки регистрации изменений можно использовать следующий пример кода:
// Пример проверки регистрации объекта в плане обмена
ПланОбменаСсылка = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("ЗУП");
Если Не ПланОбменаСсылка.Пустая() Тогда
ЗарегистрированныеИзменения = ПланыОбмена.ВыбратьИзменения(ПланОбменаСсылка, 1);
Пока ЗарегистрированныеИзменения.Следующий() Цикл
Если ЗарегистрированныеИзменения.НомерСообщения = Неопределено Тогда
Сообщить("Объект зарегистрирован и готов к отправке: " + ЗарегистрированныеИзменения.Данные);
КонецЕсли;
КонецЦикла;
КонецЕсли;
В клиент-серверном варианте (SQL) регистрация изменений может происходить через фоновые задания. Рассмотрим ситуацию, когда синхронизация запускается слишком быстро. Система может не успеть обработать транзакцию записи и поместить ее в таблицу изменений. Рекомендуется:
Таким образом, мы выяснили, что основная причина проблемы чаще всего кроется в отсутствии автоматической регистрации документа из-за фильтров по дате или из-за особенностей записи объекта в Бухгалтерии. Для решения проблемы необходимо проверить настройки Даты запрета загрузки и приучить пользователя всегда нажимать кнопку «Записать» после изменения статуса отражения. Это позволит системе штатно поместить документ в план обмена и передать признак разблокировки в ЗУП при следующем сеансе синхронизации.