FS 304310 EPOD-TTM Interface
OBS Logistics Ltd
EPOD-TTM Interface
CALIDUS EPOD
20th December 2012 - 0.2
Reference: FS 304310
Contents
Functional Overview
Client Requirement
Regarding the projects LF Logistics, Partnerlink and others, it is required to have a stand-alone interface between the two CALIDUS products TTM and EPOD.
Additional requirements from the Partnerlink project:
- TTM to provide ETA information for jobs on loads.
- EPOD to allow resequencing of jobs on a load.
- TTM to show audits of Resequencing.
These will be specified spearately, but the details of the interface will be noted here.
Solution Overview
The solution will be to provide the data and files from EPOD, which will have the responsibility of passing along the information from the clients' TMS systems, acting as a data store for TTM.
All interface actions required are from EPOD to TTM, with the existing systems.
Actions required:
- Initial creation of Trip and Order information - Message type TRP, including full Order details
- Updates of Trip information - Message type TRP, including header Order information
- Updates of Order information - Message type ORD.
- Resequencing of Orders on Trips - Message type RES (based on TRP message).
- Moving Orders from one Trip to another Trip - Message type TRP, including header Order information.
- Order In Progress - Message type OIT, including GPS information (based on existing ALC message)
- Order Complete - Message type DEL
- Order Cancelled - Message type CAN
- Trip Complete (Not required at this stage)
Scope
Set-up
Pre-requisites
- Working versions of CALIDUS ePOD and TTM.
Menu Structure
None
Data
As described
Functional Description
EPOD Changes
EPOD Import and Admin will need to change when amending statuses on orders, to reset XFER flags where necessary, as this is the mechanism by which the messages will be sent.
- Loads and Jobs should be created with an Interface flag set to blank ("")
- Confirmation or Cancellation of a Job or Load requires that the Interface flag be reset to "N"
- Updates of EPL_LOAD_ID on EPOD_JOB should reset the Interface Flag of the Load From and the Load To, if present, to blank. Admin and Import.
- Updates of Load or Job information on Loads or Jobs that are not Cancelled or Completed to reset the Interface Flag on the relevant file to blank. Admin and Import.
- Add Interface Flag to EPOD_USER_AUDIT. Initialise to "N".
For Partnerlink:
- Add Resequence functionality
- Add EPL_SEQUENCE to EPOD_JOB
- Create EPL_SEQUENCE in Import, initially in order received.
- Flag to control whether Jobs should be in Planned Start D/T Seq - if so, resequence at end.
- Add LOAD_RESEQUENCE message to Server
- Add LOAD_RESEQUENCE send
File Delivery Mechanism
The interface will
- deliver a single message per file
- in flat-file format
- in TTM XML format, all content being HTML-safe-encoded.
- following the standard TTM naming convention (<SysFrom>_<SysTo>_<SourceID>_<EventID>_<UniqueID>.XML)
- <SysFrom> - The system sending the message - always "EPOD"
- <SysTo> - The system receiving the message - always "LOTS"
- <SourceID> - Identifying source ID of the payload - always EPL_SITE_ID
- <EventID> - the message being transmitted. Always one of: "TRIP", "ORD", "OIT", "DEP", "CAN", "DEL"
- <UniqueID> - a unique ID for the file. Always made up of Date/Time stamp in format DDMMYYHHNNSSMM.
- initially created as .TMP files, then renamed to .XML when complete
All messages will be sent through the existing AutoExport functionality of CALIDUS EPOD, utilising configuration specified within the label EPOD_XF_CONFIG.
Additional fields will be added to this table:
- A new Type "FILE" will be added, to identify that this send is through File-copy Transfer.
- New ID (in addition to the existing standard EPOD message types of LOAD and JOB) will be created to filfil the required actions listed above, as "TTM-IF". This will act for all message types that require sending for TTM.
- Destination will be set to the directory to which the flat files will be copied. This is expected to be a share on the same machine, e.g. "\\127.0.0.1\TTM-IMPORT\"
- A new field will control the filename created. This will be populated with "EPOD_LOTS_<EPL_SITE_ID>_<EPL_XF_ID>_<DTS>.XML". EPL_XF_ID will be set to the message type being sent (DEP, TRP, OIT, etc), the other "tags" will be replaced with relevant values, either from the data (Site) or generated (Date/Time stamp).
The auto-export program, when creating one of these files, will create the file locally in a temporary area, then re-name the file, when populated, to the destination directory and generated file name. 
Note: the name will only be generated when the file is fully built.
Once the file is delivered, the existing audit mechanism (EPOD_XF_AUDIT_HEADER/DETAIL) will be used to note that the file was sent. The built file will not be stored (this will be done by EPOD).
Failure to deliver the file will result in the error being retrieved and stored against the tables above.
Message Details
Messages will be checked for sending in this order:
- TRP
- RES
- ORD
- DEL/CAN
- OIT
Note: The sequence is very important for the process to work efficiently. Note also that OIT is after DEL/CAN, as TTM can then decide whether an order is closed before receiving the In Transit message (if batched together) and therefore controll whether an ETA needs to be calculated.
Type TRP
This message will be used for the following:
- Initial creation of Trip and Order information
- Updates of Trip information
- Moving Orders from one Trip to another Trip
The message will be sent by finding all Loads on EPOD_LOAD where the Interface flag is blank - the status is irrelevant.
All loads found will have an individual file created for them.
The process will:
- For Each Load Found:
- Start Transaction
- Retrieve all Job, Container and Product information for the Load.
- Build the Trip Header XML information for the Load (Format TBC)
- For each Job on the Load:
- Build the Order and Stop XML information for the Job. If the Interface flag is blank the full information will be build, otherwise only skeleton data will be built.
- Set the Job interface flag to "N"
- Set the Load Interface flag to "N"
- Build temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
Note: Order Detail XML data will send Containers with a quantity of 1, by default. If the container is a loose container, it will send the product information within instead.
Type RES
This message will be used for the following:
- Resequencing of Orders on Trips - Message type RES (based on TRP message).
The message will be sent by finding all EPL_MESSAGE_TYPE of "LOAD_RESEQUENCE" on EPOD_USER_AUDIT where the interface flag = "N".
Warning: EITHER
All records found will have an individual file created for them.
OR
All records found will be sent in one file.
The process will:
- For Each Record Found:
- Start transaction
- Build the RES XML information for the record.
- Set the record interface flag to "Y"
- Build temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
Type ORD
This message will be used for the following:
- Updates of Order information
The message will be sent by finding all Jobs on EPOD_JOB where the Interface flag is blank - the status is irrelevant.
Warning: EITHER
All Jobs found will have an individual file created for them.
OR
All Jobs found will be sent in one file.
The process will:
- For Each Job Found:
- Start transaction
- Build the Order and Stop Full XML information for the Job.
- Set the Job interface flag to "N"
- Build temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
Note: Order Detail XML data will send Containers with a quantity of 1, by default. If the container is a loose container, it will send the product information within instead.
Type DEL/CAN
This message will be used for the following:
- Order Complete - Message type DEL
- Order Cancelled - Message type CAN
The message will be sent by finding all Jobs on EPOD_JOB where the Interface flag is "N" and the status is "C" or "X", sorted by status. All Jobs found will be sent in one file for DEL and one file for CAN.
The process will:
- Start transaction
- For Each Complete Job Found:
- Build the Order and Stop Full XML information for the Job.
- Set the Job interface flag to "Y"
- Build/Add to temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
- Start transaction
- For Each Cancel Job Found:
- Build the Order and Stop Full XML information for the Job.
- Set the Job interface flag to "Y"
- Build/Add to temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
Note: Order Detail XML data will send Containers with a quantity of 1, by default. If the container is a loose container, it will send the product information within instead.
Type OIT
This message will be used for the following:
- Order In Progress - Message type OIT, including GPS information (based on existing ALC message)
The message will be sent by finding all EPL_MESSAGE_TYPE of "JOB_LOCK_REQUEST" on EPOD_USER_AUDIT where the interface flag = "N".
All records found will have an individual file created for them.
The process will:
- For Each Record Found:
- Start transaction
- Build the OIT XML information for the record.
- Set the record interface flag to "Y"
- Build temporary file with XML information
- Rename temporary file to destination directory and filename
- Commit transaction
Appendix A: TEST PLAN
| Test Script / Scenario Reference | EPOD-TTM Interface | Call Number(s): 304310 |
| Test Script / Scenario Description | description of what is to be achieved | PASS / ISSUES / FAIL |
| Menu Access | Where on the menus the item can be found | |
| Pre-requisites | The prerequisites of the test | Tested By: |
| Test Objective | The details of what each group of tests is to achieve | Date: |
| Step | Action | Result | Remarks | P/F |
| 1 | Area being tested in this cycle | |||
| Any notes or prerequisites for the tests following. | ||||
| 1.01 | The actions to follow | The expected result | ||
| 1.02 | The actions to follow | The expected result | ||
| 1.03 | The actions to follow | The expected result |
Appendix B: Quote & Document References
| Cost Details | |||
| Activity | No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
| Requirements | 0.00 | 0 | £0.00 |
| Change Request Evaluation | 0.00 | 0 | £0.00 |
| Functional Specification | 0.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0 | £0.00 |
| Development | 0.00 | 0 | £0.00 |
| Testing and Release | 0.00 | 0 | £0.00 |
| Implementation | 0.00 | 0 | £0.00 |
| Project Management | First argument to "number_format" must be a number. | 0 | £First argument to "number_format" must be a number. |
| TOTAL | First argument to "number_format" must be a number. | £First argument to "number_format" must be a number. | |
| Estimate excludes training, release to live and go live support. |
B.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | Reference1 | 0.1 | 01/01/2011 |
B.2 Glossary
B.3 Authorised By
Phil Harding | OBS Project Manager | _____________________________ |
Graham Rothwell | OBS Consultant | _____________________________ |
