2782 rfsa

From UG

(Difference between revisions)
Jump to: navigation, search
Line 34: Line 34:
It is our understanding that in order to send updates Descartes needs to receive only MAWB number.
It is our understanding that in order to send updates Descartes needs to receive only MAWB number.
 +
'''
 +
**Currently the conditions'''
=== One CT one direct flight ===
=== One CT one direct flight ===
-
For shipments that are complete and are booked on a direct flight the incoming messages should update the following fields in CT.   
+
For shipments that are complete and are booked on one flight or direct flight the incoming messages should update the following fields in CT.   
====Fields to be updated:====
====Fields to be updated:====
Line 48: Line 50:
=== Transshipment airports ===
=== Transshipment airports ===
-
 
It is possible to have more than one transhipment airport.
It is possible to have more than one transhipment airport.
Line 62: Line 63:
-
In this case airline might call and say that X plts/pcs/etc will be placed on Flight F1.
+
In this case airline might update saying 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 update saying 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.
+
Later airline might update saying 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
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.
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.
Line 92: Line 91:
-
=== When to send XML ===
+
=== When to send messages ===
CT2 system should send [[Ct#MAWB]] through EDI as soon as it gets assigned by operator.
CT2 system should send [[Ct#MAWB]] through EDI as soon as it gets assigned by operator.

Revision as of 17:50, 17 February 2011


Contents

Parent mantis

0002422: [Air Status EDI] ............. <proj parent>

Glossary

  • FSU-message - Freight Status Update message - Incoming message from Descartes to CT2
    • Set up in XML format
  • FSR-message - Freight Status Request message - Outgoing message to Descartes GLN
    • Set up in XML format
  • FSA-message - Freight Status Answer message - Incoming message from Descartes to CT2
    • Set up TBD
  • FHL-message - Forwards House bill details - Out going message to Descartes GLN
    • Set up in CargoImp format
  • FWB-message - Forwards way bill or MAWB details - Out going message to Descartes GLN
    • Set Up in CargoImp format


Business Requirements

Descartes is offering Automated Air Status Update Service

This service allows airfreight shipments booked directly by Jaguar with the airlines, to be fed automatic status updates (departure and arrival dates), removing our need to manually check and then update the status of Airfreight shipments.

It is our understanding that in order to send updates Descartes needs to receive only MAWB number.

    • Currently the conditions


One CT one direct flight

For shipments that are complete and are booked on one flight or direct flight the incoming messages should update the following fields in CT.

Fields to be updated:

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 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.


Split case

In this case airline might update saying that X plts/pcs/etc will be placed on Flight F1.

Later airline might update saying that Y plts/pcs/etc will be placed on Flight F2.

Later airline might update saying 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


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.

    • SPLIT SHIPMENT - First part has departed
    • SPLIT SHIPMENT - Last part has departed
    • SPLIT SHIPMENT - First part has arrived
    • 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 not update the record.

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.


When to send messages

CT2 system should send Ct#MAWB through EDI as soon as it gets assigned by operator.

    • It seems that this is set up to send at the time the operator clicks save. I think this should be changed because we do not want to send an FSU message until the record is complete. UAT has shown that the mawb is being transmitted to the airline once the airline is assigned and save is hit. So the operator does not have to enter even the remaining digits of the mawb.

Use Case Operator changed MAWB

This is addressed in a separate http://ct.jaguarfreight.com/wiki/2555_rfsa

Personal tools