Мы рассмотрели одну часть — создание заявки на командировку. Сама по себе информация, которую мы смогли заполнить на предыдущем шаге, несет в себе не очень много ценности. Рассмотрим процесс с точки зрения системы и нашей жизни. В системе мы создаем заявку на командировку, чтобы обозначить ее период, цель, сумму аванса и отразить потенциальные затраты, чтобы система проверила есть ли бюджет на командировку. Заявку нам по умолчанию утверждает линейный руководитель по оргструктуре, либо ответственный сотрудник, который видит в отчете неутвержденную заявку и ее согласует. Этот процесс можно изменить, так как он построен на потоке операций (WS20000050). Менять поток мы научимся позже, когда будет отдельный курс по потокам операций.

Мы согласовали заявку на командировку. И теперь начинаются различия в процессах. На основании утвержденной заявки мы создаем маршрут командировки или план. В этом документе указывается весь маршрут нашего передвижения, а что еще интереснее, то там указываются и бронируются гостиницы, перелеты, переезды, автомобили. И это все в рамках стандартного решения. Исключение только то, что это решение ориентировано на прямой договор и соответственно доступ к системе Amadeus и немецким железным дорогам. То есть сотрудник сам может выбрать нужные билеты, отель и прочие параметры из системы бронирования. У нас же пока это делается либо вне системы, либо через секретаря, либо внутреннего или внешнего провайдера. Выход я пока вижу только один — писать интеграции с внешними провайдерами (система позволяет это сделать через badi).

Второе полезное свойство заявки на командировку, что после ее согласования можно выполнить проводку для выплаты аванса, если он был затребован.

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

Ввиду того, что создание плана командировки для нас пока неактуально, перейдем к утверждению заявки командировки. Как было упомянуто выше, утвердить мы можем несколькими способами: автоматически, вручную и через поток операций.

Вернеемся к настройке командировок. Автоматическое утверждение реализовано через отчет в транзакции PRAP. В badi TRIP_APPROVAL можно указать условия, при которых система часть командировок будет утверждать самостоятельно. Если у нас будет интеграция командировок с CATS, чтобы автоматически создавать часы отсутствия в командировке, то может пригодиться транзакция ACTEXP_APPR_LITE, которая также может утвердить командировку, а следом и передать время отсутствия в CATS.

Ручное утверждение работает через транзакцию TRIP, где менеджер может вручную выбрать табельный номер, заявку и нажать кнопку утверждения.

Утверждение через поток операций работает следующим образом. Наши командировки связаны с так называемым бизнес-объектом BUS2089 (транзакция SWO1):

swo1_bus2089

В чем суть? Когда мы изменяем командировку в любом ее виде, то система вызывает события. Событие это событие. То есть сигнал, что что-то случилось, изменилось. Например, мы создаем командировку, сохраняем. Система вызывает событие EmployeeTrip.RequestCreated. Теперь давайте откроем поток операций, который отвечает за утверждение заявки (WS20000050). Транзакция SWDD:

swdd_travel_1

Как мы видим, поток начинается с двух событий. Точнее с одного из, которе будет вызвано первым. Слева у нас событие (увидим дальше), справа ручной запуск потока. Если два раза кликнуть на событие Travel Request Created, то мы увидим следующую картинку:

swdd_travel_2

На закладке Start Events указывается, какие события могут инициировать запуск потока. Вдалеке виднеется наш бизнес-объект BUS2089 и событие.

Для любознательных в backend системе событие вызывается таким образом:

SAPMFITP_event

IF NOT ( event IS INITIAL ). «WBGPLN «MAWK010663
PERFORM create_event USING objkey event
CHANGING sw_event.
ENDIF. «WBGPLN «MAWK010663

и далее

CALL FUNCTION ‘SWE_EVENT_CREATE’
EXPORTING
objtype = ‘BUS2089’
objkey = p_objkey
event = p_event
IMPORTING
event_id = event_id
TABLES
event_container = event_container
EXCEPTIONS
objtype_not_found = 1
OTHERS = 2.

Как видите, логика работы достаточно простая. Если посмотреть внимательно на все шаги процесса утверждения в части потока операций, то вы увидите основные элементы: выбор пользователя, отправка уведомления, изменение статуса. Все делается небольшими операциями — кирпичиками, из которых складывается поток. Попробуйте самостоятельно протестировать отправку уведомления линейному руководителю (подсказка: у такого руководителя должна стоять галочка начальника в PPOME на штатной должности). И усложните — добавьте еще экономиста в цепочку согласования.

 

P.S. насколько такой уровень пояснений достаточен или нужно детальнее объяснять?