브라운필드 S/4HANA 전환에서 가장 자주 터지고, 가장 오래 붙잡고 있는 작업이 바로 BP·CVI다. 컨설턴트도 개발자도 여기서 밤을 새운다. 이유는 단순하다. S/4HANA는 고객(`KNA1`)이나 공급업체(`LFA1`)를 따로 만들 수 없고, **비즈니스 파트너(Business Partner, BP)가 유일한 진입점**이기 때문이다. 그래서 전환 전에 기존 고객·공급업체를 전부 BP로 동기화(CVI)해 둬야 한다. 이 사전작업이 끝나지 않으면 기술 전환(SUM) 자체가 막힌다. 이 글은 왜 필요한지, 어떤 순서로 하는지, 그리고 **어디서 자주 터지는지**를 정리한다. ## 왜 BP로 합쳐야 하나 ECC에서는 고객 마스터(`KNA1`)와 공급업체 마스터(`LFA1`)가 서로 독립적인 객체였다. S/4HANA는 이 둘을 **하나의 BP 아래**로 통합한다. 고객도 BP, 공급업체도 BP, 같은 법인이면 BP 하나에 두 역할이 붙는다. **CVI(Customer-Vendor Integration)**는 이 BP와 옛 고객/공급업체 마스터를 잇는 양방향 동기화 다리다. ECC에서는 고객/공급업체가 주(leading)이고 BP가 따라오지만, S/4HANA로 넘어가면 **BP가 주가 되고 고객/공급업체가 따라온다.** 전환은 이 방향을 뒤집는 작업이기도 하다. ## 전환 전에 '반드시' 끝내야 한다 핵심을 한 번 더. **모든 고객·공급업체가 BP로 동기화돼 있어야 기술 전환을 시작할 수 있다.** 이건 선택이 아니라 필수 선결 과제다. Simplification Item Check와 사전 점검이 미동기화 데이터를 잡아내고, 남아 있으면 전환을 막는다. 전환 안 할 고객/공급업체(쓰지 않는 옛 데이터)는 그냥 두면 안 되고, **삭제 표시(deletion flag) 후 아카이빙**하거나 정리해야 한다. "안 쓰니까 놔두자"가 가장 흔한 지연 원인이다. ## 셋업 순서 (ECC 쪽에서) 대략 이 순서로 간다. 1. **비즈니스 펑션 활성화** — `CA_BP_SOA`를 켠 뒤 `CVI_FS_CHECK_CUSTOMIZING` 리포트를 돌리면 해야 할 커스터마이징 항목 목록이 나온다. 여기서부터 출발하면 빠지는 게 없다. 2. **번호범위·grouping·account group 매핑** — 아래 4번에서 따로 다룬다. CVI 에러의 절반이 여기서 난다. 3. **BP 역할(role) 정의** — 고객은 `FLCU00`(FI 고객)·`FLCU01`(고객/SD), 공급업체는 `FLVN00`(FI 공급업체)·`FLVN01`(공급업체/MM) 역할 카테고리를 매핑한다. 4. **데이터 정합성 사전 점검** — 동기화 전에 마스터 데이터 품질을 검사한다(정합성 체크 리포트 `CVI_PRECHK`). 주소·세금번호·은행정보 같은 필수 필드가 비어 있으면 여기서 걸러진다. 5. **대량 동기화** — `MDS_LOAD_COCKPIT`(동기화 코크핏)에서 "고객 → BP", "공급업체 → BP"를 대량 실행한다. 전체 진행 상황은 `CVI_COCKPIT`에서 본다. ## 번호범위 — 가장 흔한 함정 CVI 에러의 단골이 번호범위 설정인데, 여기서 방향을 헷갈리는 경우가 많다. 보통은 BP 번호를 기존 고객/공급업체 번호와 **똑같이** 가져간다(1:1). 그런데 고객·공급업체는 이미 번호가 매겨져 있으니, **BP가 그 번호를 넘겨받아야** 한다. 그래서 동기화 중에는 BP 쪽을 외부 채번으로 열어둬야 한다. | 시점 | BP 번호범위 (`BUCF`) | 의미 | |---|---|---| | ECC 동기화 중 | **External** | 기존 고객/공급업체 번호를 BP가 그대로 넘겨받음 | | 동기화 완료 후 (S/4HANA 전) | **Internal 로 되돌림** | 이후 새로 만드는 BP는 자동 채번 | 여기에 더해 BP Grouping ↔ Account Group 매핑에서 **"Same number"**를 체크해야 BP 번호 = 고객/공급업체 번호가 된다. 흔한 실수가 BP를 처음부터 Internal로 둔 채 "Same number"를 켜는 것이다. 동기화 단계에선 BP가 외부(기존 번호)를 받아야 하니 **External이 맞고**, 동기화가 끝난 뒤 Internal로 되돌린다. 이 방향이 어긋나면 그 유명한 `The number ranges for account group & grouping are different` 에러가 뜬다. ## 자주 터지는 에러 3가지 | 증상 | 원인 | 대응 | |---|---|---| | `number ranges for account group & grouping are different` | 동기화 중 BP 번호범위 방향이 잘못됨 | BP=External + "Same number" 체크 → 동기화 후 Internal 복귀 | | BP 저장·역할 확장 시 CVI link 에러 | `BUT000`의 `PARTNER_GUID`가 `CVI_CUST_LINK`/`CVI_VEND_LINK`와 안 맞음 (옛 매핑 꼬임) | 링크 테이블 정합성 점검 후 재동기화 | | 동기화 실패 / 일부 레코드 누락 | 필수 마스터 데이터(주소·세금·은행) 품질 문제 | 동기화 전에 `CVI_PRECHK`로 클렌징 먼저 | 같은 법인인데 고객·공급업체로 따로 존재하는 경우(예: 거래처가 매입·매출 둘 다)는 하나의 BP로 병합해야 하는데, 이때 `CVI_LEDH`(Legal Entity Data Harmonization) 같은 도구로 정리한다. 자동으로 알아서 합쳐지지 않으니 사전에 매칭 기준을 정해둬야 한다. ## MDS_LOAD_COCKPIT — 동기화는 어떻게 도나 대량 동기화는 버튼 한 번이 아니라 단계가 있다. `MDS_LOAD_COCKPIT`에서 보통 이렇게 돈다. 1. **동기화 프로세스 선택** — "고객 → BP", "공급업체 → BP"처럼 방향을 고른다. 2. **컨트롤 파라미터 설정** — 블록 크기(block size)로 병렬 처리 단위를 정한다. 데이터가 많으면 이 병렬도가 성능을 좌우한다. 3. **선택 조건 입력** — 어떤 고객/공급업체 범위를 돌릴지 지정한다(계정그룹·번호 범위 등). 4. **실행 → 로그 확인** — 성공/실패 건을 로그로 본다. 실패는 대개 마스터 데이터 품질 문제라, `CVI_PRECHK`로 돌아가 고친 뒤 재실행한다. 수십만 건이면 한 번에 다 돌리지 말고, 작은 범위로 시범 운전해 에러 패턴을 먼저 파악한 다음 전체로 확장하는 게 안전하다. ## 고객·공급업체만이 아니다 — 직원·연락처 CVI라고 하면 고객·공급업체만 떠올리기 쉽지만, BP로 합쳐야 하는 대상은 더 있다. **연락처(contact person)**, 그리고 HR을 함께 쓰는 시스템이라면 **직원(employee)**도 BP로 동기화해야 한다. 특히 직원→BP 동기화는 별도 절차가 있어, HR/HCM이 얽힌 전환에서 이걸 빠뜨리면 막판에 발목을 잡힌다. 동기화 대상 범위를 처음 잡을 때 고객·공급업체뿐 아니라 연락처·직원까지 포함해 정의해 두자. ## 전환 전 체크리스트 - [ ] `CA_BP_SOA` 활성화 + `CVI_FS_CHECK_CUSTOMIZING` 항목 전부 처리 - [ ] 번호범위(External/Internal) + grouping↔account group 매핑 정렬 - [ ] BP 역할 `FLCU00/01`, `FLVN00/01` 매핑 완료 - [ ] `CVI_PRECHK`로 데이터 정합성 클렌징 (주소·세금·은행) - [ ] 안 쓰는 고객/공급업체는 삭제표시 후 아카이빙 - [ ] `MDS_LOAD_COCKPIT` 대량 동기화 → `CVI_COCKPIT`에서 0 오류 확인 이 여섯 줄이 깨끗하게 통과되면, BP·CVI 때문에 전환이 막히는 사태는 거의 피한다. 반대로 이걸 미뤄두면 전환 막판에 가장 비싼 시간에 터진다. CVI는 "전환 직전에 후딱" 할 작업이 아니라, **전환 프로젝트 초반에 먼저 깔아두는** 작업이다. ## 전환 후 — 방향이 뒤집힌다 여기까지가 ECC에서의 사전 작업이다. 전환이 끝나 S/4HANA로 올라오면 **주도권이 바뀐다.** 이제부터는 **BP가 주(leading)**가 되고, 고객·공급업체는 BP에서 파생된다 — 새 거래처를 만들 때 고객 마스터가 아니라 `BP` 트랜잭션부터 시작한다. 번호범위도 앞서 본 대로 동기화가 끝나면 BP를 다시 Internal로 되돌려, 이후 새 BP가 자동 채번되게 한다. 즉 CVI는 "한 번 동기화하고 끝"이 아니라, **데이터의 주인을 고객/공급업체에서 BP로 넘기는 전환**이다. 이 방향 전환을 이해하고 있어야 전환 후 마스터 데이터 운영이 헷갈리지 않는다. ## 자주 묻는 질문 **CVI는 전환 직전에 하면 안 되나요?** 권장되지 않습니다. 데이터 정합성 정리와 대량 동기화에 시간이 걸리고, 막히면 전환 일정 전체가 밀립니다. 프로젝트 초반에 깔아두는 작업입니다. **고객·공급업체 외에 또 동기화할 게 있나요?** 연락처(contact person)와, HR을 함께 쓰면 직원(employee)도 BP로 동기화해야 합니다. **번호를 굳이 같게(Same number) 맞춰야 하나요?** 필수는 아니지만, 기존 고객/공급업체 번호를 BP에서도 그대로 쓰면 사용자·인터페이스 혼란이 적어 대부분 same number로 갑니다. 그래서 번호범위 방향(동기화 중 BP=External)이 중요합니다. 전환을 어떤 방식으로 갈지는 [브라운필드 vs 그린필드 vs 블루필드](/education/s4hana-transition-brownfield-greenfield-bluefield)에서, 커스텀 코드 정리는 [커스텀 코드 적응](/education/custom-code-adaptation-s4hana)에서 다룬다. ECC 지원종료 일정 자체는 [SAP ECC 지원종료 2027/2030 정리](/education/sap-ecc-eos-2027-2030)를 참고. ## 출처 - SAP 공식 — *FAQ: CVI for system conversion to SAP S/4HANA*: [community.sap.com](htt