JP2010086055A - 在庫管理装置、在庫管理方法、プログラム - Google Patents

Abstract

【課題】倉庫内の在庫情報をバッチ処理等によりまとめて更新する仕組みにおいて、倉庫内の現在の在庫情報を把握することができる仕組みを提供すること。
【解決手段】当日に倉庫から出庫する商品の出庫数を入力する情報処理装置と通信可能な、倉庫内の商品の在庫数を管理する在庫管理装置（管理サーバ０１）であって、該情報処理装置から、倉庫から出庫する商品の出庫数を示す出庫ワークデータから得られる、当日に倉庫から出庫した商品の個数実績を示す出庫実績データと、倉庫内の商品の在庫数を示す倉庫在庫データと、問合せの当日に受け付けた出庫ワークデータとから現在の倉庫内の在庫数を算出し、該算出された在庫数を出力することを特徴とする。
【選択図】図１

Description

本発明は、商品の在庫数を管理する在庫管理装置、在庫管理方法、プログラムに関する。

従来、商品を配送する配送担当者は、商品を配送するため、配送に必要な商品を必要な数だけ倉庫から取り出し車両に積み込んでいた。

その際に、倉庫から取り出し車両に積み込む商品の種類やその数量を入力端末に担当者が入力する。

そして、倉庫内の在庫データを管理している管理サーバに、入力端末がその入力されたデータを送信すると、管理サーバは、管理サーバで管理している倉庫内の在庫データをすぐに更新する。これにより、現在の倉庫内の在庫数を把握すること知られている。

しかしながら、このような仕組みでは、管理サーバで管理している在庫データの量、又は更新するデータ（車両に積み込んだ商品の種類やその数量等のデータ）の量が多いと、そのデータ更新に多くの時間を要してしまう。

さらに、従来、入力端末は、データが更新し終わるまで管理サーバに接続しなければならないため、データ更新に多くの時間を要した場合、管理サーバと接続する時間が増し、これに伴い、管理サーバにデータを送信する待ち行列が発生していた。

この課題を解決するため、管理サーバは、入力端末から更新するデータを受信しても、すぐに管理サーバ内の在庫データを更新せず、夜間バッチで、受信したデータから管理サーバ内の在庫データを一括で更新する仕組みが一般に運用されている。

特許文献１には、各種物品を物品収納庫から持ち出す際に、ハンディターミナルにて持ち出した物品の種類および数量データなどを入力し、入力されたデータは管理サーバに転送され、管理サーバは、在庫データを更新することが開示されている。
特開２００１−２０６５１５号公報

しかしながら、上記従来の技術では、夜間バッチ処理が完了しなければ、倉庫から入出庫した商品の種類やその数などのデータを、管理サーバ内の在庫データに反映させることはできず、倉庫内の現在の在庫数などをリアルタイムに把握することはできなかった。

また、配送担当者による商品や売上金などの盗みを把握又は防止するため、当日に入出庫した商品数（在庫数）などの入出庫データを携帯端末から管理サーバに送信（アップロード）できるのが１日１回しかできない制限がある場合で、急遽、前日に予定していたよりも多く商品を車に積まなくてはならなくなってしまったような場合は、当日の倉庫内の在庫数を正しく把握することが困難である。

すなわち、このような場合、前日の入出庫の実績しか出力することができず、当日、変動する倉庫内の在庫数を把握することが困難であった。

本発明は、倉庫内の在庫情報をバッチ処理等によりまとめて更新する仕組みにおいて、倉庫内の現在の在庫情報を把握することができる仕組みを提供することを目的とする。

本発明は、当日に倉庫から出庫する商品の出庫数を入力する情報処理装置と通信可能な、倉庫内の商品の在庫数を管理する在庫管理装置であって、倉庫内の商品の在庫数を示す倉庫在庫データを記憶する第1の記憶手段と、前記情報処理装置から、前記倉庫から出庫する商品の出庫数を示す出庫ワークデータを受け付ける第1の受付手段と、所定の時間に、前記第１の受付手段で受け付けた出庫ワークデータから得られる、当日に倉庫から出庫した商品の個数実績を示す出庫実績データを記憶する第２の記憶手段と、前記情報処理装置からの現在の倉庫内の商品の在庫数の問合せに応じて、前記第1の記憶手段に記憶された倉庫在庫データと、前記第２の記憶手段に記憶された出庫実績データと、前記問合せの当日に前記受付手段で受け付けた出庫ワークデータとから、現在の倉庫内の在庫数を算出する算出手段と、前記算出手段で算出された倉庫内の在庫数を出力する出力手段とを備えることを特徴とする。

本発明によれば、倉庫内の在庫情報をバッチ処理等によりまとめて更新する仕組みにおいて、倉庫内のある時点の在庫情報を把握することができる。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１（システム構成図）の説明
図１は本発明の実施形態の在庫管理装置を説明するためのシステム構成図である。

図１に示す在庫管理システムは、管理サーバ０１（在庫管理装置）と、ＰＣ端末０２（情報処理装置）と、携帯端末０３（ハンディターミナルやＨＴとも言う。）と、ネットワーク０４とから構成されている。

また、管理サーバ０１、ＰＣ端末０２、携帯端末０３はそれぞれ通信可能なプリンタと接続され（不図示）、当該プリンタに対して帳票の印刷などの出力指示を行うことが可能である。

管理サーバ０１は、データベース２０を備え、該データベースには、営業所在庫データ１３、車上在庫データ１４、入出庫実績データ１５、入出庫ワークデータ１６を記憶している。これらのデータは各拠点の営業所（倉庫）２２及び配送車２３毎に記憶されているものとする。

これらのデータの一例を図２０に示している。具体的には、営業所管理データ１３は図２０の（ａ）（ｅ）、車上在庫データ１４は図２０の（ｂ）（ｆ）、入出庫実績データ１５は図２０の（ｇ）、入出庫ワークデータ１６は図２０の（ｃ）に示している。

また、管理サーバ０１の一時フォルダ２１は、携帯端末０３より受信したＨＴ積み降しデータ１９（例えば、図２０に示す（ｄ）ＨＴ積み降ろしデータ）を一時的に記憶しておく記憶領域である。

ＰＣ端末０２のＣＰＵは、後述する車上受払処理０９、商品他受払表（プレロード）出力処理０５、商品他受払表（日報）出力処理０７を実行する（図１１〜１４に示す処理を実行する）。

ＰＣ端末０２における商品他受払表（日報）出力処理０７（図１３）は、商品他受払表（日報）を出力するための検索画面（図５）をＰＣ端末０２の表示部に表示する。この画面は、前日までの倉庫内の商品の在庫数を含む在庫情報を検索するための検索条件入力画面である。

ＰＣ端末０２は、この検索画面を介して検索条件を受け付けると、受け付けた検索条件を管理サーバ０１に送信する。そして、ＰＣ端末０２は、管理サーバ０１から検索結果を受信し、その検索結果を出力する。ＰＣ端末０２は検索結果を受信すると、例えば、図８に示すような商品他受払表（日報）（帳票）を、ＰＣ端末０２の表示部に表示又は、通信可能なプリンタから印刷することが可能である。

また、ＰＣ端末０２は、処理０９（車上受払処理）より、その日に配送車２３に積み込んだ物品、又は、次の日に配送車２３に積み込むために、事前準備された物品（プレロード）の種類と数量の入力を行うと、車上受払伝票１０を出力し、入力情報を管理サーバ０１へ送信する。

なお、プレロードとは、営業所内にはあるが倉庫からは取り出され、配送車への積み込み待ちの状態になっている物品をさす。

管理サーバ０１は、ＰＣ端末０２より受信した車上受払入力情報（図６の画面から入力されるデータ）を、入出庫ワークデータ１６（図２０（ｃ））に一時的に記憶しておく。

図６に、ＰＣ端末０２における、車上受払入力の入力画面を示す。

図９に、車上受払伝票の具体例を示す。

また、ＰＣ端末０２は、現在のリアルタイムの倉庫内の在庫情報として、処理０５（商品他受払表（プレロード））を実行することにより、管理サーバ０１の営業所在庫データ１３、入出庫実績データ１５、入出庫ワークデータ１６より該当データを参照し、商品他受払表（プレロード）０６を出力する。

