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