다법인 ERP 구축: 회사별 거래·공통 기준정보·권한 분리 기준

다법인 ERP 구축은 회사 선택 메뉴를 추가하는 일이 아니라, 함께 써도 되는 기준정보와 법인별로 분리해야 하는 거래·권한을 정의하는 일입니다. 공통 품목을 사용하더라도 매입단가와 재고·주문·승인 책임은 다를 수 있습니다. 한 법인의 거래가 다른 법인으로 전달될 때도 서로의 거래 ID와 처리 상태를 연결해야 중복 반영이나 한쪽만 완료된 상황을 설명할 수 있습니다.

여러 법인을 운영하는 회사가 ERP를 통합할 때는 한 화면에서 보고 싶다는 요구와 각 회사의 데이터를 분리해야 한다는 요구가 동시에 나옵니다. 화면의 회사 필터만으로 이를 해결하려 하면 상세 URL, 파일 다운로드나 자동 보고서에서 다른 회사 데이터가 섞일 수 있습니다. 공통 데이터베이스를 쓰는지 여부보다 어떤 경계가 조회·입력·승인·내보내기 전 과정에 적용되는지가 중요합니다.

먼저 법인, 사업장, 창고와 부서의 차이를 조직도와 거래 흐름으로 확인하세요. 창고가 다르다는 이유만으로 법인을 나눠야 하는 것도 아니고, 같은 브랜드를 쓴다는 이유로 별도 법인의 매입·매출·원장을 하나로 합쳐도 되는 것도 아닙니다. 이 글은 법인의 법적 지위나 연결회계·세무 처리를 판단하지 않으며, 담당자가 확정한 조직 경계를 시스템 데이터와 권한에 반영하는 방법을 다룹니다.

가상 예시는 공통 품목 P를 쓰는 A·B 두 법인입니다. A가 보유한 100개 중 20개를 B로 보내는 과정을 사용하지만, 단순 창고 이동인지 법인 간 매매인지 이 글이 결정하지 않습니다. 회사 담당자가 상호 거래라고 확정한 경우를 별도 표본으로 만들어 A의 출고와 B의 입고·구매가 연결되는지를 검수합니다. 숫자는 실제 거래 실적이나 적정 가격을 뜻하지 않습니다.

공식 회사 간 데이터 공유는 공유 대상과 정책을 따로 정합니다#

Microsoft Dynamics 365 공식 문서는 회사 간 기준정보 공유에서 공유할 테이블·필드·회사를 정책으로 지정하며, 역할과 보안 구성으로 유지관리 권한을 제한할 수 있다고 설명합니다. 회사 간 거래를 모두 하나의 공유 마스터처럼 다룬다는 뜻은 아닙니다. 이 글은 해당 제품의 범위에서 공유 정책 개념을 참고했고, 구체적인 법인별 거래·권한 표는 발주 검수를 위한 별도 설계 예시입니다.

• Microsoft Learn: Cross-company data sharing overview: 공유 방식, 대상 테이블·필드·회사와 권한의 공식 설명입니다. 확인일은 2026년 10월 22일입니다.
• Microsoft Learn: Cross-company data sharing: 기준정보 공유와 거래 데이터 공유의 제한을 구분하는 자료입니다. 모든 ERP의 동일 기능이나 회계 요건을 의미하지 않습니다.

운영 인수는 공통 변경·법인 추가·실패 복구를 포함합니다#

공통 품목 수정은 모든 회사의 업무에 영향을 줄 수 있습니다. 품목명처럼 표시만 바뀌는 값과 기본 단위처럼 거래 계산에 영향을 주는 값을 구분하고, 기존 주문이 새 단위로 재계산되지 않는지 확인해야 합니다. 변경 요청에는 참여 법인, 영향 필드와 적용 시점을 적고 법인별 보완이 필요한 조건을 정하세요. 공통 관리자가 수정한 내용을 각 법인이 확인할 방법도 필요합니다.

신규 법인 추가 시 기존 법인의 데이터를 복제하면 운영이 빨라 보이지만 승인자, 단가, 문서 번호와 외부 연동 계정까지 복제될 위험이 있습니다. 공통 템플릿과 새 법인이 확정해야 할 설정을 나누고, 실거래가 시작되기 전에 회사별 코드·창고·계정·권한 점검표를 실행하세요. 비활성 법인에 데이터가 계속 들어오거나 종료한 계정으로 자동 보고가 발송되지 않는지도 확인합니다.

회사 간 연동에는 공통 거래 키와 양쪽 문서 ID, 송신 버전·처리 상태를 남깁니다. A의 출고가 완료된 뒤 B의 입고 생성이 실패했으면 어떤 원장을 이미 반영했는지 운영자가 알아야 합니다. 무조건 전체 취소하거나 재전송을 반복하면 중복 거래가 생길 수 있으므로 재시도 가능한 사건과 담당자 확인이 필요한 상태를 구분합니다. 이미 처리한 문서에는 같은 사건을 다시 적용하지 않도록 검수하세요.

