How to handle changes after Sending of Freight Documents

[GRABLERE]

Introduction

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 is due to changes happening to the document after the previous Transportation Request was sent to the carrier. This way the system protects you from having a mismatch in what is confirmed in your system vs what the transportation service provider thought he agreed to when sending his confirmation, as this would lead in a minor case to a financial dispute in the worst case to your customer showing up at the wrong side trying to pickup someething that wasn't planned to be shipped anymore after all.

Status - Changed After Sending

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.

Filter Criteria - Changed after Sending

This enables the user to effectively monitor and manually recommunicate changed documents en masse.

Worklist - Changed after Sending

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.

Chaco Method to Send Freight Order

Chaco Strategy - Method Assignment

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.

Chaco Condition to Send Freight Order

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.

Data Access Definition - Subcontracting Changes

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

BADI to modify identified 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.

Freight Order Batch Report

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.

Selection Profile - Freight Orders changed after sending

Summary

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.