Making Pricing Changes Safely in RPM
A change management guide for RPM administrators after the RPM system is configured and running.
Significant pricing changes carry real risk. If a calculation is configured incorrectly, every affected order may use the wrong price until the issue is discovered.
This guide explains how to stage, test, implement, and maintain RPM pricing changes so that major updates can go live with confidence.
The guiding principle is simple: prove the change before you trust it, and keep the system clean enough to recognize when something is wrong.
- Stage Changes in a Parallel Schedule
Do not make significant changes directly to your live Master Schedule. Instead, create a separate schedule for the new configuration and leave the current Master Schedule unchanged while testing.
After the new schedule has been fully tested, switch the Master designation:
- Clear the Master option on the current Master Schedule.
- Select the Master option on the new schedule.
This approach provides an immediate rollback option. If an issue is discovered after the change goes live, you can restore the previous configuration by switching the Master designation back to the original schedule.
- Build a Test Scenario Library You Can Trust
A small number of Test Scenarios may not provide enough coverage for a major pricing change. Depending on the size and complexity of the configuration, you may need dozens or even hundreds of Test Scenarios.
Each Test Scenario should include an Expected Unit Price.
A test without an expected value confirms only that RPM returned a result. It does not confirm that RPM returned the correct result. The expected price turns the Test Scenario into a meaningful validation.
Include Test Scenarios that cover:
- Items with exceptional or nonstandard pricing.
- Every filter condition, including one test where the filter is met and another where it is not met.
- Every calculation used in the pricing configuration.
- Important customer, item, quantity, date, unit of measure, currency, and location combinations.
- Known edge cases and unusual transaction conditions.
The larger the change, the more complete the test coverage should be. A change that affects Master pricing should be tested against every known edge case.
- Generate Tests from Real Transaction Data
Diagnostic Logs are one of the fastest ways to create a meaningful Test Scenario library.
Diagnostic Logs contain actual pricing requests from real transactions. This makes them valuable test material because they represent combinations of customers, items, quantities, dates, and other values that have already occurred.
Generate Test Scenarios from recent Diagnostic Logs to validate the updated configuration against real-world pricing activity.
- Test the Staged and Live Versions Side by Side
When testing a new schedule, enter the staged schedule in the Limit to Schedule field on the Test Scenario. This ensures that the test runs specifically against the staged configuration.
Consider maintaining two versions of each important Test Scenario:
- One that runs against the current live configuration.
- One that runs against the staged schedule.
Running the tests side by side shows exactly how the returned price changes before the new configuration is made live.
Small changes in the ending price may be intentional. Reviewing those differences before go-live confirms that the staged schedule is producing the expected results.
- Use Date-Specific Tests as Long-Term Bellwethers
When historical pricing data is retained in RPM, Test Scenarios that use fixed historical dates should consistently return the same result because their inputs do not change.
These scenarios can serve as early warning indicators. If a previously successful date-specific test suddenly fails or returns a different price, something in the pricing configuration may have changed unexpectedly.
To create a test using current data:
- Copy an existing Test Scenario.
- Update the transaction date.
- Run the test.
- Confirm that the returned result is correct.
- Select Set Expected to Returned to save the returned value as the new expected result.
The copied scenario can then be used as an ongoing validation test.
- Keep the Pricing Configuration Clean
Complexity makes a pricing configuration more difficult to understand, test, and trust. Over time, schedules and calculations may remain in the system even though they are no longer used.
Review the configuration regularly and remove unnecessary components.
- Investigate calculations that do not modify the price. A calculation that consistently returns no change may be obsolete, incorrectly configured, or no longer applicable.
- Review unusual calculation settings. For example, a rounding rule on a percentage-based calculation may indicate that the calculation needs further review.
- Remove unused schedules and calculations. Export them before deletion so they can be restored later if necessary.
- Run the full Test Scenario library after cleanup. Confirm that removing unused records did not affect expected pricing.
- Use clear names and descriptions. Anyone reviewing the configuration should be able to understand what each schedule and calculation does and why it exists.
A configuration that is difficult to understand is also difficult to maintain safely.
- Understand How Percentage Calculations Stack
Percentage-based calculations behave differently depending on whether From the Base Starting Price is selected.
For example, assume the starting price is $100 and two 1% calculations are applied.
From the Base Starting Price is cleared
Each calculation uses the current running price.
- Starting price: $100.00
- First 1% calculation: $1.00
- Running price: $101.00
- Second 1% calculation: $1.01
- Final price: $102.01
From the Base Starting Price is selected
Each calculation uses the original starting price.
- Starting price: $100.00
- First 1% calculation: $1.00
- Second 1% calculation: $1.00
- Final price: $102.00
The difference may be small on a single transaction line, but it can become significant across a large number of transactions.
Determine which behavior matches the intended pricing method and configure the option deliberately.
Final Consideration
A pricing configuration that cannot be thoroughly tested cannot be fully trusted.
Staging changes, validating expected results, testing real transaction data, maintaining rollback options, and removing unnecessary complexity make it possible to understand exactly how a pricing change will behave before it reaches customers.