JP2019101483A - 危険物等の回収システムおよびその方法 - Google Patents

Abstract

【課題】危険物等を一般家庭から回収し、処理業者による廃棄処理を行うまでの工程を効率的に行う。【解決手段】危険物等を顧客から回収し、処理する工程を管理するための危険物等の回収システムにおいて、前記顧客の端末に通信可能に接続された基幹サーバを備え、前記基幹サーバは、前記顧客の端末から受付フォームに入力された情報を取得し、前記受付フォームに入力された前記危険物等の数量から、前記危険物等を運送する際の個口数を算出し、前記危険物等を回収して処理する処理業者に関する情報が格納されたデータベースを参照して、前記数量と前記個口数とに基づいて処理業者を決定する主制御部と、前記決定された処理業者のサーバに集荷指示ファイルを送信する通信処理部とを含む。【選択図】図２

Description

本発明は、危険物等の回収システムおよびその方法に関し、より詳細には、可燃物などの危険物を一般家庭から回収し、処理業者による廃棄処理を行うまでの運用を効率的に行うための危険物等の回収システムおよびその方法に関する。

一般に、卓上コンロ用のカセットボンベ、使い捨てライターなどの可燃物、マッチなどの軽火工品、揮発油を含む塗料、強酸を含む鉛蓄電池などの危険物等は、一般家庭において、大量ではないが、必要な数が定常的に使用されている。これら危険物等について、例えば、リコールが発生した場合には、製造業者は、各家庭で保管されている危険物等、または一部使用されている危険物等を回収しなければならない。

しかしながら、運送約款上、これら危険物等を通常の郵送、小荷物による方法では運ぶことができないので、顧客または製造業者において、所定の要件を満たす運送方法を手配しなければならない。また、危険物等が一定量を超えると、公共交通機関に持ち込むことができないので、顧客が、製造業者の営業所等の拠点に持ち込む場合にも、難しい場合がある。このように、危険物等の運送には制約があることから、製造業者がリコールによる商品の回収を企図しても、顧客の協力が得られず、回収効率が上がらない場合があった。

また、危険物等や有害物質などを取扱う業者は、所定の許認可を受けていなければならない。また、危険物等や有害物質を運送する際にも、所定の荷姿が規定されていたり、別途、運送のための許認可を受ける必要もある。従って、危険物等や有害物質を回収して処理する場合には、顧客宅からの回収から処理業者による処理までの全工程を、一元的に管理できることが望ましい（例えば、特許文献１参照）。

特開２００１−２８２９０２号公報

さらに、上述したリコールに際して、危険物等を回収する場合には、一時的に大量の危険物等を運送、処理しなければならないので、製造業者においては、運送業者、処理業者を含めた一連の処理フローを効率的に運用する必要がある。

本発明の目的は、危険物等を一般家庭から回収し、処理業者による廃棄処理を行うまでの工程を効率的に行うための危険物等の回収システムおよびその方法を提供することにある。

本発明は、このような目的を達成するために、一実施態様は、危険物等を顧客から回収し、処理する工程を管理するための危険物等の回収システムにおいて、前記顧客の端末に通信可能に接続された基幹サーバを備え、前記基幹サーバは、前記顧客の端末から受付フォームに入力された情報を取得し、前記受付フォームに入力された前記危険物等の数量から、前記危険物等を運送する際の個口数を算出し、前記危険物等を回収して処理する処理業者に関する情報が格納されたデータベースを参照して、前記数量と前記個口数とに基づいて処理業者を決定する主制御部と、前記決定された処理業者のサーバに集荷指示ファイルを送信する通信処理部とを含むことを特徴とする。

前記基幹サーバには、前記処理業者が一日に処理できる量、および一日単位で受け入れた本数と処理した本数とを集計した配送枠が格納され、前記基幹サーバは、前記配送枠を参照して、前記決定された処理業者において最短の受入可能日を決定することができる。

以上説明したように、本発明によれば、基幹サーバに処理業者を管理するためのデータベースを有しているために、一時的に大量の危険物等を運送、処理する場合であっても、危険物等の数量と個口数とに基づいて、最適な、運送業者、処理業者を決定することができる。

