При настройке обмена данными между конфигурациями 1С:Зарплата и управление персоналом (ЗУП) и 1С:Бухгалтерия предприятия (БП) пользователи часто сталкиваются со странной ситуацией: в исходной базе (ЗУП) данные успешно регистрируются и выгружаются, но принимающая база (БП) сообщает, что получено 0 объектов. Особенно часто это проявляется при переходе с файлового режима работы на клиент-серверный (SQL). Рассмотрим подробно, почему это происходит и как решить данную проблему.
Прежде чем переходить к сложным манипуляциям с сервером, проанализируем настройки самой 1С:Бухгалтерии. Одной из самых частых причин «тихого» отказа от приема данных является неверно установленный признак ведения учета. Выясним, установлена ли в базе БП необходимая опция.
Перейдем в раздел Администрирование — Настройки программы — Параметры учета — Настройки зарплаты. Здесь должен быть выбран вариант «В сторонней программе». Если флажок стоит правильно, но данные все равно не поступают, попробуем переоткрыть сеанс. Проанализируем также справочник Организации: ИНН и КПП в обеих базах должны совпадать до символа. Если БП не может сопоставить организацию из пакета данных со своей записью, она может проигнорировать входящие документы.
Как показывает практика, основной причиной сбоя в SQL-версиях часто является «зависание» внутренних механизмов платформы, отвечающих за работу с временными файлами и кэшем метаданных. Если в журнале регистрации мы видим успешную выгрузку, но нулевой прием, первым делом выполним перезапуск службы Агент сервера 1С:Предприятие.
Разберем, почему это помогает. В процессе синхронизации сервер создает временные файлы и удерживает определенные области оперативной памяти. При длительной работе без перезагрузки или после обновлений платформы могут возникнуть конфликты сессий. Перезагрузка службы очищает оперативную память и сбрасывает зависшие соединения, что зачастую мгновенно восстанавливает работоспособность обмена.
Если перезагрузка службы помогла лишь временно или не помогла вовсе, проанализируем права доступа. В SQL-варианте процесс обмена выполняется от имени пользователя, под которым запущен сервер 1С (обычно это USR1CV8 или LocalSystem).
Рассмотрим пошагово проверку прав:
C:\Windows\Temp и папку временных файлов в профиле пользователя сервера (например, C:\Users\USR1CV8\AppData\Local\Temp).Многие механизмы синхронизации (особенно в старых версиях или при прямом подключении) используют COM-соединение. Проанализируем ситуацию: если у вас установлен 64-битный сервер 1С, он требует наличия 64-битной библиотеки comcntr.dll, зарегистрированной в системе.
Посмотрим на пример команды для регистрации библиотеки, если обмен выдает скрытые ошибки инициализации:
regsvr32 "C:\Program Files\1cv8\8.3.X.XXXX\bin\comcntr.dll"
Важно помнить, что версии платформ на сервере и на рабочих станциях, где инициируется обмен, должны быть идентичны. Даже разница в несколько релизов может привести к тому, что COM-объект создастся, но его методы для передачи данных не сработают корректно.
Иногда обычного перезапуска службы недостаточно. Выясним причину: сервер 1С кэширует структуру метаданных в специальных папках. Если вы обновляли конфигурацию БП или ЗУП, старый кэш может конфликтовать с новыми правилами обмена EnterpriseData.
Для радикального решения проблемы выполним следующие действия:
1C:Enterprise 8.3 Server Agent.C:\Program Files\1cv8\srvinfo\reg_1541).GUID баз и удалим в них содержимое подпапок snccntxt.Внимание: это действие приведет к тому, что первый запуск базы после очистки будет долгим, так как системе потребуется время на перегенерацию кэша.
Современные версии БП 3.0 и ЗУП 3.1 работают через универсальный формат. Разберем, как убедиться, что данные действительно «ушли». В базе ЗУП откроем окно Синхронизация данных и выберем пункт Состав отправляемых данных. Если список документов пуст, значит, правила регистрации изменений не сработали. В этом случае нам нужно вручную добавить документы в состав отправки.
Также проверим Дату начала использования синхронизации в настройках узла обмена. Если документы в ЗУП созданы 31-м числом прошлого месяца, а в настройках синхронизации указано 1-е число текущего, то документы будут «выгружаться» как технические ссылки, но БП их не примет, так как они не входят в разрешенный период.
Если в БП данные все равно не появляются, выясним, не заблокированы ли регламентные задания. После восстановления базы из копии 1С автоматически включает блокировку фоновых заданий. В этом случае прием данных просто не стартует.
Проанализируем Журнал регистрации в принимающей базе (БП). Установим фильтр по событию Данные.Прием. Часто там можно обнаружить ошибки XDTO-сериализации:
EnterpriseData не совпадает.Рассмотрим еще один момент: блокировки базы данных на уровне SQL. Если во время обмена выполняется тяжелый отчет или перепроведение документов, транзакция приема данных может быть отменена по таймауту, при этом в интерфейсе мы увидим просто «0 объектов».
Мы выяснили, что проблема «нулевой» синхронизации в SQL-версии чаще всего кроется в инфраструктурных особенностях: работе службы агента сервера, правах доступа к временным каталогам или устаревшем кэше. Рекомендуем всегда начинать с перезапуска службы и проверки актуальности релизов обеих конфигураций. Совместная работа системного администратора и программиста 1С позволяет быстро локализовать проблему через анализ журналов сервера и настроек прав доступа USR1CV8.