Как обновить и ускорить 1С 8.3 без остановки учёта: план работ

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

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

Аудит базы перед модернизацией 1С

Начинайте не с обновления, а с инвентаризации. Без неё нельзя оценить ни сроки, ни риски.

Что выяснить и записать:

• 🔢 Версия платформы. Видна в окне «О программе» (кнопка с буквой «i» или меню с тремя полосками в правом верхнем углу).
• 📦 Конфигурация и релиз. Там же, в «О программе», или в Конфигуратор → Справка → О программе.
• 🔧 Статус поддержки. В Конфигураторе откройте Конфигурация → Поддержка → Настройка поддержки. Если там «На поддержке», объекты не менялись. «Изменения разрешены» — в базе есть доработки, и их нужно найти.
• 🧩 Расширения. Список в Администрирование → Печатные формы, отчеты и обработки → Расширения (в БП 3.0 и ЗУП 3.1). Расширения переживают обновление проще, чем правки в основной конфигурации, но их тоже надо проверить.
• 📄 Внешние обработки и печатные формы. В том же разделе — «Дополнительные отчеты и обработки». После смены релиза часть из них может перестать работать.
• 🔄 Обмены. С сайтом, банком, другими базами 1С, ЭДО. Каждый обмен — отдельный пункт в плане тестирования.
• 💾 Размер базы и режим работы. Файловая или клиент-серверная, сколько пользователей одновременно, какая СУБД.

Как найти доработки

Возьмите чистую типовую конфигурацию того же релиза (файл .cf из дистрибутива) и сравните с основной: Конфигурация → Сравнить конфигурации. Отчёт о сравнении покажет каждый изменённый объект. Сохраните его — это готовая оценка объёма работ.

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

Здесь решается, сколько будет стоить проект. Удобно разложить по трём сценариям.

Стоимость работ ориентировочно: час специалиста по 1С в регионах — около 1 500–3 000 ₽, в Москве — 2 500–5 000 ₽. Обновление типовой базы на несколько релизов обычно укладывается в 2–4 часа. Модернизация доработанной базы с тестированием легко выходит на 20–60 часов.

Почему расширения — главный приём модернизации

Расширения конфигурации появились в платформе 8.3.6. Доработка в расширении хранится отдельно от основной конфигурации. Основная остаётся на поддержке и обновляется как типовая, а расширение просто подключается поверх.

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

Обновление платформы 1С:Предприятие

Платформу обновляют первой, но не «до последней версии», а до той, которую требует нужный релиз конфигурации. Минимальная версия платформы указана в описании релиза (файл ReadMe.txt или 1cv8upd.htm в дистрибутиве обновления).

Порядок для файловой базы:

1. Скачайте дистрибутив платформы с портала поддержки по вашей подписке.
2. Установите новую версию на все компьютеры, где работают с базой. Старые версии удалять не обязательно, они ставятся рядом в C:\Program Files\1cv8\<номер версии>.
3. Запустите базу. Стартер 1cestart.exe по умолчанию берёт самую новую установленную версию.

Для клиент-серверного варианта есть жёсткое правило: версия платформы на клиентах и на сервере 1С должна совпадать полностью, до последней цифры. Иначе клиент просто не подключится.

Порядок для сервера:

1. Предупредите пользователей: при остановке службы сервера все сеансы оборвутся. Делайте это вне рабочего времени.
2. Установите новую версию сервера рядом со старой.
3. Остановите службу агента сервера старой версии и зарегистрируйте службу новой (через установщик или утилиту ragent с параметром регистрации службы).
4. Запустите службу, проверьте в консоли кластера, что базы на месте.
5. Обновите платформу на клиентских компьютерах или терминальном сервере.

Режим совместимости

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

Переход на новый релиз и слияние изменений

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

Штатное обновление типовой базы

Для баз на полной поддержке в БП 3.0 и ЗУП 3.1 удобнее всего пользовательский режим: Администрирование → Обслуживание → Обновление версии программы. Программа сама подберёт цепочку релизов через интернет -поддержку и сделает резервную копию для файловой базы.

