s/4hana migration reference

ACDOCA is the Universal Journal, new in S/4HANA. It replaces and merges BSEG, FAGLFLEXA, COEP, ANEP, and MLCD into a single table. All compatibility views (BSEG, FAGLFLEXA, etc.) read from ACDOCA. This is the single source of truth for all financial line items in S/4HANA.

ACDOCP is the plan data counterpart to ACDOCA in S/4HANA. Replaces CO plan tables (COSP/COSS plan portions). Enables integrated plan/actual reporting from a unified data model.

AFAB is unchanged in S/4HANA. Settlement rules for production orders remain in AFAB. In S/4HANA, settlement postings flow to ACDOCA (Universal Journal) but the rule definition table AFAB is unchanged.

AFFL is unchanged in S/4HANA.

AFKO is unchanged in S/4HANA. Production orders continue to use AFKO as the header table. Cost and quantity actuals flow into ACDOCA (Universal Journal) but AFKO retains its structural role.

AFPO is unchanged in S/4HANA. Remains the production order item table. Settlement and goods movement postings flow to ACDOCA but AFPO structure is stable.

AFRU is unchanged in S/4HANA. Confirmations still stored in AFRU; actual costs from confirmations flow to ACDOCA (Universal Journal).

AFVC is unchanged in S/4HANA. Remains the primary table for production order operations.

AFVV is unchanged in S/4HANA.

ANKA continues to define asset classes in S/4HANA. Asset classes control account determination, number ranges, and default depreciation parameters for new assets.

ANLA still exists in S/4HANA as the central asset master. However, asset postings now flow through ACDOCA (Universal Journal) instead of separate FI-AA posting tables like ANLP and ANLC.

ANLB remains in S/4HANA. Each record holds depreciation parameters for a specific depreciation area of an asset. Depreciation postings themselves go to ACDOCA.

In S/4HANA, cumulative asset values previously stored in ANLC are derived from line items in ACDOCA (Universal Journal). ANLC may still exist as a compatibility view but is no longer the source of truth for cumulative depreciation.

ANLH continues to store historical changes to asset master records in S/4HANA. It captures organizational assignment changes over time (cost center, business area, etc.).

In S/4HANA, periodic depreciation postings previously stored in ANLP are written directly to ACDOCA (Universal Journal). ANLP is replaced and asset depreciation line items are unified with all other FI postings in ACDOCA.

ANLZ remains in S/4HANA to store time-dependent organizational data such as cost center, business area, and plant assignments that can change over the asset's lifecycle.

AUFK is the cross-module order master data table used by CO (internal orders), PM (maintenance orders), PP (production orders), PS (network orders), and QM (quality orders). In S/4HANA, AUFK is unchanged. It remains the central order header table. Order cost reporting now reads from ACDOCA (filtering on AUFNR) rather than COEP/COBK, but AUFK itself is not modified.

Unchanged in S/4HANA. Central to Variant Configuration (VC) — VC sales order configuration values, super-BOM/routing conditions, and batch classification all write to AUSP. High-volume table in manufacturing clients. Always filter by KLART and CUOBJ range for performance.

Accounting document header fields are merged into ACDOCA line items. BKPF still exists in S/4HANA for compatibility, but ACDOCA is the primary table for reporting.

BNKA remains the central bank master table in S/4HANA, storing bank directory information (bank name, address, SWIFT/BIC codes).

Cleared customer items secondary index replaced by CDS views on ACDOCA.

Cleared vendor items secondary index replaced by CDS views on ACDOCA.

Cleared G/L items secondary index replaced by CDS views on ACDOCA.

Finance tables merged into Universal Journal (ACDOCA). ACDOCA is the single source of truth for all FI and CO postings in S/4HANA — eliminates the need for separate totals tables and secondary indexes.

In S/4HANA, tax line item data from BSET is merged into ACDOCA (Universal Journal). Tax-related fields are available directly in the universal journal line item. BSET may still be populated for compatibility.

