Decision tables for determination logic

A large share of SAP behavior is decided by the condition technique: a field catalog, condition tables built from a few of those fields, condition records holding the values, an access sequence that searches the tables from most specific to most general, condition types, and a procedure that puts the condition types in order. Pricing is the famous example, but the same idea drives output, text and account determination. For a tester, the important point is that each of these is a rule with several inputs and one or more outputs. That is exactly what a decision table models.

From determination rule to decision table

A decision table lists the conditions (inputs) as rows at the top, the actions (outputs) as rows at the bottom, and each column is one rule: one combination of condition values and the action it should produce. With three yes/no conditions there are 2 × 2 × 2 = 8 combinations. Writing them all out, even the ones that "can't happen", is what makes the technique powerful: it forces the business to say what should happen in every case.

Contoso's order-to-cash team defined how order confirmations go out for sales area 1710 / 10 / 00. In SAP S/4HANA output management, output parameters such as output type, receiver and channel are found by rules held in decision tables (built on BRF+), where the first matching row wins and a blank cell matches any value. The business rule Maria wrote down was: fleet customers get an order confirmation; customers set up for EDI get it electronically, everyone else by email; rush orders get a confirmation whatever the customer group.

Collapsing rules

Full tables grow fast, so the next step is to collapse them. When two columns differ in only one condition and produce the same actions, that condition does not matter for them: merge the columns and write a dash ("don't care"). R1 and R2 both send by EDI whether or not the order is a rush, so they collapse into one rule. R3 and R4 collapse the same way. What remains is five rules:

Decision table coverage is the share of feasible columns your tests exercise. Five tests, one per collapsed rule, give 100%. Collapse only when you are sure the dash is true in the system, not only in the requirement: if the configured BRF+ rule happens to check the rush flag for fleet customers, a collapsed table hides that. On a high-risk rule, test the full table.

Executing the table needs test data designed with the same care. Each column needs a customer and order that match its conditions exactly: a fleet customer set up as an EDI partner, a fleet customer without EDI, an aftermarket customer with EDI, and so on. Contoso keeps one customer master record per column in client 100 and names them after the rule they serve, so nobody borrows the EDI test customer for a pricing test and silently changes its setup. For evidence, capture the output the order actually determined (output type, receiver and channel as shown on the order's output overview) rather than a success message on save. An order can save perfectly and determine nothing at all.

Writing every combination exposes two kinds of defect before a single test runs. A missing rule is a column the business never specified. Maria's sentence never said what happens to a non-fleet, non-rush order from an EDI partner (R6); the team had to decide, and decided "no confirmation". In the system, a missing rule usually means nothing is determined at all, and nothing is the hardest result to notice. A conflicting rule is a combination that matches two rows with different actions. In output determination and in access sequences, order decides which row wins, so a conflict is resolved silently by row order. Build one test for each conflict you find and check that the winner is the one the business wants.

Pricing and tax determination

An access sequence is itself a decision table with a priority order. Contoso's price for CMC-ALT-100 is searched customer-specific price first, then price list price, then general material price. Conditions: does a customer-specific record exist? does a price list record exist? does a material record exist? With three conditions and "first found wins", there are four meaningful outcomes, including "no price found", which should stop or flag the item. Test each, and remember that condition records have validity dates: a record that expired yesterday falls into the "does not exist" column.

Tax determination follows the same pattern, though the details vary by country and by whether tax is calculated inside SAP or by an external tax service. Typical conditions are the departure and destination country or jurisdiction, the customer's tax classification and the material's tax classification; the action is the tax code or tax condition found. Check your own tax design document for the actual inputs before building the table.