製造業の出荷積込照合システム導入｜便・荷姿ID・出発ゲートの設計

製造業で出荷積込照合システムを導入するとき、確認すべき対象は「出荷指示と製品が合うか」だけではありません。梱包を終えた正しい荷物でも、違う車両や便へ積めば誤納品になります。ドックに複数の便が並び、混載、分納、積み残し、直前の便変更がある現場では、荷姿ID・出荷指示・車両／便・実際の積込動作を同じ取引として記録する必要があります。本稿は、タイの製造拠点を想定し、バーコード照合の設計から例外処理、ERP・WMS・TMS連携、RFPと受入試験までを具体化します。費用や効果の一律の数値は、現場の便数、荷姿、既存システムによって変わるため提示しません。

まず区別する：出荷検品と積込照合はどこが違うか

ピッキング検品は、指示された品目・ロット・数量を棚から取ったかを確認します。梱包検品は、箱やパレットの中身が注文と一致するかを固定します。出荷検品は、出荷可能な品質状態や伝票との一致を確認します。これらが完了していても、ドックでA便のパレットをB便のトラックに載せる事故は止まりません。積込照合の固有の判断は「この荷姿を、いま、このドアに着けた、この車両の、この便に載せてよいか」です。

従来の入出荷検品の設計は入出荷検品システムの記事で扱っています。そこで作った箱IDと検品完了状態を、積込時の入力として利用できます。一方、誤出荷防止の関門設計を積込工程に当てはめると、最後の関門は伝票発行ではなく、現物が車体へ移る瞬間と出発許可です。

積込照合を新規に導入するなら、既存WMSに「出荷完了」という状態があるだけで十分と判断してはいけません。その状態が梱包完了、倉庫からの払出、ドックへの搬送、実際の積込、出発のどの時点を指すのかを調べます。名称が同じでも会社やシステムで意味が異なります。

GS1と主要WMSの一次資料から読み取れる設計原則

GS1の物流ラベルガイドラインは、物流単位をSSCCで識別し、積み込んだパレットをスキャンして出荷通知と実態を合わせる流れを示しています。これは「予定のパレットを全部スキャンする」のではなく、本当に載せたものを積込事実として記録するという設計上の基準になります。同じ資料は、ASNに物流単位のSSCCと内容を含めることも述べています。SSCCの採用は取引先要件やラベル体系によりますが、一意の荷姿IDと内容のひも付けは自社内でも必要です。

GS1のEPCIS 2.0ガイドラインは、業務上の出来事を時刻や場所とともに表すイベントの考え方を示します。本稿の「積込」「積戻し」「出発」は、この考え方を社内イベント設計へ応用した提案です。EPCISへの完全準拠や外部交換を、すべての導入に必須と主張するものではありません。

SAP EWMの輸送単位への積込には、輸送単位とドアを基準に予定・積込済みのHandling Unitを扱い、積込の取消しや輸送単位のクローズを行う運用が記されています。Immediate Loadingは、出荷単位が梱包済みなら一部を先に積む処理も説明します。Oracle WMSのOBLPN積込も、積込先のload／trailer番号と荷姿を扱います。これらは特定製品の採用を勧める根拠ではなく、RFPで確認すべき「便・車両・荷姿・取消・完了」の論点を具体化する参考です。

照合の最小単位を「品目」ではなく荷姿IDにする

積込でSKUだけを読んでも、同じSKUを載せる複数の客先や便を区別できません。ロットだけでも同じロットの分納を区別できません。現物の箱、パレット、通い箱、コンテナに一意の荷姿IDを付け、そこへ中身、出荷指示、数量、ロット、品質状態をひも付けます。パレットを丸ごと積むときはパレットIDを読み、その下に属する箱IDの一覧を確定させます。箱を抜く・追加する場合は、親子関係を更新してから積込結果を計算し直します。

