← На главную

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

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

Почему «пропадают» записи при загрузке: эффект затирания

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

В независимом регистре сведений уникальность каждой строки определяется комбинацией значений всех его измерений. В регистре, подчиненном регистратору, главным ключевым полем всегда выступает сам документ-регистратор (в совокупности с полем НомерСтроки). Если при выгрузке записей из независимого регистра мы привязываем их к одному и тому же документу-приемнику, но загрузка происходит построчно (как для независимого регистра), возникает коллизия.

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

Менеджер записи против Набора записей

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

Для независимых регистров платформа разрешает использовать построчную запись через объект МенеджерЗаписи. Однако для регистра, подчиненного регистратору, на уровне ядра 1С установлен строгий запрет на использование менеджера записи. Такие данные должны записываться исключительно пакетом — через НаборЗаписей с обязательным отбором по конкретному документу-регистратору.

Попытки перенести данные напрямую, игнорируя формирование полноценного набора движений документа, всегда приводят либо к ошибкам, либо к потере данных из-за затирания.

Решение 1: Перенос через табличную часть документа (Рекомендуемое)

Многие специалисты 1С применяют изящный и 100% надежный обходной путь: перенос данных не напрямую в регистр, а в табличную часть документа базы-приемника. Этот метод исключает проблемы с наборами записей.

Разберем по шагам этот алгоритм:

1. В базе-источнике создаем произвольный алгоритм выборки (ПВД), который собирает запросом все нужные записи из независимого регистра.
2. В правилах конвертации настраиваем выгрузку этих данных в формате табличной части подходящего документа базы-приемника. Отличным вариантом будет технический документ или стандартный документ КорректировкаЗаписейРегистров.
3. Для реализации передачи данных в структуру документа используем функцию ВыгрузитьПоПравилу(). Можно скомпоновать все 3000 строк в один документ, либо разбить на несколько.
4. При загрузке в базе-приемнике создается документ с полностью заполненной табличной частью. При его проведении штатные механизмы конфигурации корректно сформируют нужные движения (набор записей) по подчиненному регистру сведений.

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

Решение 2: Перенос данных в качестве движений документа

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

Для этого потребуется собрать данные регистра в базу-источнике, например, сформировать таблицу значений (ТЗ) с записями. Затем передать эту таблицу, а в базе-приемнике (в обработчиках загрузки документа) программно сформировать и записать набор движений. Это более сложный путь, требующий хорошего знания обработчиков «Конвертации данных».

Решение 3: Настройки свойств регистра и документа

Если архитектура конфигурации-приемника позволяет вносить изменения, можно рассмотреть следующие настройки:

1. Периодичность регистра. Если регистр периодический, установка настройки «В пределах секунды» может помочь нейтрализовать сворачиваемость записей по времени, если ключи пересекались именно из-за совпадения периода. (Примечание: если регистр непериодический, этот шаг не актуален).
2. Корректировка записей регистров. Проставьте в регистре базы-приемника в качестве документа-регистратора универсальный документ (например, КорректировкаЗаписейРегистров). Это позволит переносить данные по методике загрузки «как остатки», что сильно упрощает процесс описания правил обмена.

Важные нюансы и перспективы (КД 3.x)

При настройке правил обязательно проверяйте корректность полей поиска (ПКО). Если структура регистра сильно меняется (например, измерение Номенклатура становится ресурсом или реквизитом), некорректно настроенные поля поиска заставят систему считать разные сущности одним объектом, что приведет к обновлению одной и той же записи.

Также стоит отметить, что если вы планируете переводить обмен на универсальный формат Enterprise Data (Конвертация данных 3.x), логика работы с подчиненными регистрами будет аналогичной. Структура подчиненного регистра там описывается через объект набора записей (массив строк), что лишь подтверждает правило: подчиненные регистры требуют пакетной передачи движений, а не построчной записи.