Переход с платформы «1С:Предприятие 8.2» на 8.3 и миграция данных из старых редакций (таких как «Управление торговлей 10.3») в современные (УТ 11.5) — это процесс, часто сопровождающийся техническими коллизиями. Одной из наиболее распространенных проблем является ошибка СУБД, связанная со сравнением строк неограниченной длины. В этой статье мы подробно разберем, почему возникает эта ситуация, и совместно изучим алгоритмы её решения.
Разберем ситуацию: при загрузке данных в УТ 11 система выдает сообщение о том, что поле НаименованиеПолное (или аналогичное) имеет неограниченную длину и не может участвовать в сравнении. Проблема кроется в фундаментальном различии архитектуры метаданных. В УТ 10.3 реквизит НаименованиеПолное справочника Номенклатура имеет тип Строка с длиной 0 (неограниченно). В УТ 11 разработчики ограничили это поле длиной в 1024 символа.
Когда правила обмена пытаются сопоставить объект в базе-приемнике с объектом в источнике, платформа формирует SQL-запрос. На уровне СУБД (будь то MS SQL Server или PostgreSQL) операция сравнения (=) или группировки (DISTINCT) для полей типа NTEXT или BLOB (которыми являются неограниченные строки) недопустима. Система просто «не понимает», как сравнивать две «портянки» текста объемом в несколько мегабайт, и прерывает выполнение транзакции.
Проанализируем самый технически правильный способ — корректировку правил обмена (файла XML). Если мы используем типовой или модифицированный перенос, нам необходимо заглянуть в ПКО (Правила конвертации объектов).
Номенклатура.НаименованиеПолное.Артикул + Наименование (рабочее) или по уникальному идентификатору (GUID).Рассмотрим пример того, как программно можно переопределить поля поиска в обработчике «Поля поиска» непосредственно в правилах:
Если СвойстваПоиска["НаименованиеПолное"] <> Неопределено Тогда
// Удаляем длинное поле из структуры поиска, чтобы не провоцировать ошибку СУБД
СвойстваПоиска.Удалить("НаименованиеПолное");
КонецЕсли;
// Устанавливаем приоритет поиска по артикулу
Если ЗначениеЗаполнено(СвойстваПоиска["Артикул"]) Тогда
НомерВарианта = 1;
КонецЕсли;
Выясним, как подготовить данные в исходной базе, чтобы минимизировать риски. Если в вашей базе НаименованиеПолное используется как хранилище маркетинговых описаний (как в примере с рюкзаком спасателя), просто «обрезать» строку — значит потерять важную информацию. Мы предлагаем алгоритм «переливки» данных в реквизит Описание.
Рассмотрим шаги автоматизации этого процесса в УТ 10.3:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка,
ДЛИНАСТРОКИ(Номенклатура.НаименованиеПолное) КАК Длина
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
ДЛИНАСТРОКИ(Номенклатура.НаименованиеПолное) > 1024
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
Если СтрДлина(Выборка.НаименованиеПолное) > 1024 Тогда
ОбъектНом = Выборка.ПолучитьОбъект();
// Сохраняем все данные в Описание (которое в УТ 11 тоже станет Описанием)
ОбъектНом.Описание = Выборка.НаименованиеПолное;
// Обрезаем НаименованиеПолное до допустимого в УТ 11 предела
ОбъектНом.НаименованиеПолное = Лев(Выборка.НаименованиеПолное, 1024);
ОбъектНом.Записать();
КонецЕсли;
КонецЦикла;
Важный нюанс: при обрезании строк до 1024 символов существует риск получить неуникальные наименования, если различие между товарами было в самом конце описания. Поэтому поиск по артикулу становится обязательным.
Если специфика бизнеса требует поиска именно по полному наименованию, и оно длиннее 1024 символов, рассмотрим продвинутый метод — хеширование. Вместо сравнения самих строк, мы будем сравнивать их «отпечатки» (хеш-суммы) фиксированной длины.
Разберем логику:
ХешПолногоНаименования (Строка, 64 символа).Пример функции вычисления хеша (с использованием платформенных возможностей 8.3):
Функция ПолучитьХешСтроки(ВходнаяСтрока)
Хеширование = Новый ХешированиеДанных(АлгоритмХеширования.SHA256);
Хеширование.Добавить(ВходнаяСтрока);
Возврат НРег(СтрЗаменить(Строка(Хеширование.ХешСумма), " ", ""));
КонецФункции
Посмотрим на ситуацию шире. В современных конфигурациях типа УТ 11, ERP 2.5 или КА 2.5 поле НаименованиеПолное предназначено исключительно для вывода в печатные формы (УПД, счета-фактуры). Тексты со спецификациями, такие как «система MOLLE», «изотермический ампулярий» или «USB зона зарядки», должны храниться в специально отведенных местах:
Подводя итог нашему разбору, проанализируем последовательность действий для успешного перехода:
НаименованиеПолное в УТ 10.3.&, <, >, которые могут нарушать структуру XML-пакета.ПКО Номенклатура.Описание, оставив в полном наименовании только то, что действительно нужно для бухгалтерской первички.Соблюдение этих шагов позволит вам избежать ошибок СУБД и обеспечит корректную передачу данных в новую систему управления торговлей.