Customer open items secondary index replaced by CDS views on ACDOCA. Use account type filter (KOART = D) instead of a dedicated table.

Vendor open items secondary index replaced by CDS views on ACDOCA. Use I_JournalEntryItem or custom CDS views filtering on vendor account type.

G/L open items secondary index replaced by CDS views on ACDOCA. Use account type filter (KOART = S) for G/L items.

BUT000 is the central Business Partner table in S/4HANA. It has no standard predecessor in classic ECC FI/SD — in ECC, vendor and customer master data lived in LFA1/KNA1 without a unified BP concept (BUT000 existed only in ECC CRM). In S/4HANA, BUT000 becomes mandatory for all business partners: vendors, customers, employees, and contact persons. Every LFA1 vendor and KNA1 customer must have a corresponding BUT000 record. LFA1 and KNA1 are retained as compatibility views. This table is listed here as ecc_table because it was seeded into QueryPath DB in Prompt 5, not because it existed in ECC.

Core S/4HANA Business Partner table. Introduced with S/4 BP model. No classic equivalent — this replaces scattered address linkages previously held in LFA1/KNA1 fields directly.

Core S/4HANA table. Replaces legacy KNVK (customer contact persons) and analogous vendor contact structures. Time-dependency is mandatory — stale records without DATE_TO=99991231 are a common data quality issue.

BVOR continues to define asset transaction types in S/4HANA (acquisitions, retirements, transfers, etc.). These transaction types control posting logic and account determination for asset movements.

CAUFV is a database VIEW in both ECC and S/4HANA — not a physical table. Joins AUFK and AFKO. Exists unchanged in S/4HANA. The standard view used in virtually all ABAP programs that read production order data. Never contains data of its own; always reads from underlying AUFK/AFKO.

Unchanged in S/4HANA. Remains the primary field-level audit trail mechanism. Complements CDHDR (header). Volume can be extremely high in active systems — always filter by CHANGENR range or join to CDHDR first for date/object scoping.

CEPC remains the profit center master data table in S/4HANA. Profit center gains additional importance as it becomes a mandatory field on ACDOCA line items. Segment is derived from profit center for IFRS segment reporting.

Profit center text table unchanged in S/4HANA.

CKMLCR remains the core periodic valuation table in S/4HANA. With ML mandatory in S/4, this table is always populated.

CKMLHD is mandatory in S/4HANA as Material Ledger is always active. The table structure remains the same but its importance increases significantly in S/4HANA.

COBK stored CO document headers in ECC — each CO posting created a COBK record with document number, posting date, reference, and text. In S/4HANA, the concept of a separate CO document is eliminated. FI and CO are unified in ACDOCA, so there is no separate CO document header. COBK is no longer populated for new transactions. The BELNR in ACDOCA serves as the unified reference for both FI and CO aspects of every posting.

COEJ line items are merged into ACDOCA in S/4HANA. The Universal Journal contains all CO actual line items with the order number (AUFNR) as a native field. COEJ may still exist for compatibility but ACDOCA is the single source of truth.

COEP stored CO actual line items (costs by cost element, cost object, and value type) in ECC. It was the primary table for cost object controlling reports — cost center actuals, internal order costs, WBS element costs. In S/4HANA, CO no longer generates separate CO documents. Every cost-relevant FI posting writes one ACDOCA line item carrying all CO dimensions (cost center, order, WBS, profit center). COEP is no longer populated for new transactions. Historical COEP data is migrated to ACDOCA during system conversion.

COFP continues to be used for CO planning line items in S/4HANA. Planning data is not merged into ACDOCA (which is actual-only in most implementations). CO planning remains in the traditional CO tables.

COSP was the CO totals table for external (primary) cost postings, storing period-level aggregated actual and plan cost totals per cost object and cost element. In S/4HANA, totals are derived on-the-fly from ACDOCA — COSP is no longer maintained for new postings. This eliminates the delta update process and update bottlenecks that COSP caused in high-volume ECC systems. Custom code reading COSP for CO period totals must be rebuilt using ACDOCA aggregation or standard CDS analytical views.

