The SAP Condition technique
Conditions have many uses in SAP. The easiest to understand or to
relate to is usually in Pricing, where conditions are used to specify the many
components of a price (base price, surcharges, discounts, freight, taxes
etc). These components may differ for different customers, materials,
regions - in fact they may differ in a lot of ways depending on the particular
businesses requirements. We may give a customer in West Australia a better price
or discount for a product than a customer in NSW for example.
We start with a procedure which I think of as a
"spreadsheet". This "spreadsheet" tells the system the
calculations to do and the order in which to do them to calculate the final
price or cost of an order item. Each type of calculation is specified by a
condition type. In other words the condition type is simply telling
the system what kind of calculation to do (a flat amount or a percentage for
example). It does not in itself say what numbers to use.
| Procedure (Spreadsheet) |
| Line Number |
Condition Type (Calculation Type) |
Based On Line |
| 10 |
Price |
| 20 |
Discount |
20 |
| |
Total |
When an order is entered into the system, the system knows a whole lot of
information (everything it can get from the customer master, the material master
and whatever was entered on the order itself).
It first works out which procedure to use (using procedure determination
configuration). Then for that procedure, it needs to look up what numbers
to use for the calculations in the "spreadsheet". IE: what
prices apply here, what discounts, what taxes for this customer, material etc.
For each condition type (or calculation type), there can be lots of records
in the system with numbers (e.g.: lots of different prices). The system
needs to know which is the right record (or price) and in which order should it
look for the right record. The configuration lets us specify an "access sequence" for each
condition type. The access sequence tells the system in what order to
should "access" or look for records.
For example for the 'PRICE' condition type it may have the following order:
| 'Price' Access (Look Up) Sequence |
| Description |
Table |
| Region / material |
100 |
| Customer Group / material |
120 |
| Material |
200 |
So the system will first look in table 100 which is keyed by region and
material, and will look last in table 200, which is keyed just by material.
Each condition table will have some condition records (master data).
For example table 100 may have:
| Region |
Material |
Price |
| WA |
X |
10 |
| NT |
X |
12 |
Table 120:
| Customer Group |
Material |
Price |
| A |
X |
11 |
Table 200:
| Material |
Price |
| X |
15 |
| Y |
200 |
For a condition record to be the 'right' record, the information in the
order, customer master or material master must match the key of the
record. If not then the system will go on to check the next table.
| Worked Examples using data from the example
tables above |
| Customer |
Customer Group (from the customer
master) |
Region |
Material |
Price |
| 1234 |
A |
NSW |
X |
11 |
| 1224 |
A |
WA |
X |
10 |
| 2346 |
C |
QLD |
X |
15 |
| 1224 |
A |
WA |
Y |
200 |
A similar lookup is then done for each condition type. E.g.: the discount
condition could specify various percentage discounts.
TAX APPLICATION
For the tax condition type, it is most likely that the tax classification
fields on the customer and material master would be used as keys for the tax
condition records.
|