本発明の一実施形態にかかる危険物等の回収システムを示す構成図である。 本実施形態の危険物等の回収システムにおける基幹サーバの構成を示す図である。 本実施形態の基幹サーバにおける処理の流れを示す図である。 基幹サーバにおける処理業者を管理するためのデータレコードの一例を示す図である。 基幹サーバにおける配送枠を管理するためのデータレコードの一例を示す図である。 基幹サーバにおける危険物等の回収依頼を受け付けるための画面を示す図である。 基幹サーバにおける申込受付を管理するためのデータレコードの一例を示す図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。本実施形態では、危険物として卓上コンロ用のカセットボンベを例に、リコールが発生して、これを一般家庭から回収し、処理業者による廃棄処理を行う場合を説明する。

図１に、本発明の一実施形態にかかる危険物等の回収システムを示す。本実施形態では、製造業者が所有する業務用システム１の中のサブシステムとして、危険物等の回収システムが構築されている。業務用システム１には、顧客の端末、外部の業者のシステムとのインタフェースとなるフロントエンドサーバ１４に、危険物等の回収システムの基幹サーバ１１、顧客管理サーバ１２、商品管理サーバ１３などが接続されている。フロントエンドサーバ１４は、インターネット２などの通信回線を介して、顧客の端末３ａ，３ｂ、処理業者のサーバ４、運送業者のサーバ５に接続されている。危険物等の回収システムは、基幹サーバ１１が主となり、他のサーバと連携して、危険物等を顧客から回収し、処理する工程を管理する。

図２に、本実施形態の危険物等の回収システムにおける基幹サーバの構成を示す。危険物等の回収システムの基幹サーバ１１は、危険物等を顧客から回収し、処理する工程を管理するためのサーバプログラムと種々のデータベースが格納された記憶部２２と、業務用システム１内の通信インタフェースとなる通信処理部２３とが接続された主制御部２１を備えている。

記憶部２２には、危険物等を回収して処理する処理業者に関する情報等が格納された危険物処理ＤＢ２２１、顧客宅から処理業者まで危険物等を運送する運送業者の情報等が格納された運送管理ＤＢ２２２、および顧客からの回収依頼を受け付けた際の受付フォームが格納された申込受付ＤＢ２２３とが含まれる。

図３に、本実施形態の基幹サーバにおける処理の流れを示す。最初に、基幹サーバ１１は、処理業者のサーバ４から各データベースのデータレコードに必要な情報を取得して記録しておく（Ｓ３１）。

図４に、基幹サーバにおける処理業者を管理するためのデータレコードの一例を示す。危険物処理ＤＢ２２１のデータレコードには、処理業者に関する設備データとして、受け入れ可能な危険物の種類（本実施形態では、カセットボンベに限るので図示を省略）、受け入れ可能な１個口当りの処理数（カセットボンベの本数）、一日に処理できる危険物等の量（カセットボンベの処理可能本数）、受け入れ可能な日時などが記録されている。

処理業者の処理設備、例えば、カセットボンベからガスを抜き取る設備では、所定の治具に複数本のカセットボンベを収容して、まとめて処理する方法が取られる。従って、カセットボンベを回収する際にも、所定の治具にそのまま収容可能な荷姿で回収できれば、処理効率が向上する。本実施形態では、カセットボンベの６本入り容器と２４本入り容器とを使用する場合を例に説明する。

図５に、基幹サーバにおける配送枠を管理するためのデータレコードの一例を示す。処理業者は、設備に応じて一日に処理できる量、すなわちカセットボンベの処理本数（処理可能本数）が決められている。基幹サーバは、一日単位で、受け入れた本数（受入本数）と処理した本数（処理本数）とを集計して、日々更新し、「配送枠」として危険物処理ＤＢに記録している。各設備の処理本数の最大値が、処理可能本数であり、受入本数がその日の処理可能本数を上回ると、翌日に処理することになる。

そこで、向こう２月程度、各設備ごとに「配送枠」を参照して、その日に受け入れることができるカセットボンベの本数を算出し、運送管理ＤＢ２２２のデータレコードに記録しておく。

