Как откатить обновления в 1С Розница

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

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

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

Почему штатного отката в 1С нет и что это значит

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

Из этого следует практический вывод: единственный надёжный способ вернуться на прежний релиз — развернуть копию базы, снятую до обновления. Копией может быть файл .dt (выгрузка информационной базы), дамп базы SQL или, для файлового варианта, полная копия каталога с файлом 1Cv8.1CD.

Подготовка: что сделать перед восстановлением базы

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

Далее определите, какие данные появились в базе между моментом обновления и текущим моментом: продажи, приходные документы, кассовые операции, результаты инвентаризации. Эти данные при откате будут потеряны, и их нужно либо перенести специальными обработками, либо ввести вручную после восстановления.

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

1. 1
   Сделайте копию текущей (проблемной) базы
2. 2
   Найдите и проверьте копию, снятую до обновления
3. 3
   Составьте список данных, введённых после обновления
4. 4
   Завершите сеансы пользователей и остановите регламентные задания
5. 5
   Отключите обмены с кассами и внешними системами

Откат файловой базы через восстановление из копии

Для файлового варианта есть два рабочих способа. Первый — загрузка выгрузки .dt: запустите конфигуратор в монопольном режиме, откройте меню «Администрирование» → «Загрузить информационную базу» и укажите файл копии, снятой до обновления. После загрузки база вернётся к состоянию на момент копирования, включая старую версию конфигурации.

Второй способ — замена файла базы. Закройте конфигуратор и все сеансы, скопируйте файл 1Cv8.1CD из резервного каталога на место текущего файла базы. Этот вариант быстрее для больших баз, но требует аккуратности: не перепутайте каталоги и не замените файл в работающей базе.

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

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

Откат клиент-серверной базы

В клиент-серверном варианте восстановление выполняется на стороне СУБД. Стандартный подход — восстановить дамп базы данных, снятый до обновления, средствами MS SQL Server, PostgreSQL или другой используемой СУБД, а затем подключить восстановленную базу к кластеру 1С.

Альтернатива — загрузка .dt через конфигуратор, как в файловом варианте. Этот способ проще, но на больших базах выгрузка и загрузка занимают значительное время, а иногда .dt-файл не создавался вовсе, если администратор полагался только на SQL-бэкапы.

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

Что делать с данными, введёнными после обновления

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

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

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

Проверка результата после отката

После восстановления базы не спешите запускать пользователей. Сначала проверьте версию конфигурации, затем выполните тестирование и исправление информационной базы (в конфигураторе: «Администрирование» → «Тестирование и исправление») — это выявит повреждения, если копия была снята некорректно.

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

Типичные ошибки при откате и как их избежать

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

Вторая распространённая проблема — забытые обмены. Если во время отката работала синхронизация с другой базой (например, с 1С Бухгалтерией или управляющей системой), в смежной базе могли остаться документы, которых в восстановленной Рознице уже нет. Такие расхождения нужно выявить и устранить вручную.

Как подготовиться к следующему обновлению, чтобы откат был безболезненным

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

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

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

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