292349 - Revision history

Admin: /* EDI Maintenance */

2012-05-11T14:40:53Z

EDI Maintenance

← Older revision		Revision as of 16:40, 11 May 2012
Line 61:		Line 61:
	For example:		For example:

	[[Image:]]		[[Image:292349_1.png]]

	The ‘Params’ screen will be used to set a new trigger called ‘Send Handshake Message’ to a value of ‘Y’ for a type of ‘P’ to send the ‘handshake’ message to PLUTO upon successful upload of the inbound file:		The ‘Params’ screen will be used to set a new trigger called ‘Send Handshake Message’ to a value of ‘Y’ for a type of ‘P’ to send the ‘handshake’ message to PLUTO upon successful upload of the inbound file:

	[[Image:]]		[[Image:292349_2.png]]

	The ‘FTP Details’ screen will be used to store the FTP details for the ‘handshake’ message:		The ‘FTP Details’ screen will be used to store the FTP details for the ‘handshake’ message:

	[[Image:]]		[[Image:292349_3.png]]

	A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the outbound XML file from C-TMS to PLUTO via DHL Link using the ‘TripOrder’ XML format.		A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the outbound XML file from C-TMS to PLUTO via DHL Link using the ‘TripOrder’ XML format.
Line 77:		Line 77:
	For example:		For example:

	[[Image:]]		[[Image:292349_4.png]]

	The ‘Params’ screen will be used to set a new parameter called ‘PRINT_ORD_SECTION’ to a value of ‘N’ for a type of ‘P’ to exclude the order sections from the ‘TripOrder’ XML file.		The ‘Params’ screen will be used to set a new parameter called ‘PRINT_ORD_SECTION’ to a value of ‘N’ for a type of ‘P’ to exclude the order sections from the ‘TripOrder’ XML file.

Admin at 14:37, 11 May 2012

2012-05-11T14:37:27Z

@@ Line 1: / Line 1: @@
-[[Image:]]
+{{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Pluto C-TMS Integration|Reference=FS 292349 PM-8LZMAN|Version=2.0|Date=4/11/2011|Sysver=10.7|Client=DHL C-TMS}}
 == Client Requirement ==
 PLUTO - C-TMS Integration.

Admin: /* Client Requirement */

2012-05-11T14:35:41Z

Client Requirement

← Older revision		Revision as of 16:35, 11 May 2012
Line 47:		Line 47:
	== Client Requirement ==		== Client Requirement ==
	PLUTO - C-TMS Integration.		PLUTO - C-TMS Integration.


	Receive and upload XML files representing vehicle movement by driver shift planned in PLUTO. Send 1 trip in each file.		Receive and upload XML files representing vehicle movement by driver shift planned in PLUTO. Send 1 trip in each file.


	Handshake confirmation of data successfully uploaded into C-TMS back to PLUTO.		Handshake confirmation of data successfully uploaded into C-TMS back to PLUTO.


	C-TMS creation of actual arrivals and actual departures message to PLUTO based on same Trip and Order schema.		C-TMS creation of actual arrivals and actual departures message to PLUTO based on same Trip and Order schema.


	Store PLUTO stop number in C-TMS.		Store PLUTO stop number in C-TMS.


	== Solution ==		== Solution ==

Admin: /* Solution */

2012-05-11T14:35:20Z

Solution

Admin: /* EDI Maintenance */

2012-05-11T14:34:33Z

EDI Maintenance

