Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
cancel
Showing results for 
Search instead for 
Did you mean: 
Tobias_Berger
Advisor
Advisor

Context and Requirement


As architect in planning team, I often hear statements about “the” context determination. Sadly this is rather nonspecific as TM has a bunch of different context determinations for other purposes, e.g. the context determination before starting the VSR optimizer (see also this blog of mine: here), the context determination for scheduling etc.. Most of the context determinations in TM are technically and cannot therefore not be deactivated by customizing.

The context determination I want to talk about today is the so called “Context Determination for Res. and Docs [for the transportation cockpit selection]” which you can find in the transportation cockpit settings of the planning profile (respectively on the planning profile in older releases).

As you can find it in the settings you for sure can activate or deactivate this one depending to your needs.

The main requirement which lead to the development of this feature was the introduction of the Gantt chart. Working with the Gantt chart a planner needs to see every freight order for the resources he/she is working on in the session. Otherwise, the Gantt chart would show gaps on the timestream even if there are “hidden” not-loaded freight orders.


Activation of Context Determination in the Transportation Cockpit Settings



The Feature


So, the context determination was introduced to give a planner a full view on the resources in the session. Basically, the logic works like that:

  1. For each freight order and transportation unit in the user selection the resources caring them are determined.

  2. For each resource in the user selection or found from step 1 all freight orders or transportation units inside of the planning horizon are determined.

  3. For all freight orders in the user selection or found from step 2 the drivers are determined

  4. For all drivers in the user selection or found from step 3 the freight orders are determined

  5. For all capacity documents in the user selection or found in previous steps the first lower assigned transportation unit level is determined (e.g., for a freight order directly assigned trailer units will get determined)

  6. For all requirement documents in the user selection or found in previous steps the first higher capacity document level is determined



Context Determination Step 1 and 2


With that logic you can ensure e.g.:

  • For a selected freight document, you will have the currently assigned resource in the session

  • For a selected resource, you will have all freight orders assigned to it in the session


This turns out especially valuable working with single resources or the Gantt chart as the planner get a full view on the used resources.

As the logic is not recursive but runs through once you can only be sure that you see the whole picture for the initial selected objects as it could be for example that you enter with one FO selected, the resource is found in step 1, all other FOs on the resource are found in step 2 and assigned trailer units are determined in step 5; in this example you will not see the resources for the trailer units. Anyways for all resources you can see a clear/full picture.

For performance reasons at time being SAP is not offering a determination of freight units yet (heard this requirement from one customer yet).

With S4HANA 2022 the logic was extended by a (separately controlled) determination of default drivers for resources and default resources for drivers which is done before the other steps described above are executed.

Technical Insides


The New Structure


Now let’s talk about the technical part, which is the interesting one from an architect’s point of view. With the introduction of the new feature in 2022 the code was refactored to meet a modern style of coding.

In older releases you can find the code in class /SCMTMS/CL_PROF_ACC => READ_CONTEXT_­DATA and below methods which basically calling the sequence as described above in a static manner in long, hard to read and understand methods. There was no separation of concerns, certain code was duplicated (e.g. for different resource types) and the responsibilities of methods were unclear.

In the newer release this totally changed. The transportation cockpit context determination was moved to an own package /SCMTMS/PLN_TBO_CD consisting of about 20 classes with dedicated responsibly.

Basically, each step above got an own class taking care of only this particular context determination (there are even more classes as e.g. step 2 “determining context for resources” is translated into three steps “determining context for trucks trailers and containers”).

The steps are all implementing the same interface /SCMTMS/IF_PLN_TBO_CD_STEP which offers a context determination based on a harmonized input and output table (offering all needed tables).


New Controller for Context Determination Executes Steps Independent On the Sequence


For a further harmonization there is a super class /SCMTMS/CL_PLN_TBO_CD_STP_SUPR which is defining a template method (maybe I will talk a little about design patterns in my next blog…). Further inheritance is enabling re-use of common code (e.g. for different resource categories).

The sequence of the steps is now no longer hard coded, but there is a sequence controller (/SCMTMS/CL_PLN_TBO_CD_SEQ_CONT) which is returning a table of context determination step classes to be executed in the sequence of the table.

For debugging reasons there is an explanation class which can be activated via user parameter /SCMTMS/TBO_CD_EXP. The explanation instance collects in- and output of all steps (and highlights which step determined new data). It can only be viewed in debugger only (there is no explanation log or tool planned yet).

Opportunities, Conclusion and Outlook


With the new structure the context determination can be changed or enhanced very easily as the sequence is controlled only via an internal table to be filled. If you need you can add new steps or exchanging existing once with implementing own steps using /SCMTMS/IF_PLN_TBO_CD_STEP and overwrite the sequence controller using the new enhancement concept (you can find information here).

In future SAP might foresee further steps like “determine all freight units for capacity documents” and create a customizing for the overall sequence rather than controlling the sequence hard-coded.

Let me know in case you would see the need for a customizing (e.g. to skip certain steps for certain planning profiles only) and whether you miss steps standard should offer from your perspective.