КД2: Не выгружается справочник СерииНоменклатуры из КА1.1 в КА2.4 из-за конфликта КлючВыгружаемыхДанных

Перенос данных между конфигурациями разных поколений — например, из 1С:Комплексная автоматизация 1.1 (или УПП 1.3) в Комплексную автоматизацию 2.4 — всегда таит в себе множество подводных камней. Одним из таких неочевидных препятствий является механизм кэширования «1С:Конвертации данных 2.1» (КД2). В процессе выгрузки документов программисты часто сталкиваются с ситуацией, когда в базе-источнике в табличной части присутствуют разные номенклатурные позиции со своими уникальными сериями, но в итоговом файле выгрузки XML оказывается лишь одна серия, а вторая бесследно исчезает или подменяется первой.

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

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

1. Товар: Оправка поршневых колец универсал., Серия: с/н 04/03/2019 (GUID серии: 8bc4e391-3e31-11e9-a56b-28924acd4010)
2. Товар: Съемник стопорных колец, Серия: с/н 04/03/2019 (GUID серии: 8bc4e393-3e31-11e9-a56b-28924acd4010)

Несмотря на то, что в логах выгрузки регистрируется обработка обеих серий, в результирующем XML-файле сохраняется только одна из них. Давайте детально разберем по шагам, почему так происходит.

1. Механизм кэширования в КД2 и роль КлючВыгружаемыхДанных

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

1. Проверяет, выгружался ли данный объект ранее в рамках текущего сеанса.
2. Если объект еще не выгружался, он сериализуется (полностью записывается в XML со всеми реквизитами и свойствами), а в кэш записывается информация о его выгрузке с присвоением уникального порядкового номера — параметра Нпп (номер по порядку, например, <Ссылка Нпп="125">).
3. Если объект уже присутствует в кэше, повторная полная выгрузка не производится. Вместо этого в XML-файл записывается короткая ссылка вида <Ссылка Нпп="125"/>, указывающая на ранее выгруженную структуру.

По умолчанию в качестве ключа кэширования КД2 использует внутреннее строковое представление ссылки объекта источника — системный аналог функции ЗначениеВСтрокуВнутр(Источник). Это гарантирует абсолютную уникальность: две разные серии с одинаковыми наименованиями, но разными GUID, будут обработаны как два независимых объекта.

Проблема возникает в тот момент, когда разработчик в обработчике ПКО ПередВыгрузкойОбъекта принудительно переопределяет этот ключ вручную:

КлючВыгружаемыхДанных = Источник.Наименование;

Давайте проанализируем, к чему это приводит. Переопределяя КлючВыгружаемыхДанных строковым наименованием серии (например, "с/н 04/03/2019"), мы заставляем систему кэшировать данные не по уникальной ссылке, а по текстовому представлению. Происходит следующая последовательность событий:

1. Система обрабатывает первую строку документа. Обнаруживается серия "с/н 04/03/2019" для Оправки поршневых колец.
2. Поскольку ключа "с/н 04/03/2019" еще нет в кэше, объект выгружается полностью. Ему присваивается определенный номер Нпп. Ключ регистрируется в кэше.
3. Система переходит ко второй строке документа. Обнаруживается серия "с/н 04/03/2019" для Съемника стопорных колец.
4. Вычисляется КлючВыгружаемыхДанных, который снова равен строке "с/н 04/03/2019".
5. КД2 находит этот ключ в своем кэше выгруженных объектов. Программа полагает, что данная серия уже была полностью выгружена ранее.
6. Вместо полной выгрузки второй серии (с ее уникальным GUID и владельцем) КД2 просто записывает в файл быструю ссылку Нпп на первую серию. В итоге, при загрузке в базу-приемник у второго товара либо подставится чужая серия первого товара, либо поле вовсе очистится из-за несоответствия владельцев.

2. Правильное формирование КлючВыгружаемыхДанных

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

Разберем правильный пример заполнения обработчика ПередВыгрузкойОбъекта для ПКО СерииНоменклатуры:

// Формируем гарантированно уникальный ключ на основе GUID самой серии и GUID ее владельца
КлючВыгружаемыхДанных = Строка(Источник.УникальныйИдентификатор()) + "/" + Строка(Источник.Владелец.УникальныйИдентификатор());

Если в источнике у серий отсутствует GUID (например, это плоская таблица или внешние данные), но есть уникальный код и наименование в разрезе владельца, можно использовать комбинированную строку:

КлючВыгружаемыхДанных = "СправочникСерии_" + СокрЛП(Источник.Владелец.Код) + "_" + СокрЛП(Источник.Код) + "_" + СокрЛП(Источник.Наименование);

При таком подходе КД2 корректно распознает серии как разные объекты, и обе структуры со своими реквизитами благополучно попадут в результирующий XML-файл.

3. Разбор флага «Не запоминать выгруженные объекты»

У начинающих разработчиков часто возникает вопрос: «А что если просто установить в настройках ПКО флаг "Не запоминать выгруженные объекты"? Нужен ли тогда КлючВыгружаемыхДанных?»

Выясним физический смысл этой настройки. Если взвести флаг «Не запоминать выгруженные объекты», то система КД2 действительно перестанет помещать обработанные объекты этого правила в глобальный кэш. Проблема с дублированием ключей исчезнет, так как при встрече каждой серии система будет выгружать её структуру целиком заново.

Однако этот подход имеет критические недостатки:

• Лавинообразное увеличение размера файла: Если одна и та же серия используется в тысячах документов или строк, она будет записана в XML-файл тысячи раз. Размер итогового файла выгрузки увеличится в разы, а в некоторых случаях — на порядки.
• Падение производительности загрузки: При загрузке в базу-приемник платформа 1С будет вынуждена тысячи раз выполнять поиск и перезапись одного и того же элемента справочника в транзакции. Это создаст колоссальную избыточную нагрузку на СУБД и критически замедлит процесс переноса данных.

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

4. Связь ключа выгрузки и флага «Получить значение из входящих данных»

Проанализируем еще одно частое заблуждение: связана ли ручная установка КлючВыгружаемыхДанных с флагом ПКС «Получить значение из входящих данных».

Прямой жесткой зависимости на уровне ядра платформы нет. Однако на практике эти механизмы часто используются совместно при решении нестандартных задач конвертации:

1. Флаг «Получить значение из входящих данных» указывает правилу конвертации свойства (ПКС), что значение реквизита не нужно считывать из объекта-источника напрямую. Вместо этого значение должно быть принудительно извлечено из специальной транзитной структуры ВходящиеДанные, переданной из вышестоящего правила выгрузки.
2. Если на основе этих входящих данных мы конструируем «виртуальный» объект (который физически не существует в базе-источнике в виде ссылки), у системы отсутствует стандартный Источник. Соответственно, КД2 не может автоматически рассчитать его уникальный внутренний идентификатор.
3. В этом сценарии разработчик обязан самостоятельно сформировать уникальный КлючВыгружаемыхДанных в обработчике ПКО. Если этого не сделать, все генерируемые «на лету» виртуальные объекты склеятся в кэше КД2 в один единственный элемент, и перенос завершится ошибкой или потерей информации.

5. Архитектурные особенности переноса серий из КА 1.1 в КА 2.4

Помимо тонкостей работы самой КД2, при переносе серий номенклатуры важно учитывать кардинальные различия в архитектуре учета этих объектов между старыми конфигурациями (КА 1.1, УПП 1.3) и новыми решениями на ERP-платформе (КА 2.4, ERP 2, УТ 11).

Рассмотрим ключевые различия, которые необходимо заложить в правила конвертации до начала переноса:

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

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