Обработка предназначена для разработчиков, использующих в своей практике динамические обновления конфигурации в управляемом режиме, с использованием сервера 1С: Предприятия. Обработка исправляет зависание базы, бесконечную загрузку базы.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Наименование
Скачано
Купить файл
По подписке PRO
Решение проблемы с зависанием базы после динамического обновления:
Первоначальная задача заключалась в локальном переносе добавленных объектов метаданных (справочников, документов) и кастомной логики в расширение без потери накопленных данных. Но в ходе проекта, когда работы были уже практически завершены, заказчик принял решение полностью вернуть конфигурацию к типовому виду и перенести в расширение все измененные свойства стандартных объектов, включая изменения типов реквизитов.
Я при обновлениях ноу хау никогда не использовал, всегда действовал вручную несколько часов, сливая новый код вендора со старыми изменениями. Почитал тут статью "Использование нейросети для обновления расширений 1С: GPT, Git и анализ эффективности на 33 реальных проектах", ну и времени всегда мало, приходится искать варианты, как сделать, чтобы его было достаточно. Мое мнение в том, что методы 1С по тысячам строк, которые приходится лопатить, сначала дорабатывать а потом обновлять, плохо влияют на здоровье, интерес к различным средствам автоматизации процесса обновлений у меня очень высок. Делюсь своими потугами после первого применения. Вывод - ИИ оказался полезным. Простые случаи выгоднее обновлять ручным слиянием традиционно так как ИИ как такси, на обновлениях жрет очень много контекста. Для сложных, которые жрут не меньше, но убивают больше нервов, нашаманил скилл. Описываю процесс, подробно обо всем понемногу. Возможно, у Вас получится лучше, я торопился.
К нам на проект сложного обновления пришла конфигурация «1С:ERP УХ» с доработанным отчетом, построенным на базе типового «Задолженность поставщикам по срокам». После обновления целевая форма открывалась без учета переданных данных.
На проекте сложного обновления 1С:ERP 2.4.14.181 до версии 2.5.22.106 нам было нужно уложить обновление в технологическое окно 48 часов (выходные). Исходный замер, с учетом промежуточных релизов 2.5.8.443, 2.5.12.270, 2.5.17.234, 2.5.22.106, показал требуемое время в 659 часов…
Обновление ролей в расширении 1С отличается от аналогичного процесса в основной конфигурации. Ситуация осложняется, когда доработки вносятся не в «обычное», а в поставляемое расширение.
Внешняя обработка для проверки методов расширений с директивами &Вместо, &Перед, &После и &ИзменениеИКонтроль после обновления типовой конфигурации.
Обработка анализирует файловые выгрузки старой и новой конфигурации, автоматически определяет изменившиеся типовые методы и формирует список методов расширения, требующих проверки.
Делюсь практикой переноса доработок при обновлении 1С:КА с 2.5.22 на 2.5.27 с помощью Claude, подключённого к конфигурации в EDT через MCP. Что у ИИ получилось хорошо, где он бессилен, что он осознанно отказался переносить — и какой главный вывод я сделал для следующего раза.
Когда доработанную 1С не обновляли годами, начинать приходится не с переноса кода, а с разбора того, что вообще накопилось в базе. Там могут быть десятки обработок, расширения, правки типовых объектов, а документации либо нет, либо она давно не актуальна. На примере реального обновления разбираем, как кодовые агенты, MCP-серверы и языковые модели помогают навести порядок в доработках, собрать план миграции, понять, где при переносе будут проблемы, и автоматизировать часть исправлений.