図７に、ＰＣ端末０２における、商品他受払表（プレロード）の入力画面を示す。

図１０に、商品他受払表（プレロード）の具体例を示す。

携帯端末０３は、車上積み降し処理１１より配送車に載せる物品の種類、数量の入力を行うと積み降しモニタ１２を出力し、ＨＴ積み降しデータ１８を作成し、携帯端末０３内に記憶しておく。

また、管理サーバ０１は、携帯端末０３より送信されてきたＨＴ積み降しデータ１８を、ネットワーク０４経由で受信し、ＨＴ積み降しデータ１９として、一時フォルダ２１に格納する。

＜図２の説明＞
図２は、管理サーバ０１及びＰＣ端末０２のハードウエア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Basic Input / Output System)やオペレーティングシステムプログラム（以下、ＯＳ）や、管理サーバ０１又はＰＣ端末０２の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するためのプログラムは外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

さらに、本発明に係わるプログラムが用いる定義ファイル及び各種情報テーブルは外部メモリ２１１に格納されており、これらについての詳細な説明は後述する。

＜図３の説明＞
図３は従来の実施形態の在庫管理システムの業務フローを示す図である。

朝、セールスオペレーターは業務開始と同時に携帯端末０３へ最新の車両在庫情報（車両在庫データ）や、その他のマスタ情報を管理サーバ０１より受信する。（処理３０１）

受信後、携帯端末０３より自身の車両の車上在庫表を出力し、車両内の在庫状況を確認する。

次に、本日の訪問・納品予定と車両内にある在庫を比較し、車両内の商品在庫で過不足があれば、必要数の商品を車両へ積み込み、または降ろす作業を行う。（処理３０２）

積み込み、降ろしの作業が終了すれば、その商品毎の積み込み・降し数量を携帯端末０３へ入力し、「積み降しデータ」として格納する。その後、ルート業務へ出発する。

日中の業務が終了し、営業所へ帰所後、車両内の商品在庫の棚卸を行う。携帯端末０３に日中の業務で使用した商品の数量が加味された理論在庫数が表示され、先ほど行った棚卸数量と一致しているか確認し入力し「車上在庫データ」として格納する。不一致であった場合はその過不足数量を調査する。棚卸数が確定した後、携帯端末０３より当日の最終車上在庫表を出力する。

次に翌日の朝積み込み分を、夜の内に積み込む場合がある。この場合は、翌日分の積み込み・降ろし作業が完了した後、携帯端末０３より「翌日積み込み・降ろし」処理を選択し、その数量を各々入力し「翌日積み降しデータ」として格納する。（処理３０３）

入力作業完了によりその日の携帯端末０３での作業が完了であるため、携帯端末０３に格納された情報を管理サーバ０１へ送信する。（処理３０４）

送信された「積み降しデータ」、「車上在庫データ」はサーバの夜間バッチ処理にて更新され「車上在庫データ」、「入出庫実績」として作成される。（処理３０５）

このとき、積み降しデータの更新により車両在庫数が増減し、これに合わせて営業所在庫データも増減する。関係は以下の通りである。

・積込データ 車上在庫データ：数量増加 営業所在庫データ：数量減少
・降しデータ 車上在庫データ：数量減少 営業所在庫データ：数量増加

よって、携帯端末０３で入力された「積み降しデータ」はリアルタイムに営業所在庫データに反映されるのではなく、夜間バッチ時に反映される。そのため、営業所在庫データは夜間バッチが実行されないと在庫が確定しないことになる。

翌日セールスオペレーターが携帯端末０３に受信した時には、夜間バッチで作成された「車上在庫データ」が最新の車両在庫情報としてあらたに格納される。（処理３０６）

その後、セールスオペレーターが積み込み・降ろし作業を行い、携帯端末０３に入力し（処理３０７）、積み降しデータとして格納しても、リアルタイムに入出庫実績データとして更新されない。

商品管理者がこの時に［図８］商品他受払表（日報）を出力しようとして［図５］の画面より情報を入力し出力しても、［図８］商品他受払表（日報）は入出庫実績データより出力されるため、その日携帯端末０３で入力された積み降しデータは入出庫実績データには反映されていないため、携帯端末０３の入力データが加味されていない状態で出力されることになる。（処理３０８）

これにより、［図５］により出力された［図８］商品他受払表（日報）では営業所の在庫棚卸し作業は困難になる。

＜図４の説明＞
図４は本発明の実施形態の在庫管理システムの業務フローを示す図である。

セールスオペレーターは日中の業務が終了し、帰所後に翌々日（本日８／３１の場合、９／２）の朝の積み込み分として必要な商品及びその数量を「商品依頼書」に記入し、商品管理者へ提出する。（処理４０１）

翌日（９／１） セールスオペレーター（ルート）は携帯端末０３に必要情報を受信して日中業務へ出発する。（処理４０２）

商品管理者は提出された「商品依頼書」をもとにセールスオペレーター毎に積み込み・降し分をＰＣ端末０２から［図６］の車上受払処理にて翌日分とし入力し、管理サーバ０１のＤＢへ入出庫ワークデータとして格納する。（処理４０３）

セールスオペレーターは帰所後に翌日分として積み込み・降しの入力を行う必要はなくなる。

夜間バッチ処理にて送信された当日「積み降しデータ」、「車上在庫データ」は更新され「車上在庫データ」、「入出庫実績データ」として作成される。またこの時、入出庫ワークデータも入出庫実績データに更新される。（処理４０４）

次日（９／２） セールスオペレーターが朝、携帯端末０３に受信すると、車上在庫データが前日（９／１）に商品管理者により入力された翌日積み込み分が反映された内容で携帯端末０３へ送られてくる。（処理４０５）

当日（９／２）の朝にセールスオペレーターが急に、新たに配送する商品が必要になり、倉庫から商品を出庫し車両へ積み込みを行い、あわせてその内容（商品やその数量など）を携帯端末０３へ入力する。その時、携帯端末０３より出力される「積み込みモニタ」（このモニタには、入出庫ワークデータに示す出庫した商品やその数量などが記載されている）を商品管理者へ提出する。（処理４０６）

商品管理者はその「積み込みモニタ」を確認し、ＰＣ端末０２から［図６］の車上受払処理にて当日分とし入力し、管理サーバ０１のＤＢへ入出庫ワークデータとして格納する。（処理４０７）

営業所在庫の棚卸時には、ＰＣ端末０２から［図１０］の商品他受払表（プレロード）を出力する。（処理４０８）

［図１０］商品他受払表（プレロード）は前日までの入出庫実績データと入出庫ワークデータを参照して出力されるため、現在のリアルな在庫を確認できる。この帳票を用いて営業所在庫の棚卸が効率的に行えることになる。

当日（９／２）の夜間バッチでは、携帯端末０３より入力されサーバへ送信された当日の積み降しデータと、ＰＣ端末０２から［図６］の車上受払処理にて入力された当日の入出庫ワークデータとどちらも同様の内容のデータが存在するが、それは夜間バッチがデータの内容を判断し、入出庫ワークデータは更新対象外とし、携帯端末０３にて入力された積み降しデータのみ更新対象として更新を実施する。（処理４０９）

＜図１１の説明＞
図１１は、ＰＣ端末０２のＣＰＵ２０１によって実行されるメニュー選択処理を説明するためのフローチャートである。

図１１に示すステップＳ１１０１からステップＳ１１０４の処理は、ＰＣ端末０２のＣＰＵ２０１によって実行される。即ち、ＰＣ端末０２のＣＰＵ２０１がＰＣ端末０２の外部メモリ２１１等に格納されるプログラムを実行することにより、ＰＣ端末０２は図１１に示すように機能する。

まず、ＰＣ端末０２のＣＰＵ２０１は、ＰＣ端末０２のＣＲＴ２１０等の表示部に不図示のメニュー画面を表示する。この表示画面は、「商品他受払表（日報）出力処理」、「商品他受払表（プレロード）出力処理」、「車上受払入力処理」の３の処理を選択可能な画面である。