図６に、基幹サーバにおける危険物等の回収依頼を受け付けるための画面を示す。顧客は、スマートフォン、ＰＣなどの端末３ａ，３ｂから業務用システム１にアクセスし、フロントエンドサーバ１４が提示する受付フォーム６０に従って、カセットボンベの回収を申し込む（Ｓ３２）。

危険物等を運送する場合には、所定の荷姿に梱包して運送しなければならない。カセットボンベの場合には、製品出荷時に取り付けられていたキャップを取り付けた上で、キャップが外れないように梱包する必要がある。また、上述したように、処理設備に適した荷姿の容器を使用するために、受付フォーム６０には、カセットボンベの本数６１と不足するキャップ数６２とを入力する欄を設けている。

なお、図示していないが、受付フォーム６０には、カセットボンベの種類、製品名を入力する欄、または選択させる欄、購入日、使用状態などを入力する欄を設けてもよい。これらの情報を、商品管理サーバ１３に転送し、商品管理のために使用してもよい。また、危険物等によっては、製造時の容器とは異なる容器に入れられている場合もあり、このような情報を入力する欄も設けておくことができる。

受付フォーム６０には、その他に顧客の氏名６３、住所６４、連絡先６５、配送希望日時６６を入力する欄を設けている。これらの情報は、顧客管理サーバ１２に転送してもよいし、予め顧客管理サーバ１２に格納された情報から一部を抽出してもよい。なお、本実施形態では、カセットボンベの本数が３０本を超える場合には、さらに異なる要件を満たす運送方法を取る必要があるため、ここでは、製造業者の営業窓口での対応としている。また、他の危険物等であって、製造時の容器とは異なる容器に入れられている場合も営業窓口での対応とする。

図７に、基幹サーバにおける申込受付を管理するためのデータレコードの一例を示す。基幹サーバ１１の主制御部２１は、フロントエンドサーバ１４から受付フォーム６０に入力されたデータを取得して、記憶部２２の申込受付ＤＢ２２３のデータレコードに申込データを記録していく（Ｓ３３）。ここで、受け付けた顧客ごとに、処理業者を決定する手順について説明する。処理業者を決定するキーには、運送の際の個口数、処理する本数、配送希望日時を含む。

ａ）主制御部２１は、受付フォーム６０のカセットボンベの本数６１から、運送の際の個口数を算出する。
本数２４−３０本：２４本入り容器１個＋６本入り容器１個
本数 １−２３本：６本入り容器１−４個（本数を６で割って小数点以下切り上げ）
ｂ）２４本入り容器を使用する場合は、危険物処理ＤＢを参照して、２４本入り容器に対応した処理業者に優先的に割り当てる（図４，５を参照すると、処理業者ＦＦ）。運送管理ＤＢ２２２を参照して、受付フォーム６０のカセットボンベの本数６１を処理することができる最短の受入可能日を決定する。
ｃ）６本入り容器のみを使用する場合は、危険物処理ＤＢを参照して、受付フォーム６０のカセットボンベの本数６１を処理することができ、かつ配送枠から算出された最短の受入可能日が最も早い処理業者に割り当てる。
ｄ）次に、主制御部２１は、処理業者の受入可能日と受付フォーム６０の配送希望日時６６とを比較し、受入可能日が配送希望日時の翌日以降であれば、決定した処理業者を申込データに記録し、配送枠を更新する（Ｓ３４）。すなわち、処理業者は、受入可能日に当該顧客から回収したカセットボンベを処理する。
ｅ）受入可能日が配送希望日時と同日か、それ以前であれば、受入可能日−１日を、配送が可能な最短の配送日付として顧客に提案する。顧客への提案は、例えば、フロントエンドサーバ１４を介して、顧客の端末のブラウザ上に表示する。
ｆ）顧客の端末から、配送が可能な最短の配送日付に対する同意が得られれば、決定した処理業者を申込データに記録し、当該処理業者の受入可能日の配送枠を更新する。同意が得られなければ、配送希望日時＋１日を当該処理業者にて処理するものとして配送枠を更新する（Ｓ３４）。

