Промежуточные конфигурации 1С, часть 3: нетривиальные примеры обновления — случаи из жизни

02.07.25

Разработка - Рефакторинг и качество кода

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

Ранее мы писали, как подбирать промежуточных (ключевые) конфигурации для обновления и какие методы оптимизации можно применить, чтобы ускорить установку обновления на базу.

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

Случай 1: долго устанавливается обновление

Исходные данные: 

  • «1С: Управление торговлей» версии 11.4.13, 
  • целевой релиз 11.5.17, 
  • 4 промежуточных конфигурации.

Описание проблемы:
мы подготовили четыре промежуточные конфигурации версий 11.4.14, 11.5.8, 11.5.12, 11.5.17 (целевой релиз), но установка обновлений на версии 11.5.8 и 11.5.12 серьезно затягивают обновление. Согласно замерам, общее время обновления занимало 58 часов. Целевое время обновления — 48 часов.

  • Общее время реструктуризации до оптимизации — 11:14:00.
  • Общее время основных обработчиков до оптимизации — 5:32:00.
  • Общее время отложенных обработчиков до оптимизации — 40:25:00.

После анализа отложенных обработчиков версий 11.5.8, 11.5.12 была выявлена основная проблема задержки: данные заказов в версии 11.4.13 хранились в регистре накопления «Свободные остатки».

В версии 11.5.8 обработчик перекидывает данные в регистр накопления «Распределение запасов движений», а регистр «Свободные остатки» безвозвратно удален. Также заполняется новый регистр сведений «Распределение запасов».

В версии 11.5.12 данные из регистра накопления «Распределение запасов движений» переносятся в новый регистр накопления «Запасы и потребности». Записи в «Распределение запасов движений» сохраняются. Записи в регистре сведений «Распределение запасов» корректируются.

В версии 11.5.17 безвозвратно удаляется регистр накопления «Распределение запасов движений», остаются регистры «Запасы и потребности» и «Распределение запасов».

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

Что мы предприняли: в версиях 11.5.8, 11.5.12 полностью отключили обработчики обновления регистра накопления «Распределение запасов движений», регистра сведений «Распределение запасов», регистра накопления «Запасы и потребности».

В 11.5.17 разработали свой обработчик обновления регистра накопления «Запасы и потребности» взяв за основу обработчик из версии 11.5.12. В него же добавили функционал заполнения регистра сведений «Распределение запасов» таким образом, чтобы он выполнялся только после заполнения регистра накопления. 

После тестирования обновления выполнили замеры установки промежуточных на базу: 

  • Общее время реструктуризации — 11:14:00.
  • Общее время основных обработчиков — 5:00:00.
  • Общее время отложенных обработчиков — 22:00:00.

Итого, общее время установки обновления сократилось до 38 часов. Mission clear!
 

Случай 2: потеря данных из-за изменений в архитектуре типовой конфигурации

Исходные данные: 

  • 1С:ERP. Управление холдингом версии 3.1.11,
  • целевой релиз 3.2.1, 
  • одна промежуточная конфигурация 3.1.13.

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

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

Помимо этого в рабочей конфигурации документ «Оперативный план» использовался в добавленных объектах (в реквизитах, движениях), а после обновления в этих объектах уже были ссылки на неиспользуемые документы. Для решения этой проблемы были разработаны обработчики обновления, которые заполнили новые реквизиты и заменили регистраторы в движениях актуальными данными.
 

Случай 3: долго идет реструктуризация

Исходные данные: 

  • 1С: Бухгалтерия предприятия КОРП 3.0.103.21 + Бит.Финанс 3.1.50.4,
  • целевой релиз 3.0.163.26 + 3.1.61.13, без промежуточных.

Описание проблемы:
на сервере заказчика реструктуризация шла трое суток из-за плана счетов «Хозрасчетный», это непозволительно долго для их небольшой по объему базы.

Мы включили и настроили оптимизированный механизм реструктуризации (v2). Замеры показали ускорение в несколько раз.

Время реструктуризации на нашем сервере:

  • v1 — 4 часа.
  • v2 — 20 минут.

Время реструктуризации на сервере заказчика:

  • v1 — 108 часов.
  • v2 — 3 часа.
     

Случай 4: сильно увеличивается размер базы

Исходные данные: 

  • 1С: ERP 2.2.3.231,
  • целевой релиз 2.4.13.103, 
  • 4 промежуточных — 2.2.4, 2.4.7, 2.4.11, 2.4.13, 
  • база 1.6 ТБ.

Описание проблемы:
по коду конфигурации было видно, что база претерпела несколько частичных обновлений из версий 2.2.4, 2.5.7, 2.4.13. При обновлении на вторую промежуточную конфигурации (с 2.2.4 на 2.4.7) база на выполнении некоторых отложенных обработчиков зависала на неделю, сильно увеличивалась в размере, а процесс так и не завершался. Допустимый промежуток установки обновления на базу составлял 5 дней на все промежуточные.

Мы проанализировали данные в базе и нашли два источника зависания.

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

Второй — обновление проходило с допустимой скоростью, а 90% времени занимал расчет итогов, выполнявшийся при записи данных регистров накопления в обработчиках обновления, который вел к разрастанию TempDB и увеличению файла базы с исходного размера 1.6 ТБ до 6 ТБ.

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

