1С

Типовой механизм упрощенного изменения конфигурации в ERP 2.0 и УТ 11

В ERP 2.0 (и соответственно в УТ 11) появился функционал для упрощенной возможности модификации конфигурации разработчиками. Он касается в частности изменения форм объектов и размещения подписок на элементы, теперь задача изменения конфигурации на поддержке упростилась. Также появились дополнительные возможности в новой версии платформы 8.3.5, которые также упростят задачу.

В ERP 2.0 (и соответственно в УТ 11) появился функционал для упрощенной возможности модификации конфигурации разработчиками. Он касается в частности изменения форм объектов и размещения подписок на элементы, теперь задача изменения конфигурации на поддержке упростилась. Также появились дополнительные возможности в новой версии платформы 8.3.5, которые также упростят задчу.

Этот функционал представлен следующим блоком общих модулей (разбивка на наш взгляд):

1)      События форм. Этот блок представлен двумя общими модулями -  «События Форм» и «События Форм Клиент».

Если вернуться в статьям о механизмах минимального изменения конфигураций, то эти два модуля позволяют разместить динамически элементы и обработчики на форме и обрабатывать их. В модуле «События Форм» находится процедура «ПриСозданииНаСервере», которая вызывается из практически каждой формы в функции формы «ПриСозданииНаСервере». Соответственно в ней удобно разместить код позволяющий создавать динамически элементы на формах и обработчики событий этих форм. К примеру, можно это сделать следующим образом:

Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;

Однако разработчики предложили перенести этот код в общий модуль «МодификацияКонфигурацииПереопределяемый». И из процедуры идет еще один вызов:

МодификацияКонфигурацииПереопределяемый.ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка);

Для отработки динамических команд элементов практически в каждой форме добавлена только одна обезличенная процедура Подключаемый_ВыполнитьПереопределяемуюКоманду, обрабатывать события предлагается в специальных общих модулях – «События Форм Клиент». Решение элегантное. С общим модулем «События Форм Клиент» ситуация аналогичная, в нем происходит перевозов процедуры.

2)      Модификация конфигурации. Этот блок представлен следующими общими модулями:

«Модификация Конфигурации Вызов Сервера Переопределяемый», «Модификация Конфигурации Клиент Переопределяемый», «Модификация Конфигурации Клиент Сервер Переопределяемый», «Модификация Конфигурации Переопределяемый».

В каждой форме документа коллеги вставили следующий код для поддержки механизма модификации конфигурации. На серверной части:

  • В процедуре «ПриСозданииНаСервере» вызывается «СобытияФорм.ПриСозданииНаСервере»;
  • В процедуре «ПриЧтенииНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПриЧтенииНаСервере»;
  • В процедуре «ПослеЗаписиНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПослеЗаписиНаСервере»;
  • В процедуре «ПередЗаписьюНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПередЗаписьюНаСервере»;

На клиентской части:

  • В процедуре «ПослеЗаписи» вызывается функция «МодификацияКонфигурацииКлиентПереопределяемый.ПослеЗаписи»;
  • И универсальная процедура для обработки событий для всех элементов формы на клиенте «Подключаемый_ВыполнитьПереопределяемуюКоманду».

Для обработки действий связанных с инициализацией, обработкой событий необходимо провести проверку по условию принадлежности к той или иной форме. Для этого необходимо воспользоваться свойством наименование управляемой формы, к примеру, сделать это в следующем виде:

Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;

И для обработки команд дополнительное условие:

Если Команда.Имя= «Команда_Х» Тогда
ИначеЕсли ….
КонецЕсли;

3)      Особенности. К особенностям можно отнести некоторые специфические моменты.

Во-первых, пока не во всех формах и списках добавлена поддержка этого механизма. Вполне возможно, что в бедующих релизах этот пробел будет восполнен.

Во-вторых, в некоторых случаях разработчики сами используют блок динамической инициализации обработчиков изменений элементов. При первоначальном включении в их блок мы сперва очень удивились, что почему-то некоторые наши обработчики не совсем адекватно и не всегда отрабатывают в некоторых документах. Объяснение этому простое, как оказалось для документов в которых используется механизм согласование: Заказ Клиента, Реализация Товаров и Услуг и др.; используется динамическое создание подписок на события изменения элементов, которое происходит после нашей точки инициализации (в процедура При создании на сервере). На сброс флага согласован влияет множество изменений реквизитов и чтобы не обрабатывать каждый реквизит в отдельности они создают динамическую привязку события изменения к одной функции. К тому же эта операция происходит не всегда, а зависит от статусов документа.

