View source for SCR 369093 Part Confirm Despatch

{{Template:SmallCR
|Client=DHLT
|LogNumber=369093
|Date=24/01/2020
|Requester=Denis Starodubov
|YourName=Tony Walker
|System=MCS
|Request=Multiple users - Users not able to stop mid-load for another user to continue. Allow a user to stop scanning for despatch, and for some other user to pick up on this later and complete.
|Reason=The MCS product has been designed specifically to be one user per trip, and for that trip to be completed before moving on, as explicitly described in both the product documentation and the customer's solution design document.

Despite this, the customer does not wish to abode by this stated restriction of the product. They require that a despatch be allowed to be part-completed by one user, then for another user to be able to continue with it later, seeing what has already been completed by the first user. This is to allow the user to go on a break or finish work for the day without completing their current task.
|Alternatives=The customer does not wish to hand over a terminal that is logged in under one user for another user to complete. Nor do they want to force completion of work before going on a break. 
|Changes=Currently, completing a trip, all items must be scanned or marked as damaged on the device.

The process then does the following:
* Send a "DESP_CONF" per each item scanned:
** Writes a reason code on SOIRC and STI.
** Sets quantities on STI and SOI.
* Send a "DESP_COMP" for the trip:
** Update the trip status.


Solution would be to either:
* Allow complete to be clicked on the trip before completion. Possible change label value. Send back "DESP_CONF" messages for only those that are marked as delivered/damaged/added. Do not send back a "DESP_COMP" message.
* Send back the "DESP_CONF" message as the items are scanned, and allow the user to simply back out when required.

In either case, sending the "DESP_CONF" messages before trip confirmation poses issues:
* This actually confirms the data in CTMS. If these items were then subsequently "un-scanned", that would need to be undone on CTMS.
* Particularly, scanning an item as an additional item for a trip may well split an order and plan the item to the despatching trip. If then subsequently removed, the audit trail would remain - it would need to be either undone or another audit record added. Furthermore, this split order would not then revert to the original planned trip, but would instead remain UNSCHEDULED. This is not a problem for DHL, as they are configured for planned items only. However, there is a fundamental issue here that needs to be resolved (see risks and scope later).
* If an item is scanned and confirmed as loaded, then subsequently unloaded by another user, the item would show as loaded on that trip (reason code SL) and there would be no confirmation that it had been unloaded until a subsequent reason code was received when the user says why it is was not loaded (i.e. damaged). It would eventually look OK, but the reports would show this as loaded. To combat this, we will change the damages process package to do the following:
** Remove any SL messages for this depot - it is now damaged.
** Explicitly set the quantities for this item to 0.
* In any case, should the user NOT confirm the trip, the trip status will not be moved on (as no DESP_COMP message will have been set, which would break the process. This is true in any case without this change, so may be ignored. However, the customer should be aware of the break in the process if one user is not made ultimately responsible for completing the despatch of that trip.
* With changes being entered into under log 369066, any item marked with a reason code will be de-planned from any subsequent trips. Those items could not then be scanned to be reset and then successfully loaded. So, this process MUST NOT allow items that are marked as damaged to be scanned and reset. 


To achieve this functionality, we must make the following changes:
*	System configuration required:
**	New MCS system parameter "MCS_UPDATE_DESPATCH_IMMEDIATELY", values "Y", "N", assume default "N" if unconfigured.
**	MCS modified to retrieve and store this new system parameter. 
* If this functionality is configured, in MCS:
**	Update each item when scanned with CTMS.
**	Completion (despatch) of the trip must only send the completion message, not the "item scanned" messages.
*	MCS Refresh function must update and delete items as well as add new ones (generic change) - no configuration necessary for this.

Additionally:
* Adding RC against a pallet already shown as loaded at this depot should remove the SL reason code and explicitly set the quantity to 0.
* If this new functionality is configured, and the functionality is configured to un-plan items from a trip if marked as damaged (log 369066), items marked as damaged will not be allowed to be scanned again and reset within despatch.


The final process will be:
* Start Despatch
* Enter a trip
* All items displayed.
* Scan several, including one as damaged.
* Log off the device.
* Start again on a different device.
* Start Despatch
* Enter a trip
* All remaining items displayed, initially hiding those already scanned.
* Damaged item cannot be re-scanned.
* Loaded item can be scanned again to unload it.
* Complete scanning of all items.
* Mark any missing/damaged with reason codes.
* Complete the trip as despatched.

|Risks=The following risks are identified:
* This functionality SHOULD NOT be enabled for any customer that does not despatch to plan. If they do, they must be aware of the risks that any unplanned item will be loaded and split from the original order. If this is then subsequently unloaded, the split order will remain and will probably remain as UNSCHEDULED until either properly planned by the operation.
Scope:
* Items (packages or pallets) marked as Damaged will be unplanned (under changes in progress). If both this functionality and the functionality specified here are enabled, once an item is marked as damaged, it may not be reset, as the item has been de-planned already.
|EST=0.50
|DEV=6.5
|TEST=1.75
|Implications=Existing operations using C-MCS may be affected by this additional functionality (LFS and TDL specifically). Care must be taken to implement these changes so that, if not configured to do as described above, the application still works in the same way.
|Status=
|Justification=}}