Разбор от сообщества: обновление 1с ерп релизы

10 октября 2026 · infolimp.ru

1. Ловушка «актуального релиза»: почему последний дистрибутив — не всегда ваш случай

Когда заказчик говорит «поставьте нам последнюю ERP», он не знает, что между первой версией 2.5 и последней — десятки промежуточных релизов. И в каждом из них — изменения структуры метаданных, новые регистры, изменение состава реквизитов. Специалист со стажем понимает: прямое обновление с 2.5.7 на 2.5.19 не равно последовательному прохождению пятнадцати шагов. Это две разные процедуры.

В справке 1С сказано, что обновление через поставщика выполняется «последовательно, с учётом поддерживаемых версий». Но на практике разработчик ERP не гарантирует корректность перехода через «разрыв» — когда пропущено более одного-двух релизов. Механика такая: при обновлении конфигурации платформа берёт только разницу между текущей и целевой версиями, а не «всю историю». Если промежуточный релиз вносил изменения в структуру таблиц, которые потом были переименованы или переиспользованы, — запись и чтение данных в этих таблицах начинают конфликтовать.

Что реально происходит «под капотом»

Файл поставщика 1cv8.cfu содержит правила преобразования и набор изменений для версий, но только для тех, которые разработчик объявил как «дорожку обновлений». В ERP стандартная цепочка обновления часто подразумевает пропуск не более четырёх-пяти версий. Внутри процедуры обновления работают не просто «перезаписи объектов», а скрипты конвертации данных — например, заливка данных из временных таблиц, переформирование остатков. Если вы прыгаете через три релиза, скрипты конвертации выполняются в неправильном порядке — таблица-донор может ещё не существовать, а таблица-приёмник уже удалена.

Ключевой тезис: обновление ERP «в один шаг» на последнюю версию — это не то же самое, что обновление до последней версии последовательным прохождением всех промежуточных. Пропустив релиз, вы берёте на себя обязательство вручную исправить всё, что там было изменено.

Вот реальный пример из практики: на одной из баз попытались перейти с ERP 2.5.5 на 2.5.16. Обновление формально прошло, но на следующий день при проведении документов поступления стали дублироваться записи регистра «НДС Покупки». Оказалось, что в 2.5.8 была изменена структура регистра, а в 2.5.12 — введён новый регистр, который в 2.5.16 заменил старый. Вследствие пропуска скрипт преобразования данных из 2.5.8 не выполнился, и старые записи остались в «чужой» таблице. Пришлось вручную конвертировать данные через временное хранилище.

2. Сравнение подходов: последовательное обновление vs «прыжок»

Нельзя сказать, что «прыжок» всегда запрещён. Иногда поставщик явно делает релиз-сборку, которая поддерживает обновление с нескольких предыдущих. Для этого существуют специальные релизы-«мосты». Разница принципиальна:

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

Как определить, является ли целевой релиз «мостом»? Убедитесь в наличии файла 1cv8.schedule, либо используйте официальный перечень обновлений ИТС. Альтернативный вариант — проверить в описании релиза список «предыдущих поддерживаемых версий». Эта информация, увы, не в справке, а в карточке релиза на портале 1С.

Практический приём: программная проверка допустимости перехода

Можно написать обработку, которая через HTTP-запрос к сервису 1С (специальный метод ИТС) получает массив «предыдущих версий» для целевого релиза. Это избавит от ручного поиска.

