JP2013003871A - 預かりタイヤ管理システム - Google Patents

Abstract

【課題】情報の管理が効率的に行われ、且つ、人手による作業が低減されている、預かりタイヤ管理システムを提供する。
【解決手段】預かりタイヤ管理システムは、ユーザからタイヤを預かる事業所が備える事業所端末と、事業所端末と通信ネットワークを介して通信可能に接続された管理サーバとを具備し、管理サーバは、事業所端末から送信された、タイヤの預け入れを依頼する預け入れ依頼情報を受信し、預け入れ依頼情報ごとに識別コードを付与し、識別コードと関連付けて預け入れ依頼情報を記憶すると共に、識別コードを事業所端末に通知し、倉庫内の複数の保管スペースのそれぞれに付された保管スペースコードが、収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、預け入れ依頼情報に含まれるタイヤサイズ・本数情報に基づいて保管スペースを決定し、その保管スペースコードを預け入れ依頼情報と共に記憶する。
【選択図】図２

Description

本発明は、自動車のタイヤを預かり、保管した後に返却する管理を行う預かりタイヤ管理システムに関するものである。

一般的に、自動車のタイヤは、通常のタイヤ（以下、「通常タイヤ」と称する）を春季から秋季にかけて使用し、冬季には積雪道路用のタイヤ（以下、「冬タイヤ」と称する）に交換されることが多い。交換後の通常タイヤまたは冬タイヤは、それぞれ次に使用するシーズンまで保管する必要があるが、ユーザによってはタイヤの保管スペースを確保することが困難な場合がある。また、交換の度に交換場所までタイヤを運搬することを、負担に感じるユーザもいる。

そこで、自動車販売店など、タイヤの交換サービスに加えて、交換後のタイヤを預かり保管するサービスを行う事業所が増えてきている。そのような事業所では、自身が所有する倉庫にタイヤを保管することもあるが、その場合は保管可能なタイヤの数が限定され易い。そこで、管理会社を介して、保管スペースが豊富な外部の倉庫に、タイヤの保管を委託する事業所も多い。

そのような場合、従来では、預かったタイヤに関する情報やタイヤの所有者であるユーザに関する情報等は、ユーザから直接タイヤを預かった事業所と、倉庫を手配した管理会社との双方において、或いは、それに倉庫を加えた三者において、それぞれ台帳で管理されていた。そのため、労力負担が重複し、情報の管理が非効率的であった。また、倉庫の保管スペースの内のどこにタイヤを保管するかを割り当てる作業は、人手によって行われており、煩雑であった。

そこで、本発明は、上記の実情に鑑み、事業所がユーザから預かったタイヤを、事業所からの依頼により更に預かって倉庫に保管するにあたり、情報の管理が効率的に行われ、且つ、人手による作業が低減されている、預かりタイヤ管理システムの提供を課題とするものである。

上記の課題を解決するため、本発明にかかる預かりタイヤ管理システムは、「ユーザからタイヤを預かる事業所が備える事業所端末と、該事業所端末と通信ネットワークを介して通信可能に接続された管理サーバとを具備し、該管理サーバは、前記事業所端末から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ・本数情報を含む預け入れ依頼情報を受信し、前記預け入れ依頼情報ごとに識別コードを付与し、該識別コードと関連付けて前記預け入れ依頼情報を記憶すると共に、前記識別コードを前記事業所端末に通知し、倉庫内の複数の保管スペースのそれぞれに付された保管スペースコードが、保管スペースに収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、前記タイヤサイズ・本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶する」ものである。

「管理サーバ」は、預かりタイヤ管理システム全体を管理する者（管理会社等であり、以下、「管理者」と称する）の管理下にあるサーバである。タイヤを預かる「事業所」としては、自動車の販売会社及びその店舗、タイヤの販売会社及びその店舗、ガソリンスタンド、自動車のメンテナンス・修理を行う店舗・工場を、例示することができる。

「倉庫」は、管理者が自身で所有する倉庫であっても、タイヤの保管を委託する第三者が所有する倉庫であっても、その双方であっても良い。

上記構成によれば、事業所端末で入力された預け入れ依頼情報が管理サーバに記憶される。そして、それぞれの預け入れ依頼に際して入力及び記憶される預け入れ依頼情報は、預け入れ依頼ごとに付与される識別コードによって識別される。この識別コードは、事業所端末にも通知されるため、事業所端末側でも、入力済みの預け入れ依頼情報を識別コードと共に管理することができる。従って、従来では、ユーザからタイヤを預かる事業所と、タイヤの倉庫への保管を手配する管理者との双方で、タイヤに関する情報を個々に台帳で管理していたところ、本発明によれば、事業所端末からの一度の入力作業により、管理者と事業所との双方が利用できる情報資源を得ることができる。そのため、情報の処理が効率的である。

加えて、事業所端末から預け入れ依頼情報を入力すれば、管理サーバによって、倉庫におけるタイヤの保管スペースが自動的に決定される。従って、従来では、タイヤの保管場所を割り当てる作業は、人手によって行われる煩雑な作業であったところ、本発明によれば、その作業を人手で行う必要がない。これにより、労力負担を大きく低減して、ユーザから預かったタイヤの管理を行うことができる。

なお、「預け入れ依頼情報」のうち、保管スペースの決定に使用される「タイヤサイズ・本数情報」を、タイヤ外径、タイヤ幅、及び、タイヤ本数とし、保管スペースに収容可能なタイヤの「サイズ条件」を、タイヤ外径の最大値、及び、タイヤ総幅（預け入れる複数本のタイヤそれぞれの幅の合計）の最大値とすれば、情報の数を最小として保管スペースを定めることができ、好適である。また、「サイズ条件」にタイヤ外径の最小値を加えれば、広い保管スペースに小径のタイヤが収容されて、余剰の空間が大きなものとなる無駄を排除することができ、より好適である。

なお、タイヤ外径は、その値自体が「タイヤサイズ・本数情報」として入力されるものであっても良いが、タイヤ外径はホイール直径にタイヤ厚みを加えた値として算出することができる。そこで、「タイヤサイズ・本数情報」をタイヤ幅、ホイール直径、及び、偏平率（タイヤ幅に対するタイヤ厚みの割合を百分率で表示したもの）を含むものとし、これらの情報に基づいて、管理サーバがタイヤ外径を算出する設定としても良い。

本発明にかかる預かりタイヤ管理システムは、上記構成に加え、「前記保管スペーステーブルは、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数の前記スペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの前記保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたものであり、前記管理サーバは、前記保管スペーステーブル、及び、タイヤを収容済みの保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶したテーブルを参照し、それぞれのスペースグループについて、前記グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの前記タイヤサイズ・本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループの前記グループコードを前記預け入れ依頼情報と共に記憶する」ものとすることができる。

預け入れ依頼を受けるタイヤは、通常４本で１セットであるが、６本で１セットの場合、８本で１セットの場合など、１セットの本数が４本を超える場合がある。そのため、１セットが４本であることを前提として、タイヤの規格を参照して保管スペースのサイズを設定しおくと、４本を超える本数で１セットの場合は、一つの保管スペースに１セットのタイヤを収容できない。一方、そのような事態を防ぐことを目的として、個々の保管スペースを余裕を持たせたサイズ設定とすると、４本で１セットのタイヤを収容する大多数の場合に余剰の空間ができてしまい、無駄が大きなものとなる。

これに対し、本構成では、間仕切りなく隣接している複数の保管スペースを一つの単位（スペースグループ）とし、グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの総幅とを対比することによって、タイヤを保管するスペースを決定する。すなわち、グループ内タイヤ許容幅から、そのスペースグループ内に既に収容されているタイヤの総幅を減算した値が、これから預け入れたいタイヤの総幅以上であれば、そのスペースグループをタイヤの保管するスペースとして決定することができる。これにより、預け入れの依頼を受けたタイヤの本数に関わらず、保管するスペースを定めることができる。加えて、既にタイヤを収容しているスペースグループであっても、余剰の空間に別のセットのタイヤが収容可能であるかが判断される構成であるため、スペースグループ内の空間を、タイヤの保管のために有効に使用することができる。

