在庫管理システム×ハンディ連携｜取引の確定境界・ERP突合・受入条件

在庫管理システムとハンディ端末の連携仕様では、スキャンした値をどの在庫取引に変換し、どの時点で確定し、ERP/WMSの残数とどう突合するかを先に決めます。この記事の中心は、受入・移動・払出し・棚卸を並べた取引マトリクスと確定境界の設計です。ここが曖昧なままバーコードを読める画面だけを増やすと、二重計上、未送信のままの作業、ロット違いの払出し、棚卸差異の無断調整が起こります。タイの工場では、原材料の受入、倉庫から製造への払出し、工程間移動、完成品の出荷が複数言語のチームにまたがるため、画面の速さと同じくらい取引の意味をそろえることが重要です。

この記事は、一般的なハンディターミナル導入の全体像や在庫管理システムの選定・導入を読んだ後に、具体的な連携仕様を作る担当者向けです。受入、保管場所移動、ピッキング、循環棚卸を一つずつ取引として定義し、通信断と復旧、承認、ERPとの照合、RFPとFAT/SATの判定まで落とし込みます。端末メーカーや特定製品の価格を比較する記事ではありません。

先に決めるのは「スキャンした事実」と「在庫を動かす取引」の境界

スキャンは物理的なラベルを読み取った事実にすぎません。在庫が増減したことを示す確定取引とは別です。たとえば入荷品のラベルを読んでも、発注残の照合、数量確認、検査待ちへの振分けが済んでいなければ「使用可能在庫」として増やしてはいけません。逆に、確定済みの払出しをネットワークの再送で再度計上してもいけません。この二つを区別できる設計が、ハンディ連携の中心になります。

取引設計では、最低限「取引ID、取引種別、対象伝票、品目、数量と単位、ロットまたはシリアル、移動元と移動先、作業者、端末、発生時刻、サーバー受信時刻、承認状態、処理状態」を定義します。取引IDは端末で一度作り、再送しても変えない設計が有効です。サーバーは同じ取引IDを再受信しても二度目の在庫更新をしない。これは実装上の推奨設計であり、既存ERPの標準機能を意味しません。更新後にはサーバー側の確定番号を端末へ返し、現場画面に「未送信」「送信中」「確定」「要確認」を分けて見せます。

在庫の正本も決めます。WMSが現場数量の正本でERPへ仕訳・在庫移動を送る構成、ERP在庫が正本でハンディが直接そのAPIに取引を登録する構成、MESが工程内仕掛品を持つ構成では、同じスキャンでも責任が異なります。導入前に「どのシステムが、どの在庫状態の正本か」を図で示してください。二つのシステムが互いに在庫を加算する構成は避け、片側からもう片側への伝達結果と例外を追えるようにします。

業務別の取引を1枚のマトリクスにする

最初の成果物は端末の画面一覧ではなく、業務別取引マトリクスです。以下はタイ工場を想定した例です。実際の導入では品目の管理粒度、品質判定、会計締めのルールに合わせて調整します。

このマトリクスの「在庫を変える時点」が空欄だと、テストで何を確認すべきか決まりません。スキャン成功音を鳴らすことと、ERPの残数が変わることを同じ完了と呼ばないでください。入荷が品質検査待ちなら、物理的には工場にあるものの、生産へ引当て可能な残数ではない場合があります。帳簿上の総数、引当可能数、検査待ち数、保留数をそれぞれどう表現するかを先に合意します。

入荷受入：数量を足す前に「どの状態に置くか」を決める

入荷画面の最初の質問は「何個来たか」だけではありません。「どの発注または入荷予定に対応するか」「包装単位と管理単位の換算は正しいか」「検査を通るまで使えない品目か」を確認します。たとえば箱ラベルは1ケースでも、発注単位が個で、在庫単位がkgという構成なら、単位換算と端数処理を取引に残す必要があります。換算率を端末側に固定値として埋め込むと、マスタ改訂後の端末が古い計算を続ける恐れがあります。表示用の換算値、原単位、在庫単位、換算に使ったマスタ版をサーバーで管理し、作業者には確定前の数量を見せます。

