271596
221596 - PA-7N6HZH/ EFX Cancellation
Copyright OBS Logistics © 2010
The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied
FUNCTIONAL OVERVIEW
Client Requirement
Allow Posted Trips in EFX to be cancelled from MTS.
Create a link between MTS and EFX to cancel trips previously posted on EFX.
Possibly add a button in Trip Detail to invoke pop-up window with EFX reference number and cancellation reason codes, transmit these to EFX to invoke Cancel action and populate reason codes within EFX. Change Trip status to PLANNED and revert Carrier to Owning Depot and clear Payment Summary within MTS.
Solution
The following assumptions have been made in this estimate. Changes to these assumptions will require a revised estimate, or if the estimate has already been approved, a new RIO.
- Trips can only be cancelled in EFX from MTS if no party has yet accepted the trip within the EFX system.
- The EFX system will send a response to the cancellation message, indicating whether the cancellation is accepted or rejected.
- If the cancellation message needs to be resent to EFX, it will be done through the EFX interface screen, not through the Trip screens.
The changes to the Trip due to the cancellation (change the trip status, remove the payment, revert the carrier and remove the EFX reference) will be done on receipt of a cancellation acceptance message back from EFX.
Due to timing issues it is possible that a trip could be accepted in the EFX system before the cancellation message is received and processed by the EFX system. In that instance we assume that a cancellation rejection message would be returned by EFX.
If a cancellation rejection message is received then no changes will be made to the trip other than to reset the EFX flag to ticked.
NB) The receipt and processing of the cancellation acceptance or rejection message will be done as part of the EFX status updates (271604/ PA-7XVL6X). The development time for this processing is included in that Estimate so there is no development time in this estimate for processing the received messages.
The Trip Planning (TRIP_PLAN) and Trip Manipulation (TRIPSUM) will both be amended in the same way. The EFX flag will be available to uncheck. This will only be possible where the trip status is at Tendered. Once the trip passes to ACCEPTED or beyond then it will not be possible to uncheck the EFX flag.
When the EFX flag is unchecked or the Cancel Button is pressed in either the TRIPSUM or TRIP_PLAN screens then the user will be taken to a new canvas.
This will have 4 reason codes on radio buttons:
The work is being taken back in house (the default) This job is a duplicate and is no longer required The customer has cancelled this load The accepting depot failed to deliver. If the user presses the OK button then a cancellation message will be sent to EFX using the selected reason code and the new canvas will be closed.
If the user presses the Cancel button then the canvas will be closed and the EFX flag will be set as ticked again.
To generate the cancellation message the screens will write into the file INT_TRIP_DTL (in the same way as the initial message to EFX is sent) except that the message_type will be EFX_CANC.
The INT_MSG procedure will be amended so that the EFX_CANC messages are handled by their own function.
In addition to the source details (system, site, message ref, date and message type) the message will report the following:
The EFX reference The Customer name
A cancellation code as follows: For reason ‘The work is being taken back in house’ code ‘OWN’. For reason ‘This job is a duplicate and is no longer required’ code ‘DUPL’. For reasons ‘The customer has cancelled this load’ and ‘The accepting depot failed to deliver’ code ‘CNCL
The cancellation reason codes full text.
Scope
This change will be applied to system version 10.6.
FUNCTIONAL DESCRIPTION
Trip Forms
The trip manipulation screen (TRIPSUM) currently looks like :-
If EFX Flag (SCH_TRIP.EFX_SEND_FLAG) is ticked, the EFX Reference is set and the trip is at either status ‘TENDERED’ or ‘ACCEPTED’ then the user can uncheck the tick flag. The user may also use the new Cancel in EFX button on the new EFX Tab within the Trip Screens.
When unchecked then a new canvas will force the user to select one of 4 reasons why they are cancelling the EFX request. These will line up with the hard coded reason codes that appear when requests are cancelled in the EFX system.
If a request has not already been sent to EFX and is still awaiting a response then a new message to be sent to EFX will then be generated.
A record will be written to the INT_TRIP_DTL table with the Schedule Name, Trip ID, Message Type of 'EFX_CANC' and the corresponding EFX_CANC_REASON (1,2,3 or 4).
These same changes will also be made to the TRIP_PLAN form.
New Procedure PROCESS_EFX_CANC
In the package INT_MSG there is a procedure called PROCESS_OUTSTANDING_TRIP_DTL.
This procedure currently caters for message types of ’DSG_TRIP_DTL’ and ‘EFX_TRIP_DTL’ which in turn call the appropriate procedure within the INT_MSG package.
A new message type ‘EFX_CANC’ will now be received which will call the new procedure PROCESS_EFX_CANC.
The new procedure will process the outstanding EFX cancellation requests and generate new XML file’s based upon the XSD provided by EFX (see appendix A).
A file will need to be produced per owning depot of the trips that need sending.
The files will be placed in the same folder as the existing csv files identified by the existing system registry ‘EFX_TRIP_DTL_PATH’.
The files will be called MTS_EFX_CANC_<date/time>.XML with the date/time down to the micro-second to ensure that it is unique for each file produced.
Other Considerations
It may be necessary to lock the Trip from updates between the Cancellation Request and any acknowledgments or rejection/acceptance being received from EFX. This should be confirmed prior to development starting.
REFERENCES
Not Available
DOCUMENT HISTORY
| Initial version | ||||
| Changes following meeting | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
