In-system checks for SAP

Stop bad data — before it reaches the database.

GUARD is a small framework that lets any client running an SAP system protect their data from invalid changes. It plugs into standard or custom transactions just before SAVE, runs the business rules you care about, and stops the SAVE if anything is wrong — turning scattered hard-coded checks into clean, transportable customizing.

See how it helps → How it works
The problem

Bad data sneaks in long before anyone notices.

In every long-running SAP project, business rules end up scattered across user-exits, BADIs, and includes — each one a separate piece of code, hard to find, hard to change, impossible to govern.

Every new check becomes a development ticket, even when the logic is just a value list or a "must not be empty". And the data quality reports that do exist run hours later — by which time the bad record has already been used by downstream postings, IDocs, and replications.

The idea

Move the rules out of code, into configuration.

GUARD turns business checks into customizing. A rule is a transparent pipeline — Filter ⟶ Steps ⟶ Conditions ⟶ Messages — stored in standard tables and transported between systems exactly like any other SAP customizing.

The framework plugs in once per Business Object — through a BADI, a USER-EXIT, a CUSTOMER-EXIT, or any place inside a custom transaction or function module where the relevant tables are available before SAVE. From that moment on, anyone with SAP technical literacy can add, change, or retire a check without touching ABAP — and everyone in the project gets a single place to look.

How it works

Three layers — wire it up once, configure forever.

A developer enables GUARD on a Business Object. From there, every new rule is configuration only.

1

Object

A developer wires GUARD into the Business Object once — Contract, PIR, Article, Promotion, BP, or your own — and lists the tables that feed the check.

2

Project

Each product or team gets its own Project — a cluster of rules for one purpose (e.g. CONTRACT_MANAGEMENT). Multiple projects can coexist on the same Object.

3

Rule

Every Rule is a sorted pipeline — Filter, Steps (Decision Table, Function, or OSQL), Conditions, Messages. Transparent in one screen, transportable like any customizing.

Why teams adopt it

Fewer mistakes. Faster onboarding of new rules. A clean audit trail.

Real-time protection

Checks run before SAVE — not in a report hours later. Bad data never makes it into the database.

No code per rule

The framework is wired up once per Business Object. From there, every new check is configuration — no developer required.

Three flavors of check

Decision Tables for value lists, Functions for richer logic, OSQL for cross-table look-ups — pick what fits the rule.

Two transport modes

Run the configuration as transport-relevant — rules flow through DEV → TST → PRE → PRD on standard transport requests like any other customizing. Or set systems editable and let users maintain rules directly in production, with a one-click export of an entire Project to a file that can be re-imported into any other system. No transport request needed when a rule has to change in PRD now.

Built-in trace

Every step of every rule writes a SLG1-style log on demand — perfect for debugging or for proving "the rule did fire" to an auditor.

Authorable by anyone

Functional consultants, developers, and SAP-fluent business users can all maintain rules. One source of truth, many capable hands.

Who it's for

Anyone who has to keep an SAP system clean.

GUARD fits wherever a Business Object is being created or changed — and someone, somewhere, has to make sure the data is right.

📝

Master data teams

Articles, BPs, prices, contracts — kept consistent at the moment of save.

🛒

Buying & merchandising

Catch contract or promotion mistakes before they ripple downstream.

🏷️

Pricing & conditions

Enforce payment terms, currency, and scale rules without scattered code.

📊

Data quality

Move from "find it in a report" to "prevent it at the source".

🛡️

Compliance & audit

Every rule is documented, transported, and traced. Auditors can read it.

🧰

Functional consultants

Onboard a new check without filing a development ticket.

👩‍💻

Developers

Stop maintaining 20 user-exits. Wire up GUARD once, hand the rest over.

🏢

System architects

One framework, one logging convention, one transport flow — across every BO.

Want to see real situations?

Walk through five everyday SAP changes — article extensions, payment terms, promotions, business partners, master data — and the exact GUARD message the user gets when something is off.

See the use cases →

Wondering how to install it?

Five steps for a developer to enable GUARD on a new Business Object — find the insertion point, list the tables, six lines of ABAP, configure the Object once, and hand it over to functional. Usually less than a day.

See the installation →

Want to see the app itself?

A tour of the configuration screens — the navigation tree, Objects, Projects, Custom Data Sources, Decision Tables, OSQL queries, and the four parts of a complete Rule. Six mocked screenshots, one page.

Inside the app →

See real situations where GUARD steps in.

Walk through everyday SAP changes — extending an article to a new store, locking down payment terms, keeping promotions inside their contract window — and see exactly the message GUARD shows the user when something is off.

Read the use cases →