Rate Record Attribute SMC Discounts Not Being Sent To Rateware (Doc ID 1342115.1)

Last updated on SEPTEMBER 08, 2016

Applies to:

Oracle Transportation Management - Version: 6.2.1 and later   [Release: 6.2 and later ]
Information in this document applies to any platform.

Symptoms

Assumption:

A carrier has a discount rate of 79.5%. However, this is to only be applied up to the M10M level. So, in SMC Czarlite, one would have to pass the below attributes to get the appropriate rate factor from SMC:

Min Discount = 62%; L5C Discount = 79.5%, M5C Discount = 79.5%, M1M Discount = 79.5%; M2M Discount = 79.5%; M5M Discount 79.5%; M10M Discount 79.5%; M20M Discount 0%; M30M Discount 0%; M40M Discount 0%.

In order to accomplish this, there is a rate record that has a rate geo cost of 79.5% discount and the above discounts detailed on the Rate Geo Attributes Tab.

When configured in this fashion, the ATTRIBUTES discounts are ignored and only the COST discount is taken into consideration.

When the COST discount is removed, OTM passes the attributes discounts out to Czarlite, and Czarlite does the calculations.

This causes several issues.

When using the standard Rate Cost and LTL - MASTER configuration, Czar is returning the extended cost base rate to OTM at which time OTM is calculating the discount for the shipment. The cost that is calculated in this case is accurate.

When using the newly configured LTL - MASTER-SMC with SMC DISCOUNTS attribute, OTM is passing the SMC discounts to Czar and applies the discount against the rate factor in SMC as opposed to the extended cost. The rate factor is rounded to the hundreth decimal and therefore leaves off a couple of decimal places resulting in an incorrect cost.

Although it may have been the intended value, there seems to be an inherent flow with how the discount is communicated to Czar and/or how Czar responds to those discounts.

Basically, there are two scenarios:

A. There is a discount on the rate cost - in this case, OTM reaches out to Czarlite, gets back the tariff and applies the discount.
-It is important to note a few things in this case:

1) This does in fact calculate the correct rate.

2) Czarlite returns what they call a rate factor against the weight of the shipment (lets say 11000lbs). So to the "tariff" that Czarlite sends back in this case, OTM then applies the discounts to.

B. There are SMC discounts on the rate attributes tab - in this case, OTM sends the SMC discounts to Czarlite, and Czarlite uses them to calculate the cost with the discount applied and sends the result back to OTM.

-The difference between A and B does not end with what "type" of information is sent to and from OTM but how the discount is applied. In this scenario, OTM sends the discounts to Czarlite, as stated above. However, where ever OTM is sending those (meaning whatever mapped tables it is sending to in Czarlite) are inherently different then the original OTM/Czarlilte design (which is a major issue for both OTM and Czarlite). As opposed to discounting the "tariff", the discount is applied against the cost.

-----So the first issue is both an OTM and Czarlite issue.

-----The second issue, (which is caused by the first issue) is that the discount is being applied against an incorrect "rate factor". This rate factor is rounded resulting in an incorrect rate.


We did contact Czarlite and this is what they said:

Here is the current output to OTM from CZAR: The RCNWYA is what you need to focus on. The R should be a C instead based on the response from CZAR I have listed below as well

0223010201E1LITECZ02N10-01-200050313 28216 01Shipment ID NN RCNWYA 6565 7800 7800 7800 7800 7800 7800 0000 0000 0000 6565 7800 7800 7800 7800 7800 7800 0000 0000 000050 15000.0198010203 LITECZ02 01100K0150000150000030.090000.00000000000000.00000673.50 Shipment ID 10-01-200000.0002 DD 0.00 0.000004.49000673.50
0223010201E1LITECZ02N10-01-200050313

OTM is currently passing a R instead of a C.

Discount Application N 1 R=Rates, C=Charges. "R" means apply discount to the rates. "C" means apply discounts to the Charges. Default is "C” for Charges.

From SMC:

Below are the properties (API) for RateWare to build an interface. You will never see this. These properties are used (within the desired programming language) by the developer—as well as other features, to build the interface you see.

Below are the properties (API) for RateWare to build an interface. You will never see this. These properties are used (within the desired programming language) by the developer—as well as other features, to build the interface you see.

Field Name Required Length Description

Use Discounts? N 1 Y=Yes, N=No. "N" means do not apply any discount to this shipment. "Y" means apply the discounts, which were supplied in the DSC segments. The default for this field is N.
Origin Routing Flag N 1 D=Direct Point, I=Indirect Point, blank=let system determine routing. Use either D or I to override system-determined service for the application of discounts. Use Blank if the system is to determine routing from installed routing files for the carrier or from CarrierConnect.
Destination Routing Flag N 1 See Origin Routing Flag.
Discount Application N 1 R=Rates, C=Charges. "R" means apply discount to the rates. "C" means apply discounts to the Charges. Default is "C” for Charges.
Carrier SCAC N 4 Use the carriers SCAC code to obtain Service days and Service Type for origin and destination
Carrier Type N 1 Used in conjunction with Carrier SCAC. A code of A = LTL carrier, code of B = TL carrier. The default for this field is A.
Rate Adjustment Factor N 5 A factor that increases or decreases rates by a specific percentage. The factor is applied to the rates, then uses the adjusted rates in calculating charges. The factor has an implied decimal 9V9999. 15000 would increase rates 50%, 07500 would decrease rates 25%.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms