Lesson 3 of 6
Rules: validations, derivations and BRF+
10 min
Listen to this lesson
MDG checks data with several layers of logic. Some checks come from SAP S/4HANA itself: the business partner and product checks that run in any transaction. MDG adds its own checks from the data model, and customers add validation rules (is the data acceptable?) and derivation rules (fill or change fields automatically). Customer rules are usually built in BRFplus, through the MDG activity for defining validation and derivation rules, or in ABAP through the rule service BAdI (USMD_RULE_SERVICE) where logic is too complex for decision tables. Data quality rules (from sap-xpr-206, lesson 4) can also be used in change request checks.
| Aspect | Validation | Derivation |
|---|---|---|
| Purpose | Accept or reject data with a message | Set or change field values |
| Example at Contoso | Mexican customers in 1910 need an RFC tax number in the right format | Payment terms default to 0004 for sales area 1910 / 10 / 00 |
| Typical failure | Rejects valid data or accepts invalid data | Overwrites what the user entered, or fires in the wrong order |
| Key test | Valid, invalid and boundary values per rule | User value present versus empty; order of derivations |
| Evidence | Message text and the record state | Field value before and after the check |
Designing rule tests
Rules are ideal for classic test design techniques. Equivalence classes split the input into groups that should behave the same way, so one value per class is enough. Boundary values test the edges of each class. Decision table testing covers combinations of conditions. A rule with a scope (which records it applies to) needs out-of-scope cases too, or a rule that wrongly checks everyone will pass every test.
| Class | Example input | Expected |
|---|---|---|
| In scope, valid company RFC (12 characters) | Customer in 1910, RFC for a company | Accepted |
| In scope, valid person RFC (13 characters) | Customer in 1910, RFC for a person | Accepted |
| In scope, wrong length | RFC with 11 or 14 characters | Error message naming the field |
| In scope, empty | Customer in 1910 without RFC | Error, unless the rule allows a documented exception |
| Out of scope | Customer in company code 1710 without RFC | No message from this rule |
| Boundary of scope | Customer extended from 1710 to 1910 in the same request | Rule applies to the new 1910 data |
Equivalence classes for Contoso's "RFC required for 1910 customers" validation (illustrative; check the current SAT format rules with Lucía and tax advisors).
Derivations and their order
Derivations cause subtler defects than validations. Three questions catch most of them. Does the derivation overwrite a value the user entered on purpose? Does it run again when the user changes a field later in the same request, and with what effect? And when two derivations touch related fields, which runs first? Test each derivation with the target field empty, with a user-entered value, and after a later change to the source field.
Testing BRFplus rules efficiently
- Use the BRFplus simulation in the workbench to test a decision table or function with prepared inputs before any end-to-end test.
- Export decision tables to a spreadsheet and review them with the data owner; a wrong row is found faster by reading than by testing.
- For each rule, keep a small set of inputs and expected outputs that can be re-run after every change.
- After unit tests pass, run a smaller number of end-to-end change requests to prove the rule is actually called in the process.
Messages are part of the test
A validation that blocks correctly but shows "Entry invalid" is a defect waiting to happen: requesters will guess, retry and call the steward team. For every validation, record the expected message text and check that it names the field and the fix, for example "RFC tax number must have 12 characters for companies or 13 for persons." Check the message type too: an error blocks the request, a warning lets it continue. A rule meant to warn that is configured as an error stops valid business, and the reverse lets bad data through.
What goes wrong in testing
| Symptom | Real cause | Lesson |
|---|---|---|
| Rule passes every test | Scope too wide, so all test data was in scope and valid | Always include out-of-scope and invalid cases |
| Message appears twice | Same check in BRFplus and in a BAdI | Inventory every rule layer before testing |
| User's value disappears | Derivation overwrites on every check | Test derivations with user-entered values |
| Works in CMQ, fails in CMP | Decision table content maintained differently in production | Compare table versions as part of release checks |
Common rule test failures and what they teach.
What would you do?
A validation for the 1910 RFC tax number passes all 20 test cases. In acceptance, Lucía finds that customers in company code 1710 are also blocked when the RFC is empty. What was missing from the tests?
- Validations accept or reject; derivations set values. Both need their own test design.
- Use equivalence classes, boundaries and out-of-scope cases for every rule.
- Test derivations with empty and user-entered values, and after later changes.
- Directly maintained decision table content must trigger regression.
Check your understanding · not graded
Lesson check
1. Which test case most often reveals a rule whose scope is too wide?
2. What is the classic defect of a derivation rule?
3. Where can a BRFplus decision table be tested fastest before end-to-end tests?
4. Why is direct maintenance of decision table content a quality risk?