Обновление конфигурации 1С, которая не видела обновлений более 5-6 лет, — это не просто техническая процедура, а полноценный проект по реинжинирингу системы. В нашем случае мы имеем дело с 1С:Общепит (релиз 3.0.66 от 2018 года), которую нужно довести до актуального состояния (3.0.195). Разберем пошагово, как минимизировать риски и сохранить работоспособность базы.
Прежде чем приступать к каким-либо манипуляциям с конфигуратором, нам необходимо понять, что именно было изменено в коде за эти годы. Проанализируем ситуацию: если в базе изменены только программные модули (без добавления новых реквизитов и справочников), это упрощает задачу, но не делает ее тривиальной. Проблема в том, что за 8 лет логика типового решения могла измениться на 80-90%.
Рассмотрим алгоритм предварительного анализа:
1С:Бухгалтерия или 1С:Общепит последних версий.Этот метод считается наиболее правильным с точки зрения сохранения истории данных. Основная идея заключается в том, чтобы сделать конфигурацию максимально близкой к типовой, а все необходимые доработки реализовать через механизм расширений.
Разберем этот процесс по шагам:
Шаг 1: Перенос кода в расширение. Не пытайтесь сразу обновить базу. Сначала создайте новое расширение и перенесите туда программную логику. Используйте современные аннотации, такие как &Вместо, &После или &Перед. Это позволит «отвязать» ваш код от типовых модулей.
Пример оформления процедуры в расширении:
&После("ОбработкаПроведения")
Процедура ИН_ОбработкаПроведенияПосле(Отказ, РежимПроведения)
// Ваша уникальная логика, которая должна выполниться после типовой
Если Не Отказ Тогда
// Дополнительные движения или проверки
КонецЕсли;
КонецПроцедуры
Шаг 2: Возврат на поддержку. После того как код вынесен, необходимо вернуть базу к полностью типовому виду. Для этого в конфигураторе выберите «Конфигурация — Поддержка — Настройка поддержки» и используйте сравнение/объединение с типовым cf файлом того же релиза (3.0.66), установив режим «Взять из конфигурации поставщика» для всех объектов.
Шаг 3: Последовательное обновление через «узловые» релизы. Вы не сможете «прыгнуть» с релиза 2018 года сразу в 2024-й. Существуют переходные релизы, на которых происходят критические изменения структуры данных или версии платформы. Посмотрим на важные моменты:
Если база за 8 лет накопила огромное количество «мусора», ошибок в регистрах или если доработок было слишком много, проще и быстрее будет создать чистую базу актуального релиза. Рассмотрим преимущества этого подхода:
3.0.195.Проанализируем технологию переноса:
Для реализации этого метода используем типовую обработку «Выгрузка и загрузка данных XML» или настроим правила в Конвертации данных. Нам необходимо перенести:
При обновлении с 2018 года мы столкнемся с фундаментальными изменениями в ядре системы (БП 3.0), на котором построен «Общепит»:
1. Новые ФСБУ: За эти годы вступили в силу ФСБУ 5/2019 (Запасы), ФСБУ 6/2020 (Основные средства), ФСБУ 25/2018 (Аренда). Алгоритмы проведения документов по этим направлениям изменились полностью. Старый доработанный код может просто не найти нужных полей в регистрах.
2. Налоговый учет и ЕНС: Введение Единого налогового счета (ЕНС) и Единого налогового платежа (ЕНП) кардинально изменило структуру регистров по налогам и зарплате. Если ваши доработки касались выплат или налогов, их придется переписывать с нуля.
3. Прослеживаемость и маркировка: В новых релизах появились мощные подсистемы интеграции с Честным ЗНАКом и ГИС МТ. Проверьте, не дублируют ли ваши старые интеграции этот функционал.
Выясним, как проверить, что обновление прошло успешно. Главный инструмент бухгалтера и программиста в этом случае — Оборотно-сальдовая ведомость.
Сравним ОСВ в старой базе и в новой (или обновленной) на одну и ту же дату. Особое внимание уделим следующим счетам:
Важный совет: Если вы решили переносить код в расширение, помните, что в релизах 2018 года механизм расширений был ограничен. Полную проверку работоспособности расширения можно проводить только на финальном, актуальном релизе конфигурации, используя возможности платформы 8.3.22 и выше.
Подводя итог, скажем: для маленькой базы с минимальными правками подойдет последовательное обновление. Для большой базы с историей в 8 лет наиболее рациональным выбором будет перенос остатков в чистую конфигурацию с последующей реализацией необходимых функций в виде расширений.