Стратегия обновлений: что в 1С можно отложить, а что ставить сразу

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

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

Как понять, что релиз обязателен

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

Релиз обязателен, если в нём есть хотя бы одно из этого:

• 📑 новые формы регламентированной отчётности или новые форматы выгрузки, которые вступают в силу до вашего ближайшего отчёта;
• ⚖️ изменения законодательства: ставки, лимиты, новые правила расчёта налогов, взносов, пособий;
• 🧾 новые форматы электронных документов: счетов-фактур, УПД, документов для маркировки;
• 🐞 исправление ошибки, которую вы уже видите в своей базе — неверный расчёт, падение формы, сбой проведения;
• 🔗 обязательный переходный релиз: без него следующие версии на вашу базу не встанут.

Релиз можно отложить, если он:

• ✨ добавляет функции, которыми вы не пользуетесь (новый блок для производства, а у вас услуги);
• 🎨 меняет интерфейс и оформление;
• 🔧 исправляет ошибки в разделах, которые у вас не работают.

Платформа и конфигурация: две разные очереди

Обновления 1С 8.3 приходят двумя независимыми потоками. Их путают, и отсюда половина проблем.

Платформа

Версии платформы можно ставить «через одну» и через несколько. Промежуточные установки не нужны: новый дистрибутив ставится рядом со старым, несколько версий спокойно живут на одном компьютере.

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

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

Конфигурация

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

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

Чем опасен пропуск важных исправлений

Риск пропуска зависит от того, что именно было в пропущенном релизе. В бухгалтерии последствия обычно денежные, а не технические.

Отчётность и законодательство

• ❌ Отчёт по старой форме не примут. Если форма или формат выгрузки сменились, а вы на старом релизе, отчёт вернут с ошибкой. Срок сдачи при этом никто не продлит.
• 💸 Неверный расчёт. Старый релиз считает по старым правилам: ставки взносов, НДФЛ, пособия, лимиты. Ошибку найдёте при сверке или при проверке, а исправлять придётся задним числом.
• 📨 Сбои документооборота. Контрагенты и операторы переходят на новые форматы, а ваша база отправляет старые или не может прочитать входящие.

Безопасность и стабильность

Платформа работает с сетью, сервером СУБД, веб-публикацией, внешними компонентами. Исправления в этих частях выходят в новых версиях платформы. Если база опубликована в интернете через веб-сервер или к ней подключаются удалённые сотрудники, тянуть с обновлением платформы на годы опаснее, чем для базы в закрытой локальной сети.

Технический долг

Чем дольше база стоит без обновлений, тем дороже переход. Цепочка из двадцати релизов — это несколько часов обновления, отложенная обработка данных и большая вероятность конфликта с доработками. Особенно это заметно в доработанных конфигурациях: каждое обновление требует сравнения и объединения, а пакет из многих релизов — объединения сразу всех изменений.

Производительность и стабильность после обновления

Новый релиз не всегда работает быстрее старого. Иногда после обновления база ощутимо тормозит в первые дни, и это не повод откатываться сразу.

Что происходит после загрузки релиза:

1. 🔄 Обработчики обновления. При первом запуске программа переводит данные на новую структуру. В крупной базе это занимает от минут до часов.
2. ⏳ Отложенная обработка. Часть преобразований идёт в фоне уже после запуска. Пока она не завершилась, отдельные отчёты и списки могут работать медленно или выдавать предупреждения. Ход обработки видно в разделе Администрирование → Обслуживание, в блоке результатов обновления программы.
3. 📈 Перестроение статистики СУБД. В клиент-серверном варианте после крупного обновления стоит обновить статистику и перестроить индексы средствами СУБД — запросы с новой структурой без этого часто идут медленнее.

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

Цепочка обновлений и совместимость

Совместимость — главное техническое ограничение пропуска релизов.

Как узнать цепочку

Есть два пути.

• 🌐 Автоматически. Обновление через интернет -поддержку само определяет, какие релизы нужны для перехода с вашей версии на актуальную, скачивает их и ставит по очереди. Для типовых конфигураций без доработок это самый простой способ. Подключение интернет-поддержки — в разделе Администрирование → Интернет-поддержка и сервисы.
• 📄 Вручную. В дистрибутиве каждого релиза есть описание порядка обновления со списком версий, с которых он ставится. Если вашего номера там нет — ищите самый поздний релиз, который с вашей версии ставится, и идите от него.

Что ещё ограничивает прыжок

• 🧩 Минимальная версия платформы. Новый релиз конфигурации требует платформу не ниже указанной. Сначала обновляют платформу, потом конфигурацию.
• 🖥️ Клиент и сервер. В клиент-серверном варианте версия клиента должна точно совпадать с версией сервера 1С. Обновили сервер — обновляйте клиентов на всех рабочих местах, иначе подключение не пройдёт.
• 🔌 Расширения и внешние обработки. После обновления расширение может перестать подходить к изменённым объектам, а внешняя печатная форма — ссылаться на удалённый реквизит. Их проверяют отдельно.
• 🛠️ Доработанная конфигурация. Если конфигурация снята с поддержки или изменена, обновление идёт через конфигуратор: Конфигурация → Поддержка → Обновить конфигурацию, со сравнением и объединением. Автоматическое обновление в таком случае не подходит.
• 🔗 Обмены данными. Если базы обмениваются данными (БП и ЗУП, УТ и БП), сильный разрыв в релизах ломает правила обмена. Обновлять связанные базы лучше согласованно.

Как проверить обновление перед внедрением

Рабочую базу обновляют только после пробного прогона на копии. Для файловой базы в 2–3 пользователя это полчаса, для сервера с доработками — отдельный этап работ.

Пошагово

1. Сделайте резервную копию. В конфигураторе: Администрирование → Выгрузить информационную базу, получится файл .dt. Для серверной базы дополнительно сделайте копию средствами СУБД.
2. Разверните тестовую базу. Создайте новую пустую базу и загрузите в неё .dt через Администрирование → Загрузить информационную базу. Работайте только в ней.
3. Пройдите всю цепочку. Поставьте все нужные релизы по порядку, запуская базу в режиме 1С:Предприятие после каждого — обработчики обновления выполняются именно при запуске.
4. Дождитесь отложенной обработки. Проверьте, что она завершилась без ошибок.
5. Проверьте свою работу. Откройте и проведите типичные документы, сформируйте ключевые отчёты за прошлый закрытый период, сравните цифры с рабочей базой. Проверьте печатные формы, расширения, обмены и отправку отчётности.
6. Перенесите на рабочую базу. В нерабочее время повторите то же самое на основной базе. Пользователей предупредите заранее: на время обновления структуры работать в базе нельзя.

Если обновление пошло не так

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

График обновлений для бухгалтерии

Удобная схема для небольшой организации на типовой конфигурации без доработок:

Привязывайте обновления к календарю отчётности, а не к выходу релизов. Квартальные отчёты, годовая отчётность, изменения с 1 января — вот точки, к которым база должна быть на актуальной версии. Между ними можно спокойно пропускать мелкие выпуски.

Частые вопросы