Nobody should have to remember what this customer pays.
Special pricing in Accredo Saturn is a rules engine: agreements, contract prices and volume breaks held as data and resolved automatically at the moment a line is priced, on every quote, order and invoice. Set up properly it is the difference between a price list the business can explain and a set of discounts three people carry in their heads.
Personal reply from Andrew within one business day.
What is special pricing in Accredo Saturn?
Special pricing is Accredo Saturn’s rules engine for every price that is not the standard sell price. A rule says who it applies to, what it applies to, what it does to the price and when it is in force — and the product resolves it as each line is priced, rather than by rewriting price lists in advance.
Four parts make up a rule, and naming them is worth the effort because almost every argument about pricing turns out to be a disagreement about one of them: a scope (who it is for and what it covers), an effect (what it does to the price), a window of dates it is in force for, and a precedence deciding what happens when more than one rule matches the same line.
The important phrase is at pricing time. This is not an overnight job that stamps new numbers onto a price list and hopes nothing changes before morning. Rules are evaluated as the line is entered, so the price on the quote is the price on the invoice, and a rule changed this afternoon applies to the next line typed. They also live in the company data with everything else — same permissions, same backup, same restore as the ledger they price against. That is the entire reason the spreadsheet currently holding these agreements is not a like-for-like alternative, however carefully somebody maintains it.
A single agreement is configuration; a pricing structure is a project. One customer on one negotiated rate is an afternoon and needs nobody technical. What turns pricing into an engagement is interaction: dozens of agreements that overlap, categories that mean slightly different things in different parts of the business, and promotions that must stack with some rules and not others.
Where should a pricing rule live?
Two questions settle it, and neither is technical. Can the rule be stated as who gets what, on which products, until when? And who needs to be able to change it — somebody in the business, or somebody who writes code?
| Saturn’s own rules | A scripted engine | Outside the ERP | |
|---|---|---|---|
| What it is | The product’s built-in special pricing: rules set up through the standard screens, no code involved. | A script that prices lines against definitions you hold in Saturn, for conditions the standard rules cannot express. | A spreadsheet, a CRM field or a pricing product of its own, holding the agreement outside the ledger. |
| What it fits | Anything expressible as who, what, how much, until when — including volume breaks and category-level matrices. | Rules that depend on the rest of the order, on trading history, or on an attribute the pricing rules cannot see. | Prices that are genuinely negotiated per deal, or that belong to a system that properly owns them. |
| What you get without building anything | Resolution on every quote, order and invoice, maintainable by the people who negotiate the agreements. | Nothing. It is a build, and it needs definitions, precedence and a way for the business to maintain it. | Whatever that tool does well today, immediately, with no setup inside Saturn at all. |
| What it will not do | Express a condition it has no vocabulary for — what else is on the order, or what the customer bought last year. | Maintain itself. A script nobody but its author can change is a dependency, not an asset. | Price anything automatically. Somebody reads it and types the number, on every order, forever. |
| What it costs to own | The agreements themselves, kept current. The mechanism needs no looking after. | A definition to keep true, precedence to keep documented, and a regression test whenever pricing changes. | Nothing to build and everything to run — the cheapest option to start and reliably the most expensive to have started. |
| Best for | The large majority of real pricing requirements, and always the first thing to try. | The genuine remainder, once the standard rules have been established as insufficient rather than assumed to be. | Deals decided by a person with authority, where the system’s job is to record the decision rather than make it. |
// Who, what, how much, until when? Standard rules. Depends on the rest of the order? A script. Decided by a human every time? Then let a human decide it.
Start with the rules the product already has, and mean it. The most common expensive mistake here is not a bad script — it is a script that never needed to exist, written because nobody spent an afternoon establishing what the standard rules resolve on their own. A requirement should be shown to exceed them, specifically and in writing, before anybody proposes code.
The third variation is the signal. When a scripted rule is genuinely justified, the first one arrives as a single special case — one promotion, one customer, one product group — and writing it as a self-contained script is entirely reasonable. The second arrives as a copy of the first with the constants changed, which is still survivable. The third is the one that matters, because by then the pattern is clear and the choice is between a fourth copy and one engine reading definitions from a table. Making that turn at the third variation rather than the eighth is what separates a pricing engine somebody can maintain from a folder of near-identical scripts that all have to be found and edited when one rule changes.
Where the answer is the third column, that is not a failure either. Plenty of pricing is a negotiation, and a rules engine that pretends otherwise produces a system people fight rather than use. What matters is that the decision is recorded somewhere the ledger can see, rather than agreed on a phone call and remembered differently by two people — which is a question about how systems talk to each other, and the systems and API integration page takes it properly.
What can a special pricing rule actually resolve?
Considerably more than most sites use. The ceiling people run into is usually not the engine’s — it is that nobody ever mapped the agreements properly, so the rules were set up for the handful of cases somebody could remember.
Scope does the heavy lifting. A rule can be aimed at a single customer, at a group who trade on the same terms, or at a type of account, and it can cover a single product, a category or an entire group of them. The combination is what makes the useful shape possible: a matrix of price levels, one per product category per customer, which is what a large share of distribution agreements actually are once written down. That matrix is dull to look at and it is the workhorse — it lets a business onboard a new account by setting a dozen entitlements instead of negotiating every product line individually.
The effect can be a price, a reduction or a level — an absolute price, a percentage or amount off the standard one, a margin worked from cost rather than sell, or simply which price level this customer is entitled to on this category. Volume breaks sit on top of any of them: quantity thresholds where the rate changes, so the tenth unit prices differently from the first without anybody watching for it. And because rules carry dates, a promotional rate can be set up in advance and expire by itself — worth more than it sounds, since the most common way a discount becomes permanent is that removing it was somebody’s job and they left.
Where it stops is worth knowing before you scope. The standard rules evaluate a line against the pricing data; they do not evaluate it against the rest of the order, against trading history, or against a product attribute that lives outside pricing. So a rule saying three of these and one of those, together, earn a fourth free, or this rate applies while trailing twelve-month volume stays above a threshold, is past the boundary. Both are entirely buildable, and both are event scripting rather than configuration — a different estimate and a different maintenance story, worth deciding deliberately rather than discovering halfway through.
What does a pricing engine project involve?
Five things, and only the third is what people picture when they ask for one. Writing the engine is the small part; agreeing precedence and proving the answers against orders that have already been invoiced is most of the work and all of the risk.
-
01
Write the rules down
Each one in a sentence: who gets it, on what, what it does, until when. The sentences nobody can finish are the most valuable output of the whole stage.
breaks here if: a rule exists only as “we look after them”, and gets automated at whatever the last invoice happened to say -
02
Settle precedence
Decide what wins when two rules match the same line, and whether anything stacks. Write it as an ordering, not as an intention.
breaks here if: two rules both match, the answer is whichever was found first, and no one can explain a price to a customer -
03
Model it as data
Definitions in a table the business maintains, read by one engine, with a screen to edit them. Not one script per agreement, however reasonable the first one looked.
breaks here if: the third variation arrives as another copied script, and one rule change now means finding four files -
04
Stamp what it did
Record on the line which rule priced it, at the moment it is priced, so the invoice carries its own explanation downstream into the ledger.
breaks here if: it is skipped, and nobody can say what the agreement cost without re-deriving six months of orders by hand -
05
Prove it on real orders
Run it against orders already invoiced and compare line by line against what was actually charged. Every disagreement is a finding, not noise.
breaks here if: it goes live on faith, and the first person to notice the defect is a customer reading an invoice
Step four is the one everybody skips and everybody later wants. When a rule decides a price, record which rule it was, on the line, as it happens. It is close to free at the time and cannot be reconstructed afterwards with any confidence, because reconstruction means re-running today’s rules against last quarter’s orders and hoping nothing was edited in between. With the stamp in place, “did that promotion make us any money” is a query; without it the honest answer is that nobody knows, and the argument is settled by whoever is most confident rather than by the data. Where the stamp sits on a field the product already carries forward from the order to the invoice, attribution follows the paperwork into the ledger with nothing scripted to move it — and from there it is a reporting question rather than a forensic one.
A rule that fires when an order is saved will fire again when that order is edited. This is the defect that catches every first pricing engine, and it is a design decision rather than a bug to be found later. Real orders get split across locations, part-shipped, re-opened and saved four more times before anybody invoices them. A rule that adds a line or changes a price therefore has to do one of two things: recognise its own previous work and re-derive the correct answer from the current state of the order, or record that it has already run and decline to run twice. Both are legitimate and they suit different rules. Choosing between them before writing the engine is the difference between something clean and a year of tickets that all begin with the discount having been applied twice.
In practice it starts with a spreadsheet and whoever prices things now. The spreadsheet is the most useful artefact available — a working specification written by the people who need the answer, exceptions included — and the inconsistently filled rows are where the real rules are hiding. What gets handed over is the definitions, the engine that reads them, the screen the business maintains them through, and a document stating the precedence order in plain words. The Accredo Saturn capability page covers the rest of the toolbox this works with, and the definitions themselves usually live in a custom table built for the purpose.
Pricing that only two people fully understand? Describe it — the audit is free, and often the answer is that the standard rules already do it.
Book a free process auditCan Accredo pricing rules be seen and changed outside Saturn?
Yes, and it is one of the more valuable things to do with them — subject to a design rule that is not negotiable: Saturn stays the only place the rules actually live. Everything else is a window onto them, never a second copy.
The problem is usually that the pricing is correct and invisible. The rules resolve properly on every invoice and the people selling cannot see them. A rep quoting on site works from memory or a printout; the CRM shows a company record with no indication of what that company is entitled to. The ledger is right, and the information is nowhere near the point where it would change a decision — a distribution problem rather than a pricing one.
The pattern that works is read from the ledger, write back to the ledger, and never hold a second copy. A card on the CRM record, or a screen in a field sales tool, showing live entitlements and writing changes straight back into Saturn where they take effect immediately. The temptation is always to cache it somewhere for convenience, and the moment there are two stores of the same agreement there is a reconciliation job that never ends and an invoice that eventually disagrees with what a rep promised. One source of truth, with as many windows onto it as are useful.
One constraint is worth checking before promising a date. Not every part of the pricing area is published on Saturn’s web service, and which tables are published is discoverable from the service’s own metadata in about a minute. Where something is not exposed directly the route is still open: reads go through a query and writes through a server-side script invoked over the service, which is well established and works reliably. It is simply a different estimate from a plain record write, and finding that out during the build rather than the scoping is how a two-week integration becomes a four-week one. The Accredo API and OData integration page covers what the service exposes and where it stops; where the window itself has to be built, that is a custom app.
When is special pricing the wrong answer?
More often than a consultant selling pricing engines is supposed to say. Four cases account for nearly all of it, and the first does by far the most damage.
When nobody can state the rule. “We look after them” is not a pricing rule, and automating it is really a request to make it permanent and give it the authority of a system. The finding, more often than is comfortable, is that two or three accounts trade on rates nobody in the room would agree to today and everyone assumed somebody else had approved. Worth discovering — but it is a commercial conversation, not a build.
When the price structure itself is the problem. If the levels overlap, or a category means one thing in one branch and something else in another, a rules engine on top resolves the wrong answer faster and more consistently than a human did. Restructuring the price list first is unglamorous, frequently unpopular, almost always the higher-value half of the project, and it makes the automation afterwards smaller.
When it is genuinely a negotiation. Some prices are decided per deal by a person with the authority to decide them, and a system should not pretend otherwise. The useful design makes the standard case automatic and leaves the deal to the human, with the override recorded and visible rather than hidden inside a typed-over number.
When the exceptions outnumber the rule. If a large share of orders need somebody to intervene after the engine has priced them, the rule implemented is not the rule the business runs on. That is a signal to go back to the first stage and find the real one, not to add conditions until the overrides stop.
Questions about Accredo special pricing.
What is special pricing in Accredo Saturn?
Special pricing is Accredo Saturn’s rules engine for any price that is not the standard sell price. A rule has a scope (which customers or customer groups, and which products or categories), an effect (a fixed price, a discount, a margin over cost, or a price level), a date window, and a precedence that decides what happens when more than one rule matches. Rules are resolved as each line is priced rather than by rewriting price lists in advance, so the price on the quote is the price on the invoice.
What is an SP script in Accredo, and when do you need one?
An SP script is code that prices lines for conditions the standard special pricing rules cannot express — typically rules depending on the rest of the order, on trading history, or on an attribute the pricing rules cannot see. You need one considerably less often than it is proposed: the standard rules already handle customer and group scope, category and product scope, volume breaks, date windows and priority, and a requirement should be shown in writing to exceed those first. When a script is justified, build one engine reading rule definitions from a table the business maintains, not a separate script per agreement.
Can Accredo handle contract pricing and volume breaks?
Yes, both, without code. Contract pricing is a rule scoped to a customer or customer group with a start and end date, so an agreement applies for its term and expires by itself. Volume breaks are quantity thresholds where the rate changes above a given quantity. The two combine, so a contracted customer can have negotiated rates that also improve with order size. The common shape in distribution is a matrix of price levels — one entitlement per product category per customer — which lets a new account be set up with a dozen decisions instead of a negotiation on every product.
Can special pricing rules be viewed or updated from outside Accredo?
Yes — from a CRM record, a field sales tool or a web app — provided Saturn remains the only place the rules live and everything else reads and writes through it. Holding a second copy anywhere creates a reconciliation job that never ends. One practical check belongs in the scoping: not every part of the pricing area is published on Saturn’s web service, and which tables are published is discoverable from the service metadata. Where something is not exposed directly, reads go through a query and writes through a server-side script invoked over the service — reliable, but a different estimate from a plain record write.
How do you tell whether a pricing agreement or promotion actually made money?
By recording, on each line, which rule priced it — at the moment it is priced. That stamp costs almost nothing then and cannot be reconstructed afterwards with any confidence, because reconstruction means re-running today’s rules against orders that may have been edited since. With attribution in place the question is a query against invoiced lines; without it, the answer is an argument settled by whoever sounds most certain. It is the most commonly skipped stage of a pricing project and the one clients ask for first, usually about three months after go-live.