Работа с запущенными базами 1С, где предыдущие специалисты «фрагментарно» обновляли объекты (выдергивали куски кода или метаданных из свежих релизов и вставляли в старые), — это классический пример борьбы с тяжелым техническим долгом. Основная сложность здесь заключается не столько в количестве пропущенных релизов, сколько в нарушении целостности структуры метаданных и риске потери данных при попытке привести всё к стандартному виду. Рассмотрим подробный алгоритм действий, который позволит выйти из этой ситуации с минимальными потерями.
Прежде всего, разберем ситуацию. Имеется 1С:Бухгалтерия для Казахстана ред. 2.0. Конфигурация типовая, но доработанная. При этом в старый релиз (например, 2.0.6.3) были вручную добавлены объекты из гораздо более поздних версий. Главная опасность здесь кроется в GUID (внутренних идентификаторах). Когда вы просто копируете документ или реквизит из одной базы в другую через Сравнение/Объединение, система может создать новый объект с новым уникальным идентификатором. Если позже вы попытаетесь накатить официальное обновление, 1С не «узнает» ваш вручную добавленный объект. Она посчитает его чужеродным и попытается создать свой (официальный), а ваш — удалить или оставить как «нетиповой», что приведет к дублированию или потере данных в полях.
Проанализируем основные опасности:
Предприятие, ожидают увидеть определенную структуру. Если структура «перекошена» ручными вставками, код может отработать с ошибками, оставив базу в промежуточном, нерабочем состоянии.Первым делом нам необходимо вернуть базу на «рельсы» официальной поддержки. Если конфигурация поставщика (та, что находится под замком) не соответствует реальному релизу основной конфигурации, обновление будет происходить некорректно. Рассмотрим, как это сделать:
Выясним точный номер релиза, которому соответствует основная конфигурация. Затем найдем файл .cf именно этого релиза. В конфигураторе перейдем в меню Конфигурация — Поддержка — Настройка поддержки. Если база уже «снята с замка», нам нужно загрузить конфигурацию поставщика из .cf файла соответствующей версии. Это позволит системе снова понимать, какие объекты являются типовыми, а какие — измененными относительно конкретной точки отсчета.
Существует два основных подхода при большом количестве пропущенных обновлений (в нашем случае — 31 релиз):
Способ А: Пошаговое обновление через .cfu. Это самый надежный, но и самый долгий путь. Мы скачиваем все промежуточные файлы обновления и последовательно их применяем. Важно на каждом шаге (или на ключевых релизах) запускать базу в режиме Предприятие.
Способ Б: Обновление через полный .cf файл. Рассмотрим этот метод подробнее, так как он экономит время, но требует предельной внимательности:
.cf файл актуального релиза (например, 2.0.29).Конфигурация — Сравнить, объединить с конфигурацией из файла.Документ.АвансовыйОтчет) в основной конфигурации имеет реквизиты, которых нет в конфигурации поставщика старого релиза, но они есть в новом — мы должны убедиться, что система правильно сопоставила их.Для максимально безопасного переноса доработок в условиях «каши» из релизов, проанализируем ситуацию с помощью трех конфигураций:
Сравнивая А и Б, мы находим ВСЕ изменения, внесенные программистами. Сравнивая А и В, мы видим все изменения, внесенные фирмой 1С. Наша задача — в конфигурацию В перенести из Б только те изменения, которые являются уникальными доработками, и проигнорировать те, которые теперь стали частью типового функционала конфигурации В.
Разберем пример из сообщения пользователя: в базу был внедрен документ из будущего релиза. Чтобы при обновлении не затереть данные, выполним следующие действия:
Посмотрим на настройки сравнения. Если система предлагает «Удалить» ваш старый реквизит и «Добавить» новый типовой с тем же именем — это признак того, что GUID не совпадают. В этом случае:
Выборка = Документы.АвансовыйОтчет.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Выборка.ПолучитьОбъект();
Объект.НовыйТиповойРеквизит = Объект.СтарыйСамопальныйРеквизит;
Объект.Записать();
КонецЦикла;
Только после того как данные перенесены, можно удалять «самопальный» объект в конфигураторе.
Выясним, почему нельзя просто «накатить» финальный .cf и успокоиться. В 1С:Бухгалтерии (особенно для Казахстана, где часто меняется налоговое законодательство, формы ЭСФ и СНТ) каждый релиз содержит обработчики обновления. Они могут:
Если вы прыгнете через 20 релизов одним махом, платформа может запустить только обработчики последнего релиза, пропустив промежуточные. Это приведет к «битой» базе. Рекомендуем делать «остановки» на ключевых релизах. Обычно это релизы, где меняется вторая или третья цифра версии (например, с 2.0.6 на 2.0.15, затем на 2.0.25 и так далее). В режиме Предприятие обязательно дождитесь окончания работы всех фоновых заданий по обновлению.
Проанализируем ситуацию с точки зрения долгосрочной поддержки. Чтобы облегчить себе жизнь в будущем, придерживайтесь следующих правил:
//+ СвойПрефикс НазваниеЗадачи Дата
// Ваш код
//- СвойПрефикс
Процесс обновления «запущенной» базы 1С — это кропотливая работа по сопоставлению метаданных. Не пытайтесь сделать это быстро одним нажатием кнопки Загрузить конфигурацию из файла, так как это гарантированно уничтожит уникальные идентификаторы объектов и приведет к потере данных. Используйте только Сравнить/Объединить, внимательно анализируйте каждый флажок в дереве объектов и не забывайте про запуск базы в пользовательском режиме на промежуточных этапах. Только такой системный подход гарантирует сохранность данных и корректную работу алгоритмов бухгалтерского и налогового учета Казахстана.