Makeで受注件数を毎日照合する｜欠けた注文と二重記録を探す

完成するものと対象範囲

受注元の注文一覧と、管理表へ記録した注文を毎日照合します。件数の一致だけでは同じ注文が揃ったか分からないため、注文IDの集合を比べます。発送や返金の処理は行わず、欠落・重複・時刻境界の差を担当者が確認するための一覧を作ります。

取得元の注文状態は、日付と同じくらい重要です。受注済み、保留、取消、下書きなどのどれを元一覧へ含めるかを決めます。管理表が確定注文だけを持つなら、元一覧も同じ範囲へ揃えるか、除外理由を差分へ表示します。注文の状態を日中に変更したときに過去の照合がどう変わるかも、運用担当者へ説明できるようにします。

項目と保存先を準備する

入力と保存先に用意する項目は、照合日、元の注文ID、記録済み注文ID、取得範囲、重複件数、差分理由、確認者です。元の値と担当者が確認した値は区別し、同じ名前の列を別の意味へ使い回さないようにします。実運用の情報を入れる前に、練習用の識別子で一件を作成し、必要な担当者だけが参照・編集できる保存先を選びます。

注文IDの正規化は、前後の空白を除く程度から始めます。大文字小文字や記号を勝手に落とすと、別の注文が同じIDになる可能性があります。実際に同値と扱ってよい規則だけを採用し、比較用IDと原文IDを併記します。大量の検索条件へIDを渡す場合も、取得件数の上限や一度に照合できる数を確認し、結果の一部だけで一致と判断しません。

設定を順に進める

受注元と記録先で同じ時刻範囲を定義します。日付が海外時間の場合は日本時間との境界を明示し、取得遅延に備えて前日分を再確認する範囲も決めます。ページ分割がある取得元は、全ページを取得したことを記録します。

取得した注文IDを正規化し、元にあって管理表にないIDと、管理表だけにあるIDを分けます。数字に変換して先頭の零を落とさず、文字列として扱います。重複行は集合比較だけでは見えないため、ID別の件数も集計します。

差分一覧へ取得時刻と元データへの参照を保存し、担当者が理由を選べるようにします。単なる取得遅延、取消、手動入力、連携失敗を分けます。通知は差分の概要と一覧へのリンクに留め、顧客情報を広いSlackチャンネルへ転記しません。

少数のデータで確かめる

元の注文がA・B・C、管理表がA・B・Bなら件数は同じ三件ですが、Cが欠けてBが重複しています。この練習例を使い、件数だけの比較では合格しないことを確認します。翌日にCが届いた場合も、前日の未確認差分を自動で消さず解消理由を残します。

運用中の変更を扱う

日次の差分は新規、継続、解消を分けて管理します。毎朝同じ欠落を別の障害として通知すると、担当者が何を処理済みか分からなくなります。差分IDには照合規則と注文IDを含め、解消時に原因と修復参照を記録します。通知しない日にも照合が正常終了した記録を残し、障害がないことと監視が動かなかったことを区別できるようにします。

費用と利用量を見積もる

日次照合は元一覧と管理表を取得する両側の処理を数えます。過去日を再確認する範囲を広げると、毎日の読み取り量が増えます。注文件数、ページ数、照合対象の日数、差分通知を記録し、必要な検出時間と取得範囲を決めます。復旧時に大量の再取得が必要になる場合の余裕も見積もり、通常日だけの利用量で枠を使い切らない構成を検討します。

不具合が出たときの確認

大量の差分が出たら、全件追加の修復より先に取得範囲と接続先を確認します。別店舗や別期間を比較している可能性があります。欠落が確定したIDだけを取り込み直し、修復後に同じ照合条件で差分がなくなったかを再確認します。

運用を始める前の確認

公開・運用前の確認では、通常の一件だけでなく、必須項目が欠けた一件、同じ識別子を再利用した一件、確認後に内容を変更した一件を分けて試します。特に「照合日」が元の記録へ戻る手掛かりになり、件数とIDの集合を両方比較し、修復前後の差分と理由を保存するという条件を満たすか確認してください。結果を担当者と共有し、どの入力をどの状態へ残すかが説明できてから対象を広げます。

照合対象の取得が途中で止まった日には、差分ゼロと表示しないようにします。元一覧が百件のはずなのに最初の五十件しか取れなかった場合、管理表側に余分な注文があると誤判定する可能性があります。取得完了の状態と照合完了の状態を分け、全ページの取得が終わっていなければ結果を未完了にします。練習では二ページ目だけ失敗させた想定を作り、欠落した取得結果を修復用データへ使わないことを確認します。監視の失敗を受注の失敗と混同しない運用にしてください。

• Shopifyの注文記録
• MakeのHTTPモジュール
• Makeのエラー対応