offdataai
SAP · data model template

SAP Customer Service (CS) data model

Third-normal-form mirror of the SAP CS service-management tables as they land from the source ERP. Each SAP table becomes its own entity with a warehouse surrogate key plus the genuine SAP business key(s); technical objects model their hierarchies via self-referencing keys, and notification/order/operation/confirmation child tables reference their headers and master data via foreign keys. Customer name/city and the confirming employee number are PII-masked.

Normalized replica of SAP ECC/S4HANA Customer Service / service management source tables for a warehouse staging/replication layer: the installed base of functional locations (IFLOT/IFLOTX) and equipment (EQUI/EQKT) with measurement points (IMPTT); the service process of notification (QMEL) → service order (AUFK/AFIH) → operation (AFVC) → confirmation (AFRU); and service contracts (VBAK/VEDA) with items and equipment warranties — keyed by the real SAP business keys (tplnr, equnr, qmnum, aufnr, vbeln) and anchored to customer (KNA1), plant (T001W), work center (CRHD) and material (MARA) master tables. It is a normalized (3NF) relational model that mirrors the source system, suited to operational databases and to landing source data faithfully.

3NFSAPISO-9001SOX
15
tables
125
columns
21
relationships
3
PII columns

Opening the template creates a project with the ERD, platform-native DDL, a dbt project and documentation already generated (recommended platform: PostgreSQL). Edit it in plain English or on the canvas, then ship it to any supported warehouse.

Subject areas

installed_baseservice_processingservice_contractsmaster_data

Design decisions

  • Installed base modeled as functional location plus equipment with self-references

    SAP CS represents the installed base as functional locations (IFLOT) and equipment (EQUI), each forming a hierarchy via a superior functional location and superordinate equipment; capturing those parent keys as self-references preserves the structural tree without re-keying every technical object.

  • Notification → order → operation → confirmation kept as separate entities

    SAP CS drives service through a notification (QMEL) that spawns a service order (AUFK/AFIH) broken into operations (AFVC) that are time-confirmed (AFRU); replicating that chain 1:1 keeps the staging layer lossless and lets MTBF/MTTR and service-order cost reconcile against the source documents.

  • Service contracts split into header and item with SLA fields

    SAP stores service contracts as a sales document (VBAK) with contract data (VEDA) and items covering specific equipment/material; modeling the header and item separately with SLA response/resolution fields supports entitlement checks, SLA compliance, and contract-renewal reporting.

  • Equipment-centric measurement points retained for condition data

    SAP CS records condition and counter readings against measurement points (IMPTT) attached to a technical object; keeping measurement points as their own entity tied to equipment preserves the source granularity needed for condition monitoring and counter-based maintenance.

  • SAP business keys preserved in the replica layer

    Because this is a replication/staging layer, retaining the real SAP business keys (tplnr, equnr, qmnum, aufnr, vbeln) alongside the warehouse surrogate keys keeps every row reconcilable against the source ERP and avoids ambiguity when cross-referencing back to SAP transactions.

Tables in the SAP Customer Service (CS) model

Every table with its grain, columns, types and keys. PK marks a primary key, BK a business key and PII a column classified as personal data, which gets a masking strategy by default.

Tables (10)

functional_location

Grain: one row per functional location (tplnr)

SAP IFLOT/IFLOTX — functional location and its description.

ColumnTypeKeys
functional_location_keybigintPK
plant_keybigint
tplnrvarcharBK
pltxtvarchar
fltypvarchar
eqartvarchar
abckzvarchar
parent_funcloc_keybigint
installation_datedate

equipment

Grain: one row per piece of equipment (equnr)

SAP EQUI/EQKT — equipment master and its description.

ColumnTypeKeys
equipment_keybigintPK
material_keybigint
functional_location_keybigint
customer_keybigint
equnrvarcharBK
eqktxvarchar
sernrvarchar
eqtypvarchar
databdate
installation_datedate
parent_equipment_keybigint
is_in_serviceboolean

measurement_point

Grain: one row per measurement point (point)

SAP IMPTT — measurement point on a technical object.

ColumnTypeKeys
measurement_point_keybigintPK
equipment_keybigint
pointvarcharBK
mptypvarchar
atnamvarchar
indctvarchar
decimal_placesinteger
measurement_unitvarchar

warranty

Grain: one row per equipment warranty assignment

SAP equipment warranty (BGMK/warranty counter) — modeled per equipment.

ColumnTypeKeys
warranty_keybigintPK
equipment_keybigint
warranty_idvarcharBK
warranty_typevarchar
warranty_startdate
warranty_enddate
is_activeboolean

service_notification

Grain: one row per service notification (qmnum)

SAP QMEL — service-relevant quality/service notification.

ColumnTypeKeys
service_notification_keybigintPK
equipment_keybigint
functional_location_keybigint
customer_keybigint
qmnumvarcharBK
qmartvarchar
qmtxtvarchar
erdatdate
priokvarchar
problem_codevarchar
required_startdate
required_enddate
notification_statusvarchar

