2782 rfsa

From UG

(Difference between revisions)
Jump to: navigation, search
 
(20 intermediate revisions not shown)
Line 1: Line 1:
-
[[Category:RFD]]
+
[[Category:RFSA]]
 +
<div style="background-color:lightSteelBlue">
== Parent mantis ==
== Parent mantis ==
Line 16: Line 17:
*'''FSA-message''' - Freight Status Answer message - Incoming message from Descartes to CT2
*'''FSA-message''' - Freight Status Answer message - Incoming message from Descartes to CT2
-
**Set up TBD
+
**Set up in XML format  
-
 
+
-
*'''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
*'''FWB-message''' - Forwards way bill or MAWB details -  Out going message to Descartes GLN
Line 26: Line 23:
**Set Up in CargoImp format
**Set Up in CargoImp format
 +
== Information ==
-
== Business Requirements ==
+
Descartes is offering a service to automate air status updates.
-
Descartes is offering ''Automated Air Status Update Service''
+
In order to receive these updates for shipments that we do not book directly with the airline (which is the majority of shipments), we need to send a FSR message to Descartes and Descartes will pass this information on to the airlines.  In response to the FSR message the airline will send back and FSU or FSA to Descartes, which Descartes will push through to our system.  These messages should update the Airport Of Departure Actual Date, Trans Shipment Actual Date (if applicable) and Airport Of Destination Actual Date.
-
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.
+
Implementing Automatic updates would save the operators a lot of time.  Currently the operators call the airlines and manually enter these updates.
-
It is our understanding that in order to send updates Descartes needs to receive only MAWB number.
+
== Business Requirements ==
-
 
+
-
 
+
-
=== 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. 
+
-
 
+
-
====Fields to be updated:====
+
-
 
+
-
*[[CT#Airport Of Departure Actual Date]] -
+
-
**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]]
+
-
*[[CT#Airport Of Destination Actual Date]]-
+
-
**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 [[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 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.
+
-
** '''''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 XML ===
+
-
 
+
-
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
+
-
 
+
-
 
+
-
 
+
-
 
+
-
 
+
-
 
+
-
 
+
-
 
+
-
=== One CT one direct flight Use Case UC1 ===
+
-
 
+
-
One CT is traveling on one airplane from origin to destination.
+
-
 
+
-
We assume that Descartes will send back:
+
-
 
