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