FOUNDATION 04 · DATA FOUNDATIONS
What data makes a process work?
SAP transactions do not invent their meaning at runtime. They combine organizational context, configured rules, reusable master data, user or interface input, and prior documents to determine what can happen next.
Business partners, products, accounts, assets, employees, and technical objects need stable identities and lifecycle control.
Data is often extended to company code, plant, sales area, purchasing organization, valuation, or other organizational levels.
Attributes drive pricing, tax, planning, account determination, payment, fulfilment, reporting, and authorization outcomes.
DATA CLASSES
Separate reusable rules from business events
MASTER DATA IS CONTEXTUAL
One object can have several organizational views
A central identity does not mean every attribute is globally shared.
General identity is combined with roles and organizational data for customer, supplier, company-code, sales-area, and purchasing contexts. Exact structures depend on scope and edition.
Basic identity is extended with sales, purchasing, planning, plant, storage, valuation, warehouse, quality, and accounting attributes as required.
Chart-of-accounts definition combines with company-code settings and ledger design to support posting and reporting.
Cost centers, internal orders, projects, production orders, and profitability dimensions carry responsibility, validity dates, and settlement or allocation behavior.
Financial valuation, location, maintenance responsibility, equipment history, and operational status may intersect without being the same object.
GOVERNANCE LIFECYCLE
Good data is an operating process, not a cleanup project
Define the business need, search for an existing object, prevent duplicates, and identify the authoritative source.
Collect mandatory attributes, validate organizational scope, apply workflow and segregation, and record ownership.
Measure completeness, validity, duplicates, failed transactions, exception rates, and reconciliation—not just populated fields.
Use effective dates, approvals, audit history, blocking and deletion indicators, retention rules, and downstream impact analysis.
DETERMINATION
A document value usually has a lineage
Do not ask only “Which table stores it?” Ask how the value was proposed, copied, calculated, overridden, and persisted.
User, interface, source document, date, product, partner, quantity, and organizational values establish the request.
Access sequences, partner determination, field selection, substitutions, derivations, and master-data defaults propose values.
Availability, pricing, tax, credit, tolerances, units, currencies, and account determination evaluate the request.
The transaction records the relevant result and status. Later master-data changes do not necessarily rewrite historical documents.
WORKED EXAMPLE
A supplier invoice proposes the wrong payment terms
The visible field may come from several layers: supplier company-code data, purchase-order terms, invoice reference behavior, document type, user entry, interface mapping, or a substitution. Correct diagnosis reconstructs lineage rather than overwriting the invoice and moving on.
- Identify whether the invoice references a purchase order and capture company code, supplier, document type, dates, and source channel.
- Compare the persisted invoice value with the referenced purchase order and relevant supplier master data.
- Check whether configuration, substitution, workflow, interface mapping, or a user override changed the proposal.
- Decide whether the defect belongs to master data, the originating document, processing logic, or training.
- Correct future behavior, then handle existing documents through an approved business process with an audit trail.
QUALITY THAT MATTERS
Measure fitness for process and control
Required fields and organizational views exist for the intended process—not merely for saving the record.
Units, currencies, classifications, partner roles, dates, and account assignments agree across related objects.
The data produces correct documents, postings, outputs, planning signals, approvals, and analytics under realistic scenarios.
Field availability, governance apps, data models, and migration tools vary by edition and activated scope.