+
-
* [[Ct#Airport_Of_Departure_Actual_Date]] first
+
-
* [[Ct#Airport_Of_Destination_Actual_Date]] later
+
-
 
+
-
=== One CT multistop flight Use Case UC2 ===
+
-
 
+
-
In this case there is one or more airport of transhipment.
+
-
 
+
-
Our system may accommodate one. We need to add flexibility if there are more than one.
+
-
 
+
-
We assume that Descartes will send back:
+
-
 
+
-
* [[Ct#Airport_Of_Departure_Actual_Date first]]
+
-
* [[Ct#Airport_Of_Destination_Actual_Date later]]
+
-
* [[Ct#Trans_Shipment_Actual_Date]]  - first trans-shipment
+
-
* [[Ct#Trans_Shipment_Actual_Date2]]  - 2nd trans-shipment. '''New field!'''
+
-
* so on
+
-
 
+
-
==== Implementation Phase 1 ====
+
-
The system should '''update''' the [[CT#Trans Shipment]] airport and its [[CT#Trans Shipment Actual Date]] after receving of Descartes status message.
+
-
:* All updates can be viewed in [[Update Log (main) |CT Update Log]].
+
-
 
+
-
==== Implementation Phase 2 ====
+
-
CT2 should be re-designed to support more than one transhipment airport. Each time when status message is coming we should receive and '''keep''' departure or destination Trans-shipment Airport value along with Dates.
+
-
 
+
-
=== Split Use Case UC3 ===
+
-
 
+
-
Example from [[#Business Requirements]]
+
-
 
+
-
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 need to modify our UI / DB to accommodate this case
+
-
 
+
-
==== Implementation Phase 1 ====
+
-
The system should update the next CT fields:
+
-
:* [[CT#Airport Of Departure Actual Date]]
+
-
::* 1) when the first piece has departed.
+
-
::* 2) when the last piece departs.
+
-
:* [[CT#Airport Of Destination Actual Date]]
+
-
::* 1) when the first piece arrives.
+
-
::* 2) when the last piece arrives.
+
-
 
+
-
The system will need to keep a count of departed and arrived [http://mantis.jaguarfreight.com/wiki/Commodity#Grand_Total:_Loose_Pkgs Grand Total: Loose Pkgs] and [http://mantis.jaguarfreight.com/wiki/Commodity#Grand_Total:_Pkgs_On_Plts Grand Total: Pkgs On Plts].
+
-
:* These values should be '''updated''' each time when Descartes sends the meaningful updates until the total matches.
+
-
 
+
-
==== Implementation Phase 2 ====
+
-
We need to modify our UI / DB to '''keeping a record''' of all this updates.
+
-
 
+
-
=== Delays UC4 ===
+
-
 
+
-
See [[#Delays]]
+
-
 
+
-
=== CT profile and DB re-design to accommodate multiple trans shipment points and splits ===
+
-
 
+
-
To satisfy requirements [[#Transshipment airports]] and [[#Split case]] we could:
+
-
 
+
-
* option A) create additional fields in DB so that all related info can be a part of report/search
+
-
* option B) add Transshipment/Split Comment textarea and post all info there
+
-
 
+
-
BA favors option A  but if the cost (in man-hours) is too high she might go with option B. Please provide this cost.
+
-
 
+
-
=== General info about Messaging ===
+
-
 
+
-
CT2 and Descartes system (GLN) will exchange XML messages.
+
-
 
+
-
In a nutshell:
+
-
* CT2 sends MAWB (same as FWB) to Descartes(GLN) network/server
+
-
* GLN forwards to Airline nework
+
-
* when update becomes available info is passed back to CT2 through Descartes
+
-
 
+
-
Per Rusty (Descartes):
+
-
 
+
-
FSU messages are event driven meaning they will be sent per flight per event.
+
-
 
+
-
==== Common FSU Types ====
+
-
 
+
-
Freight Status Update (FSU) Messages - http://www.ccnhub.com.au/fsu/ [^]
+
-
 
+
-
Common FSU Types:
+
-
 
+
-
- BKD: Consignment booked on a specific flight
+
-
- RCS: Consignment received from shipper or agent
+
-
- MAN: Consignment manifested on a specific flight
+
-
- DEP: Consignment departed on a specific flight
+
-
- TFD: Consignment transferred to another airline
+
-
- RCT: Consignment received from another airline
+
-
- RCF: Consignment received from a given flight
+
-
- NFD: Consignment arrived at destination and the consignee or agent has been informed
+
-
- AWD: Consignment arrival documents delivered to the consignee or agent
+
-
- TRM: Consignment to be transferred to another airline
+
-
- CCD: Consignment cleared by Customs
+
-
- DLV: Consignment delivered to the consignee or agent
+
-
- DIS: Consignment with a discrepancy
+
-
 
+
-
==== Expanded Consignment Status description ====
+
-
 
+
-
'''BKD'''StatusDetails - Consignment booked on a specific flight.
+
-
'''FOH'''StatusDetails - Consignment is on hand pending "ready for carriage" determination.
+
-
'''RCS'''StatusDetails - Consignment physically received from a shipper or an agent.
+
-
'''RCT'''StatusDetails - Consignment received from another airline.
+
-
'''PRE'''StatusDetails - Consignment prepared for loading.
+
-
'''MAN'''StatusDetails - Consignment manifested on a specific flight.
+
-
'''DEP'''StatusDetails - Consignment departed on a specific flight.
+
-
'''RCF'''StatusDetails - Consignment physically received from a given flight or surface transport of the given airline.
+
-
'''CRC'''StatusDetails - Consignment information has been reported to Customs.
+
-
'''CCD'''StatusDetails - Consignment cleared by Customs.
+
-
'''TGC'''StatusDetails - Consignment has been transferred to Customs/Government control.
+
-
'''AWD'''StatusDetails - Consignment where arrival documents have been delivered to the consignee or his agent.
+
-
'''TRM'''StatusDetails - Consignment to be transferred to another airline.
+
-
'''TFD'''StatusDetails - Consignment transferred to another airline.
+
-
'''AWR'''StatusDetails - Consignment documents arrived on a given flight or surface transport of the given airline.
+
-
'''ARR'''StatusDetails - Consignment arrived on a given flight or surface transport of the given airline.
+
-
'''DIS'''StatusDetails - Consignment with a discrepancy.
+
-
'''NFD'''StatusDetails - Consignment where consignee or his agent has been informed of ints arrival at destination.
+
-
'''DLV'''StatusDetails - Consignment delivered to the consignee or his agent.
+
-
'''DDL'''StatusDetails - Consignment delivered to consignee door.
+
-
 
+
-
=== IATA/CASS id for Valley Stream office ===
+
-
 
+
-
We can register the New York office with 9994939/0015 number. - Rusty
+
-
 
+
-
=== Outgoing message ===
+
-
Must be included:
+
An FSR message should be transmitted under the following conditions.
-
* From (Jaguar id)
+
Only if the full 11 digit airline is set and the airline is set and the estimated departure is set.
-
* To (Airline id)
+
-
* doctype
+
-
* FWB number
+
-
Example:
+
The FSR should start sending 1 day prior to departure or when departure date is set to the current date and plus 24 hours.  The FSR should continue to transmit every X hours until the actual airport of departure date has been confirmed and updated. 
-
<pre>
+
*  Status code for Departure in the FSU or FSA is DEP
-
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+
-
<ns3:Envelope xmlns:ns2="http://www.myvan.descartes.com/ebi/2004/r1" [^] xmlns:ns3="http://www.w3.org/2003/05/soap-envelope" [^] xmlns:ns4="http://schemas.xmlsoap.org/ws/2004/03/addressing"> [^]
+
-
<ns3:Header>
+
-
<ns4:From>
+
-
<ns4:Address>urn:duns:657589457</ns4:Address>
+
-
</ns4:From>
+
-
<!—THIS NEEDS TO BE THE AIRLINE ID.-->
+
-
<ns4:To>urn:duns:657589457</ns4:To>
+
-
<ns4:Action>urn:myvan:FWB</ns4:Action>
+
-
<ns2:Sequence>
+
-
<ns2:MessageNumber>351-5648-6541</ns2:MessageNumber>
+
-
</ns2:Sequence>
+
-
</ns3:Header>
+
-
    <ns3:Body>
+
-
        <JaguarFile>
+
-
            <Shipment>
+
-
                <FWB>
+
-
                    351-5648-6541
+
-
                </FWB>
+
-
            </Shipment>
+
-
        </JaguarFile>
+
-
    </ns3:Body>
+
-
</ns3:Envelope>
+
-
</pre>
+
-
=== UC1 Incoming message ===
+
The FSR should begin to start to transmit again 24 hours prior to the estimated arrival of the trans-shipment airport if applicable and continue to send every X hours until the actual arrival of the trans-shipment airport has been updated.  If no trans-shipment airport is entered, this step should be skipped.
-
Example: (Total shipment delivered), sent by Rusty
+
*  Status code for arrival of a trans-shipment airport RCF (received from flight) or ARR. 
-
[[File:No trans no split.JPG]]
+
The FSR should again begin to start to send 24 hours prior to estimated arrival of the destination airport and continue to send every X hours until the actual arrival of the destination airport has been confirmed and update.  
-
=== UC2 Incoming message ===
+
*  Status code for arrival of the destination airport is ARR.
-
This is multistop case.
 
-
No example available.
 
-
=== UC3 Incoming message ===
+
Current conditions have been hard coded and we have been advised is no longer required.
 +
*Specified Airlines
 +
*Specified Origin Country - Gen tab, 11. Origin country;
 +
We will need an admin section which will be defined
-
This is split case.
+
We should also provide operators with the ability to transmit the FWB message, when they have booked the shipment directly with the airlines.
-
Partial shipment: (per Rusty)
+
*The system will have no way of validating if the shipment was a direct booking or not, so the giving the operators the ability to transmit this on there own is current suggestion.
 +
When an FWB message is transmitted to the airline, this should trigger automatic updates without the use of FSR's.  This is not a guaranteed rule by every airline, so the FSR's should continue to be sent as defined above.
 +
We should have a log of all messages sent and received.
-
<?xml version="1.0" encoding="utf-8"?>
+
We should also have a place to be able to view any rejected messages or messages that do not match records.
-
<ns0:Status xmlns:ns0="http://FLogic.DescartesAir.Schemas" [^] >
+
-
<Header>
+
-
  <Identifier>FSU</Identifier>
+
-
  <AirlinePrefix>016</AirlinePrefix>
+
-
  <AirWaybillNumber>58153406</AirWaybillNumber>
+
-
  <AirWaybillOriginCity>ORD</AirWaybillOriginCity>
+
-
  <AirWaybillDestinationCity>FMO</AirWaybillDestinationCity>
+
-
  <ShipmentInformation>
+
-
  <DescriptionCode>T</DescriptionCode>
+
-
  <NumberOfPieces>68</NumberOfPieces>
+
-
  <WeightCode>L</WeightCode>
+
-
  <Weight>31381</Weight>
+
-
  </ShipmentInformation>
+
-
</Header>
+
-
<FlightStatusInformation>
+
=== Additional Use Cases ===
-
  <Identifier>DEP</Identifier>
+
-
  <StatusDescription>Consignment has departed</StatusDescription>
+
-
  <CarrierCode>UA</CarrierCode>
+
-
  <FlightNumber>940</FlightNumber>
+
-
  <Day>28</Day>
+
-
  <Month>10</Month>
+
-
  <AirportCode>ORD</AirportCode>
+
-
  <ArrivalAirportCode>FRA</ArrivalAirportCode>
+
-
+
-
<ShipmentInformation>
+
-
<DescriptionCode>P</DescriptionCode>
+
-
<NumberOfPieces>7</NumberOfPieces>
+
-
</ShipmentInformation>
+
-
? <TimeInformation>
+
-
? <Departure>
+
-
<TypeOfTimeIndicator>A</TypeOfTimeIndicator>
+
-
<Time>1828</Time>
+
-
</Departure>
+
-
? <Arrival>
+
-
<TypeOfTimeIndicator>E</TypeOfTimeIndicator>
+
-
<Time>0921</Time>
+
-
<DayChangeIndicator>N</DayChangeIndicator>
+
-
</Arrival>
+
-
</TimeInformation>
+
-
</FlightStatusInformation>
+
-
</ns0:Status>
+
-
== QA Strategy and Test Plan ==
+
Reusing a MAWB number - This is addressed in a separate http://ct.jaguarfreight.com/wiki/2555_rfsa
-
== History ==
+
Split shipments are still being researched and will be defined in the future.
-
=== 0002491 [Air Status EDI] (BA) Create requirements wiki for this project ===
+
-
=== Delays section added ===
+
==Admin==
-
* added to spec: [[#Delays]] --[[User:Alex|Alex]] 22:05, 18 November 2010 (EST)
+
We will need a specified or separate message details sections (same as we have in admin > client application admin > TMS tab, but it should not interfere with this tab or be combined with this tab)  
-
=== 0002555: [Air Status EDI] (Use case) Operator attempted to change MAWB  ===
+
We also, would like to be able to stop transmission of the FSR's to certain airlines if required, so we should have all the airlines listed and a check box to disable certain airlines.
 +
</div>

Current revision as of 21:41, 24 February 2011

Contents

[edit] Parent mantis

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

[edit] 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 in XML format
  • FWB-message - Forwards way bill or MAWB details - Out going message to Descartes GLN
    • Set Up in CargoImp format

[edit] Information

Descartes is offering a service to automate air status updates.

In order to receive these updates for shipments that we do not book directly with the airline (which is the majority of shipments), we need to send a FSR message to Descartes and Descartes will pass this information on to the airlines. In response to the FSR message the airline will send back and FSU or FSA to Descartes, which Descartes will push through to our system. These messages should update the Airport Of Departure Actual Date, Trans Shipment Actual Date (if applicable) and Airport Of Destination Actual Date.

Implementing Automatic updates would save the operators a lot of time. Currently the operators call the airlines and manually enter these updates.

[edit] Business Requirements

An FSR message should be transmitted under the following conditions.

Only if the full 11 digit airline is set and the airline is set and the estimated departure is set.

The FSR should start sending 1 day prior to departure or when departure date is set to the current date and plus 24 hours. The FSR should continue to transmit every X hours until the actual airport of departure date has been confirmed and updated.

  • Status code for Departure in the FSU or FSA is DEP


The FSR should begin to start to transmit again 24 hours prior to the estimated arrival of the trans-shipment airport if applicable and continue to send every X hours until the actual arrival of the trans-shipment airport has been updated. If no trans-shipment airport is entered, this step should be skipped.

  • Status code for arrival of a trans-shipment airport RCF (received from flight) or ARR.

The FSR should again begin to start to send 24 hours prior to estimated arrival of the destination airport and continue to send every X hours until the actual arrival of the destination airport has been confirmed and update.

  • Status code for arrival of the destination airport is ARR. 


Current conditions have been hard coded and we have been advised is no longer required.
*Specified Airlines
*Specified Origin Country - Gen tab, 11. Origin country; 
We will need an admin section which will be defined

We should also provide operators with the ability to transmit the FWB message, when they have booked the shipment directly with the airlines.

  • The system will have no way of validating if the shipment was a direct booking or not, so the giving the operators the ability to transmit this on there own is current suggestion.

When an FWB message is transmitted to the airline, this should trigger automatic updates without the use of FSR's. This is not a guaranteed rule by every airline, so the FSR's should continue to be sent as defined above.

We should have a log of all messages sent and received.

We should also have a place to be able to view any rejected messages or messages that do not match records.

[edit] Additional Use Cases

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

Split shipments are still being researched and will be defined in the future.

[edit] Admin

We will need a specified or separate message details sections (same as we have in admin > client application admin > TMS tab, but it should not interfere with this tab or be combined with this tab)

We also, would like to be able to stop transmission of the FSR's to certain airlines if required, so we should have all the airlines listed and a check box to disable certain airlines.

Retrieved from "https://wiki.jaguarfreight.com/2782_rfsa"
Personal tools