TPM_MIGRATION은 단순 데이터 이관이 아니라 S/4HANA의 Flow 기반 회계 구조로 거래를 재생성하는 엔진입니다. 성공의 핵심은 Flow Type, Update Type, Account Determination, BP, Valuation Area까지 포함한 IMG와 FI 연계 구조를 완결시키는 것이며, 검증은 ACDOCA까지 이어지는 회계 체인으로 수행해야 합니다.
TPM_MIGRATION 프로세스 설명: TRM Migration S/4HANA 구조의 본질
S/4HANA 기준에서 TPM_MIGRATION은 기존 Legacy TRM(Treasury and Risk Management) 거래를 새 구조로 “재생성”하는 엔진입니다. 쉽게 비유하면 이삿짐을 옮기는 게 아니라, 오래된 설계도로 지은 집을 최신 건축 기준에 맞춰 다시 도면화하는 작업에 가깝습니다. 여기서 중요한 키워드가 Universal Journal, ACDOCA, Flow Type, Update Type, Account Determination입니다. ECC에서는 거래, Flow, Posting 로직이 비교적 느슨하게 연결된 경우가 많았고, 운영 중 보정 로직에 의존하는 케이스도 적지 않았습니다. 반면 S/4HANA의 Transaction Manager S/4 변경사항은 Flow 기반 회계 처리와 Universal Journal 직접 반영이 훨씬 강해졌고, Business Partner 기반 마스터 통합까지 전제합니다.
아래 흐름을 먼저 머릿속에 넣으시면 좋습니다.
- Legacy TRM Data — 전환 전 ECC 거래/포지션 원천 데이터
- TPM_MIGRATION 실행 — Legacy 데이터를 S/4HANA 구조로 변환
- Flow 재생성 — S/4 Flow Builder 기준으로 Cash Flow 재구성
- Update Type 적용 — 거래 유형별 Update Type 매핑
- Account Determination — Update Type 기준 계정 결정
- FI Posting to ACDOCA — Universal Journal 전기 완료
위 다이어그램은 SAP Treasury Migration 흐름의 핵심만 추린 것입니다. 한 단계라도 정의가 비어 있으면 뒤 단계가 연쇄적으로 무너집니다.
TRM과 FI 통합 구조 이해의 핵심 체인은 아래와 같습니다.
- TRM 거래
- Flow Type
- Update Type
- Account Symbol
- G/L Account
- ACDOCA
실제 프로젝트에서 이런 케이스가 있었는데요. 거래 자체는 정상 이관됐는데 Flow Type 하나가 빠져서 파생 Flow가 안 만들어졌고, 결국 ACDOCA에 Posting이 생기지 않았습니다. 화면상 거래는 있어 보이니 더 헷갈리죠. 그래서 TPM_MIGRATION은 “거래 존재 여부”가 아니라 “회계 체인 완결 여부”로 봐야 합니다. 관련 Fiori App은 운영 환경에 따라 Treasury 포지션/전표 조회 앱을 병행할 수 있고, 검증용으로는 ACDOCA 기반 리포트 확인이 꼭 필요합니다. SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.
정리해보면 ECC와 S/4의 가장 큰 차이는 “데이터가 있느냐”가 아니라 “그 데이터가 회계적으로 다시 해석되느냐”입니다. TPM_MIGRATION은 바로 그 재해석의 중심입니다.

