楽天RMSのピッキングリストは、注文単位で確認するRMS標準帳票を使うのか、商品別に複数注文を束ねる集約リストを別で作るのかを分けて考えるのがポイントです。RMSだけで回せる範囲はありますが、注文数が増えるほどCSV整形やOMS/WMSの活用が現実的になります。
RMSでいうピッキングリストは何か
RMS標準帳票とピッキングリストは同じか
同じではありません。RMSで出荷作業に使いやすい標準帳票は、受注明細票とお買い上げ明細書です。受注明細票は梱包や配送伝票記入、紙での確認に向いた注文単位の資料で、ピッキングの土台にはなりますが、商品別に複数注文を横断して束ねる集約ピッキングリストとは別物です。
受注明細票・お買い上げ明細書の使い分け
受注明細票は「この注文を確実に処理する」ための紙に近い帳票です。お買い上げ明細書は購入者への同封物として使う帳票で、倉庫内の移動順を最適化する用途とは少し違います。
| 帳票・リスト | 向いている使い方 | RMS標準での位置づけ |
|---|---|---|
| 受注明細票 | 梱包、伝票記入、紙での作業確認 | 注文単位の出荷補助 |
| お買い上げ明細書 | 商品同封、金額表示の案内 | 同封用帳票 |
| 集約ピッキングリスト | 同じ商品を複数注文分まとめて拾う | RMS標準では作り分けが必要 |
集約ピッキングリストが必要になる場面
集約ピッキングリストが必要になるのは、たとえば次のような場面です。
- 同じSKUを複数注文分まとめて拾いたい
- 倉庫の棚順に並べて移動距離を減らしたい
- ピッキングと検品を分けて管理したい
- 注文数が増えて、注文単位の紙だけでは追い切れない
この段階になると、RMSの帳票だけに頼るより、CSV整形や外部システムで横断集約するほうが扱いやすくなります。
RMSの受注処理のどの段階で使うか
ピッキングリストは、注文が入った瞬間に作るのではなく、発送待ちの注文を対象にするのが基本です。楽天側の決済処理と不正検知が終わると発送待ちに進むため、出荷対象を確定してから帳票を出す流れにすると、やり直しが減ります。発送完了報告CSVでも、発送待ち注文の発送日を登録し、配送会社と伝票番号がそろってから更新する流れが案内されています。
いつの注文を対象にするか
対象は、原則として発送待ちの注文です。見えている注文をそのまま全部出荷対象にすると、未決済や確認中の注文まで混ざってしまいます。
発送待ちになる前後で確認すること
発送待ちに入る前後では、少なくとも次を確認します。
- 決済が通っているか
- 与信や不正検知で止まっていないか
- 住所や配送条件に問題がないか
- 例外注文を通常出荷に混ぜていないか
発送情報の登録はいつ行うか
発送情報の登録は、発送日・配送会社・伝票番号が確定したあとです。ピッキングと発送情報登録は別工程なので、ここを一緒にしないことが重要です。
RMS単体で足りるか、外部ツールが必要か
RMS単体で回しやすいのは、件数が少なく、注文単位の帳票を見ながら手作業で出荷できる店舗です。逆に、複数注文をまとめたい、例外注文を止めたい、検品まで一気通貫にしたいなら、OMSやWMSを入れたほうが安定します。WMSとOMSの役割分担は、WMSとOMSの違いとは？管理範囲と連携のメリットを解説 や WMS・OMS・TMSの違いとは？受注から配送までの役割と連携 で整理できます。通販でWMSが必要になる場面は、通販にWMSは必要？EC物流の課題を解決する機能と選び方 も参考になります。
| 運用 | 向いている店舗 | つまずきやすい場面 |
|---|---|---|
| RMS単体 | 注文数が少なく、注文ごとに出荷確認できる | 集約、検品、例外分岐が増えると重い |
| CSV整形 | 受注データを並べ替えたい、半自動化したい | 再投入や列ずれの確認が甘いと危険 |
| OMS/WMS | 例外分岐、バーコード検品、複数倉庫管理が必要 | 最初の設計を詰めないと運用が崩れる |
RMS単体で完結できる範囲
RMS単体では、発送待ちの注文に対して帳票を出し、目視でピッキングするところまでは回せます。小規模運用なら十分です。ただし、棚番順の最適化や同一商品の横断集約、検品の履歴化まで求めると、RMSだけでは不足しやすくなります。
どんな場合にOMSやピッキング用ソフトが必要か
次のどれかに当てはまるなら、OMSやピッキング用ソフトを検討したほうがいいです。
- 注文数が増えて、注文単位の紙では追い切れない
- 同じSKUを複数注文分まとめて拾いたい
- 住所不備や備考付き注文を自動で止めたい
- 検品やバーコード照合を入れたい
- 複数店舗の注文を同じ流れで処理したい
外部ツールを入れると何が改善するか
外部ツールを入れると、単に作業が楽になるだけではありません。作業の順番がそろう、止める注文が明確になる、二重処理を防ぎやすいという利点があります。倉庫側の連携では、バーコード付きピッキングリストとハンディターミナルで商品・数量を照合する形もあります。
CSVや受注データからピッキングリストを作る方法
RMS標準で集約しきれないなら、受注CSVを元に自分で整えるのが現実的です。RMSの受注データダウンロードは申込後に使える無料サービスで、文字コードはShift-JISです。商品CSV一括編集とは別のサービスなので、そこは分けて考えます。
CSVで何を整形するか
実務では、受注番号を軸にした一覧を作るのが安全です。そのうえで、出荷作業に必要な情報を並べます。
- 受注番号
- 商品名またはSKU
- 数量
- 配送先
- 保留対象かどうか
- 住所確認や配達条件の有無
どの列を必須に見るべきか
少なくとも次の3点は外さないほうが安全です。
- 注文を一意に識別できる列
- 何をいくつ取るか分かる列
- 出荷してよいか判断できる列
この3つがそろうと、商品名だけの簡易表より事故が起きにくくなります。
テストしてから本番投入する理由
CSV運用は、最初に少数件で試すべきです。1件だけのテストで、列のずれ、文字化け、桁落ち、エラーの出方を確認してから本番に広げるほうが、やり直しのコストが小さいからです。
例外注文をどう扱うか
例外注文は、ピッキングリストに載せる前に通常出荷と分けるのが基本です。住所不備や備考欄ありの注文を通常の出荷リストに混ぜると、あとで止めるのが難しくなります。配達希望日がある注文も、早出しすると保管期限や受け取り条件で問題になります。
住所不備や備考欄あり注文をどう分けるか
住所不備や備考あり注文は、通常出荷のリストから外して確認待ちに回します。OMSでは[確認待ち]のように人の判断が必要な状態へ分けられるため、RMS単体より止めやすくなります。
配達希望日がある注文をどう止めるか
配達希望日がある注文は、希望日に間に合う時点まで保留します。急いで出荷してしまうと、早すぎる到着や保管期限切れにつながるためです。OMS側では[印刷日待ち]のように、希望出荷日まで保留する運用も取れます。
確認が必要な注文を誰が判断するか
判断役は、作成者とは別に置くのが理想です。作成者がそのまま出荷すると、見落としに気づきにくくなります。少なくとも、作る人・確認する人・出荷する人の3役を分けておくと安定します。
ピッキングリスト運用のチェック体制
ピッキングリストは、作るだけでは意味がありません。誰が作り、誰が確認し、どの単位で試し、どう戻すかまで決めておくと、誤配送や二重処理を防ぎやすくなります。
誰が作成し誰が確認するのか
作成担当と確認担当は分けるのが基本です。CSV整形や外部連携を入れる場合は、入力ミスと確認漏れが別々に起きるので、同じ人が全部見る体制は危険です。
テストはどの単位で行うか
初回は1件〜少数件で十分です。いきなり全件で回すより、少ない件数で出力結果と処理結果を照らし合わせたほうが、安全に本番へ進めます。
誤配送や二重処理をどう防ぐか
防ぎ方の軸は3つです。
- 例外注文を通常リストに混ぜない
- CSVや帳票の再投入ルールを決める
- 発送情報の更新とピッキング作業を分ける
この3つを押さえるだけでも、現場の混乱はかなり減ります。
まとめ
楽天RMSでピッキングリストを考えるなら、標準で使いやすいのは注文単位の受注明細票で、商品別に複数注文を束ねる集約ピッキングリストはRMS標準だけでは作りにくい、というのが結論です。発送待ちの注文を対象にし、件数が増えるならCSV整形やOMS/WMSへ広げるのが現実的です。例外注文は通常リストから外し、作成・確認・出荷を分けて運用すると、ミスを減らしやすくなります。