search

opentripmodel / otm5-change-requests

Tracking and reporting bugs and change requests of the OTM5 specification.
5 stars 1 forks source link

Improve the Consignment.status concept (part 2): accomodate the consignment booking process #40

Closed BobZuidhoek closed 2 years ago

BobZuidhoek commented 2 years ago

I'd like to change something of the OTM 5 spec.

Background Currently a "Consignment"."status" attribute exists, with currently these enumeration values:

Looking at these statuses, they actually describe the status of different (independent) lifecycles. For example:

  1. If all basic data of the consignment is complete for the consignment to be executed: status draft exists, missing status: final.
  2. What the status of the administrative booking process is: status requested, confirmed (formerly accepted) and cancelled exist, missing: rejected
  3. What the main transportation execution status is: status inTransit and completed exist. Others are missing.
  4. There could be other process statuses, such as invoicing-status or payment-status.

For efficient discussion, I'll make a Github issue to discuss my suggestion improvement on each status lifecycle. Second subject: support the administrative booking process.

Introduction A shipper sends OTM5 TransportOrders/Consigments to a carrier. In some cases, the shippers expects a formal acknowledgement from the carrier that the carrier has reviewed the Consignment and confirms that he will be able to execute the Consignment. Note that this is different from getting a HTTP 200-series response, which merely means that the TransportOrder/Consigmnent was technically delivered & technically validated successfully.

I suggest to add an attribute (or maybe that is even a whole model) of "AdministrativeBooking".

There are 2 main scenario's:

  1. The shipper wants to get a formal acknowledgement from the carrier (scenario name: MustAcknowledge). The shipper sends a Consignment to the carrier with "AdministrativeBookingStatus" "Requested". The carrier reviews the consignment and can answer back with status "Accepted" (I think this is a better word than Confirmed) or "Rejected" (with RejectedReason). At all times, both the Shipper and Carrier can send a "Cancelled" status to each other (with CancellationReason).

  2. The shipper is not interested in a formal acknowledgement from the carrier (scenario name: FireAndForget). The shipper sends a Consignment to the carrier with "AdministrativeBookingStatus" "Accepted". The Carrier does not have to do anything. At all times, both the Shipper and Carrier can send a "Cancelled" status to each other (with CancellationReason).

So essentially we have an attribute "AdministrativeBookingStatus", with enumeration statuses "Requested", "Accepted", "Rejected" and "Cancelled". Another attribute "AcknowledgementType" controls the process flow type and has enumeration "MustAcknowledge" and "FireAndForget". We also need attributes "RejectedReason" and "CancellationReason".

Only consignments that have a "AdministrativeBookingStatus" "Accepted" status, can be taken into execution by the carrier. Also note the relationship with Github Issue #39, where I suggested that only consignments that have a "ConsignmentBasicDataCompleteness" "Final" status, can be taken into execution by the carrier. Therefore I think only consignments that are Final & Accepted should be taken to into the carrier's transport execution process (their TMS's should check for this).

Describe alternatives you've considered Maybe this can somehow also be captured using OTM Actions and Events. However, that felt a little less logical to me, because actions and events seem to be mostly tied to the transport execution-stage of a consignment.

Additional context I've tried to describe the suggested solution above as detailed as I could. It most certainly can be improved.