そして、ＰＣ端末０２のＣＰＵ２０１は、当該メニュー画面を介して商品管理者からの当該３つの処理の選択の指示を受け付ける（ステップＳ１１０１）。

次に、ＰＣ端末０２のＣＰＵ２０１は、商品管理者からの選択指示を受け付けると、選択された処理を識別するデータを管理サーバに送信し、管理サーバから、選択された処理に対応する処理画面を表示するための情報を受信し、その情報に基づいて、選択された処理に対応する処理画面を表示する。

ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「商品他受払表（日報）出力処理」の選択を受け付けると（ステップＳ１１０２：ＹＥＳ）、図１３に示す商品他受払表（日報）出力処理に移行する。

また、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「商品他受払表（プレロード）出力処理」の選択を受け付けると（ステップＳ１１０３：ＹＥＳ）、図１４に示す商品他受払表（プレロード）出力処理に移行する。

また、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「車上受払入力処理」の選択を受け付けると（ステップＳ１１０４：ＹＥＳ）、図１２に示す車上受払入力処理に移行する。

＜図１２の説明＞
図１２は、ＰＣ端末０２のＣＰＵ２０１によって実行される車上受払入力処理を説明するためのフローチャートである。

本フローチャートは、商品管理者が当日に倉庫内の商品の出し入れの数を管理サーバに登録するための処理である。

図１２に示すステップＳ１２０１からステップＳ１２１０の処理は、ＰＣ端末０２のＣＰＵ２０１によって実行される。即ち、ＰＣ端末０２のＣＰＵ２０１がＰＣ端末０２の外部メモリ２１１等に格納されるプログラムを実行することにより、ＰＣ端末０２は図１２に示すように機能する。

まず、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「車上受払入力処理」の選択を受け付けると（ステップＳ１１０４：ＹＥＳ）、車上受払入力処理を実行するための初期画面（図６）を表示部に表示する（ステップＳ１２０１）。

この画面は、ステップＳ１１０１で選択された「車上受払入力処理」に対応する処理画面を管理サーバから受信し、初期画面（図６）を表示される。

次に、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から処理の終了指示を受け付けると（ステップＳ１２０２：ＹＥＳ）、初期画面（図６）の表示を終了し、図１１のステップＳ１１０１に戻り、メニュー画面を表示する。

ＰＣ端末０２のＣＰＵ２０１は、ステップＳ１２０１で初期画面（図６）を表示部に表示し、表示された各項目の入力を受け付ける。

例えば、初期画面（図６）に表示された「伝票番号」、「配送営業所コード（倉庫を識別する情報）」、「担当ルート（配送担当者）」、「当翌区分」、「受払区分」、「商品コード」、「商品名」、「入数」、「ケース数量」、「バラ数量」などの入力や、「終了」ボタン、「クリア」ボタン、「検索」ボタン、「実行」ボタン、「新規」ボタン、「修正」ボタンなどを押下することによる指示を受け付ける。

例えば、図２０（Ｃ）に示す入出庫ワークデータを新規に登録する場合は、「伝票番号」、「配送営業所コード（倉庫を識別する情報）」、「担当ルート（配送担当者）」、「当翌区分」、「受払区分」、「商品コード」、「商品名」、「入数」、「ケース数量」、「バラ数量」などを入力し、「新規」ボタン６０３を押下する。

受払区分が「営業所→車上」（営業所から車上に商品を出庫することを意味している）が選択され、「入数」（出庫数）に数値が入力することで、当日に倉庫から出庫する商品の出庫数を入力することができる。

また、すでに入出庫ワークデータ（図２０（Ｃ））に登録されているデータを修正する場合は、「伝票番号」などを入力して、「検索」ボタンを押下する。そして、入力した「伝票番号」に対応する各データ（「商品名」や「入数」などの図６に表示された各項目のデータ）が表示される。そして、表示されたデータをＰＣ端末のキーボード２０９などの入力手段から該データの修正を入力した後、「修正」ボタン６０４を押下すると、入力されたデータ（修正データ）を管理サーバに送信するので、入出庫ワークデータ（図２０（Ｃ））に登録されているデータを修正することができる。

このように、ステップＳ１２０１で表示された初期画面（図６）は、表示された各項目の入力を受け付ける。

以下、車上受払入力処理（図１２のフローチャート）の説明に戻る。

ＰＣ端末０２のＣＰＵ２０１は、初期画面（図６）を介して商品管理者から登録区分の入力を受け付ける（ステップＳ１２０３）。

具体的には、商品管理者から初期画面（図６）に表示された「新規」ボタン６０３又は、「修正」ボタン６０４の押下を受け付ける。

そして、商品管理者から「新規」ボタン６０３又は、「修正」ボタン６０４が押下されると、どのボタンが押下されたかを判定し（ステップＳ１２０４）、「新規」ボタン６０３が押下されたと判定した場合は（ステップ１２０４：修正）、ステップＳ１２０５に処理を移行する。一方、「修正」ボタン６０４が押下されたと判定した場合は（ステップＳ１２０４：新規）、ステップＳ１２０９の処理に移行する。

ＰＣ端末０２のＣＰＵ２０１は、ステップＳ１２０５において、初期画面から「伝票番号」の入力を受け付けた後に、「検索」ボタン６０１が押下されたことを認識すると、管理サーバに当該入力された「伝票番号」に対応するデータ（入出庫ワークデータ）の抽出を要求する（ステップＳ１２０５）。

そして、ＰＣ端末０２のＣＰＵ２０１は、管理サーバから、当該入力された伝票番号に対応するデータ（入出庫ワークデータ）を取得すると、当該取得したデータを初期画面の各項目に表示する（ステップＳ１２０６）。

そして、ＰＣ端末０２のＣＰＵ２０１は、当該表示された初期画面を介して商品管理者から、入出庫ワークデータを修正するデータを受け付け（ステップＳ１２０７）、受け付けた修正するデータの更新要求を管理サーバに送信する（ステップＳ１２０８）。そして、更新要求が正常に完了すればＰＣ端末０２の画面表示をクリアーしステップＳ１２０１の初期画面を表示する。

また、ＰＣ端末０２のＣＰＵ２０１は、「新規」ボタン６０３が押下されたと判定した場合は（ステップ１２０４：修正）、商品管理者から初期画面を介して入力されたデータ（入出庫ワークデータ）の入力を受け付ける（ステップＳ１２０９）。そして、ＰＣ端末０２のＣＰＵ２０１は、受け付けたデータを管理サーバに登録するべく該管理サーバに更新要求を送信する（ステップＳ１２１０）。そして、更新要求が正常に完了すればＰＣ端末０２の画面表示をクリアーしステップＳ１２０１の初期画面を表示する。

＜図１３の説明＞
図１３は、ＰＣ端末０２のＣＰＵ２０１によって実行される商品他受払表（日報）出力処理を説明するためのフローチャートである。

本フローチャートは、商品管理者が、前日までに倉庫内のどの商品をどれだけ外に出したか、それとも受け入れたかを出力することで把握するための処理である。

図１３に示すステップＳ１３０１からステップＳ１３０６の処理は、ＰＣ端末０２のＣＰＵ２０１によって実行される。即ち、ＰＣ端末０２のＣＰＵ２０１がＰＣ端末０２の外部メモリ２１１等に格納されるプログラムを実行することにより、ＰＣ端末０２は図１３に示すように機能する。

まず、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「商品他受払表（日報）出力処理」の選択を受け付けると（ステップＳ１１０２：ＹＥＳ）、図５に示す「商品他受払表（日報）」の初期画面（出力条件入力画面）をＰＣ端末０２の表示部に表示する（ステップＳ１３０１）。

この画面は、ステップＳ１１０１で選択された「商品他受払表（日報）出力処理」に対応する処理画面を管理サーバから受信し、初期画面（図５）を表示される。

ＰＣ端末０２のＣＰＵ２０１は、終了指示を受け付けたかを判定する（ステップＳ１３０２）。そして、終了指示を受け付けた場合は（ステップＳ１３０２：ＹＥＳ）、初期画面の表示を終了し、図１１のステップＳ１１０１で表示された画面をＰＣ端末０２に表示する。

