Рано или поздно любой специалист по автоматизации сталкивается с ситуацией, когда крупная производственная база на базе 1С:Управление производственным предприятием (УПП) ред. 1.3 долгое время не обновлялась, поскольку «все и так работало». Но внезапно от бухгалтерии и отдела кадров поступает срочная задача: сдать новую регламентированную отчетность или рассчитать зарплату по изменившемуся законодательству. Выясняется, что конфигурация отстала от актуальных релизов более чем на год, а сама база при этом сильно доработана («переписана вхлам» предыдущими разработчиками).
В этой статье мы подробно проанализируем, как правильно подойти к решению этой сложной задачи, разберем технологические риски частичного обновления по подсистемам и рассмотрим оптимальные алгоритмы обновления, а также альтернативные архитектурные решения.
Первое побуждение, которое возникает у разработчика в условиях жесткого дефицита времени — обновить только то, что требуется. Например, перенести изменения только по подсистемам Зарплата, Кадры и РегламентированнаяОтчетность, оставив нетронутыми производство, склад и продажи.
Рассмотрим подробнее, почему этот подход является критической ошибкой:
ФизическиеЛица, Организации, ПодразделенияОрганизаций) и вызывают процедуры из общих модулей. Если обновить только часть объектов, система начнет выдавать ошибки компиляции из-за отсутствия новых реквизитов, функций или параметров в методах.Вывод: Обновлять конфигурацию по подсистемам категорически нельзя. Необходимо обновлять всю конфигурацию целиком.
Прежде чем приступать к каким-либо действиям с рабочей базой, выполним обязательные подготовительные шаги:
cf) того же релиза. Это позволит нам локализовать измененные объекты, составить список уникальных доработок и оценить трудозатраты.Если база содержит множество уникальных кастомных механизмов, простое обновление через стандартный поиск доступных обновлений сотрет все доработки. Проанализируем правильный алгоритм обновления сильно измененной конфигурации вручную с использованием метода трехстороннего сравнения:
Рассмотрим пример того, как может выглядеть переопределение обработки заполнения в модуле документа при ручном слиянии кода:
// Исходный код типовой конфигурации нового релиза
Процедура ОбработкаЗаполнения(ДанныеЗаполнения, ТекстовыйДокумент)
// Типовой алгоритм заполнения реквизитов
ЗаполнитьТиповыеРеквизиты(ЭтотОбъект, ДанныеЗаполнения);
// Вставка нашего уникального доработанного механизма
// Проверяем наличие специфических данных заполнения для нашей компании
Если ТипЗнч(ДанныеЗаполнения) = Тип("СправочникСсылка.СпецификацииНоменклатуры") Тогда
ЗаполнитьПоУникальнойСпецификации(ЭтотОбъект, ДанныеЗаполнения);
КонецЕсли;
КонецПроцедуры
После завершения объединения обязательно выполняем синтаксический контроль (Сервис — Параметры — Синтаксический контроль) для всей конфигурации, чтобы исключить синтаксические ошибки в модулях.
После того как метаданные успешно объединены в Конфигураторе и база сохранена (клавиша F7), критически важно правильно выполнить запуск системы в режиме «Предприятие».
При каждом переходе на промежуточный или узловой релиз необходимо запускать базу от имени пользователя с административными правами. В этот момент запускается механизм обновления информационной базы. Система выполняет отложенные обработчики обновления: заполняет новые константы, реструктуризирует таблицы регистров, переносит данные из устаревших реквизитов в новые структуры.
Если проигнорировать этот шаг и попытаться последовательно применить несколько обновлений в конфигураторе подряд без промежуточного запуска в режиме «Предприятие», данные в базе будут безнадежно испорчены, так как обработчики последующих релизов будут пытаться обратиться к данным, которые не были подготовлены обработчиками предыдущих релизов.
Для контроля этого процесса мы можем программно отслеживать ход выполнения обновлений, используя типовые механизмы БСП (если они внедрены) или специализированный журнал регистрации. В кодовой базе за запуск этих процедур отвечает общий модуль:
// Пример системного вызова инициализации обновления данных
ОбновлениеИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы();
Если ручное последовательное обновление 20 релизов занимает у разработчика колоссальное количество времени, имеет смысл автоматизировать рутинные операции. Для этого отлично подходит специализированный софт, например, «Обновлятор-1С».
Выясним, как правильно использовать автоматизацию в нашем сценарии:
РеализацияТоваровУслуг, ТребованиеНакладная) или модули расчета себестоимости, автоматика может перезаписать ваш код. В этом случае «Обновлятор» используют для автоматического наката обновлений на те участки, которые не подвергались изменениям, либо для автоматизации рутинных запусков между сессиями ручного слияния кода.Давайте посмотрим на ситуацию стратегически. Обновление сильно кастомизированной, тяжелой системы 1С:УПП 1.3 только ради того, чтобы сдать отчетность и рассчитать зарплату — это невероятно дорогой, долгий и системно неэффективный процесс.
Современный архитектурный подход диктует совершенно иное решение: разделение контуров учета.
Вместо того чтобы тратить недели работы высокооплачиваемых программистов на постоянную актуализацию «переписанной» УПП, целесообразно выполнить следующие шаги:
Этот подход раз и навсегда решает проблему зависимости производственного контура от частых законодательных изменений в части отчетности и зарплаты. Оперативную базу УПП после этого можно не обновлять годами (или обновлять крайне редко при изменении производственных процессов), а регламентированные базы ЗУП и БП будут обновляться в пару кликов.
Принимая решение о вливании бюджета в обновление текущей УПП, необходимо обязательно донести до руководства и заказчика важную информацию о жизненном цикле данного программного продукта:
Таким образом, наилучшей тактикой в текущей ситуации будет временное оперативное обновление УПП полностью последовательным методом (с привлечением разработчиков для ручного слияния кода на копии), с параллельным запуском проекта по переходу на 1С:ERP или выносу регламентированных блоков в специализированные типовые решения.