| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.21 E86578-01 |
|
 Previous |
| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.21 E86578-01 |
|
Previous |
The Merchandising Foundation Cloud Service Pricing module (called Pricing throughout the rest of document) is a configurable and flexible pricing solution designed to meet the varied needs of the retail industry. Pricing empowers retailers to streamline pricing strategies across the organization, yielding a more predictable and profitable outcome. It provides decision support through pricing-focused business information to validate and approve new retails and markdowns. This approach results in improved margins and strengthened productivity, all while remaining competitive.
Pricing supports the creation and management of price changes and clearances, integrating with the pricing execution systems, such as the POS in the store and e-commerce systems, to provide details on these events when approved.
The following flowchart illustrates the position of Pricing in relation to other Oracle Retail modules:
During installation and implementation, Pricing requires some initial data setup to create and implement price changes and clearances. This foundation data includes zone structures, initial price zone definitions, and rounding rules.
The zone structure in Pricing allows you to define groupings of locations for pricing purposes and eliminates the need to manage pricing at the most granular, location, level. At the highest level, these groupings are divided into categories called zone groups. Zone groups are used in both regular and clearance pricing; the same zone groups are available to be used in both. You can determine how zone groups are created for your business based on a number of different factors, the type of pricing event, regular and/or clearance, or the items being priced, such as by department or division.
Within zone groups are groupings of locations (stores or warehouses) called zones. The function of these zones is to group locations together in a manner that best facilitates company pricing strategies. For example, you might choose to create zones based on geographic regions, such as:
US East region
US West region
Mexico stores
Similarly, you can create zones with locations with similar geographical or customer characteristics, such as
US urban stores
US rural stores
There are no restrictions on the number of locations a zone can contain and a location can (and likely will) exist in multiple zone groups. For example, a New York City store might exist in the US urban stores zone group as well as the US East region zone group. However, two rules apply to the relationship between locations and zones:
A location cannot exist in more than one zone within a zone group.
All locations within the same zone must use the same currency.
When new stores or warehouses are added in Merchandising, a pricing location is designated for the new store or virtual warehouse. Pricing will take this information for the new location and attempt to add the new location to every zone group/zone in which the pricing location exists across all zone groups. If the pricing location and the new location are not of the same currency, then the new location will be added to every zone group where the pricing location exists, but the system will create a new zone for the location with the currency of the new location. This process applies for all store types, including company and customer (franchise, or wholesale) stores and stockholding or non-stockholding locations.
|
Note: Pricing of warehouses is determined by a system option in the Pricing module. |
You can create an empty zone and add locations to the zone at a later date. Price events can also be created against a zone with no locations, based on a system option setting; however, conflict checking will not run and records are not generated on the Future Retail table. Once locations have been added to those zones, any new item/location relationships created will be added to price events created for those zones.
When a location is added to an existing zone, the location will participate in any price events which are approved in the future, but it will not inherit any existing approved events. When a location is removed from a zone, it will stay on any existing approved events, but will not be included in any new events created for that zone. If a location needs to be added to or removed from an existing event, setting the event back to worksheet and then re-approving will add that location.
Once zone groups are created in Pricing, you are able to assign them to Initial Price Zone Definitions. This allows you to specify the zone structure that is used when pricing new items added in a particular department, class, or subclass, including markup percentage, and markup type (cost or retail), and rounding rules.
|
Note: Markup is also defined as part of the department creation process, but Pricing uses the Initial Zone Definition to determine initial price markup. |
Rounding rules help you create a uniform pricing strategy. They are used to smooth proposed retails in order to maintain a consistent set of price points by applying "ends in" logic to retail values. Rounding Rules are defined globally, but can also include exceptions or exclusions based on merchandise hierarchy and/or currency. This provides a simple but flexible configuration to handle a wide variety of scenarios.
|
Note: Editing rounding rules details will only affect retails derived by the rounding rules from that point on. It will not affect/overwrite any retails that have already been derived based on the old rounding rules. |
Rounding rules are optional. If you do not use rounding rules, the following rules are enforced for "percent off" price events, based on the number of decimal places defined as part of the currency set up in Merchandising:
Regular Price Changes: if the extra digit (beyond the number of digits for the currency) is between 0 and 4, round down; if it is between 5 and 9, round up.
Clearance Events: retail will always round down
This section of the document provides details that pertain to all types of price events and helps provide insight on how to optimize and configure data to get the most out of the functionality in Pricing.
Price changes are the pricing events that affect the regular retail price. When a price change is created, the following information is specified:
The item receiving the price change, by specifying items by parent, parent/diff, or transaction item.
Where the price change is occurring, by selecting zones or locations.
How the price is changing, by selecting a percent or amount change, or a new fixed price.
When the price change will take effect, by designating an effective date
Why the price change is occurring, by optionally specifying a reason code
Price change groups are used to group together multiple price change events for easier management of the individual events, such as facilitating mass approval of items in the group. For example, a price change group might be used to group together items whose prices are changing on the same date within a department or a set of zones.
When price change events are approved in Pricing, they are made available in advance of their effective date to multiple systems for ticketing and to prep selling locations for the upcoming changes. Normally, only one price change for an item/location on a given day is allowed to be approved, however there can be more than one if an "emergency" retail price change is entered and executed by an authorized emergency user. Once the emergency price is received by the selling systems (POS, ecommerce) it will overlay the other retail price that was received previously. For more on emergency events, see below.
Clearance events are defined as a reduction in the permanent retail designed to increase demand and move inventory out of stock. These reductions may consist of a single markdown or a series of markdowns, with the goal of selling through all stock in the locations designated. When a clearance event is created, you specify the items and locations where the clearance is in effect along with the discounted price and the dates on which it will apply. Like price changes, clearance events can be created for parent items, parent/diffs, or transaction items. Locations where the markdown applies are selected by zone or individual location.
Clearance groups are used to group together multiple clearance events for easier management of the individual events. This is particularly helpful for items that will have multiple markdowns throughout their lifecycle to provide visibility to the various markdown prices and dates together for easier management. This can also help facilitate mass update of the events in the group, such as approving multiple events together.
When creating price change and clearance events for a group of items, it is recommended to enter the item data at the highest level possible. For fashion items, this is generally parent item (style) or parent/diff (style/color), whereas for grocery and hardlines this is generally at the transaction item level (SKU). This is also true for the selection of locations; it is recommended creating price events at zone level, rather than by store or warehouse. This provides the following advantages:
Managing price events at the higher levels will increase the usability of the application by having fewer rows for you to manage. It will also help ensure pricing consistency for similar items and locations, in line with your company pricing strategy.
The Future Retail tables will have the ability to store data at the highest level possible which, in turn, will ensure that Pricing will run as efficiently as possible, including response time for processing and screen flow.
There is a system option called Price Event Processing Days that is set to designate the number of days required between the current date and the effective date of a price event. This rule ensures that price changes and clearances are created and approved with enough advance timing that stores and other impacted areas can react accordingly.
However, for situations where price events were missed for one or more items or locations, emergency price events can be created. This allows you to create events that go into effect less than the standard number of processing days, which can even include the current date. A separate security privilege provides the ability to limit the users that can create these emergency events, while preventing others who have the ability to create price change and clearance events from creating emergency events. For example, if the setting for price event processing is 3 days, you will be prevented from creating or approving an event that occurs within 3 days, unless you have emergency security privileges.
When an emergency price event is created and approved the information is passed to downstream systems the next time the batch extracts are run. If the price change is to go into effect on the current date, then the item/location price in Merchandising is done on approval, along with any markdowns or markups in the stock ledger.
Whenever a price change or clearance is submitted or approved, it will be subject to the conflict checking process. This ensures that invalid prices, or prices out of alignment with your pricing strategy, are not sent down to the point of sale. Conflicts that are checked can be configured using some of the Pricing system options, which are covered in detail below. It also relies on a calculated "future retail" to help determine when a conflict has occurred.
When price changes and clearance events are approved or unapproved, they can negatively impact the retail value of an item/location when it goes into effect, which can cause conflicts. As such, the Pricing module uses these events to calculate a future retail price for the impacted items and locations on the events. This allows it to have a view to the regular or clearance price on any given day and helps facilitate the conflict checking process.
A roll-up batch ensures the system holds future retail data at the highest level possible. This batch looks at lower-level timelines and attempts to roll up to a higher level where timelines match exactly between lower levels and higher levels.
When conflicts occur, the Conflicts window displays the price event at the level of the timeline where the conflict occurred, which could be higher than transaction item and location level.
As referred to above, Merchandising shares a number of key pieces of information with Pricing, including items, locations, item/location relationships, and merchandise hierarchies. Pricing also provides Merchandising with key information. This section will outline the key data points that are shared between modules.
When regular or clearance price changes are set to go into effect, the Price Event Execution batch process integrates the new price information to update the item and stock ledger information in Merchandising. This initiates the process to update the unit retail and the clearance flag for the item/location (if needed), records the markup or markdown in the stock ledger, and records the price history for the item so that sales can be correctly classified when they occur as either regular or clearance.
Initial pricing for items is dependent upon the Initial Price Zone Definition managed in Pricing. When the department, class, and subclass are selected for the new item, the markup percent and type defined are used to calculate a suggested initial price based on the unit cost for the primary supplier that has also been defined for the item. Rounding rules are also applied, if included in the definition to calculate the suggested retail using a standard "ends in" amount.
Merchandising also relies on future retail details that are provided by Pricing to calculate item/location level margin information. Future retail, combined with the future cost calculations in Merchandising, provides the ability to show not only the current margin for an item/location, but also a view of future margin based on upcoming clearance and price changes.
Foundation information, such as merchandise and organization hierarchies, is essential to Pricing functionality. Price events ultimately impact an item, so Pricing needs to know all approved, sellable items currently in Merchandising, including their item/location relationships.
When an item is reclassified to a new department/class/subclass in Merchandising, Pricing is notified. Similarly, when an existing item is deleted in Merchandising, Pricing is notified to remove all references to that item including table clean up and removing them from existing price events.
Foundation Data and Item information are accessed directly from Merchandising to support pricing functions and allow for more streamlined communications between modules.
As noted above, new stores and virtual warehouses created in Merchandising must be added to a zone structure in Pricing to ensure that items sold in the locations can be priced according to company strategies.
When new item/location relationships are established in Merchandising, Pricing is informed to create the initial Future Retail record (for sellable, approved, transaction items) and looks to see if there are any pricing events that will be inherited by this new relationship. If any active events, such as the item/location should be on clearance due to the location's zone relationship, pricing information in Merchandising will be updated immediately. For future events, the Future Retail timeline will be established and the price event will be sent for the item at the new location to the selling systems, as needed.
When an existing item/location is deleted in Merchandising, Pricing is notified to remove all references to that item/location, including table clean up and removing it from existing price events.
The Pricing module uses a number of system options to configure the functionality, which allows you to tailor the functionality for your business, including conflict checking options, defaulting commonly used values, and data retention.
All of the following system options can be viewed and edited through the Pricing screens.
| System Options | Functional Area | Description |
|---|---|---|
|
Single UOM for All Items |
Price Changes Clearance |
When a value is designated for this system option, this value is used as the unit of measure (UOM) for all price events created and Pricing does not perform UOM validation when you create events. If a value is not selected, when you create fixed-price price changes or clearance events, either a UOM must be designated, or Pricing will attempt to derive one and will raise errors if it is not consistent amongst items in the event. |
|
Price Event Processing Days |
Price Changes Clearance |
Number of days required between the current date and the effective date for price changes and clearance. It ensures that price events are created with enough advance timing that stores and other impacted areas can react accordingly. Security will permit certain users to create price events inside this window, including creating same day price events, sometimes called "emergency" changes. This must be set to a value greater than zero. Note: this system option does not determine the communication processes to the selling systems. Default value: 1 |
|
Regular Retail Greater than Clearance Retail |
Conflict Checking |
If the indicator is checked, conflict checking will raise a conflict for the event when the retail of the clearance is greater than the regular retail for the item location. If the indicator is unchecked, conflict checking will skip this rule. Default value: checked |
|
Clearance Retail less than Previous Markdown |
Conflict Checking |
If the indicator is checked, conflict checking will raise a conflict for the clearance event when the retail of the clearance is greater than the previous markdown for the item/location. If the indicator is unchecked, conflict checking will skip this rule. Default value: checked |
|
Display Conflicts Only |
Conflict Checking |
This system option determines what details are displayed for conflicts in the Pricing screen. When this system option is unchecked all approved events that have an effective date in the ranged defined by the two options below (Records Displayed before/after Effective Date) as it relates to the effective date of the event in conflict are displayed in the Conflict Review List window. If checked, then Pricing will only display the other events that caused the conflict with the event being viewed.. Default value: Yes (checked) |
|
Records Displayed after Effective Date |
Conflict Checking |
This system option defines the number of days after the effective date of the event with conflicts for which other price events will be displayed. This option, along with Records Displayed before Effective Date, provides a window for you to see the other events that have been approved in the same timeframe as the event in conflict. It enables only when the Display Conflicts Only indicator is unchecked. Valid values: 1-99 Default value: 30 |
|
Records Displayed before Effective Date |
Conflict Checking |
This system option defines the number of days before an effective date of the event with conflicts for which other price events will be displayed. This option, along with Records Displayed after Effective Date, provides a window for you to see the other events that have been approved in the same timeframe as the event in conflict. It enables only when the Display Conflicts Only indicator is unchecked. Valid values: 1-99 Default value: 30 |
|
Run for Submit |
Conflict Checking |
This option determines whether or not conflict checking will be performed when submitting a price event for both price changes and clearance. If this system option is checked, conflict checking process will be performed when you submit a price event. Otherwise, conflict checking will be skipped and not performed until approval. Default value: No (unchecked) |
|
Parent Ranging |
Zones |
If this system option is checked, when you create a price change/clearance at a level higher than transaction item/location, there must be at least one ranged item/location combination represented. If there is not at least one, then the system will not allow you to create the event. If this system option is not checked, then ranging checks will not be performed on events created at a level higher than transaction item / location. Default value: Yes (checked) |
|
Recognize Warehouses as Locations |
Zones |
This system option controls whether warehouses will exist in zone groups/zones and if price events can be created against warehouses. When the system option is checked, warehouses can be assigned to price zones and can be used in price events. When the system option is unchecked, warehouses cannot be added to zones or events. Default value: No (unchecked) |
|
Price Change/Clearance Rejects |
Data Retention |
This field defines the number of days after the effective date of a rejected price change or clearance the event should be purged from the system. Valid values: 1- 999 Default values: 30 |
|
Clearance Groups |
Search Results |
This option limits the data that is displayed in the Clearance Group Search results to a manageable number to review. You can enter additional criteria to narrow down the list if the groups they are searching for is not returned in the initial search. Valid values: 1-999 Default value: 100 |
|
Price Change Groups |
Search Results |
This option limits the data that is displayed in the Price Change Group Search results to a manageable number to review. You can enter additional criteria to narrow down the list if the groups they are searching for is not returned in the initial search. Valid values: 1-999 Default value: 100 |
The following system defaults can be viewed and edited through the user interface. Also, there are separate options for price changes and clearance for each of these defaults, so that different values can be used for defaults by price event type.
| System Defaults | Functional Area | Description |
|---|---|---|
|
Diff Type |
Price Change Clearance |
This defines a default value for the desired default diff type in price change and clearance events. Examples of diff types are color, size, flavor, and so on. Valid values for diff type are defined as part of Merchandising Foundation Cloud Service Foundation Data. |
|
Item Level |
Price Change Clearance |
This defines the default item level that will be used when you create a price change or clearance. Valid values are Parent, Parent/Diff, or Transaction Item. If a value is not defined for this option, then Transaction Items will be used. |
|
Change Type |
Price Change Clearance |
This defines a value for the change type that will be displayed when you are creating a price change or clearance. Valid values (price change): Change by Percent, Change by Amount, or Fixed Price Valid values (clearance): Percentage Off, Amount Off, or Fixed Price Default value: Change by Amount |
|
Reason Code |
Price Change Clearance |
This defines a value for the default reason code in price change and clearance events. Valid values are dependent on the values setup in the Pricing system. |