service_order

Grain: one row per service order (aufnr)

SAP AUFK + AFIH — service order header and maintenance order header.

ColumnTypeKeys
service_order_keybigintPK
service_order_type_keybigint
equipment_keybigint
functional_location_keybigint
service_notification_keybigint
customer_keybigint
aufnrvarcharBK
ktextvarchar
gstrpdate
gltrpdate
planned_costdecimal
actual_costdecimal
currencyvarchar
order_statusvarchar

service_order_operation

Grain: one row per service order operation (aufpl, aplzl)

SAP AFVC — operations within the service order.

ColumnTypeKeys
service_order_operation_keybigintPK
service_order_keybigint
work_center_keybigint
aufplvarcharBK
aplzlvarcharBK
vornrvarchar
ltxa1varchar
arbeidecimal
planned_durationdecimal
actual_durationdecimal

service_confirmation

Grain: one row per order confirmation (rueck, rmzhl)

SAP AFRU — order completion confirmations.

ColumnTypeKeys
service_confirmation_keybigintPK
service_order_keybigint
rueckvarcharBK
rmzhlvarcharBK
operation_numbervarchar
actual_workdecimal
confirmation_datedate
employee_idvarcharPII
is_final_confirmationboolean

service_contract

Grain: one row per service contract header (vbeln)

SAP VBAK + VEDA — service contract document and contract data.

ColumnTypeKeys
service_contract_keybigintPK
customer_keybigint
vbelnvarcharBK
contract_typevarchar
vbegdatdate
venddatdate
sla_response_timedecimal
sla_resolution_timedecimal
contract_valuedecimal
currencyvarchar
is_auto_renewboolean
contract_statusvarchar

service_contract_item

Grain: one row per service contract item (vbeln, posnr)

SAP VBAP + VEDA item — service contract item and contract data.

ColumnTypeKeys
service_contract_item_keybigintPK
service_contract_keybigint
equipment_keybigint
material_keybigint
vbelnvarcharBK
posnrvarcharBK
covered_servicevarchar
response_sladecimal

Lookup tables (5)

material

Grain: one row per material master general record

SAP MARA/MAKT — material master, referenced as a lookup here.

ColumnTypeKeys
material_keybigintPK
matnrvarcharBK
maktxvarchar
mtartvarchar
matklvarchar

customer

Grain: one row per customer master general record

SAP KNA1 — customer master (general), referenced as a lookup here.

ColumnTypeKeys
customer_keybigintPK
kunnrvarcharBK
name1varcharPII
land1varchar
ort01varcharPII

plant

Grain: one row per plant / maintenance planning plant

SAP T001W — plant/branch check table.

ColumnTypeKeys
plant_keybigintPK
werksvarcharBK
name1varchar
land1varchar

work_center

Grain: one row per work center

SAP CRHD — work center header, referenced as a lookup here.

ColumnTypeKeys
work_center_keybigintPK
arbidvarcharBK
arbplvarchar
ktextvarchar
werksvarchar

service_order_type

Grain: one row per service order type

SAP TCO* / T003O — order type customizing, referenced as a lookup here.

ColumnTypeKeys
service_order_type_keybigintPK
auartvarcharBK
descriptionvarchar
order_categoryvarchar

Relationships

Each relationship is a foreign key on the first table referencing the second.

  • functional_location.plant_key → plant (many-to-one)
  • equipment.material_key → material (many-to-one)
  • equipment.functional_location_key → functional_location (many-to-one)
  • equipment.customer_key → customer (many-to-one)
  • measurement_point.equipment_key → equipment (many-to-one)
  • warranty.equipment_key → equipment (many-to-one)
  • service_notification.equipment_key → equipment (many-to-one)
  • service_notification.functional_location_key → functional_location (many-to-one)
  • service_notification.customer_key → customer (many-to-one)
  • service_order.service_order_type_key → service_order_type (many-to-one)
  • service_order.equipment_key → equipment (many-to-one)
  • service_order.functional_location_key → functional_location (many-to-one)
  • service_order.service_notification_key → service_notification (many-to-one)
  • service_order.customer_key → customer (many-to-one)
  • service_order_operation.service_order_key → service_order (many-to-one)
  • service_order_operation.work_center_key → work_center (many-to-one)
  • service_confirmation.service_order_key → service_order (many-to-one)
  • service_contract.customer_key → customer (many-to-one)
  • service_contract_item.service_contract_key → service_contract (many-to-one)
  • service_contract_item.equipment_key → equipment (many-to-one)
  • service_contract_item.material_key → material (many-to-one)

Related templates

All templates →
Start for $1

From requirements to AI-ready context, in one platform.

Describe your business in a conversation, start from a template or connect your own database. Your first model is ready in minutes.

Get startedBook a demo

Plans from $1/month · cancel any time