← На главную

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

Такая ситуация означает, что ранее в типовой конфигурации этого реквизита не было, и разработчики расширения добавили его "с нуля". Теперь, когда в новой версии типовой конфигурации (в нашем случае УТ 11.5.8.410) появился реквизит с аналогичным именем, возникает конфликт, поскольку платформа не может однозначно определить, какой из объектов следует использовать.

Предварительный анализ ситуации и подготовка к решению

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

1. Создание резервной копии: В первую очередь, создайте полную и актуальную резервную копию вашей информационной базы. Это ваш "спасательный круг" на случай непредвиденных проблем.
2. Развертывание копии базы: Разверните созданную копию на тестовом сервере или локальном компьютере. Все последующие шаги будут выполняться именно в этой тестовой базе.
3. Анализ текущего состояния реквизита в расширении: Нам нужно понять, используются ли данные в конфликтном реквизите ЗаказПоставщику.Товары.ДатаОтгрузки, который находится в расширении. Для этого мы можем воспользоваться консолью запросов или написать небольшую обработку.

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

Скопировать код

ВЫБРАТЬ
    ДокЗаказПоставщикуТовары.Ссылка.Ссылка КАК СсылкаНаДокумент,
    ДокЗаказПоставщикуТовары.НомерСтроки КАК НомерСтроки,
    ДокЗаказПоставщикуТовары.ДатаОтгрузки КАК ДатаОтгрузкиРасширения
ИЗ
    Документ.ЗаказПоставщику.Товары КАК ДокЗаказПоставщикуТовары
ГДЕ
    ДокЗаказПоставщикуТовары.ДатаОтгрузки ЕСТЬ НЕ NULL

Если запрос возвращает строки, значит, данные в реквизите есть, и их необходимо будет перенести. Зафиксируйте эти данные, возможно, выгрузите их в таблицу или текстовый файл для дальнейшего сравнения.

4. Определение версии типовой конфигурации: Убедимся, что мы точно знаем текущую версию УТ и целевую версию (в нашем случае 11.5.8.410). Это поможет при дальнейших действиях.

Пошаговое устранение конфликта и миграция данных

Теперь, когда мы провели подготовку и анализ, приступим к решению проблемы. Наш основной план будет состоять в том, чтобы временно переименовать реквизит в расширении, обновить типовую конфигурацию, заимствовать новый типовой реквизит и затем перенести в него данные.

Шаг 1: Переименование реквизита в расширении

Начнем с модификации расширения, чтобы устранить непосредственный конфликт имен до обновления основной конфигурации.

1. Откройте расширение в конфигураторе: Перейдите в конфигуратор тестовой базы, откройте конфигурацию и через меню "Конфигурация" -> "Расширения конфигурации" найдите и откройте ваше расширение.
2. Найдите и переименуйте конфликтный реквизит: В дереве объектов расширения найдите документ ЗаказПоставщику. В нем найдите табличную часть Товары. Внутри этой табличной части вы увидите реквизит ДатаОтгрузки, который был добавлен расширением (он не будет иметь значка заимствования, обозначающего что он свой, а не типовой). Переименуйте его, например, в удДатаОтгрузки (сокращение от "устаревшая ДатаОтгрузки") или Расш_ДатаОтгрузки. Главное, чтобы новое имя было уникальным и не пересекалось с типовыми объектами.
3. Обновите конфигурацию базы данных для расширения: После переименования сохраните изменения в расширении (кнопка "Сохранить конфигурацию" или F7) и обновите конфигурацию базы данных. На этом этапе обновляется только расширение, основная конфигурация остается без изменений.
4. Проверьте работоспособность: Запустите 1С в режиме предприятия и убедитесь, что система запускается, а основные функции, связанные с документом "ЗаказПоставщику" и его табличной частью "Товары", продолжают работать. Если данные в удДатаОтгрузки были, они должны быть доступны.

Шаг 2: Обновление типовой конфигурации

После успешного переименования реквизита в расширении, мы можем приступить к обновлению основной конфигурации.

1. Выполните обновление: Обновите типовую конфигурацию "Управление торговлей" до целевой версии (11.5.8.410). Этот процесс обычно выполняется через меню "Конфигурация" -> "Поддержка" -> "Обновить конфигурацию".
2. Примените изменения: После завершения обновления конфигурации, обновите конфигурацию базы данных.
3. Убедитесь в появлении нового реквизита: После обновления, если открыть конфигурацию основной поставки, вы должны увидеть, что в документе ЗаказПоставщику, в табличной части Товары, теперь присутствует реквизит ДатаОтгрузки. Это тот самый типовой реквизит, который вызвал конфликт.

Шаг 3: Заимствование типового реквизита в расширение

Теперь, когда новый типовой реквизит существует, нам нужно, чтобы расширение работало именно с ним, а не с его устаревшей версией.

1. Откройте расширение: Снова откройте ваше расширение в конфигураторе.
2. Заимствуйте типовой реквизит: Найдите документ ЗаказПоставщику в основной конфигурации (не в расширении). Перетащите его в расширение или используйте контекстное меню для заимствования. Если документ ЗаказПоставщику уже заимствован, перейдите к его табличной части Товары. Найдите типовой реквизит ДатаОтгрузки и заимствуйте его. После заимствования, этот реквизит в расширении будет отмечен специальным значком, указывающим на его заимствованность.
3. Обновите конфигурацию базы данных для расширения: Сохраните изменения в расширении и обновите конфигурацию базы данных.

Шаг 4: Миграция данных из старого реквизита в новый

Это самый ответственный шаг, если у вас были данные в реквизите удДатаОтгрузки. Нам нужно перенести их в новый типовой реквизит ДатаОтгрузки, при этом не создавая лишних записей в журналах регистрации изменений для обмена данными.

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

Предположим, что вы переименовали реквизит в расширении на удДатаОтгрузки, а новый типовой реквизит называется ДатаОтгрузки.

Скопировать код
Запрос = Новый Запрос;
Запрос.Текст =
    "ВЫБРАТЬ
    |    ЗаказПоставщикуТовары.Ссылка.Ссылка КАК СсылкаНаДокумент,
    |    ЗаказПоставщикуТовары.НомерСтроки КАК НомерСтроки,
    |    ЗаказПоставщикуТовары.удДатаОтгрузки КАК УстаревшаяДатаОтгрузки
    |ИЗ
    |    Документ.ЗаказПоставщику.Товары КАК ЗаказПоставщикуТовары
    |ГДЕ
    |    ЗаказПоставщикуТовары.удДатаОтгрузки ЕСТЬ НЕ NULL"; // Выбираем только те строки, где устаревшая дата заполнена

Выборка = Запрос.Выполнить().Выбрать();

НачалоТранзакции(); // Опционально: можно выполнять в транзакции для атомарности

Пока Выборка.Следующий() Цикл
    Попытка
        ДокументОбъект = Выборка.СсылкаНаДокумент.ПолучитьОбъект();
        Если ДокументОбъект = Неопределено Тогда
            Сообщить("Внимание: Не удалось получить объект документа по ссылке " + Выборка.СсылкаНаДокумент + ". Пропускаем.");
            Продолжить;
        КонецЕсли;

        // Устанавливаем флаги для предотвращения регистрации изменений и блокировки обмена
        // Это критически важно, чтобы запись не вызвала регистрацию для обмена с другими базами (например, с Бухгалтерией)
        ДокументОбъект.ДополнительныеСвойства.Вставить("ОтключитьМеханизмРегистрацииОбъектов", Истина);
        ДокументОбъект.ОбменДанными.Загрузка = Истина;

        // Ищем нужную строку табличной части
        НайденаСтрока = Ложь;
        Для Каждого СтрокаТабличнойЧасти Из ДокументОбъект.Товары Цикл
            Если СтрокаТабличнойЧасти.НомерСтроки = Выборка.НомерСтроки Тогда
                СтрокаТабличнойЧасти.ДатаОтгрузки = Выборка.УстаревшаяДатаОтгрузки; // Переносим данные
                НайденаСтрока = Истина;
                Прервать;
            КонецЕсли;
        КонецЦикла;

        Если НайденаСтрока Тогда
            // Записываем документ без регистрации изменений
            ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
            Сообщить("Данные по документу " + ДокументОбъект.Ссылка + " строка " + Выборка.НомерСтроки + " успешно перенесены.");
        Иначе
            Сообщить("Внимание: Строка " + Выборка.НомерСтроки + " не найдена в документе " + ДокументОбъект.Ссылка + ". Данные не перенесены.");
        КонецЕсли;

    Исключение Э
        Сообщить("Ошибка при переносе данных для документа " + Выборка.СсылкаНаДокумент + ": " + Э.Описание);
    КонецПопытки;
КонецЦикла;

// Опционально: Если использовалась транзакция, необходимо либо ЗафиксироватьТранзакцию(), либо ОтменитьТранзакцию()
// ЗафиксироватьТранзакцию();
Сообщить("Процесс переноса данных завершен.");
Показать весь код

