One FO for each DTR

[Former Member]

Dear Gurus,

Our client has a very specific requirement. They want a 1:1 relationship between Freight Order and DTR even if the vehicle has spare capacity and even if multiple DTRs are created with same Pick-up & Delivery locations with same Pick-up and Delivery dates for the same Customer. In other words, client does not want any consolidation of DTRs for creating Freight Orders during automatic planning by VSR optimizer. Could you please advise how this can be achieved during Optimizer based automatic planning  by standards (without any enhancement)

Regards

Dipankar

[former_member203115]

Hi, Dipankar

We implemented the "like" values incompatibility as Jonathan suggested at a prior client and it worked perfectly.  If you don't want the planners to override this solution then you can exclude the FU from their cockpits.  In our case the planning for this DTR type was executed automatically by the planning batch job.  No issues whatsoever.

Mac McLarin

[Bimal_S]

Hi Dipankar,

In such situations we usually do not create a FU. From FUBR we create FO directly. Is this suitable for your business scenario?

From

Bimal

[former_member1124846]

Dipankar,

Incompatibilities is one option however there is an easier way. SAP provided standard FUBR methods that would create exactly one FO per FU. However your requirement is to do it at a DTR level. This is also possible with the following two steps.

1. Ensure FUBR has a large split quantity and use the option 'consolidate by request'. This will ensure one DTR always creates one FU.
2. Create a new FUBR strategy with the following methods in this order - FUB_PRE, FUB_AUTO, FUB_POST and FUB_PLAN_U.

FUB_PLAN_U is the key method. If you do the above, for each delivery you will see one DTR, one FU and one FO.

Best Regards,

KC

[Former Member]

Hi, Krishna - we are trying this "new" method FUB_PLAN_U and it seems to work ok.  The only problem is that it always seems to use the default FO type as the corresponding FO rather than the FO type we specify in the FU configuration.  I just generated an OSS message to SAP asking if this is a bug.  Did you run into this problem?  We are on TM 9.1 SP05

Mac McLarin

[Former Member]

Dear Krishna and Mac,

Thanks for all the insights. However, our requirement is not exactly one FU per DTR. It is rather one FO per DTR. This means we may have many FU-s (say, many pallets) in the DTR but they should go into one FO. This FO should not consolidate FU-s from another DTR even if the vehicle may have spare space. On the contrary if the FU-s from one DTR exceeds the capacity of the vehicle, then another FO should be created

Hope this clarifies the requirement

Regards

Dipankar

[former_member1124846]

Dipankar,

There is another standard method FUB_PLAN that can create FOs by consolidating FUs however the basis for consolidation in standard TM may not be DTR. So you could copy this method and create a custom one while modifying just the consolidation basis.

Best Regards,

KC

[Former Member]

Dear Krishna,

Thanks again for your prompt reply. Our client is a bit averse to custom developments and need to get a standard SAP TM solution for this requirement

Many thanks if something by standard may be suggested

Regards

Dipankar

[former_member1124846]

Mac,

This method calls a standard action (AUTOPLAN_STAGE) which is probably not designed to consider the FO type specified on FU type customizing. We used it at a client on TM 9.1. SP05 but we used it for Rail where there was only one default FO type.

Another option you could try is to specify a 'planning profile' on OTR / DTR type customizing which can also drive the FO type. I'm not sure if the standard action would respect this nor do I remember if this option is available in TM 9.1 (it is in 9.3).

In any case I believe SAP should improve the standard action to prioritize the FU type customizing above the default type. May be you can request them for a fix.

Best Regards,

KC

[Former Member]

Krishna - you know that planning profile idea seems to have worked.  Still think there is a bug but that is a great fallback option.  Thanks for the suggestion

[Former Member]

We have achieved this using an incompatibility at the freight unit level as we create 1 FU per DTR, though there may be other ways.

Condition setup:

Create a data access definition for the TOR object, Root node, field name TOR_ID

Create a condition of type /SCMTMS/INC_FU referencing the data access definition you have specified.

Incompatibility setup:

Incompatibility area 01 (or whatever you need it to be)

Incompatibility type 01 (FU-FU at vehicle level)

Determination method: Condition-based

Identical values only: Checked

First condition: the condition you created above

Second condition:  Blank

Make sure this incompatibility is set to be used during your optimization by adding it to the planning profile.

[Former Member]

Dear Jonathan,

Many thanks for the hints. I am interested to know if this Incompatibility will stop the Planner if he/she in exceptional cases manually wants to shift FU-s from one FO to another FO which would mean a combination of more DTR-s into one FO to be performed manually in planning cockpit in exceptional cases

Regards

Dipankar

[Former Member]

Dipankar,

Incompatibilities are designed to be able to support different reactions when called automatically and manually.  In our case, we set the field Automatic Violation to "Incompatibility Must Not Be Violated", meaning that when the incompatibility is called in the background it will never be violated, but we have set the field Manual Violation to "Warning If Incompatibility Is Violated".  In this setup, a user will receive a warning (yellow text) if their actions, such as adding a second FU to an FOR, violate the incompatibility, but the system will not prevent the user from moving forward/saving.

You can read more about incompatibilities in section 9.1.5 of the TM 9.3 SP03 help guide linked on the main page of the TM SCN site.

-J