SAP TPM_MIGRATION 단계별 실행 가이드와 데이터 정합성 확보하기

 

SAP TPM_MIGRATION 단계별 실행 가이드는 단순 프로그램 실행이 아니라, Flow와 Position 데이터 정합성을 재구성하는 핵심 전환 작업입니다.
현업에서는 G01 Test Run에서는 큰 문제 없어 보였는데 실행버튼을 눌러 전환 진행했을 때 실패하고, TPM13에서는 금액이 맞는데 TPM20에서 포지션이 어긋나며, TPM26까지 내려가면 Ledger 잔액이 틀어지는 상황이 자주 나옵니다.

여기서 많이 헷갈립니다. TPM_MIGRATION은 “한 번 돌리면 끝나는 마이그레이션 프로그램”이 아니라 G단계와 H단계로 나뉜 데이터 정비 프로세스에 가깝습니다. 특히 ECC 6.0에서 S/4HANA로 Brownfield Conversion(기존 ECC 시스템을 그대로 S/4HANA로 업그레이드)을 진행하는 경우, 기존 TRM 데이터가 Flow 중심으로 관리되던 구조와 S/4HANA의 Position/Quantity Ledger 중심 구조가 충돌하면서 문제가 드러납니다.

이 글은 운영 담당자와 컨설턴트가 실제로 확인해야 할 순서에 맞춰 정리했습니다. 선행 점검, G01~H03 단계 의미, TRDT_FLOW와 VTBFHAPO 연결 구조, TPM13·TPM20·TPM26 검증 순서, 그리고 DEV/QA/PRD에서 무엇이 CTS 대상이고 무엇이 Local 실행 대상인지까지 나눠서 보겠습니다.

 

TPM_MIGRATION을 프로그램으로 보면 실패하고, 데이터 구조로 봐야 풀립니다

ECC TRM에서는 거래별 현금흐름 관점이 강합니다. 그래서 Flow 데이터가 핵심이고, 실무 검증도 Flow 조회 중심으로 진행되는 경우가 많습니다. 반면 S/4HANA에서는 Position과 Ledger 관점이 더 중요해집니다. 잔액, 평가, 수량 기준 정합성을 맞추는 구조가 강화되기 때문입니다.

이 차이 때문에 TPM_MIGRATION이 필요합니다. 역할을 짧게 정리하면 다음과 같습니다.

• G계열: 기존 Flow 데이터를 전환 가능한 상태로 정리

• H계열: 정리된 Flow를 기반으로 Position과 Quantity Ledger 성격의 데이터를 생성 또는 보정

 

질문을 바꿔보면 이해가 더 쉽습니다.

• G01~G03은 무엇을 하나?
  기존 거래 데이터가 S/4HANA 구조로 넘어갈 준비가 되었는지 확인하고, 전환 상태를 관리합니다.

• H01~H03은 무엇을 하나?
  실제로 Position 또는 Ledger 성격의 결과 데이터를 만들고, 이후 조회와 평가가 가능하도록 맞춥니다.

 

실무적으로는 이렇게 이해하면 됩니다.

TRDT_FLOW → G단계 정리 → H단계 변환/생성 → TPM20/TPM26 검증

 

화면상으로는 단계 목록이 나열될 뿐이지만, 내부적으로는 데이터 성격이 다릅니다.
G계열은 Customizing/구조 점검 성격이 강하고, H계열은 실제 거래 데이터에 직접 영향을 주는 Transaction Data Conversion 성격이 강합니다. 운영 전환에서는 이 차이가 크게 중요해집니다.

실행 전에 막아야 할 선행 조건: SAP Note 2270529와 FIN_TRM SI14

상세 작성 계획에 포함된 기준대로 보면, 선행 조건은 두 가지가 핵심입니다.

1. SAP Note 2270529 적용 여부 확인

2. FIN_TRM SI14 Consistency Check 완료

이 두 개를 건너뛰고 TPM_MIGRATION부터 들어가면, 프로그램 오류처럼 보이지만 실제로는 사전 데이터 정합성 문제인 경우가 많습니다. SI-Check 단계에 확인되는 이 에러들은 반드시 관련 내용을 확인하고, 변화사항을 봐야 합니다.