本発明にかかる預かりタイヤ管理システムは、上記構成に加え、「前記事業所端末は、倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、前記識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、前記管理サーバに送信し、前記管理サーバは、倉庫と事業所との間に設定された配送ルートに付された配送ルートコードが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの前記出荷依頼情報に基づき配送ルートごとに配送可能なタイヤの残数を更新し、前記事業所端末からの要求に基づき、配送ルートで配送可能なタイヤの残数を稼働日ごとに前記事業所端末に表示させる」ものとすることができる。

「出荷」は、倉庫に保管されていたタイヤを倉庫から搬出し、事業所に向けて送り出す処理を指している。また、「配送」は、出荷されたタイヤを、事業所まで移動させる処理を指している。

「稼働日」は、「出荷」及び「配送」が可能な日である。なお、「稼働日ごとの表示」は、その時点から２週間先まで、一か月先までというように、表示がなされる期間を限定して行うことができる。

「配送ルート」は、倉庫から事業所までトラック等を用いてタイヤを配送するルートを指している。また、「配送ルートで配送可能なタイヤの最大数」は、その配送ルートにおける一日の便数、配送に使用される車両等に積載可能なタイヤの数によって定まる。なお、「配送ルート」は、一つの倉庫と一つの事業所との間に一つの「配送ルート」が設定される場合に限定されず、一つの「配送ルート」に対して倉庫及び事業所の一方または双方が複数設定されるものであっても良い。或いは、一つの倉庫と一つの事業所との間に、複数の「配送ルート」が設定されるものとすることもできる。

上記構成により、配送ルートで配送可能なタイヤの残数が更新され、更新された情報を事業所端末に表示させることが可能となる。これにより、配送ルートで配送可能なタイヤの残数を確認してから、配送ルートに空きがある日を配送希望日として特定し、出荷依頼をすることができる。その結果、事業所側の立場では、配送ルートに空きがない日を配送希望日として出荷依頼し、希望した日に配送が受けられない不都合を回避することができる。一方、管理者側の立場では、配送ルートに空きがない日を配送希望日として出荷依頼がなされ、配送希望日とは異なる日を配送予定日として設定し直す手間を省くことができる。これにより、配送予定日に関する情報の管理が効率的に行われ、且つ、人手による作業によらず配送予定日を決定することができる。

本発明にかかる預かりタイヤ管理システムは、上記構成に加え、「前記管理サーバは、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、前記預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて前記入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、前記事業所端末から送信された情報に含まれる、タイヤが事業所に配送される配送希望日に基づき決定した、配送予定日を超えて前記配送済み登録がなされない場合は、未配送アラーム情報を生成する」ものである。

「回収」は、事業所からタイヤを受け取り、倉庫にまで移動させる処理を指している。また、「入庫」は、タイヤを倉庫に搬入する処理を指している。

入庫済み信号を送信する端末、及び、配送済み信号を送信する端末は、倉庫が備える端末、或いは、タイヤの回収を行う作業者が携帯可能な携帯式端末であって、通信ネットワークを介して管理サーバと通信可能な端末とすることができる。或いは、上記の携帯式端末に入庫済みの情報または配送済みの情報が入力された後、管理者や倉庫が備える端末に携帯式端末を接続し、管理者や倉庫が備える端末を介して、入庫済み信号や配送済み信号が管理サーバに送信される通信形態とすることもできる。

「回収期限日」及び「配送予定日」は、これらの日を管理サーバが決定するための規則を予め定めておくことができる。例えば、「回収期限日」については、“預け入れ希望日の３稼働日後を回収期限日とする”、“預け入れ希望日の２日後を回収期限日とする”等と定めることができる。一方、「配送予定日」については、“配送希望日に配送ルートに空きがある場合は配送希望日とする”、“配送希望日に配送ルートに空きがない場合は配送希望日の翌稼働日とする”等と定めることができる。

「未回収アラーム情報」或いは「未配送アラーム情報」が生成されることにより、このようなアラーム情報を検索条件として、多数の預かり依頼（以下、「依頼ケース」と称することがある）の中から、アラーム情報が付された依頼ケースのみを抽出することができる。これにより、事業所からの依頼に沿ってタイヤの回収または配送が行われていない事態に気付き易く、早期に適切な対応をとることが可能となる。すなわち、預かり依頼を受けたタイヤの現状に関する情報の管理が効率的に行われ、且つ、タイヤの回収または配送が予定通りに行われているかどうかの管理に関する人手による作業を、大幅に低減することができる。

本発明にかかる預かりタイヤ管理システムは、上記構成に加え、「前記管理サーバは、少なくとも前記識別コードを含む二次元コードを生成し、タイヤに付帯させる現品票を、前記二次元コードが付された状態で前記事業所端末から出力させると共に、事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書、及び、倉庫からタイヤを搬出し事業所に配送する際に使用される配送指示書を、それぞれ前記二次元コードが付された状態で出力する」ものとすることができる。

タイヤは、事業所から倉庫へ、倉庫から事業所へと移動するが、「現品票」は常にタイヤに付帯して移動させる。この「現品票」には、預かり依頼情報を特定する「識別コード」を情報として含む二次元コードが付されているため、「預かり依頼を受けたタイヤの１セット」と「現品票」とは一対一に対応する。そして、「回収確認書」及び「配送指示書」にも同じく「識別コード」を情報として含む二次元コードが付されている。そのため、二次元コードを読み取ることにより、タイヤを回収する際の「現品票」と「回収確認書」との照合、及び、タイヤを配送する際の「現品票」と「配送指示書」との照合を、極めて容易に行うことができる。これにより、回収すべきタイヤであるか否か、配送すべきタイヤであるか否かの確認を、極めて容易な作業で誤りなく行うことができる。

加えて、二次元コードを読み取る操作に基づいて、“事業所からタイヤを回収した（回収済み）”、“倉庫にタイヤを搬入した（入庫済み）”、“倉庫からタイヤを搬出した（出庫済み）”、“事業所までタイヤを配送した（配送済み）”という情報を、それぞれ管理サーバに送信することが可能である。これにより、管理サーバにタイヤの状況を登録する処理を、極めて容易に行うことができる。すなわち、管理サーバが管理する情報が有効に利用されて、二次元コードが生成され出力されることにより、書類の照合や、タイヤの状況を登録する処理に関する人手による作業を、大幅に低減することができる。

以上のように、本発明の効果として、事業所がユーザから預かったタイヤを、事業所からの依頼により更に預かって倉庫に保管するにあたり、情報の管理が効率的に行われ、且つ、人手による作業が低減されている、預かりタイヤ管理システムを提供することができる。

本発明の一実施形態の預かりタイヤ管理システムの構成図である。 保管スペースを割り当てる処理の流れを説明するフロー図である。 スペースグループを単位として保管スペースを割り当てる処理の流れを説明するフロー図である。 （ａ）回収確認書を例示する図であり、（ｂ）配送指示書を例示する図である。 配送空き情報の表示を例示する図である。

以下、本発明の一実施形態である預かりタイヤ管理システムについて、説明する。預かりタイヤ管理システム１は、図１に示すように、ユーザからタイヤを預かる事業所が備える事業所端末１０と、事業所端末１０と通信ネットワークを介して通信可能に接続された管理サーバ２０とを具備している。

