View source for 271602

=271602 - PA-7XVMF8/ EFX to CTMS Accepted Orders=

Copyright OBS Logistics © 2010

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied


=FUNCTIONAL OVERVIEW=

==Client Requirement==
Create an interface between EFX and CTMS to transfer Load Detail from EFX into CTMS for loads accepted from the Notice Board. 

For loads taken from a non-CTMS enabled site then some basic detail would be sent to enable a generic order to be created - From Postcode, To postcode, (a postcode decode table to populate the to/from locations would be required) RPE quantity, offering site (via EFX Site Decode table) delivery date, delivery time, Offering site contact details into Special Instructions (prompting the accepting site to contact the offering site for precise to/from locations).

If a load is accepted from an CTMS enabled site, evidenced by the reference being CTMS produced (MAN/RTE-00XXXXX) this reference should then be used at interface to obtain the original CTMS order detail, or in effect create a cross-docked order.


==Solution==
EFX/ESI will require a method of identifying which CTMS database name is associated with each Loading site and each Accepting site.

When a Trip is Accepted in EFX and the Loading site is an CTMS site then the existing message will be sent to the Loading site as now to tell them which site has Accepted the trip.

On receipt of the message by the Loading sites CTMS system it will then update its relevant data in CTMS (as specified under RIO PA-7XVL6X).

In addition to this if the accepting site is associated to an CTMS database then a new order flow message will need to be sent to this accepting site. 

The Order data to be passed between the EFX and the accepting sites CTMS system will use the existing TripOrder.XSD format.

A new set of folders, system registries, database jobs etc. will need to be created on the CTMS systems to accommodate this new order flow.

The existing system registries for the existing EFX flow are unchanged but may need setting up on CTMS systems that do not currently interact with EFX and the registries are :-

EFX_PATH
EFX_TRIP_DTL_PATH
EFX_FAILURE_PATH  

The new system registries for the new EFX order XML flow will be  :

EFX_INBOUND_PATH (/webint/<database>/interface/EFX/IN)
EFX_INBOUND_FAIL (/webint/<database>/interface/EFX/IN/failures)
EFX_INBOUND_ARCH(/webint/<database>/interface/EFX/IN/archive)
EFX_INBOUND_ORDER_IDENTIFIER (EFX_MTS_ORDER_*.XML)
EFX_INBOUND_ORDER_LISTING_NAME (EFX_ORDER_FILES.lst)
EFX_LISTING_ORDER_SCRIPT_NAME (EFX_ORDER_SCRIPT.ksh)

The new XML order flows between EFX and CTMS systems will use the existing generic order flow. 

==Scope==
This change will be applied to system version 10.5 

==System Registries==
Existing system registries for the current EFX flow are unchanged but may need setting up on CTMS systems that do not currently interact with EFX and are :-

EFX_PATH
EFX_TRIP_DTL_PATH
EFX_FAILURE_PATH  

The new system registries for the new EFX XML Inbound order flow will be :-

EFX_INBOUND_PATH (/webint/<database>/interface/EFX/IN)
EFX_INBOUND_FAIL (/webint/<database>/interface/EFX/IN/failures)
EFX_INBOUND_ARCH(/webint/<database>/interface/EFX/IN/archive)
EFX_INBOUND_ORDER_IDENTIFIER (EFX_MTS_ORDER_*.XML)
EFX_INBOUND_ORDER_LISTING_NAME (EFX_ORDER_FILES.lst)
EFX_LISTING_ORDER_SCRIPT_NAME (EFX_ORDER_SCRIPT.ksh)

=FUNCTIONAL DESCRIPTION=

'''In order for the following functionality to work it will be necessary for ESI/EFX to be able to distinguish which offering/accepting sites are associated with which CTMS databases (if any)''' 

There 4 possible scenarios that need to be considered.

*Neither the offering site (site that loaded the trip onto the EFX system) nor the accepting site have CTMS databases.

In this case CTMS will not be involved at all so not relevant to this specification.

*The offering site is CTMS related but the accepting site is not.

The sending of the trip to EFX is covered in the specification for RIO PA-7XVM64 and the returning message is covered under specification for RIO PA-7XVL6X there may be a need for minor changes by EFX and ESI to cope with multiple CTMS databases starting to send and receive EFX messages as currently this is a single flow to the Consumer database.

*The offering site is not CTMS related but the accepting site is CTMS related.

A new order flow will be generated by EFX and sent through ESI to CTMS. It is this change that is covered by this specification.

*Both the offering site and the accepting site have CTMS systems.
 
