In the following you find parts of the SDD for refactoring authorizations

in TM in SAP S/4HANA (Release 1709). In later releases, some further

authorization objects were introduced for new use cases. Please check
the documentation of the specific authorization objects directly and
check the What's New section in the release notes for Transportation
Management in SAP S/4HANA.

Changes to Authorization Objects

SAP TM 9.5 has 69 authorization objects, contained in object class SCTS. Not all of these objects are
still used, and several of them are defined in a suboptimal way.
Remark: With SAP TM in S/4, there is the chance to get rid of the obsolete objects, and to bring all
objects into a good shape. Due to compatibility reasons, the changes and the deletion of authorization
objects cannot be down-ported to SAP TM 9.5. So, independent from the decision to down-port the
development of this design document to SAP TM 9.5, or not, the content of this sub chapter will not be
part of it.
In this chapter, first all authorization objects are shortly discussed and classified (to be ok, to be
deleted, or to be optimized). For all objects to be optimized, an improved design is proposed.
In general, SAP TM is using Authorization Objects in static, explicit calls (as usual), or dynamically via
BO authorization check classes. Statically called authorization objects can be found with a Where-
Used-Check of the Authorization Object Maintenance (SU21). For dynamic usage, the BO specific
SAP TM authorization check classes need to be checked. For this, program ZDS_SU21TMCHECK can
be used in system ER9. It is checking the usage of Authorization Objects in any of the SAP TM BO
specific authorization check classes, entered in system table /SCMTMS/I_OBM_BO, field
AUTHCHK_CLASS.
Objects which are not used at all, will be removed from SAP S/4HANA TM.
All other objects are discussed in detail in the following sub chapters.
A summary of all authorization objects and the general actions, which will performed for them, is listed
in the following table:

Authorization Object Description Action

T_EXP_USR Authorization for Explanation Tool Based on User OK
T_BW_INIT BW Initialization OK
T_COND Condition Definition OK
T_LAYOUT Page Layouts for Transportation Cockpit OK
T_BO Static Check on BO Name OK
T_TRANSLOC Trans-shipment Location assignment OK
T_INS Instructions OK
T_AGR_QUOT Forwarding Agreement Quotation New
T_PL_SETS Profile and Layout Sets New
T_TCFAGSP Service product To be
--> T_AGR_SPC optimized

T_WBPRCHSE Way bill purchase To be

--> T_WB_PUR optimized
T_WBSALES Way bill sales To be
--> T_WB_SLS optimized

T_ADMIN Authorizations for administrative settings To be

optimized
T_TCFA_OBP Freight Agreement To be
--> T_AGR_FR optimized

T_TCFW_OBP Forwarding Agreement To be

--> T_AGR_FW optimized

T_TCIN_OBP Internal Agreement To be

--> T_AGR_INT optimized

T_TCMU_OBP Mutual Agreement To be

--> T_AGR_MUT optimized

T_RFQ_FA Freight Agreement RFQ To be

--> T_AGR_RFQ optimized

T_TCCALCSH Calculation Sheet To be

--> T_CALCSH optimized

T_PRFDLVID Delivery profile ID To be

--> T_PRF_DLV optimized

T_TRQ_DTR Delivery-based Transportation Requirement Based on To be

--> T_TR_DTR Type optimized

T_TR_FWOF2 Forwarding Order Based on Functions (ext. [Link]) To be

--> T_TR_FWOF optimized

T_TRQ_FWO Forwarding Order Based on Type To be

--> T_TR_FWO optimized

T_TRQ_FWQ Forwarding Quotation Based on Type To be

--> T_TR_FWQ optimized

T_CF_TYPE Forwarding Settlement Document Type To be

--> T_SD_FWSD optimized

T_SF_TYPE Freight Settlement Document Type To be

--> T_SD_FSD optimized

T_FUBRID Freight Unit Building Rule ID To be

--> T_FUBRULE optimized

T_PRFINCID Incompatibility Profile ID To be

--> T_PRF_INC optimized

T_TRQ_OTR Order-based Transportation Requirement Based on Type To be

--> T_TR_OTR optimized

T_PRFOPPID Planning profile ID To be

--> T_PRF_PLN optimized

T_TCRATE Rate Table To be

