Latest revision as of 13:28, 20 March 2013

PartnerLink

EPOD Vigo Interface

CALIDUS EPOD

20th February 2013 - 0.4
Reference: FS 305796

Functional Overview

The document is intended to describe the exact requirements for the Vigo TMS system interfacing to and from the CALIDUS EPOD system.

Client Requirement

The requirements were captured from the Partnerlink staff on 18/01/2013, at the Kettering operation.

The Vigo system will send messages to the CALIDUS EPOD system to define Loads and Trips to be completed.
The CALIDUS EPOD system will inform the Vigo system that the jobs are completed or cancelled.

Note: There is also a requirement to interface an image of the generated POD document to all TMS systems being used by the PartnerLink partners. This will be covered in a separate document, as this will make use of the existing image upload processing available in the TMS systems.

Solution Overview

A new interface to and from CALIDUS EPOD will be created. This will be heavily based around the existing JobShare interface.

The summary of the solution requirements are:

Standing Data (Vehicles, Users, Reason Codes, Job Groups, Sites) will be manually set up within CALIDUS ePOD - no automated drip-feed of this data will be entered into.
Sending of data to CALIDUS ePOD will be through a new Partnerlink CSV format.
Receiving data from CALIDUS ePOD will be through the OBS XML format.
The mechanism of sending and receiving data will be through Flat File transfer via a shared folder on the Vigo system
The sending of data to CALIDUS ePOD will be through a manual option within the Vigo system ("Send to ePOD").
The Vigo system must merge of Delivery and Collection manifests into a single Consolidated Manifest when sending data.
The Vigo system must sort the data by Type (Deliveries first, then Collections), the planned start time, if available, or sequence to be completed, as required by the customer (Partnerlink).
Amendments to the manifests sent will not be automatically re-exported to CALIDUS ePOD - all amendments will be manually resent on demand by the user through the mechanism above.
CALIDUS ePOD exporting of completed or cancelled jobs will be through a timed process, expected to be every 5 minutes.

Out of scope of this document:

CALIDUS ePOD will be modified to export the POD/POC documents through the standard JobShare Image Upload system.

This will require the Vigo system to be modified as follows:

Consolidate manifests that are assigned to the same user and vehicle onto a new Consolidated Manifest ID.
Convert the information into an agreed CSV format (described here).
FTP or copy the file containing the CSV-formatted payload to an agreed folder.
Create a process for importing data back into the Vigo TMS from an XML flat file in the OBS XML format.

Scope

Note: There are modifications being made to the CALIDUS EPOD system, both for product enhancement and specifically for the Partnerlink customer that are driving changes into both the import and export functionality described here. Some have not yet been finalised. All known modifications to the schemas have been added to this document. Should any further requirements be known after this document is issued, this document will be revised and reissued at that time.

Note: Future modifications may be made to the exporting of data from CALIDUS EPOD to the Vigo system. When modifications of this nature are made, a new validation schema (XSD) for the XML payload will be issued. The modifications to the Vigo system to import this data should be made in such a way that this new XSD can be replaced into the system without program modifications in the future.

Note: It is not deemed necessary at this time to map interfaces from Vigo for Standing Data, as it was agreed that this would be maintained separately and manually within CALIDUS EPOD. Those flows are:

Vehicles
Reason Codes (used when cancelling jobs or pallets)
Users (Drivers)
Customers

Note: A number of actions are outstanding from this meeting regarding the production of this interface specification, as follows:

Partnerlink to provide a list of existing Partner Codes in use.
Partnerlink to provide a document of the standard Reason Codes in use.
Partnerlink to update the spreadsheets (provided to map the import to and Export from ePOD) to indicate Vigo Table and Field Names, for inclusion in this document.

Until these actions are completed, the document will remain in draft form, unless authorised by the customer.

Set-up

Pre-requisites

A working Vigo TMS and CALIDUS EPOD system must be in place.
The two systems must be able to connect via a shared folder, either through an internet or LAN connection. This must be accessible directly, without user and password information, through a shared user-name on the two servers or domain. This will be co-ordinated and configured by the Partnerlink IT team.

Menu Structure

None

Data

As described below.

Functional Description

Vigo Export

The export to the CALIDUS EPOD system will be made at the request of the Vigo user - the user will select an option from the screen which will send all selected manifests through to the CALIDUS EPOD system.

The following is a screen-shot of where this functionality is expected to be added.

Creating the Messages

Should any manifests be available for sending at any time, and there are manifests for the same date that are allocated to the same driver, vehicle and trailer, Vigo will generate a Consolidated Manifest ID and assign this to the manifests that are linked. This will be a unique manifest number in itself, although does not have to be generated in the same format.

The purpose of this is so that some operations will link two manifests together, a set of deliveries, and a set of collections. As the customer requires these tasks to be executed by the same driver and interleave the collections among the deliveries if possible, they must be collected onto the same manifest.