← Older revision		Revision as of 16:34, 11 May 2012
Line 118:		Line 118:
	== EDI Maintenance ==		== EDI Maintenance ==
	A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the inbound XML file from PLUTO via DHL Link into C-TMS using the ‘TripOrder’ XML format.		A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the inbound XML file from PLUTO via DHL Link into C-TMS using the ‘TripOrder’ XML format.


	For example:		For example:


	[[Image:]]		[[Image:]]


	The ‘Params’ screen will be used to set a new trigger called ‘Send Handshake Message’ to a value of ‘Y’ for a type of ‘P’ to send the ‘handshake’ message to PLUTO upon successful upload of the inbound file:		The ‘Params’ screen will be used to set a new trigger called ‘Send Handshake Message’ to a value of ‘Y’ for a type of ‘P’ to send the ‘handshake’ message to PLUTO upon successful upload of the inbound file:


	[[Image:]]		[[Image:]]


	The ‘FTP Details’ screen will be used to store the FTP details for the ‘handshake’ message:		The ‘FTP Details’ screen will be used to store the FTP details for the ‘handshake’ message:


	[[Image:]]		[[Image:]]


	A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the outbound XML file from C-TMS to PLUTO via DHL Link using the ‘TripOrder’ XML format.		A new EDI process will be setup in the ‘EDI Maintenance’ screen to process the outbound XML file from C-TMS to PLUTO via DHL Link using the ‘TripOrder’ XML format.


	A ‘stop departure’ message will be required to be sent to PLUTO.		A ‘stop departure’ message will be required to be sent to PLUTO.


	For example:		For example:


	[[Image:]]		[[Image:]]


	The ‘Params’ screen will be used to set a new parameter called ‘PRINT_ORD_SECTION’ to a value of ‘N’ for a type of ‘P’ to exclude the order sections from the ‘TripOrder’ XML file.		The ‘Params’ screen will be used to set a new parameter called ‘PRINT_ORD_SECTION’ to a value of ‘N’ for a type of ‘P’ to exclude the order sections from the ‘TripOrder’ XML file.


	== PLUTO to C-TMS Processing ==		== PLUTO to C-TMS Processing ==

Admin: /* Trip and Order Validation */

2012-05-11T14:34:06Z

Trip and Order Validation

← Older revision		Revision as of 16:34, 11 May 2012
Line 156:		Line 156:
	=== Trip and Order Validation ===		=== Trip and Order Validation ===
	A unique identifier will be passed in for each order as the customer reference. This identifier will be unique and will define the purchase order number, purchase order number line, purchase order line number split and leg number. For each trip, PLUTO will provide a route code which defines the vehicle movement in the plan for the shift, for example ‘BEL DD3-1’ means ‘Bellshill Double Deck 3 for shift 1’. PLUTO plans based on vehicle movements for notional vehicles available from the fleet.		A unique identifier will be passed in for each order as the customer reference. This identifier will be unique and will define the purchase order number, purchase order number line, purchase order line number split and leg number. For each trip, PLUTO will provide a route code which defines the vehicle movement in the plan for the shift, for example ‘BEL DD3-1’ means ‘Bellshill Double Deck 3 for shift 1’. PLUTO plans based on vehicle movements for notional vehicles available from the fleet.


	It is expected that all required information to create both orders and trips will be provided in the message. The existing validation process will be performed and any messages that do not contain the necessary information will be rejected. If the orders or trips are invalid they will be rolled back and a new file will need to be sent to create the orders and trips.		It is expected that all required information to create both orders and trips will be provided in the message. The existing validation process will be performed and any messages that do not contain the necessary information will be rejected. If the orders or trips are invalid they will be rolled back and a new file will need to be sent to create the orders and trips.


	Specific validation on the trip and order file will include the following checks for the upload:		Specific validation on the trip and order file will include the following checks for the upload:


	File Level:		File Level:


	* <nowiki>The ‘<EVENT_SOURCE_TYPE>’ tag is ‘PLUT’.</nowiki>		* <nowiki>The ‘<EVENT_SOURCE_TYPE>’ tag is ‘PLUT’.</nowiki>
Line 172:		Line 168:

	Trip Level:		Trip Level:


	* <nowiki>The ‘<ROUTE_CODE>’ tag is populated.</nowiki>		* <nowiki>The ‘<ROUTE_CODE>’ tag is populated.</nowiki>
Line 178:		Line 173:

	Trip Stop Level:		Trip Stop Level:


	* <nowiki>The ‘<STOP_SEQ>’ tag is populated with the stop number.</nowiki>		* <nowiki>The ‘<STOP_SEQ>’ tag is populated with the stop number.</nowiki>
Line 184:		Line 178:

	Order Level:		Order Level:


	* <nowiki>The ‘<SO_REF>’ tag is populated (i.e. external reference).</nowiki>		* <nowiki>The ‘<SO_REF>’ tag is populated (i.e. external reference).</nowiki>
