App:Travel assistance service administration: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older edit
VisualWikitext
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
No edit summary
 
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Global basic travel service definitions ==
The travel service administration is split into two parts:
b-op defines basic travel services, which hold:


* a travel-service global identified (GID),
* [[Dev:Travel services - Global travel service map|Global travel service map]] - this holds a list of all known travel services known to b-op. It is centrally maintained and acts as standardization between all carriers. This is required to provide global compatibility and to deliver the option for collaboration.
* a travel service code (e.g. "STRETCHER")
* '''Service customization''' - Each carrier digital, e.g. Lufthansa / LH, may define, where, how and by whome services are delivered and customize services picked from the [[Dev:Travel services - Global travel service map|global travel service map]].
* the point of delivery - either '''port''' or '''segment'''.  
This article is about this service process customizations, which is done in this app.  
** Port means that the travel service might be delivered at embarcation, disembarcation or each transfer port.
** Segment means that the travel service can be delivered per segment
* requires mounting/dismantling work at travel device (Yes/No)
* requires notifications to ports
* Travel service flavours with flavour-GID (e.g. there are multiple types of wheelchair service)


== Carrier specific definitions ==
== Service type ==
If a digital is authorative for a travel carrier, e.g. Lufthansa / LH, the digital may define per each carrier to which it is authorative, where, how and by whome services are delivered.


=== Service availability definition ===
* '''Travel Service''' '''Category''' - This service requires medical approval before confirming the service
A list of travel services which are generally supported by the carrier. This is done by picking from a list of global travel service definitions.
* '''Icon''' - The icon used to signal the request on the backend process of OC
* '''Color Tag''' - The signal color of the service request in the backend process of OC


Once a service is picked, the digital can define (depenendent on the point of delivery) for the carrier, if the service is
== Service availability definition ==
By picking from a list of global travel service definitions, it becomes generally available to the carrier. Once this is done the customization part starts:


* '''generally available''' -  to all ports / all services () available to the carrier or  
Based on the settings in the [[Dev:Travel services - Global travel service map|global travel service map]], a service is either delivered at ports or during travel segments. Still, each carrier may define if the service is
* '''limited available''' - in this case the carrier wants to define availability per port or per offered segment.  
 
* '''generally available''' -  The service is available to all ports/segments or
* '''limited available''' - in this case the carrier wants to define availability per port or per offered segment.


====== Port limited availability ======
====== Port limited availability ======
If limited availability is selected and point of delivery is set to "''per port''", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:
If limited availability is selected and point of delivery is set to "''per port''", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:
* '''embarcation''' - Only availbale, if embarcation ports support this service
* '''embarcation''' - This service is to be delivered at embarcation ports. 
* '''disembarcation''' - Only available, if disembarcation ports support this service
* '''disembarcation''' - This service is to be delivered at disembarcation ports.
* '''embarcation and disembarcation''' - Only available, if the embarcation ports and disembarcation points of a trip support this service
* '''transfer (inbound)''' - This service is to be delivered at transfer ports, where the carrier does the inbound segment
* '''all''' - Only available if each port of the iitinerary support the service
* '''transfer (outbound)''' - This service is to be delivered at transfer ports, where the carrier does the outbound segment
Depending on the itinerary type "Round trip" or "One way" or "Multi city" the system can detect embarcation ports and disembarcation ports.
Please note that services can only be delivered, if a service delivery partner is known to the system, which supports this service. Within the [[App:Delivery partner administration app|delivery partner administration app]], the list of supported services at supported ports and the available service providers can be defined.  


====== Segment limited availability ======
====== Segment limited availability ======
If limited availability is selected and point of delivery is set to "''offered segment''", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:  
If limited availability is selected and point of delivery is set to "''offered segment''", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:  


* '''travel device''' - Only available if the travel device supports it. If so, the travel device administration will allow the admin per each travel device to define if the service is available or not.
* '''vessel type''' - Only available if the vessel type supports it. The user can pick from a list of travel devices, which support this service.
* '''segment''' - Only available if the segment supports it. If so, the offered segments administation, will allow the admin per offered segment to define if the travel service is available or not.
* '''segment''' - Only available if the segment supports it. The user can pick from a list of segments, which support this service.
* t'''ravel device and segment''' - Only available if the travel device and segment support it. In this case in both administrations, the admin will be offered to define availability.
Please note, that both limitations can be active.
<br />Examples
 