This Consolidated Manifest number should be used to identify the Load for CALIDUS EPOD.

When manifests are consolidated in this way, the sorting of the data should be preserved, but the Delivery manifest jobs placed first on the consolidated manifest.

This functionality should be enabled through configuration within the Vigo system.

Message Content

A basic list of all the fields in the interface for Load (Manifest) and Job follows. A full spreadsheet of all the import flows and fields containing all the limitations on length and defaulted values is provided separately.

#	Field Name	Type	Max Length	Mapped Field	Notes
1	Requestor	C	3	(owning) partner code	Owning Partner - the partner that owns the JobShare job (if present), else the Delivery or Collection Partner, depending on Job Type
2	Reference 1	C	7	Ref1
3	Reference 2	C	16	Ref2
4	Reference 3	C	16	Ref3
5	PartnerJobID	C	14	tracking_code	Is used to form the pallet ID of the pallets to be delivered (this field plus 2-digit count from 01 to Total Pallets). Stored in new reference field.
6	Job Date	C	8
7	Collection Name	C	30	col_name	Collection details - required for POD note (Consignor address)
8	Collection Address 1	C	30	col_addr1	Collection details - required for POD note (Consignor address)
9	Collection Address 2	C	30	col_addr2	Collection details - required for POD note (Consignor address)
10	Collection Address 3	C	30	col_addr3	Collection details - required for POD note (Consignor address)
11	Collection Address 4	C	30	col_addr4	Collection details - required for POD note (Consignor address)
12	Collection Postcode	C	10	col_post	Collection details - required for POD note (Consignor address)
13	Collection Contact	C	30	""	This field is always to be sent blank, to force the users to enter a contact on the PDA client.
14	Collection Phone Number	C	16		Collection details - required for POD note (Consignor address)
15	Collecting Partner	C	3	partner code	Partner code of the partner executing the job (if it's a collection job type)
16	Collection Date	C	8	col_date	Planned Start Date
17	Collection Time	C	5	time	Planned Start Time
18	Delivery Name	C	30	del_name	Customer or Job Address
19	Delivery Address 1	C	30	del_addr1	Customer or Job Address
20	Delivery Address 2	C	30	del_addr2	Customer or Job Address
21	Delivery Address 3	C	30	del_addr3	Customer or Job Address
22	Delivery Address 4	C	30	del_addr4	Customer or Job Address
23	Delivery Postcode	C	10	del_post	Customer or Job Address
24	Delivery Contact	C	30	""	This field is always to be sent blank, to force the users to enter a contact on the PDA client.
25	Delivery Phone Number	C	16	phone
26	Delivery Partner	C	3	Partner Code	Partner code of the partner executing the job (if it's a delivery job type)
27	Delivery Date	C	8	del date	Planned Start Date
28	Delivery Time	C	5	time	Planned Start Time
29	Number of Full Pallets	N		full	Added to form Total Pallets
30	Number of Half Pallets	N		half	Added to form Total Pallets
31	Number of Quarter Pallets	N		qtr	Added to form Total Pallets
32	Number of OverSize Pallets	N		osize	Added to form Total Pallets
33	Weight in Kilos	N		kilos	Divided by Total Pallets to create a Weight per pallet
34	Manifest Notes 1	C	48	notes1	Job Instructions
35	Manifest Notes 1	C	48	notes2	Job Instructions
36	Manifest Notes 1	C	48	notes3	Office Instructions
37	Manifest Notes 1	C	48	notes4	Office Instructions
38	Service	C	2	service	Service Level
39	Surcharges	C	16	surcharges
40	Pallet Spaces	N		spaces
41	Number of Chep pallets	N			N/A
42	Hazardous	C	1		N/A
43	ADR Number	N	5.2		N/A
44	Packing Group	C	10		N/A
45	Category	C	10		N/A
46	Product name	C	10		N/A
47	UN Number	C	10		N/A
48	24 Hour Phone Number	C	10		N/A
49	Number of Packs	N			N/A
50	Number of Litres	N			N/A
51	Weight in Kilos	N			N/A
52	Value 1	N			N/A
53	Value 2	N			N/A
54	Value 3	N			N/A
55	Spare Text 1	C	6		N/A
56	Job Bar Code	C	16		N/A
57	Manifest Number	C	20	manifest_no	Load ID
58	Account Code	C	12		required - unknown what this is.
59	Trailer Number	C	10	trailer	Trailer ID
*	Driver ID	C	10		Driver to whom the job has been assigned
*	Vehicle ID	C	10	vehicle
*	Job Type	C	2		Identifying Collection "C" or Delivery "D"
*	PF Depot	C	3		Palletforce depot code
*	PF Tracking Number	C	13		Palletforce tracking number

Notes:

The Vigo Table and Field names have been provided by the Partnerlink team.
Jobs with planned start dates and times should be sent through on the message.
Jobs without planned start dates and times, but with a service level agreement against them i.e. AM or PM deliveries, should have the time defaulted appropriately. For example:
- AM - set to 11:59
- PM - set to 16:59
Jobs without any planned start times or service level agreements should leave the time unset (i.e. blank).
The jobs should be sent through in the order in which they should be completed on the manifest.

Sending Mechanism

The files can be :

Sent by the Vigo TMS via FTP to an FTP service hosted by OBS.
Pulled by CALIDUS ePOD via FTP from an FTP service hosted by Vigo.
Copied by CALIDUS ePOD from a shared folder on the Vigo TMS.
Copied by Vigo to a shared folder on CALIDUS ePOD.

Note: It is expected that this transfer will be via file transfer though a shared folder on the Vigo TMS.

Regardless of the mechanism chosen above, the final destination folder should contain only completed files in the agreed naming convention, not files being built. The files should be built and copied under a temporary naming convention, before renaming to csv file (i.e. .tmp files).

The files to be picked up will be named as follows:

<SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>__<SEQ>.csv

where

<SENDER> is the system sending the file - expected to be "vigo"
<RECEIVER> is the system receiving the file - expected to be "epod"
<OPERATING_PARTNER> is the operating partner code, i.e. L02, L03, etc.
<DATE> is the date in YYYYMMDD format
is the time in HHMMSSNN format
<SEQ> is a unique counting sequence for each file created in a run.

No responses to the files shall be given - the receiving system (CALIDUS ePOD in this case) will maintain an audit trail to be examined by the user on event of failure.

Each manifest should be sent in a separate file, to minimise disruption if a single file fails.

The entire content of the file will fail if there is a problem with any content.

Importing into CALIDUS EPOD

Note: This information is specified in detail in another document, but the bulleted information is listed here for completeness.

The import into CALIDUS EPOD will be modified as follows:

Vehicle ID will be created in advance
If the vehicle does not exist, one will be created with basic information
The Vehicle data will be modified to hold whether this vehicle is a tractor.
If vehicles are created through the import and a trailer ID is identified against the vehicle, the vehicle will be marked as a tractor, requiring Trailer entry.
The Load and Jobs data will be modified to hold the trailer ID against them.

CALIDUS EPOD Export Process

A process runs on a timed schedule within the CALIDUS EPOD application, to pick up any jobs that have been completed and export them to external systems.

The system be configured to ensure that updates are sent.

The exporting of this data will be modified to include:

Entered Trailer ID (at Job level).
Clause information (per pallet)
External Reference ID (at Job level, containing the PartnerJobID.

Note: Trailer ID and Clause modifications are out of scope of the existing solution being provided, but have been added here so that the systems can be prepared to handle this functionality when it becomes available.

CALIDUS EPOD Export Message Content

A basic list if all the fields in the interface for Job follows. A full spreadsheet of all the export flows and fields containing all the limitations on length and defaulted values is provided separately.

EPOD_JOB

Name	Description	External Field	Notes
EPL_SITE_ID	Unique Reference for the Site that the Job belongs to	partner code	This will be the Partner ID
EPL_JOB_ID	Unique reference for the job. If not provided on Import, this will be generated by EPOD		N/A
EPL_LOAD_ID	Unique Reference for the Load that the Job belongs to. If not provided, defaulted from the enclosing EPOD_LOAD	Manifest_No	As Sent
EPL_JOB_TYPE	D=Delivery, C=Collection, S=Service	"D" or "C"	As Sent
EPL_JOB_GROUP		partner code	This will be the Partner ID
EPL_JOB_INSTRUCTION	Instructions for the Driver	Notes1+Notes2	As Sent
EPL_JOB_SIGNATURE	The signature taken from the customer when the job was completed. This is in the form of a Base64-encrypted Jpeg file		x
EPL_REASON_CODE	If a job has been cancelled, the reason code entered by the user is held here.		x
EPL_LINKED_REASON	If the job is a delivery, and a collection of the same load with the same EPL_JOB_CODE is cancelled, this delivery will be cancelled, and this field will be set to "Y"		N/A
EPL_STATUS	C- complete, X cancelled		x
EPL_CUSTOMER_CODE	Customer Code from external system. If not provided, one will be generated from EPL_CUSTOMER_NAME	Account_Code	As Sent
EPL_PHOTO_ID	If cancelled, a photo may have been taken by the user. If so, this field is populated with a unique ID.		x
EPL_PHOTO	The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file		x
EPL_ENG_SIGNATURE	The signature taken from the driver/engineer when the job was completed, if required. This is in the form of a Base64-encrypted Jpeg file		x
EPL_SEQUENCE	The sequence of the job. This could be the sequence sent on Import, a pre-defined sequence (if one was not provided) or a user-changed value (if enabled)
EPL_START_PLANNED_DATE		Del_Date	As Sent
EPL_START_PLANNED_TIME		Time	As Sent
EPL_END_PLANNED_DATE		Del_Date	As Sent
EPL_END_PLANNED_TIME		Time	As Sent
EPL_START_ACTUAL_DATE	The date the user actually chose to start the job. Format: YYYYMMDD		x
EPL_START_ACTUAL_TIME	The time the user actually chose to start the job. Format HHMMSSNN		x
EPL_ARRIVED_DATE_TIME	The date the user indicated they arrived at the destination. Format: YYYYMMDD		x
EPL_ARRIVED_DATE_TIME	The time the user indicated they arrived at the destination. Format HHMMSSNN		x
EPL_END_ACTUAL_DATE	The date the user completed or cancelled the job. Format: YYYYMMDD		x
EPL_END_ACTUAL_TIME	The time the user completed or cancelled the job. Format HHMMSSNN		x
EPL_DISTANCE_PLANNED			N/A
EPL_DISTANCE_ACTUAL			N/A
EPL_DRIVING_TIME			N/A
EPL_CUSTOMER_NAME	The Name of the customer	Del_Name	As Sent
EPL_JOB_ADDRESS	A flag indicating whether this is a default Customer Address or a specific address for this job alone.		N/A
EPL_ADDRESS_1		Del_addr1	As Sent
EPL_ADDRESS_2		Del_addr2	As Sent
EPL_ADDRESS_3		Del_addr3	As Sent
EPL_ADDRESS_4		Del_addr4	As Sent
EPL_ADDRESS_5			N/A
EPL_POSTCODE		Del_post	As Sent
EPL_CONTACT		Del_post	As Sent
EPL_TELEPHONE			As Sent
EPL_EMAIL			As Sent
EPL_INVOICED			N/A
EPL_CUST_SIGNATORY	The name of the customer signatory on the job.		x
EPL_JOB_CODE	External reference for the Job. This element can be used to link a collection and delivery together under the same reference. So, if an order is being collected at A and delivered at B, there are 2 jobs, each with a unique Job ID, but with the same Job Code. Optionally, EPOD will keep the Delivery leg of a linked job updated with the information captured from the collection.	Ref1	As Sent
EPL_CUST_REF	Customer's Order Reference	Ref2	As Sent
EPL_OFFICE_INSTRUCTION	Instructions for Admin staff	Notes3+Notes4	As Sent
EPL_SIGNED_UNCHECKED	An indication whether the customer signed for the goods without checking them first. Note that this field can be used for any check-box entry, as this is configurable.		x
EPL_SO_NUMBER	Sales Order Reference.	Ref3	As Sent
EPL_TNCS	An XML fragment, displaying the Terms and Conditions agreed to by the customer when signing for the goods. This can also include up to 3 configurable check-boxes that the user may check.		x
EPL_ORDER_DATE	Date Order created - defaulted to the date the order was received if not provided		N/A
EPL_SALES_CONTACT	The operative who took the order. Can be used as a display field for documentation		N/A
EPL_USER_NOTES	Optional Notes entered by the driver while completing the job.		x
EPL_OWNER_NAME		(owning) partner code	Need to set this as partner owning job.
EPL_SERVICE_LEVEL			N/A
EPL_TRAILER_ID	To be used if the vehicle being used to fulfil the job is a Tractor unit, and a trailer ID has been entered by the user.		x
EPL_EXT_REF	An external reference for the host system if required. For Partnerlink, this will be the PartnerJobID.	PartnerJobID	As Sent
EPL_LAST_CHANGED_DATE			N/A
EPL_LAST_CHANGED_TIME			N/A
EPOD_CONTAINERS	Contains a series of EPOD_CONTAINER objects, detailing all the deliverable items on this load. If there are loose products, there will also be a container with ID '000000000' holding these products.		A collection of pallets that were part of the job, plus the status.
EPOD_SERVICE	If the job is a Service, this object holds all the service-related information. In that case, no containers or products will be specified against the job.		N/A

EPOD_CONTAINER

Name	Description	External Field	Notes
EPL_JOB_ID	Unique reference for the job. If not provided on Import, this will be generated by EPOD
EPL_CONTAINER_ID	EPL_CONTAINER_ID: The unique identifier for a cotainer.	Label_ID	Actually from the tracking id (an id for each pallet to be delivered).
EPL_SEQUENCE	A sequence for the containers to be shown on the user's device.		As Sent
EPL_CONTAINER_PACKAGE_CODE		EF/EH/EQ/SF/SH/SQ	As Sent
EPL_CONTAINER_PACKAGE_DESC		EURO FULL, etc	As Sent
EPL_REASON_CODE	If a job has been cancelled, the reason code entered by the user is held here.		x
EPL_LINKED_REASON	If the job is a delivery, and a collection of this container on the same load with the same EPL_JOB_CODE is cancelled, this container will be cancelled, and this field will be set to "Y"		x
EPL_STATUS	EPL_STATUS: Status of the current Container. C-Completed, X-Cancelled.		x
EPL_PHOTO_ID	If cancelled, or received with a clause, a photo may have been taken by the user. If so, this field is populated with a unique ID.		x
EPL_PHOTO	The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file		x
EPL_CUST_COMMENTS	Optional entry by the user, indicating whether the customer has identified an issue with the received item (a claused receipt). If present, the customer may have requested an image, which would be contained in EPL_PHOTO.
EPL_DESCRIPTION_LONG			As Sent
EPL_CODE_1	Multi-purpose field	Spaces	As Sent
EPL_CODE_2	Multi-purpose field		As Sent
EPL_CODE_3	Multi-purpose field		As Sent
EPL_LAST_CHANGED_DATE			N/A
EPL_LAST_CHANGED_TIME			N/A
EPOD_PRODUCTS	Contains a series of EPOD_PRODUCTS objects, detailing the products within the container, or loose products		N/A

Note: Fields identified with an 'x' are expected to be stored within the Vigo system. Neither the Partnerlink nor OBS teams know which fields are in use within Vigo to store this data, but this must be stored by the application.

Note: Regarding Signature and Photo data formats in this message: This data is stored and transmitted as a text string, Base64-encrypted. This data can be decoded and saved as binary data once received if required.

A sample of a single job with a single pallet is shown below:

<EPOD_EXPORT_JOB>
  <EPOD_JOBS>
    <EPOD_JOB>
      <EPL_SITE_ID>L03</EPL_SITE_ID>
      <EPL_JOB_ID>0000000001</EPL_JOB_ID>
      <EPL_LOAD_ID>000000000002</EPL_LOAD_ID>
      <EPL_JOB_TYPE>D</EPL_JOB_TYPE>
      <EPL_JOB_GROUP>L03</EPL_JOB_GROUP>
      <EPL_JOB_INSTRUCTION>Very Fragile Parcel..Please handle with Care</EPL_JOB_INSTRUCTION>
      <EPL_JOB_SIGNATURE>R0lGODlh4AB4APcA...NKdJTY4EBAA7</EPL_JOB_SIGNATURE>
      <EPL_REASON_CODE></EPL_REASON_CODE>
      <EPL_LINKED_REASON>N</EPL_LINKED_REASON>
      <EPL_STATUS>C</EPL_STATUS>
      <EPL_CUSTOMER_CODE>OBS</EPL_CUSTOMER_CODE>
      <EPL_PHOTO_ID></EPL_PHOTO_ID>
      <EPL_ENG_SIGNATURE></EPL_ENG_SIGNATURE>
      <EPL_SEQUENCE>1</EPL_SEQUENCE>
      <EPL_START_PLANNED_DATE>20111108</EPL_START_PLANNED_DATE>
      <EPL_START_PLANNED_TIME>12000000</EPL_START_PLANNED_TIME>
      <EPL_END_PLANNED_DATE>0</EPL_END_PLANNED_DATE>
      <EPL_END_PLANNED_TIME>0</EPL_END_PLANNED_TIME>
      <EPL_START_ACTUAL_DATE>20111108</EPL_START_ACTUAL_DATE>
      <EPL_START_ACTUAL_TIME>10490000</EPL_START_ACTUAL_TIME>
      <EPL_END_ACTUAL_DATE>20111108</EPL_END_ACTUAL_DATE>
      <EPL_END_ACTUAL_TIME>10520000</EPL_END_ACTUAL_TIME>
      <EPL_DISTANCE_PLANNED>0</EPL_DISTANCE_PLANNED>
      <EPL_DISTANCE_ACTUAL>0</EPL_DISTANCE_ACTUAL>
      <EPL_DRIVING_TIME>0</EPL_DRIVING_TIME>
      <EPL_CUSTOMER_NAME>OBS Logistics</EPL_CUSTOMER_NAME>
      <EPL_JOB_ADDRESS>N</EPL_JOB_ADDRESS>
      <EPL_ADDRESS_1>Southern Gateway</EPL_ADDRESS_1>
      <EPL_ADDRESS_2>Speke Boulevard</EPL_ADDRESS_2>
      <EPL_ADDRESS_3>Liverpool</EPL_ADDRESS_3>
      <EPL_ADDRESS_4>Merseyside</EPL_ADDRESS_4>
      <EPL_ADDRESS_5></EPL_ADDRESS_5>
      <EPL_POSTCODE>L24 9HZ</EPL_POSTCODE>
      <EPL_CONTACT>Xavier Wai</EPL_CONTACT>
      <EPL_TELEPHONE>01514480331</EPL_TELEPHONE>
      <EPL_EMAIL>[email protected]</EPL_EMAIL>
      <EPL_INVOICED></EPL_INVOICED>
      <EPL_CUST_SIGNATORY></EPL_CUST_SIGNATORY>
      <EPL_JOB_CODE>L03</EPL_JOB_CODE>
      <EPL_CUST_REF></EPL_CUST_REF>
      <EPL_OFFICE_INSTRUCTION></EPL_OFFICE_INSTRUCTION>
      <EPL_SIGNED_UNCHECKED></EPL_SIGNED_UNCHECKED>
      <EPL_SO_NUMBER></EPL_SO_NUMBER>
      <EPL_TNCS></EPL_TNCS>
      <EPL_ORDER_DATE>0</EPL_ORDER_DATE>
      <EPL_SALES_CONTACT></EPL_SALES_CONTACT>
      <EPL_USER_NOTES></EPL_USER_NOTES>
      <EPL_OWNER_NAME></EPL_OWNER_NAME>
      <EPL_SERVICE_LEVEL></EPL_SERVICE_LEVEL>
      <EPL_TRAILER_ID></EPL_TRAILER_ID>
      <EPL_EXT_REF></EPL_EXT_REF>
      <EPL_LAST_CHANGED_DATE>20120314</EPL_LAST_CHANGED_DATE>
      <EPL_LAST_CHANGED_TIME>9420098</EPL_LAST_CHANGED_TIME>
      <EPOD_CONTAINERS>
        <EPOD_CONTAINER>
          <EPL_SITE_ID>L03</EPL_SITE_ID>
          <EPL_JOB_ID>0000000001</EPL_JOB_ID>
          <EPL_CONTAINER_ID>000000000000001</EPL_CONTAINER_ID>
          <EPL_SEQUENCE>0</EPL_SEQUENCE>
          <EPL_CONTAINER_PACKAGE_CODE>XX</EPL_CONTAINER_PACKAGE_CODE>
          <EPL_CONTAINER_PACKAGE_DESC>Pallet</EPL_CONTAINER_PACKAGE_DESC>
          <EPL_REASON_CODE></EPL_REASON_CODE>
          <EPL_LINKED_REASON></EPL_LINKED_REASON>
          <EPL_STATUS>C</EPL_STATUS>
          <EPL_PHOTO_ID></EPL_PHOTO_ID>
          <EPL_CUST_COMMENTS></EPL_CUST_COMMENTS>
          <EPL_GROSS_WEIGHT>120</EPL_GROSS_WEIGHT>
          <EPL_DESCRIPTION_LONG></EPL_DESCRIPTION_LONG>
          <EPL_CODE_1>1</EPL_CODE_1>
          <EPL_CODE_2></EPL_CODE_2>
          <EPL_CODE_3></EPL_CODE_3>
          <EPL_LAST_CHANGED_DATE>20120614</EPL_LAST_CHANGED_DATE>
          <EPL_LAST_CHANGED_TIME>16362322</EPL_LAST_CHANGED_TIME>
        </EPOD_CONTAINER>
      </EPOD_CONTAINERS>
      <EPOD_SERVICES></EPOD_SERVICES>
    </EPOD_JOB>
  </EPOD_JOBS>
</EPOD_EXPORT_JOB>

Note: The signature has been shortened for the purposes of this document.

CALIDUS EPOD Export Mechanism

The files can be:

Pulled by the Vigo TMS via FTP from an FTP service hosted by OBS.
Sent by CALIDUS ePOD via FTP to an FTP service hosted by Vigo.
Copied by CALIDUS ePOD to a shared folder on the Vigo TMS.
Copied by the Vigo TMS from a shared folder on the CALIDUS ePOD system.

Note: It is expected that this transfer will be via file transfer though a shared folder on the Vigo TMS.

Regardless of the mechanism chosen above, the final destination folder should contain only completed files in the agreed naming convention, not files being built. The files should be built and copied under a temporary naming convention, before renaming to csv file (i.e. .tmp files).

The files to be picked up will be named as follows:

<SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>__<SEQ>.xml

where

<SENDER> is the system sending the file - expected to be "epod"
<RECEIVER> is the system receiving the file - expected to be "vigo"
<OPERATING_PARTNER> is the operating partner code, i.e. L02, L03, etc.
<DATE> is the date in YYYYMMDD format
is the time in HHMMSSNN format
<SEQ> is a unique counting sequence for each file created in a run.

No responses to the files shall be given - the receiving system (Vigo TMS in this case) will maintain an audit trail to be examined by the user on event of failure.

Each job will be sent in a separate file, to minimise disruption if a single file fails.

Appendix A: Document References

A.1 References

Ref No	Document Title & ID	Version	Date
1	JobShare Mapping v0.2.xlsx	0.2	18/02/2013
2	EPOD Export Mapping v0.5.xlsx	0.5	20/02/2013
3	EPOD XSD.zip	N/A	25/01/2013

A.2 Glossary

Term	Definition
EPOD	Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD.
CALIDUS eSERV	The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system.
PDA	The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android.
DAL	Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it.
GPS	Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device.
GPRS, 3G, HSDPA, Data Service	All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet.

A.3 Authorised By

Andrew Allison

Client Representative

_____________________________

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' EPOD}}
 {{#vardefine:Doc_Title|EPOD Vigo Interface}}
-{{#vardefine:Version|0.3}}
+{{#vardefine:Version|0.4}}
-{{#vardefine:Date|18th February 2013}}
+{{#vardefine:Date|20th February 2013}}
 {{#vardefine:Reference|305796}}
 {{#vardefine:Year|2013}}
@@ Line 39: / Line 39: @@
 * Sending of data to ''CALIDUS'' ePOD will be through a new Partnerlink CSV format.
 * Receiving data from ''CALIDUS'' ePOD will be through the OBS XML format.
-* The mechanism of sending and receiving data will be through Flat File transfer via FTP.
+* The mechanism of sending and receiving data will be through Flat File transfer via a shared folder on the Vigo system
 * The sending of data to ''CALIDUS'' ePOD will be through a manual option within the Vigo system ("Send to ePOD").
 * The Vigo system must merge of Delivery and Collection manifests into a single Consolidated Manifest when sending data.
@@ Line 66: / Line 66: @@
 * Customers
-A number of actions are outstanding from this meeting regarding the production of this interface specification, as follows:
+{{Note}} A number of actions are outstanding from this meeting regarding the production of this interface specification, as follows:
 * Partnerlink to provide a list of existing Partner Codes in use.
 * Partnerlink to provide a document of the standard Reason Codes in use.
 * Partnerlink to update the spreadsheets (provided to map the import to and Export from ePOD) to indicate Vigo Table and Field Names, for inclusion in this document.
 Until these actions are completed, the document will remain in draft form, unless authorised by the customer.
 <!-- NEW PAGE -->
 = Set-up  =
@@ Line 76: / Line 77: @@
 == Pre-requisites  ==
 * A working Vigo TMS and ''CALIDUS'' EPOD system must be in place.
-* The two systems must be able to connect via FTP, either through an internet or LAN connection.
+* The two systems must be able to connect via a shared folder, either through an internet or LAN connection. This must be accessible directly, without user and password information, through a shared user-name on the two servers or domain. This will be co-ordinated and configured by the Partnerlink IT team.
 == Menu Structure  ==
@@ Line 116: / Line 117: @@
 <tr><td>3</td><td>Reference 2</td><td>C</td><td>16</td><td>Ref2</td><td>&nbsp;</td></tr>
 <tr><td>4</td><td>Reference 3</td><td>C</td><td>16</td><td>Ref3</td><td>&nbsp;</td></tr>
-<tr><td>5</td><td>PartnerJobID</td><td>C</td><td>14</td><td>tracking_code</td><td>Is used to form the pallet ID of the pallets to be delivered (this field plus 2-digit count from 01 to Total Pallets)</td></tr>
+<tr><td>5</td><td>PartnerJobID</td><td>C</td><td>14</td><td>tracking_code</td><td>Is used to form the pallet ID of the pallets to be delivered (this field plus 2-digit count from 01 to Total Pallets). Stored in new reference field.</td></tr>
 <tr><td>6</td><td>Job Date</td><td>C</td><td>8</td><td>&nbsp;</td><td>&nbsp;</td></tr>
 <tr><td>7</td><td>Collection Name</td><td>C</td><td>30</td><td>col_name</td><td>Collection details - required for POD note (Consignor address)</td></tr>
@@ Line 188: / Line 189: @@
 == Sending Mechanism ==
-The files can be
+The files can be :
-* Sent by the Vigo TMS via FTP to an FTP service hosted by OBS
+* Sent by the Vigo TMS via FTP to an FTP service hosted by OBS.
-* Pulled by ''CALIDUS'' ePOD via FTP from an FTP service hosted by Vigo
+* Pulled by ''CALIDUS'' ePOD via FTP from an FTP service hosted by Vigo.
-* Copied by ''CALIDUS'' ePOD from a shared folder on the Vigo TMS
+* Copied by ''CALIDUS'' ePOD from a shared folder on the Vigo TMS.
-* Copied by ''CALIDUS'' ePOD from a shared folder on the ''CALIDUS'' ePOD system.
+* Copied by Vigo to a shared folder on ''CALIDUS'' ePOD.
+{{note}} It is expected that this transfer will be via file transfer though a shared folder on the Vigo TMS.
 Regardless of the mechanism chosen above, the final destination folder should contain only completed files in the agreed naming convention, not files being built. The files should be built and copied under a temporary naming convention, before renaming to csv file (i.e. .tmp files).
@@ Line 230: / Line 232: @@
 * Entered Trailer ID (at Job level).
 * Clause information (per pallet)
+* External Reference ID (at Job level, containing the PartnerJobID.
 {{Note}} Trailer ID and Clause modifications are out of scope of the existing solution being provided, but have been added here so that the systems can be prepared to handle this functionality when it becomes available.
@@ Line 292: / Line 294: @@
 <tr><td>EPL_SERVICE_LEVEL</td><td>&nbsp;</td><td>&nbsp;</td><td>N/A</td></tr>
 <tr><td>EPL_TRAILER_ID</td><td>To be used if the vehicle being used to fulfil the job is a Tractor unit, and a trailer ID has been entered by the user.</td><td>&nbsp;</td><td>x</td></tr>
+<tr><td>EPL_EXT_REF</td><td>An external reference for the host system if required. For Partnerlink, this will be the PartnerJobID.</td><td>PartnerJobID</td><td>As Sent</td></tr>
 <tr><td>EPL_LAST_CHANGED_DATE</td><td>&nbsp;</td><td>&nbsp;</td><td>N/A</td></tr>
 <tr><td>EPL_LAST_CHANGED_TIME</td><td>&nbsp;</td><td>&nbsp;</td><td>N/A</td></tr>
@@ Line 381: / Line 384: @@
        <EPL_SERVICE_LEVEL></EPL_SERVICE_LEVEL>
        <EPL_TRAILER_ID></EPL_TRAILER_ID>
+      <EPL_EXT_REF></EPL_EXT_REF>
        <EPL_LAST_CHANGED_DATE>20120314</EPL_LAST_CHANGED_DATE>
        <EPL_LAST_CHANGED_TIME>9420098</EPL_LAST_CHANGED_TIME>
@@ Line 413: / Line 417: @@
 == ''CALIDUS'' EPOD Export Mechanism ==
-The files can be
+The files can be:
-*    Sent by the Vigo TMS via FTP to an FTP service hosted by OBS
+*    Pulled by the Vigo TMS via FTP from an FTP service hosted by OBS.
-*    Pulled by ''CALIDUS'' ePOD via FTP from an FTP service hosted by Vigo
+*    Sent by ''CALIDUS'' ePOD via FTP to an FTP service hosted by Vigo.
-*    Copied by ''CALIDUS'' ePOD from a shared folder on the Vigo TMS
+*    Copied by ''CALIDUS'' ePOD to a shared folder on the Vigo TMS.
-*    Copied by ''CALIDUS'' ePOD from a shared folder on the ''CALIDUS'' ePOD system.
+*    Copied by the Vigo TMS from a shared folder on the ''CALIDUS'' ePOD system.
+{{note}} It is expected that this transfer will be via file transfer though a shared folder on the Vigo TMS.
 Regardless of the mechanism chosen above, the final destination folder should contain only completed files in the agreed naming convention, not files being built. The files should be built and copied under a temporary naming convention, before renaming to csv file (i.e. .tmp files).
 The files to be picked up will be named as follows:
+*    <SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>_<TIME>_<SEQ>.xml
-*    <SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>_<TIME>_<SEQ>.csv
 where
 *    <SENDER> is the system sending the file - expected to be "epod"
 *    <RECEIVER> is the system receiving the file - expected to be "vigo"
@@ Line 447: / Line 449: @@
 |Ref2=EPOD Export Mapping v0.5.xlsx
 |RefV2=0.5
-|RefDate2=25/01/2013
+|RefDate2=20/02/2013
 |Ref3=EPOD XSD.zip
 |RefV3=N/A

Anonymous

Search

FS 305796 EPOD Vigo Interface: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 13:28, 20 March 2013

Contents

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Vigo Export

Creating the Messages

Message Content

Sending Mechanism

Importing into CALIDUS EPOD

CALIDUS EPOD Export Process

CALIDUS EPOD Export Message Content

CALIDUS EPOD Export Mechanism

Appendix A: Document References

Navigation

Navigation

Translate

Wiki tools

Wiki tools

Anonymous

Search

FS 305796 EPOD Vigo Interface: Difference between revisions

Latest revision as of 13:28, 20 March 2013

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Vigo Export

Creating the Messages

Message Content

Sending Mechanism

Importing into CALIDUS EPOD

CALIDUS EPOD Export Process

CALIDUS EPOD Export Message Content

CALIDUS EPOD Export Mechanism

Appendix A: Document References

Navigation

Wiki tools

Page tools

Categories