Администрирование · 11 мин
Как проверить 1С после обновления конфигурации
Пошаговая проверка 1С после обновления конфигурации: тестирование и исправление, контрольные операции, проверка данных, отчётов и обменов. Что делать при ошибках.
Обновление конфигурации 1С завершается не нажатием кнопки «Обновить конфигурацию базы данных», а проверкой того, что программа работает корректно. Пропущенные ошибки на этом этапе проявляются позже — в виде сбойных документов, неверных отчётов или расхождений в обменах, когда откатиться уже сложно.
Проверка строится в три слоя: технический контроль базы (тестирование и исправление), функциональный контроль (проведение документов, формирование отчётов) и контроль интеграций (обмены, внешние печатные формы, подключаемое оборудование). Каждый слой имеет свои признаки нормы и проблемы.
Порядок действий зависит от режима работы базы — файловый или клиент-серверный, а также от того, что именно обновлялось: типовой релиз на поддержке или конфигурация с доработками. Ниже разобраны оба сценария.
Подготовка: резервная копия и контроль версии
Первое действие после любого обновления — убедиться, что у вас есть рабочая резервная копия, сделанная до обновления. Если копию забыли сделать, сделайте её сейчас, до начала любых проверок и исправлений: тестирование с включёнными флагами исправления изменяет данные необратимо.
Далее сверьте версию. Откройте в конфигураторе «Конфигурация → Поддержка → Настройка поддержки» или в пользовательском режиме раздел «О программе» и убедитесь, что номер версии соответствует тому релизу, на который вы обновлялись. Если версия старая — обновление не применилось или применилось частично.
Отдельно проверьте, что обновление конфигурации базы данных выполнено до конца. Признак незавершённого обновления — при запуске предприятия пользователи видят сообщение о несоответствии версий конфигурации и конфигурации базы данных, либо база требует монопольного доступа для завершения обновления.
Тестирование и исправление информационной базы
Штатный инструмент технического контроля — обработка «Тестирование и исправление» в конфигураторе (меню «Администрирование»). Она проверяет физическую и логическую целостность базы и умеет исправлять часть найденных проблем.
Запускать её нужно в монопольном режиме и только при наличии резервной копии. Для первого прохода после обновления достаточно проверок логической целостности и ссылочной целостности; проверка физической целостности файловой базы занимает заметно больше времени и оправдана при подозрении на повреждение файла.
- 1Сделайте резервную копию (выгрузка в dt для файловой базы или средствами СУБД для клиент-серверной).
- 2Выгнать всех пользователей и откройте конфигуратор в монопольном режиме.
- 3Откройте «Администрирование → Тестирование и исправление».
- 4Отметьте проверки «Логическая целостность информационной базы» и «Ссылочная целостность информационной базы».
- 5Выберите режим «Тестирование» (без исправления) и нажмите «Выполнить».
- 6Изучите список ошибок. Только после анализа запустите режим «Тестирование и исправление» при необходимости.
Важный нюанс: при ссылочных ошибках режим исправления предлагает варианты «Создавать объекты», «Очищать ссылки» или «Не изменять». Очистка ссылок удаляет «битые» ссылки из документов — это может скрыть проблему вместо решения. Безопасный вариант — сначала выяснить, откуда появились битые ссылки, и только потом выбирать действие.
Для клиент-серверных баз на MS SQL или PostgreSQL тестирование и исправление не заменяет проверки средствами СУБД. Если есть подозрения на повреждение данных на уровне сервера, используйте штатные инструменты СУБД (например, DBCC CHECKDB для MS SQL).
Контроль обработчиков обновления и отложенных операций
При переходе на новый релиз типовой конфигурации выполняются обработчики обновления данных — они переносят и преобразуют информацию под новую структуру. Часть из них работает в отложенном режиме и может выполняться в фоне после запуска пользователей.
Проверьте статус обработчиков: в типовых конфигурациях это делается через раздел «Администрирование → Обслуживание → Результаты обновления приложения» (в некоторых конфигурациях — «Результаты обновления программы»). Все обработчики должны иметь статус успешного завершения. Зависшие или завершённые с ошибкой обработчики — прямой признак того, что данные преобразованы не полностью.
До завершения отложенных обработчиков часть функций может быть ограничена, а отчёты — показывать неполные данные. Не торопите пользователей и не запускайте регламентные операции (закрытие месяца, расчёт себестоимости), пока отложенное обновление не завершено.
Функциональная проверка в пользовательском режиме
Технические проверки не гарантируют, что прикладная логика работает. Следующий шаг — контрольные операции в режиме предприятия. Состав проверок зависит от того, какие подсистемы реально используются, но базовый набор одинаков почти для любой конфигурации.
Выполните типовой цикл работы на копии базы или в тестовом периоде: создайте и проведите по одному документу каждого активно используемого вида (поступление, реализация, платёж, начисление зарплаты — по профилю базы), отмените проведение, проведите повторно. Ошибки проведения и незаполненные движения — типичный признак проблем после обновления.
Сформируйте ключевые отчёты за один и тот же период и сверьте итоги со значениями, зафиксированными до обновления: оборотно-сальдовая ведомость, отчёты по взаиморасчётам, остатки склада, регистры налогового учёта. Совпадение итогов — главный признак того, что данные при обновлении не пострадали.
Как проверить результат
Итоги совпадают со значениями до обновления
Изменились сальдо или обороты по счетам
Документ проводится, движения формируются
Ошибка проведения или пустые движения
Форма открывается и заполнена корректно
Ошибка формирования или пустые поля
Остатки совпадают с данными до обновления
Расхождения в количестве или суммах
Проверка прав и ролей пользователей
Новые релизы иногда добавляют новые роли и объекты метаданных. Убедитесь, что у пользователей сохранился доступ к их рабочим разделам: войдите под учётной записью рядового пользователя (или используйте запуск от имени другого пользователя) и откройте его типовые документы и отчёты. Ошибки «Нарушение прав доступа» после обновления обычно означают, что новые объекты не вошли в профили групп доступа.
Проверка обменов, печатных форм и оборудования
Интеграции ломаются после обновления чаще, чем внутренняя логика: меняется состав реквизитов, форматы выгрузки, версии API. Проверку обменов нельзя пропускать, даже если внутри базы всё работает.
Выполните тестовый обмен с каждой связанной системой: синхронизация с другой базой 1С, обмен с банком (клиент-банк), обмен с сайтом, ЭДО, отправка отчётности. Проверьте, что данные выгружаются без ошибок и на принимающей стороне документы выглядят корректно.
Отдельно проверьте внешние печатные формы, дополнительные отчёты и обработки — они не обновляются вместе с конфигурацией и могут ссылаться на переименованные или удалённые объекты. Подключённое торговое оборудование (кассы, сканеры, терминалы) проверяется пробной операцией: пробейте тестовый чек, считайте штрихкод.
Особенности проверки доработанной конфигурации
Если конфигурация снята с полной поддержки и содержит доработки, объём проверок увеличивается. Обновление могло «затереть» доработки или, наоборот, доработки могли не примениться к изменённым объектам.
Составьте список всех доработок до обновления и после обновления пройдите по каждой: откройте доработанные формы, выполните доработанные процедуры, проверьте доработанные отчёты. Особое внимание — модулям, в которых при обновлении выполнялось объединение с режимом «взять из новой конфигурации поставщика»: такие места требуют ручного переноса доработок.
Если доработок много, перед обновлением рабочей базы обновление прогоняют на копии и составляют чек-лист проверки каждой доработки. Это единственный надёжный способ не пропустить скрытую поломку.
Как выбрать действие
Частые вопросы о проверке 1С после обновления
Сколько времени занимает тестирование и исправление базы?
Зависит от размера базы и набора проверок. Небольшая файловая база проверяется за десятки минут, большая клиент-серверная — за несколько часов. Проверку физической целостности больших баз планируют на нерабочее время.
Можно ли проверять базу, пока в ней работают пользователи?
Функциональную проверку (документы, отчёты, печать) — да, хотя лучше на копии. Тестирование и исправление в конфигураторе требует монопольного доступа: всех пользователей и фоновые сеансы нужно завершить.
Что делать, если после обновления отчёт показывает другие цифры?
Сначала проверьте, завершились ли отложенные обработчики обновления — неполные данные частая причина. Затем сузьте поиск: сравните отчёт по счетам/регистрам с прошлым периодом и найдите документ, дающий расхождение. Только после этого принимайте решение об исправлении или откате.
Нужно ли проверять базу после обновления платформы, а не конфигурации?
Да, но акцент другой: проверяют запуск базы на новой платформе, работу тонкого и веб-клиента, печать, COM-соединения и обмены. Тестирование и исправление после смены платформы обычно не требуется, если нет признаков повреждения данных.
Когда нужен откат на резервную копию?
Откат оправдан, когда обнаружены повреждения данных, массовые ошибки обработчиков обновления или расхождения в учётных данных, которые нельзя быстро объяснить и исправить. Учтите: данные, введённые после обновления, при откате будут потеряны и потребуют повторного ввода.
Обязательно ли обновлять копию базы перед рабочей?
Для типовой конфигурации без доработок и с небольшим объёмом данных — желательно, но допустимо обновлять рабочую базу при наличии свежей копии. Для доработанной конфигурации обновление на копии с составлением чек-листа проверки — фактически обязательный этап.
Что важно запомнить
Проверка после обновления — обязательный этап, а не формальность. Порядок один: резервная копия, тестирование и исправление, контроль обработчиков обновления, функциональная проверка документов и отчётов, проверка обменов и внешних объектов. Главный критерий успеха — совпадение итогов отчётов с данными до обновления и отсутствие ошибок у рядовых пользователей.