В практике администрирования систем на базе 1С:Предприятие нередко возникает ситуация, когда конфигурация (например, «1С:Бухгалтерия предприятия 3.0») обновляется на новый релиз, однако технологическая платформа остается устаревшей. Часто это обнаруживается не сразу, а лишь спустя некоторое время, когда пользователи уже успели ввести в систему множество новых документов. В этой статье мы подробно разберем, почему программа позволяет работать в таком режиме, какими рисками это грозит, нужно ли делать откат системы назад и как правильно исправить ситуацию по шагам.
Многие пользователи и начинающие специалисты задаются вопросом: почему система вообще позволила установить обновление и запустить базу данных, если платформа не соответствует требованиям? Давайте проанализируем технические механизмы, которые это допускают:
ОбновлениеИнформацииОВерсияхПлатформы, проверяет текущий релиз и сравнивает его с минимально необходимым. До тех пор, пока это задание не отработало или если в коде проверки произошел программный сбой, система будет пускать пользователей в базу.БП 3.0.75.58. Минимально необходимой версией платформы для него являлась 8.3.15.1830. При обновлении на старых ветках (например, 8.3.14) база успешно проходила этап реструктуризации таблиц в конфигураторе, но при запуске в режиме «1С:Предприятие» выдавала предупреждение о несоответствии, предлагая пользователю выбор: продолжить работу или закрыть программу.Программный контроль версии платформы при запуске конфигурации обычно выглядит следующим образом:
// Пример логики проверки минимальных требований платформы
МинимальнаяВерсияПлатформы = "8.3.15.1830";
ТекущаяВерсияПлатформы = ИнформацияСистемы.ВерсияПриложения;
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ТекущаяВерсияПлатформы, МинимальнаяВерсияПлатформы) < 0 Тогда
ПредупреждениеИлиОтказ = Истина;
ЗаписатьВЖурналРегистрации("Система.Платформа", УровеньЖурналаРегистрации.Предупреждение, , ,
"Внимание! Текущая версия платформы устарела. Требуется версия не ниже: " + МинимальнаяВерсияПлатформы);
КонецЕсли;
Продолжение работы пользователей в базе данных, конфигурация которой опережает версию технологической платформы, связано с серьезными техническими рисками. Рассмотрим их подробнее:
Логическое повреждение структуры данных. Новые релизы конфигураций активно используют оптимизированные механизмы СУБД, новые типы индексов и измененные типы данных в таблицах. Старая платформа не умеет корректно обрабатывать эти нововведения. При записи документов могут возникать «невидимые» ошибки: битые ссылки, незаполненные реквизиты или некорректная запись движений по регистрам накопления и сведений.
Сбои при выполнении регламентных процедур. Критически важные фоновые задания (такие как расчет себестоимости, закрытие месяца, расчет амортизации) могут аварийно завершаться без вывода явного предупреждения на экран пользователя. В результате регламентированный учет будет вестись некорректно.
Проблемы с государственными интеграциями и отчетностью. Современные механизмы обмена данными с ЕГАИС, системой маркировки «Честный ЗНАК», а также модули отправки регламентированной отчетности («1С-Отчетность») и электронного документооборота (ЭДО) задействуют системные библиотеки шифрования и криптографии последних версий платформы. На старой платформе эти функции перестают работать или формируют некорректные пакеты данных для контролирующих органов.
Конфликты и падение расширений. Если в вашей информационной базе установлены расширения конфигурации, разница в версиях платформы приведет к тому, что расширения либо полностью отключатся, либо заблокируют запуск всей системы.
Выясним, стоит ли возвращаться к копии базы данных, сделанной до обновления. Откат назад — это крайняя и нежелательная мера. Если пользователи уже работали в базе и создавали новые документы, восстановление старого бэкапа приведет к безвозвратной потере всей внесенной информации. Вам придется вручную восстанавливать первичные документы, перепроверять проводки и заново вводить справочники.
В 99% подобных случаев правильным решением является обновление технологической платформы до актуального стабильного релиза с последующей комплексной профилактикой информационной базы. Это позволит сохранить все внесенные данные и восстановить полную работоспособность системы.
Разберем по шагам правильную последовательность действий, которая позволит устранить последствия работы на несоответствующей платформе и гарантирует целостность базы данных.
Перед началом любых технических работ обязательно обезопасьте данные:
1Cv8.1CD в отдельную папку.Установите актуальную стабильную версию платформы «1С:Предприятие», рекомендованную для вашей конфигурации. Помните о следующих правилах:
Временные файлы (кэш), сформированные при работе старой платформы с обновленной конфигурацией, гарантированно будут вызывать фантомные ошибки даже после установки нового ПО. Нам необходимо выполнить очистку кэша. Рассмотрим основные способы:
/ClearCache.Если ваша база данных файловая, перед запуском конфигуратора рекомендуется проверить базу на наличие физических повреждений таблиц:
C:\Program Files\1cv8\8.3.XX.YYYY\bin\).chdbfl.exe.1Cv8.1CD.Запустите информационную базу в режиме «Конфигуратор» под управлением новой платформы. Перейдите в меню Администрирование — Тестирование и исправление. Проанализируем настройки, которые необходимо выставить для лечения базы:
После успешного завершения тестирования запустите базу в режиме «1С:Предприятие». Найдите документы, которые создавались пользователями в период работы на некорректной платформе, и выполните их выборочное групповое перепроведение. Это заставит систему заново рассчитать движения по регистрам с использованием механизмов новой платформы и исключит появление расхождений в отчетах.
Соблюдение этого алгоритма позволит вам быстро вернуть систему в штатный режим работы, минимизировав риски потери важных бизнес-данных и избежав трудоемкого ручного ввода документов.