S/4HANA Finance에서 가장 근본적인 변화 하나만 꼽으라면 단연 **Universal Journal**, 그리고 그 실체인 테이블 `ACDOCA`다. ECC에서 재무 데이터가 여러 테이블에 제각기 흩어져 있던 것을, S/4HANA는 **하나의 라인아이템 테이블로 합쳤다.** 이 한 번의 통합이 FI와 CO의 경계, 마감 절차, 리포팅, 그리고 커스텀 코드까지 전부 바꿔놓았다. 정리하면 이렇다. ECC의 FI(`BSEG`)·CO(`COEP`)·자산회계(`ANEP`)·재료원장(`MLIT`)이 각자 들고 있던 데이터가 `ACDOCA` 한 곳으로 모였고, 둘 사이를 맞추던 **조정(reconciliation) 작업이 사라졌으며**, 원가요소와 GL 계정이 하나로 합쳐졌다. 아래에서 왜 이렇게 바꿨고, 옛 테이블은 어떻게 됐고, 컨설턴트가 반드시 알아야 할 것이 무엇인지 차근차근 본다. ## 1. ECC의 문제 — 데이터가 여러 테이블에 흩어져 있었다 ECC의 재무 데이터 구조는 분산돼 있었다. 같은 전표 하나가 모듈마다 다른 테이블에 다른 모습으로 쌓였다. | 영역 | 라인아이템 | 집계/인덱스 테이블 | |---|---|---| | 재무회계(FI-GL) | `BSEG`, `FAGLFLEXA` | `GLT0`, `FAGLFLEXT` | | 채권/채무(AR/AP) | `BSEG` | `BSID`/`BSAD`(고객), `BSIK`/`BSAK`(공급업체) | | GL 미결/결제 | `BSEG` | `BSIS`/`BSAS` | | 관리회계(CO) | `COEP` | `COSP`(1차), `COSS`(2차) | | 자산회계(FI-AA) | `ANEP`, `ANEA` | `ANLP`, `ANLC` | | 재료원장(ML) | `MLIT` | `MLCD` 등 | 문제는 두 가지였다. 첫째, **같은 숫자가 여러 테이블에 중복 저장**됐다(라인아이템 + 집계 + 인덱스). 디스크와 갱신 비용이 컸고, 어디 하나가 어긋나면 정합성이 깨졌다. 둘째, **FI와 CO가 서로 다른 값을 들고 있어** 둘을 맞추는 조정(reconciliation) 작업이 상시 필요했다. CO 전표 하나가 라인아이템(`COEP`)과 집계(`COSP`/`COSS`)에 따로 쌓이는 식이었다. ## 2. 해결 — 라인아이템을 ACDOCA 하나로 S/4HANA는 이 모든 라인아이템을 **하나의 테이블 `ACDOCA`(Universal Journal)로 통합**했다. FI, CO, 자산회계, 재료원장, 그리고 수익성분석(account-based CO-PA)까지 한 줄에 담긴다. 그래서 ACDOCA는 필드가 300개를 훌쩍 넘는다 — FI의 계정·금액에 더해 CO의 원가센터·수익센터·오더, 자산, 수량, 다중 통화가 한 행에 다 들어가기 때문이다. 핵심 효과는 이것이다. **모든 재무 앱이 이제 ACDOCA를 바라보는 뷰(view)가 됐다.** 데이터를 모듈 사이로 복사하거나 사후에 맞출 필요가 없다. 한 앱의 속성(예: CO의 수익센터)이 다른 앱(FI)에서도 그대로 보인다. "하나의 원장에 모두 기록하고, 보고는 관점만 달리한다"가 Universal Journal의 한 줄 요약이다. ## 3. 그럼 옛 테이블은 어떻게 됐나 가장 많이 오해하는 부분이다. **`BSEG`와 `BKPF`는 사라지지 않았다.** 둘은 여전히 실제 테이블로 남아 전표가 기록된다. 다만 역할이 갈렸다 — `BSEG`는 "재무 운영(financial operations)" 라인아이템, `ACDOCA`는 "재무회계(financial accounting)" 라인아이템으로, ACDOCA가 보고와 분석의 단일 원천이다. 참고로 ECC의 `BSEG`는 전표 한 건에 **라인 999개**라는 오래된 제약이 있었는데, `ACDOCA`는 이 한계를 크게 풀어 분개를 훨씬 세밀하게 기록한다. Universal Journal을 기존 `BSEG` 확장이 아니라 새 테이블로 설계한 이유 중 하나다. 반면 **중복 집계·인덱스 테이블들은 더 이상 데이터를 들고 있지 않다.** HANA의 컬럼 저장 덕분에 라인아이템에서 즉석 집계가 가능해, 미리 합산해 둘 이유가 없어졌기 때문이다. 이들은 **호환 뷰(compatibility view)**로 바뀌었다. 핵심은 **옛 테이블 이름(`BSIS`·`COSS` 등)이 그대로 뷰 이름이 된다**는 점이다. 그래서 기존에 `SELECT ... FROM COEP` 하던 코드가 수정 없이도 돌아가되, 실제 데이터는 ACDOCA에서 즉석 계산해 돌려준다. | 옛 테이블 | S/4HANA에서 | |---|---| | `BSEG`, `BKPF` | 실제 테이블로 유지 (전표 기록) | | `COEP` (실적 WRTTP=04) | 데이터는 `ACDOCA`로, 접근은 호환 뷰 | | `GLT0`, `FAGLFLEXT` (GL 집계) | 호환 뷰 — ACDOCA에서 즉석 집계 | | `BSIS`/`BSAS`/`BSID`/`BSAD`/`BSIK`/`BSAK` (인덱스) | 호환 뷰 | | `COSP`/`COSS` (CO 집계) | 호환 뷰 | | `ANEP`·`ANEA`·`ANLP`·`ANLC` (자산 실적) | 데이터는 `ACDOCA`로 | 전환 전의 원본 데이터를 그대로 봐야 할 때는 `V_*_ORI` 형태의 뷰(예: `V_COEP_ORI`)로 마이그레이션 이전 값에 접근할 수 있다. "테이블 이름은 그대로 읽히는데 실제로는 뷰더라"가 S/4HANA Finance를 처음 만질 때 가장 헷갈리는 지점이다. ## 4. 원가요소 = GL 계정 ECC에서 원가요소(cost element)는 CO의 마스터 데이터로, GL 계정과 별도로 관리됐다(`KA01`/`KA06`). S/4HANA는 이 둘을 **하나로 합쳤다.** 이제 원가요소는 GL 계정의 한 종류이고, **GL 계정 유형(account type)이 용도를 결정한다.** - **1차 원가요소** → GL 계정 유형 "Primary Costs or Revenue" - **2차 원가요소** → GL 계정 유형 "Secondary Costs" — 이제 **계정과목표(chart of accounts)의 일부**다. 즉 별도의 원가요소 마스터가 사라지고, GL 계정 마스터(`FS00`) 안에서 함께 관리된다. 2차 원가요소(내부 정산·배부에 쓰던)까지 GL 계정이 되면서 FI와 CO가 같은 계정 체계 위에 서게 된 것이다. 이것이 다음 변화로 곧장 이어진다. ## 5. FI-CO 조정 원장이 없어졌다 FI와 CO가 같은 테이블(ACDOCA)·같은 계정 체계를 쓰게 되면서, 둘을 맞추던 **조정 원장이 통째로 필요 없어졌다.** ECC에서 CO 내부 전표(예: 부서 간 배부)가 FI에 실시간 반영되지 않아 주기적으로 맞춰주던 작업(`KALC` 등)이 S/4HANA에선 사라진다. CO 전표가 곧 ACDOCA 전표이고, 그게 곧 FI에서도 보인다. 집계 테이블이 필요 없어진 것도 같은 이유다. `COSP`/`COSS`/`GLT0`에 미리 합산해 두지 않아도, 라인아이템(ACDOCA)에서 바로 집계해 보고하면 되기 때문이다. ## 6. 통화와 병렬 원장 ECC에서는 FI와 CO가 각자의 통화 설정을 따로 들고 있었다. Universal Journal은 이 통화 개념을 **하나로 통합**했고, 한 라인아이템에 **여러 통화(원장별 최대 10개 — 기본 2개 + 자유 정의 8개)**를 동시에 담는다. 회사 통화·그룹 통화·거래 통화 등을 한 줄에서 다 들고 가니, 통화별 보고에 추가 변환이나 별도 테이블이 필요 없다. 병렬 회계도 같은 테이블 위에서 푼다. **원장(ledger, `RLDNR`)** 개념으로 대표 원장(leading ledger `0L`)과 병렬 원장을 함께 두어, IFRS와 로컬 GAAP처럼 서로 다른 회계 기준을 한 ACDOCA 안에서 나란히 기록한다. ## 7. 컨설턴트 필독 5가지 1. **`BSEG`/`COEP`는 안 사라졌다, 다만 데이터의 단일 원천은 ACDOCA다.** 보고·분석은 ACDOCA 기준으로 봐야 한다. 2. **FI-CO 조정이 없다.** 실시간 통합이라 "CO와 FI가 안 맞는다"는 옛 고민 자체가 사라진다. 3. **원가요소는 GL 계정이다.** 마스터가 통합됐고, 2차 원가요소도 계정과목표에 들어온다. 4. **account-based CO-PA가 기본.** 수익성분석이 ACDOCA에 통합돼, costing-based CO-PA와 달리 FI와 항상 일치한다. 5. **마이그레이션 때 과거 라인아이템이 ACDOCA로 이관된다.** 전환 시 ECC의 `BSEG`/`COEP`/`FAGLFLEXA` 등이 ACDOCA로 매핑돼 들어오므로, 코딩블록(coding block) 정합성과 과거 데이터 품질이 마이그레이션 성패를 가른다. ## 8. 커스텀 코드·리포팅에 주는 영향 집계·인덱스 테이블이 뷰로 바뀐 건 개발자에게 직접적인 영향을 준다. ECC에서 `GLT0`나 `BSIS`를 직접 `SELECT`해 빠르게 합계를 읽던 커스텀 리포트는, S/4HANA에선 그 뷰가 매번 ACDOCA에서 집계를 돌리므로 **대량 조회 시 성능 특성이 달라진다.** 새로 짜는 리포트는 호환 뷰를 우회해 **ACDOCA를 직접 읽거나, 표준 CDS 뷰를 쓰는 쪽**이 낫다. 이런 식으로 옛 테이블을 가정하고 짠 코드가 깨지는 지점은 [커스텀 코드 적응](/education/custom-code-adaptation-s4hana) 글에서 다룬 ATC 점검으로 미리 잡아낸다. ## 자주 묻는 질문 **ACDOCA가 뭔가요?** S/4HANA의 Universal Journal 라인아이템 테이블입니다. FI·CO·자산회계·재료원장·수익성분석을 한 테이블에 통합한 단일 원천입니다. **그럼 BSEG는 없어졌나요?** 아니요. `BSEG`와 `BKPF`는 실제 테이블로 남아 전표가 기록됩니다. 다만 보고·분석의 단일 원천은 ACDOCA이고, `BSIS`·`GLT0`·`COSP` 같은 집계/인덱스 테이블이 호환 뷰로 바뀌었습니다. **FI-CO 조정(reconciliation)은 왜 없어졌나요?** FI와 CO가 같은 테이블·같은 계정 체계(원가요소=GL 계정)를