Real situations

Five everyday changes — and what GUARD shows the user.

Each scenario follows the same flow: a real user opens an SAP transaction, makes a change, and presses SAVE. GUARD intercepts, runs the relevant rule, and either lets the SAVE through or shows a clear, actionable message — all before any data hits the database.

1 Use case ARTICLE

Category Manager · transaction MM41 / MM42

"Add this wine to a convenience store."

A category manager opens article 100023 — a premium wine, "Château Mont" — and extends it to plant 5012, the new Express City Center convenience format. They press SAVE.

The convenience format doesn't carry alcohol. Without GUARD, the article would land in MARC, replicate to the store, and surface as a problem on the shelf or — worse — in a customer's basket.

Article 100023 — Château Mont, 0.75 L
Article type ZWEI (Wine)
Plant being added 5012 — Express City Center
Allowed types for plant 5012 ZFOO, ZBEV, ZHHL

ErrorZGUARD 017

Article type ZWEI is not allowed for plant 5012 — Express City Center. Allowed types: ZFOO, ZBEV, ZHHL.

SAVE has been stopped. Either change the article type or extend the article to a plant that permits ZWEI.

Rule ART017_MARC_MTART Project STORE_OPS Steps OSQL → DTab
Behind the scenes
  1. OSQL — "is this a new MARC entry?" The first step runs an Open SQL query against the database to confirm there is no existing MARC row for the (MATNR, WERKS) being saved. If the row already exists, the user is just changing an existing extension and this rule doesn't apply. 
    SELECT SINGLE matnr FROM marc
  WHERE matnr = &MATNR
    AND werks = &WERKS
  2. Decision Table — allowed types per plant. When the OSQL confirms a new extension, GUARD looks up plant 5012 in the ZRSDF parameter mapped to ART017 and gets back the allowed article types.
  3. Condition + Message. If the article type isn't on the list, message ZGUARD 017 is raised with the rejected type and the allowed types as placeholders.
2 Use case CONTRACT

Buyer · transaction ME31K / ME32K

"30-day payment terms with our top supplier."

A buyer creates a value contract with supplier 1004563 — Northern Foods AG, a Tier-A strategic supplier — and proposes payment terms ZB30 (30 days net).

Tier-A suppliers carry a stricter cash-flow policy: only ZB14 (14 days net) is permitted. The mistake would normally be caught weeks later in a finance audit; with GUARD, it never makes it to SAVE.

Contract New value contract, supplier 1004563
Supplier tier Tier-A (strategic)
Payment term entered ZB30 (30 days net)
Allowed for Tier-A ZB14 only

ErrorZGUARD 013

Payment terms ZB30 are not allowed for Tier-A supplier 1004563 (Northern Foods AG). Use ZB14 (14 days net).

Strategic-supplier policy CFO-2024-07 — see SharePoint for exception process.

Rule CM013_EKKO_ZTERM Project CONTRACT_MANAGEMENT Steps DTab
Behind the scenes
  1. Filter. The rule is restricted to contract document type EKKO-BSART = 'WK' (value contract).
  2. Decision Table. Maps (supplier-tier, payment-term) to allowed / not-allowed. The lookup returns "not allowed" for Tier-A + ZB30.
  3. Message. The error message uses EKKO-LIFNR and ZTERM as message variables so the supplier number and tier always appear in the text.
3 Use case PROMOTION

Promotion Planner · transaction WAK1 / WAK2

"Run this promo until the first week of September."

A promotion planner creates promo PR-2026-1145 for article 200034, valid from 2026-08-15 to 2026-09-05. The underlying purchase contract 4500876123, however, expires on 2026-08-30 — the last six days of the promotion would have no contract behind them.

Without GUARD, the promo would go live and a quiet revenue gap would open up. With GUARD, the planner sees it now, talks to the buyer, and either extends the contract or shortens the promo before saving.

Promotion PR-2026-1145
Article 200034
Promo validity 2026-08-15 → 2026-09-05
Underlying contract 4500876123 · expires 2026-08-30

ErrorZGUARD 021

Promotion validity ends 2026-09-05, but contract 4500876123 expires 2026-08-30. Extend the contract or shorten the promotion.

6 days of the promotion would run without a valid contract.

Rule PR021_WAKH_DATBI Project PROMO_GOVERNANCE Steps OSQL
Behind the scenes
  1. OSQL — find the active contract. A single Open SQL query joins the promotion's article to the active contract conditions (EKKO + EKPO) and returns the latest contract end date.
  2. Condition. The promotion's WAKH-DATBI must be ≤ the contract end date. If not, the rule fails.
  3. Message. Both dates and the contract number are passed as placeholders so the user immediately knows which contract to talk to the buyer about.
4 Use case BP

Master Data Steward · transaction BP

"New customer, role: Customer. We'll fill in the rest later."

A master data steward creates business partner 100078 — Northwind GmbH — and assigns role FLCU01 (Customer). They leave the VAT ID blank, planning to come back to it later.

For DACH-region customers, VAT ID is mandatory the moment the Customer role is added — both for legal invoicing and for tax reporting. GUARD blocks the SAVE so the gap can't slip past.

Business Partner 100078 — Northwind GmbH
Role FLCU01 — Customer (FI)
Country DE (Germany)
VAT ID entered (empty)

ErrorZGUARD 008

Business partner 100078 — Northwind GmbH has role FLCU01 (Customer) but no VAT ID was entered. VAT ID is mandatory for customers in DE / AT / CH.

Add the VAT ID under Identification → Tax Numbers and re-save.

Rule BP008_DFKKBPTAXNUM Project BP_COMPLIANCE Steps Function
Behind the scenes
  1. Filter. Active only when the BP has at least one role from the "VAT-relevant" group (FLCU01, FLVN01, …) and the country is in (DE, AT, CH).
  2. Function. A custom class implementing ZIF_GUARD_FUNCTION reads the BP's tax-number table, looks for category DE0 / AT1 / CH3, and removes the entry from its working copy if a non-empty value is found.
  3. Condition. If the working copy still has a matching role-without-VAT entry, the rule emits the error.
5 Use case ARTICLE

Master Data Steward · transaction MM41

"English description is enough for now."

A master data steward creates article 300199 — "Eco Refill Pack 1L" — and saves it with only the English description filled in. German and Austrian translations are mandatory before the article can be listed in stores in those markets, but the SAVE itself isn't blocked: this is a warning, not an error.

GUARD lets the SAVE through and surfaces the gap so the steward sees it now and the data stays in flight, ready for downstream translation.

Article 300199 — Eco Refill Pack 1L
Description (EN) "Eco Refill Pack 1L"
Description (DE) (empty)
Description (AT) (empty)

WarningZGUARD 032

Article 300199 saved with English description only. Add German (DE) and Austrian (AT) translations within 7 days for local-market readiness.

The SAVE went through. The article is on the data-quality watchlist until the translations are added.

Rule ART032_MAKT_LANG Project MASTER_DATA_QUALITY Steps OSQL
Behind the scenes
  1. OSQL — translation count. A single SELECT on MAKT for the saved article counts how many language versions exist.
  2. Condition. If DE or AT is missing, the rule fails — but the rule's STOP_ERROR flag is off, so the SAVE proceeds.
  3. Message. Severity is W (warning) instead of E; the message body still carries the gap so the steward knows what's pending.

One framework. Hundreds of scenarios.

Every check above looks different to the user — but under the hood it's the same Object → Project → Rule pipeline, the same Filter → Steps → Conditions → Messages, the same transport flow. Add the next rule in minutes, not weeks.

Back to overview →