Line 190:		Line 183:

	The external reference will store the PLUTO order reference in the following format:		The external reference will store the PLUTO order reference in the following format:


	* Order (i.e. Purchase Order Number)		* Order (i.e. Purchase Order Number)
Line 198:		Line 190:

	For example: ‘99999999.0001.01.01’		For example: ‘99999999.0001.01.01’


	<nowiki>The ‘INT_XML_IN’ package will be changed so that the PLUTO trip and order upload process is identified using the ‘<EVENT_SOURCE_TYPE>’ tag (i.e. ‘PLUT’) and a new procedure called ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ is run from the existing ‘PROCESS_ORD_XML_IN’ procedure called by the EDI polling process, this new procedure will be performed after the successful validation of the information provided in the file at the file level. The ‘PROCESS_ORD_XML_IN’ procedure will be changed to check the event source type and if it is ‘PLUT’ then it will pass control to a new procedure called ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ to extract the data from the file.</nowiki>		<nowiki>The ‘INT_XML_IN’ package will be changed so that the PLUTO trip and order upload process is identified using the ‘<EVENT_SOURCE_TYPE>’ tag (i.e. ‘PLUT’) and a new procedure called ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ is run from the existing ‘PROCESS_ORD_XML_IN’ procedure called by the EDI polling process, this new procedure will be performed after the successful validation of the information provided in the file at the file level. The ‘PROCESS_ORD_XML_IN’ procedure will be changed to check the event source type and if it is ‘PLUT’ then it will pass control to a new procedure called ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ to extract the data from the file.</nowiki>


	Modifications of trip stops will only be permitted until the actual arrival or actual departure date and time is entered against a loading trip stop of a leg. This will be normally from an update message from Microlise, but manual intervention during trip debrief will be possible. Once this has happened, the trip stops and orders on those stops will be locked from any changes via the PLUTO interface.		Modifications of trip stops will only be permitted until the actual arrival or actual departure date and time is entered against a loading trip stop of a leg. This will be normally from an update message from Microlise, but manual intervention during trip debrief will be possible. Once this has happened, the trip stops and orders on those stops will be locked from any changes via the PLUTO interface.


	Microlise will send update messages for actions ‘STA’ (i.e. start-up) and ‘DEP’ (i.e. departure) and it will be these messages that will ‘lock’ the legs of the trip to prevent further modification for planning because they relate to the trip stops where loading activities will occur.		Microlise will send update messages for actions ‘STA’ (i.e. start-up) and ‘DEP’ (i.e. departure) and it will be these messages that will ‘lock’ the legs of the trip to prevent further modification for planning because they relate to the trip stops where loading activities will occur.


	If the actual arrival or actual departure date and time has been entered against a trip stop then the leg of the trip will be ‘locked’ and the trip stop cannot be updated or replaced by the upload process.		If the actual arrival or actual departure date and time has been entered against a trip stop then the leg of the trip will be ‘locked’ and the trip stop cannot be updated or replaced by the upload process.


	N.B. A leg will be considered to be the loading and unloading activities at the location stops and it is expected that there will be distinct stops for each activity (i.e. there will be pairs of trip stops that constitute a leg). It is also expected that the stop number will be consecutive for these stops.		N.B. A leg will be considered to be the loading and unloading activities at the location stops and it is expected that there will be distinct stops for each activity (i.e. there will be pairs of trip stops that constitute a leg). It is also expected that the stop number will be consecutive for these stops.


	For example, if stop 1 (which contains a loading activity) has actual times set then stop 1 and stop 2 will be ‘locked’ because the leg of the trip is between stops 1 and 2.		For example, if stop 1 (which contains a loading activity) has actual times set then stop 1 and stop 2 will be ‘locked’ because the leg of the trip is between stops 1 and 2.


	However, if stop 2 (which contains an unloading activity) has actual times set then stop 3 will not be ‘locked’ regardless of the activity because it is part of a separate leg.		However, if stop 2 (which contains an unloading activity) has actual times set then stop 3 will not be ‘locked’ regardless of the activity because it is part of a separate leg.


	~~''Technical Note:''~~


	''The new procedure ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ will extract the trip and order data from the file and perform the validation needed, the inbound file’s data will be stored on the existing database tables: ‘INT_XML_TRIP_STOP’, ‘INT_XML_ORD_HEADER’ and ‘INT_XML_ORD_DETAILS’ for validation and further processing.''


	''If validation fails then the status will be ‘FAILURE’ and the upload will be prevented, if validation has passed then the status will be ‘NEW’ until the creation stage of the upload is completed. The status will then be updated to ‘SUCCESS’ or ‘FAILURE’ as appropriate for the creation stage of the upload.''


	~~''Procedure ‘P_PROCESS_RESCHEDULED_TRIP_ORDER’ will call a new function called ‘F_PROCESS_RESCHEDULED_TRIP_ORDER’ to delete and create the trip and orders.''~~


	~~''If a ‘handshake’ message is required, an interface control record will be written with the trip data for external system as the EDI process name and event type ‘TRP’.''~~


	=== Trip and Order Processing ===		=== Trip and Order Processing ===