Второй путь — Конфигуратор:

1. Конфигурация → Поддержка → Обновить конфигурацию.
2. Укажите файл обновления или поиск доступных обновлений.
3. Дождитесь окна сравнения, нажмите «Выполнить».
4. Подтвердите обновление конфигурации базы данных.
5. Запустите базу в режиме «1С:Предприятие» — откроется обработка обновления данных.

Для пакетного обновления без интерфейса пригодятся параметры командной строки:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /DumpIB"D:\Backup\buh_before.dt" /Out"D:\Backup\log.txt"
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /UpdateCfg"D:\Updates\1cv8.cfu" /UpdateDBCfg /Out"D:\Backup\log.txt"

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

Слияние доработанной конфигурации

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

Типовые варианты для объекта:

• 📥 Взять из новой конфигурации поставщика — если ваша доработка больше не нужна или поставщик сделал то же самое.
• 🔀 Объединить — платформа попробует свести изменения построчно. Результат обязательно просматривайте глазами.
• 🔒 Оставить свою версию — опасно для общих модулей: новый код поставщика из других объектов может обращаться к процедурам, которых у вас нет.

Отдельная ловушка — общие модули с доработками. Поставщик переписывает их почти в каждом релизе. Сто строк вашего кода в таком модуле на каждом обновлении превращаются в ручную работу. Перенос этих вставок в расширение окупается за два-три релиза.

Производительность после модернизации

После перехода на свежий релиз база часто какое-то время работает медленнее. Причины обычно понятные.

• ⏳ Отложенные обработчики обновления. Современные типовые конфигурации часть данных переводят в фоне, уже после входа пользователей. Ход процесса виден в разделе Администрирование → Обслуживание, в группе результатов обновления программы. Пока обработка не закончена, отчёты могут показывать неполные данные и тормозить.
• 📊 Устаревшая статистика СУБД. После реструктуризации таблиц планы запросов в СУБД строятся по старой статистике. Для MS SQL Server помогает обновление статистики (sp_updatestats или регламентное задание обслуживания), для PostgreSQL — VACUUM ANALYZE.
• 🗂 Фрагментированные индексы. Перестройку индексов включают в план обслуживания СУБД ночью, когда нет пользователей.
• 🧹 Кеш клиента. Если после обновления странно ведут себя формы или команды, запустите клиент с параметром /ClearCache. Кеш пересоздастся при следующем входе.

Когда нужна аппаратная модернизация

Иногда упирается не в релиз, а в железо и архитектуру.

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

Тестирование и запуск обновлённой базы

Все эксперименты — только на копии базы. Рабочую базу обновляют один раз, по готовому и проверенному сценарию.

Как сделать тестовую копию: в Конфигураторе Администрирование → Выгрузить информационную базу, затем создайте новую пустую базу и загрузите туда файл .dt через Администрирование → Загрузить информационную базу. Загрузка требует монопольного доступа к целевой базе — для новой пустой базы это не проблема.

Что проверить на копии перед переносом на рабочую базу:

Ввод в эксплуатацию

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

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

Ошибки, которые делают модернизацию дороже

• ❌ Пропуск релизов «потом догоним». Отставание на 30–40 релизов превращает обновление в отдельный проект. Регулярное обновление раз в месяц-два обходится дешевле.
• ❌ Правки прямо в типовых объектах «по-быстрому». Каждая такая правка снимает объект с поддержки и добавляется в работу при каждом следующем обновлении.
• ❌ Обновление платформы на сервере без клиентов. Пользователи не подключатся, пока версии не совпадут.
• ❌ Проверка только «база открылась». Ошибки слияния вылезают при проведении конкретных документов и закрытии месяца, а не на старте.
• ❌ Отсутствие документации по доработкам. Через год никто не помнит, зачем менялся модуль. Короткий файл со списком изменений экономит часы при следующем слиянии.

Частые вопросы о модернизации 1С