より詳細には、管理サーバ２０は、預かりタイヤ管理システム１の管理者が備えるサーバであり、ウェブサーバ２１とメインサーバ２２とを備えている。ここで、ウェブサーバ２１は、預かりタイヤ管理システム１に関する事業所向けウェブページ（以下、単に「ウェブページ」と称する）をインターネット上で公開する機能を有するサーバである。一方、メインサーバ２２は、種々のデータベースを備えて預かりタイヤ管理システム１全体における情報を集中管理する機能を有すると共に、預かりタイヤ管理システム１に関する情報処理のうち、ウェブページの提供に関する情報処理以外を行うサーバであり、預かりタイヤ管理システム１における中心的な構成である。なお、ウェブサーバ２１とメインサーバ２２は、何れもハード構成として、主記憶装置、補助記憶装置、主記憶装置に記憶されたプログラムに従って情報処理を行う中央処理装置、及び、通信ネットワークを介して情報の送受信を行う通信装置を主に具備する、汎用のコンピュータで構成されている。

事業所端末１０は、インターネット上で提供されるウェブページを閲覧する機能を備えており、ウェブサーバ２１によるウェブページの提供サービスを受ける。事業所端末１０を備える事業所は、管理者との取り決めにより、予めウェブページのＵＲＬについて通知を受け、ウェブページにログインするためのＩＤの付与を受けると共に、パスワードを登録しておく。すなわち、管理者と所定の取り決めを行った特定の事業所のみが、ウェブページを閲覧することができ、管理サーバ２０との間で情報の送受信を行うことができる。ここで、事業所端末１０は、ハード構成として、主記憶装置、補助記憶装置、中央処理装置、及び、通信装置を主に具備する汎用のコンピュータで構成されており、キーボードやポインティングデバイス等の入力装置と、ディスプレイやプリンタ等の出力装置を備えている。

本実施形態の預かりタイヤ管理システム１は、上記の構成に加えて、メインサーバ２２と通信ネットワークを介して通信可能に接続され、メインサーバ２２が管理する情報資源を利用可能な複数の端末を備えている。かかる端末としては、管理者の本社が備える本社端末３１と、管理者の複数の営業所がそれぞれ備える営業所端末３２とがある。ここで、本社端末３１及び営業所端末３２は、事業所端末１０と同様に、入力装置及び出力装置を備えた汎用のコンピュータで構成される。また、本社端末３１及び営業所端末３２は、何れもインターネットに接続されたメールサーバ（図示を省略）を介して、電子メールの送受信が可能である。

なお、本実施形態では、メインサーバ２２及び本社端末３１は、共に管理者の社内ＬＡＮ４５に接続されており、社内ＬＡＮ４５は、インターネットを介したデータの送受信を中継する通信装置４１を介して、インターネットと接続されている。

また、管理者の本社及び営業所は、何れも預かりタイヤ管理システム１においてタイヤの保管に使用する倉庫を有している。従って、本社端末３１及び営業所端末３２は、メインサーバ２２が管理する情報資源を利用する端末であり、管理者側の端末であると共に、倉庫側の端末でもある。

更に、本実施形態では、倉庫として、本社及び営業所がそれぞれ所有する倉庫（以下、「社内倉庫」と称する）に加え、タイヤの保管を管理者から委託された第三者が所有する倉庫（以下、「委託倉庫」と称する）がある。委託倉庫は委託倉庫端末３３を備えており、委託倉庫端末３３は、メインサーバ２２から送信された電子メールをインターネットを介して受信することが可能であるが、メインサーバ２２にアクセスしてメインサーバ２２が管理する情報資源を利用することはできない。

なお、図１では、管理者側の構成を一点鎖線で囲んで示している。また、営業所端末３２とインターネットとの接続を実線で、委託倉庫端末３３とインターネットとの接続を破線で示しているのは、委託倉庫端末３３と管理サーバ２０との通信手段が、メールサーバを介した電子メールに限定されており、営業所端末３２と管理サーバ２０との間で可能な通信と形態が異なることを表したものである。

次に、メインサーバ２２が備えるデータベースについて説明する。メインサーバ２２の記憶装置には、種々のデータベースが記憶されている。例えば、以下のようなデータベースである。
「預け入れ依頼情報テーブル」：「預け入れ依頼情報」データ（項目については後述）を、「識別コード」と関連付けたテーブルである。
「預かりタイヤ情報テーブル」：「預け入れ依頼情報テーブル」のデータに、「回収期限日」、「出荷希望日」、「配送予定日」、「回収済み」、「入庫済み」、「出庫済み」、「出荷済み」、「配送済み」等のデータを、時間の経過に伴って付加していくテーブルであり、依頼ケースに関する最新の情報を反映したテーブルである。
「出荷依頼情報テーブル」：ウェブページを介して事業所端末１０から送信された「出荷依頼情報」を、「識別コード」と関連付けたテーブルである。

「事業所テーブル」：事業所に関するデータ（事業所名、住所、電話番号等）を、「事業所コード」と関連付けたテーブルである。ここで、各事業所には、タイヤの保管に使用できる倉庫が定められており、「倉庫コード」が事業所に関するデータに含まれる。また、管理者との取り決めにより、事業所ごとに使用可能な「保管スペース」の最大数（以下、「上限スペース数」と称する）が定められており、「上限スペース数」が事業所に関するデータに含まれる。
「倉庫テーブル」：倉庫に関するデータ（倉庫名、社内倉庫・委託倉庫の別、担当者名等）を、「倉庫コード」と関連付けたテーブルである。

「保管スペーステーブル」：保管スペースが属する倉庫の「倉庫コード」、保管スペースに収容可能なタイヤの「サイズ条件」等のデータを、「保管スペースコード」と関連付けたテーブルである。ここで、「サイズ条件」は、保管スペースに収容することが許容されるタイヤのサイズに関する条件であり、「タイヤ外径の最小値（Ｍｉｎ）」、「タイヤ外径の最大値（Ｍａｘ）」、及び、「タイヤ総幅の最大値（Ｌ）」である。また、次の優先順位で、それぞれの数値が小さい保管スペースから昇順で「保管スペースコード」が付されている。
（１）「タイヤ外径の最小値（Ｍｉｎ）」
（２）「タイヤ外径の最大値（Ｍａｘ）」
（３）「タイヤ総幅の最大値（Ｌ）」

「配送ルートテーブル」：配送ルートに関するデータ（配送ルート名、適用期間等）を、「配送ルートコード」と関連付けたテーブルである。また、倉庫及び事業所との間に配送ルートが設定されるため、「倉庫コード」及び「事業所コード」が、配送ルートに関するデータに含まれる。更に、配送ルートごとに配送可能なタイヤ数の目安として、タイヤ４本で１セットとした場合のセット数が、「配送可能セット数」として配送ルートに関するデータに含まれる。
「保管料単価テーブル」：タイヤの保管料の単価を、タイヤ種別、タイヤサイズ、保管時期等と関連付けたテーブルである。

「担当者テーブル」：担当者に関するデータ（担当者の氏名、所属、電子メールアドレス等）を、「担当者コード」と関連付けたテーブルである。また、管理者側の担当者については、メインサーバ２２が管理する情報資源を利用する際の権限が、担当者によって異なる。そのため、テーブルの変更、預かりタイヤ情報の変更、請求書の発行等に関する処理に対して、権限の有無を示すデータ（０：無、１：有）が、担当者に関するデータに含まれる。
「稼働日テーブル」：年月日に、回収及び配送を行う稼働日であるか、休日であるかを関連付けたテーブルである。

次に、預かりタイヤ管理システム１における情報の処理の流れを、預け入れ依頼、回収日の決定、保管スペース割り当て、回収・入庫、出荷依頼、出庫・配送の順に説明する。

＜預け入れ依頼＞
まず、ユーザ（タイヤの所有者）からタイヤ交換及びその後のタイヤ保管の依頼、或いは、タイヤ交換とは別にタイヤを預け入れたい旨の依頼を受けた事業所は、ウェブサーバ２１が提供しているウェブページに、事業所端末１０からアクセスする。このとき、上述のように、ＩＤ及びパスワードによる認証を経てログインする。