また、ＰＣ端末０２のＣＰＵ２０１は、終了指示を受け付けなければ（ステップＳ１３０２：ＮＯ）、図５の初期画面を介して出力条件の入力を受け付ける（ステップＳ１３０３）。

そして、ＰＣ端末０２のＣＰＵ２０１は、ステップＳ１３０３で入力された出力条件を管理サーバに送信し、当該入力された出力条件に対応するデータの抽出要求を行う（ステップＳ１３０４）。

図５に出力条件入力画面の一例を示す。

図５の画面には、「終了」ボタン、「エクセル出力」ボタン５０１、「プレビュー」ボタン５０２、「印刷」ボタン５０３の各オブジェクトと、出力条件として「出力日付」、「配送営業所コード（倉庫）」、「商品コード」を入力する領域を備える。

倉庫を特定する配送営業所コードや、商品を特定する商品コードなどの出力条件が入力され、「エクセル出力」ボタン５０１、「プレビュー」ボタン５０２、「印刷」ボタン５０３のいずれかのボタンが押下されると、入力された出力条件に対応するデータの抽出要求をステップＳ１３０４で行う。

そして、ＰＣ端末０２のＣＰＵ２０１は、管理サーバから当該入力された出力条件に対応するデータ（抽出結果）を受信すると（ステップＳ１３０５）、抽出結果をＰＣ端末０２のＨＤＤへ保存（記憶）するとともに、押下された「エクセル出力」ボタン５０１、「プレビュー」ボタン５０２、「印刷」ボタン５０３のいずれかのボタンに対応した出力を行う。ここでは、例えば、図８に示すような帳票（印刷出力結果）を出力する。

そして、ＰＣ端末０２のＣＰＵ２０１は、印刷出力または、ＨＤＤの保存が正常に完了したとＰＣ端末０２が判断した場合は、ステップ１３０１の初期画面を再表示する。このとき前回の入力指示情報はクリアーする。

＜図１４の説明＞
図１４は、ＰＣ端末０２のＣＰＵ２０１によって実行される商品他受払表（プレロード）出力処理を説明するためのフローチャートである。これは、商品管理者が現在の倉庫内の在庫情報（在庫数など）を出力するための処理である。

図１４に示すステップＳ１４０１からステップＳ１４０６の処理は、ＰＣ端末０２のＣＰＵ２０１によって実行される。即ち、ＰＣ端末０２のＣＰＵ２０１がＰＣ端末０２の外部メモリ２１１等に格納されるプログラムを実行することにより、ＰＣ端末０２は図１４に示すように機能する。

まず、ＰＣ端末０２のＣＰＵ２０１は、商品管理者から「商品他受払表（プレロード）出力処理」の選択を受け付けると（ステップＳ１１０３：ＹＥＳ）、図７に示す「商品他受払表（プレロード）」の初期画面（出力条件入力画面）をＰＣ端末０２の表示部に表示する（ステップＳ１４０１）。

この画面は、ステップＳ１１０１で選択された「商品他受払表（プレロード）出力処理」に対応する処理画面を管理サーバから受信し、初期画面（図７）を表示される。

ＰＣ端末０２のＣＰＵ２０１は、終了指示を受け付けたかを判定する（ステップＳ１４０２）。そして、終了指示を受け付けた場合は（ステップＳ１４０２：ＹＥＳ）、初期画面の表示を終了し、図１１のステップＳ１１０１で表示された画面をＰＣ端末０２に表示する。

また、ＰＣ端末０２のＣＰＵ２０１は、終了指示を受け付けなければ（ステップＳ１４０２：ＮＯ）、図７の初期画面を介して出力条件の入力を受け付ける（ステップＳ１４０３）。

そして、ＰＣ端末０２のＣＰＵ２０１は、ステップＳ１４０３で入力された出力条件を管理サーバに送信し、当該入力された出力条件に対応するデータの抽出要求を行う（ステップＳ１４０４）。

図７に出力条件入力画面の一例を示す。

図７の画面には、「終了」ボタン、「エクセル出力」ボタン７０１、「プレビュー」ボタン７０２、「印刷」ボタン７０３の各オブジェクトと、現在の処理日時と、出力条件として「配送営業所コード（倉庫）」、「商品コード」を入力する領域と、出力順序を選択するラジオボタンを備える。

倉庫を特定する配送営業所コードや、商品を特定する商品コードなどの出力条件が入力され、「エクセル出力」ボタン７０１、「プレビュー」ボタン７０２、「印刷」ボタン７０３のいずれかのボタンが押下されると、入力された出力条件に対応するデータの抽出要求をステップＳ１４０４で行う。

そして、ＰＣ端末０２のＣＰＵ２０１は、管理サーバから当該入力された出力条件に対応するデータ（抽出結果）を受信すると（ステップＳ１４０５）、抽出結果をＰＣ端末０２のＨＤＤへ保存（記憶）するとともに、押下された「エクセル出力」ボタン７０１、「プレビュー」ボタン７０２、「印刷」ボタン７０３のいずれかのボタンに対応した出力を行う。ここでは、例えば、図１０に示すような帳票（印刷出力結果）を出力する（ステップＳ１４０６）。

そして、ＰＣ端末０２のＣＰＵ２０１は、印刷出力または、ＨＤＤの保存が正常に完了したとＰＣ端末０２が判断した場合は、ステップ１４０１の初期画面を再表示する。このとき前回の入力指示情報はクリアーする。

＜図１５の説明＞
図１５は、管理サーバ０１のＣＰＵ２０１によって実行される処理を説明するためのフローチャートである。

図１５に示すステップＳ１５０１からステップＳ１５０４の処理は、管理サーバ０１のＣＰＵ２０１によって実行される。即ち、管理サーバ０１のＣＰＵ２０１が管理サーバ０１の外部メモリ２１１等に格納されるプログラムを実行することにより、管理サーバ０１は図１５に示すように機能する。

まず、管理サーバ０１のＣＰＵ２０１は、ＰＣ端末０２から、図１１のステップＳ１１０１で選択された処理を識別するデータを受信する。

そして、管理サーバ０１のＣＰＵ２０１は、受信したデータに従って、選択された処理が、「車上受払入力処理」であると判定された場合は（ステップＳ１５０１：ＹＥＳ）、図６に示す「車上受払入力処理」の初期画面の情報をＰＣ端末０２に送信し、図１６に示す車上受払処理を実行する。

また、管理サーバ０１のＣＰＵ２０１は、受信したデータに従って、選択された処理が、「商品他受払表（日報）処理」であると判定された場合は（ステップＳ１５０２：ＹＥＳ）、図５に示す「商品他受払表（日報）」の初期画面の情報をＰＣ端末０２に送信し、図１７に示す商品他受払表（日報）処理を実行する。

また、管理サーバ０１のＣＰＵ２０１は、受信したデータに従って、選択された処理が、「商品他受払表（プレロード）出力処理」であると判定された場合は（ステップＳ１５０３：ＹＥＳ）、図７に示す「商品他受払表（プレロード）出力」の初期画面の情報をＰＣ端末０２に送信し、図１８に示す商品他受払表（プレロード）出力処理を実行する。

また、管理サーバ０１のＣＰＵ２０１は、ＯＳから現在の時間を取得して、現在の日時が、予め設定された、夜間バッチ処理（更新処理）を実行する時間（所定の時間）か否かを判定し（ステップＳ１５０４）、現在の時間が所定の時間であると判定された場合は（ステップＳ１５０４：ＹＥＳ）、図１９に示すバッチ処理を実行する。

ここで、夜間バッチ処理は、ルートマン（配送担当者）が帰社後にハンディターミナル内のデータ（売上数や車上在庫数や倉庫に積み降ろした商品の数など）を管理サーバに送信した後の夜に実行される。すなわち、夜間バッチ処理は、１日１回実行される。

＜図１６の説明＞
図１６は、管理サーバ０１のＣＰＵ２０１によって実行される車上受払処理を説明するためのフローチャートである。