ラベルに全データを印刷する必要はありません。ラベルは識別キーであり、最新の内容や出荷先はシステムの記録から引きます。ラベルを刷り直しても、同じキーを再利用するのか、新しいキーを発行して旧キーを無効化するのかを決めておきます。同じIDのラベルが2枚生きている状態は、代理スキャンや二重積込を見逃す原因になります。

荷姿IDは社内採番でも始められます。取引先や物流事業者と単位レベルで情報交換するなら、GS1 SSCCの適合性を確認します。GS1の説明によれば、物流ラベルで必須となる識別情報は物流単位ごとの一意のSSCCです。現行の自社ラベルを一斉に変えるより、外部交換要件、読取設備、発行責任を先に決める方が実務的です。

この表の「正本」は導入前に関係部署で合意します。複数システムが同じ便IDを発行したり、WMSとTMSのどちらが便変更を確定するか曖昧だったりすると、現場のスキャンが正しくても判定結果が揺れます。

ドックでの標準フロー：便を開く、積む、閉じる

1. 車両・便・ドアの組み合わせを確定する

配車計画にある「車両番号」を確認するだけでは足りません。同じ車両が同日複数便を走る、牽引車とトレーラーが入れ替わる、同じドアを次の便が使う状況があります。便IDを主キーにし、車両またはトレーラーID、ドアID、予定出荷指示、予定荷姿を関連付けます。作業員はドア側のコードを読み、端末に便の行先、車両、積込予定件数を表示させます。車両の物理確認を別担当が行う場合、その確認者と時刻も記録します。

2. 現物ラベルを車体に入れる直前に読む

ステージングエリアで一括スキャンすると、スキャン後に他便へ移した荷物を検出できません。読み取る位置は、荷物がドア境界を越える直前、またはフォークリフトが車体へ入る直前に置きます。端末には、読み取ったIDが現在の便へ割り当てられているか、品質HOLDがないか、同じ荷姿がすでに積込済みでないかを判定させます。判定がOKでも、作業員が読取だけして荷物を載せなかった場合は記録と現実が食い違います。リスクが高い出荷では、車体内の受け手による確認、ドアカメラ、フォークリフトの通過検知などを追加するかを評価します。ただしセンサーを足す前に、読取位置と積戻しの運用を固めるべきです。

3. 積戻し・便変更は逆イベントで扱う

荷物を降ろしたときに積込記録を削除すると、何が起きたか追えなくなります。「積込」「積戻し」「再積込」の各イベントを時刻と操作者付きで残し、現在状態をイベントから計算します。便変更なら、元便から積戻し、新便へ割当変更、変更承認、新便での再積込という順番を定義します。元の便が出発済みなら通常操作では戻せないようにし、訂正伝票や輸送側の処理に移します。取消を許す範囲と締切は、現場だけで決めず、経理・営業・物流とも合意します。

4. 出発ゲートで「予定」と「実績」を突き合わせる

出発承認画面は、予定荷姿の未積込、予定外の積込、積戻し後の再積込漏れ、品質HOLD、便変更未承認、ラベル重複を別々に表示します。「合計件数が同じ」だけで通さないことが重要です。Aの積み残し1件とBの余分な積込1件は件数上は相殺されるためです。例外が一件でも残れば原則として便を閉じず、現物を確認します。顧客合意のある分納など、業務上許容する差分だけを、理由・承認者・対象荷姿・後続処理付きで通します。出発時刻、車両、運転者確認、便の実績一覧を固定し、出荷通知や輸送指示へ渡します。

車両・便別積込検品で止めるべき例外

例外設計がない積込システムは、繁忙時に「管理者解除」で素通りする運用へ傾きます。全件を画面に赤く表示するだけでなく、作業継続可能なケース、現物確認が必要なケース、出発を禁じるケースを分けます。判定と承認権限は、顧客との契約、品質規程、現場の責任分界に合わせて決めます。

オフライン時には、端末で「OK」と見えたことと、サーバーで確定したことを区別します。別端末が同じ荷姿を読んだり、便が変更されたりする可能性があるため、同期前の状態を出発可能にしてはいけません。イベントID、端末ID、連番を使い、再送で二重計上しない設計にします。電波の弱いドックがあるなら、無線調査とオフラインからの復旧試験をRFPの範囲に含めます。

