StackCubeDocs
문서

검토 예외 처리#

스택큐브 세팅 개선은 대부분 반복되는 검토 예외에서 나옵니다. 예외를 주문 판단 문제인지, 세팅을 개선해야 하는 신호인지 구분하세요. 출고에 영향을 주는 주문을 단순히 큐에서 없애려고 승인하면 안 됩니다.

스택큐브 검토 표시와 승인 컨트롤
검토 표시, 주문 금액, 주문 상태, 승인과 반려 컨트롤을 기준으로 출고 전 예외를 처리합니다.

알 수 없는 거래처#

발신자, 로그인 아이디, 파일 출처를 하나의 거래처 기록으로 연결할 수 없다면 승인을 보류합니다.

같은 거래처가 다른 이름으로 등록되어 있는지, 바이어가 새 이메일이나 전화번호를 썼는지, 지점 또는 계열 거래처 주문인지 확인합니다. 신규 거래처라면 주문 승인 전에 거래처 기록을 먼저 만드세요.

품목 미매칭#

출고에 영향을 주는 품목이라면 매칭이 불확실한 라인은 승인하지 않습니다.

원본 메시지, 첨부파일, 이전 주문, 품목 별칭을 확인해 라인을 수정할지, 주문을 반려할지, 승인을 보류할지 결정합니다. 같은 수정이 반복되면 매번 라인을 고치지 말고 카탈로그 별칭에 추가하세요.

가격 불일치#

가격 예외는 단순 입력 문제가 아니라 정책 판단입니다. 오타는 검토자가 수정할 수 있지만, 반복적인 가격 덮어쓰기는 거래처 가격 등급이나 등급별 규칙이 빠졌거나 오래되었다는 신호입니다.

승인 전에 제출 가격, 설정된 품목 단가나 등급 단가, 영업 합의 중 무엇이 기준인지 확인하세요. 다음 검토자가 같은 논의를 반복하지 않도록 결정 내용을 남깁니다.

중복 의심 주문#

같은 거래처, 같은 품목, 비슷한 수량의 주문이 가까운 시간에 들어오면 보류합니다.

원본 메시지와 후속 메시지를 확인하세요. 어떤 중복은 정정 요청이고, 어떤 경우는 의도적인 반복 주문입니다. 원본 근거로 의도가 명확할 때만 승인합니다.

반려해야 하는 경우#

원본이 주문이 아니거나, 거래처가 취소했거나, 품목을 식별할 수 없거나, 요청된 처리 방식이 운영 기준에 맞지 않으면 수정하지 말고 반려합니다.

주문 메모나 내부 운영 기록에는 시스템 상태만 남기지 말고 운영상 이유를 적습니다. 다음 검토자가 왜 주문이 진행되지 않았는지 이해할 수 있어야 합니다.

검토 후 세팅 개선#

하루가 끝나면 반복 예외를 묶어서 확인합니다.

  • 알 수 없는 발신자가 반복되면 거래처 별칭이나 연락처 연결을 추가합니다.
  • 품목명이 반복적으로 미매칭되면 품목 별칭을 추가합니다.
  • 승인된 가격 덮어쓰기가 반복되면 거래처 가격 등급이나 등급별 규칙을 업데이트합니다.
  • 고객이 불완전한 주문을 계속 보내면 채널 안내를 조정합니다.