| Oracle® Retail Price Management Oracle® Retail Price Management Operations Guide Release 15.0 E64975-01 |
|
 Previous |
 Next |
| Oracle® Retail Price Management Oracle® Retail Price Management Operations Guide Release 15.0 E64975-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 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) and Oracle Retail Online Order Capture (OOC). 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.
RPM publishes information to the Oracle Retail Point-of-Sale (ORPOS) application via an XML file feed. This file is built specifically for consumption only by ORPOS and serves as a mechanism to deliver only the data that ORPOS supports in a format specific to the ORPOS DIMP process.
Once RPM has built the necessary XML files for ORPOS to consume, these files are bundled together with other XML that the Oracle Retail Merchandising System (RMS) builds. This bundle is then provided to ORPOS.
Refer to the section "Oracle Retail POS Suite - RPM Integration" which describes the full flow of data out of RPM to ORPOS and what data is intentionally excluded in this feed.
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 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 cancelled/deleted.
Promotions
RPM publishes approved promotions, including the promotion details. Simple promotions are published with the promotional retail and change type so ORPOS 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 not publish manually created transaction promotion exclusions to ORPOS.
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 "rib_user.properties" and"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 |
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 the following 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. The xml file, generated in RPM, must be put in the source folder for RMS to process the data and include it in the archive file provided to the Oracle Retail Back Office.
The following diagram 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 |
| Item Classification | 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 have been excluded from the XML:
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 that mix change type between reward lists (such as amount, percent).
Multi-Buy promotions that mix and/or values between buy and/or reward list.
Promotion details with change types Exclude or No Change. This includes manually created transaction promotion exclusions.
Promotion items for which an exception has also been approved.
Amount threshold promotions containing a single/multiple item.
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.
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. |
| The Item Number field is larger in Oracle Retail Price Management than POS 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-Service 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 should be configured through the System Options to calculate promotional retail using the Non-Compounding, Best Deal option when integrating with the POS Suite. This does not account for the use of Price Guides with RPM, but will ensure consistent application of promotion discounts between the two systems. |
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 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 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 and POS 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 the Accounting Method field. | Assume the discount. |
| Oracle Retail Price Management does not directly support the Deal Distribution field. | RPM is sending Source target for no reward list promotions, and target for promotions with reward lists. |
| Target Quantity field is not supported in Oracle Retail Price Management. | Assume target quantity of 1. |
