Lookup tables are stored in fragments. What a compensation analyst sees as a single readable row — “100,000 – 200,000 → 8%” — is physically spread across three or four tables (cs_relationalmdlt, CS_MDLTcell, cs_mdltindex), with separate columns used depending on whether the dimension value is a number, a string, or a date. Writing the SQL to reconstruct that row correctly takes time and is easy to get wrong.

Classifiers come in four distinct types. A classifier in SAP Commissions can be a Product (cs_product), a Customer (cs_customer), a Postal Code (cs_postalcode), or a Generic Classifier (cs_genericclassifier). Business users think of these as one concept — “the things in my category tree” — but they are stored in entirely separate tables. Any unified report requires a UNION of all four.

Effective dating and soft deletes are everywhere. Every record carries an effectivestartdate, an effectiveenddate, and a removedate. Miss any one of these on any one join and your numbers silently include expired or deleted records. This is the single biggest source of subtle reporting bugs across implementations.

Human-readable names hide behind internal keys. Unit types, business units, and processing units are stored as numeric foreign keys (businessunitmap, processingunitseq). Every useful report needs to resolve those into names, which adds more joins and more surface area for mistakes.

 

Source link