При обновлении доработанных конфигураций 1С с большим разрывом между исходным и целевым релизами важно разделять изменения в логике типового решения и ошибки, вызванные некорректным переносом доработок. Сделанный первым этапом анализ поведения программы в «эталонной» среде может существенно сэкономить время и трудозатраты.
«Переписанный» календарь и разрыв в 30 релизов
На очередном проекте сложного обновления нашей команде пришлось столкнуться со следующей задачей.
- Конфигурация: 1С:ERP. Управление холдингом.
- Исходный релиз: 3.2.1.83.
- Целевой релиз: 3.2.8.18.
- Объект анализа: отчет «Платежный календарь» ( ПлатежныйКалендарьУХ ).
- Степень доработки: высокая — изменены модуль объекта, модуль менеджера, СКД и все 15 форм отчета. Одна из доработок Платежного календаря была связана с расширением периода построения и всей функциональности отчета на архивные периоды.
После обновления пользователи потеряли возможность проводить документы РаспоряжениеНаПеремещениеДенежныхСредств, созданные через календарь, с датой списания меньше даты документа. Система блокировала проведение сообщением: «Дата платежа не может быть меньше даты документа».
Первый фильтр: почему мы начали с чистых баз, а не с поиска ошибок в коде
Учитывая масштаб изменений в объекте, традиционный путь «отладка в текущей базе — анализ доработок» является заведомо не оптимальным по трудозатратам.
Принимая во внимание интенсивное развитие типовых решений 1С, при котором меняются не только интерфейсы, но и фундаментальные механизмы, например, логика контроля заполнения реквизитов, диагностика была начата с анализа в эталонных средах.
Алгоритм проверки:
- Развертывание эталонных сред: установка типовых демобаз релизов 3.2.1.83 и 3.2.8.18.
- Синхронизация настроек: настройка функциональных опций и параметров казначейства в демобазах в соответствии с базой заказчика.
- Воспроизведение: мы воспроизвели действия пользователей в типовых средах: сформировали распоряжения через Платежный календарь и вручную установили в них дату платежа раньше текущей.
Результат проверки: В демобазе релиза 3.2.1.83 документ, в котором дата списания меньше текущей, успешно провелся.
А вот в демобазе релиза 3.2.8.18 вышло сообщение об ошибке. Это подтвердило, что поведение является типовым для новых релизов ERP+УХ.
Также мы заметили, что при создании распоряжения с помощью календаря в демобазе релиза 3.2.8.9, документ создался в статусе «Не согласовано», а в базе релиза 3.2.8.18 в статусе «К оплате». Чтобы на 100% быть уверенными в том, что это изменение является типовым и обосновать это заказчику, опираясь на код, мы проанализировали типовые изменения в отчете.
«Спящий» контроль: почему старая проверка вдруг начала «кусаться»
Детальный анализ кода показал, что изменения в типовом решении затронули механизм инициализации реквизитов при программном формировании документа из формы отчета.
1. Модификация модуля формы отчета ПлатежныйКалендарьУХ
В сравнении старая (3.2.1.83) - новая (3.2.8.18) в модуле формы отчета в процедуре СохранитьПереводСобственныхСредств была добавлена строка, устанавливающая конечному документу статус «К оплате» непосредственно в момент создания:
2. Механизм контроля в модуле объекта
Код процедуры ОбработкаПроверкиЗаполнения в самом документе не менялся. В системе давно заложена логика: если документ уже имеет статус «К оплате» или «Согласовано», он не может быть проведен с датой платежа в прошлом. Ранее эта проверка просто не срабатывала из-за другого статуса по умолчанию.
Причина возникновения различия в поведении: В старом релизе при создании через «Платежный календарь» документам по умолчанию присваивался статус «Не согласовано». В этом случае условие проверки в модуле объекта не выполнялось, и система позволяла проводить распоряжения с датой платежа меньше даты документа. После обновления до версии 3.2.8.18 изменение статуса на «К оплате» в модуле формы привело к автоматической активации существующего контроля в модуле объекта, что заблокировало привычный для пользователя бизнес-процесс.
Главный урок обновления: не ищите ошибку там, где её нет
Применение эталонных демобаз в качестве «первого фильтра» диагностики позволяет:
- Сэкономить время на анализе сильно измененного кода.
- Мгновенно разделить развитие типового функционала и ошибки обновления.
- Обоснованно транслировать изменения бизнес-процесса заказчику, опираясь на стандарты вендора.
На своих проектах мы автоматизируем процесс проверки базовых действий через «1С:Автоматическое тестирование конфигураций», запуская тесты одновременно в базе до обновления, обновленной базе и новой типовой демобазе, в которой содержатся данные заказчика, но нет доработок. Это сокращает трудозатраты и улучшает качество обновления.
Вступайте в нашу телеграмм-группу Инфостарт