Почему доработанная 1С обновляется сложнее типовой
Типовая конфигурация обновляется по понятному маршруту: поставщик выпускает релиз, платформа сравнивает изменения, администратор применяет обновление. Но в доработанной базе часть объектов уже отличается от типовых. Когда новый релиз приносит свои изменения в те же места, появляется конфликт.
Конфликт не всегда выглядит как ошибка на экране. Иногда программа открывается, документы проводятся, но расчет стал другим, реквизит перестал заполняться или обмен начал отправлять не те данные. Поэтому проверка после обновления важнее самого факта успешной установки релиза.
Хорошее обновление доработанной 1С не сводится к нажатию кнопки. Это небольшое обследование системы: какие изменения есть, кто ими пользуется, что можно заменить типовым функционалом, а что нужно аккуратно перенести.
Что ломается чаще всего
В первую очередь страдают места, где типовая логика пересекается с логикой бизнеса. Например, в документ добавили реквизит, изменили проведение, переписали печатную форму или встроили проверку перед записью. Новый релиз может изменить тот же документ, и старый код перестает подходить.
Вторая группа риска - обмены. Сайт, CRM, банк, ЭДО, складское оборудование и другие базы 1С часто завязаны на структуру справочников и документов. После обновления меняются реквизиты, правила заполнения, статусы или формат данных, и обмен начинает давать дубли, пропуски или некорректные остатки.
Третья зона - отчеты и обработки. Они могут обращаться к устаревшим реквизитам, временным таблицам, регистрам или движениям документов. Пользователь видит это просто: отчет вчера формировался, а после обновления пустой, медленный или показывает странные цифры.
Типовые симптомы после неаккуратного обновления:
- документ перестал проводиться или проводит движения иначе;
- печатная форма открывается с ошибкой или потеряла нужные поля;
- обмен с сайтом, CRM или другой базой начал создавать дубли;
- отчетность требует новый релиз, но база не принимает обновление;
- у части пользователей пропали права на привычные операции;
- старые внешние обработки перестали запускаться.
Как снизить риск до начала работ
Первое правило - не обновлять боевую базу без копии и плана проверки. Даже если обновление кажется простым, у компании должны быть резервная копия, тестовая база и список операций, которые нужно проверить до переключения.
Второе правило - не переносить доработки вслепую. Если в базе десять лет копились изменения, часть из них могла устареть. Иногда новый типовой релиз уже решает старую задачу лучше, чем самописный код. Переносить нужно не все изменения подряд, а только то, что реально используется и дает бизнесу ценность.
Третье правило - привлекать пользователей к приемке. Программист может проверить техническую сторону, но только бухгалтер, менеджер, кладовщик или производственный диспетчер знает, как выглядит правильная операция в реальной работе.
Чек-лист перед обновлением доработанной 1С
- Понять текущий релиз платформы и конфигурации.
- Проверить, находится ли конфигурация на поддержке и какие объекты изменены.
- Составить список критичных документов, отчетов, печатных форм и обменов.
- Сделать резервную копию и тестовую базу.
- Обновить сначала копию, а не рабочую базу.
- Проверить закрытие месяца, проведение ключевых документов, обмены и права.
- Согласовать окно финального обновления и план отката.
Таблица для быстрого решения
| Риск | Что сделать заранее |
|---|---|
| Потеря доработанной печатной формы | Собрать образцы форм и проверить их на тестовой базе после обновления. |
| Ошибки обмена | Проверить правила обмена, состав полей, статусы и тестовую выгрузку. |
| Неверные движения документов | Сверить проведение на типовых контрольных примерах до и после обновления. |
| Простой пользователей | Проводить рабочее обновление вечером или в выходной, после приемки копии. |
Когда лучше не тянуть
Обращаться к специалисту стоит не тогда, когда все уже остановилось, а когда появились повторяющиеся симптомы: база давно не обновлялась, пользователи обходят проблему вручную, данные расходятся, один сотрудник хранит всю логику в голове или любое изменение вызывает страх сломать учет.
Нормальный первый шаг не обязывает начинать большой проект. Достаточно описать ситуацию, показать один-два примера и получить понятный маршрут: что проверить, где риск, какая работа действительно нужна.