CRM·ERP 고객 코드 연동: 법인·사업장·청구처 매핑 검수 기준

CRM·ERP 고객 코드 연동은 고객명을 복사하는 일이 아니라 법인·사업장·청구처·납품처와 영업 관계가 어느 코드에 해당하는지 정하는 작업입니다. 서로 다른 시스템과 회사에서 같은 숫자 코드를 사용할 수 있으므로 원천 시스템·회사 범위·코드의 조합을 보존하고, 새 거래처 생성과 기존 거래처 연결을 구분해야 합니다.

고객 이름이 같아도 영업팀이 관리하는 조직과 회계·물류에서 사용하는 거래처는 단위가 다를 수 있습니다. CRM에는 최종 고객 하나가 있고 ERP에는 공장별 납품처와 청구처가 나뉘는 경우를 먼저 확인하세요. 한 행씩 이름을 맞추는 방식만으로는 주문과 채권의 상대를 정확히 연결하기 어렵습니다.

이 글은 CRM과 ERP를 유지하면서 거래처 코드를 연결하려는 발주자를 위한 설계 가이드입니다. 고객 코드, 금액과 상태는 검수용 가상 예시이며 특정 제품의 기본 기능이나 자사 고객 실적을 뜻하지 않습니다. 법인 식별과 세금계산서 발행 대상의 확정은 관련 업무 담당자와 별도로 검토해야 합니다.

연동의 완료 조건은 두 화면에 같은 고객명이 보이는 것이 아닙니다. 신규 고객 승인, 주소 변경, 합병·분리, 거래 중지와 잘못 연결한 코드의 복구 뒤에도 견적·주문·납품·청구의 연결 근거가 설명돼야 합니다. 먼저 자동 연결의 한계와 승인 주체를 정하고 개발 범위를 비교하세요.

제품의 식별 키 기능과 회사의 고객 판정 정책은 다릅니다#

Microsoft Dataverse 공식 문서는 외부 시스템이 내부 GUID를 보관하지 않을 때 하나 이상의 열 조합으로 행을 식별하는 대체 키를 설명합니다. 이는 시스템 사이에서 이름 외의 안정적인 식별 기준이 필요함을 보여주는 제품 사례입니다. 어떤 고객을 같은 법인으로 볼지, 코드 병합을 승인할지는 회사 정책이며 대체 키 기능만으로 결정되지 않습니다.

• Microsoft Dataverse 대체 키 정의: 외부 데이터 연동에서 단일 값 또는 고유 조합으로 기록을 식별하는 기능과 제약을 확인할 수 있습니다.

코드 대조표를 운영 가능한 승인 원장으로 바꾸세요#

사전 진단에서는 각 시스템의 고객 목록을 승인된 범위로 추출하고 원본 코드를 먼저 보존합니다. 정상 연결, 여러 후보, 연결 없음, 거래 중지와 코드 재사용 의심을 나눠 집계하세요. 연결률 하나로 압축하면 검토가 필요한 고위험 관계가 보이지 않을 수 있습니다. 실제 고객 자료는 공유 전 범위와 보호 방법을 정합니다.

코드를 문자열로 보존할지와 정규화 방법도 명시해야 합니다. 앞의0을 지우거나 하이픈을 제거한 값이 서로 다른 원본 코드와 충돌할 수 있습니다. 화면 검색을 위한 정규화 값과 원천 식별자를 구분하고, 허용하지 않는 문자나 누락된 회사 범위가 들어오면 임의 보정 대신 검토 오류로 표시하도록 요구하세요.

고객과 거래처의 거래 중지 상태도 한 가지 뜻이 아닐 수 있습니다. 신규 주문 제한, 납품 보류와 기존 청구 조회 허용을 같은 상태로 묶지 말고 항목별 동작을 정하세요. CRM에서 영업 기회를 열 수 있다는 사실이 ERP에서 거래를 확정해도 된다는 신호로 해석되지 않도록 경계 화면을 검수합니다.

일별 대사에는 새로 생성한 코드뿐 아니라 연결이 바뀐 코드와 종료한 관계를 포함합니다. 미연결 건, 여러 후보와 승인 대기를 담당자가 처리할 목록으로 나누고, 자동으로 처리한 건도 규칙 버전과 근거를 확인할 수 있게 하세요. 개별 오류를 수동으로 고친 뒤 같은 원본이 재도착했을 때 보정이 유지되는지도 확인해야 합니다.

