291809 - Revision history

Admin: /* Inbound Order Upload */

2012-05-03T13:00:57Z

Inbound Order Upload

← Older revision		Revision as of 15:00, 3 May 2012
Line 141:		Line 141:


	[[Image:~~291808_1~~.png]]		[[Image:291809_1.png]]

	If all the orders are successfully uploaded and the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’ a new auto-planning procedure will be called. This procedure will retrieve the uploaded orders in ROUTE_CODE and STOP_SEQUENCE order. The STOP_SEQUENCE in this case will be a count within each ROUTE_CODE based on the sequence the orders are passed into the file. Note that stops that are passed into the file that have the same location will be assigned to the same stop. For each ROUTE_CODE, the program will check for a C-TMS trip record. If one exists, then the trip will be removed from the system by calling the TRM.DELETE_TRIP procedure. This will have the effect of un-scheduling all the orders from that trip and removing all the payments generated so far. Note that if the trip selected is at status ‘En-Route’ or later then it will not be possibly to modify the trip. In this scenario, no changes will be made to the existing trip. The file upload for the orders will still be considered as being successful since the orders will process correctly, so the user will have to check that if there any trip level issues by accessing the ‘XML Trips’ canvas within the Interface Errors form:		If all the orders are successfully uploaded and the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’ a new auto-planning procedure will be called. This procedure will retrieve the uploaded orders in ROUTE_CODE and STOP_SEQUENCE order. The STOP_SEQUENCE in this case will be a count within each ROUTE_CODE based on the sequence the orders are passed into the file. Note that stops that are passed into the file that have the same location will be assigned to the same stop. For each ROUTE_CODE, the program will check for a C-TMS trip record. If one exists, then the trip will be removed from the system by calling the TRM.DELETE_TRIP procedure. This will have the effect of un-scheduling all the orders from that trip and removing all the payments generated so far. Note that if the trip selected is at status ‘En-Route’ or later then it will not be possibly to modify the trip. In this scenario, no changes will be made to the existing trip. The file upload for the orders will still be considered as being successful since the orders will process correctly, so the user will have to check that if there any trip level issues by accessing the ‘XML Trips’ canvas within the Interface Errors form:

Admin: /* Inbound Order Upload */

2012-05-03T13:00:08Z

Inbound Order Upload

← Older revision		Revision as of 15:00, 3 May 2012
Line 141:		Line 141:


	[[Image:]]		[[Image:291808_1.png]]

	If all the orders are successfully uploaded and the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’ a new auto-planning procedure will be called. This procedure will retrieve the uploaded orders in ROUTE_CODE and STOP_SEQUENCE order. The STOP_SEQUENCE in this case will be a count within each ROUTE_CODE based on the sequence the orders are passed into the file. Note that stops that are passed into the file that have the same location will be assigned to the same stop. For each ROUTE_CODE, the program will check for a C-TMS trip record. If one exists, then the trip will be removed from the system by calling the TRM.DELETE_TRIP procedure. This will have the effect of un-scheduling all the orders from that trip and removing all the payments generated so far. Note that if the trip selected is at status ‘En-Route’ or later then it will not be possibly to modify the trip. In this scenario, no changes will be made to the existing trip. The file upload for the orders will still be considered as being successful since the orders will process correctly, so the user will have to check that if there any trip level issues by accessing the ‘XML Trips’ canvas within the Interface Errors form:		If all the orders are successfully uploaded and the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’ a new auto-planning procedure will be called. This procedure will retrieve the uploaded orders in ROUTE_CODE and STOP_SEQUENCE order. The STOP_SEQUENCE in this case will be a count within each ROUTE_CODE based on the sequence the orders are passed into the file. Note that stops that are passed into the file that have the same location will be assigned to the same stop. For each ROUTE_CODE, the program will check for a C-TMS trip record. If one exists, then the trip will be removed from the system by calling the TRM.DELETE_TRIP procedure. This will have the effect of un-scheduling all the orders from that trip and removing all the payments generated so far. Note that if the trip selected is at status ‘En-Route’ or later then it will not be possibly to modify the trip. In this scenario, no changes will be made to the existing trip. The file upload for the orders will still be considered as being successful since the orders will process correctly, so the user will have to check that if there any trip level issues by accessing the ‘XML Trips’ canvas within the Interface Errors form:


	[[Image:]]		[[Image:291809_2.png]]

	If the original trip is deleted successfully, then the process will create a new trip record for the new ROUTE_CODE. Note that this will have a different C-TMS TRIP_ID value as this is based on a sequence. The trip will be created using the TRM.INSERT_TRIP procedure.		If the original trip is deleted successfully, then the process will create a new trip record for the new ROUTE_CODE. Note that this will have a different C-TMS TRIP_ID value as this is based on a sequence. The trip will be created using the TRM.INSERT_TRIP procedure.

