Некоторые организации по ряду причин остаются на одном релизе так долго, как это возможно — пока позволяет фирма «1С» и законодательство. «Оттягивание» процесса обновления приводит к тому, что появляется большой разрыв в версиях между рабочей конфигурацией и целевым релизом.
Промежуточные конфигурации 1С — это конфигурации, разработанные на основе типовых ключевых релизов, и предназначенные для корректного обновления информационной базы до целевого релиза.
Не всегда рабочую конфигурацию можно сразу обновить на целевую, пропустив несколько релизов. Между релизами добавляются новые объекты, меняется структура объектов, удаляются устаревшие объекты. В обработчиках обновления реализуется логика преобразования и заполнения информацией таких объектов.
Пропуск подобных релизов может привести к нарушению или потере данных. Работа в такой базе будет приводить к ошибкам, остатки в регистрах будут некорректные, новые объекты останутся пустыми, а объекты с данными могут быть удалены.
Однако не обязательно устанавливать все обновления в таком порядке, как это указано на сайте releases.1c.ru. Можно обновить последовательно только на ключевые релизы, без которых не будет корректной работы обновления.
Есть несколько способов узнать, какие релизы при обновлении конфигурации 1С точно нельзя пропускать.
Способ №1: поиск информации о промежуточных конфигурациях на releases.1c.ru
Самый простой способ для большинства случаев. Для примера возьмем «1С:ERP 2.5». На странице продукта можно найти порядок обновления.
Информация о релизах обновления для 1С:ERP 2.4 и выше
Однако этой информации будет недостаточно, если нужно обновить базу с «1С:ERP 2.2». В таком случае можно воспользоваться таблицей «Обновления» ниже, где для каждого релиза указы версии, с которых можно совершить «прыжок». На скриншоте показан пример, как с последней версии 2.2 можно перейти на 2.4.7, минуя 2.4.3, 2.4.4, 2.4.5, 2.4.6.
Фрагмент таблицы обновлений «1С:ERP» для релиза 2.2.4.227
Также информация по обновлению может храниться в файле ReadMe.txt, приложенному к каждому комплекту поставки.
Фрагмент ReadMe.txt для «1С:Бухгалтерия Предприятия»
Способ №2: подбор промежуточных конфигураций при помощи оценки версий библиотек
Косвенно сделать вывод о необходимости промежуточных конфигураций можно после анализа версий библиотек. Это особенно актуально для таких сложных конфигураций как, например, «1С: ERP. Управление холдингом».
Для сравнения нужен файл «Версии библиотек» из комплекта поставки конфигураций исходной и целевой версии. Например, если вопрос стоит так: «можно ли обновить «1С: ERP.УХ» с версии 3.1.5.7 на версию 3.2.7.9 без промежуточных?», то ответ будет «Нет», так как в составе «1С:ERP.УХ 3.1.5.7» — «1С:ERP 2.5.7.226», а в составе «1С:ERP.УХ 3.2.7.9» — «1С:ERP 2.5.21.111».
Пример содержимого файла «Версии библиотек» для «1С: ERP. Управление холдингом»
Согласно информации с releases.1c.ru «1С:ERP» нужно обновлять последовательно с 2.5.7 на 2.5.8, затем на 2.5.12, затем на 2.5.17 и только потом на актуальный релиз 2.5.21.
Следовательно, релизы «1С:ERP.УХ» нужно подобрать таким образом, чтобы чтобы произошло последовательное обновление ERP: 3.1.5.7 → 3.1.12.25 → 3.1.13.24 → 3.2.7.9.
Способ №3: оценка сравнения конфигураций исходной и целевой версии
Способ исключительно для разработчиков — придется анализировать код и структуры данных.
Для начала нужно сравнить конфигурации поставщика исходного и целевого релизов (конфигурации без доработок) по идентификаторам объектов.
Если между исходным и целевым релизами удалены значимые объекты (документы, регистры), и нет ни одного обработчика обновления, который бы перенес данные из удаляемого объекта в новый, то без промежуточных обновлять на этот релиз нельзя. Нужно обязательно найти релиз, в котором есть обработчик обновления (или найти информацию на its.1c.ru о том, что данные из этого объекта больше никогда не понадобятся).
Пример на скриншоте ниже: слева «1С:ERP 2.5.8», справа 2.5.17. В сравнении видно, что удален регистр накопления «Распределение запасов движения» (именно удален, а не переименован в «УдалитьРаспределениеЗапасовДвижения»).
Сравнение «1С:ERP» 2.5.8 и 2.5.17
При последовательном обновлении на релизы в порядке 2.5.8 → 2.5.12 → 2.5.17 данные из регистра накопления «Распределение запасов движения» должны быть перенесены в регистр накопления «Запасы и потребности», но если совершить «прыжок» с 2.5.8 на 2.5.17, минуя 2.5.12, в котором есть нужный обработчик, то данные из регистра накопления «Распределение запасов движения» будут безвозвратно удалены, а регистр накопления «Запасы и потребности» останется незаполненным.
Проверить, все ли нужные обработчики обновления присутствуют в целевом релизе можно в сравнении текстов общих модулей исходного и целевого релизов «ОбновлениеИнформационнойБазы <Продукт1С>» в процедуре «ПриДобавленииОбработчиковОбновления».
Ещё пример: требуется обновить 1С:УНФ с версии 1.6.25 на 3.0.4.
На сайте releases.1c.ru указано, что пропускать версии нельзя, нужно последовательно обновлять на каждую. По версии сайта обновление будет выглядеть следующим образом: 1.6.25 → 1.6.26 → 1.6.27 → 3.0.1 → 3.0.2 → 3.0.3 → 3.0.4, итого 5 промежуточных конфигураций.
Если построить сравнения между исходной 1.6.25 и финальной 3.0.4, то по обработчикам в общем модуле «ОбновлениеИнформационнойБазыУНФ» будет видно, что в финальной версии присутствуют не все обработчики обновления с предыдущих версий. На скриншоте слева исходная 1.6.25, справа финальная 3.0.4. В версии 3.0.4 есть обработчики обновления на версии 3.0.2, 3.0.3, 3.0.4. В версиях 3.0.2 и 3.0.3 тоже есть эти же обработчики и они совпадают с обработчиками в 3.0.4 и поэтому эти версии можно пропустить.
Сравнение «1С:УНФ» 1.6.25 и 3.0.4
Если построить сравнение между исходной 1.6.25 и 3.0.1, то в сравнении можно увидеть, что в версии 3.0.1 также есть не все обработчики обновления с предыдущих версий. Слева исходная 1.6.25, справа версия 3.0.1. В версии 3.0.1 есть обработчики обновления на версии 1.6.27, 3.0.1. В версии 1.6.27 обработчики обновления на эту версию совпадают с обработчиками в 3.0.1, и поэтому эту версию можно пропустить.
Сравнение «1С:УНФ» 1.6.25 и 3.0.1
Таким образом можно вычислить, что первый ключевым релизом, который нельзя пропускать при обновлении, будет 1.6.26. Конфигурацию следует обновлять в таком порядке: 1.6.25 → 1.6.26, версия 1.6.27 не нужна.
Аналогичным образом можно проанализировать и другие версии. Уже известно, что в финальной версии 3.0.4 содержатся обработчики для обновления на версию 3.0.2, 3.0.3 и 3.0.4, а значит, что следующим ключевым релизом должна быть версия 3.0.1.
Конечная цепочка обновления будет такой: 1.6.25 → 1.6.26 → 3.0.1 → 3.0.4, итого — всего 2 промежуточных релиза.
Как правильно подготовить промежуточные конфигурации 1С
Если конфигурация типовая, то можно обновиться последовательно на типовые конфигурации ключевых релизов.
Если конфигурация доработанная, то в типовые конфигурации ключевых релизов необходимо перенести доработки, которые влияют на целостность данных и логику их заполнения.
Доработку можно разделить на 2 этапа.
1 этап: перенос доработок структуры конфигурации
Для сохранения целостности данных необходимо перенести в промежуточную конфигурацию объекты, добавленные в рабочей конфигурации. Перенос необходимо выполнять с помощью сравнения и объединения конфигураций, для сохранения внутренних идентификаторов объектов.
Кроме переноса добавленных объектов необходимо также перенести изменения свойств объектов: длина кода\наименования, типы, движения, предопределенные значения.
2 этап: перенос доработок, влияющих на логику заполнения данных
К таким доработкам относятся, например, доработки в запросах формирования движений в 1С:УТ\ЕРП\КА. Обычно эти запросы находятся в процедурах «ТекстЗапроса<НазваниеРегистра>» в модуле менеджера документа, но также могут быть и в модулях набора записей регистров.
В типовых конфигурациях часто встречается, что обработчиками обновления выполняется перезаполнение регистра новыми движениями, с учетом изменения логики в новой версии типовой конфигурации.
Если в рабочей конфигурации есть доработки в функционале формирования движений и в новой версии типовой тоже происходит перезаполнение движений то эти доработки нужно перенести в промежуточную конфигурацию.
Важно понимать: в промежуточные конфигурации не нужно переносить все доработки форм, модулей, макетов и других объектов метаданных. Нужно оставить только те, которые влияют непосредственно на обновление данных.
За счет отказа от переноса ненужных доработок можно сократить время на подготовку промежуточных конфигураций. Соответственно работать пользователям в базе во время установки промежуточных конфигураций нельзя, так как поведение конфигурации будет максимально приближено к типовому.
PS: На различных форумах и обсуждениях можно встретить мнение, что обновляться нужно строго последовательно на все релизы, как указано на официальном сайте релизов, иначе ошибки и потеря данных неминуемы.
Наш опыт говорит о том, что:
- Не важно, конфигурация типовая или доработанная.
- Важно определить ключевые релизы, без которых действительно возможна безвозвратная потеря данных.
- Важно правильно подготовить конфигурацию, если она доработанная, или используются расширения.
- Самое важное — тщательно протестировать обновление на копии базы, делая бэкапы на каждом этапе — после реструктуризации, после основных обработчиков, после отложенных обработчиков.
Иногда ошибки могут возникать даже при последовательном обновлении на все пропущенные релизы, причины подобного: пользователи допускают ошибки учета (с точки зрения типовой логики 1С), заводят данные задним числом, дорабатывают конфигурации в обход типовых механизмов. При правильном выборе ключевых релизов все ошибки поправимы, потери данных можно избежать даже на нетиповых конфигурациях.
***
Во второй части расскажем, как мы оптимизируем скорость отработки промежуточных конфигураций.
В третьей части опишем несколько примеров из реальной жизни про оптимизацию промежуточных конфигурации на наших проектах.
