In my earlier posts I explained what Processing Variants are and how to maintain them. This post zooms in on a single, practical question: when a Transportation Request is created, how does SAP Logistics Management determine which Processing Variant to apply – and, more importantly, what information does it have to work with? Understanding the input is the key to designing determination logic that actually fits your operation.

Determination in a Nutshell

Every product Transportation Request needs exactly one Processing Variant, and it gets one automatically, right at creation time – before it starts moving through planning and warehouse execution. The determination follows a simple order of precedence:

1. A built-in shortcut for warehouse-only Incoterms (Ex Works / Free Carrier → No Shipping)
2. Attribute-based determination, driven by the input described in this post
3. The default variant, as a safety net when nothing else applies

Steps 1 and 3 are quick to summarize. The Ex Works / Free Carrier shortcut recognizes that when the customer arranges transport, there's nothing for the system to plan, so it assigns the No Shipping variant directly. And if attribute-based determination produces no result, the request falls back to the variant you've marked as default. The interesting part – the part you influence most – is step 2, and it all comes down to the input.

How the Rules Engine Evaluates the Input

Before we look at the input itself, it helps to understand how the underlying rules engine uses it. Attribute-based determination is configured as a rule set – essentially a table where each row (a “rule”) defines a combination of criteria and the Processing Variant to assign when those criteria are met.

The engine evaluates this table top to bottom, from the first rule to the last, and it returns the first row whose criteria all match the current Transportation Request. As soon as a matching row is found, evaluation stops and its Processing Variant is assigned. Two consequences follow from this, and they're worth keeping in mind as you design your rules:

• Order matters – because the first match wins, put your most specific rules near the top and your broader, catch-all rules further down. A broad rule placed too early can “shadow” the more specific rules below it
• A row matches only if every criterion on it matches – the criteria on a single row are combined with AND logic, not OR. If any one condition on the row fails, the whole row is skipped and the engine moves to the next

 

A typical business rule for the processing variant can look something like this example here. Important: Only the columns which are used are shown in the table maintenance, e.g. in the example the weight/volume etc. is not used:

But when entering Edit mode and editing (or adding) a rule, all available fields are visible:

Some more info about the different attributes are described in the following…

The Input: What the System Knows About Each Request

At the moment of determination, SAP Logistics Management gathers a rich set of attributes describing the Transportation Request and the demand behind it. Think of this as the “profile” of the shipment. The determination logic reads this profile and decides which Processing Variant fits.

The available input falls into three natural groups.

1. Where it's coming from and going to (Geography)

For both the source and the destination, the system provides:

• Location – the business identifier of the source/destination location
• Postal code
• Region
• City
• Country/Region

That's five geographic attributes on each end of the journey – ten in total. This lets you tailor the process to lanes at whatever granularity you need: an entire country, a single region, a postal-code area, or one specific location.

2. Who and how it ships (Organizational & Routing)

• Shipping Point – the warehouse/shipping point the goods leave from
• Ship-to Party – the receiving business partner
• Route Code – the planned route
• Shipping Condition – how the goods are to be shipped (express, standard, etc.)
• Sales Organization

These attributes capture the operational and commercial context – useful when the right process depends on who is receiving the goods or which part of your organization is fulfilling the order.

3. How big it is (Dimensions)

• Total Gross Weight (with its unit of measure)
• Total Gross Volume (with its unit of measure)
• Pallet Space (with its unit of measure)

One important note: At the moment, no unit conversion is applied. So the rule will blindly check the UOM as provided. As we convert into the default UOM for the warehouse for weight and volume, typically you can just use this UoM. 

Size is often the deciding factor between shipping processes. A few kilograms might belong in a parcel process; several pallets might call for LTL or a full truck load. Because each measurement comes with its unit of measure, your determination logic can compare against meaningful thresholds without ambiguity.

An Important Detail: How Missing Values Affect Matching

A subtle but important behavior follows directly from how the rules engine matches: a rule row is selected only if every criterion on it matches the request. So if a request has no value for a given attribute, any rule row that puts a condition on that attribute simply cannot match – the engine skips that row and continues down the table.

A concrete example: suppose a rule row requires a specific route code. If the current Transportation Request has no route code at all, that row does not match, no matter how well its other criteria fit. The engine moves on to the next row.

This has a practical implication for rule design:

• Only put a criterion on a row if you expect the attribute to be populated – a condition on an attribute that's frequently empty will silently exclude those requests from that row
• Keep broad, criterion-light rules toward the bottom – a row with few or no conditions is easy to match and makes a reliable catch-all before the request would otherwise fall through to the default

The same principle applies to the size attributes: a measurement and its unit are provided together, so a row comparing against a weight or volume threshold works with a real value and its unit, never a number in isolation.

Verifying the Outcome

You can test the result of the processing variant determination rule directly in the UI, using the “Test Rule” button. Then you can enter the data you want to test and the derived processing variant is shown:

In real life, after the variant is determined, it's stored on the Transportation Request and visible in its details. In the Manage Transportation Requests app you can filter by Processing Variant, which makes it easy to:

• Confirm that requests are receiving the variants you expect
• Spot requests that fell through to the default – a sign that a rule or an input attribute might be missing
• Analyze how your shipment mix maps onto your configured processes

If a request landed on the “wrong” variant, the input profile is where to look first: was the deciding attribute actually populated on that request? Remember that a rule row matches only when all of its criteria match – so a missing shipping condition or route code will quietly exclude a request from any row that requires it, which is a common reason a request doesn't match the intended rule and slips further down the table.

Wrapping Up

Automatic Processing Variant determination is only as good as your understanding of the input it works from. SAP Logistics Management hands the rules engine a comprehensive profile of every Transportation Request – source and destination geography, shipping point, ship-to party, route, shipping condition, sales organization, and size in weight, volume and pallet space – and evaluates your rule set top to bottom, assigning the variant from the first row whose criteria all match.

Once you know what's in that profile – and that a row matches only when every one of its criteria matches – designing determination becomes intuitive: split coarsely by size, refine by lane, handle exceptions by relationship, order specific rules above broad ones, and let a well-chosen default catch the rest. The result is that every Transportation Request gets the right process automatically, the moment it's created.

Which attributes drive Processing Variant selection in your operation? Are there inputs you'd like to see added to the determination profile? Let me know in the comments!

References

• Configure Shipping Processes (Processing Variants) – SAP Help Portal
• Consolidation Cutoff – SAP Help Portal
• Processing Variants: The Idea Behind Configuration – SAP Community Blog
• Maintaining Processing Variants – SAP Community Blog

 

Source link