안녕하세요, 아는 형입니다.
ECC에서 S/4HANA Conversion을 진행할 때 FI모듈만큼 손이 많이 가는 모듈이 바로 TR(Treasury)입니다. 그런데 재밌는 건, TR 쪽은 단순히 화면이 바뀌는 수준이 아니라 데이터 모델, 마이그레이션 방식, 회계연계 구조 자체가 통째로 달라진다는 점입니다. 그래서 Simplification이라는 단어만 보고 “화면 좀 간단해지는가보다” 하고 넘어가면 나중에 진짜 크게 당황하실 수 있습니다.
이런 변화 때문에 생기는 문제를 SAP는 SI-Check라는 단계를 통해서 미리 알려줍니다. 무엇이 바뀌고, 무엇을 조치해야 하는지를요.
SI-Check란 무엇인가
SI-Check는 ECC → S/4HANA Conversion 전에 “현재 시스템에서 S/4HANA로 바뀌는 기능 때문에 문제가 생길 부분이 있는지”를 미리 검사하는 도구라고 이해하시면 가장 쉽습니다. Readiness Check보다 훨씬 더 직접적으로, “전환을 막는 항목이 있는지”를 확인하는 기술 점검에 가깝습니다.
SI = Simplification Item
SI-Check는 Simplification Item Check의 줄임말입니다. 여기서 Simplification Item이란,
ECC에서는 이렇게 사용했지만 S/4HANA에서는 데이터 구조, 기능, T-code, 프로세스 등이 변경되었기 때문에 전환 전에 조치가 필요한 항목
을 의미합니다. SAP 공식 설명에서도 SI-Check는 현재 시스템이 S/4HANA Conversion을 기술적으로 수행할 준비가 되었는지 확인하는 검사이며, 대표 실행 프로그램은 /SDF/RC_START_CHECK라고 명시하고 있습니다.
쉽게 비유하면 이렇습니다. ECC → S/4HANA로 이사를 한다고 생각해 보세요.
- Readiness Check = “이사하려면 무엇을 준비해야 하지?”
- SI-Check = “지금 상태로 이삿짐을 실제 옮길 수 있나?”
- ATC = “내가 직접 만들어 놓은 Z프로그램은 새집에서도 작동하나?”
- SUM = “실제 이사를 수행하는 이사업체”
왜 S/4HANA Conversion에서 SI-Check가 필요한가
ECC에서 S/4HANA로 가는 건 단순히 SAP 버전을 올리는 작업이 아닙니다. 예를 들면 이런 변화들이 있습니다.
| ECC | S/4HANA |
|---|---|
| 고객/공급업체 중심 Master | BP 중심 |
| Classic Asset Accounting | New Asset Accounting |
| FI 여러 데이터 구조 | Universal Journal 중심 |
| 일부 기존 테이블 직접 사용 | 신규 데이터모델/View 사용 |
| 일부 T-code 사용 | 대체/폐기 |
| 기존 데이터 구조 | S/4 신규 데이터 구조 |
이 상태에서 데이터가 잘못되어 있거나 필수 선행조건이 충족되지 않았는데 바로 Conversion을 시도하면, SUM의 Data Conversion 단계에서 실패할 수 있습니다. 그래서 SAP가 먼저 검사를 하는 겁니다.
“이 ECC 시스템의 Customizing과 데이터가 S/4HANA 구조로 변환 가능한 상태인가?”
이게 SI-Check의 핵심입니다. 이 결과 조치가 필요하다고 확인되면, 컨설턴트는 내용을 확인하고 수정을 진행하게 됩니다.
TR쪽 SI-Check에 대한 자세한 내용은 이전에 다뤘던 S/4HANA SI-Check Return Code 7, SI14_TRQ·SI14_ACCR 예외 처리하기를 참고해주세요.
이제 확인된 SI-Check 결과에서 나온 SAP Notes를 확인하고, Note의 가이드에 따라 TR Migration을 위한 사전 Config Setting을 진행해야 합니다.
SI-Check 결과 확인
이번 건에서 확인된 항목은 다음과 같습니다.
- SI3: FIN_TRM → SAP Note 2270462
- S14: FIN_TRM → SAP Note 2270529
참고로 관련 배경 자료는 S4TWL – Obsolete Transaction Codes and Programs in Treasury and Risk Management (TRM)이니, 관련 내용이 궁금하신 분은 함께 확인해보시면 좋습니다.
사전 준비: 신규 CTS 생성 및 Logical System 확인
1) 신규 CTS 생성(T-code : SE09)
TR Migration 설정을 담을 전송 요청(Transport Request)을 먼저 하나 만들어둡니다. 이 CTS 번호는 뒤에서 마이그레이션 유형을 커스터마이징 요청에 지정할 때 그대로 사용됩니다.
2) Logical System 확인 (T-code: BD54)
생산 시스템의 Logical System 이름을 BD54에서 미리 확인해둡니다. 이 값은 나중에 마이그레이션 유형 설정 화면에서 Production System, Test System, Customizing System 값으로 그대로 들어가기 때문에, 여기서 오타가 나면 뒷단에서 애매하게 꼬입니다.
사전 Config: 마이그레이션 유형 설정 및 커스터마이징 요청에 지정
경로는 다음과 같습니다.
Transaction Manager → General Settings → Tools → Conversion → Conversion Customizing → Set Migration Type and Assign to Customizing Request
여기 들어가면 처음에는 아무것도 설정이 안 되어 있습니다. 세팅을 위해 [신규엔트리]를 눌러줍니다.
Migration Type은 “Conversion from >= Enterprise 2.0 and <= ERP 6.0” 항목을 선택합니다. 그리고 앞서 만든 CTS 번호와 논리시스템 정보를 입력하고 저장합니다.
이때 요청/태스크에는 먼저 생성했던 CR 번호를 적고, 생산시스템/테스트시스템/커스터마이징시스템에는 각각 BD54에서 확인한 Logical System 정보를 입력합니다. 참고로 SAP는 아래와 같은 형식으로 입력할 것을 권장합니다.
| 입력 항목 | 설명 | 예시 (SID가 각각 DEV, QAS, PRD인 경우) |
|---|---|---|
| Customizing Request | 설정을 저장할 전송 요청(Transport Request) 번호 | DEVK900123 |
| Production System | 운영 시스템의 논리 시스템 이름 | PRDCLNT100 |
| Test System | 테스트(품질) 시스템의 논리 시스템 이름 | QASCLNT200 |
| Customizing System | 개발(커스터마이징) 시스템의 논리 시스템 이름 | DEVCLNT100 |
논리 시스템 이름은 일반적으로 <SID>CLNT<Client Number> 형식을 따릅니다.
여기서 놓치기 쉬운 부분이 하나 있습니다. 입력할 이름은 반드시 실제 각 시스템의 T000 테이블이나
SALE트랜잭션(IDoc Interface / ALE → Basic Settings → Logical Systems → Assign Logical System to Client)에서 정의된 이름과 정확히 일치해야 한다는 겁니다. 그리고 여기서 지정한 전송 요청을 통해서 마이그레이션 유형 설정이 후속 시스템(테스트, 운영)으로 전송된다는 점도 기억해두세요. 이 설정을 완료한 뒤에는TPM_MIGRATION을 실행해서 실제 데이터 전환 단계(H02, H03 등)로 넘어가게 됩니다.
요약하자면, 이 메뉴에서 요구하는 시스템 이름은 각 시스템 환경에서 정의된 논리 시스템 코드(예: PRDCLNT100)를 의미하며, 이걸 정확히 입력해야 전송 체계 안에서 마이그레이션 상태가 제대로 관리됩니다.
이번 작업에서는 개발 시스템만 먼저 생성된 상태라 QA/PRD 시스템이 아직 없었습니다. 그래서 서버별로 각각 실행하는 방식을 적용했습니다.
다음과 같이 CTS 창이 뜨면, CTS 번호를 연결한 뒤 확인을 누릅니다.
TPM_MIGRATION 실행 화면으로 확인해보기
이제 T-code TPM_MIGRATION을 실행하면 화면이 정상적으로 전환되는 걸 확인할 수 있습니다.
참고로, 이 설정 작업을 진행하지 않은 상태에서 TPM_MIGRATION 프로그램을 실행하면 “전환 유형이 없습니다”라는 메시지와 함께 아무것도 실행되지 않는 걸 확인할 수 있습니다. 혹시 이 메시지 보신 분 계신가요? 저도 처음엔 뭐가 문제인지 한참 헤맸습니다.
그리고 Note에서 언급하는 TRGT_MIG_CC_PT에도 TR Migration이 아직 실행되지 않아 아무 정보도 없는 상태인 걸 확인할 수 있습니다.
여기까지가 TPM_MIGRATION 실행 전 사전 Config Setting을 진행한 내역입니다.
돌이켜보면 이 단계 자체는 화면 몇 개 채우고 저장 버튼 누르는 게 전부라 별거 아닌 것처럼 보입니다. 그런데 막상 TPM_MIGRATION을 실행했을 때 “전환 유형이 없습니다”라는 메시지 하나만 딱 뜨고 아무 단서도 안 주니, 처음 겪으면 어디서부터 봐야 할지 감이 안 옵니다. 저도 그때 SI-Check 결과랑 Note를 다시 뒤져가며 이 설정 화면을 찾아냈던 기억이 나네요.
결국 TR Migration은 이 사전 Config가 제대로 잡혀 있어야 다음 단계로 넘어갈 수 있는 구조입니다. 논리 시스템 이름 하나, CTS 번호 하나가 틀어져도 화면 자체가 안 열리니, 실제 작업 들어가시기 전에 BD54랑 SALE 트랜잭션에서 값부터 한 번 더 확인하고 시작하시길 권합니다.
다음 글에서는 이렇게 설정을 마친 상태에서 실제 TPM_MIGRATION 수행 과정이 H02, H03 단계를 거치며 어떻게 진행되는지, 그리고 그 과정에서 저희가 실제로 마주쳤던 이슈들까지 이어서 다뤄보겠습니다.
궁금하신 분은 TPM_MIGRATION 처리는 어떻게 해야 할까? 로 바로 고고싱 하세요!