По последним замерам эта промежуточная с 2.2.4 на 2.4.7 устанавливалась на базе целиком за 36 часов без разрастания базы до 6 ТБ, что позволяло уложить обновление со всеми промежуточными этапами в заданные 5 суток. После установки обновления база стала весить 2.2 ТБ.
 

Случай 5: обработчик обновления выполняется без ошибок, но данные остаются необновленными

Исходные данные: 

  • 1С:CRM 3.0.16.11,
  • целевой релиз 3.1.31.25, 
  • 6 промежуточных — 3.0.21, 3.0.22, 3.0.23, 3.0.27, 3.0.29, 3.0.31,
  • база 100 Гб.

Описание проблемы:
при тестировании обновления выяснилось, что по какой-то причине данные справочника «Партнеры» не были обработаны. Проблема началась еще на первом шаге обновления с исходной 3.0.16 на первую промежуточную 3.0.21. Если обновлять последовательно через все регламентированные 1С релизы (3.0.17, 3.0.18, 3.0.19, 3.0.20, 3.0.21), то ошибки нет, а если с 3.0.16 сразу на 3.0.21, то ошибка есть. При этом все обработчики обновления с предыдущих версий присутствуют в 3.0.21.

По отчету о прогрессе отложенного обновления мы обнаружили, что обработчики из 3.0.18 и 3.0.19 версий обрабатывают один и тот же объект  — справочник «Партнеры» и регистрируют данные к обновлению на один узел обмена плана обмена «ОбновлениеИнформационнойБазы».
 

В отчете по прогрессу обновления обработчики перечислены через запятую, а очередь у них одна


Вместе с этим обнаружили, что аналогичная проблема будет и с документом «CRM_Интерес».
 

Обработчики документа «CRM_Интерес»


На примере справочника «Партнеры» в коде тоже можно это увидеть, как это было реализовано в конфигурации.
 

Обработчики в 1С:CRM 3.0.18.6


Обработчики в 1С:CRM 3.0.19.5

 

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

Проблема решилась доработкой обработчика 3.0.19 версии — мы перенесли регистрацию данных на другой узел.
 

Перенос регистрации данных обработчика

обновление 1с промежуточные конфигурации оптимизация обновления 1С

См. также

DevOps и автоматизация разработки Обновление 1С Системный администратор Программист 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Абонемент ($m)

Продолжаем делиться опытом ICL SOFT – в этой статье рассказываем о сложном обновлении сильно доработанной конфигурации "1С:ERP Управление холдингом с версии 3.1.8.15" до актуальной версии редакции 3.2. Публикации о сложных обновлениях, которые можно найти в открытых источниках, содержат мало подробной информации об использованных инструментах и решениях. Часто в них отсутствует информация о том, что находится под капотом этих решений. Будем рады, если наша статья окажется полезной

1 стартмани

01.07.2025    892    vladimir_iclsoft    1    

16

Обновление 1С Программист Стажер 1С v8.3 Бесплатно (free)

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

04.06.2025    3134    1c-izh    11    

16

Рефакторинг и качество кода Программист 1С v8.3 Россия Бесплатно (free)

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

03.06.2025    1356    MC4RT    5    

12

Рефакторинг и качество кода Программист 1С v8.3 Абонемент ($m)

Конфигурация для хранения стандартов и сохранения их в формате PDF.

2 стартмани

05.05.2025    3854    comptr    7    

15

Рефакторинг и качество кода 1С v8.3 Абонемент ($m)

Методический материал для собеседования. Помогает облегчить общение между кандидатом и работодателем.

5 стартмани

05.05.2025    4567    vasilev2015    109    

25

БСП (Библиотека стандартных подсистем) Обновление 1С Программист 1C:ERP Бесплатно (free)

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

29.04.2025    2333    krasnoshchekovpavel    7    

18

Рефакторинг и качество кода Программист 1С v8.3 Россия Бесплатно (free)

Цель статьи: кратко показать инструмент и возможности Cursor IDE.

21.04.2025    13415    dimzfresh    41    

46

Рефакторинг и качество кода Программист Стажер Бесплатно (free)

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

21.04.2025    10254    RPGrigorev    31    

54
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. BackinSoda 04.07.25 08:47 Сейчас в теме
А разработка оптимизации не заняла больше времени, чем сами обновления ?
2. 1c-izh 74 04.07.25 10:18 Сейчас в теме
(1) Мы занимаемся обновлением сильно измененных конфигураций, на проекте много и других работ, помимо оптимизации промежуточных)

Например, в одном из приведенных случаев — в конфигурации были изменены 1010 объектов и добавлено 723 новых, на подготовку и оптимизацию промежуточных ушло около 10% от общих трудозатрат.
3. o.nikolaev 217 06.07.25 18:34 Сейчас в теме
(Не реклама) Но Иж-Ти-Си реально рулит в деле обновления чего угодно на чего угодно. И за разумные-обоснованные деньги.
4. 1c-izh 74 07.07.25 10:30 Сейчас в теме
(3) Спасибо за оценку) Будем стараться и дальше делиться опытом в статьях.
Оставьте свое сообщение