JP2019006555A - 出入荷及び流通物品管理システム、管理サーバ、端末 - Google Patents

Abstract

【課題】 荷物運搬車両の待機時間の長期化を解消する管理システムを提供する。
【解決手段】 発倉庫拠点に用意され、発倉庫拠点側読み取り端末によって読み取られた荷物情報を表示する発倉庫拠点側端末と、着倉庫拠点に用意され、着倉庫拠点側読み取り端末によって読み取られた荷物情報を表示する着倉庫拠点側端末と、前記荷物情報の送信を受けて管理する情報管理サーバと、前記荷物を運搬する運搬車両に携行されて移動する運搬車両端末とを含む出入荷及び流通物品管理システムであって、前記情報管理サーバは、前記運搬車両に対する前記着倉庫拠点への着車案内情報を抽出する場合に、（１）前記情報管理サーバまたは着倉庫拠点端末上の在庫管理情報及び／又は受発注情報に照らした前記荷物の優先度、（２）前記荷物を搬入する際の適切な着バースがあるかどうか、のうちの少なくとも１つを判断して、前記着車案内情報を前記着倉庫拠点側端末上に提示する。
【選択図】 図５Ａ

Description

本発明は、広く荷物運搬用車両等に積載される荷物の出入荷等実績を管理する管理システムに関し、より具体的には、荷物運搬車両等と連携して流通物品等の管理をも可能とする管理システム等に関する。

従来、荷物運搬車両等による物流拠点間の運搬・納品においては、輸送・配送効率の向上やコストダウン等の工夫が重ねられてきた。例えば、トラックへの荷物の積卸し時の検品を自動化する検品装置等が提案されている（特許文献１）。

すなわち、特許文献１には、荷積み荷卸し口の周囲に、個々の荷物、パレット、ケースなどに貼付してある無線ＩＣタグの荷物情報を受信するアンテナを配設したトラックが荷積みや荷卸しのために集まってくる物流センターや倉庫などの荷物の集積場所に、無線通信コントローラを含む制御装置を配設し、来場した上記トラックのアンテナと無線通信コントローラとをケーブルによって接続可能にしたことを特徴とするトラックの積卸し時の検品装置が開示されている。

かかる装置等によれば、荷物に貼付された無線ＩＣタグからの情報をトラックの荷積み荷卸し口に配置したアンテナによって積み卸しするすべての荷物について検出して正誤を判断するようにしたので、荷物の積卸しの正誤等がその場で分かるようになり、誤配送、未配送、違う荷物の積み込みなどが皆無となり、輸配送の信頼性の向上が図れるとともに、輸配送の戻りがなくなることによる効率化とコストダウンが可能になるものとされている。

また、製品とともに流通する様々な種類のパレットに関するデータを正確に管理することができる流通物品管理システムも提案されている（特許文献２）。

すなわち、特許文献２には、物品の受け入れ側が所有し、物品の納入側に対する製品発注時の、荷姿指示により指定された流通物品の数量データを格納するデータベースと、物品の受け入れ側に設置され、物品の納入側から納入された、レンタル流通物品およびそれ以外の複数の流通物品を含む流通物品に関する、数量を含むデータを各々登録する登録装置と、前記データベースおよび登録装置とは通信回線を介して通信可能に構成され、前記データベースに格納された流通物品の数量データと、前記登録装置に登録された流通物品の数量データとを比較し、両者のデータが一致したときに、前記レンタル流通物品の数量をレンタルデータベースに確定させるとともに、流通物品に関する数量を含むデータを管理する流通物品管理装置とを備えたことを特徴とする流通物品管理システムが開示されている。

また、荷物の誤出荷防止及び荷物の出荷に伴うパレット等の個体管理を行うシステムも提案されている（特許文献３）。

すなわち、特許文献３には、フォークリフトの操縦者によって操作される端末装置と、フォークリフトに設けられる車載システムとを有する出荷管理システムが開示されており、車載システムは、パレット用タグ、荷物の包材に設けられる包材用タグ、及び包材に設けられる包材管理カードの包材管理タグを読み取る各読み取り部を備えている。そして、端末装置は、フォークリフトによる運搬車両への積荷作業時に、包材用タグ及び包材管理カードの各包材識別情報をマッチングする第１マッチング処理及び出荷指示書のコード情報に含まれる荷物識別情報と包材管理カードの荷物識別情報をマッチングする第２マッチング処理を遂行し、各マッチング処理がＯＫである場合、出荷指示書の出荷指示番号にパレット識別情報及び包材識別情報を関連付けた出荷管理情報を生成する。

特開２００５−３２０１２８号公報 特開２００６−２０６２８０号公報 特開２０１５−１２４０５２号公報

しかしながら、流通業界においては、なおも各物流拠点間の納品に関する課題を抱えている。その最たるものがトラックドライバーの待機時間の長時間化等である。この問題は流通系全体を巻き込んでさらなる問題へと発展しかねない。具体的には、次のとおりである。

一例として、日用品雑貨メーカーセンター（発倉庫）から卸売業センター（着倉庫）へ商品を納品する場合、着倉庫側の着バース（運搬車両を停車させて積卸し行うスペースである）の数が不足すると、たちまち納品待ちのトラックが滞留してドライバーの待機時間が長時間化する。特に、従前の運輸体系では、商品の納品緊急度（例えば、着倉庫において欠品商品が発生したなど）に関わらず、トラックを到着順に荷受けし、荷卸し後に入荷検品作業を行っていたため、着倉庫エリア内においても入荷仮置き作業場が常時渋滞することになる。

いったんかかる問題が発生してしまうと、ドライバーにあっては、納品待ち待機時間による配送生産性が低下し、トラック業者にあっては、滞留時間の発生によるコスト上昇が運賃等の値上げ要因ともなりかねない。さらには、配送受託を敬遠する要因をも発生させかねない。
さらに、着倉庫の近隣住民にとっては、着倉庫の周辺道路で納品順番待ちトラックが待機するために道路渋滞を招き、日常生活に対する障害にもなりかねない。

これらの課題は、次に述べるような従来の物流工程の諸段階ならびに全体における情報連携の不足が原因になっていることが考えられる。

図１２を参照して、従来の物流工程等の様子を示す。同図において、期間ｔ１２０１には物品の納品前夜の時間帯（での発倉庫の工程）があらわされており、期間ｔ１２０２には当該物品の納品当日（同図では例示的に午前中）の時間帯（での着倉庫の工程）があらわされている。

図１２の期間ｔ１２０１において、発倉庫での荷物のリスト化や検品などは基本的に手動で行われるか、上述の特許文献に開示されているような検品装置を使用した検品が行われる（工程１２１１）。
次に、検品が終わり、積み込みが完了した運搬車両は納品先（着倉庫）へ向けて出発し、配送工程に入る（工程１２１２）。このとき、上述の特許文献に開示されているように物品とともに流通するパレット等の情報が従前の管理システムにおいて管理される場合がある。

図１２の期間ｔ１２０２においては、基本的に着倉庫エリアへの到着順に着車の手配が行われ（工程１２２１）、運搬車両からの荷卸しが行われる（工程１２２２）。また、荷卸しされたパレットの仕分け（工程１２２３）や商品確認（工程１２２４）においては、従前の検査システムや管理システムによる検査や確認が行われる場合がある。こうして検品された商品（荷物）は所定の場所等に格納される（工程１２２５）。

つまり、以上のような従前の物流工程では、仮に工程の諸段階での検品等が行われたとしても工程全体における情報連携が必ずしも十分とまでは言えなかったため、予期せぬ事態（これは、往々にしてドライバーの待機時間の長期化に繋がるものである）に起因するトラブルに対し、柔軟に対応することが難しかった。

したがって、流通業界の各物流拠点間の運搬及び納品作業等において、物流工程の諸段階ならびに全体における情報連携を高めるとともに、トラックドライバーの待機時間の長期化解消の観点からのシステム改善が期待される。

そこで、本発明の一実施形態にかかる出入荷及び流通物品管理システム（以下、単に管理システムともいう）は、発倉庫拠点に用意され、前記発倉庫拠点から出荷される荷物に関する情報を取得する発倉庫拠点側読み取り端末と、前記発倉庫拠点側読み取り端末によって読み取られた情報を表示する発倉庫拠点側端末と、着倉庫拠点に用意され、前記着倉庫拠点へ入荷される荷物に関する情報を取得する着倉庫拠点側読み取り端末と、前記着倉庫拠点側読み取り端末によって読み取られた情報を表示する着倉庫拠点側端末と、前記発倉庫拠点側読み取り端末及び前記着倉庫拠点側読み取り端末から読み取られた情報の送信を受けて管理する情報管理サーバと、前記出荷及び入荷される前記荷物を運搬する運搬車両に携行されて移動する運搬車両端末とを含む出入荷及び流通物品管理システムであって、前記情報管理サーバは、前記運搬車両に対する前記着倉庫拠点への着車案内情報を抽出する場合に、（１）前記情報管理サーバまたは着倉庫拠点端末上の在庫管理情報及び／又は受発注情報に照らした前記荷物の優先度（一例として、前記荷物に欠品商品または品薄商品があるかどうかなど）、（２）前記荷物を搬入する際の適切な着バースがあるかどうか（一例として、前記荷物を搬入する際の近接着バースがあるかどうかなど）、のうちの少なくとも１つを判断して、前記着車案内情報を優先着車案内情報として前記着倉庫拠点側端末上に提示することを特徴とする。