同じ品目が複数ロットで届くときは、品目だけをまとめて受ける操作を避けます。ロット、期限、シリアル、搬送単位など、後工程の追跡に使う識別子を受入時に紐づけます。GS1のApplication Identifierはバーコード内のGTIN、ロット、期限などのデータ要素を区別する標準を定義しており、物流単位にはSSCCが使われます。ただし、自社でどの標準を採用するかは取引先ラベルと既存設備を調べてから決めます。ラベルの物理仕様は別論点であり、ここでは読み取った値をどの取引項目に入れるかに焦点を当てます。

端末の確認画面には「予定と一致」「不足・過納」「検査待ち」「ラベル再発行が必要」を分けて表示します。過納を現場判断で受けるのか、購買担当の承認後に受けるのかを決めます。未登録ロットを仮番号で受ける場合も、仮番号の発行者、紐づけ期限、利用禁止状態を残します。単にエラーを出して作業を止めると現場が紙へ戻り、後で二重入力が起こりやすくなるため、保留という正規の取引状態を用意することが実務的です。

棚入れ・移動：移動元と移動先の二点を読ませる

在庫管理システムでハンディを使う意味は、手書き転記を端末入力へ置き換えることだけではありません。作業者が実際に立つ棚と、運ぶ現品を、その場で照合できる点にあります。棚入れなら「受入済みの搬送単位を読む→移動先の棚を読む→搬送単位と棚の組み合わせを照合→完了」という短い流れにします。移動なら元棚と先棚の両方を確認します。候補棚が画面に表示されているからという理由で現場確認を省くと、誤置きが残ります。

ロケーションマスタには、倉庫、ゾーン、棚、用途、保管可能な品目・ロットの条件、品質状態、使用停止の有無を持たせます。ただし全項目をスキャン画面に並べる必要はありません。作業者には現在の行動を変える情報だけ見せます。たとえば「この棚は検査待ち専用」「異なるロットの混載不可」「移動先を再スキャン」といった具体的な指示です。Microsoft Dynamics 365 Supply Chain Managementの公式資料にも、モバイル作業でバッチ、シリアル、搬送単位、ロケーションの確認を構成できる例があります。これは設計上の参照であって、すべての製品が同じ挙動を標準で備えるという意味ではありません。

移動中の扱いも決めます。元棚を減らした後、先棚が未確定のまま通信が切れた場合、数量を「移動中」に置くのか、元棚に残しておくのか。どちらでも構いませんが、片側だけ更新したまま見えなくなる状態は避けます。搬送単位を単位として扱い、移動開始・完了を一つの業務取引として管理する方法が考えられます。途中で別の作業者がその現品を拾った場合は二重移動を拒否し、責任者が状況を確認できる保留キューへ送ります。

ピッキングと製造払出し：指示の確認順序が誤出庫を左右する

出荷向けピッキングと製造向け払出しは、見た目は「棚から取る」作業でも、その後の影響が違います。出荷では顧客・出荷指示と現品の一致、製造では製番・工程・BOM・投入ロットとの一致が必要です。端末には「指示→棚→現品→数量→確定」の順序を基本として、現品を先に読む自由入力が必要なら別の権限にします。指示番号を読み、指定棚に行き、棚ラベルと現品ラベルを読んで、要求数量と実績数量を比較する。これを完了前に画面へ出すだけで、どの条件で止めたかを記録しやすくなります。

不足・破損・別ロットへの変更は、単なる数量修正にしません。「不足数、原因、代替ロット、承認者、残指示の扱い」という例外取引として記録します。代替ロットを許すかどうかは顧客要求、品質ルール、期限管理、先入先出の方針で決まります。必要な品目だけ、ロット・シリアルを強制確認する構成にすれば、全作業に不要なスキャンを増やさずに済みます。端末画面はタイ語と日本語など実際の現場言語に合わせますが、マスタコードと取引IDは共通にし、翻訳文言を識別子代わりにしないでください。