重量照合だけではなぜ積込ミスを防げないか

トラックスケールやパレット重量は有用な補助証拠です。総重量の大きな差や、パレット単位の欠品を見つけることがあります。しかし同程度の重量の別品番や別客先の荷物を入れ替えたとき、重量だけでは識別できません。水分、梱包材、計測条件によるばらつきもあります。重量照合は「荷姿IDと便の一致」を代替するものではなく、追加の異常検知として位置付けます。重量を使うなら、理論重量の正本、許容差の根拠、秤の校正、再計量時の処理を別に設計します。

同様に、車両のナンバープレート認識だけでは荷姿の誤積込を止められません。車両が正しくても載せた荷物が違うためです。RFIDゲートも、タグを一括読取できる一方で隣接ドックや車体外の荷物を拾う条件があります。まずバーコードで正しい照合キーとゲート条件を検証し、処理量や作業姿勢が課題になった時点で自動読取の適用を評価します。どの方式でも「読めた＝載った」と短絡せず、実際の動作との対応を現場で検証します。

ERP・WMS・TMSの境界を決める

ERPには受注、出荷指示、売上や在庫の会計処理があります。WMSには荷姿、場所、ピッキング、梱包、積込の現場状態があります。TMSには車両、運送会社、便、配送先、ルートの計画と実績があります。ただし各社の導入範囲は異なるため、名称だけで責任を割り振らず、データ項目ごとに正本・更新権限・受渡時点を表にします。

典型的には、ERPの出荷指示がWMSへ渡り、WMSが荷姿IDと内容を確定し、TMSまたは配車側が便を決めます。積込照合は三者の確定済み情報を結合して判定し、積込実績と例外を返します。出発後にERPへ出荷確定を返すか、積込完了時点で返すかは在庫引落と売上計上のルールに影響します。ここは経理と物流の共同判断にします。取引先へのASNをいつ送るかも同じ境界の問題です。GS1の物流ラベルガイドラインは、積込と出荷通知の一致を重視していますが、実際の送信タイミングは契約とシステム条件で決めます。

連携は「APIがある」だけでは完成しません。便変更が出発直前に起きたとき、更新イベントの順序が前後しても正しく再判定できるかを試します。WMSから先に荷姿の内容訂正が届き、ERPの出荷指示改訂が遅れる場合には、安全側で積込を止めるのか、承認済みの一時状態を許すのかを決めます。マスタの照合にはコード変換表が必要なこともあります。顧客名の表示だけに頼らず、会社コード・納品先コード・出荷指示行を追跡できるようにします。

RFPに書くべき要求：機能名より試験可能な動作

「バーコードで積込検品できる」「ERPと連携できる」という一文では、各社の提案が比較できません。RFPには現行の便数やドック数を自社実測値として載せ、標準の流れと例外を要求します。次の表はそのまま要求項目のたたき台にできます。数字が必要な性能項目には、既存現場のピーク時間帯で測った値を入れます。

RFPには「標準機能」「設定」「追加開発」「外部製品」「運用で補う」を分けて回答させます。画面のデモだけでなく、サンプルデータ、API仕様、イベントの履歴、権限設定、障害時のログを提出物に含めます。取引先ラベルを使うなら、実物のラベル品質と読取距離で試験します。ラベルの再発行や部分パレットの扱いが頻繁なら、そこを代表ケースにします。

FATとSATで何を通すか

FATはベンダー環境で、業務ルールと連携の期待結果を固定する試験です。SATは実ドック、実車両、実端末、実ネットワークでの受入試験です。FATで正常系が動いても、トラックの位置、夕方の照明、ラベルの擦れ、無線の弱いドア、フォークリフトの動線によってSATの結果は変わります。