本発明の一実施形態にかかる管理システム等によれば、流通業界の各物流拠点間の運搬及び納品作業等において、トラックドライバーの待機時間の長期化を解消し、例えば商品の納品緊急度の急な変更にも柔軟に対応できるという効果を奏する。

本発明の一実施形態にかかる管理システムの全体構成のバリエーション例を説明する説明図である。 本発明の一実施形態にかかる管理システムにおける情報処理装置の外観構成を説明する説明図である。 本発明の一実施形態にかかる管理システムにおける情報処理装置の機能ブロックを説明する説明図である。 本発明の一実施形態にかかる管理システムの制御動作シーンを概念的に説明する説明図である。 本発明の一実施形態にかかる管理システムの動作例を説明する説明図である。 本発明の一実施形態にかかる管理システムの他の動作例を説明する説明図である。 本発明の一実施形態にかかる管理システムにおける情報処理装置の画面例（出荷作業時）を説明する説明図である。 本発明の一実施形態にかかる管理システムにおける情報処理装置の他の画面例（出荷作業時）を説明する説明図である。 本発明の一実施形態にかかる管理システムにおける情報処理装置の他の画面例（入荷作業時）を説明する説明図である。 本発明の一実施形態にかかる管理システムの制御下での物流の様子を具体的なプレーヤーを想定して説明する説明図である。 本発明の一実施形態にかかる管理システムの制御下での着バース予約処理概念を説明する説明図である。 本発明の一実施形態にかかる管理システムの制御下での着バース予約処理時における情報処理装置の画面例に説明する説明図である。 本発明の一実施形態にかかる管理システムの詳細な動作例を説明するフローチャートである。 本発明の他の実施形態にかかる管理システムの動作概念を説明する説明図である。 従来の物流工程等の様子を説明する説明図である。

本発明の一実施形態にかかる管理システム等について、図面を参照しながら詳細に説明する。

図１に、本発明の一実施形態にかかる情報処理装置等を含む管理システムの全体構成例を示す。図１に示されるように、管理システム１０は、その大別的な構成として、情報管理サーバ１１と、コミュニケーションサーバ１１２と、各拠点に用意される情報端末（図において、例示的にＰＣ１２１、１３１が示されている。以下、これらの情報端末を「情報処理装置」ともいう）と、ドライバーに携行されるなどして荷物運搬車両１４と共に移動する情報端末（図において、例示的にタブレット端末１５が示されている。以下、この情報端末を「情報処理装置」あるいは「端末」とも言う）とで構成されている。

そして、同図において、例示的に、ＰＣ１２１は発倉庫１２に設置され、ＰＣ１３１は着倉庫１３に設置されている。また、発倉庫１２に設置されたＰＣ１２１には、倉庫エリアから積み込まれるパレットや荷物１２３の情報を読み取るためのハンディターミナル（以下、読み取り端末、あるいは、単にＨＴともいう）１２２ａ及びＨＴ１２２ａを載置してデータの授受や充電等を行うためのクレードル１２２ｂが接続されている。同様に、着倉庫１３に設置されたＰＣ１３１には、倉庫エリアから積み下ろされるパレットや荷物１３３の情報を読み取るためのＨＴ１３２ａ及びＨＴ１３２ａを載置してデータの授受や充電等を行うためのクレードル１３２ｂが接続されている。
なお、クレードル１２２ｂ、１３２ｂは必ずしも必須のデバイスではなく、ＨＴとＰＣとが他の有線／無線接続手段によって接続される場合には省略することもできる。また、ＨＴから直接ネットワーク１９へ乗り入れてサーバとの間で種々のデータの授受を行わせることもできる。

また、サーバ１１、１１２及び各種端末間は、図１に示されるように専用回線やインターネット等の公衆回線（有線の回線として、１６、１７、１８ａ、１８ｂ、１９）で相互に通信可能に接続されている。また、回線は有線であっても無線であってもよく、無線の場合、例えば、タブレット端末１５は、無線で図示しない基地局や無線ルータ等を介してインターネット１９に乗り入れ、更に回線１８ｂを介してコミュニケーションサーバ１１２と相互に通信可能に接続されても良い（他の端末や情報処理装置における通信についても同様である）。
なお、本発明の一実施形態にかかる管理システム１０においては、情報管理サーバ１１とコミュニケーションサーバ１１２とを区別して記載したが本発明はこれに限定されるものではなく、１つのサーバで制御管理しても良く、さらに複数のサーバ群によって有機的に制御管理させることとしても良い。

また、本願の出願時点での携帯電話や携帯情報端末ないしタブレットは、ＰＣに比肩する処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコンピュータとも言うべきものである。

また、本発明の実施に必要なプログラムないしソフトウェアは、通常、携帯情報端末やＰＣの記憶部におけるＨＤＤないしＳＳＤ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。

また、演算実行は必ずＣＰＵ等の中央処理部で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

また、情報管理サーバ１１やコミュニケーションサーバ１１２のハードウェア構成も、基本的にはＰＣを採用することができる。なお、本発明はこれに限定されるものではないが、サーバ１１、１１２は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣを並列的に作動させることによって大規模データの処理に適した構成をとることもできる。

なお、図１において、本発明の一実施形態にかかるＨＴ端末１２２ａ、１３２ａは、ＲＦＩＤチップ等のＩＤチップ等を読み取り可能に構成され、及び／又は、バーコードやＱＲコード（登録商標）等の２次元コードが表示された紙媒体等から荷物等に関する情報を読み取り可能に構成される。
さらに、ＨＴ端末１２２ａ、１３２ａは、これらに限定されるものではないが、他の入力手段（一例として、テンキーなどを含むキーボード手段、ディスプレイ部へのタッチを検知可能なポインティング手段）を備えることもできる。

図２に、本発明の一実施形態にかかる管理システムにおける情報処理装置としてのタブレット端末の外観構成を示す。図２において、情報処理装置（タブレット端末）２０１は、筐体部２０１１とディスプレイ２０１２と筐体２０１１の下部中央部に設けられたハードウェアボタン２０１３とからなる。ディスプレイ２０１２は典型的には液晶ディスプレイ（ＬＣＤ）等で構成され、文字や画像など様々な情報を表示することができる。また、ディスプレイ２０１２にメニューボタンやソフトウェアキーボードを表示させ、これを指ないしタッチペン（不図示）等で触れることによりタブレット端末２０１への指示（コマンド）とすることができる。この点で上記ハードウェアボタン２０１３は必須の構成要素ではないが、本発明の説明の便宜上、一定の機能を担うボタンとして実装されている。もちろん、これらハードウェアボタン２０１３を、ディスプレイ２０１２の一部に表示させたメニューボタンで代替させることも可能である。

また、ディスプレイ２０１２には、マルチタッチ入力パネルが含まれており、タッチ入力パネル上でのタッチ入力位置座標が入力デバイスインタフェース（不図示）を介してタブレット端末２０１の処理系（ＣＰＵ）へ送信され処理される。そして、このマルチタッチ入力パネルは、パネルに対する複数の接触点を同時に感知することができるよう構成されている。この検出（センサ）については様々な方法で実現することができ、必ずしも接触センサに限られず、例えば、光学式のセンサを利用してパネルに対する指示点を抽出することも可能である。さらに、センサには、接触式のセンサや光学式のセンサのほか、人の肌の接触を感知する静電容量方式のセンサを用いることも可能である。

また、図２には現れていないが、タブレット端末２０１は、マイクやスピーカを備えることもできる。この場合にはマイクより拾ったユーザの声などを判別して入力コマンドとすることも可能である。さらに、図２には現れていないが、タブレット端末２０１の背面（ディスプレイ２０１２の反対側の面）には、ＣＭＯＳ等のカメラデバイスが実装可能である（必要に応じて、ディスプレイ２０１２側の同じ側の面にもサブカメラ等を実装可能である）。

図３に、本発明の一実施形態にかかるタブレット端末２０１を構成するハードウェアの機能ブロック図を例示する。タブレット端末２０１の動作は、以下に説明するハードウェアの個々の動作、及びこれらのハードウェアとソフトウェアの連携動作によって実現されている。

