Oracle Retail Price Management (RPM) – Understanding Conflict Checking Process and Rules

Welcome again Oracle Retail fans. This article is the continuation of our parent article on RPM (RPM – Deep Dive Tutorial). In this article, we are going to talk in-depth about RPM Conflict Checking processing, various rules applied and validated and also their impacts. This article should give you one view of all details which is normally scattered in various RPM product documents. 

Conflict Check Overview

Conflict checking is done in RPM to ensure that rules are followed to avert potential pricing problems. Examples of conflict checks include ensuring that a given item/location does not have more than one retail value assigned for a given date, and ensuring that parameters of regular price change, clearance, and/or promotions are not causing the retail value of the item/location to go below zero.

The asynchronous conflict check process in RPM is a mechanism by which applications can execute long-running operations in the background while allowing work to be done simultaneously. Within the RPM application, asynchronous conflict check processing is always utilized in the following functional areas:

·         Price Changes

·         Clearances

·         Promotions

·         Worksheet

Conflict Check Rules

Conflict checking is made up of 18 rules that determine whether a price event can be approved or unapproved. The rules are broken up into three step processes.

1.    Conflict checking rules controlled by System Options

 Following are the conflict check rules that can be turned on or off by changing system options settings:

2.    Pre-RFR Insert Validator Conflict Checking rules

These rules are run before the effect of the new price event is added to the RPM_FUTURE_RETAIL (RFR) table. This is the first step in conflict checking. The price events (regular price changes, clearances, or promotions) that are proposed by the user are rejected before

they populate the future timeline. This conflict checking is required, and the user cannot choose whether to run these checks.

3.    Post-RFR Insert Conflict Checking Rules

These rules are “post-insert,” meaning that the effect of the new price event has been added to the RPM_FUTURE_RETAIL (RFR) table prior to running through these rules. If any of these areles is violated by the price event, all effects of the price event are removed from the RPM_FUTURE_RETAIL table. The RPM_CONFLICT_QUERY_CONTROL table provides the ability to add some configuration for the conflict checking.

Skipping Conflict Checks

Skipping Conflict Checking during Submit

Users have the option to skip the conflict checking process during the submit process if they do not need that for their business process. They can do this by checking the "Do not run Conflict Check for Submit" system option checkbox. If they do this, RPM does not perform the conflict checking process (and will not show conflicts if there are any) when the user performs a price event submit action. The price event status is switched to "Submit" immediately.

Skipping Conflict Checking during Complex Promotion Approval

Users can skip conflict checking process during complex promotion approval (and un-approval) by enabling the "Do not run Conflict Check for Complex Promotion Approval" system option checkbox. When this system option is checked, RPM does not perform the conflict checking process (and will not show conflicts if there are any) when users approve (or un-approve) a Complex promotion but it still inserts into the Future Retail GTT table and performs the explosion and rolls forward logic. It populates the Payload tables so that RPM can communicate this complex promotion to other systems (for example, through RIB or ORPOS extract).

It is important to note and understand that by disabling Conflict Check for Complex promotions, following functionalities are lost:

o    Overlapping promotions: Item/Location in the Complex promotion is not considered when validating the overlapping promotions.

o    Price Change Promotion Overlap/Clearance Promotion Overlap: Item/Location in the Complex promotion is not considered when validating these types of overlapping.

o    The Complex promotion information is not available in the Future Retail tables.

o    Deal cannot be attached to Complex promotions.

Although users can change this system option from one state to another in the System Options Edit screen at any time, however, it is not recommended. Flipping the system option (while having active or pending Complex promotions in the system) could produce unpredictable results, such as the following scenarios:

    i.    The "Do not run Conflict Check for Complex Promotion Approval" system option is checked. The user approves a Complex promotion, unchecks the system option, and un-approves the Complex promotion (or cancels/changes the end date after the promotion becomes active). RPM attempts to execute the conflict checking process but cannot find the related records in the Future Retail tables. The Complex promotion might fail un-approval.

   ii.    The "Do not run Conflict Check for Complex Promotion Approval" system option is unchecked. The user approves a Complex promotion. RPM executes the conflict checking process and updates the Future Retail tables. The user checks the system option and un-approves the Complex promotion (or cancels/changes the end date after the promotion becomes active). RPM un-approves (or cancels/changes the end date of) the promotion without executing conflict checking process. Related records in Future Retail tables are not updated.

  iii.    The "Do not run Conflict Check for Multi-Buy Promotion Approval" system option is checked. The user approves a Complex promotion, unchecks the system option, and approves another Complex promotion that is overlapping with the first promotion. During the overlapping constraint validation, RPM will not see the first promotion.