試験表には、入力条件、操作、期待される画面、DBイベント、外部システムへの通知、解除権限を一行ずつ記します。最低限、正しい積込、別便の混入、同じIDの二度読取、積戻し、便変更、品質HOLD、部分出荷、ラベル再発行、ネット断、再同期、端末時刻ずれ、出発後の訂正を含めます。出発ゲートでは、予定と実績の件数だけが一致し中身が違う「相殺ケース」を必ず入れます。これは見た目の総数チェックでは発見できないためです。

合否は「警告が出たか」だけで判定しません。誤った積込を止めたか、権限のない人が解除できなかったか、正しい訂正が残ったか、ERP／WMS／TMSの状態が最終的に一致したかまで確認します。導入後に現場が手動解除を常用しないよう、例外理由の件数を定期的に見て、ルールやマスタの問題を直す運用も決めます。

稼働後の引継ぎと監査記録を設計する

積込は一つのシフトだけで完結するとは限りません。前のシフトがドックで待機させた荷姿を、次のシフトが積むことがあります。引継ぎ画面には、便ごとの「未着手」「積込中」「積戻し待ち」「確認待ち」「出発可」を、荷姿ID単位の理由とともに表示します。単に担当者名を変えるだけでは、前任者がなぜ止めたか伝わりません。例外に対しては、発見者、最終確認者、期限、次の処置を持たせ、出発まで未解決のまま消せないようにします。

運送会社が変わるときは、車両と運転者の情報を誰がいつ確定するかが重要です。門での受付、ドアへの接車、積込開始、シール装着、出発許可を別イベントにしておくと、車両変更がどの段階で起きたか追えます。ただし監視のために項目を増やしすぎると、入力が作業の妨げになります。最初は誤積込の防止と証拠に直結する項目を必須とし、補助項目は自動取得か任意入力に分けます。シール番号を使う運用なら、番号だけでなく装着者と装着時刻を結び、破損・交換時の履歴を残します。

顧客から「この箱はどの車両で、いつ出たか」と問い合わせを受けたときは、荷姿IDから箱の中身、出荷指示、積込・積戻しの履歴、最終便、車両、出発時刻へ一画面でたどれることを目標にします。反対に、便IDから全荷姿と未積込の差分を逆引きできることも必要です。閲覧権限と保存期間は取引先契約や社内規程に合わせて決め、個人名や画像を無制限に保持しないようにします。操作ログの修正履歴は上書きせず、訂正した理由と新旧の値を残します。

現場の指標は、出荷件数だけで評価しません。便の出発前に見つけた別便スキャン、未積込の発見、出発保留を解除した理由、ラベル再発行、オフライン復旧の所要時間を継続して確認します。これらの増減には二つの解釈があります。初期には、これまで見えなかった例外が記録されて件数が増える場合があります。その段階で単純に「悪化」と判定せず、発見位置が出発前へ移ったか、未解決のまま出た案件が減ったかを見ます。一方、解除件数が高止まりするなら、現場の不注意と決めつけず、便計画の更新遅れ、ラベル発行の間違い、端末応答、権限設計を調べます。

システム停止時の暫定運用も本番前に決めます。紙のチェック表へ戻す場合、便ID、車両、荷姿ID、読取不能の理由、確認者、時刻を記録し、復旧後に誰がどの順で入力するかを定義します。復旧後の入力を通常のリアルタイム積込と区別し、遡及登録であることが分かるフラグを付けます。停止中に便を出す条件は、品質・物流・管理者が承認した手順に限定します。模擬停止をSATで一度行い、復旧後に二重計上や積込漏れが発生しないことまで確認しておくと、端末が使えない日に現場が独自の抜け道を作る危険を減らせます。

便の切替時に前便の状態を残さない