図３において、ハードウェアブロック全体としてのタブレット端末３００は、大別すると、図２におけるハードウェアボタン２０１３、ディスプレイ２０１２に設けられたマルチタッチ入力パネル、マイク等で構成される入力部３０１と、プログラムやデータ等を記憶するためのハードディスク、ＲＡＭ及び／又はＲＯＭ等で構成される記憶部３０２と、プログラムによって様々な数値計算や論理演算を行うＣＰＵによって構成される中央処理部３０３と、ディスプレイ２０１２等で構成される表示部３０４と、チップや電気系統等の制御を行うための制御部３０５と、インターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信インタフェースから構成される通信インタフェース部３０６と、スピーカやバイブレーション等の出力部３０７と、時刻等を計時するための計時部３０８と、ＣＭＯＳ等のイメージセンサからなるセンサ部３０９と、装置内の各モジュールに電源を供給するための電源部３１０とからなり、これらのモジュールは必要に応じて適宜通信バースや給電線（図３においては、便宜上各線が適宜区分された結線３１１としてひとまとめに表す）によって接続されている。
なお、センサ部３０９には、タブレット端末３００（２０１）の位置を特定するためのＧＰＳセンサモジュールを含めることとしても良い。また、センサ部３０９を構成するＣＭＯＳ等のイメージセンサによって検知された信号は、入力部３０１において入力情報として処理される。

また、本発明の実施に必要なプログラムないしソフトウェアは、通常、記憶部３０２を構成するハードディスク等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部３０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ等の中央処理部３０３において演算実行される。

なお、演算実行は必ずしもＣＰＵ等の中央処理部３０３で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

図４に、本発明の一実施形態にかかる管理システムの制御動作シーン例を示すが、その前に本発明の基本概念について説明する。
［本発明の基本的特徴］
本発明の基本的特徴は、第１に、発倉庫での運搬車両への荷物の積み込みの際に（１）最小管理単位（Stock Keeping Unit）での商品管理コード、（２）パレット番号、（３）運搬車両の番号ないしドライバーの識別子といった３つのカテゴリーにわたるコードを紐付けてシステム管理することが挙げられる。
第２に、輸送途中の商品の在庫状況を管理可能とし（つまり、輸送途中在庫の可視化を実現し）、着倉庫側で緊急に必要となった商品（いわゆる欠品商品）の在庫確認を輸送途中の商品をも対象として行うことが挙げられる。なお、在庫管理情報及び／又は受発注情報は、着倉庫拠点端末や必要に応じて情報管理サーバ上で管理されている。
第３に、運搬車両（ないしドライバー）からの着倉庫における着バース予約を可能とし、上記の輸送途中在庫の可視化により、急ぎで欠品商品を要する着倉庫は、当該商品を積載している運搬車両に対して優先的に着バースへ誘導できるように制御できること（着倉庫からのさらなる緊急出荷にも対応可能なこと）が挙げられる。なお、優先的な着バース誘導に際してはその優先度の高さに応じて優先度（優先順位）を設けることができる。優先度を決める判断基準には、欠品商品、品薄商品、予約商品、納品期限等、種々の基準を採用することができる。
また、荷物の性質によっても優先度を決めることができる。例えば、医薬品、災害救援物資、温度管理商品、賞味（消費）期限のある商品、自主回収商品に対しては個々の性質に応じた優先度を付与することができる。
その他、着倉庫エリアでのデジタル入荷検品による入庫検品作業の不要化、着倉庫等の拠点と運搬車両（ドライバー）とのメッセージ交換等を通じた着バースの予定管理、運搬移動中の車両の位置情報の共有など種々の特徴を有する。

図４において、期間ｔ４０１には物品の納品前夜の時間帯（における発倉庫の工程）があらわされており、期間ｔ４０２には当該物品の納品当日（同図では例示的に午前中）の時間帯（における着倉庫の工程）があらわされている。

図４の期間ｔ４１１においては、発倉庫での荷物のリスト化や検品などがＲＦＩＤを介して読み込まれ、商品管理コード、パレット番号、運搬車両（ないしドライバー）の識別子が紐付け処理される（工程４１１）。

次に、検品や紐付け処理を終えて荷物の積み込みが完了した運搬車両は、納品先（着倉庫）へ向けて出発するが、出発前または出発後に運搬車両のドライバーは自身が携行するタブレット端末を介して着倉庫エリアでの着バースの予約を行うことができる（工程４１２）。

さらに、運搬車両が着バース予約を完了した後に事情が変更した場合（例えば、運搬車両が渋滞に巻き込まれて着倉庫への到着が大幅に遅れそうな場合、あるいは、着倉庫で欠品商品が発生し、当該欠品商品を運搬中の運搬車両に対して優先着車を要求する場合が挙げられる）には、運搬車両のドライバーまたは着倉庫の管理者からの要求により、着バース予約内容を変更等することができる（工程４１３）。着バース予約内容が変更された結果、優先着車の優先順位が決められていた場合には、その順番（順位）が繰り下がることもある。
なお、着バース予約内容変更は、発倉庫の管理者や図示しない荷主から要求することもできる（その場合、発倉庫側の都合による到着希望日時変更希望や、納品状況・事故による到着時刻の変更に伴う予約内容変更が考えられる）。

図４の期間ｔ４０２においては、基本的に着倉庫エリアへの到着順に着車の手配が行われるが必要に応じて優先着車が実施される（工程４２１）。
また、運搬車両からの荷卸しが行われる際にはＲＦＩＤを介した荷卸し確認が行われ、必要に応じて欠品商品や品薄商品が優先的に探索される（工程４２２）。このとき、荷卸しされたパレットの仕分け（図１２における工程１２２３）や商品確認（図１２における工程１２２４）は、工程４２２によって既に完了しているので割愛することができる。こうして検品された商品（荷物）は所定の場所等に格納される（工程４２３）。

以上の流れを従前のフロー（図１２）と比較してみると容易に理解できるように、パレット仕分けや商品確認作業を削減でき、荷卸しの緊急度ないし優先度が高い商品（欠品商品や品薄商品など）が発生した場合に要する時間も少なくて済むので、結果、着倉庫での作業時間を短縮させることができる（この短縮部分は、図４における「削減効果領域」として示した）。

図５Ａ〜図５Ｂを参照して、本発明の一実施形態にかかる管理システムの動作例を示す。図５Ａは、本発明の一実施形態として、管理サーバ及びコミュニケーションサーバを有する管理システムを介し、発倉庫拠点と着倉庫拠点と荷物を搬送する運搬車両（及びタブレット端末（ドライバー端末あるいは運搬車両端末）を携行するドライバー）との間のデータや情報のやり取りを例示している。また、図５Ｂは、特に、荷物を搬送中の運搬車両に対して優先案内や着バース変更案内等の通知を行う場合のデータや情報のやり取りを例示するものである。

図５Ａにおいて、時刻ｔ１〜ｔ５までは、発倉庫拠点で運搬車両が荷物を積み込む出荷フェーズであり、ドライバーは発倉庫に設置されたハンディターミナル（ＨＴ）を介して積み込む荷物の検品処理を行ったり、あるいは、自身が携行するタブレット端末（ドライバー端末あるいは運搬車両端末）を介して着倉庫拠点での着バース予約処理を行ったりする。
本発明の一実施形態において、より具体的には以下のような処理が行われる。

時刻ｔ１〜ｔ２までは、発倉庫拠点におけるハンディターミナルを介した積み込み荷物の検品処理やデータ登録等が行われる（ステップＳ５０１）。この検品処理及びデータ登録は、典型的には運搬車両のドライバーが行うが本発明はこれに限定されない。

時刻ｔ１〜ｔ２までの業務の一例を時系列に説明すると、まず、発倉庫端末（図１の１２１）へ出荷予定データが取り込まれる。次に、発倉庫端末に取り込まれたデータはハンディターミナルに送信され、典型的にはＨＴを操作する運搬車両のドライバーによって出荷作業が行われる（ＨＴによって読み込まれた荷物情報は、逐次発倉庫端末へ送信することができる）。そして、発倉庫端末上で運搬車両に積載される単位での出荷実績データが作成される。
この出荷データはコミュニケーションサーバを介して管理サーバへアップロードされる（時刻ｔ２、ステップＳ５０２のデータ連携）。なお、本発明の他の実施形態においては、出荷データはコミュニケーションサーバを介さずに直接管理サーバへアップロードされても良い。

