Universal Journal ACDOCA Replacing Classic Totals Tables

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom ABAP reports, LSMW loads, and interfaces with direct SELECT statements against GLT0, FAGLFLEXT, COEP, COSP, COSS or the BSIS/BSAS/BSID/BSAD/BSIK/BSAK family must be checked; most still run against the compatibility views but performance and field content can differ, and some custom code inserts or updates those tables directly, which fails outright
• Custom Z-tables built as shadow copies of totals tables for performance reasons become redundant and sometimes contradict ACDOCA-based standard reports, causing finance to see two different numbers for the same period
• Authorisation objects built around the old table structure or around CO-specific transactions may not carry over cleanly, since some classic CO reporting transactions are hidden or replaced and users lose access they expected
• Month-end habits built around running a separate CO-FI reconciliation step, or checking cost centre actuals in a CO-only transaction before checking FI, no longer match the new real-time integrated posting flow, and finance teams keep running redundant reconciliation jobs out of habit
• Reports that joined FI and CO tables manually to get a combined view now duplicate what ACDOCA gives natively, and if not retired they risk double-counting or mismatched join keys
• Data volume and archiving strategy for the old tables needs a decision, since historical data before conversion sits in the old tables or is migrated into ACDOCA with historical load logic, and reporting across the cutover date can silently split into two different data sources

Migration actions

• Run a custom code impact scan (SAP's remote-enabled analysis tooling or an equivalent ABAP Test Cockpit check) against the full custom codebase to find every direct read, insert, update or delete against the classic totals and index tables; this is a mandatory pre-conversion gate, not optional cleanup
• Classify each finding: reads through the compatibility view usually work unchanged, but any direct write, any native SQL bypassing the view, and any use of table-specific technical fields that do not exist in ACDOCA must be remediated before cutover
• Retire or rebuild custom shadow totals tables and custom reconciliation reports that duplicated FI-CO reconciliation, since keeping them running in parallel with the Universal Journal produces conflicting numbers that finance will not trust
• Rebuild authorisation roles for any transaction or report that changes shape, particularly custom CO reporting variants and any Z-transaction built on the old table structure
• Plan the historical data strategy explicitly: decide whether prior-year data is migrated into ACDOCA, left in legacy tables for reference, or both, and document which reports read which source so nobody builds a report spanning the cutover date that silently mixes sources
• Retrain finance on the disappearance of the FI-CO reconciliation step and on any new drill-down paths, since old T-code muscle memory pointing at CO-only totals reports no longer reflects how the number was actually calculated

Whose problem this is

Common pitfalls

• A custom code scan run early in the project against a small subset of Z-programs misses reports generated dynamically or called through variant transactions, so items surface only during integration test or, worse, at first month-end close on the new system
• Compatibility views perform fine in unit test with a handful of documents but slow down badly once run against a full fiscal year of production-volume postings, because the view has to aggregate what used to be pre-summarised
• Teams keep a legacy CO-FI reconciliation report running after conversion 'just in case', and it produces a mismatch against ACDOCA-based standard reports purely because of timing differences in when each was refreshed, triggering a false alarm at the first close
• Historical data loaded into ACDOCA with a different granularity or default characteristic value (profit centre, segment) than what was used going forward creates a discontinuity in trend reports that nobody notices until a year-over-year comparison is run
• Authorisation testing focuses on transaction access but misses field-level or table-level authorisation changes tied to the old table structure, so a user who could see everything in ECC is unexpectedly restricted in production