위탁재고 ERP 개발: 소유권·보관 위치·판매 확정 분리 기준

위탁재고 ERP는 물건이 놓인 창고와 그 물건의 소유자, 거래처가 보고한 판매와 회사가 승인한 판매를 각각 기록해야 합니다. 외부 창고로 보냈다는 이유만으로 판매 처리하거나, 판매 보고가 들어왔다는 이유만으로 검수 없이 재고를 줄이면 잔량과 정산 근거가 어긋납니다. 위치 이동, 판매 확정, 반환과 정정의 독립된 이력을 같은 위탁 건으로 연결하는 것이 설계의 출발점입니다.

위탁 판매를 하는 회사는 본사 창고 수량뿐 아니라 거래처에 맡긴 물건도 알아야 합니다. 그러나 ERP에 거래처 창고만 추가하면 충분하다고 보기 어렵습니다. 같은 장소 안에 자사 소유 물건, 거래처가 이미 매입한 물건, 판매 후 반품된 물건이 함께 있을 수 있기 때문입니다. 품목과 위치만으로 묶은 재고표에는 지금 누구의 물건이며 어떤 약속 때문에 움직일 수 없는지가 보이지 않습니다.

발주 담당자는 먼저 위탁 계약별 업무 경계를 적어야 합니다. 출고 시점에 소유권을 넘기는지, 최종 판매나 사용 보고를 승인할 때 넘기는지, 분실과 불량은 누가 확인하는지 문서화하세요. 이 글은 특정 계약의 법적 소유권이나 매출 인식 시점을 판정하지 않습니다. 회사 담당자가 확정한 정책을 시스템의 상태와 검수 조건으로 옮기는 방법에 집중합니다.

아래 수량은 실제 고객 실적이 아닌 가상 검수 예시입니다. 본사에 있던 상품 100개를 거래처 A에 위탁하고, 보고된 판매 30개 중 28개만 승인하며, 미판매분 10개를 반환하는 상황을 사용합니다. 일반 재고관리 글처럼 안전재고와 발주 예측을 다루기보다, 장소가 바뀌어도 소유와 판매 확정이 임의로 바뀌지 않는지를 확인하려는 독자를 위한 내용입니다.

공식 제품 문서에서는 보관과 소유 변경을 구분합니다#

Microsoft Dynamics 365의 입고 위탁재고 문서는 공급자 소유 재고를 사업장에 보관하고, 별도의 소유 변경 분개로 귀속 이전을 기록하는 흐름을 설명합니다. 이 자료는 위치와 소유를 분리하는 제품 설계의 근거로만 참고했습니다. 이 글의 거래처 위탁 판매 사례와 동일한 계약 구조라고 보거나 국내 회계·세무 처리의 기준으로 해석해서는 안 됩니다.

• Microsoft Learn: Set up consignment: 공급자 소유 재고, 보관 수량과 소유 변경 기록을 분리한 공식 기능 설명입니다. 확인일은 2026년 10월 22일입니다.

거래처 대사는 기준 시점과 미도착 사건부터 맞춥니다#

일마감 대사표에는 기초 위탁 잔량, 인수 완료, 판매 보고, 판매 승인, 반환 입고와 승인 조정을 같은 계약·품목 단위로 표시하세요. 승인 기준 장부, 보고 기준 실물 예상과 실제 실사 수량은 서로 다른 숫자로 보여야 합니다. 차이가 나면 반환 물건이 운송 중인지, 보고가 미승인인지, 집계 시점이나 품목 매핑이 다른지 확인하고 분실로 단정하지 않습니다. 실물 예상 수량만으로 재배정을 허용하지 않는 운영 기준도 정하세요.

이동 중 재고를 두 사업장에 동시에 포함하지 않도록 출고와 인수의 책임 시점을 정합니다. 본사에서 10개 반환을 접수한 시점에는 거래처 출고 대기, 택배 인계 후에는 반환 이동 중, 본사 실물 검수 후에는 정상 또는 품질 보류로 기록하는 식입니다. 운송장만 생성됐거나 일부만 도착한 상황도 별도 상태로 남겨 실물 확인 없이 반환을 완료하지 않도록 검수하세요.

판매 보고 수신 담당자와 승인 담당자를 분리할지 정하고, 거래처 담당자는 자기 계약의 품목과 잔량만 보게 해야 합니다. 외부 사용자가 보고 파일의 계약 코드를 바꾸거나 다른 거래처의 보고 ID를 직접 요청했을 때도 서버에서 접근을 거부하는지 확인합니다. 다운로드 파일, 자동 발송 이메일과 대시보드 집계에도 같은 범위가 적용돼야 합니다.

