SAP ERP: Architecture, Data Model, and Tables

1. What runs on SAP in DoD

Five systems in this suite run on SAP ERP: GFEBS, Navy ERP, GCSS-Army, LMP, and DLA EBS. They share one product data model. A purchase order sits in EKKO and EKPO in all five. A financial document sits in BKPF and BSEG in all five. What differs between programs is configuration, custom Z-tables, interfaces, and which modules are switched on.

2. Technical architecture

SAP ERP is a three-tier client-server system. Users and interfaces reach an application server. The application server runs ABAP programs in work processes. Only the application server talks to the database.

Clients, landscapes, and transports

• A client is a self-contained business tenant inside one SAP system. The client number is the first key field (MANDT) of almost every application table. Any direct SQL against an SAP database must filter on it.
• A standard landscape has three systems: development, quality assurance, and production. Configuration and code move between them in transport requests. The transport log is the change-management evidence auditors ask for.
• Configuration lives in tables too. The Implementation Guide (SPRO) is a menu over thousands of customizing tables such as T001 (company codes) and T003 (document types).
• The ABAP Dictionary (SE11) defines every table. ECC has three physical kinds: transparent tables, pooled tables, and cluster tables. BSEG is a cluster table in ECC, which is why it cannot be joined in plain SQL there. In S/4HANA it is transparent.

3. Organizational structure

SAP separates the legal view, the cost view, the budget view, and the logistics view of an organization. Each view has its own top-level unit. Assignments between them decide which postings are allowed.

4. The document principle

Every posting in SAP creates a numbered document that cannot be deleted. A correction is a new reversing document. Each document has a header and line items, and each carries a link back to the document that caused it. That chain is what makes transaction-level audit support possible.

• A financial document is identified by company code, document number, and fiscal year: BUKRS + BELNR + GJAHR.
• The header field AWTYP names the kind of source object. AWKEY holds its key. AWTYP = MKPF points to a material document. RMRP points to a logistics invoice. VBRK points to a billing document. BKPF means the posting was made directly in FI.
• The document type BLART classifies the posting. Common values: SA general ledger, KR vendor invoice, KZ vendor payment, RE logistics invoice, WE goods receipt, ZP payment run, AA asset posting.
• Posting keys (BSCHL) set debit or credit and the account type. 40 debits a GL account. 50 credits one. 31 credits a vendor. 25 debits a vendor for payment.
• Changes to master data and documents are logged in CDHDR and CDPOS. These two tables answer the question of who changed what, and when.

5. Finance and Funds Management data model

Three ledgers update together when a business event posts. Financial Accounting records the proprietary entry. Funds Management records budget consumption against fund, funds center, and commitment item. Controlling records cost against a cost center, order, or WBS element. The line item in BSEG carries the account assignments for all three.

How SAP produces USSGL budgetary accounts

Standard FI only records proprietary accounts. The US Federal extension of Public Sector Management adds a budgetary ledger. When an FM event posts, such as an obligation or a payment, the budgetary ledger derives the matching 4000-series entry and posts it in the same FI document or a linked one. The result is that one business event carries both the proprietary and the budgetary entry, which is what FFMIA requires at the transaction level.

6. Procure-to-pay document flow

Procure-to-pay is the largest transaction population in most DoD general fund audits. The flow below shows the SAP step, the tables each step writes, and the accounting effect.

1. Start from the invoice or payment in the sample. Read BKPF for the document and note AWTYP and AWKEY.
2. If AWTYP is RMRP, split AWKEY into invoice number and year and read RBKP and RSEG. RSEG gives the purchase order and item.
3. Read EKBE for that order item. It lists every goods receipt and invoice posted against it.
4. Read EKKO, EKPO, and EKKN for the obligation amount and the funding line.
5. Read FMIOI by REFBN equal to the order number for the open obligation, and FMIFIIT by KNBELNR equal to the FI document for the expenditure.
6. Read EKPO-BANFN to step back to the requisition in EBAN, or KBLP if the commitment was an earmarked funds document.

7. Other module data models

8. ECC 6.0 compared with S/4HANA

S/4HANA keeps the document principle and most table names, and changes where totals and line items live. One table, ACDOCA, holds the line items that ECC spread across FI, the new GL, CO, asset accounting, and the material ledger. Totals are computed on read.

9. Integration technologies

10. Security and controls

• Access is granted through roles built in PFCG. A role bundles transaction codes and authorization objects. Examples: F_BKPF_BUK controls posting by company code. F_FICB_FKR controls FM area access. M_BEST_EKO controls purchase orders by purchasing organization.
• Role assignments sit in AGR_USERS. Role contents sit in AGR_1251. User master data sits in USR02. These three tables support a user access review.
• Segregation of duties is tested by checking whether one user holds conflicting transactions, such as creating a vendor (XK01) and running payments (F110). SAP GRC Access Control automates the rule set.
• The security audit log (SM20) and table change logging (DBTABLOG, read through SCU3) record sensitive actions and configuration changes.
• Direct table maintenance through SE16N or SM30 in production is a common audit finding. Review who holds S_TABU_DIS.

11. Trial balance and universe of transactions queries

A defensible trial balance from SAP reads the ledger line items and sums them by the reporting dimensions. The universe of transactions is the same query without the sum.

1. Pick the ledger table: FAGLFLEXA in ECC with the new GL, ACDOCA in S/4HANA.
2. Filter on client, company code, ledger, fiscal year, and posting period.
3. Group by GL account, fund, functional area, and any other attribute the SFIS trial balance needs.
4. Compare the totals to FAGLFLEXT or to transaction FAGLB03. They must agree to the cent.
5. Join the line items to BKPF for user, date, document type, and AWTYP / AWKEY. This gives every balance a path to its source document.
6. Compare FM totals in FMIT to the budgetary accounts in the ledger. Differences point to documents that updated one ledger and not the other.