A price change is a permanent change to the retail price of an item. When a price change is created, the following occurs:
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.
Optionally (based on the 'Allow Multi Unit Pricing') multi unit price changes are supported with or without changes to the single unit 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
You can use rounding rules to move the new price to established price points, or to round the price. When a price change is added, it must go through a series of checks before it can be applied to an item/location. Depending on your user role, you may not be able to move the retail price to the next status. A change to submitted or approved status, or from approved back to worksheet, results in a conflict check.
The 'Allow Multi Unit Pricing' system option allows a retailer to maintain multi unit pricing for items through the price change process. When this system option is set, multi unit price changes can be created through the Price Change Wizard dialog, and can be edited through the Price Change Edit popup called from the Price Change Group screen.
Price change groups are used to group together multiple price change events for easier management. Mass maintenance including mass approval of the price change is supported within the price change group.
When price change events are approved, they are made available in advance of their effective date to multiple downstream systems for ticketing, and to prepare selling locations for 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' price change is entered and executed by an authorized emergency user. Once the emergency price is received by the selling system (for example, POS or ecommerce) it will overlay the other retail price that was received previously.
Note:
When the Reset Clearance with Price Change system option is set, executing a price change will imply that the item is also no longer on clearance when the price change goes into effect.When creating price changes 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 Cloud Service 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 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 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 Foundation Cloud Service is done on approval, along with any markdowns or markups in the stock ledger.
Whenever a price change 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 Cloud Service 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 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 Cloud Service 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 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.