COSS was the CO totals table for internal (secondary) cost postings — allocations, activity confirmations, and settlements. Like COSP, it stored period-level aggregated secondary cost totals per cost object and cost element. In S/4HANA, secondary cost postings (activity allocations, assessments, distributions, settlements) write directly to ACDOCA. Secondary cost elements are now real G/L accounts in S/4HANA, unifying the cost element / G/L account split that existed in ECC.

CRCO is unchanged in S/4HANA.

CRHD is unchanged in S/4HANA. Work centers are also referenced in the PPE (Production Process Model) object layer but CRHD remains the primary master data table.

CSKS is the cost center master data table — stores cost center definition, validity periods, responsible person, profit center assignment, and hierarchy area. In S/4HANA, CSKS is unchanged. Cost centers remain a core CO organizational element. The Fiori app 'Manage Cost Centers' reads from CSKS. Cost center hierarchies (CSKS.KHINR) are still defined in the standard hierarchy maintained via KS01/KS02.

Activity type master data structure remains the same in S/4HANA. Activity allocation functionality continues to use CSLA as the master table.

Text table remains unchanged in S/4HANA.

Table retained in S/4HANA. In S/4HANA Sourcing and Procurement, info records remain a core master data object.

Retained in S/4HANA. Works together with EINA for purchasing info record management.

No structural change in S/4HANA. EKKO remains the purchasing document header table.

Retained in S/4HANA.

No structural change in S/4HANA. EKPO remains the purchasing document item table.

Retained in S/4HANA. Source list is still used in S/4HANA Sourcing and Procurement for automatic source determination.

Retained in S/4HANA.

In S/4HANA, FAGLFLEXA is a compatibility view over ACDOCA. All New GL actual line items are stored directly in the Universal Journal. Migration from ECC moves FAGLFLEXA data into ACDOCA.

In S/4HANA, FAGLFLEXT is a compatibility view. Period totals are computed on-the-fly from ACDOCA line items. The table structure is maintained for backward compatibility but is no longer the primary data store.

FEBEP remains in S/4HANA as the line item table for electronic bank statements. Payment reconciliation still uses FEBEP, but the resulting FI postings go to ACDOCA. FEBEP links to BKPF/BSEG via the generated accounting documents.

GLPCA is completely replaced by ACDOCA in S/4HANA. The Universal Journal natively includes profit center as a field on every line item, eliminating the need for a separate EC-PCA ledger. All profit center reporting in S/4 reads from ACDOCA instead of GLPCA.

Unchanged in S/4HANA on-premise. In SuccessFactors, Organizational Management is handled by the Org Chart and Position Management modules in Employee Central. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. All org management relationships including reporting lines, matrix relationships, and position-to-person assignments are stored here. Cloud strategic direction: SuccessFactors Employee Central.

Retained in S/4HANA. Physical inventory processes are supported via transaction MI01-MI10.

Unchanged in S/4HANA. Core classification infrastructure. In S/4HANA with Variant Configuration (VC) and VCATT, INOB/AUSP remain central. Embedded Analytics CDS views for classification exist but map back to these structures.

Retained in S/4HANA.

JEST remains the central status management table in S/4HANA. No structural changes. Status management concepts (system status, user status, status profiles) work the same way.

Status object management unchanged in S/4HANA.

KAKO is unchanged in S/4HANA.

Product costing tables (KEKO, KEPH) remain largely unchanged in S/4HANA. The costing engine continues to use these tables for standard cost estimates.

Cost component split table remains unchanged in S/4HANA. Cost component structures and their configuration continue as before.

Customer master replaced by Business Partner (BP) model. BUT000 is the central BP table. Customers are BPs with role FLCU01. The BP model unifies customers, vendors, and contact persons.