SAP Treasury Migration 흐름: IMG 설정 경로와 단계
S/4HANA 기준에서 Migration 성공의 80%는 선행 IMG에 달려 있다고 보셔도 과장이 아닙니다. 관련 트랜잭션은 주로 SPRO, 검증 단계에서는 TPM1 같은 후속 처리도 함께 봐야 합니다.
TRM과 FI 통합 구조 이해를 위한 전체 IMG 구조
SPRO 경로
SPRO > Financial Supply Chain Management > Treasury and Risk Management > Transaction Manager > General Settings
구조를 계층으로 보면 아래와 같습니다.
Company Code
└─ Valuation Area
└─ Flow Type
└─ Update Type
└─ Account Symbol
└─ G/L Account
이 구조는 “어디서 꼬였는지” 찾을 때도 그대로 쓰입니다. 위에서 아래로 내려가며 하나씩 확인하면 원인 분석이 빨라집니다.
Flow Type 설정
SPRO 경로
SPRO > Financial Supply Chain Management > Treasury and Risk Management > Transaction Manager > General Settings > Accounting > Define Flow Types
Flow Type은 단순한 분류 코드가 아닙니다. 어떤 현금흐름인지, 회계 반영 대상인지, 어떤 Update Type을 탈 것인지를 정합니다. 핵심 필드는 다음과 같습니다.
| 설정 항목 | 의미 | 실무 체크포인트 |
|---|---|---|
| Flow Category | 현금흐름 유형 | 원금/이자/평가 흐름 구분 확인 |
| Update Type | 회계 반영 방식 | Posting 로직과 직접 연결 |
| Relevant to Accounting | 회계 관련 여부 | 미체크 시 FI Posting 미생성 |
표에서 가장 많이 놓치는 게 Relevant to Accounting입니다. 현장에서 자주 마주치는 상황이에요. Flow는 생성됐는데 전표가 안 보이니 다들 Account Determination만 의심합니다. 그런데 실제 원인은 Posting 관련 체크 누락인 경우가 꽤 많습니다.
Account Determination 설정
SPRO 경로
SPRO > Financial Supply Chain Management > Treasury and Risk Management > Transaction Manager > General Settings > Accounting > Link to Financial Accounting > Define Account Determination
여기는 Flow를 실제 G/L로 연결하는 핵심입니다.
| Flow Type | Account Symbol | G/L Account |
|---|---|---|
| 원금 상환 | TR_PRIN | 11xxxx |
| 이자 발생 | TR_INT | 51xxxx |
| 평가 손익 | TR_VAL | 71xxxx |
이 표의 의미는 단순 매핑이 아니라, TRM의 의미 체계를 FI 계정 체계로 번역하는 작업입니다. Account Symbol이 빠지면 FINS_ACDOC_CUST 계열 오류로 이어지는 경우가 많습니다.
Valuation Area와 BP Mapping
Valuation Area는 Multi-GAAP, 병렬평가, 재평가 시나리오에서 특히 중요합니다. Migration 시점에 현재 포지션만 맞추면 끝이라고 생각하시면 안 됩니다. 이후 평가 배치까지 생각해야 합니다. 또 S/4HANA에서는 BP 기반 구조가 전제이므로 CVI 완료 여부, BP Role, 회사코드 데이터 정합성이 꼭 맞아야 합니다.
💡 S/4HANA 변경사항: Customer/Vendor 중심 연결보다 BP 통합 구조가 핵심이며, Universal Journal 반영을 전제로 회계 검증 범위가 넓어졌습니다.
TPM_MIGRATION 실행 전 체크리스트
- Product Type / Transaction Type 정합성
- BP 연결 및 역할 확인
- Currency / Valuation 설정 점검
- Flow Type, Update Type, Account Determination 선행 완료
- 샘플 거래로 예상 Flow와 생성 Flow 비교
부가 설명: IMG는 “설정 화면”이 아니라 회계 로직의 설계도입니다. TPM_MIGRATION 전에 이 설계도가 비어 있으면, 실행 자체는 돼도 결과가 맞을 가능성은 거의 없습니다.