=== Examples for service availability definition ===
* Service "Wheelchair". The point of service delivery is "port", as the wheelchair service is delivered at airports. The service availability is set to "generally available", as the carrier knows that each port has to be able to deliver this service due to IATA regulations.
* Service "Wheelchair". The point of service delivery is "port", as the wheelchair service is delivered at airports. The service availability is set to "generally available", as the carrier knows that each port has to be able to deliver this service due to IATA regulations.
* Service "STRETCHER". The point of service delivery is "travel device" and availability is "travel device and segment". As STRETCHER requires mounting/dismantlich, the service stations "LH Technics Frankfurt" and "LH Technics Munich" are selected both for mounting and dismantling.
* Service "STRETCHER". The point of service delivery is "segment" and availability is "travel device and segment".  
 
== Service mounting/dismantling task automation ==


=== Service mounting/dismantling tasks ===
==== Ports / Service delivery partners ====
If the service requires work at the travel device, the service stations which are able to do the mounting/dismantling work per travel device for this service have to be defined. So the admin user can pick from the available service stations and define, if they support mounting or dismantling action or both, which is equired for rotation planning! For each service station supporting mounting and dismantling, the admin can define one or multiple mounting/dismantling rules. Each mounting/dismantling rule holds these information:
If the service requires work at the travel device, the carrier has to pick


* time distance - how many hours to a mouting/dismantlich the task shall be created
* '''mounting/dismantling ports''' - the ports which are able to do the mounting/dismantling work
* task template to use - the task template to use for the creation of the task
* '''service delivery partners''' - for each mounting/dismantling port, the user has to pick a service delivery partner, which performs the mounting/dismantling work at this port


Example:
==== Notification automation ====
For each service station supporting mounting and dismantling, the admin can define one or multiple mounting/dismantling notification rules. Each mounting/dismantling rule holds these information:
 
* '''Target'''
** '''OC internal''' - allows the definition of a person or person group
** '''service delivery partner''' - the station performing the mounting/dismantling
* '''Time to Delivery (TTD)''' - how many hours before required mouting/dismantlich, the task shall be created
* '''Task template''' - the [[travel task template]] to use for the creation of the task
 
<u>Examples:</u>


* Service "STRETCHER", 24 hours before mounting, task template "Mounting task to service station"
* Service "STRETCHER", 24 hours before mounting, task template "Mounting task to service station"
* Service "STRETCHER", 6 hours before mounting, task template "Mounting task check to MOC"
* Service "STRETCHER", 6 hours before dismantling, task template "Mounting task check to MOC"
 
== Task flow & automation ==
For each service, a list of tasks flow rules has to be created. By these, the system knows when to create tasks and for which party
 
==== Event Trigger ====
Available Triggers:
 
* '''OnSegmentServiceClaim'''
* '''OnSegmentServiceTimeToDelivery''' - Requires the user to enter a Time To Delivery (TTD) meaning how many hours to a departure or arrival event the task shall be created (embarcation or disembarcation event)
* '''OnSegmentServiceFinalApproval'''
* '''OnSegmentServicePartialApproval'''
* '''OnSegmentServiceRejection'''
* '''OnSegmentServicePartialRejection'''
* '''OnServiceCancellation'''
 
==== Used task template ====
The user has to pick the [[travel task template]] to use for creation of this task.
 
==== Event Target ====
Who receives the task / who is responsible for fulfillment. Options are
 
* '''passenger'''
* '''OC internal''' - allows the definition of a person or person group
* '''service delivery partner''' - allows to either define
** default service provider - this will pick a service delivery partner, which supports the requested service at the desired port
** fixed partner - this will always provide this task to a fixed service delivery partner
 
==== Applicability / multiplication ====
When the event target ''passenger'' or ''OC internal'' is selected, this defines how often this event will be triggered:
 