--> T_RATE optimized
T_TCSCALE Scale To be
--> T_SCALE optimized

T_SCHCAT Schedule Category To be

--> T_SCHEDULE optimized

T_PRFSELID Selection Profile ID To be

--> T_PRF_SEL optimized

T_TEND_PRF Tendering Profile To be

--> T_PRF_TEND optimized

T_TDLID Trade Lane ID To be

--> T_TDL optimized

T_TOR_XEG Transp. Order Based on Planning & Exec. Group To be

--> T_TOR_EXE ([Link]) optimized

T_TOR_XPG Transportation Order Based on Purchasing Group To be

--> T_TOR_PUR ([Link]) optimized

T_BUSID Business Share ID To be

--> T_BUSSHARE optimized

T_TALID Transportation Allocation ID To be

--> T_TAL optimized

T_CP_ADM Administration authorization of TM collaboration portal To be

Deprecated
T_TM_ALL TM All Authorizations To be
Deprecated
T_DLVP ERP Delivery Proposal To be
Deprecated
T_PRF_CR Create TM planning or selection profiles To be
Deprecated
T_TR_DTRF2 Delivery-based Transp. Requ. Based on Function (ext. To be
[Link]) Deprecated
T_TR_FWQF2 Forwarding Quotation Based on Functions (ext. [Link]) To be
Deprecated
T_CF_CAT Forwarding Settlement Document Category To be
Deprecated
T_CF_FUNC Forwarding Settlement Document Function (Obsolete) To be
Deprecated
T_SF_CAT Freight Settlement Document Category To be
Deprecated
T_SF_FUNC Freight Settlement Document Function (Obsolete) To be
Deprecated
T_TR_OTRF2 Order-based Transp. Request Based On Function (ext. To be
[Link]) Deprecated
T_SLS_XORG Organization Unit: Sales (ext. [Link]) To be
Deprecated
T_PLN_XORG Organizational Unit: Execution and Planning (ext. [Link]) To be
Deprecated
 T_PUR_XORG Organizational Unit: Purchasing ([Link]) To be
Deprecated
T_RESP_P Responsible Person To be
Deprecated
T_SCHID Schedule ID To be
Deprecated
T_BOACTION Static Check on BO Action Name To be
Deprecated
T_BONODE Static Check on BO Node Name To be
Deprecated
T_BUPA_ID TM Business Partner ID To be
Deprecated
T_TCTARIFF Transportation Charges: Tariff To be
Deprecated
T_TORACT Transportation Order Action To be
Deprecated
T_TOR_MOT Transportation Order Based on Mode of Transportation To be
Deprecated
T_TOR_RP Transportation Order Based on Responsible Person To be
Deprecated
T_TOR_OT Transportation Order Based on Type To be
Deprecated
T_TORNODE Transportation Order Node To be
Deprecated
T_TRQ_DLOC Transportation Request Based on Destination Location To be
Deprecated
T_TRQ_MOT Transportation Request Based on Mode of Transport To be
Deprecated
T_TRQ_XSO Transportation Request Based on Sales Org. ([Link]) To be
Deprecated
T_TRQ_SLOC Transportation Request Based on Source Location To be
Deprecated
T_RATEAPPR Reference Rate Table Used in Agreement To be
Deprecated
T_TCFAG Agreement To be
Deprecated
Finally, in S/4HANA TM 31 of 69 authorization objects will be deprecated, 31 objects will be replaced
by new S/4HANAobjects and then deprecated, and the remaining 7 objects will stay unchanged. One
authorization object is created new.
Changed objects in SAP S/4HANA
When designing authorization objects, the general question is, how customers will be able to define
and maintain user authorizations on basis of the provided objects, and if it can be reached what was
intended by our design.
Typically, there are two ways, how authorization objects can be designed for one area (business
object):
1. Many authorization objects with only few fields.
2. Few authorization objects with many fields.
The Activity field ACTVT is mandatory for SAP TM BO authorization objects.
In the first case (many objects with few fields), you have the problem, that you can’t define
dependencies between the authorizations. As example, you could have one objects for document
categories, and another one for types. With such objects you are not able to express, that a user is
allowed to work with category 01, types 0001 – 0003, and category 02, type 0005. You can only
express that a user is allowed to work with categories 01 and 02, and types 0001-0003 and 0005. As
soon as you can have similar types for different categories, you can’t differentiate. On the other hand,
you have a quite compact maintenance.
In the second case, the differentiation is quite good possible, but it can happen, that you have a lot of
effort to specify the authorization profile right. Extending the previous example, there might be a user
working with 5 document categories. For this user you would have to define 5 different patterns for the
authorization object in the authorization profile: One pattern per document category. With every
authorization field you need to specify additionally, the combinatorics increase. But, despite of the
potentially large number of authorization definitions in the authorization profiles, this approach is much
clearer than the first one. You define exactly, what the user shall be allowed for.
That is why in S/4HANA TM the design of authorization objects goes more into the direction of less,
but larger authorization objects.