ウェブページのトップ画面には、「集計情報」として、その事業所からの依頼により倉庫で現在保管されているタイヤの総数及びセット数が表示される。これは、その事業所の「事業所コード」が付された「預かりタイヤ情報テーブル」のデータ（詳細は後述）において、「入庫済み」が登録されているが「出庫済み」が未登録であるデータを集計した結果が表示されたものである。また、その事業所に許容されるタイヤの保管スペースの残数が表示される。これは、上記の集計結果と「事業所テーブル」の「上限スペース数」とから算出された結果である。これらの表示をもとに、事業所は、ユーザからの依頼を受けることができるか否かを、判断することができる。

また、ウェブページのトップ画面には、新規の預け入れ依頼に対して情報を入力するための「新規依頼」画面、予約登録（詳細は後述）が行われた依頼ケースを一覧できる「予約一覧」画面、及び、その事業所で過去に預かったタイヤに関して登録済みの情報を照会するための「登録照会」画面に、移動するためのリンクが貼られている。

タイヤを預け入れたい旨の依頼を受けたユーザが新規の場合は、「新規依頼」の画面に移動し、「預け入れ依頼情報」を画面上で入力する。この「預け入れ依頼情報」は、ユーザに関する情報やタイヤに関する情報を含む、以下のような情報である。
「預け入れ希望日」
「ユーザ名」
「ユーザ名フリガナ」
「事業所の担当者名」
「預かり期間の開始年月日・終了年月日」（ユーザと事業所との取り決めによる）
「車種」
「車両型式」
「登録番号」（ナンバープレート）
「タイヤメーカー」
「タイヤサイズ・本数情報」
「ホイール直径（ｍｍ）」
「タイヤ幅（ｍｍ）」
「偏平率（％）」
「タイヤ本数」
「タイヤ種別」（通常タイヤ、冬タイヤ）
「ボルト・ナット情報」（継続使用、ユーザ持ち帰り）
「ホイール名」
「残溝」
右前輪（ｍｍ）
右後輪（ｍｍ）
左前輪（ｍｍ）
左後輪（ｍｍ）

なお、「預け入れ依頼情報」として、上記に加えて、タイヤ・ホイールのキズの有無を入力できる設定としてもよい。そうすることにより、保管後にタイヤをユーザに返却する際に、保管中にタイヤ・ホイールに新たな傷が付いたりしなかったかどうかを、担当者が確認することができる。この入力は、例えば、画面上にタイヤの模式図が表示され、模式図の処々表示されたボックスに対応する位置に傷がある場合は、そのボックスにチェックマークを入れる方式とすることができる。

「預け入れ依頼情報」の入力後、確認画面で入力内容を確認し、必要に応じて修正を行う。そして、画面上の「上記内容で依頼する」ボタンをクリックすると、入力された「預け入れ依頼情報」がメインサーバ２２に送信される。このとき、現在ウェブページにログインしている事業所に割り当てられている「事業所コード」が、「預け入れ依頼情報」に自動的に付加されて送信される。

管理サーバ２０は、事業所端末１０から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ・本数情報を含む預け入れ依頼情報を受信し、預け入れ依頼情報ごとに識別コードを付与し、識別コードと関連付けて預け入れ依頼情報を記憶すると共に、識別コードを事業所端末１０に通知する処理を行う。すなわち、メインサーバ２２では、「預け入れ依頼情報」を受け取ると、「識別コード」を付与し、この「識別コード」に「預け入れ依頼情報」を関連付けた「預かりタイヤ情報テーブル」として、記憶装置に記憶する。一方、事業所端末１０に対しては、「預け入れ依頼が完了しました」とのメッセージ、及び、上記の「識別コード」を、ウェブサーバ２１を介して画面表示させる。また、事業所端末１０側では、画面に表示される「預かり票発行」ボタンをクリックすることにより、「預け入れ依頼情報」及び「識別コード」が表示された、「預かり票（事業所控え）」、「預かり票（ユーザ控え）」、及び、「現品票」をプリンタから出力することができる。

上記の操作によって、タイヤの預け入れに関する依頼が終了したこととなるが、正規の「預け入れ依頼情報」をメインサーバ２２に送信するのに先立ち、「予約登録」をすることも可能である。これは、「新規依頼」画面で「預け入れ依頼情報」の一部のみを入力し、予約用の画面で内容を確認した後、「上記内容で予約する」ボタンをクリックすることにより行うことができる。この「予約登録」により、正規の依頼に先んじて「識別コード」が付与されると共に、「預かり票（事業所控え）」、及び「預かり票（ユーザ控え）」の出力が可能となる。これにより、事業所端末１０からの「預け入れ依頼情報」の入力の準備として、ユーザまたは事業所担当者が、当該情報を預かり票に手書きで書き込みたい場合等に便利である。

上記の「予約登録」をした後、正規の預け入れ依頼を行う場合は、トップ画面に貼られたリンクから「予約一覧」画面に移動し、既に行われた予約登録を一覧表示させる。その中から目的の予約登録を選択した上で、「預け入れ依頼」ボタンをクリックすることにより、「預け入れ依頼情報」を入力可能な画面に移動することができる。また、同一のユーザが、過去にもタイヤの預け入れ依頼をしたことがある場合は、「登録照会」画面に移動し、過去の登録内容を表示させる。その上で、「預け入れ依頼」ボタンをクリックすれば、「預け入れ依頼情報」を入力可能な画面に移動することができるため、過去に入力済みのデータを利用して必要なデータの変更を行うことにより、新たな「預け入れ依頼情報」を簡易に入力することができる。

＜回収日の決定＞
上記のように「預け入れ依頼情報」が入力され、「預かりタイヤ情報テーブル」に記憶されると、メインサーバ２２は、「預かりタイヤ情報テーブル」に含まれる「預け入れ希望日」に基づいて、「回収日」及び「回収期限日」を設定する。ここで、「預け入れ希望日」とは、事業所がユーザから預かったタイヤを、管理者が手配した作業者が回収する日として、事業所が希望する日である。本実施形態では、「回収日」は、「預け入れ依頼情報」を受信した時点から「預け入れ希望日」まで、予め定めた時間以上（例えば、２４時間以上）あれば「預け入れ希望日」と同日に設定する。一方、「預け入れ依頼情報」を受信した時点から「預け入れ希望日」まで予め定めた時間未満の場合は、「稼働日テーブル」を参照して、「預け入れ希望日」の翌稼働日に設定する。また、「回収期限日」は、「預け入れ希望日」より３稼働日後を設定する。設定された「回収日」及び「回収期限日」は、「預かりタイヤ情報テーブル」のデータとして新たに登録される。

＜保管スペース割り当て＞
管理サーバ２０は、倉庫内の複数の保管スペースのそれぞれが、収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、タイヤサイズ・本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの保管スペースコードを預け入れ依頼情報と共に記憶する処理を行う。すなわち、メインサーバ２２は、「預かりタイヤ情報テーブル」に含まれる「タイヤサイズ・本数情報」に基づき、「保管スペーステーブル」を参照し、預かったタイヤに「保管スペース」を割り当てる。ここでは、「タイヤサイズ・本数情報」において、「ホイール直径」がｒ（インチ）、「タイヤ幅」がＤ（ｍｍ）、「偏平率」がＦ（％）、「タイヤ本数」がｎ（本）であると仮定して説明する。

まず、メインサーバ２２は、「タイヤ外径Ｒ（ｍｍ）」を算出する。ここで、「（タイヤ外径）＝（ホイール直径）＋（タイヤ厚み）×２」であるから、「タイヤ外径（Ｒ）」は、次式を用いて算出することができる。
Ｒ＝（ｒ×２５．４）＋（Ｄ×Ｆ／１００）×２

また、メインサーバ２２は、１セットのタイヤの幅の総計である「タイヤ総幅Ｗ（ｍｍ）」を算出する。タイヤ総幅（Ｗ）は、式（Ｗ＝Ｄ×ｎ）から算出することができる。なお、タイヤ幅（Ｄ）は、タイヤをホイールに装着したときに側方に膨らむ幅（以下、「膨らみ幅」と称する）を含んでいることがある。その場合、ホイールと膨らみ幅とを関連付けたテーブルを備えるものとし、メインサーバ２２がそのテーブルを参照して、膨らみ幅を除いたタイヤ総幅を算出する設定としても良い。

