← На главную

В процессе обновления доработанной конфигурации 1С разработчики часто сталкиваются с ситуацией, когда в типовой конфигурации поставщика появляются новые реквизиты, имена которых полностью совпадают с ранее созданными пользовательскими реквизитами. Разберем подробнее механики платформы 1С:Предприятие, риски потери данных при объединении и корректный алгоритм действий в подобном случае.

Почему возникает конфликт при объединении реквизитов

Сформулируем ключевую особенность платформы: при сопоставлении объектов метаданных платформа 1С:Предприятие опирается не на их идентификаторы-имена, а на их уникальные внутренние идентификаторы — UUID. Даже если реквизит в основной конфигурации и реквизит в конфигурации поставщика имеют абсолютно одинаковые имена и типы данных, для платформы это два разнесенных и независимых объекта.

Если на этапе сравнения и объединения конфигураций просто снять флаг со своего реквизита и задействовать реквизит поставщика, платформа выполнит реструктуризацию СУБД. В базе данных произойдет физическое удаление колонки вашего реквизита (вместе со всеми накопленными в рабочей базе значениями) и создание новой пустой колонки для объекта поставщика.

Анализ логики работы и назначения данных

Прежде чем принимать решение по объединению, проанализируем ситуацию по нескольким параметрам:

1. Назначение полей: содержат ли реквизиты идентичные бизнес-данные или названия совпали случайно, а смысловая нагрузка у них разная?
2. Программный код: какая логика завязана на пользовательский реквизит? Проверим подписки на события, модули объектов, печатные формы, отчеты и алгоритмы заполнения. Разработчики типового решения могли добавить свою логику заполнения нового реквизита поставщика.
3. Типы данных и формат: совпадают ли типы, состав составных типов, длина строк или точность чисел? При ручном сопоставлении реквизитов с несоответствующими типами во время реструктуризации СУБД значения также могут быть очищены или усечены.

Безопасный алгоритм переноса данных

Рассмотрим пошаговый порядок действий для сохранения введенных пользователями данных при переводе системы на реквизит поставщика:

1. Сохранение реквизитов на этапе объединения: В окне сравнения и объединения конфигураций сохраним свой пользовательский реквизит (при необходимости временно переименуем его в конфигурации, чтобы исключить физический конфликт имен) и добавим реквизит поставщика как новый объект метаданных.
2. Применение изменений к базе данных: Выполним обновление конфигурации базы данных. В СУБД создастся новая колонка реквизита поставщика, а старая колонка с пользовательскими данными сохранится без изменений.
3. Перенос накопленных данных: Напишем обработчик обновления информационной базы или воспользуемся стандартной обработкой (например, групповым изменением реквизитов), чтобы скопировать данные из старого реквизита в новый.
4. Корректировка программного кода: Перепишем доработанную логику (запросы, модули, формы) на работу с новым реквизитом поставщика.
5. Удаление устаревшего объекта: После проверки корректности переноса данных и работы бизнес-логики удалим старый пользовательский реквизит на следующем этапе обслуживания информационной базы.

Как предотвратить проблему в будущих доработках

Проанализируем архитектурные подходы, которые позволяют избежать подобных проблем при последующих обновлениях типовых решений:

1. Использование префиксов в именах объектов
При добавлении собственных реквизитов непосредственно в конфигурацию обязательно задавайте им уникальный префикс компании или проекта (например, сфт_ДатаОтгрузки). Это существенно снижает вероятность совпадения имен с новыми объектами от разработчиков 1С.

2. Использование расширений конфигурации
Наиболее технологичным решением является заимствование объекта в расширение и добавление собственных реквизитов внутри него. Реквизиты расширений хранятся в отдельных таблицах СУБД, что полностью исключает пересечение по UUID и именам с тиражным решением поставщика.

3. Механизм дополнительных реквизитов и сведений (БСП)
Если конфигурация построена на базе Библиотеки Стандартных Подсистем (БСП), добавление новых полей через пользовательский режим в состав дополнительных реквизитов исключает необходимость изменения структуры метаданных и риски при обновлении.