General Objects:
• T_ADMIN: This object is used in context of SAP TM STAD Trace. It is called in includes of
report /SCMTMS/TM_TRACE. In S/4HANA TM it will also be used to deactivate the TM own
authorization checks for non-dialog users, and to provide additional options e.g. on batch job
selection screens. For that, the list of allowed ACTVT codes (36 – Extended Maintenance,
A3 – Change Status) will be extended with code H1 (Deactivate).

Contracts Master:
In the area of contract master, the following authorization objects are defined, which shall be adapted
in S/4HANA TM:
• T_TCSCALE: This object is used in context of SAP TM Charge Master. It is called dynamically,
as instance based authorization check, defining the way a user is allowed to use an instance
of a scale.

For Scale objects it is the general question, if it is not sufficient for SAP TM standard, to do
only static authorization checks for Display, Create, Update, Delete, and Execute.
The check today is just based on Scale ID (/SCMTMS/SD), which is hard to handle for
customers, and the Scale Base (/SCMTMS/SB), which is a kind of domain for scales.
 Both fields do not help customers to define a good authorization concept for Scale Master. So,
both can be skipped in S/4HANA TM.
In S/4HANA TM Scales will only be checked statically, on the ACTVT code, and the object will
be created in S/4HANAas T_SCALE.
Authorization Field Description
ACTVT Activity

• T_TCRATE: This object is used in context of SAP TM Charge Master. It is called dynamically,
as instance based authorization check, defining the way a user is allowed to use an instance
of a rate table.

The check today is based on Rate Table ID (/SCMTMS/RD), which is hard to handle for
customers, the Charge Element Type (/SCMTMS/TE), and the Charge Usage Code
(/SCMTMS/TC).
In S/4HANA TM, the authorization field /SCMTMS/RD for Rate Table ID will be removed from
the authorization object, and it will be created in S/4HANAas T_RATE. Finally, the object looks
as follows (agreed by Saurav Das):
Authorization Field Description
ACTVT Activity
TM_XSORG Sales Organization
TM_XPORG Purchase Organization
/SCMTMS/TE Charge Type
/SCMTMS/TC Usage Type
/SCMTMS/RT Rate Type

• T_TCCALCSH: This object is used in context of SAP TM Charge Master. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of a calculation sheet.

The check today is based on Calculation Sheet ID (/SCMTMS/TI), which is hard to handle for
customers, the Charge Usage Code (/SCMTMS/TC).
In S/4HANA TM, the authorization field /SCMTMS/TI for Rate Table ID will be removed from
the authorization object T_TCCALCSH, and it will be created in S/4HANAas T_CALCSH.
Authorization Field Description
ACTVT Activity
 /SCMTMS/TC Usage Type

• T_TCFA_OBP: This object is used in context of SAP TM Contracts Master. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of a freight agreement, depending on the purchasing organization and business
partner.

The object will be created as object T_AGR_FR, and extended as follows:

Authorization Field Description
ACTVT Activity
TM_XPORG Purchase Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number

• T_TCFW_OBP: This object is used in context of SAP TM Contracts Master. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of a forwarding agreement, depending on the sales organization and business
partner.

The object will be created as object T_AGR_FW, and extended as follows:

Authorization Field Description
ACTVT Activity
TM_XSORG Sales Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number

• T_TCIN_OBP: This object is used in context of SAP TM Contracts Master. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of an internal agreement, depending on the sales or purchasing organization and
the business partner.
 The object will be created in S/4HANAas T_AGR_INT, and be extended as follows:
