Готовишься к экзамену?
Полнофункциональный тренажер @bot_1cnik_bot с полноценным обучением, режимом экзамена и подробной статистикой.
Модуль приложения рекомендуется использовать
для определения предопределенных процедур "ПриНачалеРаботыСистемы" и т.п.
Правильно: модуль управляемого приложения предназначен именно для обработки событий жизненного цикла клиентского приложения и сеанса пользователя; здесь уместно выполнять стартовые/завершающие действия (подтянуть настройки пользователя, установить значения по умолчанию, подготовить контекст для дальнейшего заполнения ведомостей), а основную логику расчетов и автозаполнения документа выносить в серверные модули.
как место определения процедур и функций, используемых во всей конфигурации
Неправильно: модуль управляемого приложения не предназначен для хранения общей бизнес-логики; он ориентирован на клиентский сеанс и недоступен как полноценная серверная точка для расчетов. Общие алгоритмы автозаполнения «Ведомости в кассу» правильнее размещать в общих модулях с серверным контекстом или в модулях объектов/менеджеров и вызывать их из обработчика команды формы.
как место определения предопределенных процедур, которые инициализируются при старте и окончании работы системы в режиме внешнего соединения
Неправильно: сценарии внешнего соединения обслуживаются модулем внешнего соединения, а не модулем управляемого приложения. Если ведомость создается/заполняется из внешней интеграции, обработчики старта/завершения и экспортируемые процедуры должны быть в модуле внешнего соединения и/или в серверных общих модулях.
верны ответы 1 и 2
Неправильно: верна только идея про обработчики событий сеанса. Общую логику автозаполнения «Ведомости в кассу» (подбор сотрудников, получение сумм к выплате, правила обновления строк) в модуле управляемого приложения размещать не рекомендуется - ее следует держать в серверных общих модулях/модулях объекта и вызывать по команде пользователя.
Пояснение
Как связать это с автозаполнением «Ведомости в кассу» на практике.
1) Где реально живет автозаполнение ведомости
Автозаполнение обычно запускается командой на форме документа (кнопка «Заполнить», варианты «Заполнить/Дозаполнить/Перезаполнить» - в зависимости от конфигурации). Команда на клиенте инициирует вызов серверной логики, которая подбирает сотрудников и суммы к выплате по выбранному виду выплаты и периоду. Итог попадает в табличную часть документа.
2) Почему модуль управляемого приложения - не место для алгоритма заполнения
Алгоритм заполнения требует работы с данными (расчеты, отборы, регистры/документы, задолженность/начисления), то есть полноценного серверного контекста. Модуль управляемого приложения ориентирован на события сеанса и интерфейса пользователя. Поэтому туда кладут только обработчики событий «старт/финиш», а не «движок» заполнения ведомостей.
3) Что полезного можно сделать в модуле управляемого приложения именно для ведомости
В обработчиках старта сеанса можно подготовить «удобство» для пользователя, не вмешиваясь в расчетный алгоритм:
- Подтянуть пользовательские настройки (последняя организация, касса, подразделение, месяц выплаты) и подставить значения по умолчанию в интерфейсе.
- Проверить доступность раздела выплат и нужных команд (права пользователя) и вывести понятное сообщение, если ведомость не сможет заполниться.
- Подготовить окружение для быстрого заполнения: например, установить параметры сеанса/настроек, которые потом используются серверным модулем заполнения.
4) Куда правильно размещать код автозаполнения
- Обработчик команды на форме документа «Ведомость в кассу» (клиентская часть): только инициирует действие и обновляет форму.
- Общий модуль с серверным контекстом (серверная часть): получает параметры (организация, месяц выплаты, вид выплаты, отбор по сотрудникам/подразделениям) и возвращает набор строк табличной части.
- При необходимости - модуль объекта документа/менеджера: правила, связанные с самим документом (проверки, подготовка данных к записи).
5) Внешнее соединение (если ведомость формирует интеграция)
Если «Ведомость в кассу» создается и заполняется внешним приложением через COM/внешнее соединение, то стартовые/завершающие процедуры и экспортируемые точки входа размещают в модуле внешнего соединения, а расчетные действия все равно выносят в серверные общие модули.
Вывод: модуль управляемого приложения используйте как «точку обработки событий сеанса» (вход/выход и близкие к ним действия), а автозаполнение ведомости реализуйте в серверных модулях и вызывайте его из команды формы.