SAP TM – How to Create a New Calculation Base (Data Access) to Use the SOURCE in Price Determination (Charge Management) – Luis Tacioli

Table of Contents

Context

Pricing freight agreements in SAP Transportation Management (TM) often relies on the combination “Origin × Final Destination.” In day‑to‑day planning, however, many businesses operate a “star” model – a fixed origin such as a distribution center serving multiple variable destinations. The standard TM cockpit doesn’t support this model. In a linear stage flow the origin passed to the pricing engine is treated as the destination of the previous stage, which distorts the calculation base and leads to incorrect pricing.

This article shows how to build a custom calculation base (data access) that retrieves the correct origin directly from the pricing request, bypassing the standard behaviour and enabling freight tables based on that origin (and optionally on the origin city). The solution is simple, robust and doesn’t break existing processes.

Solution Strategy

Create new custom calculation bases by copying SAP standard classes and altering only the logic that supplies the ID used during scale look‑up:

Z_SOURCE_BASE – copy of /SCMTMS/CL_TCC_CB_LOCATION_ID. Instead of accepting the “wrong” location derived from the linear flow, inject the LOCID of the actual origin already available in the IT_REQUEST.
Z_SOURCE_CITY (optional) – copy of /SCMTMS/CL_TCC_CB_SRCLOC_CITY. Adjust the source ID to read the city of the origin from the same request.

With these custom bases you can maintain freight scale tables consistent with the star model and create price tables by origin (and, if necessary, by origin city).

Technical Implementation (ABAP + Customizing)

Copy the base classes and adjust the logic:

For the origin (LOCID), copy /SCMTMS/CL_TCC_CB_LOCATION_ID to ZCL_TCC_CB_LOCATION_ID.
For the origin city, copy /SCMTMS/CL_TCC_CB_SRCLOC_CITY to ZCL_TCC_CB_SRCLOC_CITY. In the custom class it isn’t enough to change <cb_value>-qty_value_char = <loc>-id. You must enforce the raw/ID values used for scale resolution. When CT_CALC_BASE_VALUES[1]-CALC_BASE_KEY-CALC_BASE_NAME = 'Z_SOURCE_BASE' (you can parameterize this for multiple names) update:
<cb_value>-qty_value_raw at the item level, or
it_calc_base_keys[1]-res_base_key-res_base_id at the higher level. The origin LOCID is available in IT_REQUEST, so assign it directly to the RAW/ID that feeds the table look‑up. This ensures the key used in the freight table represents the correct origin rather than the destination of the previous stage.

Create the calculation bases in customizing:
Navigate to SPRO → Transportation Management → Charge Management → Master Data → Define Calculation Bases.

Create Z_SOURCE_BASE pointing to class ZCL_TCC_CB_LOCATION_ID.
Optionally create Z_SOURCE_CITY pointing to class ZCL_TCC_CB_SRCLOC_CITY.
Define the attributes (format, value type, domain) according to the ID/city you want to use in your tables.

Build a freight table based on the new base:
Create a new scale table (for example, PRICE_TABLE_ORIGIN) where the first key is Z_SOURCE_BASE. If you use the origin city, add Z_SOURCE_CITY as an additional key. Other dimensions such as destination, mode, product or weight range can remain as usual.
Integrate into the calculation sheet:
In your charge calculation sheet, replace the old base that read the “wrong” origin with Z_SOURCE_BASE. Update the rate steps to reference the new PRICE_TABLE_ORIGIN. Adjust the related condition tables if necessary.

Directed Tests

To validate the solution:

Linear flow with multiple stages – Check that the look‑up now uses the correct origin LOCID rather than the destination of the previous stage.
Star model (fixed origin, variable destinations) – Ensure the same origin drives the correct price for all destinations.
Multiple destinations/consolidations – Confirm that the custom base is not overwritten by another calculation base during pricing.
Fallbacks – Decide what happens if the origin LOCID is missing in the request. You can either log an explicit error in pricing or configure a fallback (not recommended).
Performance – Custom bases should access only the request; avoid expensive database or RFC reads inside the calculation base.

Best Practices and Pitfalls

Name and document your custom bases with functional and technical descriptions.
Parameterize the calculation base name to allow reuse.
Keep the RAW/ID coherent – that’s the key actually used to index the scale table.
Transport the new bases, tables and calculation sheet together.
Validate existing agreements to ensure nothing outside the scope changes.

Example

After creating Z_SOURCE_BASE and the table PRICE_TABLE_ORIGIN, adjust the rate steps to first look up by Z_SOURCE_BASE (origin) and then by final destination. Re‑run pricing: the results now match the expected price matrix for the star model.

Conclusion

By introducing a custom calculation base focused on the real origin of the shipment, you remove the ambiguity inherent in linear flows and regain control over pricing. The approach leverages standard charge management architecture, remains transparent to users and preserves all existing components of your calculation scheme.