（出荷時のデータ連携内容）
ステップＳ５０２において管理サーバにアップロードされるデータのうち、管理サーバにおいて少なくとも紐付けされるデータ項目は次表のとおりである。
ここで、図６Ａ〜図６Ｂを参照して、出荷作業時のＨＴ画面上の表示例を示すことによって紐付けされるデータの様子を説明する。図６ＡのＨＴ画面６００上には、編成番号（運搬単位としての編成コードであり、典型的には運搬車両ごとに編成番号が割り振られるが、複数の運搬車両によって運搬される一連の荷物については共通の編成番号が割り振られることもある。この場合には、編成番号とドライバーＮｏによって区分が可能である）６０１と、作業開始時間６０２と作業終了時間６０３とが表示され、更に画面下部の表示領域６１０には、特定のドライバーによって運搬されるパレットの一覧が示されている。同領域６１０には、ドライバーＮｏ及びパレット番号ともに同じ数値が表示されているが、ドライバーＮｏは共通でパレット番号が異なっている場合には、同一のドライバーによって運搬される複数のパレットが一覧されていることとなるし、ドライバーＮｏに複数のものが表示されている場合には、ドライバーごとに運搬される１以上のパレットが表示されていることとなる。

（平積み荷物の場合）
なお、運搬される荷物がパレットに格納されず、そのまま運搬車両に積載される場合がある。その場合には、Ｎｏ．００００やＮｏ．９９９９など一意のパレット番号を割り当てて、実際のパレットに割り当てられている番号と区別することができる。

操作領域６２１〜６２３は、画面６００に表示させる内容を変更等させるための操作ボタン等である。
また、画面６００に表示可能な情報は、基本的に管理サーバへアップロードされ、同サーバにて管理される。

また、図６ＢのＨＴ画面６３０上には、編成番号６３１及びパレット番号６３２ごとの積載商品が表示領域６３５に表示されている（同図には、作業開始時間６３３及び作業終了時間６３４も表示されている）。

表示領域６３５には、例示的に共通物流シンボル（ＩＴＦ）及び商品コード、並びに梱数が表示されている。同領域６３５にはＩＴＦ及び商品コード、並びに梱数について同じ数値が表示されているが、実際には運搬の実態に応じた個々のシンボル・コード、及び梱数が表示される。

画面６３０に表示可能な情報は、基本的に管理サーバへアップロードされ、同サーバにて管理される。

再び、図５Ａに戻り説明を続けると、時刻ｔ３において、ドライバーは着倉庫に到着した場合の着バース予約手続きを、コミュニケーションサーバを介して行う（ステップＳ５０３）。
この予約手続きは、ドライバーが携行するタブレット端末にコミュニケーションサーバとのコミュニケーションが可能なアプリケーションが予めインストールされていることにより実現されるものであり、コミュニケーションサーバにはカレンダー機能が備わっているので、着倉庫エリアにおける着バースのスケジュール管理が可能となっている。典型的には、着バース予約を行うドライバーと着倉庫の管理者との間でコミュニケーションサーバを介したやり取りを行うことにより着バース予約が行われるが、少なくとも、管理者側の端末（図１の１３１）の画面上では、適切な着バースを案内できるような情報提示や案内補助情報が提示される。こうした案内補助情報は、ドライバーや着倉庫の不測の事態が発生した場合にも柔軟に対応できるように作動可能である（詳細は後述）。

時刻ｔ３〜ｔ４において、着倉庫端末上でコミュニケーションサーバ（のカレンダー機能等）を介した着バース調整が完了すると（ステップＳ５０４）、時刻ｔ４において、コミュニケーションサーバからドライバー端末（運搬車両端末）へ予約完了通知が行われる（ステップＳ５０５）とともに、予約内容が管理サーバへも連携される（ステップＳ５０６）。かかる着バーススケジュール等はコミュニケーションサーバ及び／又は管理サーバにおいて管理更新される。

時刻ｔ５に、ドライバーは運搬荷物を積載した運搬車両を運転して発倉庫を出発する。なお、図５Ａでは、発倉庫出発前に着バース予約を実施したが本発明はこれに限定されるものではなく、発倉庫出発後（の任意の停車位置から）、着バース予約をするように運用することも可能であることは言うまでもない。

また、管理サーバで管理される情報はこれらに限らず、ここまでの流通過程で取得可能な他の情報（出庫日時、発倉庫情報、発倉庫における出庫棟情報、着倉庫への届け予定日時、データ登録日時）を入荷実績データに加えることもでき、これらを照会条件とした検索処理をすることも可能である。

時刻ｔ１１〜ｔ１２は、運搬中の管理システムの動作例である。発倉庫出発後、時刻ｔ１１までに運搬車両は渋滞に巻き込まれており、このままでは、予定時刻に着倉庫へ到着することが難しい状況である。そこで、ドライバーは自身が携行するタブレット端末からコミュニケーションサーバを介して着倉庫端末（着倉庫管理者）へ着バースの予約変更を依頼（通知）する（ステップＳ５１１）。

時刻ｔ１１〜ｔ１２まで、着倉庫端末からコミュニケーションサーバを介し（必要に応じて管理サーバとのデータ連携が行われても良い）、着バーススケジュールの再調整が行われる（ステップＳ５１２）。

時刻ｔ１２において再調整作業が完了すると、コミュニケーションサーバを介してドライバー端末へ変更完了通知が行われる（これに前後して、コミュニケーションサーバと管理サーバとの間で適宜データ連携が行われても良い）。

時刻ｔ２１〜ｔ２２では、着倉庫拠点におけるハンディターミナルを介した積卸し荷物の確認処理やデータ登録等が行われる（ステップＳ５２１）。この確認処理及びデータ登録は、典型的には運搬車両のドライバーが行うが本発明はこれに限定されない。

時刻ｔ２１〜ｔ２２までの業務の一例を時系列に説明すると、まず、着倉庫端末（図１の１３１）へ入荷予定データが取り込まれる（典型的には、コミュニケーションサーバを介して管理サーバからダウンロードされる）。次に、着倉庫端末に取り込まれたデータはハンディターミナルに送信され、典型的にはＨＴを操作する運搬車両のドライバーによって入荷作業が行われる（ＨＴによって読み込まれた荷物情報は、逐次着倉庫端末へ送信することができる）。そして、着倉庫端末上で運搬車両から下ろされた単位での入荷実績データが作成される。
この入荷実績データはコミュニケーションサーバを介して管理サーバへアップロードされる（時刻ｔ２２、ステップＳ５２２のデータ連携）。なお、本発明の他の実施形態においては、入荷実績データはコミュニケーションサーバを介さずに直接管理サーバへアップロードされても良い。

（入荷実績データ例）
基本的に、入荷実績データは、出荷データ（編成番号、ドライバー番号、パレット番号、ＩＴＦ、商品コード、梱数）に対する入荷を確認したことを表わすデータであるが、これらに限らず、これまでの流通過程で取得可能な他の情報（出庫日時、発倉庫情報、発倉庫における出庫棟情報、着倉庫への届け完了日時、データ登録日時）を入荷実績データに加えることもでき、これらを照会条件とした検索処理をすることも可能である。

ここで、図６Ｃを参照して、入荷作業時のＨＴ画面上の表示例を示すことによって確認される入荷データの様子を説明する。図６ＣのＨＴ画面６５０上には、編成番号６５１と、現在読み取られたパレット番号６５２と、パレット番号読み取り確認表示６５３とが表示されている。なお、表示６５３には、「ＲＦＩＤ 読取ＯＫ」と表示されているので、パレット番号６５２に表示された番号によって特定されるパレットの読み込みが成功したことを意味している。

そして、表示領域６５４には、運搬車両によって搬送されてきたパレット番号の一覧が表示されている。同領域６５４にはパレット番号として同じ数値が表示されているが、実際には運搬の実態に応じた（１以上の）異なるパレット番号が表示される。

本発明の一実施形態においては、パレットのＲＦＩＤ読み取りによるパレット確認を以って入荷確認とすることができる（この点で、図１２に示されたような「パレット仕分」作業や「商品確認」作業を割愛することができ、図４に示されたように入荷工数を削減することができる）。この場合は、一例として、現在読み取った（入荷確認できた）パレット番号（領域６５２に表示されたパレット番号である）に対応する領域６５４中のパレット番号が反転表示（ないし色付表示）されるなどして、入荷作業の進捗を確認することができる。パレットのＲＦＩＤ読み取りを次々とこなしていき、画面内のパレット番号が全て反転表示（ないし色付表示）されると作業完了となる。

また、入荷確認作業中または作業後においては、入荷情報を適宜修正することも可能である。この場合、ＨＴ上の図示しない入荷メニュー画面から「入力修正」を選択し、「編成番号」「パレット番号」等を入力することによって修正したい荷物データを呼び出し、例えば梱数の修正を行うことができる。

本発明の一実施形態においては、ＨＴを使用したＲＦＩＤ読み取りにより入荷作業を完了すると、ＨＴの図示しないメニュー画面上のコマンド指示により入荷実績データ送信を行い、着倉庫端末へのデータ送信を行う。
着倉庫端末とコミュニケーションサーバ及び／又は管理サーバとの間で適宜データ連携が行われることは、図５ＡのステップＳ５２１、Ｓ５２２に示したとおりである。

