← На главную

Переход с редакции 1С:Управление торговлей 10.3 на 11.5 часто сопровождается сложностями при миграции справочной информации. Одной из самых частых проблем является перенос дополнительных свойств номенклатуры. Стандартная обработка переносит данные, но зачастую в новой базе остается пустым поле НаборСвойств в дополнительных реквизитах. Давайте разберем по шагам, почему возникает эта ситуация, и проанализируем эффективные способы ее решения.

Проанализируем архитектурные различия баз данных

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

В УТ 10.3 свойства номенклатуры хранятся независимо:

1. Сами характеристики описываются в Плане видов характеристик (ПВХ) СвойстваОбъектов.
2. Привязка конкретного значения свойства к позиции номенклатуры осуществляется через независимый регистр сведений ЗначенияСвойствОбъектов.

В УТ 11.5 этот механизм кардинально изменен и стал более структурированным:

1. Свойства реализованы через механизм ДополнительныеРеквизитыИСведения.
2. Эти реквизиты не существуют сами по себе, а жестко привязываются к справочнику ВидыНоменклатуры.
3. Именно вид номенклатуры определяет элемент справочника НаборыДополнительныхРеквизитовИСведений.

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

Разберем особенности стандартной обработки перехода

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

Посмотрим на поведение системы в зависимости от этого флага:

1. Если флажок не установлен: Программа при выгрузке может создать для каждой отдельной позиции номенклатуры свой индивидуальный набор свойств. Это неизбежно приведет к появлению огромного количества дублей наборов в УТ 11.5 и загрязнению базы.
2. Если флажок установлен: Алгоритм попытается проанализировать номенклатуру базы-источника и сгруппировать общие характеристики, привязав их к создаваемым видам номенклатуры. Однако, если в исходной базе 10.3 был хаос в справочниках и свойствах, стандартный перенос все равно часто теряет связь поля НаборСвойств.

Настроим правила в Конвертации данных 2.1 (КД 2.1)

Если мы решаем использовать Конвертацию данных 2.1, разберем необходимые доработки. Недостаточно просто связать ПВХ источника и приемника. Нам потребуется сложный программный маппинг в обработчиках событий.

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

1. При выгрузке справочника Номенклатура нам необходимо программно определить, к какому элементу ВидыНоменклатуры она будет отнесена в новой базе.
2. На стороне приемника (в УТ 11.5) нужно написать алгоритм поиска или создания элемента в справочнике НаборыДополнительныхРеквизитовИСведений, который подчинен найденному ранее виду номенклатуры.
3. Данные из регистра сведений УТ 10.3 должны конвертироваться напрямую в табличную часть ДополнительныеРеквизиты самого элемента справочника номенклатуры в УТ 11.5. При этом в каждую строку должен подставляться сформированный нами НаборСвойств.

Важно помнить, что для успешного переноса значений нам нужно обязательно выгружать записи из регистра сведений ЗначенияСвойствОбъектов, а не только сам ПВХ.

Рассмотрим альтернативный подход: Постобработка загруженных данных

На практике многие специалисты предпочитают не усложнять правила КД 2.1 сложной логикой, которую тяжело отлаживать. Разберем более прозрачный путь решения.

Данные (ПВХ и регистр сведений) переносятся «как есть» с использованием типовых правил, даже если они ложатся во временные структуры или остаются без жестких привязок. Затем в самой УТ 11.5 запускается специально написанная внешняя обработка.

Что должна делать эта обработка? Разберем по шагам:

1. Программно обходит весь загруженный справочник Номенклатура.
2. Анализирует перенесенные значения из старого регистра или временных реквизитов.
3. Правильно распределяет элементы по справочнику ВидыНоменклатуры.
4. Генерирует или находит для этих видов нужные НаборыДополнительныхРеквизитовИСведений.
5. Записывает сформированные значения в табличную часть ДополнительныеРеквизиты объекта номенклатуры и заполняет поле НаборСвойств.

Этот метод позволяет полностью контролировать процесс классификации номенклатуры уже в новой архитектуре УТ 11.5, используя все возможности платформы и отладчика.

Выясним важные нюансы перед выгрузкой из УТ 10.3

Ошибки вида «Ошибка получения значения свойства объекта» при переносе через КД 2.1 часто возникают из-за некорректных данных в базе-источнике. Перед стартом процесса переноса выполним обязательные подготовительные действия в УТ 10.3:

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

Тщательная подготовка исходной базы и правильный выбор между доработкой правил КД 2.1 и написанием обработки-постпроцессора позволят вам перенести справочник номенклатуры с сохранением всей критически важной аналитики.