図１６に示すステップＳ１６０１からステップＳ１６０６の処理は、管理サーバ０１のＣＰＵ２０１によって実行される。即ち、管理サーバ０１のＣＰＵ２０１が管理サーバ０１の外部メモリ２１１等に格納されるプログラムを実行することにより、管理サーバ０１は図１６に示すように機能する。

まず、管理サーバ０１のＣＰＵ２０１は、図１２のステップＳ１２０５でＰＣ端末０２が送信した検索要求（修正要求）、又はステップＳ１２１０でＰＣ端末０２が送信した登録要求（新規登録の要求）のどちらかを受信する。

そして、管理サーバ０１のＣＰＵ２０１は、ステップＳ１２０５でＰＣ端末０２が送信した検索要求（修正要求）を受信したと判定した場合は（ステップＳ１６０１：ＹＥＳ）、ステップＳ１６０２に処理を移行する。一方、ステップＳ１２０５でＰＣ端末０２が送信した検索要求（修正要求）を受信していないと判定した場合は（ステップＳ１６０１：ＮＯ）、ステップＳ１６０５に処理を移行する。

そして、ステップＳ１６０２では、管理サーバ０１のＣＰＵ２０１は、修正要求を受信した場合、受信した要求に含まれる出力条件（図６で入力された検索条件）に対応するデータを、管理サーバのデータベースの入出庫ワークデータから検索して抽出する。そして、抽出されたデータ（検索結果）をＰＣ端末０２に送信する。ＰＣ端末は、ここで送信された検索結果を受信すると、図１２のステップＳ１２０６で検索結果を表示する。

次に、管理サーバ０１のＣＰＵ２０１は、図１２のステップＳ１２０８でＰＣ端末０２が送信した「修正するデータの更新要求」を受け付け（受付）たか否かを判定する（ステップＳ１６０３）。

そして、管理サーバ０１のＣＰＵ２０１は、「修正するデータの更新要求」を受け付けたと判定した場合は（ステップＳ１６０３：ＹＥＳ）、「修正するデータの更新要求」に含まれる修正データを、入出庫ワークデータに登録されたデータに反映させ、入出庫ワークデータを更新する（ステップＳ１６０４）。

そして、管理サーバ０１のＣＰＵ２０１は、正常に更新されると、図１５のステップＳ１５０１に処理を移行する。

例えば、出力条件（図６で入力された検索条件）として、伝票番号を受信した場合、ステップＳ１６０２で当該伝票番号に一致する入出庫ワークデータを検索し、ステップＳ１６０４で当該検索された入出庫ワークデータに、ＰＣ端末から受信した修正データを反映させ、入出庫ワークデータを更新する。そして、管理サーバ０１のＣＰＵ２０１は、正常に更新されると、図１５のステップＳ１５０１に処理を移行する。

また、ステップＳ１６０５において、管理サーバ０１のＣＰＵ２０１は、ステップＳ１２１０でＰＣ端末０２が送信した登録要求（新規登録の要求）を受信した（受け付けた）と判定した場合（ステップＳ１６０５：ＹＥＳ）、ＰＣ端末から受信した更新要求に含まれるデータ（新規に登録するデータであり、図６で入力されたデータ）を入出庫ワークデータに新規に登録する（ステップＳ１６０６）。そして、管理サーバ０１のＣＰＵ２０１は、正常に登録されると、図１５のステップＳ１５０１に処理を移行する。

一方、上記ステップＳ１６０５において、管理サーバ０１のＣＰＵ２０１は、ステップＳ１２１０でＰＣ端末０２が送信した登録要求（新規登録の要求）を受信していないと判定した場合（ステップＳ１６０５：ＮＯ）、そのまま図１５のステップＳ１５０１に処理を移行する。

＜図１７の説明＞
図１７は、管理サーバ０１のＣＰＵ２０１によって実行される商品他受払表（日報）処理（商品他受払（日報）抽出処理）を説明するためのフローチャートである。

図１７に示すステップＳ１７０１からステップＳ１７０３の処理は、管理サーバ０１のＣＰＵ２０１によって実行される。即ち、管理サーバ０１のＣＰＵ２０１が管理サーバ０１の外部メモリ２１１等に格納されるプログラムを実行することにより、管理サーバ０１は図１７に示すように機能する。

まず、管理サーバ０１のＣＰＵ２０１は、図１３のステップＳ１３０４でＰＣ端末が送信したデータの抽出要求を受信する（ステップＳ１７０１）。

そして、管理サーバ０１のＣＰＵ２０１は、当該抽出要求に含まれる出力条件に一致する入出庫実績データを、データベース２０の中から検索して抽出する（ステップＳ１７０２）。

例えば、出力条件として配送営業所コード（営業所コードとも言い、商品が保管された倉庫を識別するデータである）が「１００００」 である場合、配送営業所コードが「１００００」である入出庫実績データをデータベース内から検索する。そして、配送営業所コードが「１００００」である入出庫実績データを取得する。

ここで、図２０（ｇ）に示す入出庫実績データのテーブルには、配送営業所コードの項目を示していないが、この入出庫実績データのテーブルが配送営業所コード毎に記憶されているため、配送営業所コードに一致する入出庫実績データを検索して取得することは可能である。

また、管理サーバ０１のＣＰＵ２０１は、出力条件に一致するデータを営業所在庫データ（図２０（ｅ））内から検索して取得する。例えば、配送営業所コードが「１００００」である営業所在庫データ（図２０（ｅ））（倉庫在庫データともいう）を取得する。

その後、管理サーバ０１のＣＰＵ２０１は、配送営業所コードが「１００００」である営業所在庫データ（図２０（ｅ））と、取得した配送営業所コードが「１００００」である入出庫実績データとから、配送営業所コードが「１００００」（倉庫）の商品毎の数量（在庫数）を集計する。

すなわち、配送営業所コードから特定される倉庫内の商品ごとの在庫数を算出する。

例えば、営業所在庫データ［図２０（ｅ）］内の配送営業所コードが「１００００」のレコードの情報を取得して、当該営業所在庫データ［図２０（ｅ）］から取得した情報と、配送営業所コードが「１００００」である入出庫実績データとから、営業所、商品ごとに数量（在庫数）を集計する。

そして、管理サーバ０１のＣＰＵ２０１は、当該集計された在庫数を含む抽出結果（倉庫内の商品ごとの在庫数）をＰＣ端末０２に送信する（ステップＳ１７０３）。そして、ＰＣ端末０２は、この抽出結果を図１３のステップＳ１３０５で受信する。

＜図１８の説明＞
図１８は、管理サーバ０１のＣＰＵ２０１によって実行される商品他受払表（プレロード）出力処理を説明するためのフローチャートである。

図１８に示すステップＳ１８０１からステップＳ１８０３の処理は、管理サーバ０１のＣＰＵ２０１によって実行される。即ち、管理サーバ０１のＣＰＵ２０１が管理サーバ０１の外部メモリ２１１等に格納されるプログラムを実行することにより、管理サーバ０１は図１８に示すように機能する。

そして、管理サーバ０１のＣＰＵ２０１は、ステップＳ１４０４でＰＣ端末から送信された抽出要求を受信する（ステップＳ１８０１）。すなわち、ＰＣ端末から現在の倉庫内の商品の在庫数の問い合わせを受け付ける。

次に、管理サーバ０１のＣＰＵ２０１は、当該抽出要求に含まれる出力条件（図７の画面で入力されたデータ）に一致するデータを、管理サーバ０１のＤＢの入出庫実績データの中から検索する。

例えば、出力条件として配送営業所コード（営業所コードとも言い、商品が保管された倉庫を識別するデータである）が「１００００」である場合、配送営業所コードが「１００００」である入出庫実績データをデータベース内から検索する。そして、配送営業所コードが「１００００」である入出庫実績データを取得する。

次に、管理サーバ０１のＣＰＵ２０１は、当該出力条件に一致するデータを、管理サーバ０１のＤＢの入出庫ワークデータの中から検索する（ステップＳ１８０２）。例えば、配送営業所コードが「１００００」である入出庫ワークデータをデータベース内から検索する。なお、ここでは、ステップＳ１８０１で問い合わせを受け付けた当日に、ステップＳ１６０３又はステップＳ１６０５で受け付けた入出庫ワークデータの中から、該出力条件に一致するデータの検索を行う。

