受注データの取り込みで一部の注文だけ漏れるとき｜品番の形式を決め打ちした抽出が例外の品番を黙って落とす仕組みと、件数で突き合わせる確認
受注データの取り込みで一部の注文だけ漏れるとき｜品番の形式を決め打ちした抽出が例外の品番を黙って落とす仕組みと、件数で突き合わせる確認
楽天・Amazon・Yahoo!・自社ECの受注を1つの台帳に自動で取り込んでいる。全体としては動いているのに、特定の商品の注文だけ品番が空欄だったり、「マスタ未登録」「在庫不明」のまま放置されていたりする。エラーは出ていない。
結論を先に書きます。
この症状で最初に疑うのは、取り込み処理の中で品番の「形」を決め打ちしている箇所です。たとえば「品番は数字5桁-数字3桁」という前提で抽出条件を書いていると、その形に合わない品番の注文は、エラーにならずに素通りします。処理は最後まで走り、ログには「失敗0件」と出ます。
正しい作り方は次の3点です。
- 品番の形を抽出条件に書かない。モール側のSKUのうち形が固定されている部分（色・サイズ・価格・登録日など）を手がかりに切り出す
- 切り出した品番が商品マスタに実在するかで正否を判定する。形ではなく、照合で確かめる
- 取り込みのたびに「取り込んだ件数」と「品番が解決できた件数」を並べて出す。差が出た行は理由別に数える
以下、4チャネル・107件の受注台帳で実際に確認した数字を使って説明します。
「一部だけ漏れる」は形式の決め打ちで起きる
モールのSKUは品番そのものではない
受注を一元管理するとき、各モールの注文データに入っているのは社内の品番そのものではなく、モールごとに加工された文字列です。ある革製品メーカーの例では、チャネルごとに次のような規則になっていました。
| チャネル | 注文データ上の表現 |
|---|---|
| 自社EC | 商品コード＋色2桁＋サイズ2桁＋内部連番3桁を連結したSKU |
| 楽天 | 商品名の括弧内に商品コード、本文に「カラー:05」の形で色 |
| Yahoo! | 品番そのまま＋カラー（コード付き／名称のみの2形式） |
| Amazon | 「品番-色-サイズ-価格-登録日」をハイフンでつないだSKU |
取り込み処理は、ここから社内の正しい品番を取り出し、商品マスタで商品名を引き、在庫と照合します。品番ルールをどう統一するかは「楽天・Amazon・Yahoo!・自社ECの受注を1つにまとめる方法」に書きました。本稿はその先、取り出す処理が一部の品番を取りこぼす話です。
抽出条件に「品番の形」を書くと何が起きるか
Amazonの「品番-色-サイズ-価格-登録日」から品番を取り出すとき、素直に書くと「先頭の、数字5桁-数字3桁の部分が品番」という条件になります。手元の受注を眺めると、実際にほとんどの品番がその形だからです。
ところが、この会社の品番は少なくとも2系統ありました。
| 系統 | 形（例は架空） |
|---|---|
| 数字5桁-数字3桁 | 60000-000 |
| 数字4桁-英字1字＋数字3桁 | 8000-X000 |
抽出条件は1系統目しか想定していません。2系統目の品番の注文が来ると、条件に合わないので分解されず、長いSKUがそのまま「品番」欄に入ります。当然、商品マスタには無い文字列なので「マスタ未登録」になり、在庫照合は「在庫不明」になります。
注意したいのは、この2系統目が例外的な少数派ではなく、台帳の主力商品の系統だったことです。放っておけば、今後の同系統の受注はすべて同じ形で落ち続けます。
エラーが出ないから見つからない
この不具合が厄介なのは、どこにも赤い表示が出ないことです。
- 注文の行は台帳に入る（取り込み件数は合う）
- 抽出は「条件に合わなかったので元の文字列を返す」という正常な動きをしている
- ログは「パース失敗0件」のまま
担当者から見ると「この注文は商品マスタに未登録らしい」としか読めません。マスタ登録漏れは実際にも起こるので、取り込み側の不具合だとは疑われにくい。だから件数で確かめる仕組みが要ります。売上データで「成功と出ても明細が消える」場合の話は「売上データを取り込んだら金額が合わないときの原因」にまとめましたが、根は同じで、処理の成功と中身の正しさは別物です。
正しい作り方：形ではなくマスタとの照合で確かめる
変わらない側を手がかりに切り出す
品番の形は、商品が増えるたびに増えます。一方、モール用SKUの後ろ側、つまり「色3桁-サイズ3桁-価格-登録日8桁」は、自社で決めた付け方なので形が安定しています。
そこで、後ろの固定部分を錨（いかり）にして、その手前すべてを品番として切り出す方式にします。品番が数字5桁でも、英字入りでも、将来3系統目が増えても、抽出条件を書き直す必要がありません。
切り出した結果はマスタで検証する
切り出しただけでは、正しい品番かどうかは分かりません。そこで、切り出した文字列が商品マスタに実在するかを確かめ、実在したときだけ品番として採用します。
| 判定のしかた | 品番の系統が増えたとき |
|---|---|
| 形で判定（数字5桁-数字3桁か） | 条件に合わず黙って素通り。抽出条件の修正が必要 |
| マスタとの照合で判定 | マスタに登録されていれば自動で通る。修正不要 |
マスタに無かった場合は、推測で埋めません。先の例でも、他とまったく形の違うSKUが1件あり、規則では解けませんでした。これは「取り込み側で何とかする」のではなく、マスタ登録が必要な行として人に渡すのが正解です。推測で品番を埋めると、間違った商品の在庫を引き当てることになります。
修正後の数字
抽出方式を直し、台帳に残っていた該当行を修復した結果です。当初の報告では該当は2件でしたが、全行を機械的に洗うと3件ありました。目で見つけた件数をそのまま信じず、条件を決めて全行を洗うのが確実です。
在庫判定の内訳（受注107行）は、在庫データの差し替えと合わせて次のように変わりました。
| 在庫判定 | 直す前 | 直した後 |
|---|---|---|
| 在庫あり | 4 | 68 |
| 在庫なし（在庫0） | 2 | 17 |
| 在庫なし→製造（注文された色が無い） | 0 | 7 |
| 在庫不明 | 101 | 15 |
「在庫不明」が101件だった時点では、1件ずつの原因を追う気になれません。不明が15件まで減ってはじめて、残りの内訳が読めるようになります。
取り込み件数を元データと突き合わせる
形式の決め打ちは、コードを読まない限り見つけられません。運用側で気づけるようにするには、取り込みのたびに次の数字を並べて出します。
1. 段階ごとの件数を出す
| 段階 | 出す数字 |
|---|---|
| 元データ | チャネル別の注文件数（モール管理画面や受注メールの通数） |
| 取り込み | 台帳に追加した行数・重複でスキップした行数 |
| 品番の解決 | 正しい品番に変換できた行数／できなかった行数 |
| 在庫照合 | 在庫データと突き合わせられた行数／られなかった行数 |
実例では、品番と在庫データの突合率は84.8%（突合84件・未突合15件・品番が空8件）でした。チャネル別では、自社EC 25/35、Yahoo! 22/27、Amazon 12/16、楽天 25/29。こうして分母と分子を並べると、「Amazonだけ4件落ちている」とチャネル単位で当たりがつきます。
2. 「解決できなかった」を理由別に数える
未解決を1つの「不明」にまとめると、放置されます。実例の内訳はこうでした。
- 品番が空（8件）：受注メールの本文から品番を取れていない。チャネル別の読み取り精度の問題
- 注文された色が在庫データに無い（10件）：これは取り込みの不具合ではなく、その色の在庫が実際に無いという正しい結果。表示を「在庫不明」から「在庫なし→製造」に変えたほうが現場は動きやすい
- 在庫データに未掲載（5件）：マスタか在庫データ側の登録待ち
同じ「突き合わせられなかった」でも、直す場所が取り込み処理・表示の文言・マスタ登録と、3つに分かれます。
3. 生の文字列が残っている行を機械的に探す
品番欄に入っている値が、品番として不自然に長い、ハイフンの数が多い、マスタに無い。この3条件で台帳を全行洗うと、素通りした行が拾えます。一度作っておけば、新しい系統の品番が増えたときの検知器になります。
同じ作業で一緒に確かめたい2つのこと
取り込みの不具合を直す場面では、似た種類の「黙って間違う」箇所が近くに見つかります。
列の見出しと中身が食い違っていないか
台帳の在庫列で、見出しは「通販倉庫在庫」なのに、プログラムが書き込んでいるのは本社在庫、という状態が起こりえます。仕様変更の際に値だけ入れ替え、見出しの変更を処理に含めていないと、こうなります。
見出しを信じた担当者は「通販倉庫にある」と読んで出荷を判断します。倉庫ごとに在庫の意味が違う場合は特に危険で、その構造は「在庫データを倉庫別に合算してはいけない」に書いたとおりです。値を書き込む前に見出しを直す。順番が逆だと、正しい値が間違った意味で表示される時間ができます。
スプレッドシートへの書き込みで値が化けていないか
APIでスプレッドシートに書くとき、入力方式を「ユーザー入力として解釈」にすると、色コード01が数値の1に変わります。品番や色コードのような文字として扱う値は「そのまま書く」方式（RAW）に統一します。取り込み処理と修復用の処理で方式が違うと、修復した行だけ化ける、ということが起きます。
本番の台帳を直すときの手順
稼働中の受注台帳を修復するときは、次の順で進めると安全です。
- 空実行で差分を出す。どの行のどの列が、何から何に変わるかを一覧にする
- 現場の動きが変わる行を先に検証する。実例では、判定が「製造へ回す」に変わる8行すべてについて、品番が在庫データに実在することを確認し、「品番が無いのに製造へ回る行が0件」を確かめてから書き込んだ
- 書き込む範囲を絞る。発送完了・キャンセル済みの行は触らない。値が変わらない行には書かない
- もう一度実行して、更新0行になることを確かめる。同じ処理を2回流して結果が変わらなければ、毎朝の自動実行に載せても行が増えたり値が揺れたりしない
起こりうる失敗と予防
| 起こりうること | 予防 |
|---|---|
| 新しい形の品番の注文が、エラーなしで未登録扱いになる | 形で抽出せず、固定部分から切り出してマスタで検証する |
| 「失敗0件」のログを見て正常と判断する | 取り込み件数と品番の解決件数を別々に出す |
| 未解決が「不明」1種類に丸められて放置される | 理由別（品番が空／色が無い／未掲載）に数える |
| 規則で解けないSKUを推測で埋める | 埋めずに「マスタ登録待ち」として人に渡す |
| 見出しと中身が食い違ったまま運用される | 仕様変更時は見出しの変更も処理に含め、値より先に直す |
| 修復用の処理だけ書き込み方式が違い、コードの先頭の0が消える | 文字として扱う値はRAWで統一する |
よくある質問
Q. 取り込みツールを外注・購入している場合はどう確かめればよいですか。
コードを見られなくても、件数の突き合わせはできます。モール管理画面の注文件数、台帳の行数、品番が入っている行数の3つを、1週間分だけ並べてみてください。差が特定のチャネルや特定の商品群に偏っていれば、形式の決め打ちを疑う根拠になります。
Q. 品番の体系を1つに統一すれば解決しますか。
長期的にはそれが理想ですが、既存の品番は店頭のタグや仕入先とのやり取りにも使われており、すぐには変えられません。取り込み側を「形に依存しない」作りにしておくほうが現実的です。
Q. 注文そのものが台帳に入らない場合も同じ原因ですか。
別の原因も考えられます。受注メールの集約経路が止まっている、重複判定のキーが衝突している、などです。受注をどこから取るかの設計は「ネットショップの受注を1枚のスプレッドシートに集約する設計」を参考にしてください。
まとめ
受注の取り込みで一部の注文だけ漏れるときは、品番の形を決め打ちした抽出条件を疑います。形に合わない品番はエラーにならず、長いSKUのまま「マスタ未登録」「在庫不明」に落ちるため、ログからは見つかりません。
対策は、形ではなく商品マスタとの照合で確かめる作りにすること、そして取り込みのたびに「取り込んだ件数」「品番を解決できた件数」「解決できなかった理由の内訳」を出すことです。不明を減らしていくと、残った数件は取り込みの問題ではなく、在庫が実際に無い・マスタ登録が要る、といった現場の判断事項に変わります。
graciautoでは、ネットショップの受注一元化や在庫照合の仕組みづくりを、スプレッドシートと自動処理の組み合わせでお手伝いしています。「動いてはいるが、数字が合っているか自信がない」という段階でも、お問い合わせからご相談ください。