Как избежать задвоения данных при выгрузке и загрузке XML в 1С?

← На главную

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

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

Выясняем причину: почему стандартная обработка XML задваивает данные?

Чтобы понять логику работы платформы 1С, давайте заглянем «под капот» СУБД. Главная техническая особенность обработки ВыгрузкаЗагрузкаДанныхXML.epf заключается в том, что она работает на самом низком уровне платформы и ориентируется исключительно на уникальные идентификаторы (GUID / УИД) объектов.

Каждый элемент справочника или документ в 1С при создании получает уникальный 128-битный номер (например, 550e8400-e29b-41d4-a716-446655440000). Когда стандартная обработка выгружает документ, она записывает в XML-файл не только его реквизиты, но и GUID самого документа, а также GUID всех связанных с ним объектов (субконто, авторов, физлиц, организаций и т.д.).

При загрузке в базу-приемник происходит следующее:

Обработка считывает GUID переносимого элемента.
Выполняется прямой поиск в базе-приемнике по этому GUID.
Важный момент: поиск по наименованию, коду, ИНН или СНИЛС платформой на этом этапе не производится!
Если объект с таким GUID не найден, система создает абсолютно новый элемент и принудительно записывает ему GUID из источника.

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

Ситуация усложняется предопределенными элементами. В современных версиях платформы 1С предопределенные элементы (например, виды начислений в ЗУП) создаются динамически при первом запуске или обновлении ИБ. Если базы создавались независимо, GUID предопределенных элементов также могут отличаться. При переносе документов стандартная обработка создаст их дубли, что серьезно нарушит логику проведения документов.

Специфика задвоения в 1С:ЗУП

В конфигурации 1С:Зарплата и управление персоналом задвоение справочников критично. Это связано со сложной структурой регистров:

Справочник Сотрудники жестко подчинен справочнику Физические лица.
Кадровые приказы делают записи во множество регистров сведений (например, КадроваяИсторияСотрудников, ПлановыеНачисления).

Если перенести кадровый приказ без предварительного сопоставления физических лиц, то в базе-приемнике создадутся новые физлица и сотрудники. Документы проведутся по новым объектам. В результате в регламентированных отчетах по НДФЛ и страховым взносам начнется хаос: начисления запишутся на нового (загруженного) сотрудника, а персональные данные, вычеты и история останутся на старом.

Анализ идеи «догрузить в копию, а потом в рабочую»

Иногда у разработчиков возникает мысль: «Я загружу данные в копию рабочей базы, там все настрою, а уже потом перенесу в рабочую базу». Разберем по шагам, почему этот способ не сработает сам по себе.

Если базы-источники имели разное происхождение, то при переносе данных в копию рабочей базы задвоение произойдет точно так же, но внутри этой копии. Если затем просто переписать данные из копии в рабочую базу, вы перенесете эти дубликаты в «живую» базу. Данный подход имеет право на жизнь только в одном случае: если в копии перед финальным переносом вы проведете кропотливую работу по поиску, замене и слиянию дублирующихся элементов.

---

Варианты решения проблемы

Рассмотрим подробнее четыре рабочих способа, которые помогут перенести данные без появления дубликатов.

Способ 1. Использование «Конвертации данных 2.0» (КД 2) — правильный подход

Для корректного сопоставления объектов с разными GUID необходимо использовать специализированный инструмент — конфигурацию 1С:Конвертация данных 2.0. Этот инструмент позволяет гибко настроить правила поиска объектов при загрузке.

Проанализируем алгоритм настройки правил в КД 2:

Создаем новые правила обмена между базой-источником и базой-приемником.
Для каждого ключевого справочника (например, ФизическиеЛица, Сотрудники, Организации) создаем Правило Конвертации Объектов (ПКО).
В настройках ПКО на вкладке «Поля поиска» снимаем флажок «Искать объект по внутреннему идентификатору».
Вместо этого настраиваем правила сопоставления по ключевым реквизитам:
- Для справочника ФизическиеЛица настраиваем поиск по полям СНИЛС или связке ФИО + ДатаРождения.
- Для справочника Организации настраиваем поиск по ИНН + КПП.
- Для справочника Сотрудники настраиваем поиск по Код или связке ФизическоеЛицо + Организация.
При переносе данных через обработку УниверсальныйОбменДаннымиXML система при загрузке сначала попытается найти объект по заданным полям поиска. Если элемент найден — он будет обновлен или просто подставлен в документы, если нет — создастся новый.

