Как выгрузить данные справочника из 1С:УТ в 1С:ERP порциями и решить проблемы с конвертацией?

← На главную

При переходе с конфигурации 1С:Управление торговлей (УТ) на 1С:ERP Управление предприятием часто возникает задача переноса больших объемов данных. Один из частых вопросов — как выгрузить данные справочника не целиком, а частями, например, по 10-15 тысяч записей, чтобы избежать перегрузки системы и ошибок. Рассмотрим различные подходы к решению этой проблемы, а также особенности переноса специфических справочников и контактной информации. Для выбора конкретного сценария миграции можно изучить раздел с готовыми решениями для переноса данных в ERP.

Определение стратегии переноса: разовый или постоянный обмен

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

Если задача состоит в разовом полном переносе с последующим постоянным обменом, мы сначала переносим все необходимые данные (обычно сначала справочники и НСИ, затем документы), а затем настраиваем механизмы синхронизации для дальнейших изменений.
Для постоянного обмена часто используются универсальные форматы, такие как XML (через УниверсальныйОбменДаннымиВФорматеXML) или JSON, а также планы обмена для регистрации изменений.

Использование планов обмена для порционной выгрузки данных

Один из наиболее распространенных и управляемых способов порционной выгрузки данных в 1С — это использование планов обмена. Этот механизм позволяет нам гибко управлять тем, какие данные и в каком объеме будут выгружены. Рассмотрим, как мы можем применить планы обмена для наших задач:

Регистрация изменений: В конфигурации-источнике (например, УТ) мы создаем или используем существующий план обмена. Мы регистрируем в нем те 10-15 тысяч записей справочника, которые нам нужно выгрузить. Это делается программно или вручную, если объем небольшой. Регистрация изменений гарантирует, что в следующем сеансе обмена будут переданы только необходимые, заранее определенные записи.
Выгрузка по узлам: Каждый узел плана обмена может быть настроен на выгрузку определенного набора данных. Мы можем создать временный узел или использовать существующий, чтобы сформировать сообщение обмена только с зарегистрированными записями.
Пакетная обработка: При очень больших объемах данных, когда выгрузка занимает длительное время (более суток или не доходит до конца), мы настоятельно рекомендуем разбивать данные на порции и использовать механизмы пакетной обработки. Планы обмена как раз хорошо подходят для этого, так как они оперируют порциями зарегистрированных изменений.

Для программной регистрации изменений в плане обмена мы можем использовать методы объекта ПланыОбменаМенеджер.<ИмяПланаОбмена>.ЗарегистрироватьИзменения() или работать непосредственно с таблицами регистрации изменений, если требуется более тонкий контроль.

Реализация порционной выгрузки через "Конвертацию данных" (КД2)

Автор вопроса упоминает, что просят использовать именно "Конвертацию данных" (КД2). Это мощный инструмент для описания правил конвертации между различными конфигурациями, но порционная выгрузка через него требует определенных усилий. В чистом виде "Конвертация данных" не имеет встроенного механизма "выгрузить 10000 записей, потом следующие 10000". Однако мы можем реализовать это, используя несколько подходов:

Параметризация правил выгрузки данных (ПВД): В КД2 мы можем писать код в событиях ПВД, таких как ПередВыгрузкой или ПриВыгрузке. Мы можем добавить в правила выгрузки параметры, которые будут ограничивать выборку данных. Например, мы можем передавать параметры "НачальныйИндекс" и "КоличествоЗаписей", чтобы получить данные порциями.

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ &КоличествоЗаписей
    |    Справочник.ЕдиницыИзмерения.Ссылка
    |ИЗ
    |    Справочник.ЕдиницыИзмерения КАК ЕдиницыИзмерения
    |ГДЕ
    |    ЕдиницыИзмерения.Ссылка > &ПоследняяВыгруженнаяСсылка
    |УПОРЯДОЧИТЬ ПО
    |    ЕдиницыИзмерения.Ссылка";
Запрос.УстановитьПараметр("КоличествоЗаписей", ПараметрыВыгрузки.КоличествоЗаписей);
Запрос.УстановитьПараметр("ПоследняяВыгруженнаяСсылка", ПараметрыВыгрузки.ПоследняяВыгруженнаяСсылка);
        
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    // Добавляем запись в список выгружаемых объектов
    ВыгрузитьОбъект(Выборка.Ссылка);
КонецЦикла;

Мы должны будем отслеживать ПоследняяВыгруженнаяСсылка между итерациями выгрузки.

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

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

Особенности переноса справочников "Единицы измерения" и "Упаковки"

Автор упоминает конкретные справочники: "Единицы измерения" и "УпаковкиИЕдиницыИзмерения", а также проблему их объединения. Это одна из наиболее "болезненных" областей при конвертации:

Различия в структурах: В 1С:ERP нет прямого аналога справочника "Единицы измерения" в том виде, как он представлен в УТ. Учет в ERP может быть настроен в единицах хранения, и для каждой номенклатурной позиции может быть указана единственная единица хранения. Также используются дополнительные единицы измерения и упаковки с коэффициентами пересчета.
Консолидация и сопоставление: Мы должны провести консолидацию данных. Это означает, что мы не просто переносим "как есть", а анализируем данные из УТ и сопоставляем их с концепциями ERP. Возможно, нам придется:
- Сделать вручную из классификатора: Некоторые единицы измерения и упаковки, особенно стандартные, целесообразно создать вручную в ERP, используя встроенные классификаторы, а затем настроить перенос таким образом, чтобы он не создавал новые, а использовал существующие.
- Написать перенос без создания новых: Для нестандартных единиц измерения и упаковок, которые не имеют прямых аналогов в ERP, мы можем разработать правила конвертации, которые будут привязывать их к существующим базовым единицам или использовать механизм дополнительных единиц измерения/упаковок с заданием коэффициентов пересчета.
- Объединение справочников: Как отмечает автор, мы можем объединять данные из "ЕдиницыИзмерения" и "УпаковкиИЕдиницыИзмерения". В КД2 это реализуется через ПВД, где мы в источнике формируем нужную выборку данных, объединяя информацию из разных справочников, и затем настраиваем правила для создания единого объекта в приемнике (например, записи в регистре сведений "ЕдиницыИзмеренияНоменклатуры" или соответствующих объектах в ERP).
Последствия ошибок: Неправильно выбранные и перенесенные единицы измерения могут привести к серьезным расхождениям остатков, некорректным расчетам и проблемам в учете, поэтому к этому справочнику нужно отнестись с особой тщательностью.

Альтернативный подход: Выгрузка/загрузка через JSON и HTTP-сервисы

Один из участников дискуссии предлагает не пользоваться "обычной конвертацией" и использовать JSON. Этот подход считается более современным и гибким, особенно для оперативных обменов или когда требуется высокая производительность и минимальный объем передаваемых данных. Рассмотрим его подробнее:

Преимущества JSON:
- Лаконичность: JSON-формат более компактен по сравнению с XML, что уменьшает объем передаваемых данных и ускоряет обмен.
- Простота обработки: В 1С есть встроенные механизмы для работы с JSON (ЧтениеJSON, ЗаписьJSON), что делает его удобным для программной обработки.
- Гибкость: Мы можем полностью контролировать структуру выгружаемых и загружаемых данных, формируя их в удобном для нас виде.

Реализация через JSON:

Мы можем разработать внешнюю обработку или HTTP-сервис в базе-источнике (УТ), который будет выгружать данные справочника порциями в формате JSON. Примерный алгоритм:

На стороне источника (УТ):


// Пример функции для получения порции данных справочника
Функция ПолучитьПорциюСправочника(ПоследнийИД, Количество)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ ПЕРВЫЕ &КоличествоЗаписей
        |    Справочник.ЕдиницыИзмерения.Ссылка КАК Ссылка,
        |    Справочник.ЕдиницыИзмерения.Наименование КАК Наименование,
        |    Справочник.ЕдиницыИзмерения.Код КАК Код
        |ИЗ
        |    Справочник.ЕдиницыИзмерения КАК ЕдиницыИзмерения
        |ГДЕ
        |    Справочник.ЕдиницыИзмерения.Ссылка > &ПоследнийИД
        |УПОРЯДОЧИТЬ ПО
        |    Справочник.ЕдиницыИзмерения.Ссылка";
    Запрос.УстановитьПараметр("КоличествоЗаписей", Количество);
    Запрос.УстановитьПараметр("ПоследнийИД", ПоследнийИД);
                    
    РезультатЗапроса = Запрос.Выполнить();
    Выборка = РезультатЗапроса.Выбрать();
                    
    МассивДанных = Новый Массив;
    Пока Выборка.Следующий() Цикл
        СтруктураДанных = Новый Структура;
        СтруктураДанных.Вставить("Ссылка", Строка(Выборка.Ссылка.УникальныйИдентификатор()));
        СтруктураДанных.Вставить("Наименование", Выборка.Наименование);
        СтруктураДанных.Вставить("Код", Выборка.Код);
        // Добавляем другие реквизиты
        МассивДанных.Добавить(СтруктураДанных);
        ПоследнийИД = Выборка.Ссылка;
    КонецЦикла;
                    
    Результат = Новый Структура;
    Результат.Вставить("Данные", МассивДанных);
    Результат.Вставить("ПоследнийИД", ПоследнийИД);
                    
    Возврат Результат;
КонецФункции
                