作業が確定したら、WMS内の引当数量と実在庫をどう減らし、ERPやMESのどのイベントに送るかを定義します。「端末では完了なのにERPには翌朝まで反映されない」運用も設計上はあり得ますが、その場合は確定時刻と連携待ち時刻を別々に表示し、引当や再払出しが二重にならない条件を明示する必要があります。連携が非同期なら、端末の成功表示は「現場取引を受け付けた」であって「すべての下流システムに反映した」ではありません。

循環棚卸：カウント結果と調整仕訳を分離する

棚卸でよくある失敗は、ハンディで数えた数量をそのまま帳簿残へ上書きすることです。数え間違い、別棚の現品、移動中の在庫、未反映の出荷を調べる前に差額が消えてしまいます。棚卸取引は「計画またはスポット計数→数量記録→差異計算→再カウントまたは原因調査→承認→調整」という段階に分けます。Microsoftの循環棚卸資料でも、モバイル端末での計数後、差異をレビューして解決する流れが示されています。

計数画面では、期待数量を見せるか隠すかを方針として決めます。期待数量を見せると操作は速くなっても、数値に引きずられる可能性があります。高額・規制対象・差異の多い棚はブラインドカウント、通常棚は表示ありなど、対象によって分ける設計もあります。二人で数える場合は同じ棚を二度読んだ結果をどう比較するかを決めます。棚卸中に同じ棚からピッキングが行われるなら、棚を一時停止する、取引時刻で差し戻して残数を復元するなど、差異計算の基準時点を明確にします。

承認閾値は工場のリスクに合わせて設定し、数値自体はRFPで合意してください。「何個以上なら上長承認」のような全社共通値をこの記事で断定しません。必要なのは、差異を承認できる役割、承認の証跡、承認前の出庫可否、差異がERPに反映された時刻、会計締め後の修正手順です。棚卸結果がマイナス在庫を生む場合や品質保留ロットにかかる場合も、通常の差異と分けて扱います。

通信断への対処：オフラインは「動くか」より「再同期して壊れないか」

タイの工場には金属棚、建屋の境界、屋外搬送路など、無線が弱くなる場所があります。ただし「オフライン対応」という言葉だけでは要件になりません。機能ごとに、切断時に操作を許可するか、端末内へ何を保存するか、再接続時にどの順で送るか、サーバーが拒否したとき誰が直すかを決める必要があります。MicrosoftのField Serviceモバイルの公式資料は、オフライン用データ、同期状態、競合を別々に扱う設計例です。これは倉庫アプリが同じ機能を持つという証拠ではありません。導入候補の端末アプリで実機試験してください。

推奨する状態は「作業中」「端末内に保存済み・未送信」「サーバー受理済み」「ERP反映待ち」「例外保留」「確定」のように分けます。作業者が端末のチェックマークだけを見て作業完了と思わないよう、未送信件数を常時見せます。端末の電池切れやアプリ再起動後も未送信データが残ること、端末を紛失したとき業務データを保護できることも試験対象です。サーバー時刻と端末時刻は両方保存し、端末時計のずれで取引順を誤らないようにします。

再送の重複を防ぐには、端末が発行する一意の取引IDとサーバー側の冪等処理を設計します。同じID・同じ内容の再送なら元の結果を返す。内容が違う同じIDはエラーにする。順序に依存する移動や払出しは、単純に到着順で処理せず、対象の在庫版や作業指示の版を確認します。端末Aがオフライン中に端末Bが同じロットを消費した場合は、自動で負の残数にせず、責任者が選べる保留にします。AWSの公式資料にも、分散システムで再試行するAPIを一意のトークンで冪等にする設計原則が示されています。ここでの適用方法は当社の設計提案です。

ERP・MESとの連携は「いつ、何が正本か」を証拠で示す

システム間のインターフェース一覧には、マスタ連携と取引連携を分けます。品目、単位、倉庫、棚、ロット属性、取引先、BOM、作業者・権限はマスタです。入荷、移動、引当、払出し、出荷、棚卸差異は取引です。マスタ更新が遅れた場合のブロック方法、無効品目の表示、単位換算の版を決めないと、正しいスキャンでも誤った在庫が作れます。

