FS 304310 EPOD-TTM Interface - Revision history

Anw: Slight change to format of OIT message

2013-02-15T16:15:56Z

Slight change to format of OIT message

← Older revision		Revision as of 18:15, 15 February 2013
Line 115:		Line 115:
	* RES		* RES
	* ORD		* ORD
			* ARR
	* DEL/CAN		* DEL/CAN
	* OIT		* 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.		{{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 control whether an ETA needs to be calculated for the subsequent stop.


	Database packages will be added to seach for Loads, Jobs and Audit records where:		Database packages will be added to seach for Loads, Jobs and Audit records where:
Line 233:		Line 233:

	The message will be sent by finding all EPL_MESSAGE_TYPE of "LOAD_RESEQUENCE" on EPOD_USER_AUDIT where the interface flag = "N".		The message will be sent by finding all EPL_MESSAGE_TYPE of "LOAD_RESEQUENCE" on EPOD_USER_AUDIT where the interface flag = "N".

			{{note}} At this time, full resequencing is NOT supported, so this development is not required.

	{{warning}} '''EITHER'''		{{warning}} '''EITHER'''
Line 432:		Line 434:
	</OBS_XML>		</OBS_XML>

	CAN message format:		CAN message format: Same as DEL message

	~~{{warning}} No format provided for this~~ message

	The STOPS and ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(strMsgType). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section. The parameter will control whether the XML extract will create Stop-level information (required for the TRP, DEL and CAN messages). If the Job is at status C or X (Cancelled or completed) and the message type is DEL or CAN, this will also generate an DELIVERED tag in the ORDER_DETAIL section, showing the Actual Delivered Qty of the container (1) or the Loose product (EPL_PRODUCT_QTY_ACTUAL)		The STOPS and ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(strMsgType). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section. The parameter will control whether the XML extract will create Stop-level information (required for the TRP, DEL and CAN messages). If the Job is at status C or X (Cancelled or completed) and the message type is DEL or CAN, this will also generate an DELIVERED tag in the ORDER_DETAIL section, showing the Actual Delivered Qty of the container (1) or the Loose product (EPL_PRODUCT_QTY_ACTUAL)
Line 440:		Line 440:
	=== Type OIT ===		=== Type OIT ===
	This message will be used for the following:		This message will be used for the following:
	* ~~Order~~ In ~~Progress~~ - Message type OIT, including GPS information (based on existing ALC message)		* Operation In Transit - 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".		The message will be sent by finding all EPL_MESSAGE_TYPE of "JOB_LOCK_REQUEST" on EPOD_USER_AUDIT where the interface flag = "N".
Line 470:		Line 470:
	<TRIP_HEADER>		<TRIP_HEADER>
	<TRIP_IDENTIFIER>T</TRIP_IDENTIFIER>		<TRIP_IDENTIFIER>T</TRIP_IDENTIFIER>
	<TRIP_TRANSACTION_DATE>2012-12-20T01:37:55</TRIP_TRANSACTION_DATE>		<TRIP_TRANSACTION_DATE>2012-12-20T01:37:55</TRIP_TRANSACTION_DATE> - Date/Time from audit record
	<TRIP_ID>EPL_LOAD_ID</TRIP_ID>		<TRIP_ID>EPL_LOAD_ID</TRIP_ID>
	</TRIP_HEADER>		</TRIP_HEADER>
Line 488:		Line 488:
	<STOP_DETAIL>		<STOP_DETAIL>
	<STOP_LOCATION_ID>EPL_CUSTOMER_ID</STOP_LOCATION_ID>		<STOP_LOCATION_ID>EPL_CUSTOMER_ID</STOP_LOCATION_ID>
	~~<STOP_ACTUAL_ARRIVAL_DATE>2012-12-20T00:53:28</STOP_ACTUAL_ARRIVAL_DATE>~~
	</STOP_DETAIL>		</STOP_DETAIL>
	<ORDERS>		<ORDERS>
Line 502:		Line 501:
	<ORDER>		<ORDER>
	<ORDER_HEADER>		<ORDER_HEADER>
	<ORDER_TRANSACTION_DATE>2012-12-20T00:00:00</ORDER_TRANSACTION_DATE> - Date ~~job created~~		<ORDER_TRANSACTION_DATE>2012-12-20T00:00:00</ORDER_TRANSACTION_DATE> - Date/Time from audit record
	<WMS_WAREHOUSE>EPL_SITE_REF</WMS_WAREHOUSE>		<WMS_WAREHOUSE>EPL_SITE_REF</WMS_WAREHOUSE>
	<WMS_OWNER>EPL_JOB_GROUP_REF</WMS_OWNER>		<WMS_OWNER>EPL_JOB_GROUP_REF</WMS_OWNER>
Line 508:		Line 507:
	<TMS_REF>EPL_JOB_ID</TMS_REF>		<TMS_REF>EPL_JOB_ID</TMS_REF>
	<PO_REF>EPL_CUST_REF</PO_REF>		<PO_REF>EPL_CUST_REF</PO_REF>
	~~<BOOK_DATE>2012-12-24T10:00:00</BOOK_DATE> - Planned Start Date/Time~~
	</ORDER_HEADER>		</ORDER_HEADER>
	</ORDER>		</ORDER>

Anw: v0.4 - Added details of OIT and ARR messages

2013-02-15T14:59:09Z

v0.4 - Added details of OIT and ARR messages

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' EPOD}}
 {{#vardefine:Doc_Title|EPOD-TTM Interface}}
-{{#vardefine:Version|0.3}}
+{{#vardefine:Version|0.4}}
-{{#vardefine:Date|21st December 2012}}
+{{#vardefine:Date|15th February 2013}}
 {{#vardefine:Reference|304310}}
-{{#vardefine:Year|2012}}
+{{#vardefine:Year|2013}}
 </div>
 {{Doc_Title
@@ Line 456: / Line 456: @@
 OIT message format:
-{{warning}} No format provided for this message
+{{note}} Order listed here is just the Order Header, minus the address information, as follows:
 <!-- MEDIA LANDSCAPE YES -->

Anw at 15:24, 31 December 2012

2012-12-31T15:24:15Z

← Older revision		Revision as of 17:24, 31 December 2012
Line 78:		Line 78:
	* Import of Jobs should set the Order Date to NOW(), if the Order Date has not been provided.		* Import of Jobs should set the Order Date to NOW(), if the Order Date has not been provided.
	* Import of Jobs should set the Ordered Qty to Planned Qty, if the Ordered Qty has not been provided.		* Import of Jobs should set the Ordered Qty to Planned Qty, if the Ordered Qty has not been provided.
			* A new Interface Flag must be added to copy with the exports both to TTM and through the standard Job/Load interface. This should be updated instead of the normal interface flag when sending DEL or CAN records.

	For Partnerlink:		For Partnerlink:

Anw: Feedback regarding TRP message added.

2012-12-24T09:17:43Z

Feedback regarding TRP message added.

← Older revision		Revision as of 11:17, 24 December 2012
Line 179:		Line 179:
	<DRIVER>EPL_USER_ID</DRIVER>		<DRIVER>EPL_USER_ID</DRIVER>
	<DRIVER_NAME>EPL_USER_NAME</DRIVER_NAME>		<DRIVER_NAME>EPL_USER_NAME</DRIVER_NAME>
	<TRACTOR>~~EPL_VEHICLE_ID~~</TRACTOR>		<TRACTOR>EPL_VEHICLE_REG</TRACTOR>
	<COST_CENTRE>EXEL</COST_CENTRE>		<COST_CENTRE>EXEL</COST_CENTRE>
	<TRIP_STATUS>~~PLANNED~~</TRIP_STATUS>		<TRIP_STATUS>EN-ROUTE</TRIP_STATUS>
	<TRIP_REF>M2480031</TRIP_REF>		<TRIP_REF>M2480031</TRIP_REF>
	<TRIP_TRAILER_ID>EPL_VEHICLE_ID</TRIP_TRAILER_ID>		<TRIP_TRAILER_ID>EPL_VEHICLE_ID</TRIP_TRAILER_ID>
Line 191:		Line 191:
	<STOP_HEADER>		<STOP_HEADER>
	<STOP_IDENTIFIER>S</STOP_IDENTIFIER>		<STOP_IDENTIFIER>S</STOP_IDENTIFIER>
	<STOP_SEQ>1</STOP_SEQ>		<STOP_SEQ>1</STOP_SEQ> - Counts sequentially for each stop on the trip
	</STOP_HEADER>		</STOP_HEADER>
	<STOP_DETAIL>		<STOP_DETAIL>
Line 225:		Line 225:
	The STOPS and ORDERS sections will be generated from the EPOD_JOB DAL object, from a new method ToTTMXElement(strMsgType) (defined in a later section). The parameter to control whether the XML extract will create Stop-level information will be set to the message type TRP.		The STOPS and ORDERS sections will be generated from the EPOD_JOB DAL object, from a new method ToTTMXElement(strMsgType) (defined in a later section). The parameter to control whether the XML extract will create Stop-level information will be set to the message type TRP.

	{{note}} the ORDERS section may be fully-populated or only contain the ORDER_HEADER section without any lower-level collection tags e.g. ORDER_HEADER_ADDRESSES, ORDER_DETAILS. This detailed information will only be generated if the EPL_XFER_FLAG against the job is blank. At any other value, only Header information will be built, as we have already informed TTM of the order's existence.		{{note}} the ORDERS section may be fully-populated or only contain the ORDER_HEADER section without any lower-level collection tags e.g. ORDER_HEADER_ADDRESSES, ORDER_DETAILS. This detailed information will only be generated if the EPL_XFER_FLAG against the job is blank. At any other value, only Header information will be built, as we have already informed TTM of the order's existence (i.e. on an initial TRP message).

	=== Type RES ===		=== Type RES ===

Anw: v0.3 - Draft version awaiting further input from TTM team

2012-12-21T16:03:18Z

v0.3 - Draft version awaiting further input from TTM team

← Older revision		Revision as of 18:03, 21 December 2012
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' EPOD}}		{{#vardefine:System\|''CALIDUS'' EPOD}}
	{{#vardefine:Doc_Title\|EPOD-TTM Interface}}		{{#vardefine:Doc_Title\|EPOD-TTM Interface}}
	{{#vardefine:Version\|0.2}}		{{#vardefine:Version\|0.3}}
	{{#vardefine:Date\|21st December 2012}}		{{#vardefine:Date\|21st December 2012}}
	{{#vardefine:Reference\|304310}}		{{#vardefine:Reference\|304310}}

Anw: Added details of DEL message; highlighted message formats that have not been provided by the TTM team.

2012-12-21T16:02:39Z

Added details of DEL message; highlighted message formats that have not been provided by the TTM team.

@@ Line 5: / Line 5: @@
 {{#vardefine:Doc_Title|EPOD-TTM Interface}}
 {{#vardefine:Version|0.2}}
-{{#vardefine:Date|20th December 2012}}
+{{#vardefine:Date|21st December 2012}}
 {{#vardefine:Reference|304310}}
 {{#vardefine:Year|2012}}
@@ Line 23: / Line 23: @@
 = Functional Overview  =
-== Client Requirement  ==
+== 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.
@@ Line 65: / Line 65: @@
 <!-- NEW PAGE -->
-= Functional Description  =
+= Functional Description =
 == EPOD Changes ==
@@ Line 223: / Line 223: @@
 The method will also retrieve the jobs for the load into an EPOD_JOBS collection, with all heirarchical detail (CONTAINERS and PRODUCTS).
-The STOPS and ORDERS sections will be generated from the EPOD_JOB DAL object, from a new method ToTTMXElement(blnStops) (defined in a later section). The parameter to control whether the XML extract will create Stop-level information (blnStops) will be set to true.
+The STOPS and ORDERS sections will be generated from the EPOD_JOB DAL object, from a new method ToTTMXElement(strMsgType) (defined in a later section). The parameter to control whether the XML extract will create Stop-level information will be set to the message type TRP.
 {{note}} the ORDERS section may be fully-populated or only contain the ORDER_HEADER section without any lower-level collection tags e.g. ORDER_HEADER_ADDRESSES, ORDER_DETAILS. This detailed information will only be generated if the EPL_XFER_FLAG against the job is blank. At any other value, only Header information will be built, as we have already informed TTM of the order's existence.
@@ Line 246: / Line 246: @@
 ** Rename temporary file to destination directory and filename
 ** Commit transaction
 === Type ORD ===
@@ Line 337: / Line 341: @@
   </OBS_XML>
-The ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(blnStops). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section. The parameter will control whether the XMl extract will create Stop-level information (required for the TRP message).
+The ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(strMsgType). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section. The parameter will control whether the XML extract will create Stop-level information (required for the TRP message).
 === Type DEL/CAN ===
@@ Line 364: / Line 368: @@
 {{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 ===
@@ Line 381: / Line 453: @@
 ** Rename temporary file to destination directory and filename
 ** Commit transaction
 <!-- MEDIA LANDSCAPE YES -->

Anw at 12:34, 21 December 2012

2012-12-21T12:34:40Z

← Older revision		Revision as of 14:34, 21 December 2012
Line 97:		Line 97:
	** <SourceID> - Identifying source ID of the payload - always EPL_SITE_ID		** <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"		** <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.		** <UniqueID> - a unique ID for the file. Always made up of Date/Time stamp in format DDMMYYHHNNSSMM, plus an incremental of the number of files created in the AutoExport run (to ensure uniqueness).
	* initially created as .TMP files, then renamed to .XML when complete		* initially created as .TMP files, then renamed to .XML when complete

Anw: Added TRP message details.

2012-12-21T12:32:09Z

Added TRP message details.

@@ Line 108: / Line 108: @@
 * 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.
+The auto-export program will be modified to add processing of "TTM-IF" configurations, after the standard message type checks. The program will call a new procedure here.
-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).
+The procedure will check for messages in this order:
 * TRP
 * RES
@@ Line 123: / Line 118: @@
 {{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 ===
@@ Line 148: / Line 156: @@
 {{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 ===
@@ Line 259: / Line 337: @@
   </OBS_XML>
-The ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section.
+The ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(blnStops). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section. The parameter will control whether the XMl extract will create Stop-level information (required for the TRP message).
 === Type DEL/CAN ===

Anw: Added details on how to generate the ORD XML

2012-12-21T11:00:58Z

Added details on how to generate the ORD XML

← Older revision		Revision as of 13:00, 21 December 2012
Line 203:		Line 203:
	<EVENT_ACTION>R</EVENT_ACTION>		<EVENT_ACTION>R</EVENT_ACTION>
	</EVENT_HEADER>		</EVENT_HEADER>
	<EVENT_DETAIL>		<EVENT_DETAIL> - This section will be hard-coded within the ORD message...
	<TRIP_HEADER>		<TRIP_HEADER>
	<TRIP_IDENTIFIER>O</TRIP_IDENTIFIER>		<TRIP_IDENTIFIER>O</TRIP_IDENTIFIER>
Line 212:		Line 212:
	<STOP_IDENTIFIER>O</STOP_IDENTIFIER>		<STOP_IDENTIFIER>O</STOP_IDENTIFIER>
	<STOP_SEQ>0</STOP_SEQ>		<STOP_SEQ>0</STOP_SEQ>
	</STOP_HEADER>		</STOP_HEADER> - ... up to here
	<ORDERS>		<ORDERS>
	<ORDER>		<ORDER>
Line 258:		Line 258:
	</EVENT>		</EVENT>
	</OBS_XML>		</OBS_XML>

			The ORDERS section will be generated from the EPOD_JOB DAL object, from a new method, ToTTMXElement(). This will be added to EPOD_CONTAINER and EPOD_PRODUCT as well, to generate the ORDER_DETAIL section.

	=== Type DEL/CAN ===		=== Type DEL/CAN ===

Anw: Added ORD message details; added some more generic EPOD changes

2012-12-21T10:57:08Z

Added ORD message details; added some more generic EPOD changes

@@ Line 75: / Line 75: @@
 * 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:
@@ Line 187: / Line 190: @@
 {{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 ===