Как настроить синхронизацию данных между идентичными базами 1С:ЗКГУ 3.1?

← На главную

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

Выбор инструмента: Конвертация данных 2.1 или 3.0?

Проанализируем два основных подхода к настройке правил обмена. Выбор между Конвертация данных 2.1 и Конвертация данных 3.0 зависит от долгосрочных планов развития ваших информационных систем.

Вариант 1: Конвертация данных 2.1 (КД 2.1)

Для идентичных баз этот метод является наиболее простым и быстрым в реализации. Основной принцип работы КД 2.1 — «Метаданные источника -> Метаданные приемника». Поскольку структуры баз ЗКГУ 3.1 в вашем случае одинаковы, процесс создания правил сводится к автоматическому сопоставлению объектов. Рассмотрим преимущества:

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

Вариант 2: Конвертация данных 3.0 (КД 3.0)

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

Разные версии обновлений: Если одна база обновляется оперативно, а вторая — с большой задержкой, формат EnterpriseData обеспечит лучшую совместимость.
Стандартизация: Если в будущем планируется подключать к обмену другие конфигурации (например, 1С:Бухгалтерию), лучше сразу закладывать архитектуру на КД 3.0.

Вывод: Если базы идентичны и нетиповых изменений много, используем КД 2.1. Если вы стремитесь к современным стандартам обмена через формат EnterpriseData и готовы потратить время на описание маппинга — выбираем КД 3.0.

Программный метод: XDTO-сериализация объектов

Если вам необходимо быстро перенести конкретные объекты без создания сложных правил в специализированных конфигурациях, можно применить метод прямой сериализации. Рассмотрим ситуацию, когда базы имеют одинаковую структуру и нам нужно передать объект в формате XML.

Проанализируем пример кода для выгрузки объекта из базы-источника:


// Получаем объект, который нужно передать
ОбъектДляПередачи = ДанныеДляПередачи.ПолучитьОбъект();

// Подготавливаем запись XML
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();

// Сериализуем объект в XML через XDTO
СериализаторXDTO.ЗаписатьXML(ЗаписьXML, ОбъектДляПередачи);

// Получаем сериализованные данные в виде строки
ДанныеСтрокой = ЗаписьXML.Закрыть();

Теперь разберем процесс загрузки этой строки в базе-приемнике:


// Читаем полученную строку
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.УстановитьСтроку(ДанныеСтрокой);

// Восстанавливаем объект из XML
НовыйОбъект = СериализаторXDTO.ПрочитатьXML(ЧтениеXML);

// Устанавливаем признак загрузки, чтобы не срабатывали лишние проверки в модуле объекта
НовыйОбъект.ОбменДанными.Загрузка = Истина;

// Записываем объект в базу
НовыйОбъект.Записать();

Важное предостережение: Метод сериализации через СериализаторXDTO переносит объект «как есть», сохраняя его уникальный идентификатор (GUID). Это удобно, но опасно возникновением «битых ссылок». Если переносимый документ ссылается на сотрудника, которого нет в базе-приемнике, вы получите пустое значение или ошибку «Объект не найден». Чтобы этого избежать, предварительно убедитесь, что все связанные справочники синхронизированы.

Использование планов обмена для ежемесячной синхронизации

Для реализации автоматического ежемесячного обмена недостаточно просто уметь переносить данные. Нужно выяснить, какие именно объекты изменились. Для этого в 1С используется механизм Планов обмена. Разберем по шагам, как настроить этот процесс:

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

Особенности работы с самописными объектами и расширениями

Поскольку в вашей ЗКГУ 3.1 есть самописные документы, необходимо учитывать технические нюансы при работе с Конвертацией данных 2.1. Если ваши изменения внесены не напрямую в конфигурацию, а через Расширения, стандартная обработка выгрузки метаданных может их проигнорировать.

В этом случае выполним следующие действия:

Используем актуальную версию обработки MD83Exp.epf, которая поддерживает работу с расширениями.
При выгрузке структуры метаданных обязательно проверяем наличие галочек напротив ваших кастомных объектов.
В базе-приемнике структура расширения должна полностью совпадать с источником, иначе при записи объекта через СериализаторXDTO или загрузке через КД возникнет ошибка несоответствия типов данных.

Проблема предопределенных данных

Часто при синхронизации возникают дубли предопределенных элементов (например, статьи затрат или виды начислений). Если базы создавались не из одной копии, GUID предопределенных элементов могут различаться. При использовании КД 2.1 рекомендуем всегда устанавливать флаг «Найти объект по внутреннему идентификатору» и настраивать правила сопоставления по наименованию или коду для ключевых справочников. Это позволит системе «склеить» идентичные элементы, даже если их внутренние ссылки не совпадают.

Итоги и рекомендации

Подводя итог, для настройки синхронизации между идентичными ЗКГУ 3.1 выполним следующие шаги:

Для быстрой настройки и поддержки кастомных объектов выберем Конвертацию данных 2.1.
Создадим План обмена в обеих базах для автоматической фиксации изменений за месяц.
Если требуется разовый перенос небольшого объема данных, воспользуемся XDTO-сериализацией, помня о необходимости контроля ссылочной целостности (GUID).
При использовании расширений проконтролируем идентичность их версий в обеих информационных базах.

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