ここで、図２０（ｃ）に示す入出庫ワークデータのテーブルには、配送営業所コードの項目を示していないが、この入出庫ワークデータのテーブルが配送営業所コード毎に記憶されているため、配送営業所コードに一致する入出庫ワークデータを検索して取得することは可能である。

次に、管理サーバ０１のＣＰＵ２０１は、出力条件に一致するデータを営業所在庫データ（図２０（ｅ））内から検索して取得する。例えば、配送営業所コードが「１００００」である営業所在庫データ（図２０（ｅ））を取得する。

その後、管理サーバ０１のＣＰＵ２０１は、ここで取得した、配送営業所コードが「１００００」である営業所在庫データ（図２０（ｅ））と、入出庫実績データ、入出庫ワークデータとから、各配送営業所コードが「１００００」（倉庫）の商品毎の数量（在庫数）を集計する（ステップＳ１８０２）。

すなわち、管理サーバ０１のＣＰＵ２０１は、このようにして検索され得られた、営業所在庫データと、入出庫実績データ、入出庫ワークデータの在庫数を商品毎に加算して、商品ごとの在庫数を算出する。このようにして、配送営業所コードから特定される倉庫内の商品ごとの在庫数を算出する。

そして、管理サーバ０１のＣＰＵ２０１は、当該集計された在庫数を含む抽出結果（倉庫内の商品ごとの在庫数）をＰＣ端末０２に送信（出力）する（ステップＳ１８０３）。そして、ＰＣ端末０２は、この抽出結果をステップＳ１４０５で受信する。ここで、集計された在庫数を含む抽出結果を管理サーバの表示部に表示（出力）させる構成や、管理サーバと通信可能なプリンタに印刷（出力）する構成でもよい。

以上の通り、ＰＣ端末からの現在の倉庫内の商品の在庫数の問合せを受付け、
倉庫内の商品の在庫数を示す倉庫在庫データと、当日に倉庫から出庫した商品の個数実績を示す出庫実績データと、問合せの当日に、ステップＳ１６０１又はステップＳ１６０５に受け付けた出庫ワークデータとから、現在の倉庫内の在庫数を算出し、算出された現在の倉庫内の在庫数を出力するので、倉庫内の商品の在庫情報（在庫数）を１日１回、バッチ処理等によりまとめて更新する仕組みで、倉庫内の商品の在庫数が急遽変わった場合でも、商品管理者は、容易に現在の倉庫内の商品ごとの在庫数を把握することができる。即ち、（多くの時間が掛かる）データベース内のデータ更新処理を行わず、上記構成を取るので、現在の倉庫内の商品の在庫数を早く出力することができる。

＜図１９の説明＞
図１９は、管理サーバ０１のＣＰＵ２０１によって実行される夜間バッチ処理を説明するためのフローチャートである。

図１９に示すステップＳ１９０１からステップＳ１９０１の処理は、管理サーバ０１のＣＰＵ２０１によって実行される。即ち、管理サーバ０１のＣＰＵ２０１が管理サーバ０１の外部メモリ２１１等に格納されるプログラムを実行することにより、管理サーバ０１は図１９に示すように機能する。

まず、管理サーバ０１のＣＰＵ２０１は、ＨＴから取得したデータを１件ずつ（図２０（ｄ）の１レコード毎）読み込む（ステップＳ１９０１）。ここで、読み込むデータには、少なくとも、ＨＴ積み降ろしデータ（図２０（ｄ））に示す各項目のデータを含む。

そして、ＨＴから取得したデータを全て読み込んだか否かを判定し（ステップＳ１９０２）、全て読み込んだと判定された場合は（ステップＳ１９０２：ＹＥＳ）、ステップＳ１９０６の処理に移行し、入出庫ワークデータの読み込み処理を行う（ステップＳ１９０６）。

一方、まだ、全て読み込んでいないと判定された場合は（ステップＳ１９０２：ＮＯ）、読み込んだＨＴ積み降ろしデータから、入出庫実績データ（図２０（ｇ））を生成する（ステップＳ１９０３）。すなわち、読み込んだＨＴ積み降ろしデータに、伝票番号を付与して入出庫実績データに登録する。

ここで、倉庫から出庫した商品の個数や、倉庫に入庫した商品の個数が含まれるデータを入出庫実績データとして説明しているが、倉庫に入庫した商品の個数を含まない、当日に倉庫から出庫した商品の個数の実績（個数実績）のみを示すデータは出庫実績データと表す。ここで、出庫実績データで本実施例を説明する場合は、本実施例の入出庫実績データを出庫ワークデータに置き換えればよい。

例えば、図２０（ｄ）にあるＨＴ積み下ろしデータ（伝票日付：２００８０９０１、伝票区分：当日積込、当日降し、ルート：１０１、商品：１０００）から、図２０（ｇ）にある入出庫実績データ（伝票番号：１２３４５６９のレコード）を生成する。

そして、ここで生成された入出庫実績データの伝票区分が、「翌日車上積込」又は「翌日車上降し」か否かを判定する（ステップＳ１９０４）。すなわち、翌日には車上の在庫数が変動することを示すデータか否かを判定する。

そして、伝票区分が「翌日車上積込」又は「翌日車上卸し」（翌日に車上の在庫数が変動するデータ）であると判定された場合は（ステップＳ１９０４：ＹＥＳ）、ＨＴ車上積み降ろしデータの数量を車上在庫データ（図２０（ｆ））の在庫数に反映させて車上在庫データ（図２０（ｆ））の在庫数を更新する（ステップＳ１９０５）。

例えば、配送営業所コードが「１００００」で、ルート（配送担当者）が「１０１」で、商品コードが「１０００」のＨＴ車上積み降ろしデータの伝票区分が「翌日積み降ろし」で、その数量が２０であった場合、このデータは、翌日、商品コードが「１０００」の商品を配送担当者の車両から２０個積み降ろして、配送営業所コードが「１００００」の倉庫に入れることを示している。

したがって、車上在庫データ（図２０（ｆ））に記憶された、ルート（配送担当者）が「１０１」の車両内の商品コードが「１０００」の商品の在庫数から２０個差し引いた数を新たな在庫数として車上在庫データ（図２０（ｆ））に記憶させる処理を行う。

次に、管理サーバ０１のＣＰＵ２０１は、ステップＳ１９０５で車上在庫データ（図２０（ｆ））の在庫数の更新処理を実行すると、ステップＳ１９０１に戻り、ＨＴから取得した次のデータ（ＨＴ積み降ろしデータ）をステップＳ１９０１で読み込む。

また、管理サーバ０１のＣＰＵ２０１は、ステップＳ１９０４で伝票区分が、「翌日車上積込」又は「翌日車上卸し」ではない（翌日に車上の在庫数が変動するデータではない）と判定された場合（ステップＳ１９０４：ＮＯ）、ステップＳ１９０１に戻り、ＨＴから取得した次のデータ（ＨＴ積み降ろしデータ）をステップＳ１９０１で読み込む。

そして、管理サーバ０１のＣＰＵ２０１は、全てのＨＴ積み降ろしデータに対して、以上の処理を実行したと判定した場合は（ステップＳ１９０２：ＹＥＳ）、次に、入出庫ワークデータを１件ずつ（図２０（ｃ）の１レコード毎）読み込む（ステップＳ１９０６）。

そして、管理サーバ０１のＣＰＵ２０１は、全ての入出庫ワークデータを読み込むまで、ステップＳ１９０８からステップＳ１９１１の処理を実行する（ステップＳ１９０７）。

管理サーバ０１のＣＰＵ２０１は、ステップＳ１９０７で読み込んだ入出庫ワークデータの伝票日付と管理サーバ０１のシステム日付（現在の日付）とが同じか否かを判定する（ステップＳ１９０８）。入出庫ワークデータの伝票日付が現在の日時と同じであると判定された場合は（ステップＳ１９０８：ＹＥＳ）、ステップＳ１９０９の処理に移行する。一方、入出庫ワークデータの伝票日付が現在の日時と異なると判定された場合は（ステップＳ１９０８：ＮＯ）、ステップＳ１９０６に戻り、次のデータ（入出庫ワークデータ）を読み込む。

