This chapter provides information that addresses how RPM integrates with other systems (including other Oracle Retail systems).
This chapter is divided into the following sections that address RPM's methods of integration:
Functional dataflow
Communication flow diagram and explanation
Oracle Retail Integration Bus (RIB)-based integration
Oracle Retail Web Service Layer-based integration
Persistence layer integration
The following diagram details the overall direction of the dataflow among the various systems. The accompanying explanations of this diagram are written from a system-to-system perspective, illustrating the movement of data throughout the RPM-related portion of the enterprise. Note that this discussion focuses on a high-level functional use of data. A technical description of the dataflow is provided in this chapter.
Many tables and functions within RPM are held in common with the Oracle Retail Merchandising System (RMS). This integration provides the following two important benefits:
The number of interface points that need to be maintained is minimized.
The amount of redundant data (required if the rest of the Oracle Retail product suite is installed) is limited.
The following describes the elements of the integration interface dataflow.
Request for future retail price data
This request is based on information provided by Oracle Retail Allocation (for example, item, location, date).
Price change approval/execution
RPM publishes price change approvals to RMS so that RMS can generate a ticket request for the specified item/location. RPM also owns price change execution, which is the process of updating the retail information stored in RMS with the new regular retail prices determined by the regular price change going into effect. RPM processing asks: are there any price changes going into effect tomorrow? If there are, RPM notifies RMS, and RMS updates the retail information with the new regular retail prices. In other words, RMS table updates occur through RMS code.
Promotion execution
RPM processing asks: are there any promotions (for example, 25% of the retail price of an item) going into effect tomorrow or ending today? If there are, RPM notifies RMS, and RMS updates the promotional retail information. In other words, RMS table updates occur through RMS code. The promotion of items is frequently driven by a particular event such as a holiday or the overstock of an item. RPM also provides promotion information to RMS so that RMS can associate promotions to orders and/or transfers.
Clearance execution
Clearances in RPM are a series of markdowns designed to move inventory out of a store. Clearances always result in the price of an item going down. RPM processing asks: if there are any clearances going into effect tomorrow or resetting tomorrow? If there are, RPM notifies RMS, and RMS updates the clearance retail information. In other words, RMS table updates occur through RMS code.
Note: Price changes, clearances, and/or promotions are not applied to item/locations in RMS with a status of Deleted. |
Initial price data
Initial retail prices in RMS are derived using various pieces of information stored in RPM. To successfully initially price items in RMS, a primary zone group must be defined in RPM for the merchandise hierarchy assigned to the new item. The primary zone group definition in RPM consists of the following elements:
Primary zone group
The primary zone group determines the structure that is used to initially price the item. When users access the retail by zone link in RMS, they see an initial price for each zone with the primary zone group.
Markup percent
The markup percent is the markup applied to the cost of the item.
Markup percent type
The markup percent type is either cost type or retail type and determines what formula to use when marking up the cost.
Price guides
Pricing guides are used to help create a uniform pricing strategy. They are used to smooth the proposed retails in order to maintain a consistent set of price points.
There are several instances when RMS must notify RPM of actions that occur within RMS. These actions are as follows.
Note: RMS does not notify RPM through RIB messages; rather, RMS communicates the information through database API and triggers. The activities that are communicated include creation of stores/warehouses, items/locations, and departments. Item modification also is communicated. |
RPM publishes information via generic flat file interface that can be consumed by any application that is able to take in a flat file. Within the Oracle Retail application footprint, this file can be consumed by Oracle Retail Store Inventory Management (SIM), Oracle Retail Online Order Capture (OOC), Oracle Retail Xstore Point of Service and Oracle Retail Extension Module (RXM). This integration point is used to communicate the status of price changes, clearances, and promotions within the application. The messages are published at a transaction item/location level and include the following price change events:
Price changes
RPM publishes approved price changes at the location level and they are published as ”fixed price” price changes, with the price change type and the price guides already applied.
RPM publishes price changes that were once approved (published) but are now deleted.
Clearances
RPM publishes approved clearance price changes at the location level and they are published as fixed price clearances with the change type and price guides already applied. Clearance changes include a markdown number.
RPM publishes the reset when a clearance price changes with a reset date is approved (and therefore the reset date record is created or modified).
RPM publishes a clearance reset date add/change/remove when an update is performed via the create clearance resets functionality for an item location, independent of the clearance event.
RPM publishes clearances that were once approved (published) but are now deleted.
Promotions
RPM publishes approved promotions, including the promotion details. Simple promotions are published with the promotional retail and change type so SIM can apply them to the current regular price or clearance based on the promotion settings. Complex promotions including; Threshold, Multi-buy, Finance, and Transaction promotions are published with their details, with the exception of the specific promotional retail. The promotional retail is not calculated for complex promotions because the discount amount is determined by what is included in the transaction at point of sale. This information is known only at the time that the sale is being rung up.
RPM will publish promotion details that are manually created exclusions to transaction promotions only. Exclusions (system or manually created) for all other promotion types are not published to downstream systems.
RPM publishes promotions that were once approved (published) but are now cancelled/deleted.
Oracle Retail Store Inventory Management (SIM) makes requests to RPM to create and modify price events within RPM as described below. This communication is done through the Oracle Retail Web Service Layer.
Price Changes
SIM requests new price changes. RPM checks the submitted price change for conflicts. If the conflict checking is successful, RPM assigns a reason code and price change ID and publishes the approved results. If the conflict checking is unsuccessful, RPM informs SIM of the failure.
SIM edits existing price changes. RPM validates the edits to ensure that they do not create conflicts or a negative retail. If conflict checking is successful, approved updates are published. If conflict checking is unsuccessful, RPM publishes a status record relating that the price change was unable to be updated.
Clearances
SIM requests a new clearance price change. RPM checks the submitted clearance for conflicts and, if successful, assigns a sequence, reason code, and ID, and then publishes the approved result. If the conflict checking is unsuccessful, RPM informs SIM of the failure.
SIM edits existing clearance price changes. RPM validates the edits to ensure that they do not create conflicts, negative retails, or clearance price raises above the previous clearance retail. Approved updates are published, and SIM is able to implement the clearance. If RPM validation is unsuccessful, RPM informs SIM of the failure.
Promotions
SIM creates simple promotions at the item/location level. RPM checks the submitted promotion for conflicts and overlaps. RPM also checks for negative retails to insure that the promo retail is not above the regular retail. Approved promotions are published, and SIM is able to implement the promotion. If RPM validation is unsuccessful, RPM informs SIM of the failure.
SIM edits existing simple promotions. RPM validates the edits to ensure they don't create conflicts, negative retails or promotional retails above the regular retail. Approved changes to promotions are published, and SIM is able to implement the changes to the promotion. If RPM validation is unsuccessful, RPM informs SIM of the failure.
RPM publishes information to the RIB to communicate the status of price changes, clearances, and promotions within the application. The messages are published at a transaction item/location level and include the following price change events:
Price changes
RPM publishes approved price changes at the location level and they are published as 'fixed price' price changes, with the price change type and the price guides already applied.
RPM publishes price changes that were once approved (published) but are now deleted.
Clearances
RPM publishes approved clearance price changes at the location level and they are published as fixed price clearances with the change type and price guides already applied. Clearance changes include a markdown number.
RPM publishes the reset when a clearance price changes with a reset date are approved (and therefore the reset date record is created or modified).
RPM publishes a clearance reset date add/change/remove when an update is performed via the create clearance resets functionality for an item location, independent of the clearance event.
RPM publishes clearances that were once approved (published) but are now deleted.
Promotions
RPM publishes approved promotions, details along with promotion level details. Simple promotions are published with the promotional retail and change type so that another application can apply them to the current regular price or clearance based on the promotion settings. Complex promotions including; Threshold, Multi-buy, Finance, and Transaction promotions are published with their details with the exception of the specific promotional retail. The promotional retail is not calculated for complex promotions because the discount amount is determined by what is included in the transaction at point of sale. This information is known only at the time that the sale is being rung up.
RPM will publish promotion details that are manually created exclusions to transaction promotions only. Exclusions (system or manually created) for all other promotion types are not published to downstream systems.
RPM publishes promotions that were once approved (published) but are now cancelled/deleted.
Pricing detail is communicated from RPM to other applications through different means. The four primary communication components of pricing information are described in this section. A functional explanation of the data follows the diagram.
When a price change, clearance or promotion is approved in RPM, the system publishes those events to the Oracle Retail Integration Bus (RIB). Another application can subscribe to the message in order to pass the pricing event information on to the RIB. RPM also publishes messages when approved events are unapproved. This message informs the other application that the event previously sent will not take place.
SIM has the ability to create, modify, or delete price changes, clearances and promotions on a store by store basis. SIM communicates these requests via the Oracle Retail Web Service Layer and RPM runs the requests through conflict checking. If the requests pass conflict checking then they become approved price events. RPM sends a confirmation back to SIM for creation and modification requests, but not deletions. As stated above, the approved price events and details are then communicated via the RIB.
Ideally, Oracle Retail Allocation should know the price of an item on a given day for a given location. Oracle Retail Allocation usually requests a future date. The requests are communicated to RPM via a database API and processed by RPM from the future retail table. RPM sends back the price information for the requested item/location/date combination.
When Oracle Retail Allocation requires promotion detail, it is able to retrieve the data via RMS from RPM. There are two direct package calls involved - Oracle Retail Allocation calling the RMS package, and the RMS package calling an RPM package. This provides Oracle Retail Allocation with the promotional detail beyond what would be provided in a price inquiry request.
The flow diagrams and explanations in this section provide a brief overview of publication and subscription processing. See the latest Oracle Retail integration documentation for additional information. For information about RIB-related configuration within the RPM application, see "Disabling RIB Publishing in RPM" in Chapter 2, "Backend System Administration and Configuration".
As shown in the following diagram, the messages that RPM publishes are in an XML format; the data structure is defined by XML Schema Definitions (XSDs).
As shown by the following diagram, an event within RPM's core service layer (that is, an insert, update, or delete) leads it to write out a payload that is published to the RIB. The RIB engages in polling the JMS queue, searching for the existence of a message. A publishable message that appears on the queue is processed. The RIB is unconcerned about how RPM gets its message to the JMS queue table.
This table illustrates the relationship among the message family, message type and XSD/payload. For additional information, see the latest Oracle Retail integration documentation.
Table 5-1 Publishers Mapping Table
Family | Type | XSD/Payload |
---|---|---|
regprcchg |
REGPRCCHGCRE |
RegPrcChgDtl |
regprcchg |
REGPRCCHGMOD |
RegPrcChgDtl |
regprcchg |
REGPRCCGDEL |
RegPrcChgDtlRef |
clrprcchg |
CLRPRCCHGCR |
ClrPrcChgDtl |
clrprcchg |
CLRPRCCHGMOD |
ClrPrcChgDtl |
clrprcchg |
CLRPRCCHGDEL |
ClrPrcChgDtlRef |
prmprcchg |
MULTIBUYPROMOCRE |
PromotionDesc |
prmprcchg |
MULTIBUYPROMOMOD |
PromotionDesc |
prmprcchg |
MULTIBUYPROMODEL |
PromotionRef |
prmprcchg |
PRMCNLITEMLOCCRE |
PrmCnlItemLocDesc |
The following table briefly describes the functional role of publication messages in RPM functionality and the products involved with RIB integration. For information, see the Oracle Retail Integration Bus documentation set.
Table 5-2 Functional Areas and Descriptions
Functional Area | Integration to products | Description |
---|---|---|
Price Change Creation |
SIM |
This message is used by RPM to communicate the approval of a price change within the application. This message is published at a transaction item/location level. |
Price Change Modification |
SIM |
This message is used by RPM to communicate the modification of a new retail on an already approved price change. This message is published at a transaction item/location level. |
Price Change Deletion |
SIM |
This message is used by RPM to communicate the deletion (un-approval) of an already approved price change. This message is published at a transaction item/location level. |
Clearance Creation |
SIM |
These messages are used by RPM to communicate the approval of a clearance price change or a clearance price change reset within the application. This message is published at a transaction item/location level, and is used by SIM for visibility to the new clearance retail on the effective date for the clearance price change through the effective date for the clearance price change reset. |
Clearance Modification |
SIM |
This message is used by RPM to communicate the approval of a new retail on an already approved clearance price change. This message is published at a transaction item/location level. It is used by consuming applications for visibility to the modified clearance retail on the effective date for the clearance price change. |
Clearance Deletion |
SIM |
This message is used by RPM to communicate the deletion (un-approval) of an already approved clearance price change and any associated clearance price change resets. This message is published at a transaction level/location level, and is used to notify consuming applications of the deletion of the clearance price change. |
Promotion Creation |
SIM |
These messages are used by RPM to communicate the approval of a promotion within the application. This message is published at a transaction item/location level, and is used by consuming applications for visibility to the new promotional retail on the effective date for the promotion. |
Promotion Modification |
SIM |
This message is used by RPM to communicate the modification of a new retail on an already approved promotion. This message is at a transaction item/location level. It is used by consuming application for visibility to the modified promotional retail on the effective date for the promotion. |
Promotion Deletion |
SIM |
This message is used by RPM to communicate the deletion (un-approval) of an already approved promotion. This message is published at a transaction item/location level, and is used to notify consuming applications of the deletion of a promotion. |
Promotion Cancel Item Location |
SIM |
This message is used by RPM to communicate the cancelation of an active promotion where the merchandise level or organization level of the promotion is at a lower level than its original promotion. For example, cancel an item/location from an active promotion that is created at a department/zone level. |
Web Service-based integration allows RPM to receive enterprise payloads in much the same manner as payloads are received through RIB integration.
The following table briefly describes the functional role that RPM's Web Service Layer class has within the application.
Table 5-3 Class and Description
Class | Description |
---|---|
PriceChangeService.java |
This service, provided by RPM, allows external systems such as SIM to create/modify/delete price events. |
PriceInquiryService.java |
This service, provided by RPM, allows an inquiring system to request the effective retail for an item at a specified location on a given date. RPM provides the retail value and indicates whether the value is promotional, clearance or regular. |
The system is designed to include two RDMS data sources, RPM and RMS. RPM and RMS share certain database tables and processing logic. RPM exchanges data and processing with RMS in four ways:
By reading directly from RMS tables.
By directly calling RMS packages.
By reading RPM views based on RMS tables.
RMS utilizes RPM packages in order to access processing and information available only in RPM. This type of interaction is only done through package calls.
For more information about RPM's persistence layer and database layer, see Chapter 3, "Technical Architecture".
RPM uses the following tables through the persistence layer:
Table 5-4 Tables Accessed through Persistence Layer
RMS tables accessed through the persistence layer |
---|
AREA |
CHAIN |
CLASS |
CODE_DETAIL |
CODE_HEAD |
COMP_PRICE_HIST |
COMP_STORE |
COMPETITOR |
CUSTOMER_SEGMENTS |
DEAL_COMP_PROM |
DEAL_DETAIL |
DEAL_HEAD |
DEAL_ITEMLOC |
DEPS |
DIFF_GROUP_DETAIL |
DIFF_GROUP_HEAD |
DIFF_IDS |
DIFF_TYPE |
DISTRICT |
DIVISION |
FUTURE_COST |
GROUPS |
GTAX_ITEM_ROLLUP |
ITEM_LOC |
ITEM_MASTER |
ITEM_SEASONS |
ITEM_SUPPLIER |
LOC_LIST_DETAIL |
LOC_LIST_HEAD |
PARTNER |
PHASES |
REGION |
SEASONS |
SKULIST_DETAIL |
SKULIST_HEAD |
STORE |
SUBCLASS |
SUPS |
SYSTEM_OPTIONS |
UDA |
UDA_ITEM_FF |
UDA_ITEM_LOV |
UDA_ITEMDATE |
UDA_VALUES |
UOM_CLASS |
VAT_ITEM |
WH |
RPM uses the packages and methods shown in the following table through the persistence layer:
Table 5-6 RPM Views and Tables
RPM Views | RMS Tables |
---|---|
rpm_item_diff |
ITEM_MASTER |
DIFF_GROUP_DETAIL |
|
DIFF_GROUP_HEAD |
|
rpm_deal_head |
DEAL_HEAD |
rpm_primary_ref_item |
ITEM_MASTER |
rpm_future_cost |
FUTURE_COST |
SUPS |
|
ITEM_LOC |
|
rpm_rms_system_options |
SYSTEM_OPTIONS |
rpm_uda_view |
UDA |
UDA_ITEM_DATE |
|
UDA_ITEM_FF |
|
UDA_ITEM_LOV |