리서치 자료 기준으로 SAP Note 2270529는 TPM_MIGRATION 관련 사전 준비와 오류 대응에 연결되는 핵심 참고 자료입니다. Note의 세부 구현 내용은 시스템 릴리즈와 적용 Support Package에 따라 다를 수 있으므로, 실제 반영 여부는 SNOTE 및 시스템 상태에서 확인해야 합니다.

FIN_TRM SI14는 특히 중요합니다.
이 단계는 “실행 가능 여부를 판정하는 사전 검사”에 가깝습니다. Error가 남아 있는데 Migration을 진행하면, G01에서는 Warning 수준으로 보였던 문제가 H01/H03에서 실제 실패로 바뀌는 일이 생깁니다.

여기서 실무 포인트는 명확합니다.

• SI14 Error 0건이 원칙

• Warning도 무시하지 말 것

• Conversion Mock Run에서 동일 결과가 재현되는지 확인할 것

• QA에서 정상이었다고 PRD 데이터도 자동으로 정상이 되는 것은 아님

G01~H03를 같은 선상에 놓으면 안 되는 이유

G01 단계 (OTC: Convert Customizing for Accrual/Deferral)

이 단계는 “전환이 가능한가”를 보는 사전 검증입니다.
Company Code, Product Type 등 대상 범위를 넣고 로그를 확인하게 되는데, 여기서 핵심은 성공/실패 한 줄이 아닙니다. 어떤 거래가 왜 위험한지, 어떤 불일치가 후속 단계에서 확대될지를 읽어야 합니다.

많이 나오는 오해가 하나 있습니다.
G01이 끝났다고 데이터가 정리된 것이 아닙니다.
이 단계는 실제 변경보다 진단 성격이 강합니다.

G02 이자율 및 수익률 곡선 기능 전환 (관련 항목: SI2: FIN_TRM)

일반적으로 TPM_MIGRATION에서 G01 이후의 커스터마이징 단계 중 하나는 이자율 및 수익률 곡선(Interest Rate and Yield Curve) 관련 설정의 전환입니다.

• 수행 내용: S/4HANA에서 변경된 이자율 및 수익률 곡선 엔진에 맞게 기존 시스템의 기술적 구성을 조정합니다.

• 시점: 기술적 컨버전 프로젝트 진행 중(During conversion)에 수행됩니다.

• 중요도: 시작 릴리스(Start-Release)의 버전 및 기능 포함 여부에 따라 조건부로 필수(Conditional Mandatory)가 될 수 있습니다.

G03 문서 송수신 기능 전환 (관련 항목: SI1: FIN_TRM)

H01 Position Migration: Flow를 Position으로 연결하는 핵심 단계

이 단계부터는 “실제 데이터 변환” 성격이 강해집니다.
계획상 핵심 대상 테이블로 제시된 VTBFHAPO가 여기서 중요합니다. 실무적으로는 Flow 정보가 Position 관점으로 정상 맵핑되는지 확인해야 합니다.

이때 자주 걸리는 원인은 다음 둘입니다.

• Product Type / Transaction Type 해석 불일치

• 선행 Flow 정합성 미확보

즉 H01 실패는 H01 자체 문제라기보다, G단계 또는 마스터/설정 누락의 결과인 경우가 많습니다.

• 의미: 수익 및 비용 이연의 트랜잭션 데이터(실제 데이터) 전환 단계입니다.

• 수행 내용: G01 단계에서 생성된 새로운 커스터마이징 설정이 운영/테스트 시스템에 반영된 후, 실제 이연 데이터를 새로운 데이터 모델로 마이그레이션합니다.

• 시점: 본 서버 컨버전 전(EhP 3 이상) 또는 후(EhP 3 미만)에 실행하며, G01 설정이 완료되어야 실행 가능합니다.

 

H02 Valuation Class Adjustment: 평가 구조 보정

