ERP 반품·부분출고 검수: 재고·미출고·정산 수량 맞추는 법

ERP 반품·부분출고 검수는 버튼이 동작하는지 보는 시험이 아닙니다. 같은 주문 항목을 기준으로 출고와 미출고, 반품·취소 이력, 창고 상태와 정산 전달 결과가 일치하는지 확인하는 작업입니다. 정상 주문 한 건의 성공만으로 운영 가능성을 판단하면 예외 거래에서 수량이 어긋날 수 있습니다.

주문 10개 중 6개를 보냈고 그중 2개가 돌아왔다고 가정해 보겠습니다. 미출고는 4개일까요, 6개일까요? 돌아온 2개는 즉시 판매할 수 있을까요? 반품을 받았다는 사실만으로 답을 정할 수 없습니다. 재출고 여부와 검수 상태, 원주문의 약속을 어떻게 처리하는지에 따라 기대 결과가 달라집니다.

이 글의 숫자는 검수 방식을 설명하기 위한 가상 예시입니다. 실제 구축 실적이나 회계 처리 기준을 제시하는 것이 아닙니다. 회사의 업무 정책을 먼저 합의한 뒤, 같은 표본과 기대 결과를 후보 개발업체에 제공하는 데 활용하세요.

총재고가 맞는데도 운영이 틀릴 수 있습니다#

재고에는 물건의 위치와 판매 가능 상태가, 주문에는 고객에게 남은 약속이 담깁니다. 두 숫자는 관련되지만 같은 뜻이 아닙니다. 창고에 물건이 돌아와도 검수가 끝나지 않았다면 바로 판매하지 않을 수 있고, 반품을 종결하더라도 원주문의 미출고 약속은 그대로 남을 수 있습니다.

• 정상재고: 판매나 출고 대상으로 사용할 수 있다고 판정한 수량입니다.
• 검수대기: 물리적으로 보유하지만 사용 가능 여부가 확정되지 않은 수량입니다.
• 예약: 특정 주문에 배정해 다른 주문에서 쓰지 않도록 잡아 둔 수량입니다.
• 가용: 이 글의 예시에서는 정상재고에서 예약을 뺀 수량입니다. 실제 정의는 회사 정책으로 확정합니다.
• 미출고: 아직 이행하지 않은 주문 수량입니다. 반품 수량을 자동으로 더할지는 별도 정책입니다.

창고 이동 중, 위탁, 불량과 보류 상태가 있다면 상태별 정의를 더해야 합니다. ERP 화면의 재고 숫자가 어떤 상태를 포함하는지부터 문서화하세요. 영업팀과 창고팀이 같은 단어를 다른 의미로 쓰는 상태에서는 검수 결과도 합의하기 어렵습니다.

주문 10개·출고 6개·반품 2개로 검수해 보세요#

다음 예시는 초기 정상재고 100개, 주문 10개 전량 예약, 반품은 재출고 없이 종결하는 정책을 가정합니다. 반품품은 입고 시 검수대기로 분리하고, 합격한 뒤에만 정상재고로 옮깁니다. 다른 입출고와 추가 주문은 없는 상태입니다.

마지막 상태에서 고객에게 남은 물건은 4개이고 회사 보유 재고는 96개입니다. 원주문 이력에는 출고 6개, 반품 2개와 미출고 취소 4개가 각각 남아야 합니다. 재고 합계만 96으로 맞추려고 원래 출고를 4개로 덮어쓰면 실제로 6개를 보냈다가 2개를 돌려받은 경로를 설명할 수 없습니다.

재출고를 하는 회사라면 이 표의 결과를 그대로 사용하면 안 됩니다. 교환용 주문을 새로 만들지, 원주문에 재출고 잔량을 연결할지 정하고 중복 배정을 막아야 합니다. 반품이 불합격이라면 정상재고로 옮기지 않고 불량·보류·폐기 등 승인된 후속 상태로 처리하는 표본도 추가합니다.

거래 단위가 박스와 낱개로 섞인다면 환산 기준도 고정하세요. 품목의 기본 단위, 주문 단위와 입출고 단위가 다른 상황을 테스트하고, 과거 거래가 현재의 포장 수량 변경 때문에 다시 계산되지 않는지 확인하는 것이 좋습니다.

취소·반품 입고·정산 전달은 한 사건이 아닙니다#

미출고 취소, 물품 회수, 품질 판정과 금액 조정은 서로 다른 완료 시점을 가질 수 있습니다. 반품 접수만으로 재고를 늘리거나, 창고 입고만으로 환불이 끝났다고 표시하면 담당 부서가 다른 기준으로 업무를 종료하게 됩니다.

