Обновление нетиповой 1С без сюрпризов

Типовую базу обновляют «кнопкой». Нетиповую — слиянием: ваши доработки + изменения вендора. Публичные инструкции (KVANT-C, разборы по трёхстороннему сравнению) сходятся в одном: автогалочки в окне сравнения — самый дорогой способ «сэкономить вечер».

«Нетиповая» — не приговор. Плохо, когда обновления годами не ставили, а потом требуют «за выходные накатить всё».

Что должно быть до клика «Обновить»

1. Бэкап, который реально восстанавливали хотя бы раз.
2. Тестовая копия того же релиза, что прод (не «когда-нибудь потом»).
3. Карта доработок: расширения отдельно; правки в конфигурации — списком (объекты, зачем, кто владелец).
4. Окно простоя и план отката: кто принимает решение «стоп, откатываемся».

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

Трёхстороннее сравнение — зачем оно

Для корректного обновления смотрят три состояния (как в нормальных гайдах):

1. ваша рабочая конфигурация с доработками;
2. старый эталон поставщика (с которого «уехали»);
3. новый эталон / файл обновления.

Смысл: отличить «изменил только вендор» / «только мы» / «оба» (конфликт). Фильтр «только дважды изменённые» — ваш друг: именно там ручная работа.

Правило, которое я всегда проговариваю заказчику:

• изменил только вендор — обычно берём новое;
• изменили только вы — сохраняем своё;
• изменили оба — читаем код, не ставим галочку «взять из поставщика» из усталости.

Рабочий порядок, которым я пользуюсь

1. Инвентаризация доработок, внешних обработок, отчётов, обменов.
2. Обновление на копии с ручным разбором конфликтов.
3. Смок-сценарии под ваш бизнес: продажа, поступление, закрытие периода, зарплата, обмен — что реально болит.
4. Права: вход под ключевыми ролями, не только под полными правами.
5. Прод — только после приёмки на тесте + свежий бэкап + согласованное окно.

Отдельно: если доработки живут в расширениях — обновление обычно спокойнее. Если всё вшито в типовые модули без комментариев — каждое обновление становится мини-проектом. Это аргумент заранее переносить критичное в расширения, а не «потом как-нибудь».

Большой разрыв релизов

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

Что в абонементе, что отдельно

В сопровождении от 49 999 ₽/мес — регулярные обновления по регламенту, если объём предсказуем и база не «три года без патчей».

Если сильно доработано, снят с поддержки хаотично или разрыв релизов большой — это проект: оценка в часах от 2 999 ₽ или фикс по этапам. Иначе абонемент несправедлив ни для вас, ни для исполнителя.

Я веду такие обновления лично (enterprise-контуры, УТ/ERP/обмены): ответственность за порядок работ и приёмку, без очереди «линия → старший → ещё старший».

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