Authorization Field Description
ACTVT Activity
TM_XSORG Sales Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number
/SCMTMS/TC Charge Usage
• T_TCMU_OBP: This object is used in context of SAP TM Contracts Master. It is called
dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of a mutual agreement, depending on the sales or purchasing organization and
the business partner.

The object will be created as object T_AGR_MUT, and extended as follows:

Authorization Field Description
ACTVT Activity
TM_XSORG Sales Organization
TM_XPORG Purchase Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number
• T_RFQ_FA: This object is used in context of SAP TM Contracts Master. It is called dynamically
as instance based authorization check, defining the way a user is allowed to use an instance
of a freight agreement RFQ, depending on the purchase organization and business partner.

The object will be created as object T_AGR_RFQ, and extended as follows:

Authorization Field Description
ACTVT Activity
 TM_XPORG Purchase Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number

• T_AGR_QUOT: This object is used in context of SAP TM Contracts Master. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
an instance of a Forwarding Agreement Quotation, depending on the sales organization and
business partner.
Authorization Field Description
ACTVT Activity
TM_XSORG Sales Organization
TM_FAGTY Agreement Type
TM_BPID Business Partner Number
The list of allowed activities corresponds to T_AGR_RFQ.

Profiles:
• T_PRF_CR, T_PRFDLVID, T_FUBRID, T_PRFINCID , T_PRFOPPID, T_PRFSELID:
These objects are used in context with SAP TM profiles. T_PRF_CR is used only before a
profile is created new, with a static check on the ACTVT code for Creation (01).

The other objects are called dynamically as instance based authorization check, defining the
way how a user is allowed to use profile instances. The checks as of today are based on
profile ID, which is hard to handle for customers, and the ACTVT code.

In S/4HANA TM the object T_PRF_CR will be deprecated.

The other objects will be changed as follows:

For T_PRFOPPID field TM_PRFOPID will be removed. Instead, field TM_AUTHCTX will be
added. In addition, the new BO node AUTH_CONTEXT with data type
/SCMTMS/S_AUTH_CONTEXT_K, table type /SCMTMS/T_AUTH_CONTEXT_K, and db table
/SCMTMS/D_ACCTX needs to be added to the following BOs:
• /SCMTMS/VSR_CAPA_SEL_PROF
• /SCMTMS/VSR_LOAD_COST_FUNCTION
• /SCMTMS/VSR_OPT_PLANCOSTS
• /SCMTMS/VSR_PLANNING_PROFILE
 • /SCMTMS/VSR_OPT_SETTING_PROF
• /SCMTMS/VSR_SCHED_PROFILE
• /SCMTMS/VSR_MP_SETTINGS
In S/4HANAthe object is created as T_PRF_PLN.

For T_PRFSELID field TM_PRFSLID will be removed. Instead, field TM_AUTHCTX will be
added. In addition, the new BO node AUTH_CONTEXT with data type
/SCMTMS/S_AUTH_CONTEXT_K, table type /SCMTMS/T_AUTH_CONTEXT_K, and db table
/SCMTMS/D_ACCTX needs to be added to the following BOs:
• /SCMTMS/VSR_SEL_DEMAND_HORIZON
• /SCMTMS/VSR_SEL_LOCATION_PROF
• /SCMTMS/VSR_SEL_FILTER_PROF
• /SCMTMS/VSR_SELECTION_PROFILE
In S/4HANAthe object is created as T_PRF_SEL.

For T_PRFDLVID field TM_PRFDLVID will be removed. Instead, field TM_AUTHCTX will be
added. In addition, business object /SCMTMS/DELIVERY_PROFILE needs to be extended
with the new BO node AUTH_CONTEXT with data type /SCMTMS/S_AUTH_CONTEXT_K, table
type /SCMTMS/T_AUTH_CONTEXT_K, and db table /SCMTMS/D_ACCTX.
In S/4HANAthe object is created as T_PRF_DLV.
For T_FUBRID field TM_FUBRID will be removed. Instead, field TM_AUTHCTX will be added. In
addition, business object /SCMTMS/FUB_RULE needs to be extended with the new BO node
AUTH_CONTEXT with data type /SCMTMS/S_AUTH_CONTEXT_K, table type
/SCMTMS/T_AUTH_CONTEXT_K, and db table /SCMTMS/D_ACCTX.
The object is created in S/4HANAas T_FUBRULE.