図５Ｂに、本発明の他の実施形態として、荷物を搬送中の運搬車両に対して優先案内や着バース変更案内等の通知を行う場合のデータや情報のやり取りを示す。

図５Ｂの時刻ｔ３１において、着倉庫にて欠品商品（典型的には、日用雑貨品が該当するが本発明はこれに限定されない）が発生する。この欠品商品は、図示しない外部拠点（例えば、着倉庫から仕入れをしている販売店等であっても良い）からの連絡であっても良く（ステップＳ５５１）、あるいは、着倉庫内での在庫管理上（例えば、着倉庫端末上で在庫管理情報として管理される。なお、この在庫管理情報は適宜情報管理サーバとの連携により当該サーバと共有されても良い）、欠品が明らかになったものとしても良い。

ここで、留意すべき点は、着倉庫端末では、着倉庫内の在庫を管理するとともに、着倉庫に向かっている運搬車両に積載されている商品も在庫（これを「車両在庫」という）として管理ないし照会可能に構成されている点である。

時刻ｔ３１〜ｔ３２まで、外部から欠品連絡が入った場合には着倉庫端末ではひとまず着倉庫内の在庫確認が行われる（ステップＳ５５２）が、着倉庫内での在庫がないと判明した場合には、車両在庫に欠品商品が含まれているかどうかを管理サーバに問い合わせる（時刻ｔ３２、ステップＳ５５３）。

時刻ｔ３２〜ｔ３３において、管理サーバでは車両在庫を照会して欠品商品の有無を確認し（ステップＳ５５４）、車両在庫有りの場合には、どの運搬車両（及び／又はどのドライバー）が在庫として抱えているかを着倉庫端末へ通知する（ステップＳ５５５）。このとき、必要に応じて該当する運搬車両の現在位置を通知させることもできる。

時刻ｔ３３〜ｔ３４において、車両在庫情報（つまり、欠品商品を積載して現在着倉庫に向かっている運搬車両に関する情報であって、当該運搬車両の識別番号や現在位置などが含まれる）の通知を受けた着倉庫端末では、着バーススケジュールの再調整を行い、欠品商品を積載している運搬車両を優先的に着バースへ案内するように調整する（ステップＳ５５６）。
なお、優先的な着バース案内においては、優先度に応じた優先順位を設けることもできる。さらに、優先的な着バースそれ自体については、専用着バースが設けられることもある。専用着バースのバリエーションには、車種別着バース、特殊車両用着バース、特定荷主あるいは運搬業者専用着バースなど種々の専用バースがあり得る。

時刻ｔ３４には、再調整作業が完了し、コミュニケーションサーバを介してドライバー端末へ変更通知（あるいは、優先着バース案内通知）が行われる（ステップＳ５５７）。また、これに前後して、コミュニケーションサーバと管理サーバとの間で適宜データ連携が行われても良い（ステップＳ５５８）。

（車両在庫データ利用形態のまとめ）
以上、図５Ａ及び図５Ｂを参照して説明したシステム動作のうち、特に車両在庫データの利用形態の観点から主要な動作フローをまとめ直すと次のとおりとなる。
（１）発倉庫において
着倉庫へ向けて運搬される荷物はＲＦＩＤでその情報を読み取られ、可視化された車両在庫データとしてコミュニケーションサーバを介して管理サーバにアップロードされる。管理サーバではかかるデータを検索可能に管理する。
（２）着倉庫において
着倉庫では、典型的には運搬車両が到着した時点でコミュニケーションサーバを介して管理サーバから可視化された車両在庫データをダウンロードする（この場合、この時点での車両在庫検索は、管理サーバへの問い合わせによらずとも着倉庫端末にて実施可能となる）。
一方で、新たに欠品商品が発生し、着倉庫にも現在在庫がない場合には未着分の車両在庫を照会する必要があり、この場合には、管理サーバから到着予定分の車両在庫データをダウンロードするか、問い合わせを行うことにより、欠品商品を積載した未着車両を抽出する。
（３）未着トラック（欠品商品を運搬中の運搬車両）において
欠品商品を積載した未着車両を抽出できた場合には、着倉庫からコミュニケーションサーバを介して当該未着車両に対して優先着バース案内（一例として、優先ゲートへの誘導案内などが考えられる）がなされる。
このとき、優先的な着バース誘導に際しては、その優先度の高さに応じて優先度（優先順位）を設けることができる。優先度を決める判断基準には、欠品商品、品薄商品、予約商品、納品期限等、種々の基準を採用することができる。
また、荷物の性質によっても優先度を決めることができる。例えば、医薬品、災害救援物資、温度管理商品、賞味（消費）期限のある商品、自主回収商品に対しては個々の性質に応じた優先度を付与することができる。
（４）再び着倉庫において
欠品商品を積載した未着車両が優先着バースへ到着したら、現在欠品商品となっている対象商品をＲＦＩＤによるパレットスキャン等により探し出して当該商品をいちはやく取り出すことができる。

（より具体的なプレーヤーを想定したシステム運用例）
図７に、本発明の一実施形態にかかる管理システムの制御下での物流の様子を具体的なプレーヤーを想定して示す。

図７において、情報管理サーバ７１１及びコミュニケーション７１２は、図１の情報管理サーバ１１及びコミュニケーションサーバ１１２にそれぞれ対応するほか、メーカー７２０及び端末７２１は発倉庫１２及び発倉庫端末１２１にそれぞれ対応し、卸業者７３０及び端末７３１は着倉庫１３及び着倉庫端末１３１にそれぞれ対応する。
また、運搬車両７４０及び端末７５０は車両１４及び端末１５にそれぞれ対応する。
さらに、本発明の一実施形態において、少なくとも情報管理サーバ７１１は、運搬車両７４０及び端末７５０を管理する運搬業者によって管理されても良い。

かかる状況において、本発明の一実施形態においては、卸業者７３０からコミュニケーションサーバ７１２を介してメーカー７２０へ発注を行う（図７（１））。より具体的には、卸業者７３０は商品の発注データを端末７３１上で作成し、コミュニケーションサーバ７１２へアップロードする。コミュニケーションサーバ７１２からメーカー７２０（端末７２１）に対しては発注通知がなされる（図７（２））。この場合の発注通知には、既存のメッセージアプリ等を採用することができる（つまり、当該メッセージアプリは本発明の一実施形態にかかるシステムによって制御される）。
なお、上記発注データは、受発注情報としてコミュニケーションサーバ７１２で管理され、さらに、必要に応じて情報管理サーバ７１１とのデータ連携により共有されることもできる。

次に、発注を受けたメーカーでは、端末７２１に接続された図示しないプリンタを利用して発注書を印刷等することができる（図７（３））。続いて、メーカー側の発倉庫では出荷作業が行われ（図７（４））、バーコードスキャン等により発注番号及び送り状番号等が登録され、納品データとしてコミュニケーションサーバへアップロードされる（図７（５））。

コミュニケーションサーバへ納品データがアップロードされると、情報管理サーバはこれを検出し、運搬業者（運搬車両７４０及び端末７５０、ならびに車両７４０のドライバーを管理する業者である）へ集荷を指示する。

指示を受けた運搬業者は、メーカー７２０の発倉庫へ向かい、指示された荷物を車両７４０へ積み込む。この際に出荷データが作成され、コミュニケーションサーバ７１２を介して情報管理サーバ７１１へアップロードされることは、図５Ａ及び図５Ｂ等を参照して説明したとおりである。

メーカー７２０の発倉庫を出発した車両７４０は、例えばその出発前後に卸業者７３０の着倉庫での着バース予約をする。このとき、運搬業者は、予約完了を情報管理サーバによって知ることができ、コミュニケーションサーバを介して卸業者７３０に対してお届け予定通知を送信することができる。

卸業者７３０の着倉庫へ到着した車両７４０からは、荷物の積卸しがなされるが、このとき入荷実績データが作成されることは、図５Ａ及び図５Ｂ等を参照して説明したとおりである。また、運搬業者は、車両７４０からの荷物の積卸しが完了すると、情報管理サーバによってこれを知ることができ、コミュニケーションサーバを介してメーカー７２０や卸業者７３０に対してお届け完了通知を送信することができる。

図８に、本発明の一実施形態にかかる管理システムの制御下での着バース予約処理概念を示す。本概念は、図５Ａに示した着バース予約ステップＳ５０３や変更連絡ステップＳ５１１の上位概念あるいはバリエーション概念であり、本発明の外延（技術的範囲のサポート）を示すものである。

