FI-TV колотилка или учет командировок

Сегодня коллеги из Европы сказали, что у них FI-TV используется нетрадиционно в нашем понимании. Если мы активируем расширение FIN_TRAVEL_1, то у нас появится возможность вводить виды затрат в разрезе схем командировок, вести учет командировок, отражать затраты и вести табель. Ушлые европейцы используют это для таких задач как:

  • Командировки внутри страны/заграницу. Тут все стандартно.
  • Учет пробега на корпоративных авто (у них система накапливает пробег для целей формирования налоговой льготы в зарплате — им за километры платит государство!)
  • Учет подотчетных лиц

То есть создаются группы видов затрат, делятся по схемам (группировка такая есть в управлении командировками — что-то вроде бизнес-цели затрат), правильным образом играются с полями и получается мило. Очередная универсальная колотилка 🙂


Интеграция с AviaSales

Маленький пятничный подарок, реализованный за 1 час времени с нуля — прошу, интеграция с AviaSales.

Хотите, чтобы в модуле управления командировками можно было получать реальные цены на авиабилеты? Вот кусок кода, который можно вставить в бадишку для поиска билетов. Это образец, дальше сами сообразите. А полное решение будет в новой книге от меня 😉

 

REPORT ZAVIASALES.

DATAlo_http_client     TYPE REF TO if_http_client,
lo_rest_client     TYPE REF TO cl_rest_http_client,
lv_url             TYPE        string,
lv_body            TYPE        string,
lo_response    TYPE REF TO     if_rest_entity.
cl_http_client=>create_by_url(
EXPORTING
url              ‘http://api.travelpayouts.com’
IMPORTING
client                   lo_http_client    » HTTP Client Abstraction
exceptions
argument_not_found 1
plugin_not_active  2
internal_error     3
others             4
).
CREATE OBJECT lo_rest_client
EXPORTING
io_http_client lo_http_client.

IF lo_http_client IS BOUND AND lo_rest_client IS BOUND.
lv_url ‘/v1/prices/cheap?origin=MOW&destination=HKT&depart_date=2015-11&return_date=2015-12&token=ВАШТОКЕН’.
cl_http_utility=>set_request_uri(
EXPORTING
request lo_http_client->request    » HTTP Framework (iHTTP) HTTP Request
uri     lv_url                     » URI String (in the Form of /path?query-string)
).

* HTTP GET
lo_rest_client->if_rest_client~get).

* HTTP response
lo_response lo_rest_client->if_rest_client~get_response_entity).

* HTTP return status
DATA(http_status)   lo_response->get_header_field‘~status_code’ ).

* HTTP JSON return string
DATA(json_responselo_response->get_string_data).
write json_response.

ENDIF.

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

{«success»: true, «data»: {«HKT»:{«0»:{«price»:36693,»airline»:»SU»,»flight_number»:274,»departure_at»:»2015-11-24T19:15:00Z»,»return_at»:»2015-12-09T11:40:00Z»,»expires_at»:»2015-10-19T14:18:50Z»},»1″:{«price»:25654,»airline»:»CA»,»flight_number»:910,»departure_at»:»2015-11-22T18:55:00Z»,»return_at»:»2015-12-10T01:40:00Z»,»expires_at»:»2015-10-17T18:14:29Z»},»2″:{«price»:26837,»airline»:»EY»,»flight_number»:68,»departure_at»:»2015-11-19T12:50:00Z»,»return_at»:»2015-12-15T06:55:00Z»,»expires_at»:»2015-10-18T14:54:47Z»},»3″:{«price»:37979,»airline»:»SU»,»flight_number»:22,»departure_at»:»2015-11-16T16:10:00Z»,»return_at»:»2015-12-14T01:50:00Z»,»expires_at»:»2015-10-19T13:11:55Z»}}}}


Настройка командировок. Часть 2

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

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

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

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

Читать далее