For T_PRFINCID field TM_PRFINID will be removed. Instead, field TM_AUTHCTX will be
added. In addition, the new BO node AUTH_CONTEXT with data type
/SCMTMS/S_AUTH_CONTEXT_K, table type /SCMTMS/T_AUTH_CONTEXT_K, and db table
/SCMTMS/D_ACCTX needs to be added to the following BOs:
• /SCMTMS/INCOMPAT_DEFINITION
• /SCMTMS/INCOMP_SETTINGS
For all objects, the new org. unit assignment can be maintained optionally at runtime, to
restrict the usage of profiles. Profiles without assignment are not restricted, and can be
displayed or maintained (create, update, delete) by any users having authorization to maintain
any profile.
The creation of a new profile is checked in general only against the ACTVT code for creation
(01). A more detailed check might be performed, as soon org. unit information is added to a
profile.

• T_TEND_PRF: This authorization object is used in context of Tendering. It is called

dynamically as instance based authorization check, defining the way a user is allowed to use
Tendering Templates (or Tendering Profiles).
 The check today is based on the Tendering Template ID (TM_TP_ID), which is hard to handle
for customers, and the ACTVT code.
In S/4HANA TM, the authorization field TM_TP_ID for the Tendering Template ID will be
removed from the authorization object T_TEND_PRF. The authorization check is then just
executed as static check on the ACTVT code field.
In S/4HANAthe object will be created as T_PRF_TEND.

• T_PRF_DCA: This object is newly introduced for Decreasing Capacity Profiles. It just contains
the activity field with values for
o Create
o Update
o Delete
o Execute

Transportation Planning and Network:

• T_TDLID: This object is used in context of SAP TM Transportation Planning and Network. It is
called dynamically as instance based authorization check, defining the way a user is allowed to
use the data of trade lane.

The check today is based on the Trade Lane ID (TM_TDLID), which is hard to handle for
customers.
In S/4HANA TM, the authorization field TM_TDLID for Trade Lane ID will be removed from the
authorization object T_TDLID. The new authorization fields TM_TDLCAT and TM_TDLTYPE
will be added, instead. That means: In S/4HANA TM it will be possible to define authorizations
for trade lanes on basis of trade lane categories and types, and the ACTVT code field (Display,
Create, Update, Delete).

Authorization Field Description

ACTVT Activity
TM_TDLCAT Trade Lane Category
TM_TDLTYPE Trade Lane Type
In S/4HANAthe object is created as T_TDL.
• T_SCHCAT: This object is used in context of SAP TM Transportation Planning and Network. It
is called dynamically as instance based authorization check, defining the way a user is allowed
to use the data of schedule.

Today, there is another authorization object T_SCHID in place, containing a check on

schedule ID and ACTVT code. This object will be eliminated in S/4HANA TM.
To make authorization checks for schedules more fine granular, another authorization field
TM_SCHTYPE will be added to T_SCHCAT.

Authorization Field Description

ACTVT Activity
TM_SCHCAT Schedule category
TM_SCHTYPE Schedule Type
The object will be created in S/4HANAas T_SCHEDULE.

• T_BUSID: Authorization object for /SCMTMS/BUS_SHARE based on business share ID

The check today is based on the Business Share ID (TM_BUSID), which is hard to handle for
customers.
In S/4HANA TM, the authorization field TM_BUSID for Business Share ID will be removed
from the authorization object T_BUSID. The decision for now is, to have only the ACTVT field,
and to create the authorization object in S/4HANAas T_BUSSHARE. With this, it is possible to
restrict read (display) and change (create, update, delete) access to business share objects in
general. In S/4HANA TM standard, no more fine granular differentiation is foreseen.

Authorization Field Description

ACTVT Activity
The object is created in S/4HANAas T_BUSSHARE.

• T_TALID: Authorization object for /SCMTMSTRALLOOC based on transportation allocation ID

 The check today is based on the Allocation ID (TM_TALID), which is hard to handle for