上記のように算出された「タイヤ外径（Ｒ）」及び「タイヤ総幅（Ｗ）」を用いて、メインサーバ２２は、図２に示す処理の流れで保管スペースの割り当てを行う。まず、メインサーバ２２は、「預かりタイヤ情報テーブル」に含まれる「事業所コード」に基づき、「事業所テーブル」を参照して、「事業所コード」に関連付けられた「倉庫コード」を抽出する（ステップＳ１）。次に、この「倉庫コード」の付された「保管スペーステーブル」を読み出す（ステップＳ２）。更に、「預かりタイヤ情報テーブル」を参照し、「保管スペーステーブル」から空いている保管スペースを抽出する（ステップＳ３）。ここでは、抽出された保管スペースがＮ個であると仮定して説明する。

次に、空いているＮ個の保管スペースに対して、保管スペースコードが昇順となるように番号付けする（ステップＳ４）。この番号を「ＳＣ」とする。最初に、「ＳＣ」を１とする（ステップＳ５）。これは、上述したように、保管スペースコードは、各保管スペースに許容されるタイヤのサイズ（「サイズ条件」）が小さい順に付されており、スペースの小さい保管スペースから、対象のタイヤとサイズを対比するためである。

この対比では、まず、「タイヤ外径（Ｒ）」が、「タイヤ外径の最小値（Ｍｉｎ）」以上であるかを判定する（ステップＳ６）。その結果、Ｒ≧Ｍｉｎであれば（ステップＳ６においてＹｅｓ）、更に「タイヤ外径（Ｒ）」が「タイヤ外形の最大値（Ｍａｘ）」以下であるかを判定する（ステップＳ７）。その結果、Ｒ≦Ｍａｘであれば（ステップＳ７においてＹｅｓ）、更に「タイヤ総幅（Ｗ）」が「タイヤ総幅の最大値（Ｌ）」以下であるかを判定する（ステップＳ８）。その結果、Ｗ≦Ｌであれば（ステップ８においてＹｅｓ）、この保管スペースに対象のタイヤを１セットまとめて収容することができる。従って、この保管スペースに決定し、その保管スペースコードを「預かりタイヤ情報テーブル」に登録した後（ステップＳ９）、処理を終了する。

一方、ステップＳ６，Ｓ７，Ｓ８の何れかにおいて「Ｎｏ」であれば、この保管スペースは対象のタイヤの１セットを収容するには小さ過ぎることとなる。そこで、次に大きな保管スペースと対比するため、「ＳＣ」に１を加える（ステップＳ１０）。そして、「ＳＣ」が上限値「Ｎ」を超えていないことを確認してから（ステップＳ１１においてＮｏ）、ステップＳ６に戻り、タイヤサイズ・本数情報をサイズ条件と対比する（ステップＳ６〜Ｓ８）。

そして、最も大きな保管スペース、すなわち、「ＳＣ＝Ｎ」の保管スペースであっても、対象のタイヤを収容できない場合は（ステップＳ１１においてＹｅｓ）、この事業所が使用できる保管スペース中では、保管スペースを決定できないこととなる。そのため、「保管スペース決定不可」の情報を「預かりタイヤ情報テーブル」に書き込み（ステップＳ１２）、処理を終了する（ステップＳ１２）。

次に、保管スペースを割り当てるための別の処理について説明する。ここでは、「スペースグループ」という考え方を導入している。すなわち、ユーザから預かるタイヤは４本で１セットが通常であるが、６本で１セット、８本で１セットなど、１セットのタイヤ本数が多い場合がある。そのため、倉庫において、４本１セットを基準としタイヤサイズの規格を参照して、保管スペースの大きさを定めておくと、１セットのタイヤ本数が多い場合は、収容できる保管スペースがないこととなる。この場合、１セットのタイヤを必ずしも一つの保管スペースに収容する必要はなく、複数の保管スペースを使用して１セットのタイヤを収容すればよい、というのが「スペースグループ」の考え方である。

そこで、保管スペーステーブルを、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数のスペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたテーブルとする。

より具体的には、「タイヤ外径の最小値（Ｍｉｎ）」及び「タイヤ外径の最大値（Ｍａｘ）」が同一の保管スペースであって、且つ、間に仕切りのない隣接した複数の保管スペースを、予め一つのグループ（「スペースグループ」）にまとめる。本実施形態では、二つの保管グループをまとめて一つの「スペースグループ」とする場合を例示する。また、一つのスペースグループにおける「グループ内タイヤ許容幅」（以下、「ＬＳ」と称することがある）は、このスペースグループを構成する二つの保管スペースそれぞれの「タイヤ総幅の最大値（Ｌ）」の和である。そこで、スペースグループごとに「グループコード」を付し、「保管スペーステーブル」は、スペースグループが属する倉庫の「倉庫コード」、スペースグループに収容可能なタイヤの「サイズ条件」等のデータを、「グループコード」、及び、そのスペースグループを構成する保管スペースの「保管スペースコード」と関連付けたテーブルとする。ここで、「サイズ条件」は、「タイヤ外径の最小値（Ｍｉｎ）」、「タイヤ外径の最大値（Ｍａｘ）」、及び、「グループ内タイヤ許容幅（ＬＳ）」である。また、次の優先順位で、それぞれの数値が小さいスペースグループから昇順で「グループコード」を付すこととする。
（１）「タイヤ外径の最小値（Ｍｉｎ）」
（２）「タイヤ外径の最大値（Ｍａｘ）」
（３）「グループ内タイヤ許容幅（ＬＳ）」

また、各スペースグループを構成する複数の保管スペースについて、タイヤを保管するスペースとして選択されるための優先順位である「割り当て順位」を、保管スペースコード及びグループコードと関連付けて、「保管スペーステーブル」に記憶しておく。

そして、管理サーバ２０は、上記の保管スペーステーブル、及び、タイヤを収容済みの保管スペースの保管スペースコードを預け入れ依頼情報と共に記憶したテーブル（預かりタイヤ情報テーブル）を参照し、それぞれのスペースグループについて、グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤのタイヤサイズ・本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループのグループコードを預け入れ依頼情報と共に記憶する処理を行う。

この処理を、図３を用いて具体的に説明する。まず、メインサーバ２２は、「預かりタイヤ情報テーブル」に含まれる「事業所コード」に基づき、「事業所テーブル」を参照し、「事業所コード」に関連付けられた「倉庫コード」を抽出する（ステップＰ１）。次に、この「倉庫コード」の付された「保管スペーステーブル」を読み出す（ステップＰ２）。

更に、「預かりタイヤ情報テーブル」を参照し、保管中のタイヤの「タイヤサイズ・本数情報」に基づき、保管中のタイヤの総幅（Ｗ２）を「スペースグループ」ごとに算出する（ステップＰ３）。なお、まだタイヤが保管されていないスペースグループについては、Ｗ２＝０である。

ここで、対象のスペースグループ（その事業所が使用できるスペースグループ）がＭ個であると仮定すると、「グループコード」が昇順となるように１からＭまで番号付けをする（ステップＰ４）。この番号を「ＧＣ」とすると、まず、「ＧＣ」を１とする（ステップＰ５）。これは、上記と同様に、スペースの小さいスペースグループから、対象のタイヤとサイズを対比するためである。

その後、上記と同様に、「タイヤ外径（Ｒ）」が、「タイヤ外径の最小値（Ｍｉｎ）」以上であるか（ステップＰ６）、「タイヤ外径（Ｒ）」が「タイヤ外径の最大値（Ｍａｘ）」以下であるか（ステップＰ７）を判定する。ステップＰ６，Ｐ７の何れにおいても「Ｙｅｓ」であれば、次に、「グループ内タイヤ許容幅（ＬＳ）」から保管中のタイヤの総幅（Ｗ２）を減算した値（ＬＳ−Ｗ２）と、「タイヤ総幅（Ｗ）」とを対比する（ステップＰ８）。その結果、Ｗ≦（ＬＳ−Ｗ２）であれば（ステップＰ８においてＹｅｓ）、預け入れ対象のタイヤの１セットを、そのスペースグループに収容することができる。