KNVK stored customer contact persons in ECC — a dedicated table for individual contacts at customer organizations (name, phone, department, function). In S/4HANA, contact persons are modeled as Business Partners with a relationship to the customer BP. KNVK is replaced by BUT021 where a contact person BP is related to the customer BP via relationship type CRMH01 (contact person). KNVK data is migrated to BUT000/BUT021 during S/4HANA conversion. The transaction VD02/XD02 contact tab still works in S/4 but writes to the BP model.

KNVP stores customer-level partner function assignments: which business partners play which roles (sold-to, ship-to, bill-to, payer, sales rep, etc.) for each customer in each sales area. In S/4HANA, KNVP is retained as a compatibility table. In the full Business Partner model, partner functions are managed through BP relationships (BUT021), but KNVP continues to be populated for SD document partner determination.

Pricing conditions moved to PRCD_ELEMENTS. New table supports enhanced pricing capabilities and is used across SD, MM, and other modules.

Vendor master replaced by Business Partner (BP) model. Vendors are BPs with role FLVN01. Same BP number can be both customer and vendor.

In S/4HANA the vendor is a Business Partner (BUT000). LFA1/LFM1/LFB1 are retained as compatibility views mapped to BP data. New BP purchasing data lives in BUT000 + BP role FLVN01 attributes. replaced_by: BP purchasing organization data views.

MAPL is unchanged in S/4HANA.

No structural change in S/4HANA. MARA remains the client-level material master.

No structural change in S/4HANA. MARC remains the plant-level material master.

No structural change in S/4HANA. MARD remains the storage location inventory table.

Retained in S/4HANA. Unit of measure conversions remain critical for all logistics processes.

Retained in S/4HANA. Batch management is a core function across S/4HANA logistics.

Retained in S/4HANA. In S/4HANA, stock data may also be available via the Material Stock API.

MDKP exists in S/4HANA but in S/4HANA with MRP Live (MD01N), the planning engine is different. Classic MRP still writes to MDKP/MDTB, but MRP Live uses in-memory planning structures. MDKP/MDTB may be less populated in pure MRP Live environments.

MDTB exists in S/4HANA but may not be fully populated when MRP Live is active. In S/4HANA MRP Live, the stock/requirements list (MD04) reads from in-memory structures. For classic MRP, MDTB remains the persistent table.

Material document header merged into MATDOC. Header fields (posting date, user, etc.) are denormalized into each MATDOC line item.

Retained in S/4HANA.

Material document line items moved to MATDOC. MATDOC merges header (MKPF) and item (MSEG) data into a single table — same pattern as ACDOCA for finance.

Retained in S/4HANA. Central to the sales view of the material master.

In S/4HANA, newer output types use the Output Management framework (BRF+/Adobe Forms/CLM). NAST still exists for classic Smartforms/SAPscript outputs. Greenfield S/4 implementations may have minimal NAST data if Output Management is adopted fully.

Unchanged in S/4HANA. Still the central number range infrastructure for all object types.

PA tables persist in S/4HANA on-premise. For cloud deployments, SuccessFactors Employee Central replaces PA infotypes with Employee Profile and Employment Details objects. Integration via SAP Integration Suite.

Unchanged in S/4HANA on-premise. In SuccessFactors, organizational assignment is managed through Job Information portlet and Position Management. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. In SuccessFactors, personal data is stored in the Personal Information portlet. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. Managed entirely by payroll processing programs. In cloud, SuccessFactors Employee Central Payroll maintains equivalent status records.

Unchanged in S/4HANA on-premise. In SuccessFactors, stored in Address Information portlet with home/mailing/tax address types. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. In SuccessFactors, work schedules are managed in Work Schedule portlet with integration to SAP Time Management. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. In SuccessFactors Employee Central, compensation is managed in Compensation Information portlet with integration to Employee Central Payroll.

Unchanged in S/4HANA on-premise. In SuccessFactors, bank details are managed in Payment Information portlet with encryption for sensitive fields. Cloud strategic direction: SuccessFactors Employee Central.

Unchanged in S/4HANA on-premise. Recurring payments are replicated to SuccessFactors Employee Central Payroll for cloud payroll processing.