|
|
| Line 13: |
Line 13: |
| | * | | * |
| | * Any departure or destination airports indicated on the incoming messages that do not exist or match the CT record should be ignored. | | * Any departure or destination airports indicated on the incoming messages that do not exist or match the CT record should be ignored. |
| - |
| |
| - | == Business Processes ==
| |
| - |
| |
| - | === For 1 CT record booked on a direct flight ===
| |
| - |
| |
| - | For shipments that are booked on a direct flight the incoming messages should update the following fields in CT.
| |
| - |
| |
| - | * Airport Of Departure Actual Date -
| |
| - | o shipment should confirm the airport of departure is correct, by comparing the destination
| |
| - | airport listed on the incoming message to the CT#Airport Of Departure
| |
| - |
| |
| - | * Airport Of Destination Actual Date-
| |
| - | o shipment should confirm the airport of departure is correct, by comparing the destination
| |
| - | airport listed on the incoming message to the CT#Airport Of Destination
| |
| - |
| |
| - | === Transshipment airports ===
| |
| - |
| |
| - | It is possible to have more than one transhipment airport.
| |
| - |
| |
| - | We assume that Descartes can send meaningful updates to accommodate that case.
| |
| - |
| |
| - | In the event of more than one trans shipment airport, the system should only update the CT#Trans Shipment port listed in the CT record. Once the incoming message received showing the indicated or matching trans ship port arrival, the the CT#Trans Shipment Actual Date should be updated.
| |
| - |
| |
| - | Any departure or destination airports indicated in incoming messages that do not exist or match the CT record should be ignored. This will be addressed in Phase 2.
| |
| - |
| |
| - | === Split case ===
| |
| - |
| |
| - | In this case airline might call and say that X plts/pcs/etc will be placed on Flight F1.
| |
| - |
| |
| - | Later airline might call and say that Y plts/pcs/etc will be placed on Flight F2.
| |
| - |
| |
| - | Later airline might call and say that remaining plts/pcs/etc will be placed on Flight F3.
| |
| - |
| |
| - | It could be split 2,3,4, ... times. - Keeping a record of this updates will be TBD for Phase 2
| |
| - |
| |
| - |
| |
| - | We assume that Descartes can send meaningful updates to accommodate that case. CT2 should be re-designed to support that.
| |
| - |
| |
| - | The CT should update the CT#Airport Of Departure Actual Date when the first piece has departed and update when the last piece departs and the CT#Airport Of Destination Actual Date when the first piece arrives and updated when the last piece updates.
| |
| - |
| |
| - | A comment should be posted showing the following updates as a notification on the above.
| |
| - |
| |
| - | *
| |
| - | o SPLIT SHIPMENT - First part has departed
| |
| - | o SPLIT SHIPMENT - Last part has departed
| |
| - | o SPLIT SHIPMENT - First part has arrived
| |
| - | o SPLIT SHIPMENT - Last part has arrived
| |
| - |
| |
| - | The system will need to keep a count after the first departure, until the CT#Grand Total: Loose Pkgs or CT#Grand Total: Pkgs On Plts total matches, to accurately update the first and last parts. All other departures or arrivals should be ignored. This will be addressed in Phase 2
| |
| - |
| |
| - | === Delays ===
| |
| - |
| |
| - | In the event that a shipment is removed from the original flight or the original flight is delayed.
| |
| - |
| |
| - | Airport Of Departure Estimated Date field should be updated to reflect the corrected information.
| |
| - |
| |
| - | Airport Of Destination Estimated Date field should be updated to reflect the corrected information.
| |
| - |
| |
| - | === Phase Two Business Requirements For UC2 & 3 ===
| |
| - |
| |
| - | Additional requirements TBD
| |
| - |
| |
| - | === Transshipment airports ===
| |
| - |
| |
| - | It is possible to have more than one transhipment airport.
| |
| - |
| |
| - | We assume that Descartes can send meaningful updates to accommodate that case.
| |
| - |
| |
| - | CT2 should be re-designed to support that.
| |
| - |
| |
| - | === Split case ===
| |
| - |
| |
| - | In this case airline might call and say that X plts/pcs/etc will be placed on Flight F1.
| |
| - |
| |
| - | Later airline might call and say that Y plts/pcs/etc will be placed on Flight F2.
| |
| - |
| |
| - | Later airline might call and say that remaining plts/pcs/etc will be placed on Flight F3.
| |
| - |
| |
| - | It could be split 2,3,4, ... times.
| |
| - |
| |
| - | We assume that Descartes can send meaningful updates to accommodate that case. CT2 should be re-designed to support that.
| |
| | | | |
| | == Filters == | | == Filters == |
It is our understanding that in order to send updates Descartes needs to receive only MAWB number.
