Skip to content
isdnetworks
Go back

백로그를 만든 스킵 규칙

정산 매칭에서 처리되지 않고 계속 남아 있는 건들이 있었다. 관련 기록을 보니 옵션이 바뀐 교환 건은 정산 귀속이 업무 판단 사항이므로 옵션값이 불일치하면 자동 매칭하지 말고 수동 확인 대상으로 남긴다는 지침이 있었다.

Table of contents

Open Table of contents

안전해 보이던 규칙

그 지침의 의도 자체는 읽으면 이해가 됐다. 원주문 옵션과 재발송 옵션이 다르면 자동으로 이어 붙였을 때 틀릴 수 있으므로 사람이 보게 남기자는 것이다.

문제는 수동 확인 대상으로 남긴 것들을 실제로는 아무도 안 봤다는 점이었다. 볼 절차가 마련돼 있지 않아서 그냥 미처리로 계속 쌓였고 수동 확인 대상이라는 이름이 실질적으로는 영구 미처리를 뜻하게 됐다.

과거 성공 사례의 조회

이 판단이 맞는지 확인하려고 과거에 정상 처리된 건을 찾았다. 재발송에 연결된 정산 건 중 원주문 옵션과 재발송 옵션이 다른 것만 골랐다.

그렇게 뽑으니 여러 채널에서 상당수가 나왔다. 색상이 바뀐 것과 사이즈가 바뀐 것과 기장이 바뀐 것이 전부 재발송에 연결돼 정상 처리돼 있었다.

담당자가 확인한 정상

이것이 정말 정상 처리가 맞는지를 담당자에게 물었더니 맞다는 답이 왔다. 교환은 애초에 다른 옵션으로 바꾸는 것이므로 옵션이 다른 것이 당연하다.

정산은 실제로 보낸 것에 붙는데 교환에서 실제로 보낸 것이 재발송 항목이다. 오히려 옵션이 같은 교환이 드물며 그 규칙은 애매한 케이스가 아니라 정상 케이스를 막고 있었다.

바뀐 판단 기준

그래서 판단 기준을 옵션 일치 여부에서 원본 참조 컬럼 보유 여부로 바꿨다. 그 컬럼이 채워져 있으면 재발송 항목이고 정산은 거기에 붙는다.

옵션값 자체는 판단에서 아예 보지 않기로 했다. 커맨드에서 스킵 로직을 제거하고 밀린 건들을 다시 돌리니 그대로 해소됐다.

두 종류의 미처리

다만 여전히 매칭이 안 되는 것이 남았는데 재발송이 아직 생성되지 않은 교환이었다. 붙일 대상 자체가 없으므로 못 붙이는 것이 당연하다.

이것은 막힌 것이 아니라 시점이 안 된 것이므로 재발송이 생기면 자연히 해소된다. 애매하면 사람이 보게 남긴다는 규칙은 정말 애매한지와 볼 사람이 있는지와 볼 절차가 있는지 셋이 갖춰져야 하고 그 셋이 없으면 안전이 아니라 방치이며 기존 규칙을 만나면 과거 성공 사례로 지금도 맞는지를 확인해야 한다.

정리


Share this post on:

Previous Post
상한을 산술로 계산한다
Next Post
부분 일치가 인덱스를 못 탔다