Issue

BluJay is the legacy TMS system in North America (NA). This system caters multiple modes of Transport. 

As with the ERP Rebuild Hub project SAP TM is introduced, it is only logical to evaluate what should happen with a TMS system as BluJay: Replace or Integrate.

This question has reached higher urgency, because CLX (an important transportation provider) has decided to no longer support the current BluJay version (previously called Kewill Transport). CLX would like Syensqo to migrate to system TM Shippers instead.

The deadline for this transition is beginning of 2026.

The expectation is that the TM Shippers transition is a 5-6 month project and some of high level activities required are listed below:

• Business requirements to be accounted for.
• Thorough TMS configuration.
• Establish super users and Training.
• New integration between SAP and TM Shippers.
• Carriers to be transferred over...

Recommendation

If Syensqo would like to avoid having a second and standalone TMS system for NA, it would require doing a proper analysis of NA’s detail requirements. Based on these requirements, a fit-gap analysis needs to be done to have an understanding of what effort would be required to deliver these requirement.

A POC for certain requirements could be helpful to take away worries about the maturity of SAP TM. Or this could confirm that TM Shipper (next version of BluJay) is the correct solution.

Requesting CLX to support the current BluJay solution for a longer period of time would be helpful, especially if this scope becomes part of ERP Rebuild Hub project.

Background & Context

Introduction of SAP Transportation Management

ERP Rebuild Hub is foremost intended to replace the existing two SAP systems. With the introduction of the latest SAP version (S/4 HANA) , the module SAP Transportation Management (TM) is part of the business suite.

SAP TM is developed as a global solution for managing transportation. Both for LSP businesses as well as shippers. Initially as a standalone system, but later it was integrated with S/4 HANA.
The objective is to have full TMS capability including the functions of;

• Order Management
• Transportation Planning, Manual / Automated, Load Optimization, Routing, Resource Planning
• Carrier Selection, Tendering, Order Integration
• Track & Trace, GTS integration, Transportation Documents
• Freight Charges Calculation, Freight Agreement Maintenance

North America Specifics

The region of North America is the most complex region for transportation to comply with local regulations and industry standards. Some of the requirements that are specific to North America (mainly for USA) are:

• Advance notice to customs prior to import to USA
• Specific bill of lading requirements
• Many small trucking companies
• Specific charge calculation requirements like Rule-11 and many Accessorial Charges.

Integrate vs Replace

When trying to consider to integrate or replace with the local TMS solution, the following consideration can be made:

Implication of transition to TM Shippers

As imposed by CLX, Syensqo needs to transition to a new TMS system by end of 2025. The expectation is that the TM Shippers transition is a 5-6 month project.

Based on this information the following options could be explored:

1. Postpone the transition until ERP Rebuild Hub is completed
   It needs to be investigated that SAP TM can cover the requirements of a North America TMS system. CLX needs to be requested to support BluJay until go-live of ERP Rebuild Hub.
   
   
2. Replace BluJay with an early go-live version of SAP TMS
   SAP TM to be set up to cover North America requirements. For the first period the system works as a sidecar where the system is integrated with WP1 and PF1. Once ERP Rebuild Hub is completed the TMS system can continue to operate as an embedded system.
   
   
3. TM Shippers to replace BluJay and ERP Rebuild Hub will be integrated with TM Shippers
   If TM Shippers is a better TMS solution than SAP TM, it can well be decided to have ERP Rebuild Hub integrated with TM Shippers and keep these systems operating for North America.
   
   
4. TM Shippers could be a temporary solution, replacing TM Shippers with SAP TM to be put on the roadmap
   This approach will keep options open. There is no danger of CLX no longer supporting the NA TMS solution. NA has control of their TMS processes. During or after the ERP Rebuild Hub project it can still be decided to replace TM Shippers solution.

Assumptions

n/a

Constraints

n/a

Impacts

