(57)【要約】      （修正有）【課題】不意の異常在庫状態も適切に検出して適切な対応を採ることができる、商品流通管理システムを提供する。【解決手段】全ての商品には、一意に識別できるように、製品コードとロットナンバーをバーコードで付与する。また、配送先を一意に識別できるように、病院毎に配送先識別コードをバーコードで付与する。宅配便業者は、商品を納品する度に、配送先識別コードのバーコードと、全商品に付されているバーコードを読み取る。バーコードには製品コードとロットナンバーが記録されているので、全ての商品のバーコードを読み取る行為は、毎日棚卸をすることとなる。こうして得られた棚卸データを、病院在庫テーブル中に記録している、納品したであろうデータとの突合せを行う。病院在庫テーブルにあって棚卸データにないレコードは、発注処理を行う。病院在庫テーブルにないのに棚卸データにあるレコードは、異常在庫状態であると認識し、返品処理を行う。【選択図】図１
2009282912.tif 000002
【特許請求の範囲】
【請求項１】
複数の配送先を識別する配送先識別情報と複数の商品種別を一意に識別する商品種別情報と複数のロットを一意に識別するロットナンバーとを読み取る情報読取部と、前記情報読取部から読み取った前記配送先識別情報と前記商品種別情報と前記ロットナンバーを棚卸データとして送信する送信部とを備える端末と、
前記配送先識別情報を格納する配送先識別情報フィールドと前記商品種別情報を格納する商品種別情報フィールドと前記ロットナンバーを格納するロットナンバーフィールドとを備える配送先在庫テーブルと、前記棚卸データと前記配送先在庫テーブルとを前記配送先識別情報と前記商品種別情報と前記ロットナンバーとで紐付けて前記配送先に納入されている商品の欠損状態を検出して注文データを作成する注文データ作成部と、要求元の要求に応じて前記注文データを前記要求元に送信する注文データ送信部とよりなる受注サーバと、
前記注文データを受信する注文データ受信部と、前記注文データに基づいて前記配送先在庫テーブルの該当レコードを消費された商品の数量を差し引いて更新する売上処理部と、
前記注文データに基づいて前記配送先在庫テーブルの該当レコードに消費された商品の数量を新たに割り当てて更新する在庫補充処理部と、前記在庫補充処理部が割り当てた前記商品の出荷指示票を生成する出荷指示部とよりなる在庫管理ホストと
よりなる商品流通管理システム。
【請求項２】
前記受注サーバは更に、
前記配送先在庫テーブルに記録されておらず前記棚卸データに記録されている商品の存在を検出する異常在庫検出部と、
前記異常在庫検出部が生成した情報を表示する表示部と
を有する請求項１記載の商品流通管理システム。
【請求項３】
複数の配送先を識別する配送先識別情報と複数の商品種別を一意に識別する商品種別情報と複数のロットを一意に識別するロットナンバーとを読み取る情報読取部と、前記情報読取部から読み取った前記配送先識別情報と前記商品種別情報と前記ロットナンバーを棚卸データとして送信する送信部とを備える端末と、
前記配送先識別情報を格納する配送先識別情報フィールドと前記商品種別情報を格納する商品種別情報フィールドと前記ロットナンバーを格納するロットナンバーフィールドとを備える配送先在庫テーブルと、前記棚卸データと前記配送先在庫テーブルとを前記配送先識別情報と前記商品種別情報と前記ロットナンバーとで紐付けて前記配送先に納入されている商品の欠損状態を検出して注文データを作成する注文データ作成部と、前記注文データに基づいて前記配送先在庫テーブルの該当レコードを消費された商品の数量を差し引いて更新する売上処理部と、前記注文データに基づいて前記配送先在庫テーブルの該当レコードに消費された商品の数量を新たに割り当てて更新する在庫補充処理部と、前記在庫補充処理部が割り当てた前記商品の出荷指示票を生成する出荷指示部とよりなる在庫管理ホストと
よりなる商品流通管理システム。
【請求項４】
前記在庫管理ホストは更に、
前記配送先在庫テーブルに記録されておらず前記棚卸データに記録されている商品の存在を検出する異常在庫検出部と、
前記異常在庫検出部が生成した情報を表示する表示部と
を有する請求項３記載の商品流通管理システム。
【請求項５】
端末から送信される、複数の配送先を識別する配送先識別情報と複数の商品種別を一意に識別する商品種別情報と複数のロットを一意に識別するロットナンバーとよりなる棚卸データを受信する受信部と、
前記配送先識別情報を格納する配送先識別情報フィールドと前記商品種別情報を格納する商品種別情報フィールドと前記ロットナンバーを格納するロットナンバーフィールドとを備える配送先在庫テーブルと、
前記棚卸データと前記配送先在庫テーブルとを前記配送先識別情報と前記商品種別情報と前記ロットナンバーとで紐付けて前記配送先に納入されている商品の欠損状態を検出して注文データを作成する注文データ作成部と、
要求元の要求に応じて前記注文データを前記要求元に送信する注文データ送信部と
よりなる商品流通管理サーバ。
【請求項６】
端末から送信される、複数の配送先を識別する配送先識別情報と複数の商品種別を一意に識別する商品種別情報と複数のロットを一意に識別するロットナンバーとよりなる棚卸データを受信する受信部と、
前記配送先識別情報を格納する配送先識別情報フィールドと前記商品種別情報を格納する商品種別情報フィールドと前記ロットナンバーを格納するロットナンバーフィールドとを備える配送先在庫テーブルと、
前記棚卸データと前記配送先在庫テーブルとを前記配送先識別情報と前記商品種別情報と前記ロットナンバーとで紐付けて前記配送先に納入されている商品の欠損状態を検出して注文データを作成する注文データ作成部と、
前記注文データに基づいて前記配送先在庫テーブルの該当レコードを消費された商品の数量を差し引いて更新する売上処理部と、
前記注文データに基づいて前記配送先在庫テーブルの該当レコードに消費された商品の数量を新たに割り当てて更新する在庫補充処理部と、
前記在庫補充処理部が割り当てた前記商品の出荷指示票を生成する出荷指示部と
を備える商品流通管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、商品を消費拠点に配置し、常に補充を行う形態の、商品補充型流通システムに適用して好適な技術に関する。
より詳細には、予め病院に商品を配置しておき、商品の使用が生じた際に新たな商品を補充すると共に売上を計上する、配置販売業の流通管理システムに関する。
【背景技術】
【０００２】
周知のように、カテーテルは、医療用に用いられる中空の柔らかい管である。血管やその周辺臓器へ、腕や足などからカテーテルを挿入し、造影剤と呼ばれる薬剤を注入しＸ線撮影検査を行ったり、ＰＴＣＡ（percutaneous transluminal coronary angioplasty：経皮的冠動脈形成術）などの治療を行う。カテーテルを用いた治療方法は、人体を大きく切開せずに治療することが可能になり（低侵襲性）、患者の負担を軽減できる。
【０００３】
カテーテルはその用途や適用部位に応じて様々な大きさのものが必要である。
従来では、病院毎に卸問屋の担当者が、予め病院にある程度の分量のカテーテルを納入しておく。そして、手術にてカテーテルが使われたら、これをチェックして、売上として計上し、不足したカテーテルを新たに納入する。つまり、いわゆる「富山の薬売り」と同様の、配置販売業の商品納入形態を採っている。
なお、本発明に関係すると思われる先行技術文献を特許文献１に示す。
【０００４】
【特許文献１】特開２００２−１０９０５０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前述のように、現状では、カテーテルの流通過程に多くの卸問屋が介在している。そのため、中間マージンが発生し、コストが嵩む。そのコストは末端の医療現場、すなわち病院、そして治療費を支払う患者に及ぶ。
このようにカテーテルの流通過程に多くの卸問屋が介在している現状を改善し、製造現場から直接配送業者だけで病院にカテーテルを納入するための流通システムの検討を行った。
具体的には、卸問屋の担当者を宅配便に変更する、という発想である。
【０００６】
しかしながら、卸問屋の担当者は、人間の記憶と帳簿、そして医療現場の担当者との連絡を通じて、使用されたカテーテルの数を把握し、適切且つ柔軟にカテーテルの納品を行っているのが現状であり、このような対応は、商品を運搬するだけの、宅配便の業者に負担して貰うことはできない、という問題があった。
【０００７】
また、医療現場では時々、突然在庫がなくなってしまう、という異常事態が生じることがある。具体的には、研究等の目的で、一時的に医師が病院内に在庫として存在しているカテーテルを持ち出し、後日元に戻す、というような場合である。このような事態に対し、卸問屋の担当者であれば、異常事態を現場で目視にて把握し、担当者から事情を聞き取り、不要な納品をしないで済む。
しかし、このような対応は、宅配便業者に求めることはできない。
【０００８】
本発明はかかる課題を解決し、極めて機械的な対応で、病院に配置している在庫商品を管理し、不意の異常在庫状態も適切に検出して適切な対応を採ることができる、新規な商品流通管理システム、商品流通管理サーバ及び商品流通管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明の商品流通管理システムは、複数の配送先を識別する配送先識別情報と複数の商品種別を一意に識別する商品種別情報と複数のロットを一意に識別するロットナンバーとを読み取る情報読取部と、情報読取部から読み取った配送先識別情報と商品種別情報とロットナンバーを棚卸データとして送信する送信部とを備える端末と、配送先識別情報を格納する配送先識別情報フィールドと商品種別情報を格納する商品種別情報フィールドとロットナンバーを格納するロットナンバーフィールドとを備える配送先在庫テーブルと、棚卸データと配送先在庫テーブルとを配送先識別情報と商品種別情報とロットナンバーとで紐付けて配送先に納入されている商品の欠損状態を検出して注文データを作成する注文データ作成部と、注文データを送信する注文データ送信部とよりなる受注サーバと、注文データを受信する注文データ受信部と、注文データに基づいて配送先在庫テーブルの該当レコードを消費された商品の数量を差し引いて更新する売上処理部と、注文データに基づいて配送先在庫テーブルの該当レコードに消費された商品の数量を新たに割り当てて更新する在庫補充処理部と、在庫補充処理部が割り当てた商品の出荷指示票を生成する出荷指示部とよりなる在庫管理ホストとよりなるものである。
【００１０】
全ての商品には、一意に識別できるように、製品コードとロットナンバーをバーコードで付与する。また、配送先を一意に識別できるように、病院毎に配送先識別コードをバーコードで付与する。
宅配便業者は、商品を納品する度に、配送先識別コードのバーコードと、全商品に付されているバーコードを読み取る。バーコードには製品コードとロットナンバーが記録されているので、全ての商品のバーコードを読み取る行為は、毎日棚卸をすることとなる。こうして得られた棚卸データを、病院在庫テーブル中に記録している、納品したであろうデータとの突合せを行う。
病院在庫テーブルにあって棚卸データにないレコードは、手術で使われた商品であると認識し、発注処理を行う。
病院在庫テーブルにないのに棚卸データにあるレコードは、異常在庫状態であると認識し、返品処理を行う。
【発明の効果】
【００１１】
本発明により、極めて機械的な対応で、病院に配置している在庫商品、特に心臓手術等に用いる高額なカテーテル類を一品一品管理し、不意の異常在庫状態も適切に検出して適切な対応を採ることができる、新規な商品流通管理システム、商品流通管理サーバ及び商品流通管理装置を提供できる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態を、心臓手術等に用いる、１本数千円から数万円という高額なカテーテル類の商品流通管理システム、商品流通管理サーバ及び商品流通管理装置を例にして、図１〜図１１を参照して 説明するが、実施例に限られるものでなく適宜変更が可能である。
【００１３】
図１は、本実施の形態の例である、出荷商品管理システムの全体概略図である。図１中、出荷商品管理システム１０１は、宅配業者乙１０２が所持するバーコードリーダ１０３と端末１０４、棚卸集計ｗｅｂサーバ１０５、受注サーバ１０６、棚卸集計ｗｅｂサーバ１０５と受注サーバ１０６の間を接続するインターネット１０７、在庫管理ホスト１０８、そして受注サーバ１０６と在庫管理ホスト１０８の間を接続するＬＡＮ１０９よりなる。
【００１４】
丙病院１１０のナースステーション１１１には、納品済みの商品（以下「病院在庫商品」）１１２が所定数納入されている。この所定数は、商品を納品する病院毎に予め決められた数である。
宅配業者乙１０２は、宅配便の業者であり、毎日夕方の決まった時間に丙病院１１０のナースステーション１１１を訪れ、商品を納入する。そして、納入した商品と既にナースステーション１１１に存在する未使用の商品とを併せて、全ての病院在庫商品１１２の個々に付されたバーコード（以下「商品バーコード」）１１３を読み取る。商品バーコード１１３には、製品コードとロットナンバーが記録されている。また、ナースステーション１１１に据え置かれている病院在庫商品１１２の近くには、シール１１５が貼付されている。このシール１１５には、病院の識別情報である病院コードが記録されている病院バーコード１１４が印字されている。
バーコードリーダ１０３で読み取られた、病院コード、製品コード、ロットナンバーは、端末１０４を通じて乙社の棚卸集計ｗｅｂサーバ１０５に送信される。
【００１５】
棚卸集計ｗｅｂサーバ１０５は、ネットワークＯＳが稼動するコンピュータである。棚卸集計ｗｅｂサーバ１０５は、各配送担当者の端末１０４から無線で送信される、病院コード、製品コード、ロットナンバーを全て受信し、内部の図示しない不揮発性ストレージに棚卸データとして蓄積する。
【００１６】
カテーテル等の商品を製造販売する甲は、棚卸集計ｗｅｂサーバ１０５から棚卸データをダウンロードする受注サーバ１０６を設けている。受注サーバ１０６も棚卸集計ｗｅｂサーバ１０５と同様に、ネットワークＯＳが稼動するコンピュータである。受注サーバ１０６はインターネット１０７を通じて棚卸集計ｗｅｂサーバ１０５から棚卸データをダウンロードすると、内部の不揮発性ストレージに設けている病院在庫テーブルと照合し、出庫指示の元となる預託注文データを作成する。
【００１７】
甲社倉庫１１６には、メインフレームよりなる在庫管理ホスト１０８が存在する。在庫管理ホスト１０８も、受注サーバ１０６及び棚卸集計ｗｅｂサーバ１０５と同様に、ネットワークＯＳが稼動するコンピュータである。在庫管理ホスト１０８は、ＬＡＮ１０９を通じて受注サーバ１０６から預託注文データをダウンロードし、出庫処理等を行う。
【００１８】
図２は、棚卸集計ｗｅｂサーバ１０５の機能ブロック図である。
ｗｅｂサーバプログラム２０２は例えばＴＣＰポート８０番から来るＨＴＴＰの通信を受け入れる、一般的なｗｅｂサーバである。例えばＡｐａｃｈｅ（http://www.apache.org/）である。
棚卸データ受信ｃｇｉ２０３は、ｗｅｂサーバプログラム２０２が端末１０４から発される通信を受け入れる際に起動されるプログラムであり、端末１０４から送信される棚卸データを受信する。
【００１９】
ユーザ認証部２０４は棚卸データ受信ｃｇｉ２０３がｗｅｂサーバプログラム２０２によって起動される際に、棚卸データ受信ｃｇｉ２０３の内部から起動されるプログラムである。端末１０４から発されるＨＴＴＰメッセージのヘッダ中にある、端末１０４固有の識別文字列を検出し、ユーザマスタ２０５で照合する。照合の結果、正規の端末１０４であると認識したら、端末１０４から発される棚卸データの受信を、棚卸データ受信ｃｇｉ２０３に許可する。なお、ＨＴＴＰメッセージヘッダ中に端末或はユーザを識別するための識別文字列を埋め込む認証方法は、ＢＡＳＩＣ認証、Ｃｏｏｋｉｅ認証等、多くの方法が周知である。
【００２０】
棚卸データ受信ｃｇｉ２０３は、受信した棚卸データをプレインテキストよりなる棚卸結果テーブル２０６に追記録する。
棚卸結果送信部２０７の実体はＳＳＨ（Secure SHell）サーバであり、受注サーバ１０６から来るダウンロード要求にしたがって棚卸結果テーブル２０６を送信する。
【００２１】
図３は、受注サーバ１０６の機能ブロック図である。
棚卸結果受信部３０２の実体はＳＳＨクライアントであり、棚卸集計ｗｅｂサーバ１０５の棚卸結果送信部２０７に接続して、棚卸結果テーブル２０６をダウンロードする。棚卸結果受信部３０２が棚卸集計ｗｅｂサーバ１０５からダウンロードした棚卸結果テーブル２０６は、図示しない不揮発性ストレージに複写記録される。
【００２２】
注文データ作成部３０３は、棚卸結果テーブル２０６と病院在庫テーブル３０４との突合せを行い、差分レコードを作成する。これが預託注文データ３０５である。
入出力制御部３０６は、棚卸結果テーブル２０６と病院在庫テーブル３０４とを商品マスタ３０７と病院マスタ３０８を参照しながら、表示制御部３０９を通じて表示部３１０に確認画面を表示させ、操作部３１１から操作者の操作によって発される指示を受けて預託注文データ３０５の確定を行う。
注文データ送信部３１２は、在庫管理ホスト１０８から発せられる要求を受けて、預託注文データ３０５を送信する。
【００２３】
一方、病院在庫テーブル受信部３１３は、在庫管理ホスト１０８から新たな病院在庫テーブル３０４のデータを受信すると、病院在庫テーブル３０４の全レコードを削除し、受信したデータで書き換える。
なお、病院在庫テーブル３０４は、後述する在庫管理ホスト１０８が備える病院在庫テーブル３０４と全く同じものであり、記録されている全レコードの内容は在庫管理ホスト１０８の病院在庫テーブル３０４のミラーコピーである。
【００２４】
図４は、在庫管理ホスト１０８の機能ブロック図である。
注文データ受信部４０２は、受注サーバ１０６から預託注文データ３０５をダウンロードして、注文データファイル４０３に記録する。
入出力制御部４０４内の売上処理部４０５は、注文データファイル４０３に記録されているレコード（各病院にて使われた製品コード＋ロットナンバーのレコード）を読み取り、病院在庫テーブル４０６の該当レコードを削除すると共に、伝票テーブル４０７の該当レコードに対し、「売上が生じた」とする処理を行う。そして、在庫補充処理部４０８を起動する。
【００２５】
在庫補充処理部４０８は、注文データファイル４０３に記録されているレコードを元に、倉庫在庫テーブル４０９から各病院への商品の引き当て処理を行う。つまり、倉庫在庫テーブル４０９の該当レコードを病院在庫テーブル４０６に移動し、病院コードを割り当てる。そして、該当レコードを出庫指示情報として伝票テーブル４０７に追記する。そして、出荷指示部４１０と病院在庫送信部４１１を起動する。
出荷指示部４１０は、在庫補充処理部４０８によって伝票テーブル４０７に追記された、出庫指示情報に該当するレコードを読み取り、配送拠点である甲社倉庫１１６にある図示しないプリンタから出荷指示書を印刷出力する。
病院在庫送信部４１１は、病院在庫テーブル４０６の全てのレコードを丸ごと受注サーバ１０６へアップロードする。
【００２６】
図５は、在庫管理ホスト１０８及び受注サーバ１０６内の各種テーブルのフィールドを示す図である。
病院マスタ３０８は病院コードと対応する病院名を記憶するテーブルである。在庫管理ホスト１０８の病院マスタ３０８と受注サーバ１０６の病院マスタ３０８はそれぞれ全く同じフィールドで構成されている、同一のテーブルである。「病院コード」フィールドは、病院毎にユニークな番号が付与されている。「病院名」フィールドは病院の名称が記憶されている。
【００２７】
商品マスタ３０７は製品コードと対応する製品名を記憶するテーブルである。在庫管理ホスト１０８の商品マスタ３０７と受注サーバ１０６の商品マスタ３０７はそれぞれ全く同じフィールドで構成されている、同一のテーブルである。「製品コード」フィールドは、製品毎にユニークな番号が付与されている。「製品名」フィールドは商品の名称が記憶されている。
【００２８】
在庫管理ホスト１０８の病院在庫テーブル４０６と受注サーバ１０６の病院在庫テーブル３０４はそれぞれ全く同じフィールドで構成されている。「病院コード」フィールドは、病院マスタ３０８のそれと同じである。「製品コード」フィールドは、商品マスタ３０７のそれと同じである。「ロットナンバー」フィールドは個々の商品に付されているロットナンバーが記憶される。「有効期限」フィールドは当該ロットナンバーの商品の使用有効期限である。「在庫数」フィールドは当該病院で当該商品が在庫している数である。
【００２９】
在庫管理ホスト１０８の倉庫在庫テーブル４０９は、倉庫に在庫する商品の情報を記憶するテーブルである。「製品コード」フィールド、「ロットナンバー」フィールド、「有効期限」フィールドは病院在庫テーブル３０４のそれと同じである。「在庫数」フィールドは、倉庫に存在する数を示す。
【００３０】
伝票テーブル４０７は、倉庫から商品を出荷した時と、病院が商品を使用した、つまり売上が生じた時の記録を蓄積するテーブルである。「日時」フィールドはこの事象が発生した日時である。「出荷フラグ」フィールドと「売上フラグ」フィールドは、排他的なフラグであり、倉庫から出荷した時に「出荷フラグ」フィールドが真になり、売上を計上した時に「売上フラグ」フィールドが真になる。
【００３１】
棚卸結果テーブル２０６は病院の現在の在庫状況を示すテーブルである。
預託注文データ３０５は病院がその日に使用した商品を示すテーブルである。
【００３２】
図６（ａ）、（ｂ）及び（ｃ）と、図７（ｄ）及び（ｅ）は、丙病院１１０のナースステーション１１１にて起こる事象を説明する概略図である。
最初に、丙病院１１０のナースステーション１１１には病院在庫商品１１２が６個存在し、これが丙病院１１０の既定在庫数であるものと仮定する(図６（ａ））。
【００３３】
ある時、丙病院１１０の勤務医丁６０２が自己の医療技術研鑽のため、ナースステーション１１１にある病院在庫商品１１２を全部（図では６個）持ち去ってしまったと仮定する（図６（ｂ））。このため、この時点でナースステーション１１１には病院在庫商品１１２が一つも残っていない。つまり在庫がゼロ状態になる。
【００３４】
この後、宅配業者乙１０２が丙病院１１０のナースステーション１１１に到着する。宅配業者乙１０２はバーコードリーダ１０３で病院在庫商品１１２のバーコードをスキャンし、棚卸データを送信しようとする。しかし、病院在庫商品１１２は一つも残っていないので、その旨を棚卸集計ｗｅｂサーバ１０５に向けて送信する（図６（ｃ））。この後、「丙病院１１０のナースステーション１１１の在庫商品数はゼロである」という情報が、棚卸集計ｗｅｂサーバ１０５から受注サーバ１０６、そして在庫管理ホスト１０８に伝達され、「丙病院１１０のナースステーション１１１は商品が６個不足している」と解釈されてしまい、結果として丙病院１１０に対し、不足している分（６個）の発注が行われてしまう。
【００３５】
宅配業者乙１０２が立ち去った後、勤務医丁６０２は借用していた病院在庫商品１１２をナースステーション１１１に返却する（図７（ｄ））。ナースステーション１１１には６個の病院在庫商品１１２が戻される。
【００３６】
翌日、宅配業者乙１０２は６個の受注商品を持って現れる。ところが、勤務医丁６０２が返却した６個の商品が、既にナースステーション１１１には存在する。このため、宅配業者乙１０２は既にナースステーション１１１にある、本来の在庫である６個の病院在庫商品１１２と、新たに（誤って）納品された商品６個の、合計１２個の商品をバーコードリーダ１０３でスキャンする。結果として、丙病院１１０のナースステーション１１１は既定在庫数（６個）を超える１２個の商品を在庫として抱えることになり、過剰在庫状態となる（図７（ｅ））。
【００３７】
ここで、宅配業者乙１０２は毎日担当者が変わることが多い。例えば、図６（ｃ）の時点の宅配業者乙１０２と、図７（ｅ）の時点の宅配業者乙１０２は別人である可能性が高い。このことは、従来の卸売業者とは異なり、宅配業者乙１０２は、病院毎の既定在庫数や、急激に病院在庫商品１１２が増減したことが異常事態であることを認識しないことを意味する。
流通に介在する卸売業者を宅配業者に変えるために、本実施形態の出荷商品管理システム１０１は、従来の卸売業者が毎日の病院との付き合いで得ていた知見に基づく、上述のような異常事態の検出を、卸売業者の代わりに検出できなければならない。
【００３８】
図８及び図９は、丙病院１１０、宅配業者乙１０２と端末１０４、棚卸集計ｗｅｂサーバ１０５、受注サーバ１０６、在庫管理ホスト１０８、そして甲社倉庫１１６の、データと物の流れを示すシーケンス図である。
先ず、丙病院１１０で、手術が行われ、病院在庫商品１１２であるカテーテルが患者に使用された、とする。つまり、病院在庫商品１１２の消費による、配置在庫の減少が生じた（Ｓ８０１）。
【００３９】
この後、宅配業者乙１０２が丙病院１１０のナースステーション１１１に到着する（Ｓ８０２）。先ず、前日に注文を受けた補充商品の納品を行う。次に、既にナースステーション１１１に残っている商品と、その時納品した商品とを併せた、全ての商品のバーコードと、病院のバーコードを端末１０４のバーコードリーダ１０３で読み取る。これが、「棚卸のための在庫スキャンの実施」である（Ｓ８０３）。この時点で、端末１０４内部の図示しないＲＡＭには「棚卸データ」が作成される。この後、宅配業者乙１０２は端末１０４を操作して、棚卸データを棚卸集計ｗｅｂサーバ１０５にアップロードする（Ｓ８０４）。
【００４０】
棚卸集計ｗｅｂサーバ１０５は、端末１０４から棚卸データを受信すると、これを棚卸結果テーブル２０６に追記する（Ｓ８０５）。この処理は、各地の他の病院に分散して活動している他の宅配業者乙１０２が所持する他の端末１０４からも、同様に各病院毎の棚卸データがアップロードされるので、その都度繰り返される（Ｓ８０６）。
【００４１】
操作者は、受注サーバ１０６の操作部３１１を操作して、棚卸集計ｗｅｂサーバ１０５から棚卸結果テーブル２０６をダウンロードする指示をする（Ｓ８０７）。入出力制御部３０６は操作部３１１から発される指示を受けて、実体がＳＳＨクライアントである棚卸結果受信部３０２を起動し、実体がＳＳＨサーバである棚卸集計ｗｅｂサーバ１０５の棚卸結果送信部２０７に接続する。これを受けて、棚卸結果送信部２０７は棚卸結果テーブル２０６を棚卸結果受信部３０２へアップロードする（Ｓ８０８）。
【００４２】
棚卸結果受信部３０２は棚卸結果テーブル２０６を受信して図示しない不揮発性ストレージ内に保持した後、注文データ作成部３０３を起動する。注文データ作成部３０３は、棚卸結果テーブル２０６と病院在庫テーブル４０６を突き合せて、預託注文データ３０５を作成する。入出力制御部３０６は、注文データ作成部３０３による預託注文データ３０５の作成完了を確認すると、表示制御部３０９を通じて表示部３１０に病院毎の在庫状況を表示する（Ｓ８０９）。
【００４３】
操作者は表示部３１０に表示される内容を確認して（Ｓ８１０）、問題がなければ病院毎に預託注文データ３０５を確定する。最終的に内容が確定した預託注文データ３０５は、実体がＳＳＨクライアントである注文データ送信部３１２によって、実体がＳＳＨサーバである在庫管理ホスト１０８の注文データ受信部４０２に送信（アップロード）される（Ｓ８１１）。在庫管理ホスト１０８の注文データ受信部４０２は、注文データ送信部３１２から預託注文データ３０５を受信し、図示しない不揮発性ストレージ内に注文データファイル４０３として保持する（Ｓ８１２）。
【００４４】
図９を参照して動作シーケンスの説明を続ける。
操作者は、在庫管理ホスト１０８の操作部４１２を操作して、入出力制御部４０４を制御する。入出力制御部４０４内の売上処理部４０５は、注文データファイル４０３と病院在庫テーブル４０６を読み込み、表示制御部３０９を通じて表示部３１０に注文データファイル４０３の表示を病院毎に行う（Ｓ９１３）。
【００４５】
操作者は表示部４１３に表示される表示内容、つまり病院毎の注文データファイル４０３の内容を確認し、異常がないと判断したら、操作部３１１から売上処理部４０５に「売上処理の確定」の実行を指示する（Ｓ９１５）。すると、売上処理部４０５は病院在庫テーブル４０６から注文データファイル４０３に記録されているロットナンバーの商品を削除する。つまり、病院在庫テーブル４０６の在庫レコードを減らす。そして、この結果を伝票テーブル４０７に記録する。
【００４６】
以上の処理が終了したら、売上処理部４０５は在庫補充処理部４０８を起動して、操作部３１１と表示制御部３０９が接続されているスイッチ４１５を在庫補充処理部４０８に切り換える。つまり、ユーザインターフェースを在庫補充処理部４０８に切り換える。
【００４７】
在庫補充処理部４０８は、注文テーブルの受注情報を元に、倉庫在庫テーブル４０９から引き当てるべき商品の情報を病院毎に表示する（Ｓ９１６）。そして、操作者は表示部４１３に表示されている表示内容、つまり病院毎に引き当て可能な商品の在庫状況を確認する（Ｓ９１７）。確認の結果、引き当てを実行すると、在庫補充処理部４０８は在庫補充処理を実行する（Ｓ９１８）。具体的には、先ず、倉庫在庫テーブル４０９から注文テーブルで指示されている数の商品を当該病院に引き当てて、病院在庫テーブル４０６に割り当てる。つまり、倉庫在庫テーブル４０９から該当商品のレコードを読み取り、病院在庫テーブル４０６に記録した後、倉庫在庫テーブル４０９の元のレコードを削除する。
【００４８】
在庫補充処理部４０８は、在庫補充処理を終えると出荷指示部４１０と病院在庫送信部４１１を起動する。
出荷指示部４１０は、伝票テーブル４０７に記録された発注対象レコードを抽出して、倉庫担当者に向けて出荷伝票を作成（起票）する。倉庫担当者は伝票に従って出荷作業を行う（Ｓ９１９）。
実体がＳＳＨクライアントである病院在庫送信部４１１は、売上処理部４０５と在庫補充処理部４０８によって更新された病院在庫テーブル４０６を、実体がＳＳＨサーバである受注サーバ１０６の病院在庫テーブル受信部３１３に向けて送信(アップロード）する（Ｓ９２０）。そして、病院在庫テーブル受信部３１３は受信した病院在庫テーブル４０６を病院在庫テーブル３０４に上書きして、更新する（Ｓ９２１）。
【００４９】
翌日、宅配業者乙１０２は業務を開始すると（Ｓ９２２）、甲社倉庫１１６に移動する。そして、甲社倉庫１１６から商品の集配を行い（Ｓ９２３）、丙病院１１０のナースステーション１１１に納品し、再び棚卸スキャンを行う（Ｓ９２４）。棚卸スキャンの結果は棚卸集計ｗｅｂサーバ１０５の棚卸結果テーブル２０６に追記される（Ｓ９２５）。
【００５０】
図１０（ａ）及び（ｂ）は受注サーバ１０６の表示部３１０に表示される表示画面の一例を示す概略図である。
図１０（ａ）は病院の在庫状況が正常な状態の時の表示画面の一例である。
入出力制御部３０６は、病院コードと商品のロットナンバーで病院在庫テーブル３０４と棚卸結果テーブル２０６を紐付けて、それぞれのレコードの有無を表示部３１０に表示する。
「在庫数」欄は、病院在庫テーブル３０４に記録されている数量を示す。
「棚卸在庫数」欄は、棚卸結果テーブル２０６に記録されている数量を示す。
「使用数」欄は、病院在庫テーブル３０４に記録されていて棚卸結果テーブル２０６に記録されていない商品をチェックする欄である。
【００５１】
図１０（ｂ）は病院の在庫状況が異常な状態の時の表示画面の一例である。図６及び図７において説明した状態を想定している。
表示されているレコードは全て、「在庫数」欄に数量の表示がない。しかし、「棚卸在庫数」欄に数量の表示がある。
【００５２】
「在庫数」欄は、病院在庫テーブル３０４に記録されている数量である。つまり、在庫管理ホスト１０８の病院在庫テーブル４０６に記録されている、各病院に納入されているであろう商品の数である。これに対し、「棚卸在庫数」は、実際に宅配業者乙１０２がバーコードリーダ１０３で読み取った「棚卸データ」である。つまり、実際にその病院に存在する商品の数である。
【００５３】
本来なら、「在庫数」欄に記載されている数は、「棚卸在庫数」＋「使用数」である。使われていなければ「棚卸在庫数」に、使われれば「使用数」に表示される。
しかし、「棚卸在庫数」＋「使用数」が、「在庫数」と等しくない場合が生じる。これが、図６及び図７にて説明した、異常在庫状態である。
【００５４】
受注サーバ１０６の入出力制御部３０６は、棚卸結果テーブル２０６と病院在庫テーブル３０４をロットナンバーで紐付けて、その数を確認する。「棚卸在庫数＋使用数≠在庫数」であるレコードは、表示制御部３０９を制御して、他のレコードとは異なる色で表示し、操作者に注意を促す。
このように、入出力制御部３０６は異常在庫状態を検出する機能を有するので、異常在庫検出部ともいえる。
【００５５】
本実施形態には、以下のような応用例が考えられる。
（１）受注サーバ１０６と在庫管理ホスト１０８は一体化することができる。
図１１は本実施形態の変形例である、在庫管理ホストの機能ブロック図である。なお、前述の実施形態で説明した図と同一の機能部分には同一の番号を付している。
【００５６】
在庫管理ホスト１１０１は、図３の受注サーバ１０６と図４の在庫管理ホスト１０８を一体化した構成である。このため、
・表示部３１０、表示制御部３０９及び操作部３１１と、表示部４１３、表示制御部４１４及び操作部４１２は統合され、
・ネットワークを介する必要がないので、注文データ送信部３１２と注文データ受信部４０２、病院在庫送信部４１１と病院在庫テーブル受信部３１３はなくなり、
・ミラーコピーした病院在庫テーブル３０４を設ける必要がなくなる。
【００５７】
そして、受注サーバ１０６の入出力制御部３０６で行っていた預託注文データ２０３の確認処理は、注文確認部１１０２で売上処理部４０５に先立って実施することとなり、スイッチ４１５の代わりにスイッチ１１０３はこれを切り換える必要が生じる。
出荷商品管理システム１０１全体の視点で見ると、在庫管理ホスト１１０１が実行する処理内容は、受注サーバ１０６と在庫管理ホスト１０８と比べて、実質的に殆ど変わらない。
【００５８】
本実施形態においては、出荷商品管理システムを開示した。バーコードリーダを用いて毎日棚卸を行い、納入先に存在するであろう在庫数と、実際に棚卸作業で得た棚卸在庫数を比較して、棚卸在庫数が在庫数を超えている場合は、異常在庫状態であると識別し、操作者にその旨を表示する。このような異常状態チェック機能を出荷商品管理システムの一構成要素である受注サーバに備えることで、卸業者が行っていた在庫チェック作業が、機械化した流通システムで実現できる。したがって、卸業者の代わりに宅配業者を利用できるので、商品の流通コストを削減することができる。
【００５９】
以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
【図面の簡単な説明】
【００６０】
【図１】本実施の形態の例である、出荷商品管理システムの全体概略図である。
【図２】棚卸集計ｗｅｂサーバの機能ブロック図である。
【図３】受注サーバの機能ブロック図である。
【図４】在庫管理ホストの機能ブロック図である。
【図５】在庫管理ホスト及び受注サーバ内の各種テーブルのフィールドを示す図である。
【図６】丙病院のナースステーションにて起こる事象を説明する概略図である。
【図７】丙病院のナースステーションにて起こる事象を説明する概略図である。
【図８】丙病院、宅配業者乙と端末、棚卸集計ｗｅｂサーバ、受注サーバ、在庫管理ホスト、そして甲社倉庫の、データと物の流れを示すシーケンス図である。
【図９】丙病院、宅配業者乙と端末、棚卸集計ｗｅｂサーバ、受注サーバ、在庫管理ホスト、そして甲社倉庫の、データと物の流れを示すシーケンス図である。
【図１０】受注サーバの表示部に表示される表示画面の一例を示す概略図である。
【図１１】本実施形態の変形例である、在庫管理ホストの機能ブロック図である。
【符号の説明】
【００６１】
１０１…出荷商品管理システム、１０２…宅配業者乙、１０３…バーコードリーダ、１０４…端末、１０５…棚卸集計ｗｅｂサーバ、１０６…受注サーバ、１０５…棚卸集計ｗｅｂサーバ、１０６…受注サーバ、１０７…インターネット、１０８…在庫管理ホスト、１０９…ＬＡＮ、１１０…丙病院、１１１…ナースステーション、１１２…病院在庫商品、１１３…商品バーコード、１１４…病院バーコード、１１５…シール、１１６…甲社倉庫、２０２…ｗｅｂサーバプログラム、２０３…棚卸データ受信ｃｇｉ、２０４…ユーザ認証部、２０５…ユーザマスタ、２０６…棚卸結果テーブル、２０７…棚卸結果送信部、３０２…棚卸結果受信部、３０３…注文データ作成部、３０４…病院在庫テーブル、３０５…預託注文データ、３０６…入出力制御部、３０７…商品マスタ、３０８…病院マスタ、３０９…表示制御部、３１０…表示部、３１１…操作部、３１２…注文データ送信部、３１３…病院在庫テーブル受信部、４０２…注文データ受信部、４０３…注文データ、４０４…入出力制御部、４０５…売上処理部、４０６…病院在庫テーブル、４０７…伝票テーブル、４０８…在庫補充処理部、４０９…倉庫在庫テーブル、４１０…出荷指示部、４１１…病院在庫送信部、４１２…操作部、４１３…表示部、４１５…スイッチ、６０２…勤務医丁
【図１】
2009282912.tif 000003
【図２】
2009282912.tif 000004
【図３】
2009282912.tif 000005
【図４】
2009282912.tif 000006
【図５】
2009282912.tif 000007
【図６】
2009282912.tif 000008
【図７】
2009282912.tif 000009
【図８】
2009282912.tif 000010
【図９】
2009282912.tif 000011
【図１０】
2009282912.tif 000012
【図１１】
2009282912.tif 000013