반품 배송비를 고객 부담으로 바꿔 달라는 요청이 왔다. 데이터를 보니 귀책은 판매자로 처리조건은 환불 차감으로 돼 있었다.
Table of contents
Open Table of contents
처음의 틀린 안내
내가 처음 답한 것은 환불 차감으로 돼 있으니 이미 고객 부담이고 귀책은 그대로 둬도 된다는 것이었다. 환불금에서 배송비를 빼니 고객이 내는 것이라는 논리였다.
구매자 귀책으로 바꿔야 하지 않느냐는 지적을 받았다. 다시 보니 두 값의 역할이 달랐다.
두 값의 역할
귀책은 누가 부담하는지를 정하고 처리조건은 그 부담을 어떻게 회수하는지를 정한다. 어떻게는 누가를 바꾸지 못한다.
두 값을 같이 보면 판매자가 부담인데 고객 환불금에서 뺀다는 뜻이 되어 말이 안 됐다. 정산에서는 차감한 금액이 다시 판매자 쪽으로 잡혀 결국 판매자가 내게 되므로 고객 부담이 아니었다.
라벨이 아니라 계산 입력
내가 틀린 이유는 귀책을 표시 라벨로 봤기 때문이다. 화면에 뜨거나 통계에나 쓰는 값으로 여겼다.
실제로는 정산 계산 코드가 그 값을 읽고 분기해서 배송비를 어느 쪽에서 빼는지를 정하고 있었다. 라벨일 뿐이라고 넘기면 돈이 반대 방향으로 잡힌다. 반품 상세 사유를 보니 고객이 주소를 예전 거주지로 적은 건이라 구매자 귀책이 사실이었고 원래 데이터가 틀려 있던 것이었다.
처리 순서와 재계산
처리 순서를 다섯 단계로 잡았다. 귀책을 구매자로 바꾸고 처리조건은 환불 차감을 유지한 뒤 재계산을 눌러 정산액을 확인하고 저장한다.
가운데 두 단계가 핵심인데 귀책을 바꾸면 정산이 다시 계산되고 그 결과가 목표액과 맞는지를 봐야 하기 때문이다. 자동 산출값이 목표와 다를 때만 배송비 보정으로 맞추는데 보정을 먼저 하면 재계산이 그것을 덮는다.
확인 순서의 교정
이 건에서 절차 하나를 얻었다. 고객 부담으로 해 달라는 요청을 받으면 처리조건부터 보지 않고 귀책부터 본다.
처리조건을 먼저 보면 환불 차감이니 됐다는 결론으로 가고 그것이 내가 한 실수였다. 부담 주체를 먼저 확정하고 회수 방식을 보는 순서여야 한다. 틀린 이유를 한 줄로 줄이면 두 컬럼의 역할을 확인하지 않고 이름에서 유추한 것이고 컬럼의 역할은 그 값을 읽는 코드에서 확인해야 한다.
정리
- 부담 주체는 귀책이 정하고 회수 방식은 처리조건이 정한다
- 어떻게는 누가를 바꾸지 못한다
- 귀책은 표시 라벨이 아니라 정산 방향을 좌우한다
- 라벨로 보고 넘기면 금전이 반대 방향으로 잡힌다
- 귀책을 바꾸고 재계산한 뒤 정산액을 확인하고 저장한다
- 보정을 먼저 하면 재계산이 덮는다
- 부담 주체를 먼저 확정하고 회수 방식을 본다
- 컬럼의 역할은 그 값을 읽는 코드에서 확인한다