同じドアに次の車両が接車すると、端末が前便を表示したままでも、見た目には正常なスキャンが続くことがあります。ドア単位の端末では、便を閉じたあとに画面をロックし、次の便IDと車両IDを読み直す操作を必須にします。前便の未同期イベントが残っていたら、新便を開く前に同期または隔離して調査します。端末を作業員が持ち歩く運用では、ドア移動のたびに現在のドアを再確認し、一定時間操作がないときは便選択に戻す設計が有効です。自動タイムアウトの時間は現場観察で決め、作業中に頻繁に戻ってしまう設定を避けます。

複数ドアで同じ便を同時に積む場合もあります。この場合、一方のドアで読んだ荷姿をもう一方が再度読んだとき、サーバーは同じ便でも重複積込として止める必要があります。片方の端末だけに進捗を表示する設計では、もう片方が残数を誤解します。ドア横断のリアルタイム進捗と、通信が途絶えた端末の状態を区別して示します。便とドアの関係を固定できない現場では、便IDを主キーにして複数ドアの積込イベントを束ね、積込先の車両が同じかを別途検査します。

混載便では、一つの車両に複数顧客の荷物が載ります。「この車両に属するか」だけでなく、立寄先と荷下ろし順序まで見る必要があるかを運送会社と決めます。順序までシステムで制御するなら、奥に積む荷物と手前に積む荷物のルール、重量物や危険物の配置制限、途中で荷を降ろした後の残荷確認を別要件として定義します。本稿の基本設計は荷姿と便の一致であり、車内の積付け最適化まで自動的に保証するものではありません。機能範囲を分けて見積もることで、積込誤り防止の導入が過大なプロジェクトになるのを避けられます。

荷姿の分割・統合を「ラベル操作」で終わらせない

急な欠品や荷崩れで、パレットを崩して箱を別パレットへ載せ替えることがあります。現場では古いラベルを剥がして新しいラベルを貼るだけで済ませがちですが、それではデータ上の親子関係が古いままです。親パレットから子箱を外す操作、新しい親パレットへ子箱を追加する操作、それぞれの有効時刻を持たせます。旧パレットIDを読んだときは、取り外した子箱が積込対象に含まれないようにします。梱包内の数量が変わったら、出荷指示の残数と品質判定の影響も再確認します。

通い箱を使う場合、箱そのものの資産IDと、その時点の中身の荷姿IDを混同しないようにします。空箱が戻ってきて次の製品に再利用されても、過去の出荷証拠が新しい中身へ書き換わらない構造が必要です。一つの箱IDを連続利用するなら、充填回や出荷回の識別子を追加し、いつの中身かを区別します。これは取引先から後日にロット照会が来たときに特に重要です。箱IDだけで検索して複数回の出荷が混ざると、正しい車両を特定できません。

外部から受け取ったラベルが読めない場合、作業員がキーボードで適当な品番を入れて通す運用は避けます。読み取れない原因が印字品質なのか、取引先コードの未登録なのか、物理的な破損なのかを分けます。再発行時には現物と元伝票を照合する二者確認を設定できるか検討します。ただし全ケースで二者確認を要求すると処理が詰まる可能性があるため、顧客要求と出荷リスクに応じた閾値を決めます。手入力を認めるなら、その入力を通常スキャンと区別し、後日分析できるようにします。

イベントデータは「現在値」と「履歴」の両方を持つ

運用画面には「この荷姿はいまどの便に載っているか」という現在値が必要です。同時に、監査には「いつ、誰が、どのドアで、どの車両へ積み、その後なぜ降ろしたか」という履歴が必要です。現在値だけを上書きすると後者を失い、履歴だけを都度集計すると現場画面が遅くなることがあります。そこで、変更不可の積込イベント列を正本とし、現在状態をそのイベントから計算した表示用の値として持つ設計を検討します。両者が食い違った場合に再計算できることも受入条件に入れます。

イベントには、イベントID、荷姿ID、便ID、車両ID、ドアID、種別、端末ID、操作者、端末時刻、サーバー受信時刻、直前イベントへの参照、外部連携状態を含めると調査しやすくなります。ただし個人情報の保存範囲は必要最小限とし、実際の項目は社内規程で決めます。端末時刻とサーバー受信時刻を分けるのは、オフライン時にあとから同期されたイベントの順番を解釈するためです。時計がずれている端末から来た記録を、単純にタイムスタンプ順に並べて「先に出発した」と誤判定しないよう、端末内連番とサーバー側の確定順も扱います。