• Replacement of current or new TMS solution will impact the scope significantly and is not to be underestimated. Transportation processes are complicated and are often underestimated in effort required.
• Replacing a complicated solution will increase the chances of a failed implementation. It should be part of the consideration to estimate these risks to determine if this is worth it for Syensqo.

Business Rules

n/a

Options considered

Option A) Integration with BluJay

To have a better understanding of what the process will look like when SAP S/4 HANA system is integrated with BluJay it is probably easiest to describe it by following a (complex) transportation scenario. Below describes a scenario with two Sales Orders for one customer, consolidation in one container and it is a CIF shipment to port of discharge.

Note: Steps described are based on full manual planning. For automation see paragraph "Automation and Shortcuts".

1. Two Sales Orders are created.
2. With early transportation planning setup, two Freight Units are created.
3. The Freight Units are captured in the Transportation Cockpit for consolidation planning. User will create a Container Unit for the consolidation.
4. On the Container Unit a Default Route is applied, creating several stages for transportation.
5. A Freight Order is created for Pre-Carriage from plant to port.
6. A Freight Booking is created for ocean freight stage (port to port).
7. The TM documents are interfaced to BluJay to create TMS Orders.
8. In BluJay, through a carrier selection process, a carrier is assigned.
9. TMS Orders are communicated with carriers.
10. Updates from TMS Orders are updated back to Freight Order / Booking, including carrier, planned departure date, planned arrival date, transportation charges, order status.
11. When the delivery is created the Freight Unit is updated with linkage to the delivery (the Freight Unit is consumed by the delivery).
12. Events as reported in TMS order are updated back to Freight Order / Booking.

Automation and Shortcuts

The presented scenario is a complex scenario. However, for scenarios where the process is more straightforward there are options to have automation or apply shortcuts. Where and how this is applied in the process will be part of detail design. Some options that can be considered and used are;

• Based on Shipping Conditions e.g. "Sea FCL 40ft", where the full delivery will be loaded into one container, instead of Freight Unit creation the system can create the Container Unit directly.
• Based on Shipping Conditions e.g. "Road FTL", where the full delivery will be loaded into one truck, instead of Freight Unit creation the system can create one Road Freight Order directly.
• In case from Freight Unit or Container Unit, Freight Orders and Freight Bookings can automatically be created there are ways to automate this process.
• For consolidation planning it can be investigated if optimiser planning can be utilised to automate this process.

Decisions to be taken during detail design

• Instead of utilising the Ocean Freight Booking, a new type of Freight Order can be configured to cater for ocean legs. This could save setting up an additional set of interfaces. Functionally this would not change anything in this scenario.
• (Pre-)carrier selection could also be done in SAP TM.
• How and where automation and shortcuts need to be applied.
• Solution on making sure that Road Freight Order dates are aligned with the Ocean Freight Booking.

Assumptions

• Consolidation planning can be done in SAP TM and considering the process it thus easier to execute in SAP.
• Decision to do TMS Order tendering will be made in BluJay, together with subsequent processing.
• Existing SAP interfaces can be re-used to cater for TMS Order integration. When there are gaps in the existing interface then the interface will be enhanced.
• With the use of interface mapping existing BluJay interfaces can be re-used.

Business Rules

• Freight in North America will be managed in BluJay

Option B) Replace BluJay

When replacing BluJay, the SAP TM system has to take over the functions of BluJay. In this KDD we'll highlight the main functions that are considered most important to solve for North America. When these functions can be resolved in SAP TM then the confidence would increase that BluJay could be replaced. The functions that impact this are:

1. SMC3 CzarLite & CarrierConnect XL
2. Fuel Price and other index tables
3. Accessorial Charges
   
   

1. SMC3 CzarLite & CarrierConnect XL 

Introduction

In a nutshell, SMC3’s CzarLite LTL base rate provides a neutral rating standard that allows LTL shippers to quickly and accurately evaluate shipping rates from multiple carriers at a glance to help make informed carrier selection decisions - removing the unnecessary complexity that would otherwise accompany this process.

