A Regular Price Change permanently alters the baseline selling price of an item. Unlike a Promotion (which is a temporary discount that eventually expires), a Regular Price Change becomes the new standard.

In Oracle Retail Price Management (RPM) / Pricing Cloud Service (PCS), the workflow for executing these changes involves strict authorization, conflict checking, and massive downstream communication to the stores and the Merchandising System (RMS).

1. The Price Change Workflow#

Price changes in RPM follow a rigid status lifecycle to ensure financial control.

1. Worksheet (W): An analyst creates a price change event. They select the items, the Zones (or locations), the effective date, and the new price (or a % change).
2. Submitted (S): The event is routed to a manager for review.
3. Approved (A): The event is locked. The conflict checking engine runs a final validation.
4. Executed (E): On the night before the effective date, the batch process executes the change. The new price is published to the POS systems, and a message is sent to RMS to update ITEM_LOC.UNIT_RETAIL.

2. Conflict Checking Rules#

RPM is designed to prevent "dumb" pricing mistakes that destroy margin. When an analyst attempts to approve a price change, the Conflict Checking Engine evaluates the event against thousands of parameters.

Common conflict checks include:

• Overlapping Events: Is there already an approved price change for this item on this date?
• Margin Thresholds: Will this markdown drop the Maintained Markup (MMU) below the department's minimum allowable threshold?
• Clearance Lock: Is the item currently on Clearance? (You cannot execute a Regular price change on an item that has already entered its end-of-life clearance phase).
• Promotion Overlap: Will this permanent markdown conflict with an active 50% Off promotion, resulting in the item being sold below cost?

3. The Financial Impact (Tran Codes)#

A Regular Price Change doesn't just change the sticker on the shelf; it instantly changes the value of the company's assets on the Stock Ledger (if using Retail Accounting).

When the price change is Executed, RPM sends a payload to RMS. RMS looks at the physical STOCK_ON_HAND for every affected store and calculates the total value change.

Markups (Tran Code 11)

If the price of an item increases from $10 to $12, and a store has 100 units on hand, the store just gained $200 in retail inventory value. RMS writes a Tran Code 11 (Markup) to TRAN_DATA for $200.

Markdowns (Tran Code 15)

If the price drops from $10 to $8, the store loses $200 in retail value. RMS writes a Tran Code 15 (Markdown). This is a direct hit to the company's gross margin for that fiscal period.

4. Core Tables Reference#

(Note: These are RPM schema tables)

Price Change Header (RPM_PRICE_CHANGE)

5. SQL Deep Dives#

Tracking Future Price Changes

Store managers frequently want to know what items are dropping in price next week so they can prepare fresh signage and endcaps.

SELECT 
    rpc.price_change_id,
    rpc.effective_date,
    pcp.item,
    pcp.zone_id,
    pcp.old_retail,
    pcp.new_retail,
    ROUND((1 - (pcp.new_retail / pcp.old_retail)) * 100, 2) AS markdown_pct
FROM rpm_price_change rpc
JOIN rpm_price_change_payload pcp ON rpc.price_change_id = pcp.price_change_id
WHERE rpc.status = 'A' -- Approved but not yet executed
  AND rpc.effective_date BETWEEN SYSDATE AND SYSDATE + 7
ORDER BY rpc.effective_date ASC;

6. Official Oracle Resources#

For further reading, consult the official Oracle documentation:

• Oracle Retail Price Management (RPM) User Guide: Price Changes
• Oracle Retail Pricing Cloud Service: Regular Price Management