// Пример использования для записи в JSON
ПоследнийИД = Неопределено; // Начальное значение
Пока Истина Цикл
    Порция = ПолучитьПорциюСправочника(ПоследнийИД, 10000);
    Если Порция.Данные.Количество() = 0 Тогда
        Прервать;
    КонецЕсли;
                    
    // Запись порции в файл или отправка через HTTP
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Порция.Данные);
    ТекстJSON = ЗаписьJSON.Закрыть();
                    
    // Сохраняем ТекстJSON в файл или отправляем на HTTP-сервис ERP
    // ...
                    
    ПоследнийИД = Порция.ПоследнийИД;
КонецЦикла;

На стороне приемника (ERP):

Мы разрабатываем HTTP-сервис или внешнюю обработку, которая будет принимать JSON-данные, десериализовать их (ПрочитатьJSON()) и загружать в соответствующие справочники ERP. Здесь также можно реализовать логику сопоставления и консолидации, аналогичную той, что используется для "Единиц измерения" и "Упаковок".


// Пример функции для загрузки данных из JSON
Функция ЗагрузитьДанныеИзJSON(ТекстJSON)
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ТекстJSON);
                    
    МассивДанных = ПрочитатьJSON(ЧтениеJSON);
    ЧтениеJSON.Закрыть();
                    
    Для Каждого ДанныеЗаписи Из МассивДанных Цикл
        СсылкаИзERP = Справочники.ЕдиницыИзмерения.НайтиПоКоду(ДанныеЗаписи.Код); // Или по другому уникальному реквизиту
        Если СсылкаИзERP = Неопределено Тогда
            НовыйЭлемент = Справочники.ЕдиницыИзмерения.СоздатьЭлемент();
            НовыйЭлемент.Код = ДанныеЗаписи.Код;
            НовыйЭлемент.Наименование = ДанныеЗаписи.Наименование;
            // Заполняем другие реквизиты
            НовыйЭлемент.Записать();
        Иначе
            // Обновляем существующий элемент, если требуется
            СсылкаИзERP.Наименование = ДанныеЗаписи.Наименование;
            // Обновляем другие реквизиты
            СсылкаИзERP.Записать();
        КонецЕсли;
    КонецЦикла;
КонецФункции

Готовые решения: Некоторые разработчики предлагают готовые обработки для выгрузки/загрузки данных через JSON, например, упомянутая в обсуждении обработка ВыгрузкаЗагрузкаJSON_1.2.2.epf или аналогичные решения на Infostart. Мы можем использовать их как основу, дорабатывая под наши специфические требования.

Важно: Несмотря на свою гибкость, JSON-обмен требует более глубокого понимания программной разработки и может быть сложнее в реализации для тех, кто привык к декларативным правилам КД.

Перенос контактной информации

Автор также упоминает проблемы с переносом контактной информации. Это распространенная задача, требующая внимательного подхода:

Структура хранения: В 1С контактная информация часто хранится в отдельном регистре сведений (КонтактнаяИнформация), который связан с различными объектами (справочники "Организации", "Контрагенты", "ФизическиеЛица" и т.д.) через уникальный идентификатор владельца.
Правила переноса: В КД2 мы должны настроить ПВД для переноса записей из регистра сведений "КонтактнаяИнформация" источника в регистр сведений "КонтактнаяИнформация" приемника. Ключевым моментом является правильное сопоставление владельцев контактной информации. Мы должны сначала перенести самих владельцев (например, контрагентов), а затем при переносе контактной информации находить их новые ссылки в ERP.
Проверка качества данных: Обязательно проверяйте качество перенесенной контактной информации. Часто встречаются пустые или некорректно заполненные поля. Мы должны предусмотреть логику очистки или исправления таких данных при переносе.
Адресный классификатор: Если речь идет об адресах, мы также должны позаботиться о переносе и актуализации адресного классификатора в ERP, так как корректное отображение адресов зависит от него.

Общие рекомендации при переносе данных

Независимо от выбранного метода, мы должны учитывать несколько общих рекомендаций:

Тестовый перенос: Критически важно выполнить несколько тестовых переносов на копиях баз. Это позволит нам выявить ошибки в правилах конвертации, проверить корректность движений по регистрам и убедиться в правильности отчетов. Для выявления ошибок после миграции можно автоматически сравнить проводки между базами через COM-соединение.
Актуальные версии: Убедитесь, что релизы выгружаемой и загружаемой баз совместимы. Зачастую, для успешного обмена требуется, чтобы они были близки или даже идентичны.
Префиксы нумерации: Для корректного обмена данными и во избежание конфликтов нумерации, установите префиксы нумерации документов и справочников в обеих конфигурациях.
Использование внешних обработок: Для переноса справочников между разными конфигурациями мы можем использовать универсальные обработки, которые позволяют сопоставить реквизиты справочников без написания сложных правил в КД. Например, при точечной миграции можно сопоставлять объекты по произвольным полям поиска без создания сложных правил.
Отказ от COM: Хотя автор и упоминает использование COM, нам следует постепенно отходить от этого устаревшего механизма в пользу более современных и безопасных решений, таких как HTTP-сервисы и JSON.

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