次に、ステップＳ１９０９で、管理サーバ０１のＣＰＵ２０１は、読み込んだ入出庫ワークデータの当翌区分が「翌日」（翌日払出や翌日受入など）であるか否かを判定する。そして、当翌区分が「翌日」でなければ（ステップＳ１９０９：ＮＯ）、ステップＳ１９０６に戻り、次のデータ（入出庫ワークデータ）を読み込む。一方、当翌区分が「翌日」であれば（ステップＳ１９０９：ＹＥＳ）、ステップＳ１９０６で読み込んだ入出庫ワークデータから入出庫実績データを生成する（ステップＳ１９１０）。すなわち、読み込んだ入出庫ワークデータを入出庫実績データに登録する。

そして、管理サーバ０１のＣＰＵ２０１は、入出庫ワークデータから車上在庫データの在庫数を更新（ステップＳ１９１１）した後、ステップＳ１９０６に戻り、次のデータ（入出庫ワークデータ）を読み込む。

そして、入出庫ワークデータの全てを読み込んだと判定した場合は（ステップＳ１９０７：ＹＥＳ）、入出庫ワークデータを削除し、本処理（夜間バッチ処理）を終了する。このように、夜間バッチ処理により入出庫ワークデータを削除するので、入出庫ワークデータには、ＰＣ端末から現在の倉庫内の商品の在庫数の問合せを受け付ける当日分のデータのみが一時的に記憶されていることとなる。

ここで、ステップＳ１９１１の車上在庫データの在庫数の更新処理は、ステップＳ１９０５のＨＴ積み降ろしデータと同様の処理である。

図２０に、夜間バッチ処理後の各データの更新及び生成の例を示している。ここで、図２０を用いて、本夜間バッチ処理の例を説明する。

夜間バッチ処理の説明に入る前に、管理サーバのデータベースに記憶された各データテーブルの説明を行う。

図２０には、管理サーバのデータベースに記憶された、夜間バッチ処理前の「（ａ）営業所在庫データ」、「（ｂ）車上在庫データ」、「（ｃ）入出庫ワークデータ」、「（ｄ）ＨＴ積み降ろしデータ」と、夜間バッチ処理後の「（ｅ）営業所在庫データ」、「（ｆ）車上在庫データ」、「（ｇ）入出庫実績データ」を示している。

「営業所在庫データ」は、各倉庫内の各商品の在庫数を示すデータテーブルである。「営業所在庫データ」は、夜間バッチ処理により、１回／月、更新される。この更新処理は、１ヶ月分の入出庫実績データ（ｇ）と、１ヶ月前の営業所在庫データ（ａ）とから更新される。

すなわち、１ヶ月分の入出庫実績データ（ｇ）に示された、各倉庫の各商品を出し入れした数（数量）と、営業所在庫データ（ａ）に示された、先月の各営業所の各商品の在庫数とから、営業所在庫データ（ｅ）に更新される。

「営業所在庫データ」は、「集計年月日」、「営業所（コード」」、「商品（コード）」、「在庫数」から構成される。「集計年月日」には、前回更新された日付が記憶されている。また、「営業所（コード）」には、営業所（倉庫）を識別する情報が記憶されている。また、「商品（コード）」には、倉庫内にある商品を識別する情報が記憶されている。また、「在庫数」には、倉庫内のある商品の在庫数を示している。

「車上在庫データ」は、各ルート（配送担当者）の車上内の各商品の在庫数を示すテーブルである。「車上在庫データ」は、１回／日の夜間バッチ処理により、毎回更新される。

「車上在庫データ」は、「集計年月日」、「ルート」、「商品」、「在庫数」から構成される。

「集計年月日」には、前回更新された日付が記憶されている。また、「ルート」には、配送担当者又は配送担当者の車両を識別する情報を記憶している。「商品」には、商品を識別する識別情報を記憶している。また、「在庫数」には、車両に積んでいるある商品の在庫数が記憶されている。

「入出庫ワークデータ」は、図１６の処理により登録又は修正されるデータである。すなわち、１回／日の夜間バッチ更新後に、急遽、新たに、倉庫内の商品を車両に積み込まなくてはならなくなった場合に、どの商品をどれだけ倉庫から持ち出したか、或いはどの商品をどれだけ車両に積み込んだかを示すデータであり、一時的なワークデータとして機能している。

「入出庫ワークデータ」は、少なくとも、「伝票番号」、「伝票日付」、「伝票区分」、「ルート」、「商品」、「数量」とから構成される。

「伝票番号」は、入出庫する依頼の各伝票を識別する情報である。「伝票日付」には、当該伝票を依頼した日付を示す情報が記憶される。

「伝票区分」には、翌日又は当日に、商品が倉庫から出されるか、又は商品が倉庫に入れられるかを識別するための情報である。商品が倉庫から出される場合は、倉庫内の在庫数を減らす処理を行い、商品が倉庫に入れられる場合は、倉庫内の在庫数を増やす処理を行う。このデータは、これらを識別するために用いられる。

「商品」は、商品を識別する情報（商品コード）であって、当該商品コードにより商品を特定することができる。

「数量」は、商品が倉庫から出された数量又は商品が倉庫に入れられた数量を示している。

ここでは、入出庫ワークデータは、倉庫に入庫データ商品の数や、倉庫から出庫される商品の数を含んでいるが、当日に倉庫から出庫する商品の数（出庫数）のみを示すデータを、入出庫ワークデータの代わりに出庫ワークデータと呼ぶ。出庫ワークデータで本実施例を説明する場合は、本実施例の入出庫ワークデータを出庫ワークデータに置き換えればよい。

「ＨＴ積み降ろしデータ」は、ルートが、配送に不要な商品を倉庫に返却したり（積み降ろし）、配送に必要な商品を車両に積み込んだりした商品とその数を示し、このデータは、一日の配送が終了して帰社した際に、携帯端末（ハンディターミナル）から管理サーバに送信される。これを管理サーバが受信して記憶したデータが「ＨＴ積み降ろしデータ」である。

「ＨＴ積み降ろしデータ」は、少なくとも、「伝票日付」、「伝票区分」、「ルート」、「商品」、「数量」から構成される。各項目の説明は、入出庫ワークデータと同様なので省略する。

「（ｇ）入出庫実績データ」は、夜間バッチ処理により、「入出庫ワークデータ」と「ＨＴ積み降ろしデータ」から生成されるデータである。すなわち、倉庫からどの商品がどの数量出し入れをされたかを示すデータである。「（ｇ）入出庫実績データ」は、１回／日の夜間バッチ処理により、毎回更新される。

「（ｇ）入出庫実績データ」は、少なくとも、「伝票日付」、「伝票区分」、「ルート」、「商品」、「数量」から構成される。各項目の説明は、入出庫ワークデータと同様なので省略する。

以下に、夜間バッチ処理の具体例の説明を行う。

例えば、夜間バッチ処理により、現在の日付が２００８０９０１（2008年9月1日を示す）の場合、図２０（ｃ）にある入出庫ワークデータの伝票日付が２００８０９０１（2008年9月1日を示す）で、翌日払出、又は、翌日受入（伝票番号：１２３４５６７、１２３４５６８のレコード）のデータ（入出庫ワークデータ）から、図２０（ｇ）にある入出庫実績データ（伝票番号：１２３４５６７、１２３４５６８のレコード）を作成する（図１９のステップＳ１９１０）。そして、夜間バッチ処理により、図１９のステップＳ１９１０で作成した入出庫実績データのルートと商品に対応する車上在庫データ（ｂ）（ルートが１００で商品が１０００のレコード、ルートが１００で商品が１００１のレコード、ルートが２００で商品が２０００のレコード、ルートが２００で商品が２００１のレコード）の在庫数を、車上在庫データ（ｆ）に示すように更新する。