customers.
In S/4HANA TM the authorization field TM_TALID for Allocation ID will be removed from the
authorization object T_TALID. Instead, the new authorization field TM_TALTYPE will be
added. That means: In S/4HANA TM it will be possible to define authorizations for allocations
on basis of allocation types, and the ACTVT code field (Display, Create, Update, Delete).

Authorization Field Description

ACTVT Activity
TM_TALTYPE Allocation Type
The object will be created in S/4HANAas T_TAL.

Settlement Management:
• The three authorization objects T_CF_CAT, T_SLS_XORG, and T_CF_TYPE will be
consolidated into authorization object T_CF_TYPE. The objects are described in detail in the
next chapter 0, section Settlement Management.
The final authorization object T_SD_FWSD will look like this:

Authorization Field Description

ACTVT Activity
TM_CF_CAT Document Category
TM_CF_TYPE Document Type
TM_XSORG Sales Organization External ID
TM_XSOFF Sales Office External ID
TM_XSGRP Sales Group External ID
Permitted Activities will remain unchanged.

• The three authorization objects T_SF_CAT, T_PUR_XORG, and T_SF_TYPE will be

consolidated into authorization object T_SF_TYPE. The objects are described in detail in the
next chapter 0, section Settlement Management.
The final authorization object T_SD_FSD will look like this:

Authorization Field Description

ACTVT Activity
TM_SF_CAT Document Category
TM_SF_TYPE Document Type
TM_XPORG Purchase Organization External ID
TM_XPGRP Purchase Group External ID
Permitted Activities will remain unchanged.
Forwarding Management and Transportation Requirements:
In the area of forwarding order management and transportation requirements the following
authorization objects are defined, which will be adapted in S/4HANA TM:
• T_TRQ_DTR: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of delivery-based transportation
requirement, depending on the type of the transportation requirement.

The object is created in S/4HANAas T_TR_DTR.

• T_TRQ_OTR: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of order-based transportation
requirement, depending on the type of the transportation requirement.

The object is created in S/4HANAas T_TR_OTR.

• T_TRQ_FWO: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of forwarding order, depending on the
type of the forwarding order.
 The object is created in S/4HANAas T_TR_FWO.

• T_TRQ_FWQ: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of forwarding quotation, depending on
the type of the forwarding quotation.

The object is created in S/4HANAas T_TR_FWQ.

• T_TRQ_MOT: Find details in chapter 0, Forwarding Management and Transportation

Requirements.

• T_TRQ_XSO: Find details in chapter 0, Forwarding Management and Transportation

Requirements.

• T_TR_FWOF2: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is permitted to execute specific functions within a forwarding order,
depending on the forwarding order type, external sales organization ID, external sales office
ID, or external sales group ID.

The object is created in S/4HANAas T_TR_FWOF.

The authorization objects T_TRQ_DTR, T_TRQ_OTR, T_TRQ_FWO, and T_TRQ_FWQ will be extended
with the fields from objects T_TRQ_MOT and T_TRQ_XSO. As example for all others, T_TRQ_DTR will
look as shown in the following table:

Authorization Field Description

ACTVT Activity
TM_DTRTYPE DTr Document Type
TM_MOT Transportation Mode
TM_XSORG Sales Organization External ID
 TM_XSOFF Sales Office External ID
TM_XSGRP Sales Group External ID
As described in the next chapter (0), objects T_TRQ_MOT and T_TRQ_XSO will be deleted in S/4.
Authorization object T_TR_FWOF2 is used for authorization checks for some special BO actions for
forwarding orders. All fields but TM_FWOFUNC are already covered by the standard authorization object
T_TRQ_FWO. That is why all duplicate fields are removed from the object, leaving it in S/4HANA TM as
shown in the following table:

Authorization Field Description

ACTVT Activity
TM_FWOFUNC or Forwarding Order Function
BO_SERVICE
In S/4HANAthe object is created as T_TR_FWOF.

Freight Order Management and Planning:

In the area of freight order management the following authorization objects are defined, which will be
adapted in S/4HANA TM:
• T_TOR_XEG: This object is used in context of SAP TM Freight Order Management and
Planning. It is called dynamically as instance based authorization check, defining the way in
which users can implement an instance of business object /SCMTMS/TOR, depending on the
category, type, and external planning and execution group ID of the business document.

• T_TORACT: Find details in chapter 0, Freight Order Management and Planning.

