Background
Currently a "Consignment"."status" attribute exists, with currently these enumeration values:
draft
requested
confirmed (this replaces accepted)
inTransit
completed
cancelled
Looking at these statuses, they actually describe the status of different (independent) lifecycles. For example:
If all basic data of the consignment is complete for the consignment to be executed: status draft exists, missing status: final.
What the status of the administrative booking process is: status requested, confirmed (formerly accepted) and cancelled exist, missing: rejected
What the main transportation execution status is: status inTransit and completed exist. Others are missing.
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. Third subject: transport execution main status
Introduction
On a granular level, Actions are set against Consignments. Typically there would at least be a load and unload action, but there can be many more.
During transportation execution, Events (planned, realized, etc) are registered against entities. I presume in the context of execution of the Consignment its Actions, these Events are logged against specifically against the Actions themselves or generically against the Consignment (maybe someone can confirm or help explain this a little bit).
Currently, there also is the attribute Consignment.Status. The enumeration contains 2 statuses related to the transportation execution process (status "inTransit" and "Completed"). The way I interpret this, is that OTM has foreseen that there needs to be an overarching (master) status field that provides a high-level indication what the execution stage of the transportation process is.
However, I think the Consignment.Status attribute is specified too broadly for it to just contain a high-level (and self-contained) statusflow about the tranportation execution process. Therefore I suggest to introduce a status called "TransportExecutionMainStatus". The status enumeration could be as follows:
"NotStarted": The transportation execution process has not started yet (i.e. no realization event has taken place yet).
"InProgress" (instead of InTransit): At least 1 Action event has been realized, but not yet all Actions.
"CompletedSuccessful": All Actions have been completed successfully.
"CompletedWithExceptions": All Actions have been completed, but there have been 1 or more functional exceptions.
And then also these exception-statuses:
"Aborted": There has been a showstopper exception.
"OnHold": There has been an exception causing the expected chain of Actions / events to halt. An intervention is needed that may or may note result in resuming of transportation execution.
The idea is that every time a carrier sends an Event to the Shipper, the (updated) value of TransportExecutionMainStatus is sent along with it.
Describe alternatives you've considered
The alterative could be that it was never intended for OTM to have a concept like a TransportExecutionMainStatus. In that case, the whole idea must be thrown overboard. Systems must then themselves (internally) infer a TransportExecutionMainStatus.
Additional context
In UBL transportationStatus message, the concept of TransportExecutionMainStatus as described above is known as "TransportExecutionStatusCode": A code signifying the overall status of transport service execution.
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:
For efficient discussion, I'll make a Github issue to discuss my suggestion improvement on each status lifecycle. Third subject: transport execution main status
Introduction On a granular level, Actions are set against Consignments. Typically there would at least be a load and unload action, but there can be many more.
During transportation execution, Events (planned, realized, etc) are registered against entities. I presume in the context of execution of the Consignment its Actions, these Events are logged against specifically against the Actions themselves or generically against the Consignment (maybe someone can confirm or help explain this a little bit).
Currently, there also is the attribute Consignment.Status. The enumeration contains 2 statuses related to the transportation execution process (status "inTransit" and "Completed"). The way I interpret this, is that OTM has foreseen that there needs to be an overarching (master) status field that provides a high-level indication what the execution stage of the transportation process is. However, I think the Consignment.Status attribute is specified too broadly for it to just contain a high-level (and self-contained) statusflow about the tranportation execution process. Therefore I suggest to introduce a status called "TransportExecutionMainStatus". The status enumeration could be as follows:
And then also these exception-statuses:
The idea is that every time a carrier sends an Event to the Shipper, the (updated) value of TransportExecutionMainStatus is sent along with it.
Describe alternatives you've considered The alterative could be that it was never intended for OTM to have a concept like a TransportExecutionMainStatus. In that case, the whole idea must be thrown overboard. Systems must then themselves (internally) infer a TransportExecutionMainStatus.
Additional context In UBL transportationStatus message, the concept of TransportExecutionMainStatus as described above is known as "TransportExecutionStatusCode": A code signifying the overall status of transport service execution.