How to handle changes after Sending of Freight Documents
Maybe at some point you faced the issue that your freight order or freight booking confirmation by the transportation service provider was rejected with the message “Cannot confirm document; sent data has already been changed”.
This blog gives some background information and different strategies to handle these late changes as the shipper, based on the business requirement of your customer.
What does trigger this status change?
Maybe first thing is to understand, what changes actually trigger resetting the status:
- Location Changes
- Date&Time Changes
- Quantity Changes: For FCL/ULD bookings only changes ot the actual container capacities will trigger the status reset, the quantities within the container are not critical for the booking process at this point
- TSP Service Level Change
- Handling Code Changes
- Executing Carrier
- Master Bill of Lading/Master Airway Bill
- Changes in Stages
- Changes to Carrier Routing(Air): Flight Number, Space Allocation Code
So why not just directly resend the transportation request?
Let’s assume you do not only perform a single change after initial subcontracting but really step-by-step adapt your order due to changes in demand. Or maybe changes are just constantly happening due to changes in the underlying sales order. Sending an update after every save with a change would constantly generate messages to your transportation service provider, which he might not be able to actually handle frequent updates or put at least a lot of burden on the complete subcontracring process.
Then what are my options?
The Simple Option:
Your user knows best? So just give him a dedicated worklist filtering documents in status changed after sending.
This enables the user to effectively monitor and manually recommunicate changed documents en masse.
The impatient Option:
So even after my warning above you want to immediately resend your order…ok, so let’s do it anyway.
We will do this by setting up a chaco strategy and condition, that resends the booking once there was a subcontracting relevant change.
First we create a process controller methode stratgey including the standard Change Controller Method SEND_TOR.
Secondly we create a Change Controller Condition to only trigger the sending once a subcontracting relevant change occured that would also set the status accordingly.
The Data Access Definition in screenshot above is not deliverd as part of standard customizing, therefore you have to maintain a DAD as per screenshot below.
Assign the Chance Controller Condition to your Freight Order/Booking type and everytime a subcontracting relevant change is performed the system will asynchronously trigger a new subcontracting request.
The “Ignorant” Option:
You are very sure that in your scenario ususally only minor changes occur and the standard definition of a subcontracting relevant change is far to critical and you would not even communicate that with the carrier. Let’s say a minor quantity change happens that might not affect charges or the truck type required from your carrier and you do not even need the hazzle to communicate this to your carrier.
In this case you have the option to implement BADI /SCMTMS/TOR_CHACO_CHANGES_DET Method DET_CUSTOM_CHANGES
In this method you can validate the changes during save yourself and adapt the criticality of changes determined by the standard logic.
Disclaimer: This method is very easy to implement in case you want to identify additional changes and raise the criticality of a change. However if you want to potentially ignore changes identified in standard you need to make sure that you really only ignore the minor changes you deem not relevant for your scenario and not overwrite critical changes which are also critical for your scenario.
The middle Ground:
So you do not want to flood your TSP with Updates and you do not want this to become a manual task for your user.
In this case you have the option to send out updates by scheduling report /SCMTMS/TOR_FO_PROC_BATCH for Freight Orders, respectively /SCMTMS/TOR_BO_PROC_BATCH for Freight Bookings, in a suitable interval.
You can simply assign a selection profile that filters for documents which are in status changed after sending and collectively send those again to your service provider.
I hope this blog explains, why the system is designed the way it is. I know often customers first instinct is to expect immediate and automatic updates, but this should give you some guidance to explain why this might not be the best solution after all and tools to tailor the system to the actual customer need.
Nicely explained. Thank you.
this is a great explanation of the reasons and the different options!
Are there plans to move the trigger handling of the different status changes into customizing? This would enable much easier handling of different customer use cases. Think of a scenario like this:
Up to a certain planning status of the FO, users can manually sent the message to a carrier (they can make all kinds of changes until they are done planning and want to sent the pre-advice data to a carrier).
Only when the FO is actually sent out (here: the FO is set to "shipment completion", the truck has left the warehouse), a final message is automatically triggered containing all the actual shipping data to the carrier.