The interfaces between CTMS and the EFX for the offering site are identical to case ii) and is covered under the other specifications.

But in addition to the above a new order flow will be sent to the accepting CTMS site which is identical to case iii).

==Identify CTMS Database==

Although this will be controlled between EFX and ESI so is not directly the responsibility of CTMS the following is a suggestion of a possible solution

EFX could add a new field called TMS_DATABASE_NAME against all of the EFX sites.

When an Offering Site needs an update message sent (as specified under the other RIO’s) then if this site is related to an CTMS database then EFX can produce a file in the appropriate format with an appropriate name which contains the CTMS database name.

ESI could then use the relevant portion of the name of the file to know which flow is being dealt with and which folder on the CTMS system that the file needs to be placed in.

This will be handled in CTMS system using the existing EFX flow but with modifications which are covered under the other EFX RIO’s.

When a load is accepted by a site in EFX then this already sends a relevant message to the offering site (as one of the messages above). 

In addition to this EFX will need to check if the accepting site has a related CTMS database (it could even be the same CTMS database as the offering site). 

If it is an CTMS site than a new message will be generated by EFX containing all of the order information (with the CTMS database name as part of the file name) which will then be picked up by ESI.

ESI can then build an XML file in the appropriate format (they already create files in the correct format for existing flows to CTMS using the TripOrder.XSD) using the database name to determine which flow they are dealing with and subsequently once built then which folder on the CTMS system they need to place the file. 

==EFX via ESI to CTMS Fields==

The EFX screen that holds Load (Order) information currently looks like :-

[[Image:271602_1.png]]

Once a load is accepted (‘Accept Load’) then EFX will check if the accepting site is related to an CTMS database and if it is it will produce a file in a format to be agreed between EFX and ESI.

There are 2 possibilities for the level of information to be passed and a decision regarding which approach should be made prior to development:

*A single order for the load will be generated by ESI using the last delivery point as the destination.

*an order per delivery point is generated with quantities provided distributed evenly between all of the deliveries.

This decision will only effect what information will be passed by EFX to ESI and will not effect how CTMS will handle the XML provided.

ESI will then map the fields provided by EFX into the existing XML format required by CTMS (see Appendix A for XSD and Appendix B for a sample XML).

The following is a suggestion of which fields should map between EFX and CTMS, DHL should confirm which fields from EFX need loading into which fields in CTMS.

[[Image:271602_2.png]]

It is expected that EFX will not be able to provide a CTMS location code so the passed postcodes will be decoded into dummy locations (by postal region), which will then need to be updated by users once details have been provided by the offering site verbally.

This will be dependant upon the decision to have an order per delivery point or just one order for the load.

==New XML Process(Generic)==

CTMS already has a generic order inbound process that is configurable.

The form that controls this process looks like :-

[[Image:271602_3.png]]

A new process will be setup to receive the order XML files provided by ESI.

The filename format will probably be something like ‘EFX_TMS_COLV_ORD_’ to keep it consistent with the existing XML flows with the date time to make it unique and with an extension of ‘.XML’.

The delivery directory will be called ‘/webint/conprd/interface/EFX/IN’ to keep it consistent with sub-directories for archive and failures. 

Once started then this form will then automatically submit a database job (runs 
INT_XML_IN.PROCESS_ORD_XML_IN) to accept any files placed in the correct folder with the correct name by ESI and to generate/update orders in CTMS from data in this file.

=REFERENCES=

Not Available

=DOCUMENT HISTORY=

{| Border="1"	
| <center>'''Version'''</center>
| <center>'''Date'''</center>
| <center>'''Status'''</center>
| <center>'''Reason'''</center>
| <center>'''Initials'''</center>

|-
| <center>0.1</center>
| <center>03/03/10</center>
| <center>Draft</center>
| Initial version
| <center>DRM</center>

|-
| <center>0.2</center>
| <center>18/03/10</center>
| <center>Draft</center>
| Changes following internal meeting
| <center>DRM</center>

|-
| <center>0.3</center>
| <center>22/03/10</center>
| <center>Draft</center>
| Changes following meeting with client
| <center>DRM</center>

|-
| <center>1.0</center>
| <center>01/04/10</center>
| <center>Issue</center>
| Reviewed and Issued
| <center>MJC</center>
|}


=AUTHORISED BY=

{| Border="1"	
| '''''Matt Crisford'''''
| Development Manager
| 

|-
| '''''Peter Greer'''''
| TMSCC MTS Product Manager 
| 

|}