Microsoft Business Central의 반품·취소 공식 안내도 판매 반품 주문과 대변 메모, 미지급 판매 송장의 정정·취소를 구분합니다. 해당 제품의 단순 정정·취소 작업은 부분 반품을 지원하지 않는다고 설명하므로, 부분 반품에 필요한 경로를 따로 확인해야 합니다. 이는 제품별 차이를 보여주는 예시이며 국내 회계 처리의 정답을 뜻하지 않습니다.

발주서에는 각 사건의 책임자를 적으세요. 영업은 반품 합의를, 창고는 입고 수량을, 품질 담당은 판매 가능 여부를, 재무는 필요한 금액 조정과 마감 처리를 확인하는 식입니다. 한 부서의 완료가 다음 부서의 완료로 자동 표시되지 않게 하고, 아직 연결되지 않은 후속 작업을 찾는 목록도 요구하세요.

정상 데모 다음에 중복·실패·동시 작업을 시험하세요#

실제 운영 검수에는 같은 요청이 두 번 오거나, 두 사람이 남은 수량을 동시에 처리하는 장면이 필요합니다. 단순히 오류 메시지가 나오는지보다 실패 뒤 원장과 잔량이 어떤 상태로 남는지 확인하세요. 아래 시험은 허용된 검수 환경과 익명 데이터에서 진행해야 합니다.

재처리 버튼이 있다는 것만으로 충분하지 않습니다. 어디까지 처리됐는지, 다음 실행이 무엇을 반복하는지 운영자가 알아야 합니다. 자동 재시도 대상과 사람 확인 대상, 재시도 횟수와 중단 조건을 나누고 실패 목록에서 원주문과 창고 기록까지 이동할 수 있도록 요구하세요.

검수표는 기능명이 아니라 입력과 기대 수량으로 만듭니다#

좋은 검수 항목은 사전 상태, 수행자, 입력, 이벤트 순서와 기대 결과를 포함합니다. 반품 기능 정상이라는 한 줄보다 주문 항목 ID와 창고 상태별 기대 수량을 적으면 개발사와 현업이 같은 결과를 확인할 수 있습니다. 통과한 증거 파일과 결함 번호도 해당 항목에 연결하세요.

물류·영업·재무가 각자 검수하되 마지막에는 같은 기준 시점으로 대사해야 합니다. 창고의 일마감 숫자와 영업의 실시간 숫자를 그대로 비교하면 처리 지연을 결함으로 오해할 수 있습니다. 연동 지연의 허용 범위, 기준 시각과 미처리 이벤트를 함께 기록하고 실제 불일치와 아직 도착하지 않은 거래를 구분합니다.

최종 인수 때는 개발자 계정이 아니라 지정된 운영 담당자가 실패 건을 찾고 승인된 절차로 재처리해 보게 하세요. 운영 매뉴얼에는 필요한 권한, 처리 순서, 되돌릴 수 없는 작업과 지원 요청 조건이 있어야 합니다. 데이터 수정은 직접 DB 값을 고치는 비공식 방법에 의존하지 않는지 확인합니다.

개발 견적에서 따로 받아야 할 범위는 무엇일까요?#

반품 메뉴 하나라는 이름 안에 반품 접수, 물류 문서, 검수, 교환 출고, 정산 연동과 마감 예외가 들어갈 수 있습니다. 어느 단계까지 이번 계약에 포함되는지 나누고, 기존 ERP 설정으로 되는 작업과 별도 연동·개발을 구분해 견적을 받으세요. 이 글에서는 범위 확인 없이 비용이나 기간을 제시하지 않습니다.

초기에는 대표 품목·단위·창고와 한 가지 반품 정책으로 검수 표본을 만들고, 이후 다창고·로트·시리얼·해외 거래 같은 변형을 확장할 수 있습니다. 다만 실제 운영에 필수인 예외를 다음 단계로 미룬 채 전체 도입이 끝났다고 선언하면 안 됩니다. 단계별 사용 범위와 남은 수동 작업을 명시하세요.

유통 업무 전체 연결은 B2B 유통 ERP 재고관리, 후보사 검증은 ERP 구축 업체 선정 기준, 이전 자료의 대사는 ERP 데이터 이관 가이드로 이어서 확인하세요. 아래는 자사 서비스 범위이며 본문의 가상 예시를 실제 수행 실적으로 제시하는 것은 아닙니다.