-
Notifications
You must be signed in to change notification settings - Fork 41
Postponed commit
home > Planning phase > Postponed commit
Postponed commit is an important condition, because it has implications to the work flow. Postponed commit should be added whenever the TO cannot directly guarantee the leg. For instance, a taxi company, who needs an acceptance of a cab driver before the leg can be committed. This condition is also reflected in the scenarios field of the GET /operator/meta, but this implies that all planned trips are 'postponed commits'. In some cases there is a mix: fx if the taxi company is guaranteeing legs in the inner city, while it takes the 'postponed commit' approach in the outskirts.
The postponed commit scenario is handled in the Booking-phase, but if you use this scenario, add the conditionPostponedCommit to the result of the planning (in both cases, booking-intent=true and booking-intent=false), to notify the MP of the TO's behaviour.
Introduction
- Roadmap
- Semantic versioning
- Use cases
- Changes per version
- Contribution
- Participants
Workflow
- Operator information
- Planning phase
- Booking phase
- Trip execution phase - start
- Trip execution phase - on route
- Trip execution phase - end
- Support
- Payment
Points of attention
- Modalities
- Specifying locations
- GDPR
Eco system
- Relations
Introduction
Scope of the TOMP-API
Versioning and releases
Process Flows
- Authentication
- Operator Information
- Privacy and Registration
- Planning Module
- Booking Module
- Trip Execution Module
- Payment Module
- Support Module
Meta-Information
Reference implementations
To-dos and risks
Technical Specifications
A1 List of terms and definitions
A2 Passenger characteristics dictionary
A3 APIs available on the transportation ecosystem
A4 Overview of the User stories
A5 Authors, Architects, collaborators and stakeholders involved
A6 Adoption and Implementation of the TOMP-API