291809: Difference between revisions
| (5 intermediate revisions by the same user not shown) | |||
| 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 == | ||
| Line 65: | 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 = | ||
| Line 148: | Line 141: | ||
[[Image:]] | [[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: | ||
[[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. | ||
| Line 165: | 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''' | |||
{| style="border-spacing:0;" | {| style="border-spacing:0;" | ||
| Line 274: | Line 267: | ||
|} | |} | ||
=AUTHORISED BY= | =AUTHORISED BY= | ||
{| Border="1" | {| Border="1" | ||
Latest revision as of 15:00, 3 May 2012
DHL C-TMS
Planned Trips Flow
FUNCTIONAL SPECIFICATION - 10.7
1/11/11 - 2.0
Reference: 291809 - TH-8LFCDX
Client Requirement
Change Request Summary:
Planned Trips flow.
Change Request Details:
Planned Trips flow: Development, Mapping consultation, implementation and UAT support of the Planned Trips flow from SAP into C-TMS.
To include:
Mapping workshop
interface build
CTMS set-up
testing support
implementation to live
Benefits identified as a result of the change:
Migration away from ETHOS.
Solution
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.
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.
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.
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
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
The <ROUTE_CODE> field against each order is expected to specify a unique trip identifier that will be stored against the Trip Header record created. This field has a maximum length of 12 characters.
Inbound Order Upload
This program will be altered to create trips based on the <ROUTE_CODE> value passed against the <ORDER_HEADER> level record.
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:
File1
| OMS_REF | Current Trip Id | New Trip Id (based on ROUTE_CODE) |
| REF1 | TRIP1 | TRIP3 |
| REF2 | TRIP2 | TRIP3 |
| REF3 | NONE | TRIP3 |
| REF4 | TRIP1 | TRIP3 |
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
| OMS_REF | Current Trip Id | New Trip Id (based on ROUTE_CODE) |
| REF5 | NONE | TRIP3 |
| REF2 | TRIP3 | TRIP4 |
| REF3 | TRIP3 | TRIP4 |
| REF4 | TRIP3 | TRIP5 |
| REF6 | NONE | TRIP4 |
Expected result: Orders REF1, REF2, REF3 and REF4 will be removed from TRIP3. Order REF5 will be added to TRIP3. Orders REF2, REF3 and REF6 will be added to TRIP4, any orders that were previously on TRIP4 will be removed. Order REF4 will be added to TRIP5, any orders that were previously on TRIP5 will be removed. Since order REF1 was not passed into the second file, it will not belong to a trip after this upload and will be at status ‘UNSCHEDULED’.
In order to achieve this, firstly the orders will be processed and uploaded using the current xml order upload process. If any errors occur for any of the orders, then the file upload will be rejected and no auto-planning processing will occur. As usual, the order level errors will be visible within the ‘XML orders’ tab within the interface errors screen:
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 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.
For each order that is retrieved, the ROUTE_CODE passed in will be compared to the ROUTE_CODE for the trip that the order currently belongs to. If they are different, then the order will be removed from its current trip assuming the status is before ‘En-Route’ as before. That trip will then be revalidated by calling the TRM.CALC_DISTANCE_AND_TIME procedure followed by the TRM.VALIDATE_TRIP procedure.
Once the new trip has been created, each of the required orders will then be added to the new trip by calling the TRM.ADD_ORDER_TO_TRIP procedure. Note that if the locations passed against the order are new, then the trip validation may fail. Under this circumstance, as with the current auto-planning process, all the orders for that trip will be set as ‘UNSCHEDULED’ and the user will be expected to create the trip manually. The user would also have the option of uploading the file a second time (with a different filename) after the location codes have been updated with valid Latitude and Longitude values.
After the last order to be added to the new trip has been processed, the new trip will be revalidated by calling the TRM.CALC_DISTANCE_AND_TIME procedure followed by the TRM.VALIDATE_TRIP procedure as before. Errors that occur attempting to create or validate the new trips will also be visible in the ‘XML Trips’ canvas of the ‘Interface Errors’ screen.
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
| Module Name | Module Type | Notes |
| INT_XML_IN.sql | Inbound Order upload | |
| INT_XML_TRIP.sql | Inbound Trip Upload | New module |
References
| EST-291809 TH-8LFCDX Planned Trips Flow v1.0.doc | |||
Glossary
| C-TMS | Calidus TMS |
Document History
| Initial version | ||||
| Reviewed and Issued | ||||
| Changes following client review | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