Admin: New page: Image: '''DHL C-TMS''' '''10.7''' {| style="border-spacing:0;" | style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;pad...

2012-05-11T14:30:50Z

New page: [[Image:]] <center>'''DHL C-TMS'''</center> <center>'''10.7'''</center> {| style="border-spacing:0;" | style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;pad...

Show changes

← Older revision		Revision as of 16:35, 11 May 2012
Line 63:		Line 63:
	== Solution ==		== Solution ==
	A new EDI process will be created in the EDI Maintenance screen. This process will upload and process orders and trips sent in from the PLUTO system. The current ‘TripOrder’ XML format will be used to transmit the data from PLUTO to C-TMS and from C-TMS to PLUTO		A new EDI process will be created in the EDI Maintenance screen. This process will upload and process orders and trips sent in from the PLUTO system. The current ‘TripOrder’ XML format will be used to transmit the data from PLUTO to C-TMS and from C-TMS to PLUTO


	A unique identifier will be passed in for each order as the customer reference. This identifier will be unique and will define the order number, product number, product split and leg number. For each trip in a schedule day, PLUTO will provide a route code which defines the vehicle movement in the plan for the shift, for example ‘BEL DD3-1’ means ‘Bellshill Double Deck 3 for shift 1. PLUTO plans based on vehicle movements for notional vehicles available from the fleet each day.		A unique identifier will be passed in for each order as the customer reference. This identifier will be unique and will define the order number, product number, product split and leg number. For each trip in a schedule day, PLUTO will provide a route code which defines the vehicle movement in the plan for the shift, for example ‘BEL DD3-1’ means ‘Bellshill Double Deck 3 for shift 1. PLUTO plans based on vehicle movements for notional vehicles available from the fleet each day.


	It is expected that all required information to create both orders and trips will be provided in the message. The existing validation process will take place and any messages that do not contain the necessary information will be rejected. If the orders or trips are invalid they will be rolled back and a new file will need to be sent to create the orders and trips. Once the orders and trip have been uploaded into C-TMS and the trip set to ‘PLANNED’ status a ‘TripOrder’ message will be sent back to PLUTO to confirm file has completed. This file will use the current ‘TripOrder’ XML format and will contain the C-TMS trip ID created along with the C-TMS OMS references created. A file will only be sent back to PLUTO if all orders and trips have been created successfully. If a file is not sent back from C-TMS to PLUTO, this will indicate the trip or orders have not been successfully loaded into C-TMS.		It is expected that all required information to create both orders and trips will be provided in the message. The existing validation process will take place and any messages that do not contain the necessary information will be rejected. If the orders or trips are invalid they will be rolled back and a new file will need to be sent to create the orders and trips. Once the orders and trip have been uploaded into C-TMS and the trip set to ‘PLANNED’ status a ‘TripOrder’ message will be sent back to PLUTO to confirm file has completed. This file will use the current ‘TripOrder’ XML format and will contain the C-TMS trip ID created along with the C-TMS OMS references created. A file will only be sent back to PLUTO if all orders and trips have been created successfully. If a file is not sent back from C-TMS to PLUTO, this will indicate the trip or orders have not been successfully loaded into C-TMS.


	When creating the orders in C-TMS, each new order will be given a unique OMS reference; the identifier passed into C-TMS from PLUTO will be stored as the ‘External Reference’ (‘Customer Reference’). Each trip created will be given a unique trip ID starting with ‘PLU-’ and the status will be set to ‘PLANNED’. Changes will be processed against trips that have status ‘EN-ROUTE’ but only for legs not yet executed.		When creating the orders in C-TMS, each new order will be given a unique OMS reference; the identifier passed into C-TMS from PLUTO will be stored as the ‘External Reference’ (‘Customer Reference’). Each trip created will be given a unique trip ID starting with ‘PLU-’ and the status will be set to ‘PLANNED’. Changes will be processed against trips that have status ‘EN-ROUTE’ but only for legs not yet executed.


	When creating trip stops in C-TMS from the interface message, the unique stop ID from PLUTO for the schedule and trip will be saved and will be sent back to PLUTO for the message handshake confirmation and for the actual arrival and actual departure times update messages.		When creating trip stops in C-TMS from the interface message, the unique stop ID from PLUTO for the schedule and trip will be saved and will be sent back to PLUTO for the message handshake confirmation and for the actual arrival and actual departure times update messages.


	A new system parameter will be introduced to prevent the deletion of empty trip stops during processing.		A new system parameter will be introduced to prevent the deletion of empty trip stops during processing.


	The C-TMS interface errors forms will be available to allow the status of uploaded messages to be reviewed. This will include ‘SUCCESS’ and ‘FAILURE’. Any failures can be found and reviewed and error messages will indicate the failure reason.		The C-TMS interface errors forms will be available to allow the status of uploaded messages to be reviewed. This will include ‘SUCCESS’ and ‘FAILURE’. Any failures can be found and reviewed and error messages will indicate the failure reason.


	If a file is received that contains a trip and orders that already exist in C-TMS, this file will be treated as an update. The PLUTO route code, PLUTO stop number and order external reference will be used to uniquely identify the trips and orders that already exist on C-TMS. The existing trips and orders will be deleted and replaced with the new data. The trips and orders will be removed completely to prevent issues with unique references. Updates to trips and orders will only be permitted until the actual arrival or actual departure is entered against a stop. This will be from a Microlise update normally but manual intervention in debrief will be possible and will provide the same input. Once this has happened, the trip stops and orders on those stops will be locked from any changes via the PLUTO interface.		If a file is received that contains a trip and orders that already exist in C-TMS, this file will be treated as an update. The PLUTO route code, PLUTO stop number and order external reference will be used to uniquely identify the trips and orders that already exist on C-TMS. The existing trips and orders will be deleted and replaced with the new data. The trips and orders will be removed completely to prevent issues with unique references. Updates to trips and orders will only be permitted until the actual arrival or actual departure is entered against a stop. This will be from a Microlise update normally but manual intervention in debrief will be possible and will provide the same input. Once this has happened, the trip stops and orders on those stops will be locked from any changes via the PLUTO interface.


	PLUTO on occasion will send DELETE messages if a trip is completely removed form the plan prior to execution.		PLUTO on occasion will send DELETE messages if a trip is completely removed form the plan prior to execution.


	When an actual arrival or actual departure date and time is entered against a trip stop, a message will be triggered to PLUTO. The message will be in the ‘TripOrder’ XML format, and will contain the information for the trip that has been updated. The same leg lock strategy will be maintained in PLUTO based on the actual arrival and actual departure time available from the depot.		When an actual arrival or actual departure date and time is entered against a trip stop, a message will be triggered to PLUTO. The message will be in the ‘TripOrder’ XML format, and will contain the information for the trip that has been updated. The same leg lock strategy will be maintained in PLUTO based on the actual arrival and actual departure time available from the depot.


	A record will be written to the interface table ‘INT_XML_CONTROL’ for each trip and a database job will run at a set interval to process the outstanding messages. This outbound message will be controlled in the EDI maintenance screen.		A record will be written to the interface table ‘INT_XML_CONTROL’ for each trip and a database job will run at a set interval to process the outstanding messages. This outbound message will be controlled in the EDI maintenance screen.


	== Scope ==		== Scope ==