The new base price list for a distributor's Standard tier was approved on Monday. The commercial manager finishes entering it at 11:40 on a Tuesday and presses save. At that moment it is live. Buyers in the middle of building their orders are now looking at different rates from the ones they started with. A coordinator who quoted yesterday's rate an hour ago has an order that no longer prices as quoted. And the recalculation itself, every SKU on the list against every account on the tier, runs in the busiest stretch of the ordering day. Nobody chose 11:40 on a Tuesday. It was simply when the spreadsheet was finished.
When saving a price list is the same as switching it on.
In many ordering setups there is no difference between recording a price change and putting it into effect. The price table holds one current rate per SKU, and editing it replaces that rate for everyone, immediately. The timing of every price change is set by whoever does the data entry.
Commercial teams work office hours, and office hours are ordering hours. So the change lands while buyers are ordering and while orders taken earlier in the day are still waiting to be keyed in. Some were agreed at the old rate and will be invoiced at the new one. The difference turns up later as a disputed invoice and a credit note.
Distributors who have been through this usually find a workaround: someone stays late to enter the list after the last orders are in, or comes in early before the first. That works until the person who does it is away. The timing still depends on someone being at a keyboard at the right moment.
Effective-from: saving schedules, the clock switches.
The structural fix is to separate the two acts. Every price rule carries an effective-from date and time. Saving the rule records the change and schedules it. The rule goes live at the moment chosen, not at the moment it was saved. That holds for a rule in any of the five pricing layers, from a new base price list for a commercial tier to a manual customer override.
An immediate change is still possible. The manager sets effective-from to now. The difference is that going live on save becomes a deliberate choice, made by someone who has decided the change cannot wait, rather than the default that happens to every edit.
This also protects the ordering peak. Recalculating a base price list across thousands of buyers and SKUs is real work for the system. With a scheduled switchover it happens quietly before the effective moment, so the ordering window is never the time the pricing engine is busy recalculating a whole tier. The manager in the opening example could have saved the list at 11:40 and set it to take effect before the next morning's orders.
A price change should take effect when the commercial team decides it should, not when the data entry happens to be finished.
Two schedules for one rule: stopped at save.
Scheduling introduces a failure that a single current price cannot have. Once changes can wait for their moment, two of them can be waiting for the same rule at once. A commercial manager schedules a revised contract override for an account from the start of next month. A colleague, working from an older email, schedules a different revision of the same override for a window that starts a week earlier and runs past that date. For the days where the two windows overlap, the rule has two answers.
Two scheduled changes to the same rule with overlapping effective windows are a Conflict. In conflict detection, that is the outcome where the system cannot choose between two valid instructions, so it does not guess. The second change is blocked at save, and a person has to decide which window is right before either takes effect. Neither the later save nor the larger discount wins by default.
Where that block sits matters as much as the block itself. It happens at save, in front of the person who made the change, while the context is still fresh and before any buyer has seen either price. The alternative is finding it when finance queries an invoice weeks later, and reconstructing from email which change was meant.
Whose clock: stored in UTC, shown in local time.
A scheduled change is only as precise as the clock it is written against. "Effective from 06:00 on the first" means one moment in Cairo and another in Riyadh, and the gap between the two cities is not constant. Egypt observes daylight saving time and Saudi Arabia does not, so for part of the year the two clocks read the same hour and for the rest of the year they do not.
Consider a food manufacturer with its commercial team in Cairo and accounts on both sides of the Red Sea. The team prepares a new price list and agrees, by email, that it takes effect at 06:00 on the first of the month. The Cairo team reads that as Cairo time. A colleague handling the Saudi accounts reads it as Riyadh time. For part of the year they are describing the same moment, and for the rest they are not, and nothing in "06:00" says which applies. Whichever reading is wrong, the list goes live at a moment nobody chose.
The resolution is to separate how the moment is stored from how it is shown. Effective-from is stored in UTC, so every scheduled change refers to one unambiguous instant rather than a local hour that depends on who is reading it. It is displayed in the tenant's local timezone, so the person who scheduled it reads it on the clock they work by.
Why the switchover belongs in the pricing engine.
A price change made by editing a table is an event nobody scheduled. A price change made by saving a rule with an effective-from time is a decision with a moment attached to it. The commercial team chooses when a list goes live. The ordering peak stays clear of recalculation. Overlapping schedules for one rule are stopped at save, and the moment of switchover means the same thing in Cairo as it does in Riyadh.
It also closes a gap in the price promise. Because a scheduled change cannot raise a price in a buyer's open cart without that buyer being told, the rate the buyer is shown is the rate applied on the invoice, and no pricing rule changes between checkout and invoice. How the buyer is told is a subject of its own.
That is how pricing works in Emdaad: every rule in the five pricing layers carries its own effective-from time, and conflict detection covers changes that are scheduled as well as rules already in effect. The list goes live at the moment the commercial team chose for it.