티스토리 뷰

예약해제
온라인 판매 주문을 정리하던 중 취소 완료 한 건이 들어왔지만 가용 재고는 예상만큼 늘지 않았습니다. 주문 화면만 보면 상품 세 개가 모두 취소됐고, 내부 예약 목록에는 같은 주문 키로 두 개가 남아 있었습니다. 저는 취소 수량 세 개를 바로 더하지 않고 주문번호, 내부 키, SKU, 바코드, 상태 변경 시각을 한 표에 놓았습니다.
취소 요청과 취소 완료는 계산에서 다르게 다뤘습니다. 고객이 취소를 눌렀어도 출고 단계나 판매처 승인 상태에 따라 실제 확정 시각이 달랐습니다. 원 주문 이력에서 완료 상태를 확인하고, 그보다 앞서 송장이나 센터 출고가 잡혔는지 살폈습니다. 상태가 애매한 행은 재고에 손대지 않고 확인 대기 표시를 남겼습니다.
예약 목록에서는 상품명으로 찾지 않았습니다. 옵션명이 줄어들거나 묶음 수량이 다르게 적힐 수 있어 내부 SKU와 바코드, 주문 키를 함께 사용했습니다. 같은 SKU라도 다른 주문의 예약을 해제하지 않도록 행 ID를 보존했습니다. 조회 화면 캡처에는 고객 이름과 연락처를 넣지 않고 상태와 수량이 보이는 범위만 남겼습니다.
주문은 취소됐는데 예약 수량이 남아 있고, 별도 출고 이력도 보여 단순히 주문 수량을 되돌릴 수 없었습니다. 원 주문과 예약 행, 물류 처리를 같은 SKU 기준으로 펼쳤습니다.
- 판매처 주문번호와 내부 주문 키, SKU, 바코드를 한 줄로 연결했습니다.
- 취소 요청과 취소 완료를 구분하고 완료 시각을 확인했습니다.
- 예약 재고가 남았는지, 이미 해제됐는지 이력으로 보았습니다.
- 실제 출고나 송장 생성이 있었으면 자동 복구 대상에서 제외했습니다.
취소 재고는 주문 수량을 그대로 더하는 계산이 아니었습니다. 취소 완료, 예약 해제, 실제 출고 없음이 같은 주문과 SKU에서 확인될 때만 복구 대상으로 잡고, 어느 근거가 비었는지 행마다 남겨야 이중 복구를 막을 수 있었습니다.

출고대조
- 원 주문의 상태 변경 이력과 취소 완료 시각을 저장했습니다.
- 예약 테이블에서 같은 주문 키와 SKU의 잔여 예약을 찾았습니다.
- 송장과 센터 출고 이력을 바코드와 수량별로 대조했습니다.
- 모든 근거가 맞는 행만 수량복구 후보로 확정하고 변경 전후 값을 기록했습니다.
출고대조에서는 송장 발급과 실제 출고 처리를 같은 것으로 보지 않았습니다. 송장이 만들어졌어도 센터에서 스캔되지 않았을 수 있고, 반대로 다른 묶음 출고에 포함된 이력이 있을 수 있었습니다. 센터, 바코드, 거래별 수량, 처리 시각을 펼쳐 원 주문과 일치하는 행만 표시했습니다.
주문 세 개가 취소됐다는 합계만 보면 예약 두 개와 출고 한 개의 차이가 숨습니다. 저는 거래별 배열을 유지해 예약 2, 출고 1, 취소 완료 3을 별도 칸에 두었습니다. 이미 출고된 한 개는 재고 복구에서 제외하고 반품이나 회수 흐름으로 넘길 근거만 남겼습니다. 예약이 자동으로 해제된 행은 수동 해제를 반복하지 않았습니다.
조회 결과가 늦게 반영될 때는 같은 버튼을 여러 번 누르지 않았습니다. 변경 전 예약 수량과 조회 시각을 기록하고, 새로고침 뒤 상태가 바뀌었는지 확인했습니다. 저장 응답이 불명확하면 즉시 재시도하지 않고 최신 이력과 현재 값을 다시 읽었습니다. 외부 반영이 정확히 한 번만 일어나야 하는 작업이라 화면 지연을 실패로 단정하지 않았습니다.
헷갈렸던 지점
취소 수량 전체를 가용 재고에 바로 더하려 한 점입니다. 예약이 이미 해제됐거나 실제 출고가 끝난 수량이 섞이면 같은 재고를 두 번 복구할 수 있었습니다.
취소 요청만으로 재고를 복구하지 않습니다. 취소 완료 상태, 예약 잔여, 실제 출고 이력을 같은 주문 키와 SKU로 대조하고, 저장 결과가 불명확하면 최신 상태를 확인한 뒤 판단합니다.
수량복구
수량복구 후보는 계산식 하나로 확정하지 않았습니다. 취소 완료 수량에서 실제 출고 수량을 빼고, 예약이 이미 자동 해제된 수량은 다시 더하지 않도록 상태 플래그를 확인했습니다. 식의 입력값마다 출처 화면과 조회 시각을 붙였습니다. 값이 비어 있으면 0으로 채우지 않고 확인 필요로 남겼습니다.
변경을 적용하기 전에는 현재 가용 재고와 예약 재고를 별도 저장했습니다. 적용 뒤 두 값을 다시 읽어 예상한 행만 변했는지 확인했습니다. 다른 SKU가 함께 움직이거나 수량 차이가 나면 추가 수정을 멈추고 원 주문과 출고 이력을 다시 열었습니다. 결과표에는 고객정보 대신 주문 키 일부와 SKU, 전후 수량, 근거 상태만 기록했습니다.
제 완료 기준은 취소 주문이 목록에서 사라진 상태가 아니었습니다. 제 완료 기준은 원 주문의 취소 완료, 예약 해제 여부, 실제 출고 수량, 재고 전후 값을 한 줄로 설명하고 같은 시각의 감사 기록까지 확인하는 것이었습니다. 쿠팡 판매자 공식 포털과 관세청 시스템처럼 원천 상태를 확인할 수 있는 화면을 기준으로 삼고 복사된 엑셀만 단독 근거로 사용하지 않았습니다.
자주 묻는 질문
Q. 취소 완료면 주문 수량을 바로 더해도 되나요?
A. 예약이 이미 풀렸는지와 실제 출고가 있었는지를 확인한 뒤 복구 수량을 정해야 합니다.
Q. 송장이 있으면 모두 출고된 건가요?
A. 송장 생성과 실제 센터 출고를 나누고 바코드와 처리 이력을 대조합니다.
Q. 저장 결과가 늦게 보이면 다시 눌러도 되나요?
A. 중복 반영을 막기 위해 최신 상태와 이력을 먼저 읽고 첫 요청의 결과를 확인합니다.
- Total
- Today
- Yesterday
- 발급시점
- 재고회전
- 온라인판매운영
- 광고비
- 온라인판매회계
- 상품소싱
- 상품손익
- 재고계산
- 1688소싱
- 중국발주
- 반품정산
- 온라인판매
- 광고비상품별배분
- 판매자쿠폰
- 귀책구분
- 매출연결
- 판매수수료정산
- 상품광고
- 상품별손익
- 주문대조
- 쿠폰할인분담률
- 상품원가
- sku관리
- 정산차액
- 광고성과
- 재고관리
- 상품마진
- 쿠팡광고
- 비용분리
- 마진관리
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