• T_TOR_MOT: Find details in chapter 0, Freight Order Management and Planning.

• T_TOR_XPG: This object is used in context of SAP TM Freight Order Management and
Planning. It is called dynamically as instance based authorization check, defining the way in
which users can implement an instance of business object /SCMTMS/TOR, depending on the
category, type, and external purchasing group ID of the business document.
 • T_TOR_RP: Find details in chapter 0, Freight Order Management and Planning.
The authorization objects T_TOR_XEG and T_TOR_XPG will be extended with the fields from objects
T_TOR_MOT and T_TOR_RP. As example, T_TOR_XPG will look as shown in the following table:

Authorization Field Description

ACTVT Activity
TM_OC Document Category
TM_OT Document Type
TM_XPORG Purchase Organization External ID
TM_XPGRP Purchase Group External ID
TM_RP Person Responsible
TM_MOT Transportation Mode
TM_ACTAREA or Activity Area
BO_SERVICE
As described in the next chapter (0), objects T_TOR_MOT, T_TORACT, and T_TOR_RP will be deleted
in S/4.
The objects are created in S/4HANAas T_TOR_EXE and T_TOR_PUR.
Deprecated objects in SAP S/4HANA
The following authorization objects are not used in SAP TM, and can be deprecated in SAP S/4HANA
TM (determined with a where-used-check on the authorization objects, and report ZDS_SU21TMCHECK
in system ER9/001):
• T_BOACTION
• T_BONODE
• T_TCTARIFF
• T_CF_FUNC
• T_SF_FUNC
• T_PLN_XORG
• T_RESP_P
• T_TORNODE
• T_TOR_OT
• T_TRQ_DLOC
• T_TRQ_SLOC
• T_TR_DTRF2
• T_TR_FWQF2
• T_TR_OTRF2

General:
• T_TM_ALL: This object is used in context of the SAP TM Authorization Check API. It is called
in class /SCMTMS/CL_AC_FACTORY, method GET_AC_INSTANCE(). This authorization
object will be replaced by T_ADMIN.
• T_DLVP: This object is used in context of SAP TM ERP Integration, having only ACTVT codes
01 (create) and A9 (send). It is called in program /SCMTMS/DLV_BATCH, and the transport
cockpit.

Master Data:
For the business partner business objects /BOFU/BUSINESSPARTNER, /SCMTMS/SUPPLIER, and
/SCMTMS/BUPA there is just one authorization object in place:
• T_BUPA_ID
It contains only the Partner ID and the ACTVT code field (only with ACTVT 03 – display). Such
an authorization object does not make much sense. In SAP TM it is only used for read
operations via the BOPF Service Manager. On SAP TM UIs only the Partner ID, the Partner
Description, and the Partner Address are shown. So, it is a general question, if such an
authorization object really makes sense.
Beside the read authorization checks in SAP TM, there are also authorization checks
performed, when maintaining a business partner in the business partner maintenance UIs.
These checks are not SAP TM specific, and make sure that business partner master can only
be changed with sufficient authorization.
In S/4HANA TM authorization object T_BUPA_ID will be deprecated.

Transportation Planning and Network:

For business object /SCMTMS/FO_SCHEDULE, there are two authorization objects available:
• T_SCHID: Authorization check based on Schedule ID
• T_SCHCAT: Authorization check based on Schedule Category
In general, ID-based authorization checks are hard to handle for customers. In addition, both
objects just contain one field and the ACTVT code. So, there speaks nothing against putting both
objects together, and to delete one of them in S/4HANA TM.
 In S/4HANA TM the authorization object T_SCHID will be deprecated.

Settlement Management:
For the business object /SCMTMS/CUSTFREIGHTINVREQ three authorization objects exist:
• T_CF_CAT: Define whether a user is permitted to execute specific functions in a forwarding
settlement document, depending on the forwarding settlement document category.

• T_CF_TYPE: Define whether a user is permitted to execute specific functions in a forwarding

settlement document, depending on the forwarding settlement document type.

• T_SLS_XORG: Define authorizations based on external sales organization IDs, external sales
office IDs, and external sales group IDs.

This object is only used by business object /SCMTMS/CUSTFREIGHTINVREQ.