* '''once per itinerary''' - this option is not available, if the event target is service delivery partner
* '''per port in itinerary'''
* '''per embarcation port in itinerary'''
* '''per disembarcation port in itinerary'''
* '''per [[Dev:Travel Segment Service Items|service segment item]]'''
 
For service deliery partner the application is always per [[Dev:Travel Segment Service Items|service segment item]].


=== Service station notification tasks ===
==== Event mutiplication restrictions ====
If the service requires port notifications, port notification rules can be defined. Each rule has three atributes, by which the system knows when and for which ports to create tasks
This allows task to restricted the task execution for service segments or ports by specifying


* '''time distance''' - how many hours to a boarding or disembarcation event the task shall be created
* '''a port limitation list''' - This list of ports to which this task shall be created. If not specified, all ports defined through port-application are triggering this event
* '''port application''' (multi-select is possible) - for which ports of the itinerary this task shall be created
* '''segment limitation list''' - This allows a list of segmenttation rules (e.g. "*" - "FRA": only inbound flights to FRA) on which this task will be created
** '''embarcation ports''' - this task will be created for each embarvation ports
** '''disembarcation ports''' - Only available, if disembarcation ports support this service
** '''transfer ports -''' will be applied to each transfer port of the itinerary.


* '''ports limitation''' (optional) - This list of ports to which this task shall be created. If not specified, all ports defined through port-application are triggering this event
=== Examples ===
* '''Task template to use''' - the task template to use for creation of this task.
* Rule name "AMBULANCE prenotification"
** OnSegmentServiceTimeToDelivery''':''' 3 hours
** Used Task template: "Ambulance required task" (Deadline 1h)
** Event Target: service delivery partner
** Applicability/multiplication: per [[Dev:Travel Segment Service Items|service segment item]]
** Event multiplication restrictions: none
* Service "UK Border Patrol prenotification"
** OnSegmentServiceTimeToDelivery''':''' 3 hours
** Used Task template: "UK Border patrol notice"
** Event Target: service delivery partner
** Applicability/multiplication: per disembarcation port in itinerary
** Event multiplication restrictions: Port limitation "LHR"


Example:
== Related articles ==


* Service "AMBULANCE", 3 hours before arrival for "disembarvation ports", ports limitation "LHR", template: "UK Border patrol prenotification info"
* [[SARA.Core (Special Assistance Request Management Suite)]]
* Service "STRETCHER", 3 hours before arrival for "disembarvation ports", no ports limitation, "Outstation pickup task"
[[Category:Apps]]

Latest revision as of 12:25, 22 June 2025

The travel service administration is split into two parts:

  • Global travel service map - this holds a list of all known travel services known to b-op. It is centrally maintained and acts as standardization between all carriers. This is required to provide global compatibility and to deliver the option for collaboration.
  • Service customization - Each carrier digital, e.g. Lufthansa / LH, may define, where, how and by whome services are delivered and customize services picked from the global travel service map.

This article is about this service process customizations, which is done in this app.

Service type

  • Travel Service Category - This service requires medical approval before confirming the service
  • Icon - The icon used to signal the request on the backend process of OC
  • Color Tag - The signal color of the service request in the backend process of OC

Service availability definition

By picking from a list of global travel service definitions, it becomes generally available to the carrier. Once this is done the customization part starts:

Based on the settings in the global travel service map, a service is either delivered at ports or during travel segments. Still, each carrier may define if the service is

  • generally available - The service is available to all ports/segments or
  • limited available - in this case the carrier wants to define availability per port or per offered segment.
Port limited availability

If limited availability is selected and point of delivery is set to "per port", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:

  • embarcation - This service is to be delivered at embarcation ports.
  • disembarcation - This service is to be delivered at disembarcation ports.
  • transfer (inbound) - This service is to be delivered at transfer ports, where the carrier does the inbound segment
  • transfer (outbound) - This service is to be delivered at transfer ports, where the carrier does the outbound segment

