Sales & Distribution
Orders, deliveries, billing, and the pricing underneath
Orders, deliveries, billing documents and the pricing conditions underneath them, read at header or line level, in the currency each document was written in.
See it answer one of theseAsk it
Questions you can ask on day one
Asked in plain language. Each answer prints the SAP entity, field and period it was computed from, underneath the figure.
- “Which products are declining fastest, quarter on quarter?”
- “How much discount did we give last month, by condition type?”
- “Why is sales order 5000001 blocked?”
- “Which customers have not ordered in 90 days but used to order monthly?”
- “What is our average order value by sales organisation this year?”
- “Show me open orders past their requested delivery date”
- “What did we bill against what we shipped last month?”
What it reads
The sales objects behind an answer
Sales orders
Header and item level, with net value, currency, sales organisation, division and the blocks and statuses that explain why a document is stuck.
Deliveries
Outbound delivery headers and items: what was picked, what shipped, and when, against what the order asked for.
Billing documents
Invoices, credit and debit memos, with billed value by customer, organisation and period.
Pricing conditions
The applied pricing elements on an order item, condition type by condition type, which is where discount actually lives.
Document flow
The link from an order item to its delivery and its invoice, with the status at each hop: a real SAP relationship, not dates matched by inference.
Customer and material master
The attributes a sales figure needs to be grouped by something a person recognises.
Why it is hard
What no standard report does for you
Discount is not a field on the order
It sits on the pricing condition, by condition type, in the document's own currency, and which condition types represent a discount is a configuration decision your business made years ago. A tool that sums net value and labels it discount returns a real number about something else.
Almost every useful question is a comparison
Not what did we sell, but what changed. Standard reporting answers one window at a time, so the comparison happens in a spreadsheet, by hand, differently each time, by whoever was asked.
A line inherits its header's date
Item-level entities often carry no creation date of their own, so a question about what was ordered in a period has to reach the header for the date and the item for the quantity. Getting that wrong produces a figure that is quietly scoped to nothing at all.
What makes SD questions awkward
Sales data looks like the easiest thing in SAP to report on, and it is the module where the gap between a number and the number you meant opens widest.
The reason is that the interesting quantities are assembled rather than stored. Discount is a set of conditions. Margin is sales minus a cost that lives in another module. “Declining fastest” is two windows and the difference between them. None of those is a column anybody can point at, which is why they end up in a spreadsheet maintained by one person who understands the conventions.
Where each figure comes from
Every answer prints the entity set it read, the field and aggregation behind the number, the filter applied and the window covered. On the sales side that matters more than anywhere else, because the surface is dense with near-identical entities: there are dozens whose names contain some form of “sales order”, and a figure computed correctly from the wrong one looks entirely normal.
Document flow, not inference
“Where did this order get to” is a real relationship in SAP: order item to delivery to billing document, with a status at each step. AnrilX reads that relationship rather than inferring it from matching dates and quantities, which is the approach that works until the month somebody ships two orders to the same customer on the same day.
In more detail
What makes Sales hard to report on
The order is not the revenue, and the gap is where the arguments happen
A sales order carries a net value, and it is not what you will be paid. Between the two sit condition records, rebate accruals, credit memos, returns and whatever was agreed on the phone and typed into a header discount. Ask for revenue by customer and the honest answer depends on which of those you meant to include, which is why two people pull the same report and get different numbers, and why neither of them is wrong. AnrilX answers at the grain you asked for and prints which one that was, so the disagreement happens over a stated definition rather than over two spreadsheets.
Pricing lives at item level, and margin questions do not
Conditions attach to the item. Questions about discount leakage attach to a customer, a material group or a sales organisation, which means every useful pricing question is an aggregation across a grain change, and the moment a header-level condition enters, a naive sum double-counts it. This is the single most common way an SD report is quietly wrong, and it is invisible because the total still looks plausible.
Rejected and blocked items still have values
A line with a rejection reason keeps its net value in the table. So does an item behind a delivery block or a credit block. Whether they belong in your figure depends entirely on the question: a pipeline number probably excludes them, a demand signal probably does not, and an order-intake figure for the board almost certainly has a house rule about it. There is no default that is right for all three, so the filter is stated under the answer rather than assumed.
Dates: which one did you mean
An order has a document date, a requested delivery date, a confirmed date and a billing date, and a question about \"last month\" silently picks one. Month-end is where the choice becomes visible: an order created on the 30th and billed on the 2nd belongs to different months depending on which date the report used. The period token and the field it resolved against are both printed, because the difference is the whole of the variance somebody will ask you to explain.
One of these questions, answered
Which customers have not ordered in 90 days but used to order monthly?
Nine customers, worth 41.2m SAR over the twelve months before they stopped. The filter “no order in 90 days” on its own returns 2,340 accounts, most of which never ordered monthly; the ones below are those whose own history says they should have ordered by now.
Source: zsd_sales_order / ZA_SalesOrder · CreationDate and SoldToParty · median interval per customer over the 12 months before the last order · compared to days since
Assumed: monthly means a median interval of 35 days or less across at least six orders. Accounts with fewer than six are excluded; there is no cadence to have broken.
Where it stops
What it will not answer here
The limits particular to this module. Worth knowing before a pilot rather than during one.
-
Late-delivery arithmetic across two date fields is approximate, and the answer says so rather than presenting a clean number.
-
Whether credit memos and returns are netted into a sales figure is a convention, not a fact. The answer names the document types it counted rather than choosing one for you.
-
Reads are bounded. Where more rows exist than were returned, the answer states it instead of implying the figure is complete.
Questions people ask us
Can it tell us why a specific sales order is blocked?
Yes. It reads that document whole (its statuses, its blocks, and its flow onward to any delivery and invoice) and reports what it finds. Where no block exists it says so rather than offering a nearby field that looks like an explanation.
Does it handle discount properly?
It reads the applied pricing elements and groups by condition type, splitting by currency, and names the condition codes it counted, so you can see whether it counted the ones your business treats as discount.
Can it compare periods?
Yes, and the delta is computed in code rather than asserted. A group that appeared shows as new and one that vanished shows as gone, instead of dropping out of the comparison unseen.
Questions often cross into
Purchasing, read at the grain the money sits on
Purchase orders and their items, goods movements, supplier invoices and info records, with spend sitting on the item, where it actually lives.
Variance, margin, and what actually moved them
Cost centres, internal orders, profit centres and the postings behind them: variance against plan, with the drivers ranked rather than asserted.
Where stock is sitting that nobody ordered
Stock by location, movement history and ageing, including the stock nothing has asked for, which no standard report puts in front of you.
Bring the question your reports cannot answer
Thirty minutes against a live SAP system we provide: no access to yours, nothing to set up. If it cannot answer, you find that out in half an hour rather than three months into a pilot.