Admin: /* Inbound Order Upload */

2012-05-03T12:56:35Z

Inbound Order Upload

← Older revision		Revision as of 14:56, 3 May 2012
Line 157:		Line 157:

	Note that the existing carrier-lane based autoplan process will be altered to be called only if the ‘AUTOPLAN_METHOD’ parameter is set to ‘L’. This will allow segregation of the autoplanning process.		Note that the existing carrier-lane based autoplan process will be altered to be called only if the ‘AUTOPLAN_METHOD’ parameter is set to ‘L’. This will allow segregation of the autoplanning process.


	'''Modules to be changed'''		'''Modules to be changed'''


	{\| style="border-spacing:0;"		{\| style="border-spacing:0;"

Admin: /* Inbound Order Upload */

2012-05-03T12:56:06Z

Inbound Order Upload

← Older revision		Revision as of 14:56, 3 May 2012
Line 158:		Line 158:
	Note that the existing carrier-lane based autoplan process will be altered to be called only if the ‘AUTOPLAN_METHOD’ parameter is set to ‘L’. This will allow segregation of the autoplanning process.		Note that the existing carrier-lane based autoplan process will be altered to be called only if the ‘AUTOPLAN_METHOD’ parameter is set to ‘L’. This will allow segregation of the autoplanning process.

	'''Modules to be changed'''		'''Modules to be changed'''


Line 267:		Line 267:

	\|}		\|}

	=AUTHORISED BY=		=AUTHORISED BY=
	{\| Border="1"		{\| Border="1"

Admin: /* Data */

2012-05-03T12:55:37Z

Data

← Older revision		Revision as of 14:55, 3 May 2012
Line 59:		Line 59:
	The inbound upload process using the standard ‘TripOrder v2.23.xsd’ is expected to be used. Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.		The inbound upload process using the standard ‘TripOrder v2.23.xsd’ is expected to be used. Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.

			A new Cost Centre level parameter ‘AUTOPLAN_METHOD’ will be created and set to ‘R’ for British Gypsum.
	A new Cost Centre level parameter ‘AUTOPLAN_METHOD’ will be created and set to ‘R’ for British Gypsum.

	= Functional Description =		= Functional Description =

Admin: /* Solution */

2012-05-03T12:55:23Z

Solution

← Older revision		Revision as of 14:55, 3 May 2012
Line 33:		Line 33:
	== Solution ==		== Solution ==
	<nowiki>The inbound EDI order upload process will be altered to create trips based on the <ROUTE_CODE> value passed into the <ORDER_HEADER> level record. A new cost centre level parameter AUTOPLAN_METHOD will be created. If this parameter is set to ‘R’, a new procedure will be run to create and modify trips after all the orders have been created.</nowiki>		<nowiki>The inbound EDI order upload process will be altered to create trips based on the <ROUTE_CODE> value passed into the <ORDER_HEADER> level record. A new cost centre level parameter AUTOPLAN_METHOD will be created. If this parameter is set to ‘R’, a new procedure will be run to create and modify trips after all the orders have been created.</nowiki>


	This will retrieve the orders that have been created in Route Code sequence. For each Route Code, the trip record should be retrieved and the all the existing orders that belong to that trip will be removed.		This will retrieve the orders that have been created in Route Code sequence. For each Route Code, the trip record should be retrieved and the all the existing orders that belong to that trip will be removed.


	Then for each order passed in, a check will be made to determine if the order already belongs to a different trip by comparing the Route Code of that trip to the one passed in. If this is the case, then the order will be removed from that trip.		Then for each order passed in, a check will be made to determine if the order already belongs to a different trip by comparing the Route Code of that trip to the one passed in. If this is the case, then the order will be removed from that trip.


	The trip the order used to belong to will then be revalidated. The order will then be added to the trip for the Route Code passed in. At the end of each Route Code, the dates and times for the trip will be recalculated and the trip will be revalidated.		The trip the order used to belong to will then be revalidated. The order will then be added to the trip for the Route Code passed in. At the end of each Route Code, the dates and times for the trip will be recalculated and the trip will be revalidated.


	It is expected that the orders passed in for each trip will be sent in the sequence the stops are expected to be created.		It is expected that the orders passed in for each trip will be sent in the sequence the stops are expected to be created.

			Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.
	Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.


	== Scope ==		== Scope ==

Admin: /* Client Requirement */

2012-05-03T12:54:55Z

Client Requirement

← Older revision		Revision as of 14:54, 3 May 2012
Line 12:		Line 12:

	Planned Trips flow: Development, Mapping consultation, implementation and UAT support of the Planned Trips flow from SAP into C-TMS.		Planned Trips flow: Development, Mapping consultation, implementation and UAT support of the Planned Trips flow from SAP into C-TMS.


	To include:		To include:
Line 31:		Line 30:

	Migration away from ETHOS.		Migration away from ETHOS.


	== Solution ==		== Solution ==

Admin at 12:54, 3 May 2012

2012-05-03T12:54:31Z

@@ Line 1: / Line 1: @@
-[[Image:]]
+{{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Planned Trips Flow|Reference=291809 - TH-8LFCDX |Version=2.0|Date=1/11/11|Sysver=10.7|Client=DHL C-TMS}}
 == Client Requirement ==
 '''Change Request Summary:'''

Admin at 12:51, 3 May 2012

2012-05-03T12:51:51Z

← Older revision		Revision as of 14:51, 3 May 2012
Line 116:		Line 116:
	<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters.		<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters.

	~~There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.~~


	~~== Scope ==~~
	~~This change will be applied to system version 10.7.~~

	~~= Set-up =~~
	~~== Pre-requisites ==~~
	~~None~~


	~~== Menu Structure ==~~
	~~Unchanged~~


	~~== Data ==~~
	The inbound upload process using the standard ‘TripOrder v2.23.xsd’ is expected to be used. Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.


	~~A new Cost Centre level parameter ‘AUTOPLAN_METHOD’ will be created and set to ‘R’ for British Gypsum.~~

	~~= Functional Description =~~
	~~== Business Data ==~~
	<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters

	== Inbound Order Upload ==		== Inbound Order Upload ==
			<nowiki>This program will be altered to create trips based on the <ROUTE_CODE> value passed against the <ORDER_HEADER> level record. </nowiki>

	After the orders have been processed, a new procedure will be added to be called if the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’.		After the orders have been processed, a new procedure will be added to be called if the ‘AUTOPLAN_METHOD’ parameter is set to ‘R’.

	This will have the effect of creating a trip with a route code that matches the route code passed in against the orders. So for example of a file is sent in as follows:		This will have the effect of creating a trip with a route code that matches the route code passed in against the orders. So for example of a file is sent in as follows:


	'''File1'''		'''File1'''
Line 177:		Line 153:
	\|}		\|}
	Expected result: The 4 orders will become assigned to Trip3 with the stop sequence for the orders matching the sequence they are passed in. Trip1 and Trip2 will no longer contain REF1, REF2 and REF4 and will be revalidated. If Trip1 and Trip2 no longer contain any orders, those trips will be deleted.		Expected result: The 4 orders will become assigned to Trip3 with the stop sequence for the orders matching the sequence they are passed in. Trip1 and Trip2 will no longer contain REF1, REF2 and REF4 and will be revalidated. If Trip1 and Trip2 no longer contain any orders, those trips will be deleted.


	'''File2'''		'''File2'''