It is better to have just one authorization object with all relevant fields, instead of having many small
ones with just one field. Customers can express the same with both approaches. So, in S/4HANA
TM the three objects will be consolidated into one, T_CF_TYPE, and two of them will be
deprecated.
In S/4HANA TM the authorization objects T_CF_CAT and T_SLS_XORG will be deprecated.
For the business object /SCMTMS/SUPPFREIGHTINVREQ three authorization objects exist:
• T_SF_CAT: Define whether a user is permitted to execute specific functions in a freight
settlement document, depending on the forwarding settlement document category.

• T_SF_TYPE: Define whether a user is permitted to execute specific functions in a freight

settlement document, depending on the freight settlement document type.

• T_PUR_XORG: Define authorizations based on external sales organization IDs, external sales
office IDs, and external sales group IDs.

This object is only used by business object /SCMTMS/SUPPFREIGHTINVREQ.

It is better to have just one authorization object with all relevant fields, instead of having many
small ones with just one field. Customers can express the same with both approaches. So, in
S/4HANA TM the three objects will be consolidated into one, T_SF_TYPE, and two of them will be
deleted.
In S/4HANA TM the authorization objects T_SF_CAT and T_PUR_XORG will be deprecated.
Forwarding Management and Transportation Requirements:
The following two authorization objects from the area Forwarding Management and Transportation
Requirements will be deprecated in S/4HANA TM:
• T_TRQ_MOT: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of business documents for forwarding
order and ERP logistics integration, depending on the mode of transport on header level.

• T_TRQ_XSO: This object is used in context of SAP TM Forwarding Order Management and
Transportation Requirements. It is called dynamically as instance based authorization check,
defining the way a user is allowed to use an instance of business documents for forwarding order
integration and ERP logistics integration, depending on the external sales organization, sales
group, and sales office ID.

Both objects are merged into objects T_TRQ_DTR, T_TRQ_OTR, T_TRQ_FWO, and T_TRQ_FWQ.

Freight Management and Planning:

The following two authorization objects from the area Freight Management and Planning will be
deprecated in S/4HANA TM:
• T_TORACT: This object is used in context of SAP TM Freight Order Management and
Planning. It is called dynamically as instance based authorization check, defining the way in
which a user is allowed to execute a specific business object action on an instance of
business object /SCMTMS/TOR, depending on the category and type of the business
document.
 The object will be eliminated in S/4HANA TM, because checks on business object artifacts like
Node or Action Names should not be relevant for the definition of authorization profiles. Such
technical artifacts should be hidden from customers. Authorization checks being defined on
basis of this object need to be switched to another object for business object /SCMTMS/TOR.

• T_TOR_MOT: This object is used in context of SAP TM Freight Order Management and
Planning. It is called dynamically as instance based authorization check, defining the way in
which a user is allowed to use an instance of business object /SCMTMS/TOR, depending on
the category, the type, and the transportation mode of the business document.

This object is merged into object T_TOR_XPG and T_TOR_XEG, and will be eliminated in
S/4HANA TM.

• T_TOR_RP: This object is used in context of SAP TM Freight Order Management and
Planning. It is called dynamically as instance based authorization check, defining the way in
which a user is allowed to use an instance of business object /SCMTMS/TOR, depending on
the category, the type, and responsible person of the business document.

This object is merged into object T_TOR_XPG and T_TOR_XEG, and will be deprecated in
S/4HANA TM.

Contracts Master:
 • T_RATEAPPR: This object is used in context of SAP TM Contracts Master. It is called
dynamically as instance based authorization check. It can be used to define the way a user is
allowed to use an instance of a reference rate table in an agreement.

In S/4HANA TM this object will be merged into T_TCRATE.

• T_TCFAG: This object is used in context of SAP TM Contracts Master. It is called dynamically
as instance based authorization check, defining the way a user is allowed to use an instance
of any kind of agreement (excepting service product catalog) depending on the agreement
type.

In S/4HANA TM this object will be merged into T_TCFA_OBP, T_TCFW_OBP, T_TCIN_OBP,

T_TCMU_OBP, T_QUOT_FWA, T_RFQ_FA.

Obsolete Authorization Fields:

• TM_SLSORG
• TM_SLSOFF
• TM_SLSGRP

After all refactoring activities were done, the authorization class SCTS looks as follows: