This chapter covers the following topics:
The Price Protection transaction accounts for a distributor's on hand-inventory and retrieves on-hand inventory details. On-hand inventory refers to the physical quantity of an item that exists in inventory. This information regarding the on-hand quantities for an inventory item is critical for the price protection claim and the Price Protection application provides an Application Program Interface (API) that tracks the value of on-hand inventory and other required details. The Oracle Inventory Public API captures the following information:
Item - item number
UOM - base Unit Of Measure
On-hand Quantity – on-hand availability of the item
Subinventory – physical location of an item
Serial – item serial number
Once the price transaction is active, open purchase orders for the supplier must be updated to reflect the price drop. An integration with Oracle Purchasing enables price updates to open purchase orders of the supplier. All purchase orders for items specified on the price transaction with an open status as of the effective date on the price protection transaction are updated to reflect the new price communicated by the supplier.
The price protection transaction captures the new price for an item. The Oracle Advanced Pricing Public API copies this new price to the internal price lists of the distributor so that the new price is applied to all new purchase orders placed with the supplier. Using this API, all active price lists for the items and supplier specified on the price protection transaction are updated to the reflect new prices.
Updating Outbound Price Lists
The distributor may want to communicate a price drop to their customers and must update the outbound customer price list as well. Similar to the update for an inbound price list, the Oracle Advanced Pricing Public API updates the item price on the customer price lists. Using this API, all active price lists for the items specified on the price protection transaction are updated to the reflect the new prices.
One of the key components to the price protection module is the supplier claim that streamlines the payments flow. Oracle Channel Revenue Management claims are leveraged to facilitate the debit to the suppliers. Once the submit claim process is enabled for a price protection transaction, a claim is created in Oracle Accounts Receivable Deductions Settlement.. Integration details include:
The Oracle Channel Revenue Management Public API claims are created in Channel Revenue Management to charge the supplier for dropped price for on-hand inventory as well as any customer claims claiming price protection for their stock.
All claims created from the price protection application use a new source of Price Protection Claims, and updates to these claims are restricted from the Channel Revenue Management application.
Captured information includes:
Customer – supplier specified on the price protection transaction
Date – system date
Amount – total of the inventory value
Claim Type – Price Protection
Claim Reason – Price Protection
Claim Lines – all lines existing under the on hand inventory table will be copied as is to the claim lines table
Once the claim is successfully created, the claim number is posted on the price protection transaction as a link.
The price protection transaction captures a new price for the item that is communicated by the supplier. This new price must be reflected on the item cost so the Cost of Goods Sold calculation is based on the actual or the most appropriate cost.
To update the item cost, Price Protection supports an integration with Oracle Cost Management (Costing) application. Costing supports the following costing methods:
Average: average costing values inventory at a moving weighted average cost
Standard: standard costing values inventory at a predetermined cost
First In First Out (FIFO): also know as layered costing. FIFO costing is based on the assumption that the first inventory units acquired are first units used.
Last In Fist Out (LIFO): Also known as layered costing. LIFO costing is based on the assumption that the last inventory units acquired are the first units used.
Price Protection supports the update of costing only in average and standard costing environments. Customers using LIFO/FIFO costing methods must manually update inventory costs.
Based on the type of costing implemented in an environment, the update mechanism initiated from the Price Protection module must be different. Costing methods are unique to a costing and inventory organization, therefore, the costing setup for an organization must be evaluated before updates are performed.
Average Costing: To update item cost in average costing, Price Protection updates the New Price for an item.
Standard Costing: Using an interface table, the simulation cost for the item is populated. The successful update to the interface table initiates the Standard Cost Update which converts the simulated costs to frozen costs.
Price Protection uses the Account Generator Workflow along with a set of default accounts to derive accounts for posting the inventory price drop or price increase journal entries. The Oracle Price Protection application supports Standard Accrual Subledger Accounting method. The following section describes the accounting flow for Price Protection.
Price Protection Journal Entries
On-Hand Inventory - Buy Side
A. Price Drop
| Debit | Credit | Description |
|---|---|---|
| Accrual | - | |
| - | Cost Adjustment | (Passed by Price Protection Application) Accounting Event: this entry is triggered to General Ledger interface when item cost updates are successfully posted to the costing application. |
| Cost Adjustment | - | |
| - | Inventory Valuation | (Passed by Costing Application) This account is fed by price protection to Costing |
| AP Clearing | - | |
| - | Accruals | (Passed by Price Protection Application) Accounting Event: this entry is triggered to General Ledger interface when the supplier claim for on hand inventory is settled in the Channel Revenue Management application. |
| Payables | - | |
| - | AP Clearing | (Passed by Payables Application) |
B. Price Increase
| Debit | Credit | Description |
|---|---|---|
| Cost Adjustment | - | |
| - | Accrual | (Passed by Price Protection Application) Accounting Event: this entry is triggered to General Ledger interface when item cost updates are successfully posted to the costing application. |
| Inventory Valuation | - | |
| - | Cost Adjustment | (Passed by Costing Application) |
Customer Inventory Claims - Sell Side:
C. Customer Claims
| Debit | Credit | Description |
|---|---|---|
| Contra Liability | - | |
| - | AR Clearing | (Passed by Price Protection Application) Accounting Event: this entry is triggered to General Ledger interface when the supplier claim for on-hand inventory is settled in the Channel Revenue Management application. |
| AR Clearing | - | |
| - | Receivables | (Passed by AR Application) |
D. Supplier Claims
| Debit | Credit | Description |
|---|---|---|
| AP Clearing | - | |
| - | Contra Liability | (Passed by Price Protection Application) Accounting Event: this entry is triggered to General Ledger interface when the supplier claim for on hand inventory is settled in the Channel Revenue Management application. |
| Payables | - | |
| - | AP Clearing | (Passed by AP Application) |
Price Protection provides place holders and defaults for the following accounts:
Price Protection Accrual account – default account setup supported on system parameters
Cost Adjustment account – default account setup supported on system parameters
AP Clearing account – use existing Channel Revenue Management defaults from system parameters and claim type setup
AR Clearing account – use existing Channel Revenue Management defaults from system parameters and claim type setup
Contra Liability account – default account setup supported on system parameters and trade profiles
In addition to defaults mentioned above, Price Protection also calls the account generator workflow for the following accounts:
Price Protection Accrual account
Cost Adjustment account
The integration to the account workflow lets you derive GL account codes any way that meets your business requirements. The only seeded logic to the account generator workflow is to derive the product segment value for the GL account from the Cost of Goods Sold setup.