Обновление 1С пугает сильнее, чем оно того заслуживает. В небольших компаниях его откладывают месяцами, потом обновляются в панике перед сдачей отчётности и получают неприятности ровно в тот момент, когда времени на них нет.
Порядок действий при этом всегда одинаковый и не зависит от конфигурации: сделать копию, понять, сколько релизов вы пропустили, обновиться, проверить результат. Каждый шаг разберём подробно, с указанием того, где обычно спотыкаются.
Копия базы, без которой начинать нельзя
Резервная копия перед обновлением решает всё. Она превращает неудачное обновление из аварии в получасовую задержку: развернули вчерашнее состояние, продолжили работать, разобрались позже.
Для файловой базы копия делается просто. Все выходят из программы, вы копируете каталог базы целиком на другой диск. Именно каталог, а не только файл 1Cv8.1CD: рядом лежат служебные данные, без которых восстановление будет неполным. Каталог легко найти в окне запуска, он написан под названием базы.
Для клиент-серверной базы копию делает администратор средствами СУБД либо выгрузкой в файл формата dt. Выгрузка в dt удобна тем, что не требует доступа к серверу баз данных, но на больших базах она идёт долго: база на 60 ГБ выгружается два-три часа, и всё это время работать нельзя. Поэтому в компаниях с большой базой обновление планируют на вечер пятницы, а копию снимают штатным механизмом резервного копирования СУБД.
Проверьте, что копия действительно создалась и весит столько же, сколько оригинал. Мы видели случаи, когда копирование обрывалось на середине из-за нехватки места, а человек этого не замечал: файл вроде есть, значит всё в порядке. Подробнее про схему копирования и сроки хранения мы писали в статье про резервное копирование базы 1С.
Сколько релизов вы пропустили
Второй шаг определяет, будет обновление рутиной или проектом на два дня. Посмотрите текущую версию конфигурации: она пишется в меню «О программе» и выглядит как набор из четырёх чисел, например 3.0.164.28.
Дальше сравните её с актуальной на сайте поддержки. Если разница в один-два релиза, обновление обычное. Если вы отстали на десять и больше, готовьтесь к промежуточным шагам: разработчик не гарантирует прямого перехода с любой старой версии на текущую, и часть обновлений умеет ставиться только последовательно.
Понять, можно ли идти через один, помогает сам механизм обновления. При выборе файла обновления программа показывает, с каких версий он устанавливается. Список конкретный, там перечислены номера. Вашей версии в списке нет, значит нужен промежуточный релиз, и он тоже скачивается с сайта поддержки.
Здесь же полезно различать два разных обновления, которые в разговоре называют одним словом. Есть платформа, то есть сама программа 1С:Предприятие, её версия выглядит как 8.3.25.1394 и видна в заголовке окна. И есть конфигурация, то есть прикладное решение: Бухгалтерия, Зарплата, Управление торговлей. Обновляются они независимо, и требования у них разные. Новая конфигурация обычно требует платформу не ниже определённой версии, а вот старая конфигурация на новой платформе работает почти всегда.
Практический смысл в том, что при жалобе «не открывается после обновления у одного пользователя» причина чаще в платформе: у человека осталась старая версия программы, а базу уже перевели на новую конфигурацию. Лечится установкой той же версии платформы, что стоит у коллег, и занимает пятнадцать минут.
Отдельная история с релизами, которые меняют структуру данных. Такие обновления после установки долго перестраивают таблицы, и остановить процесс нельзя. На базе в 20 ГБ реструктуризация занимает от двадцати минут до полутора часов, на слабом диске дольше. Это не зависание, это нормальная работа, и её нужно закладывать в план.
Само обновление: где спотыкаются чаще всего
Обновление типовой конфигурации без доработок выполняется в конфигураторе через мастер и вопросов обычно не вызывает. Проблемы начинаются там, где конфигурация менялась под компанию.
Признак доработанной базы виден сразу: в конфигураторе рядом с названием конфигурации стоит замок в открытом виде, а при обновлении программа предлагает сравнить и объединить изменения. Если вы увидели окно сравнения с деревом объектов и галочками, дальше самостоятельно лучше не идти. Неверно объединённая доработка ломает проведение документов или расчёт, и увидите вы это не сразу, а через неделю, на закрытии месяца.
Второе место, где спотыкаются: обновление на компьютере пользователя вместо сервера. В клиент-серверной базе конфигурацию обновляют один раз на базе, а не на каждом рабочем месте. На местах обновляется только платформа, и то не всегда: тонкий клиент умеет догружать нужную версию сам, если это настроено.
Третье: обновление при работающих пользователях. Программа потребует монопольного режима, но в некоторых конфигурациях есть возможность продавить обновление силой. Делать этого не нужно. Документы, проводимые в момент перестройки таблиц, записываются наполовину, и потом эти движения приходится искать вручную.
И небольшая деталь, которая экономит нервы: перед обновлением выключите регламентные задания. Обмен с другой базой, запущенный в момент обновления, приводит к ошибкам синхронизации, и разбирать их потом дольше, чем выключить задания на час.
Проверка после обновления
Обновление считается законченным не тогда, когда программа запустилась, а тогда, когда прошли проверки. Их немного, занимают они минут двадцать.
Проведите один документ каждого вида, которым компания пользуется ежедневно: поступление, реализацию, платёжное поручение, кассовый ордер. Не создавайте новые, возьмите вчерашние и перепроведите. Если движения формируются как раньше, значит основное работает.
Сформируйте два-три ключевых отчёта и сравните цифры с теми, что были до обновления. Именно поэтому перед обновлением полезно распечатать или сохранить оборотно-сальдовую ведомость: будет с чем сравнивать. Расхождение в копейках после обновления это повод разбираться, а не списывать на округление.
Проверьте печатные формы. Обновления регулярно меняют макеты, и подпись, которая была на месте, уезжает на вторую страницу. Особенно это касается доработанных форм: они могли слететь на типовые.
Отдельно проверьте обмены и электронный документооборот. Синхронизация с зарплатной базой, выгрузка в банк, отправка ЭСЧФ: всё это нужно запустить руками и убедиться, что документы уходят. Настройки после обновления обычно сохраняются, но версия формата могла обновиться, и тогда требуется подтверждение на портале. Про типичные сложности с этим мы рассказывали в материале про ЭСЧФ в 1С.
Случай, который стоил четырёх часов
Компания на восемь пользователей обновлялась своими силами, без подрядчика. Бухгалтер скачала последний релиз, поставила его поверх версии полуторагодовой давности и обрадовалась, что обошлось без ошибок.
Проблема вылезла через две недели, на закрытии месяца. Себестоимость считалась неправильно у части номенклатуры, отчёты показывали странные цифры, часть документов имела движения, которых там быть не должно. Мы приехали разбираться.
Причина оказалась в пропущенном промежуточном релизе. Между старой и новой версией был выпуск, который менял порядок расчёта партий и содержал обработку перехода: она один раз пересчитывала накопленные данные в новый формат. Обновление поставилось напрямую, обработка перехода не отработала, и часть данных осталась в старом формате, а логика уже работала по новому.
Разбор занял четыре часа: восстановили копию до обновления в отдельную базу, прошли путь заново через промежуточный релиз, сравнили результаты, перенесли корректные данные. Если бы копии не было, история закончилась бы ручным пересчётом за полтора месяца.
Вывод простой. Список версий, с которых ставится обновление, это не формальность, а предупреждение. Программа честно пишет, откуда она умеет обновляться, и на этот текст стоит смотреть.
Сколько времени закладывать
Вопрос, на котором чаще всего ошибаются: обновление планируют на час, а оно занимает вечер.
Небольшая файловая база до 5 ГБ, один-два пропущенных релиза: от сорока минут до полутора часов вместе с проверками. Это единственный случай, когда обновление реально помещается в обеденный перерыв.
База 10–30 ГБ, клиент-серверный вариант: два-три часа. Основное время съедает реструктуризация, и предсказать её точно нельзя, потому что она зависит от того, какие таблицы затронуты.
Разрыв в пять и более релизов: планируйте день. Каждый промежуточный релиз ставится отдельно, между ними идёт обновление структуры, и суммарно это долго даже на маленькой базе.
Обновление доработанной конфигурации: от нескольких часов до нескольких дней, и здесь оценку даёт тот, кто будет объединять изменения. Универсальных цифр нет: всё зависит от того, сколько объектов затронуто и насколько сильно они разошлись с типовыми.
К любой из этих оценок стоит добавить время на проверку и запас на откат. Практическое правило, которым мы пользуемся: удвоить ожидаемое время и не начинать обновление, если до конца рабочего дня осталось меньше этого срока. Прерванное на середине обновление обходится дороже, чем перенос на следующий вечер.
Чек-лист на одну страницу
Собрали всё в короткий список. Его удобно распечатать и отмечать пункты по ходу дела, особенно если обновление делается раз в квартал и порядок успевает забыться.
- До обновления. Все вышли из базы. Сделана и проверена копия. Записана текущая версия конфигурации. Сохранена оборотно-сальдовая ведомость для сверки. Выключены регламентные задания. Есть запас времени: минимум два часа для маленькой базы, вечер целиком для большой.
- Во время. Проверен список версий, с которых ставится релиз. При появлении окна сравнения и объединения работа останавливается и зовётся специалист. Реструктуризация не прерывается, даже если кажется, что программа зависла.
- После. Перепроведены документы основных видов. Сверены отчёты с сохранёнными. Проверены печатные формы и обмены. Включены обратно регламентные задания. Пользователи запущены в базу и первые полчаса на связи.
Что делать, если обновление всё-таки пошло не так. Первое правило: не пытаться исправить положение новыми обновлениями. Если после установки релиза база ведёт себя странно, разворачивайте копию и возвращайтесь к рабочему состоянию, а разбираться будете на копии, в спокойном режиме и без очереди из бухгалтеров за спиной. Второе: зафиксируйте, что именно сломалось, желательно с номерами документов и скриншотами. Формулировка «после обновления всё поехало» не помогает никому, а «в реализации №1245 от 12 августа пропала колонка НДС в печатной форме» сокращает разбор до получаса.
И третье, менее очевидное. Проверьте, не откатилась ли вместе с обновлением какая-нибудь настройка. Обновления иногда сбрасывают персональные настройки отчётов, состав колонок в журналах и правила обмена. Данные при этом целы, но пользователю кажется, что программа сломалась. Пятиминутная настройка формы возвращает всё на место.
Отдельно про частоту. Компании, которые обновляются раз в месяц, тратят на это в среднем час и почти никогда не сталкиваются с сюрпризами. Компании, которые обновляются раз в год, тратят день, а иногда и два, потому что за год накапливаются промежуточные релизы, изменения форм отчётности и новые проверки при проведении. Регулярность здесь дешевле, чем кажется.
И последнее. Если конфигурация доработана, самостоятельные обновления перестают быть рутиной навсегда. В этом случае имеет смысл обсудить с подрядчиком перенос доработок в расширения: тогда типовая обновляется штатно, а доработки живут отдельно и переживают обновление без объединения кода.