// Пример функции проверки, есть ли переход с версии ТекущаяВерсия на ЦелеваяВерсия
// Используется HTTP-сервис ИТС (адрес для примера, реальный API — через ИТС)
Функция ПроверитьПереход(ТекущаяВерсия, ЦелеваяВерсия) Экспорт
    URL = "https://releases.1c.ru/service/erp/check?from=" + ТекущаяВерсия + "&to=" + ЦелеваяВерсия;
    ЗапросHTTP = Новый HTTPЗапрос(URL);
    Соединение = Новый HTTPСоединение("releases.1c.ru", 443, ПользовательИТС, ПарольИТС,
        Новый ЗащищенноеСоединениеOpenSSL()); // защищённое соединение
    Ответ = Соединение.Получить(ЗапросHTTP);
    Если Ответ.КодСостояния = 200 Тогда
        СтрокаJSON = Ответ.ПолучитьТелоКакСтроку("UTF-8");
        Чтение = Новый ЧтениеJSON;
        Чтение.УстановитьСтроку(СтрокаJSON);
        Результат = ПрочитатьJSON(Чтение); // сериализуем в соответствие/массив
        Чтение.Закрыть();
        // Проверяем, есть ли переход: в JSON приходит true/false или массив версий
        Возврат Результат.Допустимо;
    Иначе
        ЗаписьЖурналаРегистрации("Обновление ERP", УровеньЖурналаРегистрации.Предупреждение,
            , , "Код состояния HTTP: " + Ответ.КодСостояния);
        Возврат Ложь;
    КонецЕсли;
КонецФункции

Внимание: приведённый код — псевдокод, показывающий принцип. Реальный API ИТС использует авторизацию и другой формат запроса. Внедряйте его через штатный механизм обновлений или готовые обработки с ИТС.

3. Обновление, которое ломает обмены: как не попасть на расхождение кодов

Вторая частая боль после обновления ERP — это сбой в синхронизации с другими системами: «1С:Документооборот», «1С:ЗУП», внешние сервисы. Причина не в обмене как таковом, а в изменении правил обмена. При обновлении конфигурации в состав правил могут добавиться новые объекты, а старые — изменить состав реквизитов. Если план обмена настроен на определенные версии объектов, после обновления правила приходится пересобирать. Но здесь есть нетривиальный нюанс: при частичном обновлении (через расширение или в режиме совместимости) новые объекты могут не попасть в план обмена автоматически.

Механика: почему обновление не обновляет правила обмена

Когда вы запускаете «Обновление конфигурации из файла», платформа сравнивает метаданные и обновляет структуру, но правила обмена — это отдельные справочники и регистры сведений. Они не всегда имеют готовые механизмы автоматической конвертации. Фирма 1С обычно сопровождает каждый релиз комплектом обновления правил обмена, но выгрузка этих правил в информационную базу — отдельная операция. Если её не сделать, узел РИБ продолжит работать со старыми правилами, что даст дубли при встречной синхронизации.

Многие администраторы забывают, что после обновления ERP необходимо создать новый экземпляр правила обмена (или выполнить обновление через «Обмен данными с «1С:Документооборот» — всегда через мастер, а не через повторную выгрузку старого файла).

4. Что делать прямо сейчас: конвейер обновлений и чек-лист

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

1. Соберите карту вашего контура. Зафиксируйте для каждой базы: номер релиза ERP, версия платформы, подключенные расширения, настройки интеграций. Это критично для проверки совместимости.
2. Составьте Road Map обновления. Определите, какие промежуточные релизы необходимо пройти, чтобы дойти до целевого без «прыжка». Не поленитесь — скачайте их все на диск ИТС и разложите по папкам.
3. Протестируйте на копии. Обновите копию базы, затем прогоните типовые сценарии: открытие документов, проведение, закрытие месяца, обмены. Обязательно проверьте ключевые отчёты, которые заказчик запускает еженедельно.
4. Обновите правила обмена. После каждого релиза ERP пересмотрите настройки синхронизации — не надейтесь на автоматическую подстройку.
5. Мониторьте журнал регистрации. В первые дни после обновления включите запись событий «Обновление данных» и «Конфигурация» — это позволит вовремя поймать ошибки конвертации.

Чек-лист для ответственного за обновление

• ☐ Создана резервная копия базы (не файла, а именно выгрузки с сохранением истории).
• ☐ Проверена совместимость релиза ERP с версией платформы (не используйте платформу новее, чем поддерживает релиз).
• ☐ Скачаны и проверены официальные файлы обновления с ИТС.
• ☐ Обновление проведено на тестовой базе, и после теста база не удалена.
• ☐ Проверены обмены с каждой внешней системой (отправка и получение).
• ☐ Проверены права пользователей (в новом релизе могут измениться роли).

5. Типичные ошибки: как не нужно делать

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