Информация

Использование любой информации, размещённой на настоящем сайте, в том числе любых изображений и/или их частей возможно только по письменному согласованию с правообладателем такой информации (Луньков В.Н.).
Использование любой информации, размещённой на настоящем сайте, в том числе ссылок на ресурсе infostart.ru не допускается .

Перевод конфигураций на версию 8.2 с частичным использованием управляемого приложения

В статье приведена типовая последовательность действий, которые  нужно выполнить, чтобы перевести существующую конфигурацию на версию 8.2 с частичным использованием управляемого приложения. Данная методика составлена на основе опыта частичного перевода конфигурации "Управление производственным предприятием" на управляемое приложение. Методика содержит только перечень решаемых задач. Описание используемых механизмов версии 8.2 приведено в документации.

Этап 0. Подготовка конфигурации

Прежде всего, следует адаптировать конфигурацию 1С:Предприятия 8.1 к работе на платформе 8.2 без использования режима совместимости с 8.1. Методика перевода подробно описывается в рубрике "Адаптация конфигураций 1С:Предприятия 8.1 к работе на платформе 1С:Предприятие 8.2 без режима совместимости с версией 8.1".
После этого необходимо определить список тех возможностей платформы версии 8.2, которые будут использоваться в новом прикладном решении.
На этом же этапе требуется определить функционал прикладного решения, который будет использоваться в управляемом приложении, и объем, в котором предполагается его использование.
Здесь возможны следующие варианты:
  • в управляемое приложение необходимо перенести существующий функционал исходного решения (на 8.1) - тогда вносить изменения в конфигурацию (прежде всего в программный код, а также метаданные) следует так, чтобы система оставалась работоспособной и для обычного, и для управляемого приложения, и при этом чтобы по возможности не было дублирования программного кода (либо такое дублирование было сведено к минимуму);
  • для управляемого приложения реализуется новый функционал.

Этап 1. Выполнение общих настроек

На данном этапе разработчику необходимо:
1.    Определить роли и сценарии работы пользователей (рабочие места):
  • какие пользователи будут работать в управляемом приложении,
  • определить порядок их работы,
  • как эти пользователи будут взаимодействовать с другими пользователями, в том числе с теми, которые работают в обычном приложении;
  • стоит ли создавать "рабочий стол" в конфигурации или же достаточно дать возможность настройки рабочего стола специалисту по внедрению.
2.    В процессе настройки прав доступа может потребоваться либо создать новые роли, либо уточнить доступ существующих ролей к объектам в целом. Для ролей следует настроить права доступа к реквизитам объектов метаданных. Для этого необходимо определить состав реквизитов объекта, с которыми пользователь должен работать:
  • либо все реквизиты объекта,
  • либо только некоторые реквизиты (другие недоступны пользователю с этой ролью).
3.    Создать иерархию подсистем для управляемого приложения.
4.    Создать функциональные опции в необходимом количестве, настроить их состав, (если надо) учесть в программном коде. Для этого и необходимо определить функциональность (реализованную в управляемом приложении), доступностью которой можно управлять при внедрении (эксплуатации). Функциональных опций не должно быть слишком много.
5.    Установить управляемый режим блокировок.
6.    Для регистров накопления и бухгалтерии установить (проверить, что установлены) признаки разделения итогов.
7.    Настроить агрегаты для соответствующих регистров накопления.
8.    Рассмотреть целесообразность работы с часовыми поясами.

Этап 2. Настройка интерфейсных свойств объектов конфигурации

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

Этап 3. Создание и настройка управляемых форм, отчетов

На данном этапе разработчик создает управляемые формы для объектов. При этом необходимо обеспечить работу управляемых форм и в веб-клиенте.
Можно задействовать механизм сохранения данных формы в настройках. В частности, применение механизма поможет упростить организацию ввода документов по шаблону.
Там, где необходимо, следует настроить условное оформление.
Программно изменять состав управляемой формы требуется в исключительных случаях - только там, где это необходимо и обоснованно.
Для справочников и других объектов следует настроить динамические списки. При настройке условного оформления для динамического списка следует учитывать особенности, возникающие у пользователей с разными наборами прав доступа к объектам.
На данном этапе следует создать новые отчеты и при необходимости адаптировать существующие. Наиболее эффективно создавать и адаптировать отчеты с помощью системы компоновки данных.