そこで、そのスペースグループを構成する保管スペースのうち、割り当て順位が高い（図中、「ＰＮ１」と表示する）保管スペースが使用中であるかを、「預かりタイヤ情報テーブル」を参照して確認する（ステップＰ９）。空いていれば（ステップＳ９においてＹｅｓ）、「ＰＮ１」の保管スペースをタイヤの保管スペースとして決定し、その保管スペースコードを「預かりタイヤ情報テーブル」に登録して（ステップＰ１０）、処理を終了する。一方、「ＰＮ１」の保管スペースが既に使用中であれば（ステップＰ９においてＮｏ）、割り当て順位の低い（図中、「ＰＮ２」と表示する）保管スペースをタイヤを保管するスペースとして決定し、その保管スペースコードを「預かりタイヤ情報テーブル」に登録して（ステップＰ１１）、処理を終了する。

ステップＰ６，Ｐ７，Ｐ８の何れかにおいて「Ｎｏ」の場合の処理（ステップＰ１２，Ｐ１３）は、前述のステップＳ１０，Ｓ１１と同様であるため、詳細な説明は省略する。そして、「ＧＣ＝Ｍ」のスペースグループであっても、対象のタイヤの１セットを収容できない場合は（ステップＰ１３においてＮｏ）であれば、「保管スペース決定不可」の情報を「預かりタイヤ情報テーブル」に書き込み（ステップＰ１４）、処理を終了する。

なお、保管スペースを、メインサーバ２２の処理により自動で決定できなかった場合は、「預かりタイヤ情報テーブル」のデータを変更する権限を有する担当者が、「保管スぺース決定不可」の情報が付された依頼ケースを抽出し、手動で保管スペースの設定を行う。

＜回収・入庫＞
上記の預け入れ依頼を受けて、タイヤを事業所から回収して倉庫に搬入する作業に関して行われる情報処理の流れは、次のようである。まず、ある一日に「回収日」が到来する依頼ケースに関して、回収を行う作業者を手配する担当者及び倉庫側の担当者には、「回収日」の前夜の電子メール送信によって、依頼の内容が通知される。これは、メインサーバ２２が「預かりタイヤ情報テーブル」を参照して該当する依頼ケースを抽出し、「担当者テーブル」に登録された担当者のメールアドレスに、自動的に電子メールを送信することにより行われる。

また、回収を行う作業者を手配する担当者及び社内倉庫側の担当者は、管理者側の端末（本社端末３１または営業所端末３２）からメインサーバ２２にアクセスし、「回収確認書」を出力させる。この処理は、「回収確認書発行」画面で、配送ルートごとに該当する依頼ケースを抽出し、「発行」ボタンを選択することにより行うことができる。この「回収確認書」には、「識別コード」、「倉庫コード」、「事業所名」、「ユーザ名」、「タイヤサイズ・本数情報」、「保管スペースコード」等の情報が表示される。

ここで、管理サーバ２０は、少なくとも識別コードを含む二次元コードを生成し、タイヤに付帯させる現品票を、二次元コードが付された状態で事業所端末１０から出力させると共に、事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書を、二次元コードが付された状態で出力させる処理を行うことができる。すなわち、メインサーバ２２が、識別コードを含む上記の情報からなる二次元コードを生成する機能を有することにより、生成された二次元コードが上記情報と併記された、図４（ａ）に例示する「回収確認書」を、プリンタから出力させることが可能である。このことは、上述の「現品票」についても同様であり、事業所端末１０から「現品票」を出力させる際に、上記情報を含む二次元コードが併記された「現品票」を出力させることができる。

なお、委託倉庫端末３３からはメインサーバ２２にアクセスすることができない。そこで、回収したタイヤを搬入する倉庫が委託倉庫の場合、管理者側の担当者が管理者側の端末からメインサーバ２２にアクセスし、「回収確認書発行」画面で「メール送信」ボタンをクリックする。これにより、メインサーバ２２が「担当者テーブル」を参照して、委託倉庫の担当者のメールアドレスを抽出し、ファイル化された「回収確認書発行」が添付された電子メールを、委託倉庫の担当者宛てに送信する。

回収を行う作業者は、「回収確認書」を持参して事業所に出向き、「現品票」の内容と「回収確認書」の内容を照合した上で、タイヤを回収する。このとき、二次元コードを読み取り可能な携帯式端末で、「現品票」及び「回収確認書」の二次元コードを読み取れば、瞬時に誤りなく照合を行うことができる。また、このような二次元コードの読み取りに基づいて、「回収済み」の情報をメインサーバ２２に送信し、登録することができる。

回収されたタイヤは、「現品票」と共に倉庫に搬送される。倉庫では、倉庫側の「回収確認書」と「現品票」とを照合した上で、「回収確認書」に表示されている保管スペースに、「現品票」と共にタイヤを収容する。ここでの照合も二次元コードの読み取りによって行うことができ、これに伴い「入庫済み」情報をメインサーバ２２に送信し、登録することができる。

＜出荷依頼＞
事業所端末１０は、倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、管理サーバ２０に送信する。すなわち、事業所では、ユーザからタイヤ交換やタイヤ返却の依頼を受けた場合など、倉庫に保管されているタイヤを事業所まで戻したいとき、「出荷依頼」を行う。これには、まず、事業所端末１０からウェブページにログインし、トップ画面のリンクから「登録照会」画面に移動する。この画面では、所定の検索条件を入力し「検索」ボタンをクリックすることで、検索条件を満たす「預かりタイヤ情報」を表示させることができる。検索条件としては、「識別コード」、「ユーザ名」、「登録番号」、「預かり期間の終了年月日」、「事業所担当者」などが可能である。また、「預かり期間を超えるデータ」を検索条件として検索を行うこともできる。

上記の検索処理は、ウェブサーバ２１を介してメインサーバ２２の「預かりタイヤ情報テーブル」から、検索条件を満たす情報が抽出される処理とすることができる。或いは、メインサーバ２２から同期してデータが送信されることにより、メインサーバ２２の「預かりタイヤ情報テーブル」と同一内容のテーブルがウェブサーバ２１の記憶装置に記憶され、このテーブルを使用して検索・抽出が行われる設定とすることもできる。このように、ウェブページ上で検索を行う場合に、検索範囲となるデータベースについては、ウェブサーバ２１を介してメインサーバ２２のデータベースが使用されるものであっても、メインサーバ２２から同期して送信されるデータによりウェブサーバ２１の記憶装置に記憶されるデータベースが使用されるものであっても良いことは、他のデータベースについても同様である。

上記の処理により検索・抽出された情報は、事業所端末１０の画面に一覧表示される。その中から、目的とする依頼ケースを選択し「出荷依頼」ボタンをクリックすると、「出荷依頼登録」画面に移動する。この画面では、図５に例示する「配送空き情報」が表示されている。これは、管理サーバ２０は、倉庫と事業所との間に設定された配送ルートが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの出荷依頼情報に基づき配送ルートで配送可能なタイヤの残数を更新し、事業所端末１０からの要求に基づき、事業所端末１０に、配送ルートで配送可能なタイヤの残数を稼働日ごとに表示させる処理によるものである。

すなわち、「事業所テーブル」を参照することにより、ウェブページにログインしている事業所の「事業所コード」から「倉庫コード」が特定される。そして、「事業所コード」及び「倉庫コード」から該当する「配送ルートテーブル」が特定され、「配送可能セット数」が読み出される。一方、過去になされた出荷依頼に基づいて、当該配送ルートについて、既に登録されている「配送日」ごとに、依頼ケースの件数が集計される。これにより、集計結果を「配送可能セット数」から減算することにより、「配送可能なタイヤの残数」が算出される。このように、管理サーバ２０により算出された「配送可能なタイヤの残数」が、その日を起点として予め定められた期間についてまとめられた表が、「配送空き情報」として、ウェブサーバ２１によって事業所端末１０の画面に表示される。

事業所の担当者は、この「配送空き情報」を参照することにより、配送ルートに空きのある日を「出荷希望日」として選択し、入力することができる。入力内容を確認後「上記内容で依頼する」ボタンをクリックすることにより、「出荷希望日」データがメインサーバ２２に送信される。通常の処理では、「出荷希望日」と同一の日が「配送予定日」として「預かりタイヤ情報テーブル」に登録される。

＜出庫・配送＞
上記の出荷依頼を受けて、タイヤを倉庫から搬出し事業所まで配送する作業に関して行われる情報処理の流れは、上記の「回収・入庫」における処理の流れとほぼ同様である。まず、ある一日に「配送予定日」が到来する依頼ケースについて、配送を行う作業者を手配する担当者及び倉庫側の担当者には、「配送予定日」の前夜にメインサーバ２２から電子メールが送信されることにより、依頼の内容が予め通知される。

また、配送を行う作業者を手配する担当者及び社内倉庫側の担当者は、管理者側の端末からメインサーバ２２にアクセスし、図４（ｂ）に例示する「配送指示書」を出力させる。この「配送指示書」の出力方法、表示される情報、倉庫が委託倉庫の場合にメール添付で担当者に送信されること、及び、二次元コードの表示が可能であることは、上記の「回収確認書」の場合と同様である。

倉庫では、「配送指示書」に表示されている保管スペースコードで特定される保管スペースから、タイヤを「現品票」と共に搬出し、「配送指示書」と「現品票」とを照合する。ここでの照合を二次元コードの読み取りによって行うことができることは、上述の「回収」の場合と同様であり、二次元コードの読み取りに基づいて、「出庫済み」情報をメインサーバ２２に送信し、登録することができる。

配送を行う作業者は、「現品票」と共にタイヤを事業所まで搬送し、タイヤを事業所に引き渡した上で「現品票」に受領印を受ける。その後、受領印を受けた「現品票」を本社または営業所に持ち帰り、本社端末３１または営業所端末３２を介して、或いは、携帯式端末を介して、二次元コードの読み取り情報をメインサーバ２２に送信する。これにより、「配送済み」の情報をメインサーバ２２に送信し、登録することができる。

以上のような流れにより、事業所がユーザから預かったタイヤを回収して倉庫に搬入し、倉庫において所定期間保管した後、倉庫から搬出して事業所まで配送する、という一連の処理を、管理サーバ２０による情報管理の下で行うことができる。更に、本実施形態の預かりタイヤ管理システム１では、上記の処理の他、種々の処理を行うことができる。その例として、次に、登録確認、アラーム情報、請求処理、について説明する。

＜登録照会＞
事業所端末１０からウェブページにログインすることにより、管理サーバ２０に登録されている情報について照会を行うことができる。ただし、事業所からは、その「事業所コード」の付された情報のみを表示させることができ、他の事業所の情報は表示させることができない設定となっている。登録情報の照会を行う場合は、トップ画面のリンクから「登録照会」画面に移動し、検索を行う。これにより、検索・抽出された情報と共に、次のような「現在状況」が表示される。
「預かり受付済み」：「預け入れ依頼情報」登録済み、且つ、「入庫済み」未登録
「保管中」：「入庫済み」登録済み、且つ、「配送予定日」未登録
「出荷受付済み」：「配送予定日」登録済み、且つ、「出庫済み」未登録
「配送完了」：「配送済み」登録済み

一方、管理者側の端末からは、メインサーバ２２にアクセスすることにより、或いは、ウェブページにログインすることにより、登録情報を照会することができる。また、管理者側の担当者は、「担当者テーブル」に登録されている権限の範囲内で、データベースのデータの変更、「回収日」や「配送予定日」の変更、保管スペースの変更などを行うことができる。

＜アラーム情報＞
管理サーバ２０は、通信ネットワークを介して管理サーバ２０と通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して管理サーバ２０と通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、事業所端末１０から送信された出荷以来情報に含まれる配送希望日に基づき決定した、配送予定日を超えて配送済み登録がなされない場合は、未配送アラーム情報を生成する処理を行う。すなわち、次のような条件でアラーム情報が生成される。
「未回収アラーム情報」：現在日は回収期限日を超える、且つ、「入庫済み」未登録
「未配送アラーム情報」：現在日は配送予定日を超える、且つ、「配送済み」未登録

また、本実施形態では、上記のアラーム情報の他、次のような条件で、「未出荷アラーム情報」、及び、「保管スペースアラーム情報」が生成される。
「未出荷アラーム情報」：現在日は配送予定日を超える、且つ、「出庫済み」未登録
「保管スペースアラーム情報」：「保管スペース設定不可」情報が登録されている、または、同一の保管スペースコードが複数件の依頼ケースに付与されている
なお、同一の保管スペースコードが複数件の依頼ケースに付与される事態は、保管スペースを手動で設定した場合に起こり得る。

上記のようなアラーム情報が生成されることにより、アラーム情報が付されていることを検索条件として、該当する依頼ケースを検索・抽出することができる。実際には、管理者側の端末からメインサーバ２２にアクセスし、「アラーム確認」画面に移動した上で、対象のアラーム情報の種類を選択することにより、該当する依頼ケースの一覧を表示させることができる。

また、本実施形態では、メインサーバ２２は、上記のアラーム情報が生成された時点で、「担当者テーブル」を参照し、その依頼ケースの担当者のメールアドレスを宛先として、アラーム情報が生成されたことを通知する電子メールを送信する。例えば、未回収アラーム情報の場合は、回収の作業を手配する管理者側の担当者、回収するタイヤの搬入先である倉庫の担当者に電子メールでアラーム情報を送信する。また、未配送アラーム情報の場合は、配送の作業を手配する管理者側の担当者に電子メールでアラーム情報を送信する。また、未出荷アラーム情報の場合は、出荷すべきタイヤを保管中の倉庫の担当者、配送の作業を手配する管理者側の担当者に電子メールでアラーム情報を送信する。また、保管スペースアラーム情報の場合、メインサーバ２２は「担当者テーブル」を参照し、「預かりタイヤ情報テーブル」のデータを変更し手動で保管スペースの設定をする権限を有する担当者に、電子メールでアラーム情報を送信する。このようにすることにより、アラーム情報が生成された事態を、担当者が早期に把握することができるため、適切な対応を早期にとることが可能となる。

＜請求処理＞
上述したように、メインサーバ２２はデータベースとして、タイヤの保管料の単価を、タイヤ種別、タイヤサイズ、保管時期等と関連付けた「保管料単価テーブル」を有している。これにより、タイヤの保管期間の始期と終期が定まった時点で、例えば、「回収日」及び「出荷希望日」が登録された時点で、メインサーバ２２によって、保管料の請求額が算出される。或いは、保管期間の始期及び終期として仮の期日を入力することにより、請求額を試算させることができる。これにより、例えば、事業所端末１０からの要求に応じて、算出または試算された請求額を事業所端末１０に表示させることができる。或いは、管理者側の端末から、メインサーバ２２にアクセスし、請求書を発行することができる。そして、タイヤ種別、タイヤサイズによって、保管料の単価が細かく分かれていたとしても、或いは、同一のタイヤに対して、時期によって単価が異なり保管期間中に単価が変化したとしても、手動で面倒な計算をすることなく、請求額を算出・試算し、請求書を発行することができる。

以上のように、本実施形態の預かりタイヤ管理システム１によれば、事業所端末１０からの一度の入力作業によって、管理者と事業所との双方が利用できる情報資源を得ることができるため、効率的に情報資源を構築することができる。また、情報資源は管理サーバ２０によって一元的に集中管理されるため、変更、追加、削除等の処理がシステム内で重複して行われることがなく、情報処理の作業が効率的である。

また、入力されたタイヤサイズ・本数情報に基づき、管理サーバ２０によってタイヤ外径及びタイヤ総幅が算出され、タイヤが保管される保管スペースが自動的に設定されるため、保管スペースを手動で定めていた従来と比べて、労力負担が大幅に低減されている。特に、本実施形態では、保管スペースに許容されるサイズ条件に、タイヤ外径の最小値を含めているため、広い保管スペースに小径のタイヤが収容されて余剰の空間が大きなものとなる無駄が排除されている。

加えて、本実施形態では、一つの保管スペースに１セットのタイヤを収容できない場合に、複数の保管スペースを合わせて一つのスペースグループとする処理が可能であるため、１セットのタイヤの本数が多い場合であっても、問題なく保管スペースを設定することができる。

更に、本実施形態では、ウェブページに「配送空き情報」が表示されるため、事業所側で出荷希望日を定め易く、希望した日に配送が受けられない不都合を回避することができる。また、出荷希望日をそのまま配送予定日として設定する処理を、通常の処理とすることができるため、出荷希望日とは異なる日を配送予定日として設定し直す手間を省くことができる。

また、事業所からの依頼に沿って処理が行われていない場合、種々のアラーム情報が生成されるため、早期に適切な対応をとることができる。特に、本実施形態では、アラーム情報が生成された際に、その依頼ケースの担当者に電子メールで通知されるため、担当者が早期に事態を把握できるという利点がある。

加えて、本実施形態では、メインサーバ２２によって、「識別コード」及び「預かりタイヤ情報」の一部を含む二次元コードが生成され、この二次元コードが付された「現品票」、「回収確認書」、及び、「配送指示書」を出力させることが可能である。これにより、二次元コードを読み取り可能な携帯式端末を使用して、「現品票」と「回収確認書」、及び、「配送指示書」と「現品票」との照合を、簡易且つ誤りなく行うことができる。また、回収済み、入庫済み、出庫済み、配送済みの情報を、二次元コードの読み取りに基づいて、メインサーバ２２に簡易に送信し、登録することができる。

以上、本発明について好適な実施形態を挙げて説明したが、本発明は上記の実施形態に限定されるものではなく、以下に示すように、本発明の要旨を逸脱しない範囲において、種々の改良及び設計の変更が可能である。

例えば、上記では、管理サーバ２０がウェブサーバ２１とメインサーバ２２に分かれている場合を例示したが、一つのサーバがウェブサーバとしての機能とその他の機能とを兼ね備える構成とすることもできる。

また、上記では、メインサーバ２２及び本社端末３１が、社内ＬＡＮ４５を介してインターネットと接続されている場合を例示したが、これに限定されず、直接的にインターネットに接続されていても良い。

更に、上記では、メインサーバ２２が管理する情報資源を利用する際の権限は、担当者ごとに登録されている場合を例示したが、本社端末３１と営業所端末３２というように、端末によって権限を異ならせる設定とすることができる。

また、上記では、間仕切りなく隣接する二つの保管スペースを一つのスペースグループとして、保管スペースが決定される場合を例示したが、これに限定されず、三つ以上の保管スペースを一つのスペースグループとすることもできる。

１ 預かりタイヤ管理システム
１０ 事業所端末
２０ 管理サーバ
２１ ウェブサーバ（管理サーバ）
２２ メインサーバ（管理サーバ）
３１ 本社端末（通信ネットワークを介して管理サーバと通信可能に接続された端末）
３２ 営業所端末（通信ネットワークを介して管理サーバと通信可能に接続された端末）

Claims (5)

1. ユーザからタイヤを預かる事業所が備える事業所端末と、
   該事業所端末と通信ネットワークを介して通信可能に接続された管理サーバとを具備し、
   該管理サーバは、
   前記事業所端末から送信された、倉庫への預け入れを依頼するタイヤのサイズ及び本数に関するタイヤサイズ・本数情報を含む預け入れ依頼情報を受信し、前記預け入れ依頼情報ごとに識別コードを付与し、該識別コードと関連付けて前記預け入れ依頼情報を記憶すると共に、前記識別コードを前記事業所端末に通知し、
   倉庫内の複数の保管スペースのそれぞれに付された保管スペースコードが、保管スペースに収容可能なタイヤのサイズ条件と関連付けて記憶された保管スペーステーブルを参照し、前記タイヤサイズ・本数情報に基づいて、預け入れの依頼を受けたタイヤを保管する保管スペースを決定し、決定された保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶する
   ことを特徴とする預かりタイヤ管理システム。
2. 前記保管スペーステーブルは、間仕切りなく隣接する複数の保管スペースを一つのスペースグループとして複数の前記スペースグループそれぞれに付されたグループコード、及び、スペースグループを構成する保管スペースの前記保管スペースコードが、スペースグループに収容可能なタイヤの総幅の最大値であるグループ内タイヤ許容幅を含むサイズ条件と関連付けて記憶されたものであり、
   前記管理サーバは、
   前記保管スペーステーブル、及び、タイヤを収容済みの保管スペースの前記保管スペースコードを前記預け入れ依頼情報と共に記憶したテーブルを参照し、それぞれのスペースグループについて、前記グループ内タイヤ許容幅から収容済みのタイヤの総幅を減算した値と、預け入れの依頼を受けたタイヤの前記タイヤサイズ・本数情報に基づいて算出したタイヤの総幅とを対比し、預け入れの依頼を受けたタイヤを保管するスペースグループを決定し、決定されたスペースグループの前記グループコードを前記預け入れ依頼情報と共に記憶する
   ことを特徴とする請求項１に記載の預かりタイヤ管理システム。
3. 前記事業所端末は、
   倉庫に保管中のタイヤの出荷を依頼する出荷依頼情報を、前記識別コードを付し、且つ、タイヤが事業所に配送される配送希望日を特定して、前記管理サーバに送信し、
   前記管理サーバは、
   倉庫と事業所との間に設定された配送ルートに付された配送ルートコードが、配送ルートで配送可能なタイヤの最大数と関連付けられた配送ルートテーブルを参照し、受信済みの前記出荷依頼情報に基づき配送ルートごとに配送可能なタイヤの残数を更新し、
   前記事業所端末からの要求に基づき、配送ルートで配送可能なタイヤの残数を稼働日ごとに前記事業所端末に表示させる
   ことを特徴とする請求項１または請求項２に記載の預かりタイヤ管理システム。
4. 前記管理サーバは、
   通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、事業所から回収したタイヤを倉庫に搬入した後に送信される入庫済み信号を受信して入庫済み登録をすると共に、通信ネットワークを介して前記管理サーバと通信可能に接続された端末から、倉庫から搬出したタイヤを事業所まで配送した後に送信される配送済み信号を受信して配送済み登録をし、
   前記預け入れ依頼情報に含まれる預け入れ希望日に基づき決定した、回収期限日を超えて前記入庫済み登録がなされない場合は、未回収アラーム情報を生成すると共に、
   前記事業所端末から送信された情報に含まれる、タイヤが事業所に配送される配送希望日に基づき決定した、配送予定日を超えて前記配送済み登録がなされない場合は、未配送アラーム情報を生成する
   ことを特徴とする請求項１乃至請求項３の何れか一つに記載の預かりタイヤ管理システム。
5. 前記管理サーバは、
   少なくとも前記識別コードを含む二次元コードを生成し、
   タイヤに付帯させる現品票を、前記二次元コードが付された状態で前記事業所端末から出力させると共に、
   事業所からタイヤを回収し倉庫へ搬入する際に使用される回収確認書、及び、倉庫からタイヤを搬出し事業所に配送する際に使用される配送指示書を、それぞれ前記二次元コードが付された状態で出力する
   ことを特徴とする請求項１乃至請求項４の何れか一つに記載の預かりタイヤ管理システム。

Images