Переход с устаревшей редакции 1.4 конфигурации «1С:Управляющий ПРОФ» (построенной на обычных формах) на современную редакцию 2.0 (работающую на управляемом приложении) — это не просто рядовое обновление, а глобальная техническая реструктуризация всей информационной системы. В процессе такого перехода разработчики часто сталкиваются с критическими ошибками платформы и механизмов интеграции.
В этой статье мы подробно разберем, как победить две самые популярные проблемы этого перехода: ошибку реструктуризации базы данных «Имеются записи с одинаковыми измерениями» и сбой загрузки XML-данных с ошибкой «Дублирующееся имя поля». Мы детально проанализируем причины их возникновения и по шагам пройдем весь процесс корректного обновления.
---
При обновлении конфигурации через Конфигуратор на этапе реструктуризации таблиц базы данных платформа 1С может выдать ошибку, сообщающую о наличии записей с одинаковыми измерениями. Это происходит из-за того, что в новой редакции 2.0 у некоторых регистров (сведений или накопления) меняется состав ключевых полей (измерений). Платформа пытается перестроить уникальный индекс в СУБД (MS SQL, PostgreSQL или файловой таблице 1CD), но натыкается на дублирующиеся строки, которые по новым правилам уникальности совпадают. СУБД блокирует создание индекса, и процесс обновления прерывается.
Рассмотрим подробнее, как локализовать и устранить эту проблему без ручной монотонной чистки каждого регистра по отдельности.
Шаг 1. Локализация дублирующихся записей через группировочный запрос
Вместо того чтобы наугад чистить регистры в режиме «1С:Предприятие», мы напишем и запустим в консоли запросов универсальный группировочный запрос к проблемному регистру. Наша задача — сгруппировать данные по тем измерениям, которые станут ключевыми в новой редакции, и отобрать строки, где количество записей превышает единицу.
Посмотрим на пример такого запроса для условного регистра сведений:
ВЫБРАТЬ
ПроблемныйРегистр.ИзмерениеОдин КАК ИзмерениеОдин,
ПроблемныйРегистр.ИзмерениеДва КАК ИзмерениеДва,
КОЛИЧЕСТВО(1) КАК КоличествоЗаписей
ИЗ
РегистрСведений.ИмяВашегоРегистра КАК ПроблемныйРегистр
СГРУППИРОВАТЬ ПО
ПроблемныйРегистр.ИзмерениеОдин,
ПроблемныйРегистр.ИзмерениеДва
ИМЕЮЩИЕ
КОЛИЧЕСТВО(1) > 1
Этот запрос вернет нам точный список «проблемных» комбинаций измерений. Мы сможем точечно удалить дублирующие записи или выполнить их логическое слияние.
Шаг 2. Проведение Тестирования и исправления (ТиИ)
Очень часто скрытые дубли возникают из-за наличия «битых» или пустых ссылок в измерениях (так называемый объект Объект не найден...). Перед обновлением обязательно запустим процедуру тестирования и исправления информационной базы:
Эта операция автоматически очистит некорректные записи регистра, которые ссылались на несуществующие элементы справочников или документов, избавив нас от технического «мусора» перед реструктуризацией.
Шаг 3. Полная очистка технических регистров
Выясним причину: если ошибка возникает в служебных регистрах (например, история версий объектов, замеры времени, кэш программных интерфейсов или адресный классификатор), нет никакого смысла тратить время на их выборочное исправление. Мы можем полностью очистить эти таблицы программно в режиме «1С:Предприятие» перед началом обновления. При первом запуске новой редакции 2.0 система автоматически инициализирует эти регистры и заполнит их корректными актуальными данными.
---
Если для переноса данных из 1.4 в 2.0 мы решили использовать правила, созданные в конфигурации «1С:Конвертация данных 2» (КД 2), то при загрузке полученного XML-файла в базу-приемник мы можем столкнуться со следующей ошибкой: Дублирующееся имя поля "ИмяПоля" (например, с кодом валюты 643 или иным реквизитом).
Разберем по шагам причину этой ошибки и способ ее исправления в правилах обмена:
ДоговорыКонтрагентов или документ ПоступлениеТоваровУслуг).---
Поскольку редакция 2.0 программы «1С:Управляющий» радикально отличается от редакции 1.4 по внутренней архитектуре метаданных и использует абсолютно другую концепцию интерфейса (управляемые формы вместо обычных), стандартное обновление методом «сравнить и объединить» или последовательным накатыванием файлов обновлений (.cfu) на работающую базу часто приводит к логическому разрушению базы данных.
Разработчики решения (компания «РУ-СИСТЕМС») настоятельно рекомендуют осуществлять переход по схеме «выгрузка данных в чистую базу» с использованием официального дистрибутива:
Разберем по шагам правильную последовательность действий:
AppData\Roaming\1C\1Cv8\tmplts\) найдем подкаталог с установленной версией 2.0. В нем будет содержаться специализированная папка для перехода с предыдущих версий. Там лежат готовые, протестированные разработчиками правила конвертации данных (файл правил) и необходимые внешние обработки выгрузки/загрузки.ВыгрузкаДанных.epf или универсальный выгрузчик, адаптированный под правила перехода).Именно такой подход гарантирует, что структура метаданных новой базы не пострадает от конфликтов старых объектов, а все типы данных будут корректно преобразованы под требования управляемого приложения платформы 8.3.
---
Если в вашей конфигурации 1.4 нет доработок (она полностью типовая), но вы хотите выполнить именно обновление базы, а не выгрузку/загрузку данных, воспользуемся обходным профессиональным приемом с использованием промежуточной базы:
.cf) поставщика версии 1.4.13..cfu или полные конфигурации поставщика .cf)..cf-файл версии 2.0.2)..cf-файл через режим «Сравнить, объединить с конфигурацией из файла» или «Загрузить конфигурацию из файла» (если в базе абсолютно точно нет кастомных доработок).Этот метод позволяет обойти ошибки реструктуризации, связанные с промежуточными изменениями метаданных в конфигурации, предоставляя платформе сразу финальную корректную структуру таблиц новой редакции.