Conditions and Incompatibilities

BRFplus (Business Rules Framework plus) is a powerful rules-based engine, and is used by TM conditions. TM Conditions empower users to process complex business rules and it reduces the need to develop, customize, and configure. Conditions are used as filters for automatic decision-making. A condition maps input values to output values. For example, determination of product type, determination of resource type, determination of execution organization.

There are different types of conditions for different areas. For example, document type determination, order type determination, loading and unloading durations, incompatibilities, printing, approvals, tolerances, and any customer-specific rule(s).

Condition type (CT): First, you define the CT and specify the origin. Specify the CT, the fields against which you are testing, and how you want to store the test results when creating a condition. This is referred to as the origin of the condition. The system provides the following three options for the origin of the condition:

• Direct business object access: The Direct Business Object Access condition returns directly the value determined by the data access definition. There is no evaluation of the data.
• BRF+ Decision Table: The BRFplus Decision Table condition takes the input of the data access definition and evaluates it in a table. This condition table can be maintained from the condition user interface. This origin of condition is most commonly used by TM users.
• BRF+ Expression: The BRFplus Expression is a logical expression.

• Input values: Input values originate in the fields of business objects (direct business object access) or user-specific fields (data crawler), or values determined in external determination classes. The available input values depend on the condition type chosen. The condition type defines the area in which the system is to take the condition into account. There are various input values and they are determined by the following factors:

  • Direct Business Object Access

  • Data Crawler

  • Determination Class

• Output values: The output of a condition is comprised of several output values, all derived from the input values based on decision-making. The output values are determined by the condition type. For example, the FUB rule is a result of FUB rule determination.

• BRFplus decision table: The system creates a condition based on BRFplus expressions. The system then processes this table from top to bottom during determination. When the system finds a row in the BRFplus decision table whose input values match the current input values, it copies the corresponding output values and processes them in the area that made the call.

Conditions are tests performed against various objects, such as transportation requirements or freight units, to determine whether a situation is true or false. For example, to decide if products on a single transportation requirement can be shipped together, each item on the OTR is checked for certain parameters. If a certain parameter is found, rules are built to determine where consolidation can take place. If an incompatibility exists, more than one shipment is necessary.

If you need extra fields for the condition types to be delivered as standard, or if you want to use customer condition types, create new data access definitions and extend the assignments in Customizing. You can also change or add to the data access definitions used by default. The condition type must be identified when defining a condition in SAP TM. A condition type is a configurable object that is based on field contents stored in various business object nodes. Each condition type is assigned to a business object (structure) and the node name (at the header or item level).

When defining a condition type, you can identify when a result is found, if it is stored in a structure, and if one or more conditions exist for this condition type. Condition types are then assigned to data access definitions. These objects specify what fields and in what sequence users can define specific condition records.

During transportation planning, companies prepare a set of guidelines regarding shipping. For example, if a shipper has products that must be transported via a refrigerated container, they cannot ship those products with frozen freight units. While planning transportation shipments, companies define rules regarding how they consolidate loads into a single freight order. There are many factors other than capacity that impact how freight orders are built. In SAP TM, these rules are called incompatibilities. This data defines the relevant parameters controlling when it is and is not appropriate to consolidate loads.

In the figure, a company has various products to ship. The temperature at which items must be stored during transit is the attribute that signals if items can be consolidated. A test is executed to decide the temperature in which each product is shipped. A rule states that items classified as chilled cannot be shipped with items classified as frozen. This could lead to damage or spoilage if a product is shipped at the wrong temperature.

Incompatibilities are used with conditions to influence the results in SAP TM during freight unit building, transportation planning, transportation proposals, and carrier selection. Incompatibilities are important when defining requirements for load building. For example, freight units with different incoterms must not be transported together. Refrigerated goods must be transported in an appropriate means of transport. Certain means of transport cannot be loaded at a specific location because the location does not have a suitable loading ramp.

When creating an incompatibility definition, you must specify a validity area. Validity areas are composed of an incompatibility area and an incompatibility type.

Incompatibility areas define where an incompatibility can be used. Four incompatibility areas exist in TM: Automatic Planning and Manual Planning (previously know as Vehicle scheduling and routing (VSR), Freight unit building, Carrier selection, Delivery proposals.

Incompatibility Types: Incompatibility types are delivered by SAP and define the objects that are the focus of the rule being enforced. The following list contains examples of incompatibility types: Freight unit - Freight unit, Freight unit - Vehicle, Freight unit - Transshipment location, Carrier - Transportation Order.

In addition to the validity area, the incompatibility definition can determine how the rule is enforced in both manual and automatic planning by defining the reaction, for example, incompatibility is ignored, warning if ignored, must not be violated.

Incompatibilities can be defined between two attributes of two business objects. This requires that two conditions are defined and relevant results are specified. Two business objects are then incompatible if the result of the conditions matches the relevant results.

Setting the Identical Values Only checkbox in the incompatibility definition allows for an incompatibility to be defined between two instances of the same business object, for example, two freight units. In this case, a single condition is defined in the incompatibility definition. The two business object instances are then only incompatible if their values differ.

Incompatibility Settings: Incompatibility settings can be maintained in planning profiles, carrier selection settings, delivery profiles, and the freight unit building rule. Transportation planning profiles specify when the system allows incompatibilities to be violated during manual planning, in VSR optimization, or in background processing. Incompatibility settings are assigned within these profiles. The incompatibility settings group together several incompatibility definitions that can apply to a planning run. Only incompatibilities for the same incompatibility area can be combined.