Обновление сильно измененной (так называемой «подпиленной») конфигурации, такой как 1С:Управление производственным предприятием 1.3, всегда является ответственным и трудоемким процессом. В данной статье мы проанализируем оптимальный алгоритм действий, выясним, нужны ли промежуточные обновления, и разберем технические нюансы трехстороннего сравнения.
Для начала разберем главный вопрос: нужно ли сначала обновлять конфигурацию поставщика, а затем делать сравнение/объединение со своей основной конфигурацией? Ответ кроется в понимании того, как платформа 1С выполняет операцию Поддержка — Обновить конфигурацию.
Рассмотрим ситуацию подробнее. Когда мы запускаем штатное обновление, платформа одновременно анализирует три состояния системы:
Платформа автоматически вычисляет разницу между старым и новым поставщиком и накладывает только эти изменения на вашу основную конфигурацию. Если вы изменили какой-то объект, а поставщик его не трогал, система оставит вашу доработку в покое. Конфликт возникнет только в случае «дважды измененных объектов». Поэтому выполнять отдельную операцию по обновлению «только поставщика» перед основным объединением не требуется — это лишнее действие, так как всё происходит за один цикл обновления через поддержку.
Рассмотрим последовательность действий, которая минимизирует риск ошибок и потери данных:
Конфигурация — Поддержка — Обновить конфигурацию. Выберите файл обновления.В обсуждениях часто всплывает вопрос о том, можно ли просто подготовить эталонный cf на копии и загрузить его в рабочую базу через Загрузить конфигурацию из файла. Важно помнить: это сопряжено с огромными рисками.
Разберем причину: при загрузке cf платформа полностью заменяет структуру метаданных. Если в процессе подготовки файла на копии какой-то объект был удален и создан заново (пусть даже с тем же именем), его внутренний идентификатор (GUID) изменится. При загрузке такого файла в «прод» база данных не узнает объект, и данные в таблицах СУБД будут безвозвратно потеряны или станут «битыми ссылками».
Поэтому правильный путь для переноса обновлений на рабочую базу — это либо повторение процедуры через поддержку, либо (что чаще используется опытными администраторами) сравнение/объединение рабочей базы с заранее подготовленным эталонным cf.
Проанализируем специфику 1С:УПП 1.3. Поскольку эта конфигурация использует преимущественно обычные формы, процесс объединения кода модулей форм требует особой осторожности. В обычных формах визуальная часть и код тесно переплетены.
При объединении модулей обязательно используйте встроенный текстовый редактор сравнения. Вызовите его через кнопку Настройка в окне сравнения объектов. Проверьте, чтобы типовые процедуры (например, ПередЗаписью или ПриОткрытии) не затерли ваши вызовы. Если поставщик добавил в эти процедуры новые переменные или логику, вам придется аккуратно «вклеить» свой код в новый типовой код.
Еще один критический момент — составные типы данных. Рассмотрим пример:
// Пример: Добавление вашего типа в реквизит "ДокументОснование"
// Если в типовой конфигурации тип реквизита расширился,
// при автоматическом объединении ваш кастомный тип может "вылететь".
Выясним причину: если вы расширили составной тип реквизита (добавили туда свой документ), а 1С в новом релизе тоже изменила этот тип (добавила свой новый документ), платформа может предложить заменить ваш набор типов своим. Всегда проверяйте такие реквизиты вручную, чтобы ваши расширения типов сохранялись.
При обновлении УПП часто возникают проблемы с интеграциями. Рассмотрим, почему это происходит:
Состав у планов обмена после объединения.Удалить.... Если ваша доработка обращается к такому объекту, код перестанет работать. Просмотрите файл Update.txt, входящий в поставку, чтобы заранее знать о таких изменениях.После того как техническое объединение в конфигураторе завершено и база обновлена (нажата клавиша F7), наступает этап обновления данных. В УПП 1.3 за это отвечает обработка «Обновление информационной базы».
Посмотрим на этот процесс с точки зрения разработчика: типовые алгоритмы могут начать пересчитывать итоги, заполнять новые регистры или изменять данные в существующих. Если ваша логика учета сильно отличается от типовой, эти процедуры могут отработать некорректно. Рекомендуется сначала запустить этот процесс на копии и убедиться, что важные для вас данные (остатки, себестоимость) не изменились непредсказуемым образом.
Подводя итог, можно сказать, что ключ к успешному обновлению доработанной УПП — это отказ от лишних промежуточных действий в пользу грамотной настройки трехстороннего объединения и тщательный ручной контроль «дважды измененных» объектов.