289051: Difference between revisions

From CTMS
VisualWikitext
(New page: {{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Automotive Microlise Updates|Reference=289051 OB-8HGCRZ |Version=1.0|Date=|Sysver=10.6|Client=DHL C-TMS}} == Client Requirement == '''Ch...)
 
No edit summary
Line 3: Line 3:


== Client Requirement ==
== Client Requirement ==
'''Change Request Summary:'''
'''Change Request Summary:'''


Change to the Existing Microlise interface to bring it back in line with Phase two project Delivery.
Change to the Existing Microlise interface to bring it back in line with Phase two project Delivery.
Line 10: Line 10:


'''Change Request Details:'''
'''Change Request Details:'''


The existing Microlise interface requires changing to allow for phase two functionality (the systematic collections) to be handled correctly.Currently, the interface between C-TMS and Microlise (via ESI) isn't working correctly. Outbound from C-TMS to Microlise, the journey update messages are causing validation errors at Microlise as we are breaking two of the primary keys within their database. From Microlise back to C-TMS, the sequence of the drops is incorrect, causing the debrief screen to be thrown out, and the times against the drops being in the wrong place.After investigation work by all 3 parties and the project team, a solution has been identified where certain messages will be being suppressed from C-TMS to Microlise, and to use the unique stop_id (not visible to users but held within the database itself), as a unique stop number to be passed to Microlise.
The existing Microlise interface requires changing to allow for phase two functionality (the systematic collections) to be handled correctly.Currently, the interface between C-TMS and Microlise (via ESI) isn't working correctly. Outbound from C-TMS to Microlise, the journey update messages are causing validation errors at Microlise as we are breaking two of the primary keys within their database. From Microlise back to C-TMS, the sequence of the drops is incorrect, causing the debrief screen to be thrown out, and the times against the drops being in the wrong place.After investigation work by all 3 parties and the project team, a solution has been identified where certain messages will be being suppressed from C-TMS to Microlise, and to use the unique stop_id (not visible to users but held within the database itself), as a unique stop number to be passed to Microlise.


== Solution ==


== Solution ==
The following changes will be made:
The following changes will be made:


# The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.
# The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.
Line 23: Line 21:
# The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders; therefore, when they are sent to Microlise the trip stop is only included if it contains at least one order not inserted by Microlise.
# The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders; therefore, when they are sent to Microlise the trip stop is only included if it contains at least one order not inserted by Microlise.


# <nowiki>A new system parameter called ‘MIC_USE_STOP_ID’ will be created to control whether the stop ID is used by Microlise instead of the stop number in the XML tag <STOP_SEQ>: if the system parameter is set to ‘Y’ then the stop ID will be used and the stop number obtained for the stop ID when it is received from Microlise.</nowiki>
 


== Scope ==
== Scope ==
Line 31: Line 29:
== Pre-requisites ==
== Pre-requisites ==
None
None


== Menu Structure ==
== Menu Structure ==
‘Unchanged’
‘Unchanged’


== Data ==


== Data ==
# A new system parameter will be introduced (see Appendix A for the script for creation).
# A new system parameter will be introduced (see Appendix A for the script for creation).


Line 45: Line 42:


= Functional Description =
= Functional Description =
== System Parameters ==
== System Parameters ==
A new system parameter called ‘MIC_USE_STOP_ID’ will store a comma-delimited list of prefixes that will exclude the storage of a new asset.
A new system parameter called ‘MIC_USE_STOP_ID’ will store a comma-delimited list of prefixes that will exclude the storage of a new asset.


The description of the system parameter will be:
The description of the system parameter will be:


‘Determines if the stop ID or the stop sequence will be used by Microlise, if 'Y' then the stop ID will be used.’
‘Determines if the stop ID or the stop sequence will be used by Microlise, if 'Y' then the stop ID will be used.’


== ‘INT_XML_MIC’ Package ==


== ‘INT_XML_MIC’ Package ==
The following changes will be made to the ‘INT_XML_MIC’ package.
The following changes will be made to the ‘INT_XML_MIC’ package.


=== Collection Details ===


=== Collection Details ===
The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.
The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.




Trips may be considered in the examples below for when the system parameter is set to ‘TRUNK’:
Trips may be considered in the examples below for when the system parameter is set to ‘TRUNK’:




Line 149: Line 145:


|}
|}
Deliveries to a dealership loaded from a RDC location and collections from a dealership to be unloaded at a RDC location will be included for orders on ‘TRUNK’ trips.
Deliveries to a dealership loaded from a RDC location and collections from a dealership to be unloaded at a RDC location will be included for orders on ‘TRUNK’ trips.


=== Source System ===


=== Source System ===
The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders.
The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders.


When they are sent to Microlise the trip stop will only be included if it contains at least one order not inserted by Microlise.
When they are sent to Microlise the trip stop will only be included if it contains at least one order not inserted by Microlise.
Line 160: Line 156:


=== Stop Sequences ===
=== Stop Sequences ===
<nowiki>A new system parameter called ‘MIC_USE_STOP_ID’ will be created to control whether the stop ID will be used by Microlise instead of the stop number in the XML tag <STOP_SEQ>: if the system parameter is set to ‘Y’ then the stop ID will be used and the stop number obtained for the stop ID when it is received from Microlise.</nowiki>
<nowiki>The stop ID will be stored in the XML tag <STOP_ID> as described in v2.20 of the TripOrder.xsd file.</nowiki>


The stop ID may be a hyphen-delimited list of stop IDs should the stops be consolidated.
The stop ID may be a hyphen-delimited list of stop IDs should the stops be consolidated.




<nowiki>New tag <STOP_ID> will be introduced to send to, and receive from, Microlise based on the stop ID at the trip stop to accompany the stop number in the tag <STOP_SEQ>.</nowiki>


#  
#  
Line 179: Line 169:
#::::::  
#::::::  
#:::::::  
#:::::::  
#:::::::# '''table updates REQUIRED'''
#:::::::# '''Table Updates Required'''


The new system parameter may be created using the following script:
The new system parameter may be created using the following script:
[[Image:]]


The new source system may be created using the following script:
The new source system may be created using the following script:
[[Image:]]




Line 223: Line 203:


|}
|}


'''Glossary'''
'''Glossary'''

Revision as of 11:20, 17 August 2011

Aptean Logo.png







DHL C-TMS

Automotive Microlise Updates

FUNCTIONAL SPECIFICATION - 10.6 

- 1.0


Reference: 289051 OB-8HGCRZ












































Client Requirement

Change Request Summary:

Change to the Existing Microlise interface to bring it back in line with Phase two project Delivery.


Change Request Details:

The existing Microlise interface requires changing to allow for phase two functionality (the systematic collections) to be handled correctly.Currently, the interface between C-TMS and Microlise (via ESI) isn't working correctly. Outbound from C-TMS to Microlise, the journey update messages are causing validation errors at Microlise as we are breaking two of the primary keys within their database. From Microlise back to C-TMS, the sequence of the drops is incorrect, causing the debrief screen to be thrown out, and the times against the drops being in the wrong place.After investigation work by all 3 parties and the project team, a solution has been identified where certain messages will be being suppressed from C-TMS to Microlise, and to use the unique stop_id (not visible to users but held within the database itself), as a unique stop number to be passed to Microlise.

Solution

The following changes will be made:

  1. The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.
  1. The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders; therefore, when they are sent to Microlise the trip stop is only included if it contains at least one order not inserted by Microlise.


Scope

This change will be applied to system version 10.6.0.

Set-up

Pre-requisites

None

Menu Structure

‘Unchanged’

Data

  1. A new system parameter will be introduced (see Appendix A for the script for creation).
  1. The new source system will be introduced (see Appendix A for the script for their creation).
  1. The existing system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ should be set to ‘TRUNK’.

Functional Description

System Parameters

A new system parameter called ‘MIC_USE_STOP_ID’ will store a comma-delimited list of prefixes that will exclude the storage of a new asset.

The description of the system parameter will be:

‘Determines if the stop ID or the stop sequence will be used by Microlise, if 'Y' then the stop ID will be used.’

‘INT_XML_MIC’ Package

The following changes will be made to the ‘INT_XML_MIC’ package.

Collection Details

The collection details will be sent to Microlise for the dealerships if the system parameter ‘MIC_SUPPRESS_ORDER_SEGMENT’ is set to ‘TRUNK’ and the trip is between an RDC location and a dealership location in either direction. At present this system parameter is set to ‘TRUNK’ for Automotive so only delivery activities at the order destination would be included.


Trips may be considered in the examples below for when the system parameter is set to ‘TRUNK’:


Source Destination From Type To Type Included
LOC1 LOC4 LOC1 ORIGIN LOC2 RDC N
LOC2 RDC LOC3 RDC N
LOC3 RDC LOC4 BRANCH Y
LOC1 ORIGIN LOC4 BRANCH N
LOC4 LOC1 LOC4 BRANCH LOC1 ORIGIN N
LOC4 BRANCH LOC3 RDC Y
LOC3 RDC LOC2 RDC N
LOC2 RDC LOC1 ORIGIN N

Deliveries to a dealership loaded from a RDC location and collections from a dealership to be unloaded at a RDC location will be included for orders on ‘TRUNK’ trips.

Source System

The file received from Microlise creates a new order if the TMS order reference is null, if such an order is created then the source system of the order will be set to ‘MIC’ to identify these orders.

When they are sent to Microlise the trip stop will only be included if it contains at least one order not inserted by Microlise.


Stop Sequences

The stop ID may be a hyphen-delimited list of stop IDs should the stops be consolidated.


    1. Table Updates Required

The new system parameter may be created using the following script:

The new source system may be created using the following script:


References

Ref No
Document Title & ID
Version
Date
1
 EST-289051 OB-8HGCRZ Automotive Microlise Updates v1.0.doc
1.0
03/06/11


Glossary

Term or Acronym
Meaning
C-TMS Calidus TMS


Document History

Version
Date
Status
Reason
Initials
0.1
03/06/11
Draft
 Initial version
PDR
1.0
15/06/11
Issue
 Reviewed and Issued
MJC


AUTHORISED BY

Matt Crisford Development Manager
Peter Greer TMSCC MTS Product Manager
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/MTS/index.php?title=289051&oldid=4139’