한 주문의 두 라인에 대해 하나는 최초 상품이니 교환 완료로 처리하고 다른 하나는 반품 접수로 처리해 달라는 요청이 왔다. 처리하기 전에 두 라인이 실제로 무엇인지를 관계 컬럼으로 확인했다.
Table of contents
Open Table of contents
관계 컬럼이 말한 것
원본 옵션을 가리키는 컬럼을 보니 요청에 적힌 것과 정반대였다. 최초라고 적힌 쪽이 다른 라인을 원본으로 가리키고 있었고 반품 접수라고 적힌 쪽이 원본 값 없이 최초 주문이었다.
즉 요청이 최초라고 부른 것이 실제로는 그 건의 재배송품이었다. 관계가 라벨과 어긋나 있었고 그것을 확인하지 않았으면 반대로 처리했을 것이다.
플래그보다 관계
판별에 쓸 수 있는 컬럼이 하나 더 있었는데 재배송 여부를 담는 플래그였다. 이름만 보면 그것이 정답 같지만 값이 비어 있는데 실제로는 재배송인 행이 있었다.
나중에 추가된 컬럼이라 과거 데이터가 비어 있거나 특정 경로에서만 채우는 것으로 보인다. 플래그는 채워지는 경로에 의존하지만 관계 컬럼은 데이터를 만들 때 반드시 넣어야 하므로 규칙이 단순하고 예외가 없다.
클레임이 붙는 자리
클레임도 조회했더니 교환과 반품 클레임이 둘 다 최초 라인에 붙어 있었다. 재배송품 쪽에는 클레임이 아예 없었다.
마켓 쪽에서는 최초 상품에 대한 교환 요청과 반품 요청으로 보고 있다는 뜻이다. 재배송품은 우리가 만든 것이라 마켓 클레임이 안 붙으므로 클레임은 최초 라인에 몰려 붙는다.
추측으로 뒤집지 않은 이유
여기서 선택지가 둘이었다. 번호를 잘못 썼겠거니 하고 뒤집어서 처리하는 쪽과 요청자에게 매핑을 다시 확인하는 쪽이다.
뒤쪽을 골랐다. 두 라인 다 배송 완료 상태이고 정산 전이라 잘못된 클레임 상태를 남기면 정산이 그대로 흘러가는 금전 영향이 있었다. 그리고 요청자가 번호를 잘못 썼는지 라벨을 잘못 알았는지 실제로 재배송품을 교환 완료하려는 것인지를 알 수 없었는데 마지막 경우라면 내가 뒤집는 것이 틀린 처리가 된다.
회신과 처리 수단
회신은 데이터상 어느 쪽이 최초이고 어느 쪽이 재배송품인지를 적고 요청하신 라벨과 반대이니 매핑을 다시 확인해 주시면 그대로 처리하겠다는 형태로 보냈다. 틀렸다고 단정하지 않은 것은 요청자가 라벨을 잘못 알았을 수도 있고 내 조회가 무언가를 놓쳤을 수도 있기 때문이다.
처리하게 되면 어떻게 할지도 정해 뒀는데 클레임 상태 변경 같은 쓰기는 직접 조작이 아니라 화면으로 한다. 화면을 거치면 정산 재계산과 이벤트 발행과 외부 전송이 같이 돌고 직접 조작이면 그것이 전부 빠지므로 조회는 분석에 쓰고 변경은 정식 경로로 한다.
정리
- 요청에 딸려 온 라벨을 그대로 믿지 않는다
- 관계 컬럼으로 먼저 검증한다
- 플래그는 채워지는 경로에 의존한다
- 외부 유래 레코드는 최초 라인에 몰려 붙는다
- 라벨과 데이터가 어긋나면 추측으로 뒤집지 않는다
- 미정산 건에 잘못된 상태를 남기면 금전 영향이다
- 틀렸다고 단정하지 말고 이렇게 보인다고 회신한다
- 쓰기는 화면으로 하고 조회는 분석에만 쓴다