← Практика · 14 ноября 2026

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

Обновление 1С с доработками: опись внешних обработок, сравнение с чистой типовой и карта рисков, которую помогла собрать нейросеть.

7 минут чтения1С

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

Типовая, нетиповая и переезд со своей мебелью

Типовая конфигурация — это 1С в том виде, в каком её выпустила фирма 1С. Нетиповая — та же программа, в которую компания внесла свои доработки. Обновление типовой конфигурации 1С проходит почти само. С нетиповой сложнее: это переезд в новую квартиру со своей мебелью. Шкаф прежний, а планировка новая, и не факт, что он встанет на старое место.

Компания работает на 1С:ERP 2.5, впереди переход на ERP 2.6. Есть рабочая база, тестовая копия и отдельная чистая типовая база для обращений в 1С.

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

Доработок немало: 21 подписка на события, 42 правки внутри типовых модулей и 49 добавленных реквизитов — дополнительных полей в документах и справочниках.

Доработку не трогали, а она сломалась

Поводом для подготовки стал реальный случай после перехода между релизами 2.5.

Была подписка на событие — кусок кода, который 1С сама запускает в нужный момент, например при проведении документа. При проведении плана продаж она дописывала движения в бюджетный регистр. Регистр — это таблица, где 1С копит учётные записи, а движения — записи, которые документ туда вносит.

В новом релизе типовой код начал перезаписывать этот же регистр в фоновом задании — работе, которую 1С выполняет сама, без участия пользователя. И писал он с замещением: стирал старые записи и клал на их место свои. Движение, дописанное подпиской, молча пропадало.

Это как соседи сверху, которые поменяли трубы, — и у вас пропала вода, хотя ваш кран никто не трогал. Сколько ни разбирай кран, причину в нём не найти.

Штатное сравнение конфигураций 1С ничего не показывало: в самой подписке разницы нет, сломалось окружение. В отладке картина была обратной: пока разработчик стоит на точке останова, транзакция держит регистр, фоновое задание не дожидается снятия блокировки и падает — и в регистре остаётся как раз движение подписки. Ошибка будто исчезала, стоило начать её искать. Специалист 1С нашёл причину сам, и, по его словам, «крови попило много». Нейросеть потом разобрала код и подтвердила ту же причину.

Сначала разобрали кладовку

Внешние отчёты и обработки — отдельные файлы, которые добавляют в 1С свои отчёты и действия. Они годами копились в общей папке, часто в нескольких версиях. В базе было зарегистрировано 66, а какие из остальных ещё нужны, специалист уже не помнил. Знакомая кладовка: всё лежит «на всякий случай», но перед переездом придётся решить, что брать с собой.

В папке нашлось 765 файлов, из них 437 — внешние отчёты и обработки. Нейросеть сравнивала их по содержимому, а не по названию: один и тот же отчёт лежал под разными именами, а разные версии — под одним. Разных отчётов и обработок оказалось 364.

Чтобы понять, чем пользуются, нейросеть нашла их следы в сохранённых настройках пользователей и сопоставила с тем, кто ещё работает в базе. 61 обработку в базе не регистрировали, но её открывали активные пользователи. А 237 не открывал никто из активных, и 233 из них не менялись с 2021 года и раньше.

Итог — таблица с колонкой «решение», которую заполнял специалист.

Ничего не удалили, всё на месте

Решал специалист. Ненужными он отметил 298 обработок, нужными — 66: из них 10 сторонних, которые не трогали, и 56 своих. Из 298 ненужных 25 были зарегистрированы в базе — оттуда специалист убрал их сам.

С файлами действовало его правило: ничего не удалять. Ненужное уехало в архив с сохранением подпапок, а прежняя версия перед правкой — туда же с пометкой «до правки».

Нужные привели в порядок: 45 файлов пересобрано, и все 45 проверены открытием в тестовой базе. 28 зарегистрированных перезагрузили в рабочую базу, и снимок их настроек до и после совпал. В архив ушло 374 файла. Контрольные суммы — цифровые отпечатки содержимого — всех 419 перенесённых и заменённых файлов совпали с описью, ошибок 0.

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

Искали, что меняется вокруг доработок

Дальше — главное: какой типовой код может задеть доработки компании.

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

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

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

Проверка на здравый смысл: место, где специалист исправлял случай с планом продаж, отчёт пометил высоким риском. Но, как выяснилось дальше, метил он не туда, куда важнее всего смотреть.

Где специалист поправил нейросеть

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

Была и ложная тревога. Одну подписку отчёт пометил жёлтым: обработчик обновления версии пишет тот же регистр. Специалист спросил, какой тут может быть конфликт, если при обновлении никто не работает. Нейросеть проверила код: обработчик пишет записи по другим документам, и часть из них дописывает, а не замещает. Тревога ложная, а в инструменте нашёлся недочёт: нет сверки по документам и по способу записи. Исправление в списке задач.

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

Что сделано и что впереди

Сделано: опись, разметка, порядок во внешних обработках и первая версия отчёта о рисках. Сам переход на ERP 2.6 ещё не начинался — специалист его отложил. Отчёт дорабатывается по его замечаниям. Для перехода нейросеть пока составила только план: копия базы на 2.6, проверка кода обработок на ссылки на исчезнувшие объекты, проверка прав пользователей на новые объекты, репетиция и сверка «до и после».

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

Как обновлять самому

1. Начните с описи внешних отчётов и обработок. Сравнивайте по содержимому, а не по именам, и смотрите в сохранённых настройках, кто ими пользуется. В нашем случае из 364 ненужными отметили 298. Ничего не удаляйте: переносите в архив и сверяйте контрольные суммы.
2. Сравнивайте с чистой типовой того же релиза и той же сборки. Иначе изменения от 1С смешаются с вашими.
3. Ищите, что меняется вокруг доработок. Для каждой подписки и своей записи в регистр составьте список типовых мест, которые пишут туда же, и проверяйте его при каждом обновлении — особенно фоновые задания, отложенные обработчики и запись с замещением.
4. В типовом коде меняйте только свои поля. Не привязывайте правку к составу чужих таблиц и помечайте её начало и конец — при объединении её будет легко найти.
5. После обновления на тестовой копии проведите документы, по которым работают доработки, дождитесь фоновых заданий и сверьте движения «до и после». В отладке такие ошибки могут не повторяться.

Что ещё нейросеть умеет в 1С — на странице о нейросетях в 1С.