Please note that services can only be delivered, if a service delivery partner is known to the system, which supports this service. Within the delivery partner administration app, the list of supported services at supported ports and the available service providers can be defined.

Segment limited availability

If limited availability is selected and point of delivery is set to "offered segment", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:

  • vessel type - Only available if the vessel type supports it. The user can pick from a list of travel devices, which support this service.
  • segment - Only available if the segment supports it. The user can pick from a list of segments, which support this service.

Please note, that both limitations can be active.

Examples for service availability definition

  • Service "Wheelchair". The point of service delivery is "port", as the wheelchair service is delivered at airports. The service availability is set to "generally available", as the carrier knows that each port has to be able to deliver this service due to IATA regulations.
  • Service "STRETCHER". The point of service delivery is "segment" and availability is "travel device and segment".

Service mounting/dismantling task automation

Ports / Service delivery partners

If the service requires work at the travel device, the carrier has to pick

  • mounting/dismantling ports - the ports which are able to do the mounting/dismantling work
  • service delivery partners - for each mounting/dismantling port, the user has to pick a service delivery partner, which performs the mounting/dismantling work at this port

Notification automation

For each service station supporting mounting and dismantling, the admin can define one or multiple mounting/dismantling notification rules. Each mounting/dismantling rule holds these information:

  • Target
    • OC internal - allows the definition of a person or person group
    • service delivery partner - the station performing the mounting/dismantling
  • Time to Delivery (TTD) - how many hours before required mouting/dismantlich, the task shall be created
  • Task template - the travel task template to use for the creation of the task

Examples:

  • Service "STRETCHER", 24 hours before mounting, task template "Mounting task to service station"
  • Service "STRETCHER", 6 hours before dismantling, task template "Mounting task check to MOC"

Task flow & automation

For each service, a list of tasks flow rules has to be created. By these, the system knows when to create tasks and for which party

Event Trigger

Available Triggers:

  • OnSegmentServiceClaim
  • OnSegmentServiceTimeToDelivery - Requires the user to enter a Time To Delivery (TTD) meaning how many hours to a departure or arrival event the task shall be created (embarcation or disembarcation event)
  • OnSegmentServiceFinalApproval
  • OnSegmentServicePartialApproval
  • OnSegmentServiceRejection
  • OnSegmentServicePartialRejection
  • OnServiceCancellation

Used task template

The user has to pick the travel task template to use for creation of this task.

Event Target

Who receives the task / who is responsible for fulfillment. Options are

  • passenger
  • OC internal - allows the definition of a person or person group
  • service delivery partner - allows to either define
    • default service provider - this will pick a service delivery partner, which supports the requested service at the desired port
    • fixed partner - this will always provide this task to a fixed service delivery partner

Applicability / multiplication

When the event target passenger or OC internal is selected, this defines how often this event will be triggered:

  • once per itinerary - this option is not available, if the event target is service delivery partner
  • per port in itinerary
  • per embarcation port in itinerary
  • per disembarcation port in itinerary
  • per service segment item

For service deliery partner the application is always per service segment item.

Event mutiplication restrictions

This allows task to restricted the task execution for service segments or ports by specifying

  • a port limitation list - This list of ports to which this task shall be created. If not specified, all ports defined through port-application are triggering this event
  • segment limitation list - This allows a list of segmenttation rules (e.g. "*" - "FRA": only inbound flights to FRA) on which this task will be created

Examples

  • Rule name "AMBULANCE prenotification"
    • OnSegmentServiceTimeToDelivery: 3 hours
    • Used Task template: "Ambulance required task" (Deadline 1h)
    • Event Target: service delivery partner
    • Applicability/multiplication: per service segment item
    • Event multiplication restrictions: none
  • Service "UK Border Patrol prenotification"
    • OnSegmentServiceTimeToDelivery: 3 hours
    • Used Task template: "UK Border patrol notice"
    • Event Target: service delivery partner
    • Applicability/multiplication: per disembarcation port in itinerary
    • Event multiplication restrictions: Port limitation "LHR"

Related articles

Retrieved from "https://wiki.kordeus.com/index.php?title=App:Travel_assistance_service_administration&oldid=2244"