FS 304310 EPOD-TTM Interface
OBS Logistics Ltd
EPOD-TTM Interface
CALIDUS EPOD
20th December 2012 - 0.1
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.
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. It will be necessary in the future to include some request/response information instigated by TTM, but this will be covered by specific development for those projects.
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 TRP, including header Order information
- 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.
- Confirmation or Cancellation of a Job or Load requires that the Interface flag be reset to "N"
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 IDs (in addition to the existing standard EPOD message types of LOAD and JOB) will be created to filfil the required actions listed above, for example, TTMDEP, TTMORD, etc
- 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, whereas 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 that 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
- ORD
- DEL/CAN
- OIT
Note that this 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 sent by polling the status of the
- 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
- Resequencing of Orders on Trips - Message type TRP, including header Order information
- Moving Orders from one Trip to another Trip - Message type TRP, including header Order information
Type ORD
- Updates of Order information - Message type ORD.
Type OIT
- Order In Progress - Message type OIT, including GPS information (based on existing ALC message)
Based off the message audit table.
Type DEL
- Order Complete - Message type DEL
Type CAN
- Order Cancelled - Message type CAN
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 | _____________________________ |
