CVI(Customer Vendor Integration) 설정은 S/4HANA 전환에서 가장 먼저 정합성을 확보해야 하는 핵심 영역입니다. Vendor/Customer 마스터와 BP(Business Partner) 마스터를 연결·동기화하는 데이터 모델 통합 레이어로, BP 중심의 단일 마스터 구조가 S/4HANA의 핵심입니다. Vendor Customer BP 매핑, Number Range 정합성, Field Mapping 이 세 가지가 가장 중요한 축이며, MDS_LOAD_COCKPIT은 단순 이관 도구가 아니라 CVI 설정 검증 단계로 이해해야 합니다. SPRO 설정 순서, 오류 해결 방법, 실무 체크리스트를 이 글에서 단계별로 정리합니다.
CVI 설정은 S/4HANA 전환 프로젝트에서 가장 먼저 정합성을 확보해야 하는 핵심 영역입니다. ECC에서 Vendor/Customer를 각각 운영하던 환경을 S/4HANA로 전환할 때, 가장 대표적으로 나오는 혼란은 바로 이런 형태죠. “거래처는 있는데 BP가 없다”, “BP는 생성됐는데 Vendor가 연결 안 됨”. 실제 프로젝트에서도 이 문제는 매우 자주 발생합니다.
특히 다음과 같은 이슈가 반복적으로 나타나는데요. MDS_LOAD_COCKPIT 실행 시 대량 오류가 발생하거나, Vendor Customer BP 매핑 불일치로 특정 거래처만 변환이 안 되거나, 번호 범위(Number Range) 충돌로 생성 자체가 막히는 경우입니다. 필드 매핑 누락으로 인한 변환 실패나, 일부 Account Group만 BP 생성이 안 되는 불균형 현상도 빈번합니다.
이 글은 특히 아래와 같은 분들께 도움이 됩니다. FI 운영 중 S/4 전환을 준비하는 담당자, CVI 설정 SPRO 경로가 헷갈리는 주니어 컨설턴트, BP 전환 오류 방지 기준을 체계적으로 정리하고 싶은 시니어 컨설턴트라면 이 글을 끝까지 읽어보시길 권합니다.
CVI와 BP 구조 이해: 왜 이 설정이 중요한가
CVI(Customer Vendor Integration)란?
CVI는 단순히 Customer나 Vendor를 Business Partner로 “변환”하는 기능이 아닙니다. 정확히는 기존 Customer/Vendor 마스터와 BP(Business Partner) 마스터를 연결·동기화하는 데이터 모델 통합 레이어입니다. S/4HANA에서는 BP가 중심(master)이며, Vendor와 Customer는 BP에 부여되는 Role 기반 구조로 관리됩니다.
예를 들면 FLVN00 / FLVN01은 Supplier(Vendor) 역할이고, FLCU00 / FLCU01은 Customer 역할입니다. 즉, S/4HANA에서는 “거래처”의 실체가 BP이고, Vendor/Customer는 그 BP가 어떤 업무 역할을 수행하느냐에 따라 부여되는 확장 정보라고 보시면 됩니다.
S/4HANA에서 BP가 중심인 이유
ECC에서는 Customer와 Vendor가 별도 객체였기 때문에 동일 거래처가 Customer와 Vendor로 중복 관리되고, 주소·은행·세금 정보가 이원화되는 문제가 있었습니다. FI / MM / SD에서 동일 거래처를 각기 다르게 보게 되는 거죠. S/4HANA는 이를 해결하기 위해 BP 중심의 단일 마스터 구조를 채택했습니다.
즉, CVI가 생긴 이유는 이중 데이터 구조 제거, FI + MM + SD 통합 마스터 관리, 단일 거래처 기준 정보 유지, 전사적 데이터 거버넌스 강화입니다. 단순 기술 변화가 아니라 데이터 관리 철학 자체가 바뀐 겁니다.
Vendor Customer BP 매핑의 의미
CVI에서 가장 중요한 개념 중 하나는 Vendor/Customer와 BP 간의 1:1 매핑 구조입니다. 핵심은 Vendor Account Group ↔ BP Grouping, Customer Account Group ↔ BP Grouping 연결입니다. 이 연결이 흔들리면 BP 생성은 되었는데 Vendor가 안 생기거나, Vendor는 있는데 BP 연결이 없거나, 특정 그룹만 변환 실패하는 문제가 발생합니다.
실무적으로는 Account Group과 BP Grouping은 가급적 단순하고 명확하게, 1:1 구조 유지가 가장 안정적입니다. 예외 매핑이 많아질수록 MDS 변환 오류가 증가한다는 점을 기억하세요.
MDS_LOAD_COCKPIT의 역할
MDS_LOAD_COCKPIT은 기존 Customer/Vendor 데이터를 BP로 이관 + 동기화하는 대표 도구입니다. 기존 Customer/Vendor를 읽어서 CVI 설정에 따라 BP를 생성하고, 기존 객체와 BP 간 링크를 생성하며, 오류 로그를 기록하고 재처리 대상을 분리합니다. 즉, MDS_LOAD_COCKPIT은 단순 실행 툴이 아니라, 현재 CVI 설정이 실제 데이터에서 유효한지 검증하는 테스트 도구이기도 합니다.
IMG 설정 경로 및 단계: CVI 설정 SPRO 실무 순서
실무 기준으로는 아래 순서로 접근하는 것이 가장 안정적입니다.
- BP 기본 설정
- CVI 매핑 설정
- Number Range 정합성 검토
- Field Mapping 설정
- Synchronization 설정
이 순서를 거꾸로 하면, 나중에 번호 체계나 그룹핑 설계를 다시 뒤집어야 하는 경우가 많습니다.
BP 기본 설정
SPRO > Cross-Application Components > SAP Business Partner > Business Partner > Basic Settings
여기서는 BP 자체의 기본 골격을 잡습니다. 주요 설정 포인트는 BP Role 정의(예: FLVN00, FLVN01, FLCU00, FLCU01), BP Grouping 설정(Number Range 포함), Field Status Control(필수/선택/표시 전용 제어)입니다.
Role은 단순히 보여주기용이 아니라, 어떤 애플리케이션 뷰를 활성화할지 결정합니다. BP Grouping은 이후 Vendor/Customer Account Group과 매핑되므로 처음부터 체계적으로 설계해야 하며, 필드 상태는 CVI 변환 시 누락 오류와 직접 연결됩니다.
CVI 설정 SPRO 핵심 경로
SPRO > Cross-Application Components > Master Data Synchronization > Customer/Vendor Integration
이 영역이 실제 CVI 설정의 중심입니다. 여기서 설정하는 내용들이 Vendor Customer BP 매핑의 모든 기준이 됩니다.
Vendor ↔ BP 매핑
주요 설정은 Define Number Assignment for Direction BP to Vendor, Define Number Assignment for Direction Vendor to BP입니다. 여기서 결정해야 하는 핵심은 Internal Numbering vs External Numbering, BP와 Vendor가 동일 번호를 쓸지 여부, 어느 방향 동기화를 우선할지입니다.
프로젝트 초기에 반드시 결정해야 합니다. BP와 Vendor 번호를 동일하게 가져갈 것인지, 별도 번호 체계를 둘 것인지는 중간에 바꾸기 매우 어렵습니다. 특히 이미 테스트 데이터가 생성된 이후에는 영향 범위가 커집니다.
Customer ↔ BP 매핑
주요 설정은 Define Number Assignment for Direction BP to Customer, Customer Account Group ↔ BP Grouping 연결입니다. Customer도 Vendor와 동일한 논리로 접근합니다. Customer Account Group과 BP Grouping의 연결이 불명확하면 특정 고객군만 BP 생성에 실패하는 문제가 발생합니다.
Vendor Customer BP 매핑 — 가장 중요한 설정
Assign Vendor Account Groups to BP Groupings, Assign Customer Account Groups to BP Groupings 설정이 여기에 해당됩니다. 핵심 원칙은 반드시 1:1 또는 명확한 매핑 구조 유지, 하나의 BP Grouping에 여러 Account Group을 무리하게 몰아넣지 않기, 예외 케이스는 사전에 문서화입니다.
실무에서 자주 틀리는 부분은 ECC에서 Account Group 설계가 복잡한 상태를 그대로 가져오거나, BP Grouping을 너무 단순화해서 역으로 충돌이 발생하거나, 고객/공급업체가 동일 사업체인데 Account Group이 이원화되어 링크 실패하는 경우입니다.
Field Mapping — 가장 중요
Define Field Mapping and Conversion Rules 설정입니다. 여기서 Customer/Vendor 필드와 BP 필드를 연결합니다. 대표 예시는 LFA1, KNA1 ↔ BUT000, BUT020 등입니다. 필드 매핑이 왜 중요하냐면, 구조만 맞아도 실제 데이터가 들어갈 자리가 없으면 변환은 실패하기 때문입니다.
자주 문제 되는 항목은 이름/검색어 필드, 주소 필드, 국가/언어/지역코드, 은행정보, 세금번호, 사업자등록번호, 필수 분류 필드입니다. 필드 하나 누락되어도 대량 로드에서 수백 건이 동시에 실패할 수 있습니다. “테이블에 값은 있는데 BP 필드로 안 넘어간다”면 대부분 Field Mapping 또는 Conversion Rule 문제입니다. 표준 매핑으로 부족한 경우 BAdI 확장 검토가 필요합니다.
Synchronization Settings
Activate Synchronization Options, Automatic Synchronization On/Off, Direction 설정이 주요 설정입니다. 이 설정은 BP, Vendor, Customer 간 변경 시점에 동기화가 어떤 방식으로 일어날지 결정합니다.
초기 전환 단계에서는 자동 동기화 정책을 명확히 해야 합니다. 운영 전환 후에는 어느 객체를 기준 데이터로 볼지 합의가 중요하며, 자동 동기화 활성화 전 테스트 클라이언트에서 예외 케이스 검증이 선행되어야 합니다.
MDS_LOAD_COCKPIT 실행 방법과 확인 포인트
T-code: MDS_LOAD_COCKPIT
주요 실행 절차는 객체 선택(Customer / Vendor), 대상 범위 지정, 병렬 처리 설정, 실행, Error Log 확인, 수정 후 재실행입니다. 대량 데이터 이관 시 병렬 처리는 성능에 큰 영향을 주지만, 병렬 처리 수를 무리하게 높이면 로그 분석이 어려워지고 DB/애플리케이션 부하가 증가할 수 있습니다.
권장 방식은 먼저 소량 샘플로 테스트하고, 이후 Account Group 단위 또는 번호 구간 단위 분할, 마지막에 전체 병렬 처리입니다. MDS_LOAD_COCKPIT 실행 후에는 반드시 어떤 객체가 실패했는지, 동일 오류가 반복되는지, 특정 Account Group에만 집중되는지, 번호 범위 문제인지 필드 문제인지 확인해야 합니다. 실무에서는 “전체 오류 건수”보다 오류 패턴 분류가 더 중요합니다.
주요 포인트 / 실무 팁
번호 범위 전략이 가장 중요
BP와 Vendor/Customer가 동일 번호를 사용할지는 초기에 반드시 결정해야 합니다. 이유는 이후 매핑 구조 전체에 영향을 미치고, 변환 로직과 운영 정책에 영향을 주며, 프로젝트 중간 변경이 사실상 매우 어렵기 때문입니다. 가능하면 초기 아키텍처 단계에서 확정하고, 설계 문서에 Number Range 정책을 명시하며, 테스트 클라이언트에서 시뮬레이션 수행하는 것이 권장됩니다.
Vendor Customer BP 매핑은 단순하게
Account Group을 기준으로 최대한 단순하게 설계하는 것이 좋습니다. 복잡한 매핑일수록 예외가 증가하고, 예외가 많을수록 MDS_LOAD_COCKPIT 오류율이 증가하며, 운영 중 신규 거래처 생성 시 사용자 혼란이 확대됩니다.
BP Role 설계는 통합 관점으로
BP Role은 단순 마스터 코드가 아니라, 실제 업무 프로세스와 연결됩니다. FI / MM / SD 역할을 분리할지, 하나의 BP에서 통합 관리할지 검토해야 합니다. 대부분 프로젝트에서는 통합 Role 설계가 운영 효율 측면에서 유리합니다. 다만 권한, 책임 분리, 조직별 프로세스 차이가 큰 경우는 예외 설계가 필요합니다.
MDS_LOAD_COCKPIT 실행 전 체크리스트
실행 전에 최소한 필수 필드 누락 여부, 주소 데이터 정합성, 국가/우편번호 포맷, 중복 거래처 존재 여부, 사업자번호 중복 여부, One-time vendor/customer 처리 방식, 삭제 플래그 또는 Block 상태 데이터 포함 여부를 점검해야 합니다.
프로젝트에서 반드시 확인할 사항
기존 데이터 클렌징이 완료되었는가, 동일 사업자번호가 여러 Vendor/Customer에 중복되는가, 거래 중단 거래처를 이관 대상에 포함할 것인가, One-time 계정을 BP로 어떻게 가져갈 것인가, 공급업체이자 고객인 거래처를 하나의 BP로 통합할 것인가를 사전에 합의해야 합니다. 이 부분을 사전에 합의하지 않으면, 기술 설정이 맞아도 운영상 혼선이 남습니다.
SAP Error Code 해결 가이드: BP 전환 오류 방지 중심
| Error Message | 원인 | 해결 방법 |
|---|---|---|
| R1231 (BP does not exist) | 매핑은 설정되어 있으나 실제 BP 생성 실패 / BP Grouping 또는 Number Range 문제 / 선행 마스터 생성 누락 | BP Grouping 설정 확인 / Number Range 정합성 확인 / MDS_LOAD_COCKPIT 재실행 / 특정 그룹에만 발생하는지 확인 |
| CVI_MAPPING 003 | Vendor/Customer Account Group과 BP Grouping이 연결되지 않음 / 매핑은 일부만 되어 있고 예외 그룹 누락 | SPRO에서 Assign Vendor Account Groups to BP Groupings / Assign Customer Account Groups to BP Groupings 재확인 / 누락 Group 존재 여부 점검 / 1:1 매핑 원칙으로 재정리 |
| MDS_LOAD_COCKPIT 실행 시 General Error | 필드 매핑 누락 / 필수 필드 값 없음 / 변환 규칙 미설정 / 데이터 자체 오류 | Field Mapping 설정 재확인 / 필수값 존재 여부 점검 / BD001 / BD002 테이블 로그 확인 / 동일 오류가 특정 필드에 집중되는지 분석 |
| Number assignment inconsistent | BP와 Vendor 번호 범위 불일치 / Internal / External 설정 불통일 / 동일 번호 정책과 실제 범위 설계 충돌 | Internal/External 설정 통일 / BP Grouping Number Range 재점검 / Vendor/Customer Number Assignment 방향별 설정 확인 / 이미 생성된 테스트 데이터 영향 여부 검토 |
마무리: CVI 설정은 IMG가 아니라 데이터 구조 설계다
핵심만 다시 정리하면 다음과 같습니다. CVI 설정은 단순 IMG 작업이 아니라 데이터 구조 설계이며, Vendor Customer BP 매핑, Number Range, Field Mapping 이 세 가지가 가장 중요한 축입니다. 그리고 MDS_LOAD_COCKPIT은 단순 이관 도구가 아니라 설정 검증 단계라고 보는 것이 맞습니다. 여기서 오류가 많이 난다면 프로그램 문제가 아니라, 대부분 매핑·번호 체계·필드 정합성 중 하나가 설계 단계에서 흔들리고 있다는 신호입니다.
지금 바로 아래를 점검해보세요. 현재 시스템의 CVI 설정 상태를 점검하고, 테스트 클라이언트에서 사전 검증을 진행하며, Account Group ↔ BP Grouping ↔ Number Range 연결 구조를 문서화하세요. 이 세 가지만 명확히 정리해도 실제 전환 단계에서 발생하는 오류의 70% 이상을 사전에 방지할 수 있습니다. 비슷한 이슈를 겪으셨다면 댓글로 공유해주세요. 함께 고민하면 더 나은 해결책이 나올 수 있습니다.
다음에는 BP Number Range 설계 전략 (실패 사례 중심), MDS_LOAD_COCKPIT 성능 최적화 및 병렬 처리 방법, CVI Field Mapping 심화 (BAdI 활용 포함) 글로 이어가겠습니다.
참고 출처
– SAP Help Portal: Customer/Vendor Integration (CVI)
– SAP Note 2265093: Business Partner Integration – FAQ
– SAP S/4HANA Conversion Guide