그룹 합계는 조회 권한과 집계 정의를 모두 확정해야 합니다. 각 법인의 숫자를 더한 값이 내부 거래 제거가 반영된 연결 수치라고 자동 표시해서는 안 됩니다. 보고서에는 포함 법인, 기준일·통화와 미완료 연동을 명시하고, 상세로 내려갈 때도 사용자의 회사별 접근 범위를 지켜야 합니다. 연결회계와 세무 결과는 별도 전문 영역이며 이 글이 계산 규칙을 제시하지 않습니다.

권한 변경은 발급뿐 아니라 회수와 검토도 운영 업무입니다. A에서 B로 이동한 직원에게 이전 법인 접근이 남아 있는지, 공통 지원 계정이 승인자로 등록됐는지 주기적으로 확인하세요. 사용자가 여러 법인 탭을 동시에 열었을 때 A에서 작성하던 발주가 B로 저장되지 않는지도 중요합니다. 화면에 현재 법인을 분명히 표시하고 저장 요청에 명시한 법인이 권한과 일치하는지 서버에서 검증합니다.

기초 데이터 이관은 공통 식별자와 법인별 거래처 계정을 연결하는 작업부터 진행하세요. 이름이 같다는 이유만으로 서로 다른 공급자를 자동 병합하거나, 같은 거래처의 지점·청구처를 무조건 하나로 만들지 않습니다. 미확정 매핑은 승인 목록으로 분리하고 회사 담당자가 표본을 확인해야 합니다. 각 법인의 기초 잔량·미종결 주문은 기준 시점과 대사 책임자를 정해 독립적으로 인수합니다.

프로젝트 전체의 범위와 단계별 도입 판단은 커스텀 ERP 구축 가이드를 참고하세요. 공통 품목과 분리해 관리할 법인별 계약 가격의 이력은 매입단가 적용일·버전 관리에서 검수 표본을 확인할 수 있습니다.

다법인 검수는 두 회사의 기대 결과를 한 쌍으로 작성합니다#

첫 검수는 공통 품목 P와 법인별 서로 다른 단가를 등록하고 A와 B 사용자가 각각 주문을 만드는 표본입니다. 공통 규격은 같지만 법인별 가격·승인자·문서 번호가 섞이지 않는지 확인하세요. 공통 담당자가 품목 표시명을 바꿨을 때 지정한 범위에만 반영되고, 법인별 거래 당시 값은 합의한 방식으로 유지되는지 대조합니다. 공유가 편하다는 이유로 모든 필드를 일괄 공유하지 않습니다.

두 번째 검수는 A 100개에서 20개를 보내 B가 18개만 인수하는 상호 거래 표본입니다. 양쪽 문서의 상태와 차이 2개의 처리 책임을 함께 확인하고, B 입고 생성이 실패한 경우 A의 발송 이력을 잃지 않는지 보세요. 응답 유실 후 같은 연동을 재시도해도 B 입고가 두 번 생성되지 않고 원거래와 재처리 기록을 찾을 수 있어야 합니다.

세 번째는 A 전용 계정으로 B의 거래 ID, 파일 주소와 집계 API를 직접 요청하는 접근 거부 시험입니다. 허용된 테스트 환경에서 개인정보 없는 표본을 사용하고, 메뉴를 숨긴 것 외에 서버가 거부하는 증거를 남기세요. 여러 법인 사용자는 회사별로 다른 승인 한도를 적용받는지, 새로고침·다운로드·자동 이메일에서도 권한 범위가 유지되는지 확인합니다.

운영 전환 시험은 새로운 C 법인을 추가하는 절차를 담당자가 직접 실행하는 것입니다. 공통 마스터의 선택 범위, 법인별 필수 설정, 승인자·외부 계정과 빈 기초 거래를 확인하게 하세요. 실수로 A의 미종결 주문이나 가격을 복사하지 않는지 점검하고, 검수 실패 시 새 법인의 사용만 보류할 수 있는지도 확인합니다. 전체 시스템의 수동 수정 없이는 법인을 추가할 수 없다면 남은 운영 의존성을 기록합니다.

발주서에는 법인 수만 적지 말고 공통 테이블·법인별 속성·상호 거래 종류·권한 역할·보고 범위를 분리해 적으세요. 인수 자료에는 회사 경계의 데이터 사전, 권한표, 연동 실패 목록과 법인 추가·종료 절차를 포함합니다. 기존 패키지 설정으로 가능한 범위와 별도 연동·개발을 나누되, 연결회계·세무 등의 전문 설계가 포함되는지는 별도 계약 항목으로 확인해야 합니다.