Этап 4. Настройка командного интерфейса

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

Этап 5. Внесение изменений в программный код

Одновременно с выполнением приведенных действий, разработчик вносит изменения в программный код. Следует определить состав общих модулей, выработать порядок их наименования. При необходимости следует провести реструктуризацию общих модулей.
Следует учитывать следующие особенности:
  • Обработчик начала работа системы в управляемом приложении будет выполнять не все действия, которые выполняются при начале работы системы в обычном приложении.
  • Следует использовать модули менеджеров объектов в соответствии с их назначением.
  • Следует использовать режим повторного использования возвращаемых значений функций общих модулей (например, в учетных политиках).
  • Метод Сообщить() не должен применяться для того, чтобы выводить сообщения пользователю о ходе процесса и должен применяться только для сообщений об ошибках (подробнее см. раздел "Работа с сообщениями пользователю".
  • Проанализировать инструкции препроцессора на корректность: обратить внимание на инструкции, указывающие, что код будет выполняться только на клиенте "#Если Клиент Тогда". Вызов такого кода может привести:
    • либо к ошибке выполнения,
    • либо код просто не выполнится.
Следует проанализировать возможные проблемы в модулях, которые могут выполняться как в толстом клиенте, так и на сервере. Например, модули объектов, общие модули.
  • Следует рассмотреть целесообразность применения новой методики записи движений при проведении документов.
  • Следует рассмотреть целесообразность отказа от обращений к "устаревшим" именам свойств и методам, например:
    • Свойство ИмяПараметровПечати,
    • Метод ПользователиWindows().

Заполнение реквизитов нового объекта

В платформе 1С:Предприятие 8.2 логика заполнения реквизитов объекта должна располагаться в конкретном месте – в модуле объекта в процедуре ОбработкаЗаполнения().
Платформа 1С:Предприятие 8.1 ведет себя иначе: при вводе нового объекта не "на основании" процедура модуля документа ОбработкаЗаполнения() не вызывается.
Поэтому логика заполнения реквизитов нового объекта может быть расположена в разных местах, например так:
  • в модуле объекта в процедуре ОбработкаЗаполнения(): заполняются реквизиты нового документа при вводе на основании,
  • в модуле формы объекта в процедурах ПриОткрытии(), ПередОткрытием() заполняются реквизиты нового объекта при любом способе создания документа (ввод на основании, копирование, "простое" создание).
Поэтому, при переводе конфигурации на версию 8.2 необходимо проанализировать, не следует ли перенести логику заполнения реквизитов нового объекта из модуля формы (процедур ПриОткрытии, ПередОткрытием) в модуль объекта (процедура ОбработкаЗаполнения()).
При этом следует учитывать, что ОбработкаЗаполнения() не вызывается при копировании объекта.

Проверка заполнения реквизитов

Следует использовать средства автоматической проверки заполнения реквизитов, предоставляемые платформой 1С:Предприятие 8.2.
При этом следует учитывать следующее:
В платформе версии 8.2 реализована возможность предотвращать ввод некорректных данных, используя свойство Параметры выбора. Поэтому, некоторые проверки ввода, реализованные программно в версии 8.1, в управляемых формах создавать не надо. В это же время, свойство Параметры выбора не влияют на поведение обычной формы,и поэтому при переходе с версии 8.1 на версию 8.2 в обычных формах такие проверки должны остаться.
Следует проанализировать ситуации, когда программная проверка нужна или не нужна и удалить лишний программный код.

Универсальные механизмы в конфигурации

По каждому используемому механизму следует принять решение:
  • оставить, как есть (в этом случае возможно придется адаптировать существующий программный код универсального механизма чтобы исключить (снизить дублирование) программного кода,
  • использовать механизм из Библиотеки Стандартных Подсистем,
  • разработать "оригинальный" механизм.

Этап 6. Прочее

При переходе на версию 8.2 следует конвертировать используемые картинки в формат "png".

Комментариев нет: