"ユーザからタイヤを預かる事業所が備える事業所端末と、該事業所端末と通信ネットワークを介して通信可能に接続された管理サーバとを具備し、該管理サーバは、前記事業所端末から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ本数情報を含む預け入れ依頼情報を受信し、前記預け入れ依頼情報ごとに識別コードを付与し、該識別コードと関連付けて前記預け入れ依頼情報を記憶すると共に、前記識別コードを前記事業所端末に通知し、倉庫内の複数の保管スペースのそれぞれに付された保管スペースコードが、保管スペースに収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、前記タイヤサイズ本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶することを特徴とする預かりタイヤ管理システム。前記保管スペーステーブルは、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数の前記スペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの前記保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたものであり、前記管理サーバは、前記保管スペーステーブル、及び、タイヤを収容済みの保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶したテーブルを参照し、それぞれのスペースグループについて、前記グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの前記タイヤサイズ本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループの前記グループコードを前記預け入れ依頼情報と共に記憶することを特徴とする請求項1に記載の預かりタイヤ管理システム。前記事業所端末は、倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、前記識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、前記管理サーバに送信し、前記管理サーバは、倉庫と事業所との間に設定された配送ルートに付された配送ルートコードが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの前記出荷依頼情報に基づき配送ルートごとに配送可能なタイヤの残数を更新し、前記事業所端末からの要求に基づき、配送ルートで配送可能なタイヤの残数を稼働日ごとに前記事業所端末に表示させることを特徴とする請求項1または請求項2に記載の預かりタイヤ管理システム。前記管理サーバは、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、前記預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて前記入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、前記事業所端末から送信された情報に含まれる、タイヤが事業所に配送される配送希望日に基づき決定した、配送予定日を超えて前記配送済み登録がなされない場合は、未配送アラーム情報を生成することを特徴とする請求項1乃至請求項3の何れか一つに記載の預かりタイヤ管理システム。前記管理サーバは、少なくとも前記識別コードを含む二次元コードを生成し、タイヤに付帯させる現品票を、前記二次元コードが付された状態で前記事業所端末から出力させると共に、事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書、及び、倉庫からタイヤを搬出し事業所に配送する際に使用される配送指示書を、それぞれ前記二次元コードが付された状態で出力することを特徴とする請求項1乃至請求項4の何れか一つに記載の預かりタイヤ管理システム。そこで、本発明は、上記の実情に鑑み、事業所がユーザから預かったタイヤを、事業所からの依頼により更に預かって倉庫に保管するにあたり、情報の管理が効率的に行われ、且つ、人手による作業が低減されている、預かりタイヤ管理システムの提供を課題とするものである。上記の課題を解決するため、本発明にかかる預かりタイヤ管理システムは、ユーザからタイヤを預かる事業所が備える事業所端末と、該事業所端末と通信ネットワークを介して通信可能に接続された管理サーバとを具備し、該管理サーバは、前記事業所端末から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ本数情報を含む預け入れ依頼情報を受信し、前記預け入れ依頼情報ごとに識別コードを付与し、該識別コードと関連付けて前記預け入れ依頼情報を記憶すると共に、前記識別コードを前記事業所端末に通知し、倉庫内の複数の保管スペースのそれぞれに付された保管スペースコードが、保管スペースに収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、前記タイヤサイズ本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶するものである。管理サーバは、預かりタイヤ管理システム全体を管理する者管理会社等であり、以下、管理者と称するの管理下にあるサーバである。タイヤを預かる事業所としては、自動車の販売会社及びその店舗、タイヤの販売会社及びその店舗、ガソリンスタンド、自動車のメンテナンス修理を行う店舗工場を、例示することができる。倉庫は、管理者が自身で所有する倉庫であっても、タイヤの保管を委託する第三者が所有する倉庫であっても、その双方であっても良い。上記構成によれば、事業所端末で入力された預け入れ依頼情報が管理サーバに記憶される。そして、それぞれの預け入れ依頼に際して入力及び記憶される預け入れ依頼情報は、預け入れ依頼ごとに付与される識別コードによって識別される。この識別コードは、事業所端末にも通知されるため、事業所端末側でも、入力済みの預け入れ依頼情報を識別コードと共に管理することができる。従って、従来では、ユーザからタイヤを預かる事業所と、タイヤの倉庫への保管を手配する管理者との双方で、タイヤに関する情報を個々に台帳で管理していたところ、本発明によれば、事業所端末からの一度の入力作業により、管理者と事業所との双方が利用できる情報資源を得ることができる。そのため、情報の処理が効率的である。加えて、事業所端末から預け入れ依頼情報を入力すれば、管理サーバによって、倉庫におけるタイヤの保管スペースが自動的に決定される。従って、従来では、タイヤの保管場所を割り当てる作業は、人手によって行われる煩雑な作業であったところ、本発明によれば、その作業を人手で行う必要がない。これにより、労力負担を大きく低減して、ユーザから預かったタイヤの管理を行うことができる。なお、預け入れ依頼情報のうち、保管スペースの決定に使用されるタイヤサイズ本数情報を、タイヤ外径、タイヤ幅、及び、タイヤ本数とし、保管スペースに収容可能なタイヤのサイズ条件を、タイヤ外径の最大値、及び、タイヤ総幅預け入れる複数本のタイヤそれぞれの幅の合計の最大値とすれば、情報の数を最小として保管スペースを定めることができ、好適である。また、サイズ条件にタイヤ外径の最小値を加えれば、広い保管スペースに小径のタイヤが収容されて、余剰の空間が大きなものとなる無駄を排除することができ、より好適である。なお、タイヤ外径は、その値自体がタイヤサイズ本数情報として入力されるものであっても良いが、タイヤ外径はホイール直径にタイヤ厚みを加えた値として算出することができる。そこで、タイヤサイズ本数情報をタイヤ幅、ホイール直径、及び、偏平率タイヤ幅に対するタイヤ厚みの割合を百分率で表示したものを含むものとし、これらの情報に基づいて、管理サーバがタイヤ外径を算出する設定としても良い。本発明にかかる預かりタイヤ管理システムは、上記構成に加え、前記保管スペーステーブルは、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数の前記スペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの前記保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたものであり、前記管理サーバは、前記保管スペーステーブル、及び、タイヤを収容済みの保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶したテーブルを参照し、それぞれのスペースグループについて、前記グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの前記タイヤサイズ本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループの前記グループコードを前記預け入れ依頼情報と共に記憶するものとすることができる。預け入れ依頼を受けるタイヤは、通常4本で1セットであるが、6本で1セットの場合、8本で1セットの場合など、1セットの本数が4本を超える場合がある。そのため、1セットが4本であることを前提として、タイヤの規格を参照して保管スペースのサイズを設定しおくと、4本を超える本数で1セットの場合は、一つの保管スペースに1セットのタイヤを収容できない。一方、そのような事態を防ぐことを目的として、個々の保管スペースを余裕を持たせたサイズ設定とすると、4本で1セットのタイヤを収容する大多数の場合に余剰の空間ができてしまい、無駄が大きなものとなる。これに対し、本構成では、間仕切りなく隣接している複数の保管スペースを一つの単位スペースグループとし、グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの総幅とを対比することによって、タイヤを保管するスペースを決定する。すなわち、グループ内タイヤ許容幅から、そのスペースグループ内に既に収容されているタイヤの総幅を減算した値が、これから預け入れたいタイヤの総幅以上であれば、そのスペースグループをタイヤの保管するスペースとして決定することができる。これにより、預け入れの依頼を受けたタイヤの本数に関わらず、保管するスペースを定めることができる。加えて、既にタイヤを収容しているスペースグループであっても、余剰の空間に別のセットのタイヤが収容可能であるかが判断される構成であるため、スペースグループ内の空間を、タイヤの保管のために有効に使用することができる。本発明にかかる預かりタイヤ管理システムは、上記構成に加え、前記事業所端末は、倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、前記識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、前記管理サーバに送信し、前記管理サーバは、倉庫と事業所との間に設定された配送ルートに付された配送ルートコードが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの前記出荷依頼情報に基づき配送ルートごとに配送可能なタイヤの残数を更新し、前記事業所端末からの要求に基づき、配送ルートで配送可能なタイヤの残数を稼働日ごとに前記事業所端末に表示させるものとすることができる。出荷は、倉庫に保管されていたタイヤを倉庫から搬出し、事業所に向けて送り出す処理を指している。また、配送は、出荷されたタイヤを、事業所まで移動させる処理を指している。稼働日は、出荷及び配送が可能な日である。なお、稼働日ごとの表示は、その時点から2週間先まで、一か月先までというように、表示がなされる期間を限定して行うことができる。配送ルートは、倉庫から事業所までトラック等を用いてタイヤを配送するルートを指している。また、配送ルートで配送可能なタイヤの最大数は、その配送ルートにおける一日の便数、配送に使用される車両等に積載可能なタイヤの数によって定まる。なお、配送ルートは、一つの倉庫と一つの事業所との間に一つの配送ルートが設定される場合に限定されず、一つの配送ルートに対して倉庫及び事業所の一方または双方が複数設定されるものであっても良い。或いは、一つの倉庫と一つの事業所との間に、複数の配送ルートが設定されるものとすることもできる。上記構成により、配送ルートで配送可能なタイヤの残数が更新され、更新された情報を事業所端末に表示させることが可能となる。これにより、配送ルートで配送可能なタイヤの残数を確認してから、配送ルートに空きがある日を配送希望日として特定し、出荷依頼をすることができる。その結果、事業所側の立場では、配送ルートに空きがない日を配送希望日として出荷依頼し、希望した日に配送が受けられない不都合を回避することができる。一方、管理者側の立場では、配送ルートに空きがない日を配送希望日として出荷依頼がなされ、配送希望日とは異なる日を配送予定日として設定し直す手間を省くことができる。これにより、配送予定日に関する情報の管理が効率的に行われ、且つ、人手による作業によらず配送予定日を決定することができる。本発明にかかる預かりタイヤ管理システムは、上記構成に加え、前記管理サーバは、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、前記預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて前記入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、前記事業所端末から送信された情報に含まれる、タイヤが事業所に配送される配送希望日に基づき決定した、配送予定日を超えて前記配送済み登録がなされない場合は、未配送アラーム情報を生成するものである。回収は、事業所からタイヤを受け取り、倉庫にまで移動させる処理を指している。また、入庫は、タイヤを倉庫に搬入する処理を指している。入庫済み信号を送信する端末、及び、配送済み信号を送信する端末は、倉庫が備える端末、或いは、タイヤの回収を行う作業者が携帯可能な携帯式端末であって、通信ネットワークを介して管理サーバと通信可能な端末とすることができる。或いは、上記の携帯式端末に入庫済みの情報または配送済みの情報が入力された後、管理者や倉庫が備える端末に携帯式端末を接続し、管理者や倉庫が備える端末を介して、入庫済み信号や配送済み信号が管理サーバに送信される通信形態とすることもできる。回収期限日及び配送予定日は、これらの日を管理サーバが決定するための規則を予め定めておくことができる。例えば、回収期限日については、預け入れ希望日の3稼働日後を回収期限日とする、預け入れ希望日の2日後を回収期限日とする等と定めることができる。一方、配送予定日については、配送希望日に配送ルートに空きがある場合は配送希望日とする、配送希望日に配送ルートに空きがない場合は配送希望日の翌稼働日とする等と定めることができる。未回収アラーム情報或いは未配送アラーム情報が生成されることにより、このようなアラーム情報を検索条件として、多数の預かり依頼以下、依頼ケースと称することがあるの中から、アラーム情報が付された依頼ケースのみを抽出することができる。これにより、事業所からの依頼に沿ってタイヤの回収または配送が行われていない事態に気付き易く、早期に適切な対応をとることが可能となる。すなわち、預かり依頼を受けたタイヤの現状に関する情報の管理が効率的に行われ、且つ、タイヤの回収または配送が予定通りに行われているかどうかの管理に関する人手による作業を、大幅に低減することができる。本発明にかかる預かりタイヤ管理システムは、上記構成に加え、前記管理サーバは、少なくとも前記識別コードを含む二次元コードを生成し、タイヤに付帯させる現品票を、前記二次元コードが付された状態で前記事業所端末から出力させると共に、事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書、及び、倉庫からタイヤを搬出し事業所に配送する際に使用される配送指示書を、それぞれ前記二次元コードが付された状態で出力するものとすることができる。タイヤは、事業所から倉庫へ、倉庫から事業所へと移動するが、現品票は常にタイヤに付帯して移動させる。この現品票には、預かり依頼情報を特定する識別コードを情報として含む二次元コードが付されているため、預かり依頼を受けたタイヤの1セットと現品票とは一対一に対応する。そして、回収確認書及び配送指示書にも同じく識別コードを情報として含む二次元コードが付されている。そのため、二次元コードを読み取ることにより、タイヤを回収する際の現品票と回収確認書との照合、及び、タイヤを配送する際の現品票と配送指示書との照合を、極めて容易に行うことができる。これにより、回収すべきタイヤであるか否か、配送すべきタイヤであるか否かの確認を、極めて容易な作業で誤りなく行うことができる。加えて、二次元コードを読み取る操作に基づいて、事業所からタイヤを回収した回収済み、倉庫にタイヤを搬入した入庫済み、倉庫からタイヤを搬出した出庫済み、事業所までタイヤを配送した配送済みという情報を、それぞれ管理サーバに送信することが可能である。これにより、管理サーバにタイヤの状況を登録する処理を、極めて容易に行うことができる。すなわち、管理サーバが管理する情報が有効に利用されて、二次元コードが生成され出力されることにより、書類の照合や、タイヤの状況を登録する処理に関する人手による作業を、大幅に低減することができる。以上のように、本発明の効果として、事業所がユーザから預かったタイヤを、事業所からの依頼により更に預かって倉庫に保管するにあたり、情報の管理が効率的に行われ、且つ、人手による作業が低減されている、預かりタイヤ管理システムを提供することができる。以下、本発明の一実施形態である預かりタイヤ管理システムについて、説明する。預かりタイヤ管理システム1は、図1に示すように、ユーザからタイヤを預かる事業所が備える事業所端末10と、事業所端末10と通信ネットワークを介して通信可能に接続された管理サーバ20とを具備している。より詳細には、管理サーバ20は、預かりタイヤ管理システム1の管理者が備えるサーバであり、ウェブサーバ21とメインサーバ22とを備えている。ここで、ウェブサーバ21は、預かりタイヤ管理システム1に関する事業所向けウェブページ以下、単にウェブページと称するをインターネット上で公開する機能を有するサーバである。一方、メインサーバ22は、種々のデータベースを備えて預かりタイヤ管理システム1全体における情報を集中管理する機能を有すると共に、預かりタイヤ管理システム1に関する情報処理のうち、ウェブページの提供に関する情報処理以外を行うサーバであり、預かりタイヤ管理システム1における中心的な構成である。なお、ウェブサーバ21とメインサーバ22は、何れもハード構成として、主記憶装置、補助記憶装置、主記憶装置に記憶されたプログラムに従って情報処理を行う中央処理装置、及び、通信ネットワークを介して情報の送受信を行う通信装置を主に具備する、汎用のコンピュータで構成されている。事業所端末10は、インターネット上で提供されるウェブページを閲覧する機能を備えており、ウェブサーバ21によるウェブページの提供サービスを受ける。事業所端末10を備える事業所は、管理者との取り決めにより、予めウェブページのURLについて通知を受け、ウェブページにログインするためのIDの付与を受けると共に、パスワードを登録しておく。すなわち、管理者と所定の取り決めを行った特定の事業所のみが、ウェブページを閲覧することができ、管理サーバ20との間で情報の送受信を行うことができる。ここで、事業所端末10は、ハード構成として、主記憶装置、補助記憶装置、中央処理装置、及び、通信装置を主に具備する汎用のコンピュータで構成されており、キーボードやポインティングデバイス等の入力装置と、ディスプレイやプリンタ等の出力装置を備えている。本実施形態の預かりタイヤ管理システム1は、上記の構成に加えて、メインサーバ22と通信ネットワークを介して通信可能に接続され、メインサーバ22が管理する情報資源を利用可能な複数の端末を備えている。かかる端末としては、管理者の本社が備える本社端末31と、管理者の複数の営業所がそれぞれ備える営業所端末32とがある。ここで、本社端末31及び営業所端末32は、事業所端末10と同様に、入力装置及び出力装置を備えた汎用のコンピュータで構成される。また、本社端末31及び営業所端末32は、何れもインターネットに接続されたメールサーバ図示を省略を介して、電子メールの送受信が可能である。なお、本実施形態では、メインサーバ22及び本社端末31は、共に管理者の社内LAN45に接続されており、社内LAN45は、インターネットを介したデータの送受信を中継する通信装置41を介して、インターネットと接続されている。また、管理者の本社及び営業所は、何れも預かりタイヤ管理システム1においてタイヤの保管に使用する倉庫を有している。従って、本社端末31及び営業所端末32は、メインサーバ22が管理する情報資源を利用する端末であり、管理者側の端末であると共に、倉庫側の端末でもある。更に、本実施形態では、倉庫として、本社及び営業所がそれぞれ所有する倉庫以下、社内倉庫と称するに加え、タイヤの保管を管理者から委託された第三者が所有する倉庫以下、委託倉庫と称するがある。委託倉庫は委託倉庫端末33を備えており、委託倉庫端末33は、メインサーバ22から送信された電子メールをインターネットを介して受信することが可能であるが、メインサーバ22にアクセスしてメインサーバ22が管理する情報資源を利用することはできない。なお、図1では、管理者側の構成を一点鎖線で囲んで示している。また、営業所端末32とインターネットとの接続を実線で、委託倉庫端末33とインターネットとの接続を破線で示しているのは、委託倉庫端末33と管理サーバ20との通信手段が、メールサーバを介した電子メールに限定されており、営業所端末32と管理サーバ20との間で可能な通信と形態が異なることを表したものである。次に、メインサーバ22が備えるデータベースについて説明する。メインサーバ22の記憶装置には、種々のデータベースが記憶されている。例えば、以下のようなデータベースである。預け入れ依頼情報テーブル:預け入れ依頼情報データ項目については後述を、識別コードと関連付けたテーブルである。預かりタイヤ情報テーブル:預け入れ依頼情報テーブルのデータに、回収期限日、出荷希望日、配送予定日、回収済み、入庫済み、出庫済み、出荷済み、配送済み等のデータを、時間の経過に伴って付加していくテーブルであり、依頼ケースに関する最新の情報を反映したテーブルである。出荷依頼情報テーブル:ウェブページを介して事業所端末10から送信された出荷依頼情報を、識別コードと関連付けたテーブルである。事業所テーブル:事業所に関するデータ事業所名、住所、電話番号等を、事業所コードと関連付けたテーブルである。ここで、各事業所には、タイヤの保管に使用できる倉庫が定められており、倉庫コードが事業所に関するデータに含まれる。また、管理者との取り決めにより、事業所ごとに使用可能な保管スペースの最大数以下、上限スペース数と称するが定められており、上限スペース数が事業所に関するデータに含まれる。倉庫テーブル:倉庫に関するデータ倉庫名、社内倉庫委託倉庫の別、担当者名等を、倉庫コードと関連付けたテーブルである。保管スペーステーブル:保管スペースが属する倉庫の倉庫コード、保管スペースに収容可能なタイヤのサイズ条件等のデータを、保管スペースコードと関連付けたテーブルである。ここで、サイズ条件は、保管スペースに収容することが許容されるタイヤのサイズに関する条件であり、タイヤ外径の最小値Min、タイヤ外径の最大値Max、及び、タイヤ総幅の最大値Lである。また、次の優先順位で、それぞれの数値が小さい保管スペースから昇順で保管スペースコードが付されている。1タイヤ外径の最小値Min2タイヤ外径の最大値Max3タイヤ総幅の最大値L配送ルートテーブル:配送ルートに関するデータ配送ルート名、適用期間等を、配送ルートコードと関連付けたテーブルである。また、倉庫及び事業所との間に配送ルートが設定されるため、倉庫コード及び事業所コードが、配送ルートに関するデータに含まれる。更に、配送ルートごとに配送可能なタイヤ数の目安として、タイヤ4本で1セットとした場合のセット数が、配送可能セット数として配送ルートに関するデータに含まれる。保管料単価テーブル:タイヤの保管料の単価を、タイヤ種別、タイヤサイズ、保管時期等と関連付けたテーブルである。担当者テーブル:担当者に関するデータ担当者の氏名、所属、電子メールアドレス等を、担当者コードと関連付けたテーブルである。また、管理者側の担当者については、メインサーバ22が管理する情報資源を利用する際の権限が、担当者によって異なる。そのため、テーブルの変更、預かりタイヤ情報の変更、請求書の発行等に関する処理に対して、権限の有無を示すデータ0:無、1:有が、担当者に関するデータに含まれる。稼働日テーブル:年月日に、回収及び配送を行う稼働日であるか、休日であるかを関連付けたテーブルである。次に、預かりタイヤ管理システム1における情報の処理の流れを、預け入れ依頼、回収日の決定、保管スペース割り当て、回収入庫、出荷依頼、出庫配送の順に説明する。<預け入れ依頼>まず、ユーザタイヤの所有者からタイヤ交換及びその後のタイヤ保管の依頼、或いは、タイヤ交換とは別にタイヤを預け入れたい旨の依頼を受けた事業所は、ウェブサーバ21が提供しているウェブページに、事業所端末10からアクセスする。このとき、上述のように、ID及びパスワードによる認証を経てログインする。ウェブページのトップ画面には、集計情報として、その事業所からの依頼により倉庫で現在保管されているタイヤの総数及びセット数が表示される。これは、その事業所の事業所コードが付された預かりタイヤ情報テーブルのデータ詳細は後述において、入庫済みが登録されているが出庫済みが未登録であるデータを集計した結果が表示されたものである。また、その事業所に許容されるタイヤの保管スペースの残数が表示される。これは、上記の集計結果と事業所テーブルの上限スペース数とから算出された結果である。これらの表示をもとに、事業所は、ユーザからの依頼を受けることができるか否かを、判断することができる。また、ウェブページのトップ画面には、新規の預け入れ依頼に対して情報を入力するための新規依頼画面、予約登録詳細は後述が行われた依頼ケースを一覧できる予約一覧画面、及び、その事業所で過去に預かったタイヤに関して登録済みの情報を照会するための登録照会画面に、移動するためのリンクが貼られている。タイヤを預け入れたい旨の依頼を受けたユーザが新規の場合は、新規依頼の画面に移動し、預け入れ依頼情報を画面上で入力する。この預け入れ依頼情報は、ユーザに関する情報やタイヤに関する情報を含む、以下のような情報である。預け入れ希望日ユーザ名ユーザ名フリガナ事業所の担当者名預かり期間の開始年月日終了年月日ユーザと事業所との取り決めによる車種車両型式登録番号ナンバープレートタイヤメーカータイヤサイズ本数情報ホイール直径mmタイヤ幅mm偏平率タイヤ本数タイヤ種別通常タイヤ、冬タイヤボルトナット情報継続使用、ユーザ持ち帰りホイール名残溝右前輪mm右後輪mm左前輪mm左後輪mmなお、預け入れ依頼情報として、上記に加えて、タイヤホイールのキズの有無を入力できる設定としてもよい。そうすることにより、保管後にタイヤをユーザに返却する際に、保管中にタイヤホイールに新たな傷が付いたりしなかったかどうかを、担当者が確認することができる。この入力は、例えば、画面上にタイヤの模式図が表示され、模式図の処々表示されたボックスに対応する位置に傷がある場合は、そのボックスにチェックマークを入れる方式とすることができる。預け入れ依頼情報の入力後、確認画面で入力内容を確認し、必要に応じて修正を行う。そして、画面上の上記内容で依頼するボタンをクリックすると、入力された預け入れ依頼情報がメインサーバ22に送信される。このとき、現在ウェブページにログインしている事業所に割り当てられている事業所コードが、預け入れ依頼情報に自動的に付加されて送信される。管理サーバ20は、事業所端末10から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ本数情報を含む預け入れ依頼情報を受信し、預け入れ依頼情報ごとに識別コードを付与し、識別コードと関連付けて預け入れ依頼情報を記憶すると共に、識別コードを事業所端末10に通知する処理を行う。すなわち、メインサーバ22では、預け入れ依頼情報を受け取ると、識別コードを付与し、この識別コードに預け入れ依頼情報を関連付けた預かりタイヤ情報テーブルとして、記憶装置に記憶する。一方、事業所端末10に対しては、預け入れ依頼が完了しましたとのメッセージ、及び、上記の識別コードを、ウェブサーバ21を介して画面表示させる。また、事業所端末10側では、画面に表示される預かり票発行ボタンをクリックすることにより、預け入れ依頼情報及び識別コードが表示された、預かり票事業所控え、預かり票ユーザ控え、及び、現品票をプリンタから出力することができる。上記の操作によって、タイヤの預け入れに関する依頼が終了したこととなるが、正規の預け入れ依頼情報をメインサーバ22に送信するのに先立ち、予約登録をすることも可能である。これは、新規依頼画面で預け入れ依頼情報の一部のみを入力し、予約用の画面で内容を確認した後、上記内容で予約するボタンをクリックすることにより行うことができる。この予約登録により、正規の依頼に先んじて識別コードが付与されると共に、預かり票事業所控え、及び預かり票ユーザ控えの出力が可能となる。これにより、事業所端末10からの預け入れ依頼情報の入力の準備として、ユーザまたは事業所担当者が、当該情報を預かり票に手書きで書き込みたい場合等に便利である。上記の予約登録をした後、正規の預け入れ依頼を行う場合は、トップ画面に貼られたリンクから予約一覧画面に移動し、既に行われた予約登録を一覧表示させる。その中から目的の予約登録を選択した上で、預け入れ依頼ボタンをクリックすることにより、預け入れ依頼情報を入力可能な画面に移動することができる。また、同一のユーザが、過去にもタイヤの預け入れ依頼をしたことがある場合は、登録照会画面に移動し、過去の登録内容を表示させる。その上で、預け入れ依頼ボタンをクリックすれば、預け入れ依頼情報を入力可能な画面に移動することができるため、過去に入力済みのデータを利用して必要なデータの変更を行うことにより、新たな預け入れ依頼情報を簡易に入力することができる。<回収日の決定>上記のように預け入れ依頼情報が入力され、預かりタイヤ情報テーブルに記憶されると、メインサーバ22は、預かりタイヤ情報テーブルに含まれる預け入れ希望日に基づいて、回収日及び回収期限日を設定する。ここで、預け入れ希望日とは、事業所がユーザから預かったタイヤを、管理者が手配した作業者が回収する日として、事業所が希望する日である。本実施形態では、回収日は、預け入れ依頼情報を受信した時点から預け入れ希望日まで、予め定めた時間以上例えば、24時間以上あれば預け入れ希望日と同日に設定する。一方、預け入れ依頼情報を受信した時点から預け入れ希望日まで予め定めた時間未満の場合は、稼働日テーブルを参照して、預け入れ希望日の翌稼働日に設定する。また、回収期限日は、預け入れ希望日より3稼働日後を設定する。設定された回収日及び回収期限日は、預かりタイヤ情報テーブルのデータとして新たに登録される。<保管スペース割り当て>管理サーバ20は、倉庫内の複数の保管スペースのそれぞれが、収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、タイヤサイズ本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの保管スペースコードを預け入れ依頼情報と共に記憶する処理を行う。すなわち、メインサーバ22は、預かりタイヤ情報テーブルに含まれるタイヤサイズ本数情報に基づき、保管スペーステーブルを参照し、預かったタイヤに保管スペースを割り当てる。ここでは、タイヤサイズ本数情報において、ホイール直径がrインチ、タイヤ幅がDmm、偏平率がF、タイヤ本数がn本であると仮定して説明する。まず、メインサーバ22は、タイヤ外径Rmmを算出する。ここで、タイヤ外径=ホイール直径タイヤ厚み×2であるから、タイヤ外径Rは、次式を用いて算出することができる。R=r×25.4D×F/100×2また、メインサーバ22は、1セットのタイヤの幅の総計であるタイヤ総幅Wmmを算出する。タイヤ総幅Wは、式W=D×nから算出することができる。なお、タイヤ幅Dは、タイヤをホイールに装着したときに側方に膨らむ幅以下、膨らみ幅と称するを含んでいることがある。その場合、ホイールと膨らみ幅とを関連付けたテーブルを備えるものとし、メインサーバ22がそのテーブルを参照して、膨らみ幅を除いたタイヤ総幅を算出する設定としても良い。上記のように算出されたタイヤ外径R及びタイヤ総幅Wを用いて、メインサーバ22は、図2に示す処理の流れで保管スペースの割り当てを行う。まず、メインサーバ22は、預かりタイヤ情報テーブルに含まれる事業所コードに基づき、事業所テーブルを参照して、事業所コードに関連付けられた倉庫コードを抽出するステップS1。次に、この倉庫コードの付された保管スペーステーブルを読み出すステップS2。更に、預かりタイヤ情報テーブルを参照し、保管スペーステーブルから空いている保管スペースを抽出するステップS3。ここでは、抽出された保管スペースがN個であると仮定して説明する。次に、空いているN個の保管スペースに対して、保管スペースコードが昇順となるように番号付けするステップS4。この番号をSCとする。最初に、SCを1とするステップS5。これは、上述したように、保管スペースコードは、各保管スペースに許容されるタイヤのサイズサイズ条件が小さい順に付されており、スペースの小さい保管スペースから、対象のタイヤとサイズを対比するためである。この対比では、まず、タイヤ外径Rが、タイヤ外径の最小値Min以上であるかを判定するステップS6。その結果、R≧MinであればステップS6においてYes、更にタイヤ外径Rがタイヤ外形の最大値Max以下であるかを判定するステップS7。その結果、R≦MaxであればステップS7においてYes、更にタイヤ総幅Wがタイヤ総幅の最大値L以下であるかを判定するステップS8。その結果、W≦Lであればステップ8においてYes、この保管スペースに対象のタイヤを1セットまとめて収容することができる。従って、この保管スペースに決定し、その保管スペースコードを預かりタイヤ情報テーブルに登録した後ステップS9、処理を終了する。一方、ステップS6,S7,S8の何れかにおいてNoであれば、この保管スペースは対象のタイヤの1セットを収容するには小さ過ぎることとなる。そこで、次に大きな保管スペースと対比するため、SCに1を加えるステップS10。そして、SCが上限値Nを超えていないことを確認してからステップS11においてNo、ステップS6に戻り、タイヤサイズ本数情報をサイズ条件と対比するステップS6~S8。そして、最も大きな保管スペース、すなわち、SC=Nの保管スペースであっても、対象のタイヤを収容できない場合はステップS11においてYes、この事業所が使用できる保管スペース中では、保管スペースを決定できないこととなる。そのため、保管スペース決定不可の情報を預かりタイヤ情報テーブルに書き込みステップS12、処理を終了するステップS12。次に、保管スペースを割り当てるための別の処理について説明する。ここでは、スペースグループという考え方を導入している。すなわち、ユーザから預かるタイヤは4本で1セットが通常であるが、6本で1セット、8本で1セットなど、1セットのタイヤ本数が多い場合がある。そのため、倉庫において、4本1セットを基準としタイヤサイズの規格を参照して、保管スペースの大きさを定めておくと、1セットのタイヤ本数が多い場合は、収容できる保管スペースがないこととなる。この場合、1セットのタイヤを必ずしも一つの保管スペースに収容する必要はなく、複数の保管スペースを使用して1セットのタイヤを収容すればよい、というのがスペースグループの考え方である。そこで、保管スペーステーブルを、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数のスペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたテーブルとする。より具体的には、タイヤ外径の最小値Min及びタイヤ外径の最大値Maxが同一の保管スペースであって、且つ、間に仕切りのない隣接した複数の保管スペースを、予め一つのグループスペースグループにまとめる。本実施形態では、二つの保管グループをまとめて一つのスペースグループとする場合を例示する。また、一つのスペースグループにおけるグループ内タイヤ許容幅以下、LSと称することがあるは、このスペースグループを構成する二つの保管スペースそれぞれのタイヤ総幅の最大値Lの和である。そこで、スペースグループごとにグループコードを付し、保管スペーステーブルは、スペースグループが属する倉庫の倉庫コード、スペースグループに収容可能なタイヤのサイズ条件等のデータを、グループコード、及び、そのスペースグループを構成する保管スペースの保管スペースコードと関連付けたテーブルとする。ここで、サイズ条件は、タイヤ外径の最小値Min、タイヤ外径の最大値Max、及び、グループ内タイヤ許容幅LSである。また、次の優先順位で、それぞれの数値が小さいスペースグループから昇順でグループコードを付すこととする。1タイヤ外径の最小値Min2タイヤ外径の最大値Max3グループ内タイヤ許容幅LSまた、各スペースグループを構成する複数の保管スペースについて、タイヤを保管するスペースとして選択されるための優先順位である割り当て順位を、保管スペースコード及びグループコードと関連付けて、保管スペーステーブルに記憶しておく。そして、管理サーバ20は、上記の保管スペーステーブル、及び、タイヤを収容済みの保管スペースの保管スペースコードを預け入れ依頼情報と共に記憶したテーブル預かりタイヤ情報テーブルを参照し、それぞれのスペースグループについて、グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤのタイヤサイズ本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループのグループコードを預け入れ依頼情報と共に記憶する処理を行う。この処理を、図3を用いて具体的に説明する。まず、メインサーバ22は、預かりタイヤ情報テーブルに含まれる事業所コードに基づき、事業所テーブルを参照し、事業所コードに関連付けられた倉庫コードを抽出するステップP1。次に、この倉庫コードの付された保管スペーステーブルを読み出すステップP2。更に、預かりタイヤ情報テーブルを参照し、保管中のタイヤのタイヤサイズ本数情報に基づき、保管中のタイヤの総幅W2をスペースグループごとに算出するステップP3。なお、まだタイヤが保管されていないスペースグループについては、W2=0である。ここで、対象のスペースグループその事業所が使用できるスペースグループがM個であると仮定すると、グループコードが昇順となるように1からMまで番号付けをするステップP4。この番号をGCとすると、まず、GCを1とするステップP5。これは、上記と同様に、スペースの小さいスペースグループから、対象のタイヤとサイズを対比するためである。その後、上記と同様に、タイヤ外径Rが、タイヤ外径の最小値Min以上であるかステップP6、タイヤ外径Rがタイヤ外径の最大値Max以下であるかステップP7を判定する。ステップP6,P7の何れにおいてもYesであれば、次に、グループ内タイヤ許容幅LSから保管中のタイヤの総幅W2を減算した値LS-W2と、タイヤ総幅Wとを対比するステップP8。その結果、W≦LS-W2であればステップP8においてYes、預け入れ対象のタイヤの1セットを、そのスペースグループに収容することができる。そこで、そのスペースグループを構成する保管スペースのうち、割り当て順位が高い図中、PN1と表示する保管スペースが使用中であるかを、預かりタイヤ情報テーブルを参照して確認するステップP9。空いていればステップS9においてYes、PN1の保管スペースをタイヤの保管スペースとして決定し、その保管スペースコードを預かりタイヤ情報テーブルに登録してステップP10、処理を終了する。一方、PN1の保管スペースが既に使用中であればステップP9においてNo、割り当て順位の低い図中、PN2と表示する保管スペースをタイヤを保管するスペースとして決定し、その保管スペースコードを預かりタイヤ情報テーブルに登録してステップP11、処理を終了する。ステップP6,P7,P8の何れかにおいてNoの場合の処理ステップP12,P13は、前述のステップS10,S11と同様であるため、詳細な説明は省略する。そして、GC=Mのスペースグループであっても、対象のタイヤの1セットを収容できない場合はステップP13においてNoであれば、保管スペース決定不可の情報を預かりタイヤ情報テーブルに書き込みステップP14、処理を終了する。なお、保管スペースを、メインサーバ22の処理により自動で決定できなかった場合は、預かりタイヤ情報テーブルのデータを変更する権限を有する担当者が、保管スぺース決定不可の情報が付された依頼ケースを抽出し、手動で保管スペースの設定を行う。<回収入庫>上記の預け入れ依頼を受けて、タイヤを事業所から回収して倉庫に搬入する作業に関して行われる情報処理の流れは、次のようである。まず、ある一日に回収日が到来する依頼ケースに関して、回収を行う作業者を手配する担当者及び倉庫側の担当者には、回収日の前夜の電子メール送信によって、依頼の内容が通知される。これは、メインサーバ22が預かりタイヤ情報テーブルを参照して該当する依頼ケースを抽出し、担当者テーブルに登録された担当者のメールアドレスに、自動的に電子メールを送信することにより行われる。また、回収を行う作業者を手配する担当者及び社内倉庫側の担当者は、管理者側の端末本社端末31または営業所端末32からメインサーバ22にアクセスし、回収確認書を出力させる。この処理は、回収確認書発行画面で、配送ルートごとに該当する依頼ケースを抽出し、発行ボタンを選択することにより行うことができる。この回収確認書には、識別コード、倉庫コード、事業所名、ユーザ名、タイヤサイズ本数情報、保管スペースコード等の情報が表示される。ここで、管理サーバ20は、少なくとも識別コードを含む二次元コードを生成し、タイヤに付帯させる現品票を、二次元コードが付された状態で事業所端末10から出力させると共に、事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書を、二次元コードが付された状態で出力させる処理を行うことができる。すなわち、メインサーバ22が、識別コードを含む上記の情報からなる二次元コードを生成する機能を有することにより、生成された二次元コードが上記情報と併記された、図4aに例示する回収確認書を、プリンタから出力させることが可能である。このことは、上述の現品票についても同様であり、事業所端末10から現品票を出力させる際に、上記情報を含む二次元コードが併記された現品票を出力させることができる。なお、委託倉庫端末33からはメインサーバ22にアクセスすることができない。そこで、回収したタイヤを搬入する倉庫が委託倉庫の場合、管理者側の担当者が管理者側の端末からメインサーバ22にアクセスし、回収確認書発行画面でメール送信ボタンをクリックする。これにより、メインサーバ22が担当者テーブルを参照して、委託倉庫の担当者のメールアドレスを抽出し、ファイル化された回収確認書発行が添付された電子メールを、委託倉庫の担当者宛てに送信する。回収を行う作業者は、回収確認書を持参して事業所に出向き、現品票の内容と回収確認書の内容を照合した上で、タイヤを回収する。このとき、二次元コードを読み取り可能な携帯式端末で、現品票及び回収確認書の二次元コードを読み取れば、瞬時に誤りなく照合を行うことができる。また、このような二次元コードの読み取りに基づいて、回収済みの情報をメインサーバ22に送信し、登録することができる。回収されたタイヤは、現品票と共に倉庫に搬送される。倉庫では、倉庫側の回収確認書と現品票とを照合した上で、回収確認書に表示されている保管スペースに、現品票と共にタイヤを収容する。ここでの照合も二次元コードの読み取りによって行うことができ、これに伴い入庫済み情報をメインサーバ22に送信し、登録することができる。<出荷依頼>事業所端末10は、倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、管理サーバ20に送信する。すなわち、事業所では、ユーザからタイヤ交換やタイヤ返却の依頼を受けた場合など、倉庫に保管されているタイヤを事業所まで戻したいとき、出荷依頼を行う。これには、まず、事業所端末10からウェブページにログインし、トップ画面のリンクから登録照会画面に移動する。この画面では、所定の検索条件を入力し検索ボタンをクリックすることで、検索条件を満たす預かりタイヤ情報を表示させることができる。検索条件としては、識別コード、ユーザ名、登録番号、預かり期間の終了年月日、事業所担当者などが可能である。また、預かり期間を超えるデータを検索条件として検索を行うこともできる。上記の検索処理は、ウェブサーバ21を介してメインサーバ22の預かりタイヤ情報テーブルから、検索条件を満たす情報が抽出される処理とすることができる。或いは、メインサーバ22から同期してデータが送信されることにより、メインサーバ22の預かりタイヤ情報テーブルと同一内容のテーブルがウェブサーバ21の記憶装置に記憶され、このテーブルを使用して検索抽出が行われる設定とすることもできる。このように、ウェブページ上で検索を行う場合に、検索範囲となるデータベースについては、ウェブサーバ21を介してメインサーバ22のデータベースが使用されるものであっても、メインサーバ22から同期して送信されるデータによりウェブサーバ21の記憶装置に記憶されるデータベースが使用されるものであっても良いことは、他のデータベースについても同様である。上記の処理により検索抽出された情報は、事業所端末10の画面に一覧表示される。その中から、目的とする依頼ケースを選択し出荷依頼ボタンをクリックすると、出荷依頼登録画面に移動する。この画面では、図5に例示する配送空き情報が表示されている。これは、管理サーバ20は、倉庫と事業所との間に設定された配送ルートが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの出荷依頼情報に基づき配送ルートで配送可能なタイヤの残数を更新し、事業所端末10からの要求に基づき、事業所端末10に、配送ルートで配送可能なタイヤの残数を稼働日ごとに表示させる処理によるものである。すなわち、事業所テーブルを参照することにより、ウェブページにログインしている事業所の事業所コードから倉庫コードが特定される。そして、事業所コード及び倉庫コードから該当する配送ルートテーブルが特定され、配送可能セット数が読み出される。一方、過去になされた出荷依頼に基づいて、当該配送ルートについて、既に登録されている配送日ごとに、依頼ケースの件数が集計される。これにより、集計結果を配送可能セット数から減算することにより、配送可能なタイヤの残数が算出される。このように、管理サーバ20により算出された配送可能なタイヤの残数が、その日を起点として予め定められた期間についてまとめられた表が、配送空き情報として、ウェブサーバ21によって事業所端末10の画面に表示される。事業所の担当者は、この配送空き情報を参照することにより、配送ルートに空きのある日を出荷希望日として選択し、入力することができる。入力内容を確認後上記内容で依頼するボタンをクリックすることにより、出荷希望日データがメインサーバ22に送信される。通常の処理では、出荷希望日と同一の日が配送予定日として預かりタイヤ情報テーブルに登録される。<出庫配送>上記の出荷依頼を受けて、タイヤを倉庫から搬出し事業所まで配送する作業に関して行われる情報処理の流れは、上記の回収入庫における処理の流れとほぼ同様である。まず、ある一日に配送予定日が到来する依頼ケースについて、配送を行う作業者を手配する担当者及び倉庫側の担当者には、配送予定日の前夜にメインサーバ22から電子メールが送信されることにより、依頼の内容が予め通知される。また、配送を行う作業者を手配する担当者及び社内倉庫側の担当者は、管理者側の端末からメインサーバ22にアクセスし、図4bに例示する配送指示書を出力させる。この配送指示書の出力方法、表示される情報、倉庫が委託倉庫の場合にメール添付で担当者に送信されること、及び、二次元コードの表示が可能であることは、上記の回収確認書の場合と同様である。倉庫では、配送指示書に表示されている保管スペースコードで特定される保管スペースから、タイヤを現品票と共に搬出し、配送指示書と現品票とを照合する。ここでの照合を二次元コードの読み取りによって行うことができることは、上述の回収の場合と同様であり、二次元コードの読み取りに基づいて、出庫済み情報をメインサーバ22に送信し、登録することができる。配送を行う作業者は、現品票と共にタイヤを事業所まで搬送し、タイヤを事業所に引き渡した上で現品票に受領印を受ける。その後、受領印を受けた現品票を本社または営業所に持ち帰り、本社端末31または営業所端末32を介して、或いは、携帯式端末を介して、二次元コードの読み取り情報をメインサーバ22に送信する。これにより、配送済みの情報をメインサーバ22に送信し、登録することができる。以上のような流れにより、事業所がユーザから預かったタイヤを回収して倉庫に搬入し、倉庫において所定期間保管した後、倉庫から搬出して事業所まで配送する、という一連の処理を、管理サーバ20による情報管理の下で行うことができる。更に、本実施形態の預かりタイヤ管理システム1では、上記の処理の他、種々の処理を行うことができる。その例として、次に、登録確認、アラーム情報、請求処理、について説明する。<登録照会>事業所端末10からウェブページにログインすることにより、管理サーバ20に登録されている情報について照会を行うことができる。ただし、事業所からは、その事業所コードの付された情報のみを表示させることができ、他の事業所の情報は表示させることができない設定となっている。登録情報の照会を行う場合は、トップ画面のリンクから登録照会画面に移動し、検索を行う。これにより、検索抽出された情報と共に、次のような現在状況が表示される。預かり受付済み:預け入れ依頼情報登録済み、且つ、入庫済み未登録保管中:入庫済み登録済み、且つ、配送予定日未登録出荷受付済み:配送予定日登録済み、且つ、出庫済み未登録配送完了:配送済み登録済み一方、管理者側の端末からは、メインサーバ22にアクセスすることにより、或いは、ウェブページにログインすることにより、登録情報を照会することができる。また、管理者側の担当者は、担当者テーブルに登録されている権限の範囲内で、データベースのデータの変更、回収日や配送予定日の変更、保管スペースの変更などを行うことができる。<アラーム情報>管理サーバ20は、通信ネットワークを介して管理サーバ20と通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して管理サーバ20と通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、事業所端末10から送信された出荷以来情報に含まれる配送希望日に基づき決定した、配送予定日を超えて配送済み登録がなされない場合は、未配送アラーム情報を生成する処理を行う。すなわち、次のような条件でアラーム情報が生成される。未回収アラーム情報:現在日は回収期限日を超える、且つ、入庫済み未登録未配送アラーム情報:現在日は配送予定日を超える、且つ、配送済み未登録また、本実施形態では、上記のアラーム情報の他、次のような条件で、未出荷アラーム情報、及び、保管スペースアラーム情報が生成される。未出荷アラーム情報:現在日は配送予定日を超える、且つ、出庫済み未登録保管スペースアラーム情報:保管スペース設定不可情報が登録されている、または、同一の保管スペースコードが複数件の依頼ケースに付与されているなお、同一の保管スペースコードが複数件の依頼ケースに付与される事態は、保管スペースを手動で設定した場合に起こり得る。上記のようなアラーム情報が生成されることにより、アラーム情報が付されていることを検索条件として、該当する依頼ケースを検索抽出することができる。実際には、管理者側の端末からメインサーバ22にアクセスし、アラーム確認画面に移動した上で、対象のアラーム情報の種類を選択することにより、該当する依頼ケースの一覧を表示させることができる。また、本実施形態では、メインサーバ22は、上記のアラーム情報が生成された時点で、担当者テーブルを参照し、その依頼ケースの担当者のメールアドレスを宛先として、アラーム情報が生成されたことを通知する電子メールを送信する。例えば、未回収アラーム情報の場合は、回収の作業を手配する管理者側の担当者、回収するタイヤの搬入先である倉庫の担当者に電子メールでアラーム情報を送信する。また、未配送アラーム情報の場合は、配送の作業を手配する管理者側の担当者に電子メールでアラーム情報を送信する。また、未出荷アラーム情報の場合は、出荷すべきタイヤを保管中の倉庫の担当者、配送の作業を手配する管理者側の担当者に電子メールでアラーム情報を送信する。また、保管スペースアラーム情報の場合、メインサーバ22は担当者テーブルを参照し、預かりタイヤ情報テーブルのデータを変更し手動で保管スペースの設定をする権限を有する担当者に、電子メールでアラーム情報を送信する。このようにすることにより、アラーム情報が生成された事態を、担当者が早期に把握することができるため、適切な対応を早期にとることが可能となる。<請求処理>上述したように、メインサーバ22はデータベースとして、タイヤの保管料の単価を、タイヤ種別、タイヤサイズ、保管時期等と関連付けた保管料単価テーブルを有している。これにより、タイヤの保管期間の始期と終期が定まった時点で、例えば、回収日及び出荷希望日が登録された時点で、メインサーバ22によって、保管料の請求額が算出される。或いは、保管期間の始期及び終期として仮の期日を入力することにより、請求額を試算させることができる。これにより、例えば、事業所端末10からの要求に応じて、算出または試算された請求額を事業所端末10に表示させることができる。或いは、管理者側の端末から、メインサーバ22にアクセスし、請求書を発行することができる。そして、タイヤ種別、タイヤサイズによって、保管料の単価が細かく分かれていたとしても、或いは、同一のタイヤに対して、時期によって単価が異なり保管期間中に単価が変化したとしても、手動で面倒な計算をすることなく、請求額を算出試算し、請求書を発行することができる。以上のように、本実施形態の預かりタイヤ管理システム1によれば、事業所端末10からの一度の入力作業によって、管理者と事業所との双方が利用できる情報資源を得ることができるため、効率的に情報資源を構築することができる。また、情報資源は管理サーバ20によって一元的に集中管理されるため、変更、追加、削除等の処理がシステム内で重複して行われることがなく、情報処理の作業が効率的である。また、入力されたタイヤサイズ本数情報に基づき、管理サーバ20によってタイヤ外径及びタイヤ総幅が算出され、タイヤが保管される保管スペースが自動的に設定されるため、保管スペースを手動で定めていた従来と比べて、労力負担が大幅に低減されている。特に、本実施形態では、保管スペースに許容されるサイズ条件に、タイヤ外径の最小値を含めているため、広い保管スペースに小径のタイヤが収容されて余剰の空間が大きなものとなる無駄が排除されている。加えて、本実施形態では、一つの保管スペースに1セットのタイヤを収容できない場合に、複数の保管スペースを合わせて一つのスペースグループとする処理が可能であるため、1セットのタイヤの本数が多い場合であっても、問題なく保管スペースを設定することができる。更に、本実施形態では、ウェブページに配送空き情報が表示されるため、事業所側で出荷希望日を定め易く、希望した日に配送が受けられない不都合を回避することができる。また、出荷希望日をそのまま配送予定日として設定する処理を、通常の処理とすることができるため、出荷希望日とは異なる日を配送予定日として設定し直す手間を省くことができる。また、事業所からの依頼に沿って処理が行われていない場合、種々のアラーム情報が生成されるため、早期に適切な対応をとることができる。特に、本実施形態では、アラーム情報が生成された際に、その依頼ケースの担当者に電子メールで通知されるため、担当者が早期に事態を把握できるという利点がある。加えて、本実施形態では、メインサーバ22によって、識別コード及び預かりタイヤ情報の一部を含む二次元コードが生成され、この二次元コードが付された現品票、回収確認書、及び、配送指示書を出力させることが可能である。これにより、二次元コードを読み取り可能な携帯式端末を使用して、現品票と回収確認書、及び、配送指示書と現品票との照合を、簡易且つ誤りなく行うことができる。また、回収済み、入庫済み、出庫済み、配送済みの情報を、二次元コードの読み取りに基づいて、メインサーバ22に簡易に送信し、登録することができる。以上、本発明について好適な実施形態を挙げて説明したが、本発明は上記の実施形態に限定されるものではなく、以下に示すように、本発明の要旨を逸脱しない範囲において、種々の改良及び設計の変更が可能である。例えば、上記では、管理サーバ20がウェブサーバ21とメインサーバ22に分かれている場合を例示したが、一つのサーバがウェブサーバとしての機能とその他の機能とを兼ね備える構成とすることもできる。また、上記では、メインサーバ22及び本社端末31が、社内LAN45を介してインターネットと接続されている場合を例示したが、これに限定されず、直接的にインターネットに接続されていても良い。更に、上記では、メインサーバ22が管理する情報資源を利用する際の権限は、担当者ごとに登録されている場合を例示したが、本社端末31と営業所端末32というように、端末によって権限を異ならせる設定とすることができる。また、上記では、間仕切りなく隣接する二つの保管スペースを一つのスペースグループとして、保管スペースが決定される場合を例示したが、これに限定されず、三つ以上の保管スペースを一つのスペースグループとすることもできる。"