逆イベントは元のイベントIDを参照させます。たとえば一回の積込に対して二回の積戻しが届いたら、二回目を重複として拒否します。積込が未確定のまま積戻しが先に届いた場合は、受信順と業務順を分けて保留キューに置くか、端末へ再送を要求します。これらは頻繁に起こらなくても、電波の弱いドックで本番障害につながる境界条件です。画面の「成功」表示はサーバー確定後に出し、端末内だけの仮登録なら明確に違う表示にします。

部分出荷・顧客変更・出発後訂正を一つの手順に混ぜない

部分出荷は、予定の一部を積まずに便を出す判断です。顧客変更は、荷姿の納品先そのものを改訂する判断です。出発後訂正は、すでに動いた車両の実績を修正する判断です。いずれも「例外承認」ボタン一つで処理すると、誰が何に同意したか不明になります。部分出荷には残数と次便、顧客変更には改訂された受注・出荷指示、出発後訂正には輸送事業者との事実確認と訂正通知を必須条件として分けます。

顧客が急に納品先を変えても、作業員がドック端末だけで納品先を上書きできてはいけません。営業または受注側が指示を改訂し、その版がWMSと積込端末へ届いてから新しい便へ割り当てます。すでに積んだ荷姿があれば、積戻しイベントを経由します。この順番は手間に見えますが、出荷指示と現物の両方に改訂の証拠を残します。逆に、現物は積み直したのにシステム側だけ旧便という状態も防ぎます。

出発後に荷姿の積込記録が誤りと分かった場合は、元イベントを消して「出発前から正しかった」ように見せないことが重要です。誤記録を訂正するイベントを追加し、原因、発見時刻、車両の現在位置、顧客や運送会社への連絡、ASNや伝票の再発行要否を追います。監査で必要なのは最終的な正しい値だけでなく、誤りがいつ発見され、どの判断で是正されたかという経緯です。

現場の処理能力を測るときの注意点

端末一台あたりの読取速度だけを測っても、積込全体の能力は分かりません。車両の接車待ち、フォークリフトの往復、ラベルの向き、荷物を固定する作業、複数便の切替、エラー対応が流れを決めます。測定は、開始時刻を「車両がドアに着いた時」とするか「最初の荷姿を読んだ時」とするかを揃え、便ごとに荷姿数と混載の有無を併記します。例外がゼロの便だけで性能を評価すると、現場が本当に困る条件を見落とします。正常便と例外便を分けて、出発までの時間、作業員の待ち時間、再読取回数を比べます。

KPIの分母も固定します。「照合率」は予定荷姿に対する読取件数なのか、実際に積んだ荷姿に対するサーバー確定件数なのかで意味が変わります。前者だけでは予定外の積込を見逃し、後者だけでは積み残しを見逃します。そのため予定に対する未積込率、実績に対する予定外率、サーバー確定までの遅延を別々に見る方が、改善対象を特定しやすくなります。品質HOLDの出荷阻止や誤便スキャンの検知は、単なる作業遅延として扱わず、出発前に防いだ事象として記録します。

導入範囲と投資判断をどう組み立てるか

最初から全拠点・全便を対象にせず、誤積込の損失が大きく、荷姿IDを確実に付けられる便から始めます。対象ドックの実際の流れを観察し、便の切替、混載、分納、積み残し、顧客別ラベルを洗い出します。現状値として、便あたり荷姿数、ピーク時の積込時間、誤積込・積み残し件数、訂正工数、出発遅延を測ります。数値は自社データであり、記事中の架空の改善率を投資根拠にしません。