이 단계는 직접 전표를 만드는 작업이라기보다, 이후 평가 처리와 계정결정 로직이 정상 작동하도록 분류 체계를 맞추는 성격으로 이해하면 됩니다.
평가 클래스 관련 해석은 버전별 차이가 있을 수 있으므로, 실제 필드와 세부 동작은 시스템에서 확인이 필요합니다.

H03 Quantity Position Creation: 수량 Ledger 정합성 완성

S/4HANA 구조에서는 Quantity Ledger 관점 검증이 중요해집니다.
그래서 H03까지 가야 비로소 TPM20과 TPM26 비교가 의미를 갖습니다. TPM13에서만 맞는다고 끝이 아닙니다. 이 부분은 실제 운영에서 꼭 나눠서 봐야 합니다.

• 의미: 수량 포지션(Quantity Positions) 생성 단계입니다.

• 수행 내용: 자금관리 데이터의 수량 원장(Quantity Ledger)을 S/4HANA 모델에 맞춰 재구성합니다.

• 실행 조건: 사전 점검(SI-Check) 시 SI14_TRQ 항목에서 오류(데이터 불완전)가 발생한 경우, 기술적 컨버전을 진행하기 위해 필수적으로 수행해야 합니다

💬 아는형의 메모

프로젝트 수행하면서 확인을 해보면 ECC에서 TPM26 프로그램을 실행하면 실행결과가 없을 것입니다. H03을 실행 후 시스템이 데이터 변환을 끝나면 TPM26 프로그램에서 조회시 데이터가 조회가 되어집니다.

어디서 무엇을 검증해야 하나: TPM13, TPM20, TPM26의 역할 분담

실무에서는 아래 순서를 고정으로 가져가는 편이 안전합니다.

1. TPM13: Flow 기준 확인

2. TPM20: Position 기준 확인

3. TPM26: Ledger 또는 후속 잔액 기준 확인

 

이 순서를 바꾸면 원인 추적이 어려워집니다.

예를 들어 TPM26 잔액이 틀어졌다고 바로 Ledger 문제로 보면 안 됩니다.
먼저 TPM13에서 원천 Flow가 맞는지, TPM20에서 Position이 정상 생성됐는지를 봐야 합니다. Ledger mismatch는 앞단 오류의 결과인 경우가 많습니다.

실무 체크 포인트를 정리하면 다음과 같습니다.

비교 구간	무엇을 본다	핵심 판단
TPM13	거래별 Flow 금액/건수	원천 흐름이 맞는가
TPM20	Position 생성 결과	Flow가 Position으로 정상 집계됐는가
TPM26	Ledger/잔액 결과	Position이 후속 장부 구조까지 일관되는가

 

여기서 계획에 포함된 핵심 포인트인 TRDT_FLOW 합계와 VTBFHAPO 합계 비교가 중요합니다.
테이블 필드 수준의 세부 합산 기준은 거래 유형과 버전에 따라 달라질 수 있으므로 시스템 정의를 함께 봐야 하지만, 큰 원칙은 같습니다.

• TRDT_FLOW 쪽에서 빠진 건이 없는가

• VTBFHAPO 쪽에서 Position이 누락되지 않았는가

• 만기 처리된 거래나 종료 거래가 예외적으로 남아 있지 않은가

💬 아는형의 메모

저의 경우는 원화/외화 예적금, 차입금 등의 현재 진행중인 거래를 우선 추출하고 VTBFHAPO, TRDT_FLOW 테이블의 건수, TPM13,TPM20, TPM12등의 실행결과를 비교하여 이상여부를 확인하였습니다. 특히 발생/이연 거래 내역 관련하여 기존에는 VTBFHAPO에 같이 잡혀있었으나 H01 실행 후에는 VTBFHAPO 테이블에서 삭제되고 TRDT_FLOW에 모두 포함되는 부분에 대한 체크가 반드시 있어야 합니다.

G01에서 Warning만 보인 거래는 반드시 별도 리스트로 빼두는 편이 좋습니다. Cutover 당일에는 “실패한 거래”보다 “경고였지만 실제로는 후속 단계에서 깨지는 거래”가 더 찾기 어렵습니다.

