| Oracle® Retail Price Management Operations Guide Release 13.2.9 E71051-01 |
|
 Previous |
 Next |
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 Service Layer (RSL)-based integration
Persistence layer integration
The diagram below 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).
Future retail price data
Oracle Retail Allocation uses this data to provide the user with the future retail price value of the entire allocation (based on its quantities). The future retail price data is stored in RPM and consists of approved pricing events (price change, clearance, promotion) that affect an item/location throughout its pricing life. These future retail price values are retrieved by location, date, and item. RPM provides the retail price, the currency and the price type (regular, clearance, promotion). RPM plans to provide this retail value in the location's currency.
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 to Oracle Retail Store Inventory Management (SIM) 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 cancelled/deleted.
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
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 created).
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.
RPM publishes clearances that were once approved (published) but are now cancelled/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. Multi-buy promotions are published with their details, as a specific promotional retail cannot be calculated.
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 promotions that were once approved (published) but are now cancelled/deleted.
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 cancelled/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 created).
RPM publishes clearances that were once approved (published) but are now cancelled/deleted.
Promotions
RPM publishes approved promotions, including the promotion 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. Multi-buy promotions are published with their details, as a specific promotional retail cannot be calculated.
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 Service Layer (RSL) 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 "rib_user.properties" and"RMS—RPM Integration" in Chapter 2, "Backend System Administration and Configuration".
As shown in the diagram below, the messages that RPM publishes are in an XML format; the data structure is defined by XML Schema Definitions (XSDs).
As shown by the diagram below, 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.
| 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 |
The table below 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.
| 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 included) 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 SIM 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 included) 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 SIM 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 SIM 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 SIM 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 included) of an already approved promotion. This message is published at a transaction item/location level, and is used to notify SIM of the deletion of a promotion. |
RSL is a framework that allows Oracle Retail applications to expose APIs to other Oracle Retail applications. As shown in the diagram below, in RSL terms, there is a client application layer and a service provider layer. RPM includes the service provider layer that owns the business logic.
The RPM implementation of RSL exposes a synchronous method to communicate with other applications (RIB-facilitated processing is asynchronous). All RSL services are contained within an interface offered by a Stateless Session Bean (SSB). To a client application, each service appears to be merely a method call.
For information about RSL-related configuration within the RPM application, see Chapter 2, "Backend System Administration and Configuration."
The table below briefly describes the functional role that RPM's RSL class has within the application.
| Class | Description |
|---|---|
|
PriceChangeServiceJava.java |
This service, provided by RPM, allows external systems such as SIM to create/modify/delete price events. |
|
PriceInquiryServiceJava.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 tables shown below through the 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 table below through the persistence layer:
| RMS packages | RMS methods |
|---|---|
|
RPM_WRAPPER |
uom_convert_value |
|
valid_uom_for_items |
|
|
get_vat_rate_include_ind |
|
|
currency_convert_value |
|
|
PM_DEALS_API_SQL |
create_deal |
|
new_deal_comp |
|
|
RMSSUB_PRICECHANGE |
get_price_change |
| 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 |
Integration between RPM and Oracle Retail POS Suite is optional. If you are not integrating RPM with Oracle Retail POS Suite, you can skip this section.
The following section is the overview of the RPM integration.
RPM integrates with Oracle Retail POS Suite. Applications within Oracle Retail POS Suite include the following and more:
Oracle Retail Point-of-Service (ORPOS)
Oracle Retail Back Office (ORBO)
Oracle Retail Central Office (ORCO)
This section provides an overview of how RPM is integrated with Oracle Retail POS Suite.
A diagram shows the overall direction of the data among the products. The accompanying explanations of this diagram are written from a system-to-system perspective, illustrating the movement of data. For additional information on RMS, ReSA, and RPM integration with Oracle Retail POS Suites, see the Oracle Retail POS Suite Implementation Guide.
RPM sends store specific information to the Oracle Retail Back Office (ORBO) application. To integrate with ORBO, the RPM extract data output format matches the format that ORBO recognizes. RPM sends three different store specific XML record types:
Price Change (clearance and regular price changes)
Price Promotion (simple promotions)
Discount Rules (Threshold and Multi-buy promotions)
RPM uses the RPMtoORPOSPublishBatch program to format and stage output of different price events and the RPMtoORPOSPublishExport shell script to produce an XML file based on the output of the RPMtoORPOSPublishBatch. See Chapter 7, "Java Batch Processes�," for information on batches. In order to run the RMS batch, batch_orpos_extract.ksh must be manually moved from RPM to RMS. The xml file, generated in RPM, must be put in the source folder for RMS to process the data.
The diagram below illustrates the overall direction of the dataflow among the various systems.
The following explanations, based on the diagram above, are written from a system-to-system perspective, indicating the movement of data throughout the RPM related portion of the enterprise.
RMS and RPM pass data to Oracle Retail Back Office (ORBO). RPM passes pricing data. This data is combined with organizational hierarchy, merchandise hierarchy, and item data from RMS. The data is bundled, reorganized by store, and sent to ORBO.
RPM creates the following data files for ORBO:
| File | Description | Full Load or Incremental |
|---|---|---|
| Price | A store specific file containing price changes, clearances, and promotions. | Incremental |
| New Item | A classification file that contains non store specific information. | Full Load |
The data bundling process within RPM reads the price location data and bundles it to create separate files for each ORPOS store. The batch_orpos_extract.ksh is a RMS batch file.
Data bundling specific to the RPM to Oracle Retail POS Suite integration is done by jarring the XML files generated by SQL extract scripts.
The following section describes the known issues from the RPM perspective.
There is a mismatch in promotion functionality between what RPM supports and what Oracle Retail POS Suite supports. The promotion types that RPM supports that are not currently supported by Oracle Retail POS Suite are listed below. If the user creates one of these promotion types, it will not be sent to Oracle Retail POS Suite, because it does not fit in the current model of the XML report.
The following items have been excluded from the XML:
Threshold promotions with Qualification Type = ”Item Level”.
Multi-Buy promotions that combine quantity and amount requirements (buy 2 of X and spend at least $25 on Y, get $Z off).
Multi-Buy promotions with no buy lists (produced by selecting reward type ”Each Buy List”).
Promotion details with change types "Exclude" or "No Change."
Promotion items for which an exception has also been approved.
Amount threshold promotions containing a single/multiple item.
The phrase, "Support the integration of Threshold promotions with a threshold Qualification Type =Item," is not currently supported by ORPOS and therefore is not included in this design.
The phrase, "Support the integration of the item's UOM as part of a promotion," is not currently supported by ORPOS and therefore is not included in this design.
Although the ORPOS XSD specifies a five-character limit for store IDs, RPM sends the full store ID available from the database regardless of length. RPM allows for store IDs of up to 10 characters.
While multi-unit pricing can be set up in RPM it is not part of ORPOS integration.
"Fixed price" price changes and promotions can be set-up with a unit of measure (UOM) other than EA (eaches). However, UOM is not sent to Oracle Retail POS Suite on the Pricing extract file.
RPM clearance price changes are treated the same as regular price changes as Oracle Retail POS Suite does not distinguish the clearance price change type.
The following are known issues in functionality between Oracle Retail Price Management and Oracle Retail POS Suite, as encountered from the Oracle Retail POS Suite application perspective.
Functionality Gaps for Promotion Data Import
| Identified Functionality Gap | Suggested Resolution |
|---|---|
| Oracle Retail Price Management supports a larger field (Change Value - Number) than does POS Suite. This field is the amount, either monetary or percent, to be used to change or replace the current selling price for a sale unit of an item. Could result in loss of data in case of a very large discount amount. | Gap to remain unchanged for this release. |
| In Oracle Retail Price Management, all applicable price promotions are applied. In Point-of-Service, if price promotion and discount rule apply to the same item, then the best deal is applied. If price change and discount rule or price promo apply to the same item, then both price change and promo or discount rule are applied | Oracle Retail Price Management turns off overlapping promotions. This ensures that only one promotion is applied to an item or location at a time. |
| The Item Number field is larger in Oracle Retail Price Management thanPOS Suite. | POS Suite logs an error if the database field is exceeded. |
| Field for Promotion Price attribute is larger in Oracle Retail Price Management.
Multiple promotions can be applied, and the selling price represents the results of each promotion applied in the "Apply Order." One record is downloaded for each promotion applied, and each has the same selling price. The stores system only applies the best deal, and it does so at the time the transaction is rung up. In addition to the multiple promotions, Oracle Retail Price Management can also apply price guides, which might specify the price ends in .99, for example. These price guides are not included in the download file. The selling price is ignored by Point-of-Service. This results in a possible problem if Point-of-Servcie does not calculate the same price that Oracle Retail Price Management sends as selling price. This discrepancy can result from rounding, price guides, and so forth. |
Oracle Retail Price Management turns off overlapping promotions. This ensures that only one promotion is applied to an item or location at a time. |
Functionality Gaps for Price Change Data Import
| Identified Functionality Gap | Suggested Resolution |
|---|---|
| Oracle Retail Price Management supports a longer field (Selling Retail) and more precision. | Gap to remain unchanged for this release. |
| Oracle Retail Price Management Item field is longer. | Item ID length remains the same inPOS Suite and Oracle Retail Price Management. If the item ID is too long in the download file, the record is logged and discarded. |
| Oracle Retail Price Management does not support description field in download file. | Optional Description field is not populated. |
Functionality Gaps for Discount Rule Data Import
| Identified Functionality Gap | Suggested Resolution |
|---|---|
| Oracle Retail Price Management Item field length is longer. | Item ID length remains the same in POS Suite and Oracle Retail Price Management. If the item ID is too long in the download file, the record is logged and discarded. |
| Oracle Retail Price Management field (Threshold Value) is longer and supports more precision. | Field length remains the same in Oracle Retail Price Management andPOS Suite. If the threshold is a decimal value, it is logged and discarded. |
| Oracle Retail Price Management supports larger values and more precision than stores. Meaning of value (%, $, or new price) is defined by Change Type. | Field length remains the same in Oracle Retail Price Management and POS Suite. |
| Oracle Retail Price Management does not support threshold or limit. | Assume no threshold. |
| Oracle Retail Price Management does not support the Number Of Times Per Transaction (NbrTimesPerTrans) field. | Assume -1, which means no limit to the number of times the promotion can be applied to a transaction. The NbrTimesPerTrans attribute is in the PricingImport.xsd file. |
| Oracle Retail Price Management does not support the Accounting Method field. | Assume the discount. |
| Oracle Retail Price Management does not directly support the Allow Source to Repeat field. | Allow source to repeat. |
| Oracle Retail Price Management does not directly support the Deal Distribution field. | Assume target only. |
| Target Quantity field is not supported in Oracle Retail Price Management. | Assume target quantity of 1. |