Line 256:		Line 231:

	'''References'''		'''References'''


	{\| style="border-spacing:0;"		{\| style="border-spacing:0;"
Line 344:		Line 318:

	\|}		\|}


	=AUTHORISED BY=		=AUTHORISED BY=
	{\| Border="1"		{\| Border="1"

Admin: /* Business Data */

2012-05-03T12:48:33Z

Business Data

← Older revision		Revision as of 14:48, 3 May 2012
Line 116:		Line 116:
	<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters.		<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters.

			There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.


			== Scope ==
			This change will be applied to system version 10.7.

			= Set-up =
			== Pre-requisites ==
			None


			== Menu Structure ==
			Unchanged


			== Data ==
			The inbound upload process using the standard ‘TripOrder v2.23.xsd’ is expected to be used. Note that OBS are assuming that the Route Code passed in is not expected to exceed 12 characters. There is also the assumption that the SAP delivery number (which will be stored within the 50 character External Ref against the order) is unique.


			A new Cost Centre level parameter ‘AUTOPLAN_METHOD’ will be created and set to ‘R’ for British Gypsum.

			= Functional Description =
			== Business Data ==
			<nowiki>The <ROUTE_CODE> field against each order is expected to specify a unique trip </nowiki>identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters

	== Inbound Order Upload ==		== Inbound Order Upload ==