Переход программного продукта 1С:Розница с ветки 2.2.6 на 2.2.7 является одним из самых сложных этапов в истории развития конфигурации. Это связано не просто с добавлением нового функционала, а с глобальной реструктуризацией базы данных. Разработчики подготовили систему к требованиям 54-ФЗ и форматам фискальных данных (ФФД) 1.05 и 1.1, что потребовало изменения архитектуры хранения информации о платежах.
Разберем типичную ситуацию: при обновлении через конфигуратор база выдает ошибки, связанные с отсутствием табличных частей (например, ОплатаПлатежнымиКартами), или зависает на определенных этапах выполнения дополнительных процедур обработки данных. Проанализируем причины возникновения таких проблем и выработаем четкий алгоритм действий для их решения.
Основная сложность заключается в том, что в версии 2.2.7 произошло объединение нескольких табличных частей документов (таких как ОтчетОРозничныхПродажах) в одну универсальную таблицу Оплаты. Ранее в документе существовали отдельные вкладки для наличной оплаты и оплаты картами. Теперь же всё хранится в единой структуре.
Ошибка «отсутствие табличной части ОплатаПлатежнымиКартами» возникает в тот момент, когда метаданные конфигурации уже обновились и старая таблица была удалена, но фоновые обработчики обновления всё еще пытаются обратиться к ней по старому имени. Рассмотрим основные факторы, провоцирующие этот сбой:
ОтчетОРозничныхПродажах, они могут «удерживать» старую структуру метаданных, мешая корректному завершению реструктуризации..1CD блокирует корректный перенос данных из старых таблиц в новые.Процесс обновления 1С состоит из двух частей: обновления метаданных в конфигураторе и выполнения отложенных обработчиков в пользовательском режиме. Часто обновление «затыкается» на этапе 16 из 29 (или близких к нему). Посмотрим, что происходит в этот момент.
На данном этапе система выполняет перенос записей об эквайринговых операциях. Если в базе накоплено большое количество документов с некорректно заполненными видами оплат (например, пустая ссылка на эквайринговый терминал или нулевая сумма при отмеченном флаге оплаты картой), стандартный обработчик может войти в бесконечный цикл или аварийно завершиться. В такой ситуации пользователь видит, что процесс «висит», а в журнале регистрации множатся ошибки доступа к данным.
Прежде чем приступать к повторным попыткам обновления, выполним обязательные регламентные операции. Помним, что все действия проводятся только при наличии свежей резервной копии.
chdbfl.exe, которая находится в папке bin установленной платформы 1С. Это критически важно для файловых баз. Проанализируем лог: если найдены ошибки в таблицах, связанных с оплатами, исправляем их.Опыт показывает, что для стабильного перехода на Розницу 2.2.7.40 версии 8.3.10 может быть недостаточно, несмотря на минимальные системные требования. Рассмотрим рекомендуемый вариант:
Попробуем использовать платформу версии 8.3.12.1529 или выше. В этих версиях исправлено множество ошибок, связанных с динамическим обновлением метаданных и реструктуризацией тяжелых таблиц. Если база работает в клиент-серверном варианте, убедимся, что версия сервера совпадает с версией клиента.
Если обновление с 2.2.6.22 сразу на 2.2.7.40 дает сбой, применим тактику последовательных переходов. Разберем этот путь по шагам:
Если обновление все же зависло на 16-м этапе, мы можем вмешаться в процесс программно. Рассмотрим, как это сделать через справочник ОбновлениеИнформационнойБазы.
Перейдем в «Функции для технического специалиста» (ранее «Все функции») и найдем справочник «Обновление информационной базы». В нем отображается список всех процедур. Если мы видим процедуру со статусом «Ошибка» или «Выполняется» (при фактическом отсутствии активности), мы можем проанализировать журнал регистрации, исправить данные в документах, вызывающих сбой, и запустить процедуру повторно.
В крайних случаях, если данные в конкретном обработчике не являются критичными (например, старая аналитика, которая не используется), программисты иногда принудительно устанавливают статус «Выполнено» для «зависшей» строки. Внимание: это действие может привести к потере части данных в отчетах, поэтому используйте его только как крайнюю меру.
Часто бывает так: обновились с ошибками, но магазин продолжил работу, принимал накладные ЕГАИС и торговал. Теперь в базе есть новые документы, но сама она работает некорректно. Разберем алгоритм «грамотного отката»:
ВыгрузкаЗагрузкаДанныхXML.epf.Этот метод позволяет сохранить GUID-ы объектов и восстановить работоспособность системы без потери данных, введенных в период «кривого» обновления.
Рассмотрим еще один нюанс: в версии 2.2.7 произошли изменения в механизме сопоставления алкогольной продукции. Если после обновления «слетело» сопоставление производителей или поставщиков, проанализируем справочник ПроизводителиИИмпортерыАлкогольнойПродукции. Часто проблема кроется в дублях контрагентов. Перед обновлением рекомендуется запустить стандартную обработку «Поиск и удаление дублей» для всех справочников, связанных с алкоголем.
Посмотрим на пример кода, который помогает проверить наличие незавершенных обработчиков обновления через консоль кода (если база позволяет запуск внешних обработок):
Выборка = Справочники.ОбновлениеИнформационнойБазы.Выбрать();
Пока Выборка.Следующий() Цикл
Если Выборка.Статус = Перечисления.СтатусыОбработчиковОбновления.Ошибка Тогда
Сообщить("Ошибка в обработчике: " + Выборка.ИмяПроцедуры);
КонецЕсли;
КонецЦикла;
Подводя итог, можно сказать, что успешное обновление до 2.2.7.40 требует терпения и чистоты исходных данных. Проанализировав состояние табличных частей и обеспечив платформенную поддержку, мы сможем преодолеть архитектурный барьер между версиями 1С:Розница.