Как исправить неверное заполнение номенклатуры при переносе данных из ТиС 9.2 в УТ 11.4?

← На главную

Перенос данных из устаревших конфигураций на платформе 1С 7.7 в современные решения на 1С 8.3 — задача всегда ответственная и полная нюансов. Одной из самых частых проблем является некорректная идентификация объектов, в частности — Номенклатуры. Разберем ситуацию, когда при загрузке документов в Управление торговлей 11.4 номенклатура подставляется неверно из-за поиска по наименованию, которое не является уникальным, в то время как уникальность обеспечивается артикулом.

Анализируем причины проблемы идентификации

Проанализируем ситуацию: стандартные правила обмена часто настроены на поиск по внутреннему идентификатору (GUID), а если он не найден — по наименованию. В конфигурации Торговля и склад 9.2 артикул часто является ключевым полем для пользователя, но для механизмов обмена он может игнорироваться. Выясним причину, по которой изменения в графическом интерфейсе Конвертации данных 2.0 (КД 2) не всегда приносят результат при работе с базами 7.7.

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

Способ 1. Настройка поиска через обработчик «Поля поиска»

Если стандартная установка флага "Поиск" на реквизите Артикул не помогает, нам необходимо вмешаться в алгоритм сопоставления. Рассмотрим подробнее, как это сделать в Конвертации данных 2.0. Перейдем в ПКО Номенклатура на закладку "Обработчики событий" и найдем событие «Поля поиска».

Разберем по шагам логику, которую необходимо внедрить:

Система должна сначала попытаться найти объект по уникальному идентификатору.
Если по УИД объект не найден, мы принудительно заставляем систему искать по Артикулу.
Важно исключить поиск по наименованию, если мы не уверены в его уникальности.

Пример кода для обработчика «Поля поиска» на стороне приемника (УТ 11):


// Проверяем, какой вариант поиска сейчас выполняется
// НомерВарианта — это итератор поиска
Если НомерВарианта = 1 Тогда
    // Пытаемся найти по артикулу, если он передан
    Если СвойстваПоиска.Свойство("Артикул") И ЗначениеЗаполнено(СвойстваПоиска.Артикул) Тогда
        СсылкаНаОбъект = Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", СвойстваПоиска.Артикул);
        
        Если Не СсылкаНаОбъект.Пустая() Тогда
            // Если нашли — прекращаем дальнейшие варианты поиска
            ПрекратитьПоиск = Истина;
        КонецЕсли;
    КонецЕсли;
КонецЕсли;

Важный момент: Чтобы этот код сработал, убедитесь, что в ПКС (Правила Конвертации Свойств) для реквизита Артикул стоит галочка "Поиск".

Способ 2. Подготовка данных в источнике (ТиС 7.7)

Посмотрим на проблему под другим углом. В 1С 7.7 строки часто имеют фиксированную длину. Если поле артикула в конфигураторе определено, например, как 25 символов, то артикул "123" фактически выгрузится как "123" с кучей пробелов в конце. При загрузке в 1С 8.3, где тип Строка является переменным, поиск "123" может не найти "123 ".

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

Значение = СокрЛП(Источник.Артикул);

Это гарантирует, что в XML-файл попадет "чистое" значение, которое легко сопоставить в приемнике.

Способ 3. Очистка регистра соответствий в УТ 11

Часто бывает так: вы исправили правила, запустили перенос снова, но номенклатура всё равно "кривая". Почему? Выясним причину. При первом (неудачном) переносе система создала записи в служебном регистре сведений «Соответствия объектов информационных баз».

Система запомнила, что объекту ID_001 из 7.7 соответствует объект Товар_Ошибочный в 8.3. При повторном поиске программа даже не смотрит на ваши новые правила поиска по артикулу — она сразу берет готовую ссылку из регистра соответствий.

Рассмотрим порядок действий для исправления:

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

Способ 4. Синхронизация по Коду (Технический обход)

Если работа с КД 2 кажется слишком сложной или настройки не применяются из-за особенностей V77Exp.ert, рассмотрим практический совет от опытных специалистов. В 1С 7.7 стандартным и самым быстрым полем поиска является Код.

Проанализируем алгоритм этого метода:

В базе 7.7 создаем простую обработку, которая копирует значение из поля Артикул в поле Код.
Предварительно можно добавить к коду префикс (например, "ПЕР_"), чтобы избежать дублирования с существующими кодами.
В правилах конвертации в ПКО Номенклатура устанавливаем поиск только по Коду.
После завершения миграции в базе 8.3 можно вернуть артикулы на место или оставить всё как есть, так как поиск по коду в 8.3 работает мгновенно.

Нюанс с единицами измерения

Иногда номенклатура не сопоставляется из-за включенного поиска по совокупности полей. Проверьте, не настроен ли в правилах поиск по связке «Артикул + Единица измерения». В 7.7 единицы измерения — это подчиненный справочник, а в УТ 11 структура хранения упаковок и единиц значительно сложнее. Если в 7.7 единица была "шт", а в УТ 11 она создана как "шт." (с точкой), поиск по артикулу может не сработать, так как не совпадет второй обязательный параметр поиска.

Рекомендуем в ПКО Номенклатура оставить для поиска только один уникальный реквизит — либо Код, либо Артикул, предварительно убедившись в его уникальности и индексации в базе-приемнике. Для этого в конфигураторе УТ 11 у реквизита Артикул должно быть установлено свойство «Индексировать».

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