대조표에는 원천 시스템·회사·원본 코드, 연결된 CRM 고객, 관계 종류, 유효 시작·종료, 승인자와 승인 근거를 둡니다. 관계 종류를 적어야 같은 법인, 청구처와 납품처 연결을 구분할 수 있습니다. 운영자가 엑셀 매핑을 조용히 바꾸는 방식 대신 검토·승인·반영 상태를 남기는 구조를 요구하세요.

신규 고객을 CRM에서 만들면 ERP 거래처가 즉시 생성되는지, 거래처 승인 신청만 만들어지는지 구분해야 합니다. 필수 자료가 없거나 재무 검토가 필요하면 연동 대기로 남기고 담당자가 보완할 수 있게 합니다. 승인 전 임시 코드로 주문을 받을 수 있는지는 회사가 별도 정책으로 확정해야 합니다.

반영 실패는 고객 자체의 오류와 통신 오류를 나눠 처리합니다. 같은 승인 건을 재전송했을 때 거래처가 두 개 생기지 않아야 하고, 외부 생성은 성공했는데 응답만 유실된 경우도 찾아야 합니다. 원본 요청 ID와 외부 코드, 처리 결과를 연결하고 오류를 고친 뒤 어느 단계부터 다시 실행하는지 문서화하세요.

원천 시스템의 책임과 예외는 API 연동 개발 가이드에서 확인하세요. 여러 판매 조직이 같은 고객을 다룬다면 대리점 CRM 권한 설계도 함께 검토하세요. 초기 고객 자료 이전은 ERP 데이터 이관 대사와 연결해 준비할 수 있습니다.

이름이 같은 고객보다 관계가 다른 고객으로 검수하세요#

동일 상호의 다른 법인, 한 법인의 두 사업장, 납품처와 청구처가 다른 주문을 표본으로 준비합니다. 고객 총건수만 비교하지 말고 어떤 CRM 고객과 ERP 회사·코드가 연결되는지 확인하세요. 다른 관계의 거래가 섞여 고객별 견적과 청구 정보가 잘못 노출되지 않는지도 확인해야 합니다.

코드 재사용도 별도 표본으로 넣어 보세요. 종료된 거래처의 코드를 새 회사에 다시 부여할 수 있는 환경이라면 원본 코드 하나만으로 과거 관계를 되살리지 않아야 합니다. 종료 시점과 새 관계의 시작을 구분하고 늦게 도착한 과거 주문이 현재의 다른 고객에 붙지 않는지 확인합니다.

승인한 고객 관계가 없을 때 어떤 거래를 보류할지도 명시하세요. 담당자가 임시로 이름을 입력해 후속 거래를 계속 진행할 수 있다면 누락 매핑이 숨어 버릴 수 있습니다. 허용된 임시 처리와 정식 승인 조건, 임시 관계가 남아 있는 거래를 찾는 목록을 함께 인수하는 것이 좋습니다.

기존 고객을 합치거나 나누는 시험에서는 과거 거래를 보존하는지 봅니다. 잘못 연결한 관계를 해제했을 때 원주문과 당시의 상대가 남아야 하며, 새 매핑이 과거 청구 대상을 자동으로 바꾸지 않아야 합니다. 정정이 필요하다면 승인된 별도 작업과 영향 목록을 요구하세요.

주소 변경, 거래 중지와 코드 변경을 양쪽 시스템에서 발생시켜 결과를 대조합니다. 기준 시스템의 승인과 상대편 반영 사이에 지연이 생기면 사용자에게 어떤 상태를 안내하는지 봅니다. 운영 화면이 최신인 척 보여주지 않고 마지막 반영 시각과 미처리 사유를 설명할 수 있어야 합니다.

인수 때는 회사가 매핑 규칙과 승인 원장을 확인하고 새 담당자가 누락·충돌 건을 처리해 보게 합니다. 샘플 대조표, 오류 유형, 재처리 절차와 연결 해제 시험을 남기세요. 개발사가 임의 SQL로 코드를 교정해야만 운영할 수 있다면 변경 승인과 재현 가능한 도구의 범위를 다시 협의하는 것이 좋습니다.