In North America the rate base - or “list price” of freight charges - is usually not the price shippers actually pay for services. This is because carriers deliver discounts on top of this price to account for the variances in freight class, density, distance, and other factors.

Another layer of complexity: each carrier works with their own base rate and these “list prices” vary across each carrier. This means understanding the true cost of working with an individual carrier requires complicated math to untangle base rates, freight discounts, and other factors. This makes it difficult to compare carriers, and it often leads to billing discrepancies. This is where SMC³’s CzarLite fills a critical and growing need.

Solution

A Freight Agreement has a Charge Calculation Sheet. Inside this calculation sheet a charge line can be assigned with calculation method "External" (CALL_SMC3).

This calculation method utilises web services that encapsulate functionality that are called over the internet. For these charge types the system will call SMC3 to collect the transportation charges.

Some comments:

• Configuration guide is attached.
• SAP code has been last updated in 2023 (class XXXXXXXXXXXXXXXXX), latest SAP note is from 2024 (3439301). This indicates that code has been updated.
• SMC3 has support for integration with SAP TM.
  
  

 2. Fuel Price and other index tables

Introduction

A fuel surcharge is an extra fee that is charged by trucking companies to help cover the constantly fluctuating cost of diesel fuel. As fuel prices increase or decrease, fuel surcharge rates can increase or decrease along with them. The U.S. Department of Transportation estimates that fuel charges change about $0.10 per week on average, meaning fuel surcharges are always fluctuating with them. There is no one way to calculate fuel surcharge. Each carrier typically has their own formula for calculating fuel surcharge.

Solution

DOE National Average Diesel Fuel Price, Railway Fuel Surcharge Rates, and other index tables can be custom build using web services (similar as SMC3 integration), however most often this is solved by using Rate Tables. Rate Tables can be embedded in the Freight Agreement, but it is also possible to maintain a rate table outside of the agreement and reference it in multiple agreements.

It can be decided if this requires automation, or that manual maintenance of the rate table is sufficient.

 3. Accessorial Charges

Introduction

Carrier accessorial charges occur for many different reasons. Generally, these fees fall into three different categories: administrative, in-transit, and equipment.

• Administrative: Errors with a bill of lading or other documentation discovered after a shipment’s pick-up.
• Equipment: Shipments that require additional equipment for loading, delivery, or transport. Additional accessorial fees may be charged if those requirements aren’t stated in advance of pick-up.
• In-transit: Charges incurred after shipment pick-up, during transport, or at the time of delivery, such as layover, out-of-route miles, limited access, or redelivery.

Some accessorial charges in transportation are anticipated as part of the transportation needs of a shipment. These carrier accessorial charges are applied at the time of shipment booking. Fees incurred later often result from errors during planning or poor visibility of transportation movements.

Solution

Accessorial charges is a broad category. How these charges are determined and calculated requires multiple solutions. Here an overview of solutions that can be utilised in the solution design.

a. Calculation Base in Charge Calculation Sheet

Calculation bases specify the base that the system uses to calculate charges for the scale. Calculation bases always correspond to an underlying scale base. There are 131 standard calculation bases available in the system. Some bases to highlight, together with accessorial type it can be used for:

• Dangerous Goods (Hazmat Surcharge)
• Days (Layover)
• Goods Value / Insurable Value (Excess Cargo Insurance)
• Number of intermediate stops (Additional Stops)
• Delivery location holiday / Weekday (Weekend Surcharge)

For complete list, click here.

b. Event Driven Charge Calculation

In SAP TM, there is Event Driven Charge Calculation functionality. An event profile can be defined that is added to FO type customisation. The events in the profile can be linked to a charge type. Hence during FO charge calculation, if the the charge type is present in the Freight Agreement and the respective event is reported, the charges associated become active and are calculated accordingly.