Transaction Manager S/4 변경사항: 주요 포인트와 실무 팁
TPM_MIGRATION은 한 번 돌리고 끝나는 작업이 아닙니다. 반복 수행을 전제로 해야 합니다. 특히 Posting Flow와 Derived Flow 검증이 핵심이에요. 저는 보통 “예상해야 하는 흐름(Expected)”과 “실제로 생성된 흐름(Generated)”을 나란히 놓고 봅니다. 금액, 기준일, Flow Type, Posting 여부까지 같이 비교해야 합니다.
TPM_MIGRATION 수행 전 점검해야 하는 주요 포인트와 실무 팁을 정리하면 이렇습니다.
- FI 불일치 주요 원인
- Account Determination 누락
- Posting Flag 미체크
- Derived Flow 생성 규칙 미정의
- 운영 팁
- 회사코드/기간별 Batch Split
- 백그라운드 Job 병렬 처리
- 복잡한 파생흐름이 있는 샘플 거래 우선 테스트
- 후속 검증
TPM1등 후속 배치 영향 확인
- ACDOCA 전표 존재 여부와 금액 일치 검증
S/4HANA 변경사항을 요약해보면 Universal Journal 즉시 반영, BP 필수 구조, Flow 중심 회계 처리 강화라고 볼 수 있고 결국 TR Migration 성공의 기준은 프로그램 종료 메시지가 아닙니다. 생성된 Flow가 회계적으로 맞고, 이후 배치와 평가까지 문제없이 이어지는지가 진짜 기준입니다.

TPM_MIGRATION 프로세스 설명 실전: SAP Error Code 해결
아래는 프로젝트에서 자주 보는 메시지를 실무 관점으로 정리한 표입니다.
| Error Message | 메시지명 | 주요 원인 | 해결 방법 |
|---|---|---|---|
| TPM_MIGRATION 048 | No flow generated | Flow Type 누락, 거래유형 매핑 불일치 | Define Flow Types 및 거래유형 연결 재확인 |
| FINS_ACDOC_CUST 021 | Account determination not possible | Account Symbol 또는 G/L 매핑 없음 | Account Determination, Valuation Area 연결 점검 |
| TPM_TRAC 012 | Posting not possible | Update Type 미정의, Posting Relevant 미체크 | Update Type과 Relevant to Accounting 체크 확인 |
에러를 볼 때는 무조건 순서를 지켜야 합니다.
-
Flow가 생성됐는가
-
Update Type이 제대로 탔는가
-
Account Symbol이 결정됐는가
-
G/L 매핑이 가능한가
-
Posting이 ACDOCA에 반영됐는가
이 순서를 건너뛰고 바로 FI만 보면 원인을 놓치기 쉽습니다. 유사 메시지가 여러 개 겹칠 수 있으니, TPM_MIGRATION 로그와 Trace를 먼저 보고 “Flow 단계 문제인지, Account 단계 문제인지, Posting 단계 문제인지”를 분리하세요. 현장에서는 이 분리만 잘해도 분석 시간이 절반 이하로 줄어듭니다.
부가 설명: 에러 메시지 하나만 보고 원인을 단정하면 안 됩니다. Treasury Migration은 앞단 설정 누락이 뒷단 회계 오류로 나타나는 경우가 많아, 단계별 추적이 가장 중요합니다.

TPM_MIGRATION 프로세스 설명 마무리: 핵심 요약과 다음 단계
정리하면 TPM_MIGRATION은 단순 Migration Tool이 아니라 회계 구조 재생성 엔진입니다. 성공 포인트는 데이터 적재보다 Flow Type, Update Type, Account Determination, BP, Valuation Area를 포함한 IMG와 FI 연계 구조 이해에 있습니다. 그리고 실패 원인의 대부분은 결국 Flow → Account → Posting 체인 붕괴로 귀결됩니다.
핵심 3줄 요약:
- TPM_MIGRATION은 Legacy 거래를 S/4HANA의 Flow 기반 구조로 재생성합니다.
- 검증은 거래 존재 여부가 아니라 ACDOCA까지 이어지는 회계 체인 완결성으로 해야 합니다.
- Migration 테스트에서는 반드시 Flow 결과와 FI Posting을 함께 확인해야 합니다.
현재 프로젝트에서 TPM_MIGRATION 테스트 중이라면 Flow와 ACDOCA Posting을 반드시 같이 검증해보세요. 비슷한 이슈를 겪으셨다면 댓글로 공유해주세요. 다음에 읽으면 좋은 글로는 Transaction Manager S/4 변경사항 상세 분석, TRM과 FI 통합 구조: Posting Flow 중심 이해를 추천드립니다.
참고 출처
– SAP Help Portal – Treasury and Risk Management
– SAP Help Portal – Transaction Manager
– SAP Note 2344012