取引のインターフェースには、送信元取引ID、送信時刻、対象システムの受付番号、状態、エラー内容、再送回数、最終成功時刻を残します。日次の残数照合だけでは、同じ額の誤りが相殺されて見えないことがあります。件数、数量、伝票単位、ロット単位で差異を調べられるようにします。たとえば「端末で受理10件、WMS確定9件、ERP受理8件」なら、1件の保留と1件の連携エラーが分かる一覧を用意します。この数字は説明用の例で、実績統計ではありません。

会計・税務上の在庫評価をハンディの数量更新で勝手に決めてはいけません。端末は現物確認と取引証跡を集め、評価方法と仕訳ルールはERP・会計側で承認された方針に従います。月末締めをまたぐ未送信取引がある場合、現場の発生時刻、サーバー確定時刻、会計計上日の違いをどう扱うかを財務担当と合意します。締め後の過去日付修正を現場画面だけで許可しないことも重要です。

データ項目を曖昧にしないための確認例

「品目コード」「ロット」「棚」という名前が同じでも、システムごとに意味や桁数が違うことがあります。ERPの品目コードと現場ラベルの品番が一対一でなければ、どの条件で変換するかを示します。仕入先品番が同じでも自社品目が複数ある場合は、バーコード一回で確定させず、発注番号や荷姿と合わせて候補を絞る必要があります。ロットも、仕入先ロット、自社受入ロット、製造ロットを区別します。どの番号を品質追跡や出荷証明に使うかを決めないと、スキャンできても後日検索できません。

棚コードについては、表示用の名称とシステム内部の識別子を分けます。棚の名称を変更しても過去取引が消えないように、内部IDを保持するためです。棚の廃止や用途変更があった場合、過去にその棚を通ったロットの履歴はそのまま検索できる必要があります。端末が古い棚マスタを保持しているなら、確定前にサーバー側の現在の使用可否を再確認するか、オフライン中の取引を保留へ送るかを決めます。

数量には単位だけでなく精度も必要です。整数で扱う品目と小数で扱う品目、重量の実測値と理論値、開封済みの残量は同じ計算式では扱えません。荷姿換算の結果をどの桁で丸めるか、端数をどこに残すか、複数回の払出しで端数が蓄積したとき誰が調整するかを仕様に書きます。マスタの欠落や換算不能を現場の自由入力で通すと、後から差異の原因を追いにくくなります。端末は必要な入力を短くしつつ、サーバーが根拠を検証できる項目を残すことが重要です。

インターフェースの障害を直す際は、「同じ取引を送信し直す」のか「元取引を取り消して訂正取引を作る」のかを分けます。確定済み取引の内容を裏で上書きすると、現場の作業記録とERPの仕訳が食い違います。訂正には元取引への参照、理由、承認者、訂正時刻を付ける。失敗した未確定取引の単純再送には同じ取引IDを使う。この区別を運用手順に書けば、障害時の電話連絡で「もう一回スキャンして」と安易に指示するリスクを下げられます。

取引の確定境界は、時刻だけでなく責任の境界でもあります。端末で「保存」を押した時点では作業者の入力責任が終わっても、在庫管理者がその数量を利用可能と認めたとは限りません。たとえば受入品を検査待ちに置く取引は、現物を預かった事実として確定できますが、生産に使える状態への変更は品質部門の判定を待ちます。出荷ピッキングも、棚から取り出した事実と、出荷確定で顧客向け在庫から引き落とす判断を分ける場合があります。そこで取引種別ごとに「現場入力完了」「業務承認」「在庫状態変更」「ERP受付」「会計反映」のうち、どの時点を作業完了として画面に表示するかを明記します。すべてを一つの緑色の完了表示で覆うと、作業者と管理者が別々の状態を同じ言葉で呼んでしまいます。

突合の例外一覧には、単に「エラー件数」を載せるだけでなく、原因別の次の担当者を示します。未送信なら端末と通信を確認する担当、サーバーが拒否したならマスタや指示を直す担当、WMSでは確定したがERPが拒否したなら連携と会計条件を確認する担当です。例外ごとに発生時刻、経過時間、元取引ID、対象品目・ロット、影響する数量、現場の作業継続可否、再送可能か訂正が必要かを並べます。保留を解除する際には、元の取引を再実行するのか、取消・訂正の新しい取引を作るのかを選ばせ、その選択を記録します。これにより、日次の残数が一致していても、未処理の伝票や誤ったロットが埋もれていないかを確認できます。現場、在庫管理、IT、経理の誰が解消を宣言するかも、例外の種類ごとに事前に決めておきます。

