Обновление нетиповой конфигурации 1С 8

Инструкция по обновлению

1. Подготовка к обновлению

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

Первым делом раздаю 2 базы с начальной настройкой. Один, чтобы внести изменения, один, чтобы противостоять новому.

Если ваша конфигурация не является типовой, при нажатии кнопки «обновить» в конфигураторе система начнет сравнение основной конфигурации и новой конфигурации поставщика:

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

После фильтрации мы видим, что модифицированных объектов намного меньше:

У нас есть список вещей, над которыми мы будем работать. В нашем случае был только один сложный объект: документ KUDiR Record.

2. Перенос изменений обновления 1С

Для переноса изменений открываю 2 конфигуратора: в одном провожу сравнения и собираю изменения, а во втором вношу улучшения.

Следующим шагом является передача изменений напрямую. Рассмотрим основные приемы обновления нетипичных конфигураций.

3. Различия в модулях

Довольно простая операция, но очень важная: просто переносим модули из новой версии в старую. Если код закомментирован, проблем быть не должно:

Общая схема обновления

Рассмотрим ситуацию подробнее на примере любого свойства объекта метаданных. Возможны следующие варианты:

Таблица 1. Предопределенные правила обновления

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

Реализация в платформе «1С:Предприятие 8»

Общие понятия

В 1С: Предприятии 8 любая конфигурация может поддерживаться одной или несколькими другими конфигурациями, называемыми конфигурациями поставщика. Конфигурация, созданная с помощью команд «Конфигурация — Доставка конфигурации — Создать файл доставки» и «Обновления конфигурации», может использоваться в качестве конфигурации поставщика. Эта команда создает файл конфигурации (cfr). Файл, подготовленный командой «Конфигурация — Сохранить конфигурацию в файл», нельзя использовать в качестве конфигурации поставщика. Чтобы получить конфигурацию поставщика в виде файла информационной базы (1cd) или файла дампа информационной базы (dt), загрузите cf-файл, подготовленный, как указано выше, в требуемую информационную базу (возможно, пустую), выполнив команду Конфигурация — Загрузить конфигурацию из командного файла. Так что при необходимости вы можете создать файл dt с помощью стандартных инструментов.

Есть два способа получить поддержку по настройке поставщика. Первый — использовать конфигурацию, подготовленную, как описано выше (при необходимости, внести изменения). Фактически подготовленная конфигурация поставщика поддерживает конфигурацию, в которой она была создана. Аналогичный результат получается при использовании команд Конфигурация — Загрузить конфигурацию из файла и Администрирование — Загрузить информационную базу. Второй способ позволяет поддерживать уже созданную пользовательскую конфигурацию. Для этого нужно запустить команду Конфигурация — Сравнить, совместить с конфигурацией из файла. Если в качестве выбранного файла указан файл конфигурации поставщика, а конфигурация пользователя больше не поддерживается, рекомендуется получить поддержку после слияния.

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

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

Возьмем пример. Если целевая версия — «4» и обновление создается только для версии «2», невозможно будет выполнить обновление не только для версии «1», но и для версии «3». Это ограничение связано с возможностью «обратных» изменений. То есть представим, что при переходе на версию «3» провайдер увеличил длину строки в типе атрибута, а в версии «4» снова изменил ее. При подготовке обновления «2» — «4» это свойство не будет включено в файл (поскольку значения в этих версиях совпадают). Если вы разрешите использовать этот файл для обновления версии «3», у пользователя будет неправильная и более длинная строка. Файлы обновления конфигурации сохраняются до минимального размера не только за счет включения только необходимых объектов, но и за счет сжатия данных. Они оптимальны для предоставления пользователю обновлений по низкоскоростным каналам связи. Обратной стороной является описанная выше меньшая гибкость. С точки зрения дальнейшего процесса обновления использование файлов cf и cfu ничем не отличается.

Выполнение обновления

Если конфигурация пользователя находится на обслуживании и не может быть изменена, обновление является тривиальным и полностью автоматизированным процессом. Пользователь выполняет команду Configuration — Support — Update configuration и после получения подтверждения выполняется обновление. Рассмотрим второй случай, наиболее интересный. Пользователь включил возможность изменения. Обновление конфигурации выполняется с использованием стандартного механизма сравнения и слияния, но пользователю предоставляется существенная дополнительная услуга. В процессе сравнения участвуют не две, а три конфигурации: пользовательская конфигурация, старая конфигурация поставщика (она хранится в пользовательской конфигурации) и новая конфигурация поставщика, которая обновляется до. В этом случае система автоматически анализирует внесенные изменения и, согласно таблице 1, выстраивает правила объединения. Основная трудность — это вариант 2, когда и пользователь, и провайдер изменили одно и то же свойство. Как уже отмечалось, невозможно автоматически делать разумные предположения, но можно выделить эти случаи для пользователя. Все эти свойства выделены жирным шрифтом в дереве объединения. Кроме того, при настройке фильтра представления вы можете установить флажок Показывать только измененные свойства дважды, и в структуре объединения будут отображаться только те свойства, которые требуют ручной настройки правил объединения. После завершения слияния конфигурация поставщика, хранящаяся в пользовательской конфигурации, будет обновлена ​​до новой версии.

Модификация алгоритма обновления с помощью правил поддержки

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

• «Объект поставщика не редактируется» — пользователь не может редактировать объект поставщика. Основная цель этого правила будет описана ниже, но пользователь может настроить его для защиты от случайных изменений. Во время обновления эти объекты будут полностью заменены объектами провайдера новой версии.
• «Объект поставщика меняется при сохранении поддержки» — общее правило. В этом случае алгоритм комбинирования точно такой же, как описано.
• «Объект поставщика удален» — пользователь не хочет выполнять какие-либо дальнейшие обновления этого объекта. Чтобы удалить объект поставщика, вы должны сначала настроить это правило.

Вот расширенная версия Таблицы 1, в которой учтены поддерживающие правила.

Таблица 2. Предопределенные правила обновления на основе правил поддержки