Conflict Check Processing Flow

The major components of conflict checking in RPM are performed by PL/SQL and are executed on the database server instead of the application server. When conflict checking is done synchronously, the system performs conflict checks immediately when Conflict Check is clicked from the Price Change, Promotions, or Clearances workspaces. It also happens when state changes occur that require conflict check. The system then displays a pop-up dialog showing the conflicts whenever conflicts are found.

Conflict checking is always done synchronously in the following situations:

o    Retail Service Layer (RSL) calls

o    Retail Integration Bus (RIB) calls

o    batches

o    auto-generated price changes

When conflict checking is done asynchronously, the conflict check processing happens in a background task or when the system is not busy performing other tasks. The user who initiated the action receives an alert once conflict checking is done. Conflict checking for location moves is expected to operate on extremely large volume of data. It is not acceptable for the user to have to wait for minutes to hours for processing of their request to complete. Thus, conflict checking for location moves is always done asynchronously.

The Conflict Check Results workspace allows User to review the results of background conflict checking for worksheets, price changes, promotions, and clearances. An alert appears in the Conflict column of the worksheet, price change, promotion, or clearance maintenance pane when conflict checking is complete.

Below is a screenshot for the Clearance Conflict Check:

Constraints are performed asynchronously at the same time as the conflict check. When the user executes an action that kicks off a conflict check, the user will indicate whether they want constraints checked. If constraints are checked, they will be handled just like conflict check errors. There is no longer a need to perform constraint checks first.

The asynchronous conflict check process is performed as follows.

1.     The client requests the application server to perform a process on a business object or set of business objects.

2.     The server's application service layer extracts information about the request (type of business object, identifying ID, and requested action).

3.     When RPM determines that a task is eligible for asynchronous processing:

a.     A JMS message is published to the queue that contains specific information about the task.

b.     A record is inserted into the TASK table. The task-specific information about the task is persisted as a Blob in the table. This task-specific information is a Java object that, when reading from the database, is capable of calling an RPM application service to perform asynchronous processing and generate an alert when the processing is completed.

4.     As soon as a message arrives in the queue, the container triggers execution of the RPMTaskMDB. RPMTaskMDB is a message-driven bean used to facilitate RPM's asynchronous processing capability. Message Driven Beans act as listeners to specified queues for messages.

5.     The task passes information to the application service layer.

6.     The application service layer performs a state transition on the requested business object (for example, approving a particular price change) based on the information passed by the task.

7.     The results of this transition (for example, success or failure messages, conflict details) are recorded in the RPM_CONFLICT_CHECK_RESULT table.

8.     The application service inserts a record into the ALERT table.

9.     The client periodically polls the Alerts application service which looks for new

10.  alerts in the ALERTS table.

Summary Note

This was all about conflict checks in RPM. At times, it is important to understand how conflict check process works in RPM to understand and avoid Business frustrations for any pricing events. .Hope this consolidated article on RPM Conflict check helps. Please do let me know in case of any question or comments. 

— Share It —

• Facebook
• Twitter
• Google+
• Linkedin
• Pin It

About Nagesh Mishra

Nagesh Mishra - A Passionate Oracle Retail Certified Professional with more than 17 years of overall experience in IT industry and more than 15 years of domain expertise in Oracle Retail Applications. Worked extensively in diversified fields of Product Implementation, Business Consulting, Pre-Sales, Application Software Development, Maintenance and Support and Re-Engineering Oracle Retail projects.