IMG와 선행 설정은 전표보다 먼저, 하지만 영향은 뒤늦게 나타납니다

계획상 제시된 IMG 경로는 다음과 같습니다.

SPRO > Financial Supply Chain Management > Treasury and Risk Management > Transaction Manager > General Settings

다만 TRM 영역의 세부 메뉴 구조는 릴리즈와 활성화된 Business Function에 따라 일부 차이가 있을 수 있으므로, 실제 시스템 메뉴에서 확인이 필요합니다.

사전 설정으로 특히 확인해야 할 항목은 다음입니다.

• Valuation Area

• Product Type

• Transaction Type

• Account Determination

이 설정들은 TPM_MIGRATION이 직접 전표를 만드는 단계와는 구분해서 봐야 합니다.
즉, 이 설정 자체가 바로 FI 전표를 생성하지는 않습니다. 다만 이후 Position, 평가, 계정결정, Ledger 반영 과정에서 문제를 드러내기 때문에 “설정은 예전부터 있었는데 왜 이제 오류가 나지?”라는 상황이 나옵니다.

회계 관점에서도 이 점이 중요합니다.
TPM_MIGRATION 자체는 전환/정비 작업이므로 일반적인 운영 전표처럼 차변/대변을 즉시 설명하는 주제가 아닙니다. 하지만 이후 평가나 후속 Posting에서 계정결정이 잘못되면 실제 전표 오류로 연결될 수 있습니다. 그래서 Conversion 단계에서 Customizing과 Transaction Data를 분리해 보는 것이 맞습니다.

자주 막히는 지점은 에러보다 원인 분류가 먼저입니다

계획에 포함된 오류 유형을 실무용으로 다시 정리하면 다음과 같습니다.

증상/오류	원인	확인 위치	해결 방법	주의사항
Flow inconsistency detected	TRDT_FLOW 정합성 문제	G01 로그, TPM13	Flow 상세 분석 후 원천 데이터 정리	Warning으로 끝나도 H단계 실패 가능
Position cannot be generated	Flow→Position 매핑 실패, Product/Transaction Type 영향	H01 로그, TPM20, 관련 설정	선행 G단계 점검, Product Type/Transaction Type 확인	H01만 재실행하기 전에 상태값 확인 필요
Quantity Ledger inconsistency	Position과 Ledger 결과 불일치	H03 로그, TPM20/TPM26	Position 집계와 Ledger 결과 비교	앞단 오류를 먼저 제거해야 함
Migration Status 관련 재실행 오류	중간 실패 후 상태 꼬임	G03, 실행 로그	상태 확인 후 재실행 전략 수립	임의 초기화는 위험, 백업/리허설 필요

여기서 핵심은 “오류 메시지 해결”보다 “원인 분기”입니다.

• Customizing 문제인가

• Master Data 문제인가

• Transaction Data 문제인가

• Version/Conversion 차이인가

TPM_MIGRATION은 특히 Transaction Data + Conversion 상태 관리 이슈가 많습니다.
그래서 단순히 IMG만 뒤지는 방식으로는 해결이 안 됩니다.

 

DEV, QA, PRD를 같은 방식으로 보면 Cutover에서 사고 납니다

Conversion 주제에서는 이 구분이 반드시 들어가야 합니다.

구분	실무 판단
DEV	Customizing 정비, 노트 반영 검토, 단위 테스트
QA	CTS Import 후 Mock Conversion, 데이터 검증 시나리오 수행
PRD	실제 Cutover 실행, 백업 후 Local 데이터 변환
CTS 대상	Customizing, Repository, Note 반영 결과
Local 실행 대상	TPM_MIGRATION과 같은 실제 데이터 변환 실행

 

특히 강조할 점은 다음입니다.

• G계열은 Customizing/구조 변환 성격이 강하다

• H계열은 실제 데이터 변환 성격이 강하다

• QA에서 실행했다고 PRD 데이터가 변환되는 것은 아니다

• PRD에서는 실제 운영 데이터 기준으로 다시 실행해야 한다

