Most shippers would agree that cost savings from optimization of their shipments across orders are one of the major (if not the only) goals desired from a TMS implementation. After all, consolidation would logically lead to an optimized mode (LTL, TL) selection and the assignment of the cheapest cost carrier (from multiple carriers maintained in the transportation lanes). However, there is one aspect of carrier determination that is usually not in the control of the shipper - customer-specific carrier determination rules.
When customers, specifically the consignee pays for freight, they typically have their own rules for which carrier needs to be assigned based on their contractual agreements with the carriers. In such scenarios, the general setup of the transportation network (carriers maintained at the lanes and the costs) must be ignored and the customer-requested carrier should be assigned on the freight order instead. Carrier determination logic may not even consider cost, as customer rates with carriers are typically not disclosed. Usually, the customer will provide carrier assignment guidance in the form of specific weight breaks, service levels, and geo-locations within which to assign the desired carriers.
Figure 1: Prepaid & Collect Carrier Selection Options
Conditions in TM provide the flexibility to bypass the transportation network settings mentioned above and assign a customer-specific carrier based on a set of rules. There are two prerequisites required to configure the “Collect Routing” scenario. First, a custom planning strategy for use in the carrier selection setting. Second, custom logic to call the condition and a TOR update action to assign the carrier on the freight order.
The condition should be created with an origin of “Condition based on BRFplus expression”. It should be a copy of condition type /SCMTMS/TOR_TYPE with the desired data access definitions as inputs and the carrier field as the result of the condition type. The origin of the condition enables the user to create a BRFplus application (More information on BRFplus is available on our previous blog BRFplus: Business Rules Processing In SAP TM.
This ”freestyle” application is then used to model the customer-specific rules including triggering email alerts based on specific rules. For example, if there is a customer-requested carrier that is not part of the daily pick-up carriers at the dock, an email can be triggered with specific instructions to the transportation planners to call the carrier and schedule a pick-up. The beauty of this tool is that the rules can be set up by functional analysts with minimal development required. With an interactive user interface, analysts can work hand-in-hand with business users to set up these rules. Once the rules are set, business users can maintain the data in each system (via an application exit).
Figure 2: Customer Specific Rules-based Carrier Selection
With the carrier assigned on the freight order, carrier selection settings can either assign the carrier or even start a tendering process to notify the carrier of the load via standard TM tendering communication options (email/ EDI/ SMS). While the email with instructions to planners is triggered, the standard TM process can be triggered for communication with the carriers.
Additionally, modeling these customer-specific rules and optimization of multiple orders during planning onto one freight order can also help shippers provide transportation savings to their customers.
References: SAP Transportation Management (TM 9.0, TM 9.1, TM 9.2), BRF+, ABAP