具体的に、入出庫ワークデータ（ｃ）に示す、ルートが「１００」で商品が「１０００」の数量が「２０」のレコードから、車上在庫データ（ｂ）（ルートが「１００」で商品が「１０００」のレコード）を車上在庫データ（ｆ）（ルートが「１００」で商品が「１０００」のレコード）のように更新する処理について説明する。

入出庫ワークデータ（ｃ）に示す、ルートが「１００」で商品が「１０００」の数量が「２０」のレコードの伝票区分は「翌日払出」となっている。すなわち、翌日に、倉庫から商品を２０個、車に載せることを示している。したがって、車上在庫データ（ｂ）には、ルート「１００」の車上の商品「１０００」の在庫数が２００個であることを示しているが、この在庫数を、夜間バッチにより２２０個に更新する。更新された車上在庫データ（ｆ）には、ルート「１００」の車上の商品「１０００」の在庫数が２２０個に更新されている。

ここで、伝票区分に登録されるデータ（「翌日払出」、「翌日受入」、「当日積込」、「当日降ろし」）の説明をする。

「翌日払出」は、倉庫側から見た呼び方であり、翌日に倉庫から商品（在庫）を出すことを示している。また、「翌日受入」は、倉庫側から見た呼び方であり、翌日に倉庫に商品（在庫）を入れることを示している。また、「当日積込」は、携帯端末０３（ハンディターミナルともいう）から見た呼び方であり、倉庫から商品（在庫）を出すことを示している。また、「当日降ろし」は、携帯端末０３（ハンディターミナルともいう）から見た呼び方であり、車から商品（在庫）を降ろすことを示している。

以上にようにして更新された車上在庫データ（ｆ）が、翌日、携帯端末０３に送信される。

同様に、該当する営業所在庫データ（ａ）も、営業所在庫データ（ｂ）へ更新される。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１１、図１２、図１３、図１４、図１５、図１６、図１７、図１８、図１９に示す機能が外部からインストールされるプログラム（認証プログラムや情報処理プログラムなど）によって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

本発明の実施形態の在庫管理システムの構成を示す図である。 管理サーバ０１、ＰＣ端末０２のハードウエア構成図である。 従来の実施携帯の在庫管理システムの業務フローを示す図である。 本発明の実施形態の在庫管理システムの業務フローを示す図である。 本発明の実施形態の商品他受払表（日報）入力画面の一例を示す図である。 本発明の実施形態の車上受払入力画面の一例を示す図である。 本発明の実施形態の商品他受払表（プレロード）入力画面の一例を示す図である。 本発明の実施形態の商品他受払表（日報）帳票の一例を示す図である。 本発明の実施形態の車上受払伝票の一例を示す図である。 本発明の実施形態の商品他受払表（プレロード）帳票の一例を示す図である。 本発明の実施形態のＰＣ端末の全体処理のフローチャートである。 本発明の実施形態のＰＣ端末の車上受払入力処理のフローチャートである。 本発明の実施形態のＰＣ端末の商品他受払表（日報）出力処理のフローチャートである。 本発明の実施形態のＰＣ端末の商品他受払表（プレロード）出力処理のフローチャートである。 本発明の実施形態の管理サーバ全体処理のフローチャートである。 本発明の実施形態の管理サーバの車上受払入力処理のフローチャートである。 本発明の実施形態の管理サーバの商品他受払表（日報）出力処理のフローチャートである。 本発明の実施形態の管理サーバの商品他受払表（プレロード）出力処理のフローチャートである。 本発明の実施形態のサーバ側夜間バッチ処理のフローチャートである。 本発明の実施形態のＤＢ各テーブルの構造およびデータ例と、更新例を示した図である。

符号の説明

０１ 管理サーバ
０２ ＰＣ端末
０３ 携帯端末
０４ ネットワーク

Claims (6)

1. 当日に倉庫から出庫する商品の出庫数を入力する情報処理装置と通信可能な、倉庫内の商品の在庫数を管理する在庫管理装置であって、
   倉庫内の商品の在庫数を示す倉庫在庫データを記憶する第1の記憶手段と、
   前記情報処理装置から、前記倉庫から出庫する商品の出庫数を示す出庫ワークデータを受け付ける第1の受付手段と、
   所定の時間に、前記第１の受付手段で受け付けた出庫ワークデータから得られる、当日に倉庫から出庫した商品の個数実績を示す出庫実績データを記憶する第２の記憶手段と、
   前記情報処理装置からの現在の倉庫内の商品の在庫数の問合せに応じて、前記第1の記憶手段に記憶された倉庫在庫データと、前記第２の記憶手段に記憶された出庫実績データと、前記問合せの当日に前記受付手段で受け付けた出庫ワークデータとから、現在の倉庫内の在庫数を算出する算出手段と、
   前記算出手段で算出された倉庫内の在庫数を出力する出力手段と、
   を備えることを特徴とする在庫管理装置。
2. ハンディターミナルから、当日に車上から積み下ろした商品の積み下ろし数を示す積み下ろしデータを受け付ける第２の受付手段を更に備え、
   前記第1の記憶手段は、更に、車上の在庫数を示す車上在庫データを記憶し、
   前記第２の記憶手段は、更に、前記第1の受付手段で受け付けた出庫ワークデータと前記第２の受付手段で受け付けた積み下ろしデータとから得られる出庫実績データを記憶することを特徴とする請求項１に記載の在庫管理装置。
3. 所定の時間に、前記出庫実績データと前記車上在庫データとから、現在の車上在庫データを更新する第１の更新手段を更に備えることを特徴とする請求項２に記載の在庫管理装置。
4. 所定の時間に、前記出庫実績データと前記倉庫在庫データとから、現在の倉庫在庫データを更新する第２の更新手段を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の在庫管理装置。
5. 当日に倉庫から出庫する商品の出庫数を入力する情報処理装置と通信可能な、倉庫内の商品の在庫数を管理する在庫管理装置における在庫管理方法であって、
   前記在庫管理装置の第1の記憶手段は、倉庫内の商品の在庫数を示す倉庫在庫データを記憶する第１の記憶ステップと、
   前記在庫管理装置の第１の受付手段は、前記情報処理装置から、前記倉庫から出庫する商品の出庫数を示す出庫ワークデータを受け付ける第1の受付ステップと、
   前記在庫管理装置の第２の記憶手段は、所定の時間に、前記第１の受付手段で受け付けた出庫ワークデータから得られる、当日に倉庫から出庫した商品の個数実績を示す出庫実績データを記憶する第２の記憶ステップと、
   前記在庫管理装置の算出手段は、前記情報処理装置からの現在の倉庫内の商品の在庫数の問合せに応じて、前記第1の記憶手段に記憶された倉庫在庫データと、前記第２の記憶手段に記憶された出庫実績データと、前記問合せの当日に前記受付ステップで受け付けた出庫ワークデータとから、現在の倉庫内の在庫数を算出する算出ステップと、
   前記在庫管理装置の出力手段は、前記算出ステップで算出された倉庫内の在庫数を出力する出力ステップと、
   を備えることを特徴とする在庫管理装置の在庫管理方法。
6. 当日に倉庫から出庫する商品の出庫数を入力する情報処理装置と通信可能な、倉庫内の商品の在庫数を管理する在庫管理装置を、
   倉庫内の商品の在庫数を示す倉庫在庫データを記憶する第1の記憶手段と、
   前記情報処理装置から、前記倉庫から出庫する商品の出庫数を示す出庫ワークデータを受け付ける第1の受付手段と、
   所定の時間に、前記第１の受付手段で受け付けた出庫ワークデータから得られる、当日に倉庫から出庫した商品の個数実績を示す出庫実績データを記憶する第２の記憶手段と、
   前記情報処理装置からの現在の倉庫内の商品の在庫数の問合せに応じて、前記第1の記憶手段に記憶された倉庫在庫データと、前記第２の記憶手段に記憶された出庫実績データと、前記問合せの当日に前記受付手段で受け付けた出庫ワークデータとから、現在の倉庫内の在庫数を算出する算出手段と、
   前記算出手段で算出された倉庫内の在庫数を出力する出力手段として機能させることを特徴とするプログラム。

Images