Способ 2. Выравнивание уникальных идентификаторов (GUID) перед переносом

Если объем переносимых данных невелик, а справочники организаций и физлиц уже сопоставлены визуально, мы можем программно «выровнять» GUID в базе-источнике, чтобы они совпадали с GUID в базе-приемнике. После этого стандартная выгрузка/загрузка отработает идеально.

Давайте посмотрим на пример программного кода, который позволяет переназначить GUID существующего элемента в базе-источнике (код выполняется в базе-источнике):


// Пример замены ссылки объекта на ссылку с требуемым GUID
Процедура ВыровнятьИдентификаторОбъекта(ИмяСправочника, КодОбъекта, СтрокаНовогоGUID)
    
    НовыйУИД = Новый УникальныйИдентификатор(СтрокаНовогоGUID);
    НужнаяСсылка = Справочники[ИмяСправочника].ПолучитьСсылку(НовыйУИД);
    
    // Ищем старый элемент по коду
    СтарыйОбъект = Справочники[ИмяСправочника].НайтиПоКоду(КодОбъекта);
    
    Если НЕ СтарыйОбъект.Пустая() Тогда
        // Создаем новый элемент с правильным GUID
        НовыйОбъект = Справочники[ИмяСправочника].СоздатьЭлемент();
        ЗаполнитьЗначенияСвойств(НовыйОбъект, СтарыйОбъект, , "Ссылка, Код");
        НовыйОбъект.Код = СтарыйОбъект.Код;
        НовыйОбъект.УстановитьСсылкуНового(НужнаяСсылка);
        НовыйОбъект.Записать();
        
        // Перенаправляем ссылки и удаляем старый элемент
        СсылкаНаЗамену = СтарыйОбъект.Ссылка;
        Выборка = Справочники[ИмяСправочника].Выбрать();
        // Здесь должна быть логика замены ссылок в документах (или использование стандартного Поиска и замены ссылок)
        
        СтарыйОбъект.ПолучитьОбъект().Удалить();
        Сообщить("Элемент успешно пересоздан с новым GUID!");
    КонецЕсли;
    
КонецПроцедуры

Важное предупреждение: Прямая замена ссылок — сложная операция. Рекомендуется использовать готовые обработки с ИТС или профильных ресурсов (например, «Изменение GUID объектов»), предварительно сделав резервную копию базы данных!

Способ 3. Использование модифицированных версий обработки выгрузки/загрузки

Если вы не хотите погружаться в разработку правил обмена в КД 2, можно воспользоваться модифицированными версиями стандартной обработки ВыгрузкаЗагрузкаДанныхXML, которые созданы сообществом разработчиков 1С.

В интерфейс таких доработанных обработок добавлен функционал сопоставления объектов по ключевым реквизитам непосредственно в момент загрузки. Вы указываете XML-файл, выбираете справочник (например, Физические лица) и задаете галочками правила поиска (например, по Наименованию). Обработка сама на лету подменяет GUID в загружаемом потоке данных. Для переноса между базами с разной структурой ссылок также используют обработку переноса данных между похожими конфигурациями 1С с произвольными полями поиска.

Способ 4. Слияние дубликатов после переноса (Постфактум)

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

Перейдите в раздел Администрирование -> Обслуживание -> Корректировка данных.
Запустите типовую обработку «Поиск и удаление дублей».
В поле «Искать в:» выберите нужный справочник (например, Физические лица).
В правилах поиска укажите критерий совпадения (например, «ФИО совпадают по похожим словам» или «СНИЛС совпадает»).
Нажмите «Найти дубли». Система покажет список найденных пар.
Выберите в качестве «Оригинала» элемент, который изначально был создан в вашей рабочей базе, а в качестве «Дубля» — загруженный элемент.
Нажмите кнопку «Удалить дубли». Обработка автоматически найдет все документы, регистры, кадровые приказы, где фигурировал дубликат, перепишет ссылки на оригинальный элемент и корректно удалит дублирующий объект.

Важно: При слиянии дублей сотрудников и физических лиц в ЗУП обязательно проверяйте проведение документов после операции, так как в регистрах расчета зарплаты могут возникнуть коллизии из-за перерасчетов.