장기간 미보고 거래처는 재고가 없는 곳이 아니라 보고가 오래된 곳일 수 있습니다. 마지막 실물 확인일과 마지막 승인 판매일을 함께 보여주고, 확인이 필요한 수량을 별도로 표시하세요. 자동으로 판매를 추정해 잔량을 줄이는 기능은 검증된 계약 정책 없이 켜지 않습니다. 거래처가 폐업하거나 계약이 끝났을 때 남은 물건을 회수하고 접근 계정을 종료하는 담당자도 지정합니다.

초기 이관 때는 거래처의 재고 엑셀을 그대로 현재고에 더하지 않습니다. 기준일 이전 판매와 본사 출고가 이미 포함됐는지 확인하고, 소유자·계약·품목·위치별 기초 잔량을 현업 승인 대상으로 만드세요. 식별할 수 없는 품목과 계약 미확정 물건은 별도 보류 목록에 두고, 임시 코드가 실제 재고로 섞인 채 운영이 시작되지 않게 합니다.

운영 인수에는 위탁 계약별 대사 주기, 보고 지연 연락 순서, 정정 승인권자와 오류 재처리 절차가 필요합니다. 운영자가 실패한 보고 한 건을 찾아 원본과 처리 행을 비교하고, 이미 반영한 행을 제외해 다시 실행하는 과정을 직접 수행하게 하세요. 개발자의 수동 데이터 수정으로만 처리되는 예외는 인수 완료로 보지 말고 남은 지원 범위로 명시합니다.

일반 거래처 주문의 단가·여신과 출고 판단은 B2B 유통 ERP 재고관리에서 따로 다룹니다. 본사 반환 이후 재고 상태의 구체적인 대사는 ERP 반품·부분출고 검수와 함께 확인하세요.

발주 검수표는 계약별 잔량과 보고 버전을 함께 시험합니다#

첫 검수에는 위 표의 100개 표본을 사용하되 모든 단계의 원장 행을 내려받아 대조합니다. 본사 출고와 거래처 인수 사이에서 소유 수량이 사라지거나 두 번 잡히지 않는지, 보고 30개와 승인 28개가 각각 조회되는지, 반환 10개가 이동 중일 때 어느 잔량에 포함되는지를 확인하세요. 표본은 시연 전에 발주자와 개발사가 같은 기대 결과에 서명할 수 있는 수준으로 구체화합니다.

두 번째 시험은 같은 판매 보고의 재전송, 네트워크 응답 유실 후 재시도, 두 승인자의 동시 승인을 대상으로 합니다. 동일 사건이 한 번만 반영되고 승인된 수량을 초과해 차감할 수 없는지 확인하세요. 처리 이력에 성공 또는 실패만 남는 대신 적용된 계약, 재고 행, 보고 버전과 요청 식별자를 찾아갈 수 있어야 원인을 설명할 수 있습니다.

세 번째로 승인 뒤 거래처가 판매 1개를 취소하는 표본을 넣습니다. 원판매가 삭제되지 않고 정정 요청과 승인 결과가 연결되는지, 해당 물건의 실물 반환과 수량 복원이 같은 사건으로 오해되지 않는지 확인합니다. 마감 후 조정일이나 금액 처리 방식은 재무 담당자가 확정한 정책에 따라 별도로 검수하며 이 글의 예시를 회계 전표 규칙으로 복사하지 않습니다.

거래처 A의 사용자로 거래처 B의 보고와 재고를 요청하는 권한 시험도 포함하세요. 화면 메뉴를 숨기는 것 외에 조회 API, 파일 내보내기, 첨부파일 주소와 집계 수치까지 차단되는지 검증합니다. 본사 관리자 권한을 위탁 운영자에게 과도하게 주지 않아도 자기 업무를 마칠 수 있는지 확인하고, 사용자 교체 시 권한 회수 절차를 운영 문서에 남깁니다.

최종 견적은 위탁 원장, 거래처 보고 수신, 승인·정정, 실물 대사와 외부 시스템 전달을 나눠 비교하세요. 이미 쓰는 ERP의 설정으로 해결할 부분과 별도 포털·파일 변환·연동 개발이 필요한 부분을 분리하면 계약 밖 작업을 줄일 수 있습니다. 특정 비용이나 기간을 먼저 정하기보다 계약 수, 품목 식별, 보고 형식과 예외 처리 범위가 같은 제안인지 검토하는 것이 순서입니다.