図８において、コミュニケーションサーバには、その機能として公開カレンダーＡＰＩ８０１及びＢＯＴ（チャットＢＯＴ）機能８０３が搭載されており、情報管理サーバには、個々のスケジュールを決定するためのパラメータ情報を管理し、コミュニケーションサーバと連携してカレンダー管理制御を行うカレンダー管理システム８０２が実装されている。
そして、着バース予約登録依頼はドライバー及びドライバー端末８０４からなされるが、コミュニケーションサーバより提供されるコミュニケーション形態として、上述のＢＯＴ機能が採用されている。
なお、上述のＢＯＴ機能はあくまでも実施形態の一例であり、他のコミュニケーション機能を採用することとしても良い。

一例として、ドライバー端末８０４からＢＯＴ機能８０３を介してコミュニケーションサーバ及び情報管理サーバに対してバース予約登録依頼がなされると、ＢＯＴ機能８０３はその依頼をカレンダー管理システム８０２に伝達し、カレンダー管理システム８０２は公開カレンダーＡＰＩを介してバース使用に関するスケジュールを確認しながら、自身が有するパラメータ情報（問い合わせを行ったドライバーが運転する運搬車両に積載されているパレットに関する情報や荷物に関する情報など）を参照して予約可能なバースを案内したり優先的に案内したいバースをドライバー端末に通知したりする。

案内通知を受けたドライバー端末８０４では、操作者（ドライバー）の選択等により、希望する着バース（着バース番号及び日時等によって特定される）を指定する。この指定を受けて再びＢＯＴ機能８０３を介してカレンダー管理システム８０２によってバース予約確定が行われる（このとき、一例として、公開カレンダーＡＰＩ８０１に対して確定した予約内容が登録される）。カレンダー管理システム８０２からはＢＯＴ機能８０３を介してドライバー端末８０４に対してバース予約確定通知がなされる。

図９に、本発明の一実施形態にかかる管理システムの制御下での着バース予約処理時における情報処理装置（ドライバー端末１５）の画面例を示す。同図の画面例は、例えば、図５ＡのステップＳ５０３やステップＳ５１１、図８に示された着バース予約処理中の情報処理装置の画面表示の一例である。
なお、図９において、コメント９０１、９０３、９０５、及び９０７はドライバーが入力したコメントであり、コメント９０２、９０４、９０６、及び９０８はコミュニケーションサーバのＢＯＴ機能を介して送信された情報管理サーバあるいは着倉庫端末からの情報である。
コメント９０２、９０４、９０６、及び９０８の一部は、着倉庫端末から管理者によって入力されたコメントの場合があるが、それらの全部を情報管理サーバからの自動応答メッセージとすることもできる（この場合は、情報管理サーバのＡＩ機能が判断した結果としてのコメントとなる）。また、コメント９０２、９０４、９０６、及び９０８の一部が着倉庫端末の管理者によって入力されたものであるとした場合でも、図示しない着倉庫端末の画面上には、管理者が適切な着バース案内ができるような有益な情報提示がなされている（これらの詳細動作は、図１０を参照して後述する）。
以下は、図９の各メッセージのやりとりについて詳述する。

図９において、２０１７年３月１７日金曜日のドライバー端末の画面９００には、１５時１０分に情報管理サーバないし着倉庫管理者に対して着バース予約希望の旨のコメント９０１が送信されている。このコメントはドライバー端末の図示しない入力手段（ソフトウェアキーボードや音声入力等）によって入力されたものである（コメント９０３、９９０５、９０７について同じ）。

この後に、情報管理サーバないし着倉庫管理者から、着車したい倉庫名（着倉庫名）の入力を求めるコメント９０２が送信されている。この時点までに、情報管理サーバないし着倉庫管理者（着倉庫端末）では、コメント９０１を送信したドライバーの識別情報や出庫実績データないし入庫予定データが読み込まれ、これからどのような荷物がこのドライバー（及び運搬車両）によって運搬されようとしているのかが把握されている。

１５時１２分には、ドライバーから着車したい倉庫名が入力され（コメント９０３）、これに応じて、１５時１３分には、情報管理サーバないし着倉庫管理者（着倉庫端末）から予約日付の入力を求めるコメント９０４が送信されている。
１５時１４分には、ドライバーから３月１８日（つまり、翌日）の着車を希望する旨のコメント９０５が入力されている。

この後、情報管理サーバないし着倉庫端末では、希望日付に希望する着倉庫において予約可能な着バースを検索等して最終的には図９のコメント９０６に示されるような１以上の候補（予約が出来ない場合にはその旨のコメント）を提示する。このときの検索等については、本発明の種々の実施形態に基づくバリエーションがあり、基本的には、当日予約可能な着バースの番号及び時間帯を全てリストアップして提示することが可能であるが、（１）運搬車両に欠品商品や品薄商品が積載されている場合、（２）運搬車両への荷物の積載態様はパレット積みか平積みか（なお、荷物が平積みであることはパレットＮｏに特定の番号（一例として、Ｎｏ．００００やＮｏ．９９９９など）が割り当てられていることにより判別することができる）、あるいは、どちらの積載態様が主であるかに応じた優先着バース案内を要する場合、（３）積載商品の内容（食料品か化粧品かトイレタリ商品か等）及び積載量（今回希望の着バースで下したい荷物は手荷物１個だけの場合もある）に応じた優先着バース案内等を要する場合等によって、着倉庫端末及び／又はドライバー端末の画面上に種々の情報提示を行わせることができる（これらについては、図１０を参照して後述する）。

図９の１５時１６分には、ドライバーから空きバースのうちの１つを指定するコメント９０７が送信され、１５時１７分には、情報管理サーバないし着倉庫管理者から着車予約の確定通知コメント９０８が送信されている。

図１０に、本発明の一実施形態にかかる管理システムの詳細な動作例を示す。特に同図では、より適切な着バース案内をするための着バース端末上での情報提示及び／又はドライバー端末上での情報提示の具体例を示している。
図１０に示された動作フローは、主としてコミュニケーションサーバを介して着バース予約登録依頼や優先案内要求依頼があった場合の情報管理サーバ上での処理内容例を示している。

また、図１０に示された動作フローは、これまでに説明した動作フローの中では、例えば、図５ＡのステップＳ５０３〜Ｓ５０５やステップＳ５１１〜ステップＳ５１３、図８に示された処理、図９に示された処理（特に、コメント９０６を提示するための処理）の具体的動作例またはバリエーションの動作例として位置付けられるが、本発明はこれらに限定されることなく、図１０に示された動作フローを業務上の任意のタイミングで実施することができる。

例えば、発倉庫から着倉庫への出荷実績データや入荷予定データさえ情報管理サーバ上にアップロードされていれば、ドライバーないしドライバー端末からの着バース予約依頼を待たずして、先行して優先着バース案内通知を行うことができる。

そして、かかる優先着バース案内を受けたドライバーは、早く着倉庫へ行きさえすれば先方では優先的に受け入れる体制が整っていることを予め知ることができ、長時間待機の心配なく早めに出発することができる。

図１０のステップＳ１００１において処理が開始されると、ステップＳ１００２へ進み、コミュニケーションサーバ、あるいは、コミュニケーションサーバを介して着倉庫端末またはドライバー端末から車両照会要求があったかどうかが判断される。この車両照会要求は、典型的には着バース案内要求（特定の車両の着バースをスケジューリングするための要求）の一部として要求されるものであるが、本発明ではこの車両照会要求は必ずしも着バース案内要求とセットにならなければならないものではなく、上述したとおり、システム運用上任意のタイミングで実施することができる（このため、ドライバーないしドライバー端末からの着バース予約依頼を待たずして先行して優先着バース案内通知を行うことも可能となる）。

ステップＳ１００２でＮｏの場合は再び同ステップに復帰する（いわゆる要求待ちの状態）。同ステップでＹｅｓの場合はステップＳ１００３へ進む。

ステップＳ１００３では、既に情報管理サーバ上にて管理されている該当車両の出荷実績データまたは入荷予定データを照会してその運搬車両に積載されている荷物の中身を照会する。もっとも、未だ該当車両の出荷実績データまたは入荷予定データがアップロードされていない状況の場合にはその旨の図示しないエラー応答を要求元に返すことになるが、本フローでは説明を割愛する。
そして、同ステップでは、例示的に、積載荷物の中身について、パレットの有無（さらにパレットの個数、パレットでない場合には平積み荷物かどうかなど）及び荷卸しの数量（梱数）等を確認する。

次に、ステップＳ１００４へ進み、積載荷物の中に欠品商品や品薄商品が存在するか否かが照会される。着倉庫では、倉庫それ自体の在庫状況を時々刻々と管理しており、入荷及び出荷があるたびに在庫商品の数量等が管理されている（こうした情報は、情報管理サーバとの間で適宜連携可能である。一例として、図７の情報管理サーバ７１１とコミュニケーションサーバ７１２との間のデータ連携を参照）。