Объясним использованные методы:

• ДокументОбъект.ДополнительныеСвойства.Вставить("ОтключитьМеханизмРегистрацииОбъектов", Истина);: Эта строка указывает платформе, что изменения, сделанные в данном объекте, не должны быть зарегистрированы для обмена данными. Это полезно, когда мы делаем технические изменения и не хотим, чтобы они ушли в другие связанные базы (например, в 1С:Бухгалтерию).
• ДокументОбъект.ОбменДанными.Загрузка = Истина;: Этот флаг обычно устанавливается при загрузке данных извне. Он также предотвращает выполнение некоторых проверок и регистраций, предполагая, что данные приходят из доверенного источника (в нашем случае, мы сами переносим их внутри одной базы).
• ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);: Документ записывается с указанным режимом.

Эти флаги критически важны для корректного переноса данных без нежелательных побочных эффектов, таких как отправка документов в обмен, которые фактически не менялись в бизнес-логике.

Шаг 5: Проверка и окончательная очистка

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

1. Проверка данных: Запустите 1С в режиме предприятия. Откройте несколько документов "ЗаказПоставщику" и убедитесь, что в табличной части "Товары" реквизит ДатаОтгрузки теперь содержит правильные значения, которые были перенесены из старого реквизита. Вы можете также повторно выполнить запрос из Шага 1, но уже для нового реквизита, чтобы убедиться в его заполнении.
2. Проверка использования устаревшего реквизита: В конфигураторе, используя поиск ссылок (Ctrl+Shift+F), проверьте, нет ли где-либо в коде или формах расширения ссылок на реквизит удДатаОтгрузки. Если вы найдете такие ссылки, их необходимо будет скорректировать, чтобы они использовали новый типовой реквизит ДатаОтгрузки.
3. Удаление устаревшего реквизита: Если вы уверены, что реквизит удДатаОтгрузки больше нигде не используется и все данные успешно перенесены, вы можете удалить его из расширения. Это поможет поддерживать чистоту кода и структуры данных. Не забудьте обновить конфигурацию базы данных после удаления.
4. Полное тестирование: Проведите комплексное функциональное тестирование всех бизнес-процессов, связанных с документами "ЗаказПоставщику", его формами, отчетами и обменом данными. Убедитесь, что все работает стабильно и корректно.

Рекомендации по предотвращению подобных ситуаций в будущем

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

1. Использование префиксов для собственных объектов: Всегда используйте уникальные префиксы (например, "уд", "расш", "мой_") для всех объектов (реквизитов, справочников, документов), которые вы создаете непосредственно в расширении и которые не заимствованы из основной конфигурации. Это значительно снижает риск конфликта имен с новыми объектами, которые могут появиться в будущих версиях типовой конфигурации.
2. Правильное заимствование объектов: Если вы планируете изменить или добавить функционал к уже существующему объекту типовой конфигурации (например, добавить реквизит в существующую табличную часть документа), всегда сначала "заимствуйте" этот объект в расширение. Заимствованные объекты помечаются специальным значком, что наглядно показывает, что это доработка типового объекта.
3. Анализ изменений типовой конфигурации: Перед каждым крупным обновлением типовой конфигурации внимательно изучайте список изменений и новых возможностей, предоставляемый разработчиком (например, на ИТС). Это позволит заранее выявить потенциальные конфликты и спланировать адаптацию расширений.
4. Режим совместимости: Убедитесь, что режим совместимости для основной конфигурации и всех расширений установлен корректно и, при возможности, является одинаковым. Несоответствие режимов совместимости может вызывать различные необъяснимые ошибки.
5. Обновление расширений форм: Если ваше расширение дорабатывает формы типовых документов, после обновления типовой конфигурации может потребоваться обновить эти формы в расширении. Это делается через контекстное меню формы в расширении, чтобы "подтянуть" изменения из типовой формы, а затем повторно применить ваши доработки.
6. Осознанная работа с данными: Помните, что удаление расширения, содержащего собственные структуры данных, приведет к безвозвратной потере этих данных. Отключение расширения сохраняет структуры данных, позволяя его активировать позже. Всегда продумывайте стратегии сохранения и миграции данных при любых существенных изменениях структуры.

Следуя этим рекомендациям и выполняя предложенные шаги, мы сможем эффективно устранить конфликты при обновлении конфигураций 1С с расширениями, обеспечив стабильную работу системы и целостность данных.