A scheme is a label, the price is on the item — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever at GadgetSphere owns the price lists and has at some point stared at a pricing scheme record wondering why it has price boxes on it that never seem to do anything. In about twelve minutes you will know exactly which record holds the number a sales invoice uses, and which three things that look like they hold prices do not.

Step 1 — See what a pricing scheme actually is

After this step you will know what you created when you created a scheme. GadgetSphere runs three: Retail for the twenty-two branches, Member for the loyalty customers, and Wholesale for the distribution company’s corporate clients. Each of those is a label. It carries a code, a name, a description and some housekeeping, and it carries no price for any item. The prices live somewhere else entirely: on each item, on its Pricing Scheme tab, as one record per scheme, item and unit of measure. Five thousand two hundred items across three schemes is up to fifteen thousand six hundred of those records, and every one of them is where a real number is kept.

Reference: Doc Item Maintenance — Pricing Schemes

Step 2 — Ignore the price boxes on the scheme itself

After this step you will stop trying to use six columns that do nothing. The scheme record does have its own sales and purchase unit, minimum and maximum price columns. Nothing in the platform ever writes them and nothing reads them. About thirty document applets carry a copied Pricing Details panel whose Unit Price column is bound to one of those columns, so that column renders permanently blank and clicking its rows does nothing at all. The data agrees with the code: measured across all ninety tenant databases, the scheme header’s sales unit price is null on all one thousand five hundred scheme records, in all sixty-eight tenants that have any. Every price any document has ever used came from the per-item records.

Reference: Doc Item Maintenance — Pricing Schemes

Step 3 — Understand the parent tree before somebody proposes it

After this step you will know why a scheme hierarchy will not give you what people expect from one. A scheme can name a parent. When it does, linking an item to the child creates a price record on the child and on every ancestor, at that moment. That is a fan-out at creation time, not an inheritance at read time. Nothing anywhere looks up a parent scheme when a child has no price for an item, so a price you edit on the parent afterwards never reaches the children. In practice nobody has met this: the parent field is empty on every one of those one thousand five hundred scheme records, in every tenant. If somebody asks for Retail-minus-five-percent, the tree is not the answer.

Reference: Doc Item Maintenance — Pricing Schemes

Step 4 — Use the mechanism that does exist

After this step you will know how a second price list actually gets built. The scheme’s Copy tab duplicates every item price from another scheme in one pass, optionally with an amendment, which is how Member becomes Retail minus five percent across five thousand two hundred items instead of item by item. What it carries is the prices, the promotion price and the quantity bands. What it does not carry is the e-invoice block on each price record, which the copy job does not touch. It is also a one-time copy, not a link: after it runs, the two lists are independent and drift apart at whatever speed you let them.

Reference: Doc Item Maintenance — Pricing Schemes

Step 5 — Know which of the three pricing tools reaches a line

After this step you will stop mixing up three things that all look like pricing. A pricing scheme gives the same item several standard prices. A price book sits on top and applies conditional discounts and points. And each item has an Entity Pricing tab that offers a price per named customer or supplier. The scheme is the one a selling document reads. The price book acts after it. And the sales half of Entity Pricing is stored, exported, and read by nothing that prices a sales line, because the query the selling applets call has no customer field at all. Its purchase half is real, and feeds replenishment.

Reference: Doc Item Maintenance — Entity Pricing tab

Step 6 — Take away the one sentence that matters

After this step you will have the sentence to give anyone who asks. A scheme names a price list; the item holds the price; and the record that joins them, one per scheme, item and unit, is the only thing a document ever reads. Everything else on this surface is either a tool that acts afterwards, like a price book, or a column that looks like a price and is not, like the six on the scheme header. The rest of this series follows a single number from that record onto a finished invoice line, and every surprise on the way comes from something between the two.

Reference: Doc Item Maintenance — Pricing Scheme tab

How the steps fit together

    flowchart LR
  S["Pricing scheme<br/>a label: code and name"] -. "names, holds no price" .-> L
  I["Item"] --> L["Price record<br/>scheme + item + unit<br/><b>the number a document reads</b>"]
  L --> D["Document line"]
  PB["Price book"] -. "acts after" .-> D
  EP["Entity Pricing<br/>sales half"] -. "read by nothing<br/>that prices a sale" .-> D
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Which price list the document opened with · Back to the series · Play this as a presentation