図３に戻り、基幹サーバ１１の主制御部２１は、バッチ処理によって、申込受付ＤＢ２２３の申込データを参照して、当日に受け付けた申込をまとめて集荷指示ファイルとして、通信処理部２３を介して処理業者のサーバ４および運送業者のサーバ５に送信する（Ｓ３５，Ｓ３６）。

運送業者は、配送希望日時または配送が可能な最短の配送日付に、顧客宅に向かい、カセットボンベを集荷し（Ｓ３７）、翌日までに処理業者に配送する（Ｓ３８）。

危険物等の回収システムは、基幹サーバに処理業者を管理するためのデータレコードを有しているために、一時的に大量の危険物等を運送、処理する場合であっても、危険物等の数量と個口数とに基づいて、最適な、運送業者、処理業者を決定することができる。

また、危険物等の回収システムは、受入可能日が配送希望日時と同日か、それ以前であれば、新たに配送が可能な最短の日付を顧客に提案することができ、顧客は、危険物等の回収システムへの１回のアクセスで、配送日時の決定を行うことができる。

製造業者のコールセンター等による受付では、顧客との間で、危険物等の運送に関わる制約を考慮して、やり取りを行い、配送日時を決定しなければならないので、本システムによれば、リコールの受付業務を、コールセンター等に較べて安価に、正確に行うことができる。

１ 業務用システム
２ インターネット
３ａ，３ｂ 顧客の端末
４ 処理業者のサーバ
５ 運送業者のサーバ
１１ 基幹サーバ
１２ 顧客管理サーバ
１３ 商品管理サーバ
１４ フロントエンドサーバ

Claims (6)

1. 危険物等を顧客から回収し、処理する工程を管理するための危険物等の回収システムにおいて、
   前記顧客の端末に通信可能に接続された基幹サーバを備え、
   前記基幹サーバは、前記顧客の端末から受付フォームに入力された情報を取得し、前記受付フォームに入力された前記危険物等の数量から、前記危険物等を運送する際の個口数を算出し、前記危険物等を回収して処理する処理業者に関する情報が格納されたデータベースを参照して、前記数量と前記個口数とに基づいて処理業者を決定する主制御部と、
   前記決定された処理業者のサーバに集荷指示ファイルを送信する通信処理部とを含むことを特徴とする危険物等の回収システム。
2. 前記基幹サーバには、前記処理業者が一日に処理できる量、および一日単位で受け入れた本数と処理した本数とを集計した配送枠が格納され、
   前記基幹サーバは、前記配送枠を参照して、前記決定された処理業者において最短の受入可能日を決定することを特徴とする請求項１に記載の危険物等の回収システム。
3. 前記基幹サーバは、前記最短の受入可能日が前記受付フォームに入力された配送希望日時と同日か、それ以前であれば、前記最短の受入可能日−１日を、配送が可能な最短の配送日付として前記顧客の端末に提示することを特徴とする請求項２に記載の危険物等の回収システム。
4. 危険物等を顧客から回収し、処理する工程を管理するための危険物等の回収システムにおいて、前記顧客の端末に通信可能に接続された基幹サーバが実行する方法であって、
   前記顧客の端末から受付フォームに入力された情報を取得するステップと、
   前記受付フォームに入力された前記危険物等の数量から、前記危険物等を運送する際の個口数を算出するステップと、
   前記危険物等を回収して処理する処理業者に関する情報が格納されたデータベースを参照し、前記数量と前記個口数とに基づいて処理業者を決定するステップと、
   前記決定された処理業者のサーバに集荷指示ファイルを送信するステップと
   を備えたことを特徴とする方法。
5. 前記基幹サーバには、前記処理業者が一日に処理できる量、および一日単位で受け入れた本数と処理した本数とを集計した配送枠が格納され、
   前記決定するステップは、さらに、前記配送枠を参照して前記決定された処理業者において最短の受入可能日を決定することを特徴とする請求項４に記載の方法。
6. 前記最短の受入可能日が前記受付フォームに入力された配送希望日時と同日か、それ以前であれば、前記最短の受入可能日−１日を、配送が可能な最短の配送日付として前記顧客の端末に提示するステップをさらに備えた請求項５に記載の方法。

Images