欠品商品は、倉庫において出荷に伴い在庫がなくなった商品であり（かかる商品には、これらに限定されるものではないが日用雑貨などがある）、品薄商品は、倉庫の管理実績から欠品になりやすい任意の商品である。品薄状態の定義は倉庫ごとに在庫が一定数量以下になった場合に品薄状態である旨のフラグを立てるなどして定義付けできる（そして、かかる倉庫側の状況は適宜情報管理サーバとのデータ連携によって共有させることができる）。

次に、ステップＳ１００５へ進み、近接着バース検索を行わせることもできる（本ステップを省略することもできる。本発明の趣旨を逸脱しない範囲において、ステップＳ１００３、ステップＳ１００４についても同様に省略できる）。近接着バース検索は、運搬車両の積載荷物の中身の大半が特定の着バースに近い荷置場に搬入されるべきものであるときには、当該荷置場に近接した着バースをピックアップする。
複数種類の荷物（それぞれの荷物は別々の荷置場に搬入され、それぞれの荷置場に近接した着バースは異なるものとする）を積載した運搬車両に対しては、荷物の比率に応じて例えば比率の多いほうの荷物の荷置場に近い着バースを候補としてピックアップさせることができる。

また、着倉庫で荷卸しする荷物が手荷物１個などその数量が僅少の場合であって、その荷物が欠品商品ないし品薄商品である場合には、さらに特別のフラグを立てるなどして特定の優先案内情報提示ないし通知に繋げることができる。

（ステップＳ１００５の他のバリエーション）
ここで、ステップＳ１００５での近接着バース検索は、適切な着バース検索の具体例である。適切な着バースを抽出するための他の例としては、車種によってその着バースに適合するかどうか、荷主または業者専用バースであるかどうか、着倉庫の状況（例：フォークが出払っていて、卸せないなど）に照らして着車させるのに適当であるかどうか、等に基づく検索や照会が挙げられる。
また、これらの検索条件や照会条件が複数ある場合には適宜システムごとに設定される総合的な基準に基づく判断がなされる。

以上の処理を経て、ステップＳ１００６へ進み、着倉庫端末上での情報提示を行う。この情報提示は、一例として、図９のコメント９０６をドライバー端末に送信するために着倉庫端末上で提示される情報である。

（着倉庫端末上での情報提示例）
（Ａ）問い合わせ元の対象車両に欠品商品、品薄商品が積載されている場合
当該欠品商品・品薄商品が積載されている車両のレコードや、パレット番号等のレコードを他の車両のレコードやパレット番号等のレコードとは表示色を区別して提示する。
かかる色分けは、対象車両に対して優先着車案内を出すための補助情報となる。
なお、レコード等同士の区別の方法は、色による区別に限定されるものではなく、音、文字（字体や大きさ等）、マーク等により区別することができる（以下、区別の方法について同様）
（Ｂ）積載態様が平積みで荷卸し量、つまり、荷物の個数、重量、容積などの荷卸し要素が、所定以上または未満の場合（なお、これらの基準は、荷卸し要素の組合せ等により決まる）
該当する車両のレコードを他の車両のレコードとは表示色を区別して提示する（この表示色は、上記（Ａ）とも異なる色で区別されることが望ましい）。
かかる色分けは、対象車両が着車した場合に荷卸し時間が平均よりも多くかかることが見込まれる補助情報となる。
（Ｃ）問い合わせ元の対象車両にはその全部またはほとんどが特定の荷置場に搬入させるべき特定の商品が積載されている場合
該当する車両のレコードに上記特定の荷置場に近接する着バースを近いものから１以上付記する。
かかる付記情報は、対象車両を近接バースへ優先案内するための補助情報となる。
（Ｄ）積載態様が平積みか、パレット（一例として、ロールボックスパレット）かによる表示区別を行う場合
一般に、積載態様が平積みの場合には、荷卸し等の作業時間が多くかかり、ロールボックスパレットなどのパレットの場合には作業時間が短くて済む。したがって、荷卸し等の作業に多くの時間を要する積載態様の車両レコードは他のレコードと区別して表示させる。一方で、荷卸し等の作業時間が短くて済む車両レコードも別の区別をして表示させる。

次に、ステップＳ１００７へ進み、ステップＳ１００３〜ステップＳ１００５でピックアップした情報に基づいた案内をドライバー端末へ通知するかどうかが判断され、管理者の指示ないし予め定められた手順により通知を要する場合にはステップＳ１００８へ進むが、Ｎｏの場合にはステップＳ１００９へスキップする。

ステップＳ１００８では、ドライバー端末上での情報提示が行われる。この情報提示は、一例として、図９のコメント９０６のバリエーション情報である。

（ドライバー端末上での情報提示例）
（ａ）問い合わせ元の対象車両に欠品商品、品薄商品が積載されている場合
「優先案内しますので、・・・・・・に着車してください」との旨のメッセージを表示する。
この表示により、ドライバーは早く行けば優先的に着車できることを予め知ることができるので、長期待機の心配なく発倉庫を早く出発することができる。このとき、どの商品が欠品商品あるいは品薄商品になっているかについても併せて表示させるようにすると、ドライバーは着車後に迅速に欠品商品あるいは品薄商品を取り出すことができるので（つまり、ＲＦＩＤ読み取りによりパレット等をいちはやく特定できるため）、さらに良好である。
（ｂ）問い合わせ元の対象車両の積卸し荷物が僅少である場合（手荷物１個とか、所定個数以下などによって適宜僅少度合を定義可能である）、あるいは、さらにこれに加えて欠品商品、品薄商品が積載されている場合
やはり、「優先案内しますので、・・・・・・に着車してください」との旨のメッセージを表示する。
この表示により、上記（ａ）で述べたような利点が生じる。
（ｃ）上記（Ｃ）で述べたような近接バース案内ができる場合
特定の着バースを指定して着車するようにメッセージを送信することができる。
かかる表示により、着車後の荷卸し及び搬入時間を短縮できるという効果を奏する。

（優先案内対象でない場合の通知例）
さらに、上記（ａ）や（ｂ）に該当しない車両に対しては、あえて「優先案内対象ではありません」という旨のメッセージ表示をさせても良い。このような表示をさせることの趣旨は、かかる通知を受けたドライバーは、仮に早い時間帯の空きが提示されたとしても高い確率で他の優先車両に対する優先案内がなされ長時間待機になるであろうとの推測ができ、あえて早い時間帯の予約をしないで済むというメリットがある。

ステップＳ１００９では、さらなる（別車両についての）照会処理があるかどうかが判断される。換言すれば、照会処理を終了するべきか否かが判断される。照会処理を終了して良い場合（同ステップにおいてＹｅｓ）には、ステップＳ１０１０へ進み、本フローとしては終了するが、照会処理を終了しない場合（同ステップにおいてＮｏ）には、ステップＳ１００２へ復帰する。

［さらなる応用例］
図１１に、本発明の他の実施形態にかかる管理システムの動作概念を示す。ここまでの説明により、ドライバーはドライバー端末を携行して、発倉庫を出発して着倉庫へ向かい、着倉庫に到着後はその倉庫で荷卸しする荷物を下ろして搬入し、必要であれば別の着倉庫へ向けて出発するといった行動をとることが明らかである。

そこで、本発明の他の実施形態では、各拠点における近接通信端末（一例として、Ｗｉｆｉルータ）を介してドライバー端末の行動履歴（特定の拠点から出発時間、特定の拠点への到着時間、特定の拠点での作業時間等）を管理して、ドライバーの拠点への入退館管理や勤怠管理を行わせるように協調運用させることができる。
勤怠管理をさせる場合には、図示しない勤怠管理サーバとの連携が必要であるが、入退館管理等の実施形態について、図１１を参照して説明する。

図１１に示されるように、インターネット回線１１３０には、ＬＴＥ回線を介して通信接続可能な拠点ごとに設置されたＷｉｆｉルータ１１２１〜１１２３（これらのＷｉｆｉルータは、ドライバー端末１１０１ａ〜１１０１ｅとの近接通信を行い、通信日時を取得できる）と、情報管理サーバ１１４０とが示されており、情報管理サーバ１１４０は、コミュニケーションサーバ１１５０及び拠点ごとの入退時刻等を管理するための入退館管理サーバ１１６０とインターネット回線を通じて直接ないし間接的に接続されている（各サーバ間も相互通信可能に接続されている）。

かかる構成によれば、ドライバー端末を各拠点のＷｉｆｉルータと通信させることで、例えば拠点への入館や拠点からの退出の打刻管理を行うことができる。さらに、Ｗｉｆｉルータに固定のＩＰアドレスを割り当てるなどすれば、かかる打刻情報の送信位置を特定することができるので、ドライバーのより正確な行動履歴を取得することができる。
さらに、図示しない公知の勤怠管理サーバと連携させれば、ドライバーのより正確な勤怠管理を行わせることができる。

