There are thirty-six entity sets in a typical SAP system whose name contains some form of “sales order”. A model asked which one holds your discount figure will pick a plausible one. We have written before about why that goes wrong and what to do about it structurally. This is the other half of the answer, and it is not an engineering problem at all.
The schema is not the decisions
Your SAP system is not a database with business meaning attached. It is a record of decisions: hundreds of them, taken over years, by people solving a problem in front of them.
Which condition types count as a discount is one of those decisions. So is what
AdditionalCustomerGroup3 was created to hold. So is the plant that was decommissioned in 2019,
never deleted, and still carries stock movements that nobody wants in a total.
None of it is in the metadata. The entity sets are there, the field names are there, the data types are there. The reasoning is not, because there was never a field to put it in. A model reading the catalogue sees the complete shape of your system and none of its meaning, and the gap between those two things is exactly where a plausible wrong answer comes from.
What “generic” costs you specifically
An assistant that does not know your configuration has three options when it meets one of these decisions, and all three are bad.
It can guess. This is the common one, and it is the worst, because the output is well-formed. A figure computed from the wrong condition types is a real number, correctly aggregated, over the right period. Nothing downstream can catch it.
It can ask. Better, and unusable at volume. Nobody wants a system that interrupts every question with a clarification about pricing procedure configuration they would have to go and look up.
It can refuse. Honest, and it makes the product useless for precisely the questions that were worth asking: the ones where a standard report already failed you.
The three-way choice is not a design flaw in those assistants. It is what you get when the system meets the question with no prior knowledge of the system it is querying.
Reading the blueprint is the fourth option
There is a fourth, and it happens before anybody asks anything.
An SAP team reads how the system was actually built. The Business Blueprint says what each process was configured to do and why. The configuration says what it actually does now. The customisations and Z-objects say where the standard stopped being enough. Those three together are the decisions, written down, by the people who took them.
The platform is tuned to that. Your catalogue, your fields, your naming, your conventions. It answers from how your SAP was built rather than from how SAP ships, which means the question about discount resolves to the condition types your pricing procedure actually treats as discounts, and the answer prints which ones it used.
That last part is not incidental. Tuning without provenance is just a more confident guess. Every figure still carries its source, and the assumption line is where a tuning decision becomes checkable rather than trusted.
This is not bespoke software
The obvious objection: does that mean a separate build per customer, maintained forever?
No, and the distinction matters. The platform is the same platform. What differs is the catalogue it is tuned against and the conventions it answers by: configuration, not code. The same property is why an app in this system is something you describe rather than something you wait for a release to get: a capability expressed as configuration can be changed by changing the configuration.
What you are buying is not a customised product. It is a product plus the work of teaching it your system, done once, by people who have done SAP implementations before.
The honest cost
It is slower to start than signing up for something.
An assessment, a document-gathering phase and a tuning pass sit between you and the first answer, and none of them can be skipped by being clever. If what you want is a chat box against SAP this afternoon, this is the wrong product and the market has several of the other kind.
What you get for the wait is the thing that turns out to matter on the questions worth asking: an answer computed from your definitions, not from SAP’s defaults, with the definition it used printed underneath.