또 하나.
Logical System은 SID와 동일하다고 단정하면 안 됩니다. Conversion 문맥에서는 BD54 기준 Logical System Name을 봐야 하는 경우가 많습니다. 이 부분은 실제 전환 설계서와 시스템 정의를 기준으로 맞추는 것이 안전합니다.

재실행 가능 여부도 중요합니다.
Migration 상태가 남는 프로그램은 “다시 돌리면 되겠지”가 가장 위험합니다. PRD에서는 반드시 다음이 필요합니다.

• 실행 전 백업 또는 복구 전략

• 대상 건수 사전 스냅샷

• 실행 후 건수 비교

• TPM13/TPM20/TPM26 검증

• 실패 시 되돌림 가능 여부 사전 확인

QA에서 최소한 이 순서로 검증해야 PRD에서 덜 흔들립니다

Step	작업	입력값 예시	확인 화면/테이블	기대 결과
1	SAP Note 및 선행 조건 확인	Note 2270529	SNOTE, 관련 문서	선행 조건 충족
2	SI14 정합성 점검	회사코드 1000, 가상 예시	FIN_TRM SI14	Error 0건
3	G01 Test Run 실행	회사코드 1000, Product Type 예시	TPM_MIGRATION 로그	위험 거래 식별
4	G02/G03 수행	동일 범위	실행 로그, 상태 정보	Flow 정리 및 상태 반영
5	H01 수행	동일 범위	TPM20, VTBFHAPO	Position 생성 확인
6	H02/H03 수행	동일 범위	TPM26, 관련 결과 화면	Ledger/수량 정합성 확보
7	원천-결과 비교	거래번호 예시 100000001	TPM13, TPM20, TPM26	금액/건수 일관성 확인
8	재실행 리허설	실패 케이스 1건	상태 로그	재실행 절차 검증 완료

 

각 회사 ECC Sandbox의 거래를 샘플링하여 그에 맞추어 테스트 해보는 것이 중요합니다.  실제 회사코드, 상품유형, 거래번호는 프로젝트 범위에 맞게 바꿔야 합니다.

검증 시나리오에서 특히 봐야 하는 것은 두 가지입니다.

1. 만기 또는 종료된 거래가 데이터가 정상적으로 흐름이 보이는지, 포지션이 정상적으로 보이는지

2. G01 Warning 대상이 H단계에서 실제 오류로 전환되는지

이 두 개를 놓치면 QA는 통과했는데 PRD Cutover에서만 실패하는 일이 생깁니다.

결국 성공 기준은 프로그램 완료가 아니라 데이터 일치입니다

SAP TPM_MIGRATION의 핵심을 한 줄로 줄이면 이렇습니다.
G01~G03은 Flow를 정리하는 단계이고, H01~H03은 Position과 Ledger를 실제로 맞추는 단계입니다.

그래서 성공 기준도 바뀌어야 합니다.

• 프로그램이 종료되었는가 → 부족

• 로그에 에러가 없는가 → 부족

• TPM13, TPM20, TPM26이 일관되는가 → 진짜 기준

 

실무에서 꼭 기억할 세 가지를 남기면 다음과 같습니다.

1. FIN_TRM SI14를 먼저 끝내야 합니다.

2. TRDT_FLOW와 VTBFHAPO 정합성을 중간중간 끊어서 확인해야 합니다.

3. 각 거래별 건수 및 흐름이 정상적으로 VTBFHAPO와 TRDT_FLOW에 반영이 되었는지

 

TPM_MIGRATION은 프로그램 실행 작업이 아니라 데이터 품질 프로젝트에 가깝습니다.
이 관점으로 접근해야 G01 Warning, H01 실패, TPM26 잔액 불일치를 같은 선에서 연결해 볼 수 있습니다.

 

참고 자료

• SAP Note 2270529 — TPM_MIGRATION 관련 선행 준비와 오류 대응 확인에 필요한 참고 자료

• SAP Help Portal TRM Migration — S/4HANA TRM 전환 구조와 버전별 동작 차이 확인에 필요한 공식 문서