Common scenarios:

1. Specific event and flat charges: In this scenario, the carrier charges an additional amount if a specific event occurs. For example, carrier may charge for cleaning, destination charges, fumigation etc… A flat rate is usually charged and the same can be maintained against the charge type in the freight agreement. Above screen shots detail a working model for cleaning event scenario.
   
   
2. Charges based on expected and actual events: In this scenario, based on planning, an event (for example departure) is expected to happen on a certain date/time. If the actual event happens after a specified grace period, then the penalty amount is charged by the carrier for the additional waiting time. TM can automatically detect the charge applicability based on the timing of the actual event posted. Based on the expected event date, reported event date and the grace period, the charge is applied on freight order. SAP has provided a standard calculation bases - DELAY_TOT & GRACE_DAYS. The charge type, created using these calculation bases, can use rate table with the delay duration for various combinations. Currently the delay is calculated in days and in case we require hours or minutes in the rate tables, then the helper assignment in these calculation bases (/SCMTMS/CL_TCC_CB_DELAY & SCMTMS/CL_TCC_CB_REL_CBASE) have to be modified. This scenario/requirement is predominantly for delay/demurrage charges.
   
   

c. Dispute Management for Freight Settlement

A freight settlement dispute case is an individual business document that captures differences in logistics item quantities or charge amounts in a freight order or carrier invoice. As a requester of transportation services, such as a shipper, you own the information in the freight order. Your provider of transportation services, such as your carrier, checks the accuracy of the charge and logistics details in your freight order.

In the self-billing process, the service provider uses the SAP Business Network for Logistics to create a dispute case against a freight order.

In the invoice submission process, the process of settlement between you and your service provider is based on an invoice that your service provider submits to you for a freight order. Your service provider can use the SAP BNL portal to submit such an invoice. For example, your service provider can submit an invoice that contains changes to logistics details such as gross weight or gross volume, or changes to charge details such as rate or an additional charge line for an unplanned charge. In these situations, the system captures the changes in a dispute case and links the dispute case to the invoice your service provider submits.

If the dispute case fails the tolerance limits you specify in Customising, you must manually review the dispute case on the Freight Settlement Dispute Cases app.

Carrier Connect XL

Fuel Price and other index tables

Accessorial Charges

1. ostpone the transition until ERP Rebuild Hub is completed
   It needs to be investigated that SAP TM can cover the requirements of a North America TMS system. CLX needs to be requested to support BluJay until go-live of ERP Rebuild Hub.
   
   
2. Replace BluJay with an early go-live version of SAP TMS
   SAP TM to be set up to cover North America requirements. For the first period the system works as a sidecar where the system is integrated with WP1 and PF1. Once ERP Rebuild Hub is completed the TMS system can continue to operate as an embedded system.
   
   
3. TM Shippers to replace BluJay and ERP Rebuild Hub will be integrated with TM Shippers
   If TM Shippers is a better TMS solution than SAP TM, it can well be decided to have ERP Rebuild Hub integrated with TM Shippers and keep these systems operating for North America.
   
   
4. TM Shippers could be a temporary solution, replacing TM Shippers with SAP TM to be put on the roadmap
   This approach will keep options open. There is no danger of CLX no longer supporting the NA TMS solution. NA has control of their TMS processes. During or after the ERP Rebuild Hub project it can still be decided to replace TM Shippers solution

Evaluation

As consultant we would like to guide Syensqo to choose the correct future landscape. With the timeline for BluJay this is an extra complication. Support from management is required to make the decision making process possible. If there is a strong preference to implement TM Shipper, then ERP Rebuild should not spend lots of effort on making that assessment.

For this reason the scope of this decision document is on the process and it is not a final decision of which system landscape to choose.

See also

SAP_TM_SMC3_Cookbook_V3.pdf

SAP Help - Calculation Bases for Charge Calculation

Change log

Workflow history