画面と権限は例外処理から逆算する

通常の入出庫は数画面で終わっても、現場で時間を使うのは例外です。読めないラベル、予定にない品目、別ロット、数量超過、使用停止棚、破損品、端末の共有、作業中の交代。これらを「管理者に電話して後で修正」だけで済ませると、なぜ在庫が変わったかを追えません。例外コードを短い選択肢にし、必要なときだけ写真・備考・承認を求めます。写真はすべての取引に強制するのではなく、破損やラベル不鮮明など証拠が必要な場合に限定します。

権限も操作単位で分けます。作業者は通常取引と保留登録、班長は一定の例外承認、在庫管理者は棚卸差異承認、システム管理者はマスタと再送管理、といった切り分けが例です。誰がマスタを変えたか、誰が差異を承認したかを同じ監査ログに残します。共有端末でも利用者識別が必要です。サインインの手間を減らすために全員共通アカウントへすると、証跡の意味が失われます。多言語表示は作業者の理解を助けますが、エラーコードや伝票番号の共通性を保ち、問い合わせ時に日本語画面とタイ語画面で同じ事象を指せるようにします。

RFPに書くべきものは機種表より「取引ごとの合格条件」

見積依頼には端末の台数、画面の言語、バーコード種類だけでなく、次の資料を添えます。第一に、受入・移動・払出し・棚卸の現行フローと改善後フロー。第二に、マスタと取引の項目一覧。第三に、各取引で在庫が変わる時点と正本システム。第四に、ネットワーク断と再同期の振る舞い。第五に、例外・承認・監査ログの条件。第六に、既存ERP、MES、ラベルプリンター、アクセスポイントとの境界です。

ベンダー回答には「標準」「設定で対応」「追加開発」「対象外」を業務要件ごとに示してもらい、デモ画面で確認したものと文書で約束されたものを混同しないようにします。クラウドサービスでもオンプレミスでも、工場の回線と業務停止時の手順は必要です。端末モデルの交換周期、予備機、バッテリー、MDM、OS更新、ラベル媒体の保守も費用範囲として明記します。費用の比較には初期費用だけでなく、接続開発、運用、改修、現場教育、機器交換を含めます。具体的な金額や回収期間は個別見積と実測が必要です。

FAT（工場受入試験）では、テスト環境のマスタと取引データを使い、仕様どおりに動くかを確認します。SAT（現地受入試験）では、実際の棚、ラベル、無線、作業者、既存システムと接続し、業務として成立するかを確認します。名前だけのFAT/SATにしないため、テストケースには初期在庫、操作手順、期待する端末表示、期待するWMS・ERP残数、監査ログ、合否判定をセットで書きます。

合格基準には、単に「エラーが出ない」ではなく、何件をどう照合するかまで書きます。たとえばパイロット対象の全取引を日次で端末・WMS・ERPの三層で照合し、未送信・未反映・重複がゼロか、例外が責任者へ割り当て済みかを確認します。このゼロという値は提案する受入基準であり、業界平均ではありません。無線品質や処理時間の数値は工場で基準を測って決めてください。

現地SATで見落としやすい三つの条件

第一は交代勤務です。日勤で始めた受入や棚卸の途中で夜勤に引き継ぐと、未完了の作業は誰の画面に残るでしょうか。共有端末をログアウトした後も取引が消えず、後任者は権限に応じて状態を確認できる必要があります。一方で、前任者の名前を後任者の操作履歴として書き換えてはいけません。作業開始者、引継ぎ者、確定者を区別できるかを実際のシフトで試します。

第二は現物とラベルの状態です。新品のきれいなラベルだけを試すと、現場で起きる読み取り失敗を見落とします。折れ、汚れ、曲面、保護フィルム、棚の高い位置など、実際にある条件を使います。ただし読み取り率の一般値を前提にせず、対象エリアとラベルごとに測定します。読めないときの手入力を許すなら、誤入力を防ぐ二重確認や権限、再印刷したラベルと元ラベルの関係も確認します。

