Переход со старых версий конфигураций, таких как УПП, на современные решения, например БП 3.0, часто ставит перед разработчиками задачу по корректному переносу данных. Одной из самых сложных областей является контактная информация (КИ). В современных конфигурациях 1С логика хранения КИ претерпела значительные изменения: вместо набора отдельных полей в регистрах сведений теперь используется унифицированный формат хранения, основанный на JSON или XML.
В старых конфигурациях, таких как УПП 1.2, контактная информация часто хранилась в регистрах сведений в виде «плоских» данных (отдельные колонки для индекса, города, улицы и т.д.). В БП 3.0, построенной на базе БСП (Библиотека Стандартных Подсистем), данные КИ сериализуются в одну строку формата JSON. Это сделано для обеспечения гибкости, унификации работы с классификаторами и корректной интеграции с ФИАС/ГАР.
Попытки вручную сформировать JSON-строку при переносе через КД 2.0 часто приводят к ошибкам валидации, потере представлений или некорректному отображению адресов в интерфейсе. Рассмотрим, как решить эту задачу правильно.
Самый эффективный способ разобраться в том, как именно БП 3.0 ожидает получить данные — это проанализировать работу типовых правил обмена. Если вы планируете перенос данных, выполните следующие шаги:
УТ 10.3 или другие отраслевые решения).MD83Exp для получения md-файла структуры конфигурации.Конвертацию данных 2.0. Это позволит вам увидеть структуру объектов, регистров и правил, разработанных вендором.Анализ типовых правил позволит увидеть, как именно заполняются поля контактной информации в обработчиках ПослеЗагрузки или ПередЗаписью. Не пытайтесь изобретать велосипед: разработчики 1С уже создали методы для корректной записи данных.
Когда вы поймете структуру, приступайте к реализации алгоритма в КД 2.0. Основной совет — используйте встроенные модули конфигурации БП 3.0, которые отвечают за управление КИ. В частности, обратите внимание на модуль УправлениеКонтактнойИнформацией.
Рассмотрим, почему важно не писать данные напрямую в регистры:
ФИАС.Если вы пишете код в правилах обмена, старайтесь использовать следующий подход:
// Примерный алгоритм действий в обработчике "ПослеЗагрузки"
// 1. Собираем данные из источника
// 2. Формируем структуру данных в формате, ожидаемом БП 3.0
// 3. Вызываем методы БСП для записи данных
// Важно использовать менеджеры контактной информации, чтобы не нарушить целостность
При переносе важно учитывать следующие моменты:
Валидация адресов: Система БП 3.0 очень чувствительна к качеству данных. Если адрес, пришедший из УПП, не проходит проверку, он может быть помечен как «неактуальный». Убедитесь, что вы передаете данные в том виде, который ожидает БСП, чтобы избежать ручной правки тысяч адресов после миграции.
Отказ от ручного формирования строк: Никогда не пытайтесь «склеивать» строки JSON вручную через СтрЗаменить или конкатенацию. Используйте возможности платформы для сериализации объектов. Это гарантирует, что спецсимволы будут корректно экранированы, а структура JSON останется валидной.
Использование модулей приемника: В БП 3.0 существует множество функций в модуле КонтактнаяИнформацияКлиентСервер. Изучите эти функции — они значительно облегчат вашу задачу, предоставляя готовые методы для манипуляции данными КИ.
Соблюдая этот алгоритм — анализ типовых правил, использование встроенных модулей БСП и отказ от «хардкода» в пользу объектного подхода — вы сможете успешно перенести контактную информацию в новую систему без потери качества данных.