従来のスマートフォンからの接続では、位置情報を取得することが容易ではなかったため、拠点への入館や拠点からの退出情報の信ぴょう性は必ずしも高いとは言えなかった。

しかしながら、上記構成に基づいた行動履歴取得を行えば、各拠点に設置された固定ＩＰ化されたルータを経由し、スマートフォン（ドライバー端末）から正確な入館・退出記録を取得できるので、正確な作業時間の割り出しや今後の作業時間予測にも有効である。

［ドライバー情報］
本発明の他の実施形態にかかる情報管理サーバにおいては、ドライバーからの到着希望日時、天候や道路状況による到着時刻の変更、着倉庫への入退館情報（勤怠システムの一部として）等、運搬車両のドライバーに関する情報をさらに管理させることができる。

［発倉庫管理者・荷主の情報］
本発明の他の実施形態にかかる情報管理サーバにおいては、発倉庫管理者からの到着希望日時や、納品状況、事故による到着時刻の変更等の情報をさらに管理させることもできる。

［本発明の一実施形態にかかる管理システムにおける作用効果］
本発明の一実施形態にかかるシステムを採用すると、さらに具体的には、（１）発倉庫の管理者（メーカーなどを含む）、（２）着倉庫の管理者（卸売業者などを含む）、（３）運搬車両ドライバー（運搬業者を含む）の観点からそれぞれ以下のような利点がある。

（１）発倉庫の管理者（メーカーなどを含む）の観点から
コミュニケーションサーバが有する各種ツールによる、メッセージ機能やスケジュール管理機能、ファイル交換機能が利用できるため、着倉庫エリアでの着車コントロールのためのシステム開発費用ないしシステム導入初期投資を大きく低減させることができる。

（２）着倉庫の管理者（卸売業者などを含む）の観点から
ＲＦＩＤを介した読み取り等により、運搬車両に積み込む商品や荷物に関する情報をシステムに集約することができるので、着倉庫の管理者とも事前にデータ共有を図ることができる。つまり、必要が生じた場合には、必要な商品を積んだ運搬車両をいち早く検索して当該運搬車両を優先的に着バースへ誘導することができる。
また、発倉庫にてどのトラックのどのパレットにどのような商品や荷物が積まれているかについてシステム上でデータ化されるため、着倉庫ではパレットの到着確認を行った時点で、ただちにパレットに積載されている商品の入庫を確定して、入庫検品工程そのものを割愛することができる。さらに、着倉庫エリアでの入庫検品作業のための仮置き場も不要となり、入庫作業場の渋滞も解消される。

（３）運搬車両ドライバー（運搬業者を含む）の観点から
無駄な待機時間を削減出来るため、運搬車両の効率的な運用を実現できる。
また、ドライバーが携行するタブレット端末を介したコミュニケーションは操作が簡素であるため、操作方法習得のためのトレーニング等に要する時間を最小限に抑えることができる。

（４）勤怠管理の観点から
上述した拠点ごとの入退館管理サーバを採用することにより、着バース予約等手続による予約時間と実際に入館した時間とをチェックし、例えば、予定よりも早く入館した運搬車両を早めに着車をさせるなどして空き時間ができた場合には他の運搬車両に対して効率よく新たな優先着車案内をできるので、全体的な待ち時間を減少させてドライバー全体の労働時間の短縮化を実現できる。

以上、具体例に基づき、本発明の一実施形態にかかる管理システム等の実施形態を説明したが、本発明の実施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様をとることも可能である。

また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェクトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプログラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモジュール等の形態であっても良い。

さらに、プログラムは、必ずしもメインボード上のＣＰＵにおいてのみ、全ての処理が実施される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装された別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすることもできる。

本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互に排他的である組合せを除き、任意の組合せで組み合わせることができる。

また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は、明示的に否定されない限り、同一の目的、同等の目的、又は類似する目的のために働く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示された特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。

さらに、本発明は、上述した実施形態のいずれの具体的構成にも制限されるものではない。本発明は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステップ、又はそれらの組合せに拡張することができる。

１０ 管理システム
１１ 情報管理サーバ
１１２ コミュニケーションサーバ
１２１、１３１ 情報処理装置（ＰＣ）
１２２ａ、１３２ａ ハンディターミナル（読み取り端末）
１２２ｂ、１３２ｂ クレードル
１５ 情報処理装置（タブレット端末あるいは運搬車両端末）

Claims (8)

1. 発倉庫拠点に用意され、前記発倉庫拠点から出荷される荷物に関する情報を取得する発倉庫拠点側読み取り端末と、
   前記発倉庫拠点側読み取り端末によって読み取られた情報を表示する発倉庫拠点側端末と、
   着倉庫拠点に用意され、前記着倉庫拠点へ入荷される荷物に関する情報を取得する着倉庫拠点側読み取り端末と、
   前記着倉庫拠点側読み取り端末によって読み取られた情報を表示する着倉庫拠点側端末と、
   前記発倉庫拠点側読み取り端末及び前記着倉庫拠点側読み取り端末から読み取られた情報の送信を受けて管理する情報管理サーバと、
   前記出荷及び入荷される前記荷物を運搬する運搬車両に携行されて移動する運搬車両端末と
   を含む出入荷及び流通物品管理システムであって、
   前記情報管理サーバは、前記運搬車両に対する前記着倉庫拠点への着車案内情報を抽出する場合に、
   （１）前記情報管理サーバまたは着倉庫拠点端末上の在庫管理情報及び／又は受発注情報に照らした前記荷物の優先度、
   （２）前記荷物を搬入する際の適切な着バースがあるかどうか、
   のうちの少なくとも１つを判断して、前記着車案内情報を優先着車案内情報として前記着倉庫拠点側端末上に提示する
   ことを特徴とするシステム。
2. 前記情報管理サーバは、前記運搬車両に対する前記着倉庫拠点への着車案内情報を抽出する場合に、前記（１）及び／又は（２）に加えて、
   （３）前記荷物の積載態様、
   （４）荷卸し量、
   （５）荷物の性質
   のうちの少なくとも１つをさらに判断して、前記着車案内情報を優先着車案内情報として前記着倉庫拠点側端末上に提示する
   ことを特徴とする請求項１に記載のシステム。
3. 前記着車案内情報は、前記運搬車両端末にさらに送信されることを特徴とする請求項１に記載のシステム。
4. 前記着車案内情報が優先着車案内情報に該当しない場合には、その旨が前記運搬車両端末に送信されることを特徴とする請求項３に記載のシステム。
5. 請求項１または２に記載のシステムにおける情報管理サーバ。
6. 請求項１または２に記載のシステムにおける運搬車両端末。
7. 発倉庫拠点に用意され、前記発倉庫拠点から出荷される荷物に関する情報を取得する発倉庫拠点側読み取り端末と、
   前記発倉庫拠点側読み取り端末によって読み取られた情報を表示する発倉庫拠点側端末と、
   着倉庫拠点に用意され、前記着倉庫拠点へ入荷される荷物に関する情報を取得する着倉庫拠点側読み取り端末と、
   前記着倉庫拠点側読み取り端末によって読み取られた情報を表示する着倉庫拠点側端末と、
   前記発倉庫拠点側読み取り端末及び前記着倉庫拠点側読み取り端末から読み取られた情報の送信を受けて管理する情報管理サーバと、
   前記出荷及び入荷される前記荷物を運搬する運搬車両に携行されて移動する運搬車両端末と
   前記発倉庫拠点及び前記着倉庫拠点に配置された近接通信端末と
   を含む出入荷及び流通物品管理システムであって、
   前記情報管理サーバは、前記運搬車両に対する前記着倉庫拠点への着車案内情報を抽出する場合に、
   （１）前記情報管理サーバ上の在庫管理情報及び／または受発注情報に照らした前記荷物の優先度、
   （２）前記荷物を搬入する際の適切な着バースがあるかどうか、
   （３）前記荷物の積載態様、
   （４）荷卸し量、
   （５）荷物の性質
   のうちの少なくとも１つを判断して、前記着車案内情報を優先着車案内情報として前記着倉庫拠点側端末上に提示し、
   前記近接通信端末は、前記運搬車両端末との近接通信により、前記運搬車両端末とともに移動する前記運搬車両の入退館場所及び時刻を前記情報管理サーバへ送信する
   ことを特徴とするシステム。
8. 勤怠管理サーバをさらに備え、
   前記情報管理サーバは、前記送信された前記運搬車両の入退館場所及び時刻を前記勤怠管理サーバへ送信し、
   前記勤怠管理サーバは、前記送信された前記運搬車両の入退館場所及び時刻に基づき勤怠管理を行う
   ことを特徴とする請求項７に記載のシステム。