В связи с этим при данную ситуацию необходимо обрабатывать самостоятельно, если у вас есть необходимость повестить свою обработку событий на эти реквизиты.

Зато можно воспользоваться готовой встроенной функцией для установки подписки на событие элемента формы:

ОбщегоНазначенияУТ.УстановитьПодпискуНаСобытияИзмененияЭлементовФормы(ЭтаФорма, МассивЭлементов, УстановитьПодписку);

В третьих, не все случаи по прежнему удается обрабатывать данным нововведением. Хотя это уже большой плюс. И мы выражаем глубокий респект разработчикам конфигурации ERP 2.0 за такую возможность.

4)      Бонус. Правила которые мы используем при доработках типовых конфигураций.

  • Добавление своих объектов метаданных с префиксом. Мы добавляем префикс в таком формате «DI_»+наименование объекта. Иногда используется вариант добавления префикса поле наименования: наименование объект+ «DI»; но этот вариант менее нагляден. Для дополнительной фильтрации новых объектов создается своя подсистема, в которую включаются все новые объекты.
  • Добавление своих реквизитов к существующим объектам метаданных. Мы используем добавление реквизитов по аналогии с добавлением своих объектов: «DI_»+наименование реквизита.
  • Изменение форм объектов. Изменение форм объектов и подписок на элементы осуществляем динамически. Также уже используем технологию, о которой говорится выше. В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.
  • Использование модификаций запросов. В связи с нововведениями в версии платформы 8.3.5, а именно: конструктор запросов в управляемом приложении и объектная модель схемы запроса - появилась возможность более удобно вносить модификации в запросы. Если ранее пользователь создавал рваный запрос или использовал функцию СтрЗаменить, то теперь достаточно использовать объектную модель. К примеру, добавить в исходный запрос новое поле в выбранных полях:
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Запрос.Текст);
//при создании схема содержит один пакет и один оператор в пакете.
Пакет = СхемаЗапроса.ПакетЗапросов[0];
Оператор = Пакет.Операторы[0];
Оператор.ВыбираемыеПоля.Добавить(«РеализацияТоваровУслуг.Ссылка»);
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();

Ожидаем использование подобного механизма в скором будущем в текущих типовых конфигурациях.

  1. Использование подписок на события. Мы используем подписки на события для дополнительных проверок, формирования своих движение и т.д. В этом случае создается необходимая подписка на событие и формируется код проверки. Позволяет не вносить изменение в типовой функционал.
  2. Использование дополнительных команд. Для увеличения удобства интерактивной работы с нашими доработками довольно часто используем данный механизм.
  3. Поиск точки минимального изменения или воздействия. Прежде чем вносить изменения согласно задания на доработку ищем в коде тот участок, при изменении в котором понадобится минимальное число исправлений. Как вариант возможно переписывания какой-то функции целиком.
  4. Добавление реквизитов в регистры. При добавлении изменений в регистры мы поступаем по следующему правилу. Если это регистр накопления оборотный, то можем смело добавить измерение. Если это регистр накопления остатков, то в данном случае стараемся не вносить изменения в измерения и ресурсы, а создать свой новый регистр остатков. Если затрагивает реквизиты, то в данном случае можно выполнять эту операцию без проблем.
  5. Комментарии и документация. При внесении изменений мы обязательно делаем комментарии, указывая Автора, Дату, Задачу, Пояснения, вход и выход изменений. Дополнительно вносится информация в реестр изменений с такими же параметрами.
  6. Использование средств командной разработки. Мы используем механизм хранилище конфигурации, систему баг-трекинга, трехуровневое тестирование – внутренне тестирование разработчиком, тестирование таксировщиком самостоятельно и по кейсам и внешнее тестирование представителем от заказчика.
  7. Техническое задание. Хорошей практикой является формализация требований к доработкам.
  8. Другие правила.

Начать дискуссию