費用は、端末・ラベルプリンター・無線、ソフトウェア、ERP／WMS／TMS連携、マスタ整備、現場教育、保守の各項目で見積もります。SSCCや外部ASNを要求する取引先がいれば、その適合試験も含めます。導入効果は、誤積込の減少だけでなく、積込実績の追跡時間、出発前の差分確認時間、顧客問い合わせに対する証拠提示時間で評価できます。ただし事故件数が少ない便では、短期の「事故ゼロ」だけを成功指標にせず、全荷姿の照合率と未解決例外の残数も併せて見ます。

タイ拠点では、表示言語と現場用語を事前に確かめます。指示書の英語名称と現場のタイ語呼称が違っても、コードが一致すれば機械照合は可能ですが、警告時に人が判断できなければ解除が形骸化します。端末のエラー文は「不一致」だけで終わらせず、「この荷姿は別便です。ドアを確認して戻してください」のように次の操作を示します。日本側の監査担当には、同じイベントを日本語または英語の帳票で追えるようにします。

よくある質問

出荷積込のバーコード照合は、出荷検品があれば不要ですか？

出荷検品が積込先の便・車両まで現物単位で確認し、出発前の差分を止めているなら、別製品は不要な場合があります。ただし「出荷済み」状態が梱包や倉庫払出だけを意味するなら、積込先の誤りは残ります。既存システムのイベント定義と操作位置を確認してください。

車両・便別の積込検品では何を読ませますか？

まずドアまたは便を選び、次に現物の荷姿IDを車体へ入れる直前に読みます。車両IDは便とひも付けて物理確認します。SKUコードだけの読取では、同一品目の別顧客や別便を区別できません。混載パレットなら親パレットIDと子箱IDの関係を確定します。

荷姿IDと出荷指示の照合は、パレット単位で十分ですか？

パレットを崩さず運ぶなら、パレットIDで代表できます。ただし中身が変わった後も古い親子関係を使うと、正しく見える誤照合になります。部分抜取りや積替えがあるなら、その時点で子箱と親パレットの関係を更新する仕組みが要ります。

積込ミス防止システムは重量照合で代替できますか？

できません。重量は欠品や大きな差の補助検知に有効ですが、似た重量の別品や別便は区別できません。荷姿IDと便の一致を主判定にし、重量は追加の異常検知として使うのが妥当です。

出発直前の便変更や分納はどう扱いますか？

変更前の積込を消さずに積戻しイベントを残し、便の割当を承認付きで改訂し、新便へ再積込します。分納では未積込の荷姿、次便、顧客合意、出荷通知の更新を結びます。出発済みの便を通常権限で巻き戻さないようにします。

まとめ

製造業の出荷積込照合システム導入は、ハンディ端末の台数を決める作業から始まりません。荷姿IDを現物と結び、出荷指示と便・車両・ドアの関係を確定し、積込と積戻しをイベントとして残し、出発ゲートで予定と実績の差分を閉じる設計から始まります。バーコード、重量、RFID、カメラはその設計を実行・補強する手段です。RFPとFAT／SATでは、正常な積込よりも別便、便変更、積み残し、オフライン、出発後訂正を先に試すと、現場で使える仕組みか判断しやすくなります。

タイ工場の出荷ドックで「どの荷姿を、どの便の、どの車両へ載せたか」を追えるようにしたい段階なら、TOMAS TECHへご相談ください。現在の出荷指示、配車表、荷姿ラベルと積込手順を並べ、どこで記録が切れているか整理するところから相談できます。

参考資料

• GS1 Logistic Label Guideline, version 1.3 — SSCC、積込スキャン、ASNの関係。
• GS1 EPCIS and CBV 2.0 Guideline — イベントに時刻・場所・業務ステップを持たせる考え方。
• GS1: Logistic Labelの必須データ — 物流単位ごとの一意のSSCC。
• SAP Help: Loading of Transportation Units in Transit Warehouse — TU／ドア別のHU積込、取消、クローズ。
• SAP Help: Immediate Loading — HU単位での先行積込。
• Oracle WMS: Loading an OBLPN — load／trailerと荷姿の積込操作。