第三は復旧後の整合です。アクセスポイントを止めてオフラインの取引をため、回線を戻し、一部だけ成功、一部はマスタ変更で拒否される状態を作ります。端末に成功と失敗が区別して出るか、管理者のキューに理由が見えるか、同じ取引を再送しても在庫が二重に動かないかを確認します。サーバー、WMS、ERPの時計がずれていても原因を追えるかを記録し、復旧手順を現場用とIT用に分けて渡します。SATの合格は、正常操作だけでなくこの復旧まで含めて判断するのが適切です。

小さく始めるなら「一つの倉庫、一つの取引鎖」を完結させる

PoCで一画面の読み取り速度だけを見ても、導入後の在庫精度は判断できません。たとえば一つの原材料倉庫と一つの製造ラインを選び、「入荷→棚入れ→製造払出し→残数照合→棚卸」を一周させます。現場で頻度の高い例外を少なくとも一つ、意図的に試します。入荷過納、別ロット、通信断、作業交代などです。端末台数を増やす判断は、通常取引が速いかだけでなく、例外が隠れず処理できるかを見てから行います。

導入初期には紙とシステムを並行運用することがあります。その場合も、どちらを正本にするか、いつ紙を廃止するか、二重入力を誰が照合するかを決めてください。紙を無期限に残すと、システム側の不備が修正されず、現場は慣れた手順に戻ります。定着指標は「スキャン件数」だけでなく、未送信件数、例外の解消時間、棚卸差異の原因特定率、ERP連携エラーの滞留時間など、取引が閉じているかを測る項目が有効です。値は現場の基準値を採ってから目標を定めます。

パイロットの終了判定も開始前に合意します。例外が起きたとき、班長が端末から保留内容を見つけられるか、在庫管理者が残数と取引履歴を再現できるか、IT担当が連携エラーの再送結果を確認できるかを役割別に試してください。現場の声を集める際は「使いやすいか」という総評だけでなく、何回タップしたか、どのラベルを読みにくかったか、どのエラー文が理解できなかったかを記録します。小さな作業負荷を放置すると、バーコードを読まずに後でまとめ入力する抜け道が生まれます。業務、端末、無線、ラベル、マスタのどこに原因があるかを分けて修正することが拡大前の条件です。

まとめ：ハンディ連携の見積前に確認する10項目

在庫管理システムとハンディ端末の連携は、機器をつなぐ作業ではなく、現場の確定取引を正確にシステムへ記録する設計です。①在庫の正本、②業務別の確定時点、③品目・単位・ロット、④元棚と先棚、⑤指示と実績、⑥オフライン時の保存と再送、⑦重複登録の防止、⑧例外と承認、⑨ERP・MESとの照合、⑩FAT/SATの合格条件を一枚の仕様にまとめれば、ベンダー提案を同じ基準で評価できます。既存のタイ拠点向け在庫管理の概要も、全体構想を整理する際に参照してください。

TOMAS TECHへのご相談：タイ工場で、ハンディ端末と在庫管理システムの接続範囲を決めたい、ERPとの二重計上を防ぎたい、現場の例外を含むRFPや受入試験を作りたい場合は、お問い合わせフォームから現行フローと使用中のシステムをお知らせください。対象工程を絞った取引マトリクスと検証項目の整理からご相談いただけます。

参考情報

• GS1：Application Identifiers — GTIN・ロット・期限などの識別項目。
• GS1：Global Traceability Standard — 識別粒度と追跡対象。
• GS1：Logistic Label Guideline — 物流単位とSSCC。
• Microsoft Learn：Batch, serial, license plate, and location confirmation — モバイル作業の照合例。
• Microsoft Learn：Cycle counting — 計数と差異レビューの流れ。
• Microsoft Learn：Configure offline data synchronization — Field Serviceにおけるオフライン同期の設計例。倉庫アプリの機能保証ではありません。
• AWS Well-Architected：Make mutating operations idempotent — 分散システムの再試行と冪等性。