JP2021002124A - 請求書発行管理制御装置、請求書発行管理制御プログラム - Google Patents

Abstract

【課題】遂行した業務に関して、業務に関わる条件によって請求先を自動判定することで業務遂行担当者の負担を軽減する。【解決手段】現場で業務を遂行した業務遂行担当者は、当該業務における請求書を作成し、料金請求先の判断をする必要がある。料金は、様々な条件によって、請求先が異なる。そこで、業務遂行担当者は、顧客対応端末装置へ通知し、請求書の作成を指示する。顧客対応端末装置では、業務に関わる条件情報を取得し、条件情報に基づいて、業務情報の作業項目毎の料金請求先を自動判定し、顧客へ通知する請求書を作成して、現場の業務遂行担当者が携帯する通信端末装置へ出力する。これにより、現場の業務遂行担当者の負担を軽減することができる。また、請求書の通知に対する顧客からの応答（例えば、電子サイン入力等）によって、業務遂行の完了を認定することができる。【選択図】図１

Description

本発明は、顧客から受け付けた業務を、業務遂行担当者を派遣することで行った作業に関する請求書発行を管理する業務分担システムにおける請求書発行管理制御装置、請求書発行管理制御プログラムに関するものである。

主としてガスを消費する設備に用いられる関連機器（以下、単に機器という）の修理業務は、顧客からの申し出（修理依頼）により発生する。

例えば、カスタマサービスセンターで修理受付を行い、修理希望予定日を調整し、修理業務が登録されることで、ガスを管理する事業者（製造及び輸入を行う事業者、販売を行う事業者、並びに協力企業である関連事業者を含む）から作業員を派遣して、機器の修理を行う。

修理等の業務が終了すると、業務遂行担当者は、当該業務に関して業務遂行結果報告を行うことで、一連の業務の終了と認識される。このため、業務を一元管理するためには、業務遂行担当者による業務遂行結果報告書の作成が必須となる。

特許文献１には、携帯電話機との間で送受信されるデータを使用して、検針スケジュールの生成から請求書発行までの一連の業務をサポートするシステムが記載されている。

この特許文献１において、携帯電話機は、サーバからダウンロードした検針すべき顧客のリストを格納する。検針時に、携帯電話機は、メータ上の二次元コードを読み取って顧客を識別し、ダウンロードした入力画面を介して検針データをサーバに送信する。サーバは、検針データに基づいて料金を計算し、請求データを生成して携帯電話機に送信する。請求データをプリンタから印刷すると、携帯電話機は、該当する顧客データを消去するようになっている。

また、特許文献２には、ガスメータの検針が行われる場合にガス料金の請求業務を効率的に行うことができる請求書発行システム等を提供するシステムが記載されている。

この特許文献２において、配送サーバーは、モバイル端末から検針対象としてのガスメータの検針処理の要求を受け付ける受付部と、この要求に応じた検針処理を行って、検針当月分の顧客のガス料金を計算する計算部と、記憶装置の支払い状況から上記要求に対する顧客の検針当月よりも前のガス料金の支払い状況を確認し、ガス料金が未払いのときには、当該未払い分のガス料金を記憶装置から読み出す支払い状況確認部と、検針当月分のガス料金、および、未払い分のガス料金を含む請求書の情報を発行する発行部と、請求書の情報をモバイル端末に送信する送信部とを備えている。

特開２０１３−９３０４４号「特許第５４５７５６６号」公報 特開２０１４−０１３５０４号「特許第５５５２１４２号」公報

しかしながら、特許文献１及び特許文献２では、検針データに基づく料金計算であり、例えば、機器修理の際の、保証の有無やメンテナンス契約の有無等によって、料金の請求先が複数に及んだり、顧客に請求する料金が異なるといった変更理由（条件情報）が存在しない。

本発明は、遂行した業務に関して、業務に関わる条件によって請求先を自動判定することで業務遂行担当者の負担を軽減することができる業務分担システムにおける請求書発行管理制御装置及び請求書発行管理制御装置プログラムを得ることが目的である。

本発明に係る請求書発行管理制御装置は、業務遂行担当者の業務遂行後に業務情報を受け付ける受付部と、前記受付部で受け付けた前記業務情報の受け付け後に、請求書作成指示があった場合に、遂行された業務に関わる条件情報を取得する取得部と、前記取得部で取得した前記条件情報に基づいて、前記業務情報の作業項目毎の料金請求先を自動判定する判定部と、前記業務情報の内、顧客に対して、業務遂行にかかった費用に基づく料金を請求する請求項目を抽出した請求書を出力すると共に、出力された請求書に対する前記顧客からの確認応答により、業務遂行の完了を認定する認定部と、を有している。

本発明において、業務遂行による結果情報を一括管理する上位制御部と、業務遂行担当者が携帯し得る下位制御部と、複数の前記下位制御部を管理する中位制御部と、を備え、
前記受付部、前記取得部、前記判定部、及び前記認定部による請求書発行管理制御が、前記上位制御部又は前記中位制御部によって実行されることを特徴としている。

本発明によれば、例えば、受付部で受け付けた前記業務情報の受け付け後に、下位制御部から請求書作成指示があった場合に、上位制御部及び中位制御部の少なくとも一方から、遂行された業務に関わる条件情報を取得し、条件情報に基づいて、業務情報の作業項目毎の料金請求先を自動判定し、業務情報の内、顧客に業務遂行にかかった費用に基づく料金を請求する請求項目を抽出して請求書を出力すると共に、出力された請求書に対する顧客からの確認応答により、業務遂行の完了を認定している。これにより、現場で作業する業務遂行担当者による請求書発行を支援し、かつ、業務遂行完了の認定を行うことができる。

本発明において、前記中位制御部の各々が、業務遂行に必要な部品の在庫を所有しており、前記上位制御部は、前記中位制御部で所有している部品の在庫情報を集約して一括して管理し、前記中位制御部の各々への在庫補充、及び、前記中位制御部間での在庫の振り分けを実行することを特徴としている。

上位制御部では、請求書発行を契機として、業務遂行によって使用した部品等の在庫を補充する、或いは、中位制御部間で在庫を融通するといった一括管理することで、過不足のない在庫管理を行うことができる。

本発明において、前記条件情報が、保証判定情報、ガス契約先情報、少なくともメンテナンスを含むサービス加入状況情報、機器情報、修理方法情報、及びリコール・瑕疵情報の少なくとも１つを含むことを特徴としている。

条件情報として、保証判定情報、ガス契約先情報、サービス加入状況情報、機器情報、修理方法情報、及びリコール・瑕疵情報の少なくとも１つを含むことで、的確に料金請求先を判定することができる。

本発明に係る請求書発行管理制御プログラムは、コンピュータを、上記の請求書発行管理制御装置の受付部、取得部、判定部、及び認定部として動作させることを特徴としている。

以上説明した如く本発明では、遂行した業務に関して、業務に関わる条件によって請求先を自動判定することで業務遂行担当者の負担を軽減することができるという効果を奏する。

本実施の形態に係る業務分担システムの概略図である。 （Ａ）は本実施の形態に係り、顧客対応端末装置（中位制御部）に設けられた請求書作成部での制御を機能別に説明する機能ブロック図、（Ｂ）は変形例に係る上位制御部、中位制御部、下位制御部の連携状態を示す概念図である。 一例として、業務支援管理サーバーで実行される進捗状況管理制御ルーチンを示すフローチャートである。 本発明の請求書発行管理制御装置における、顧客の業務履歴情報の活用のみならず、修理等の業務受付から業務完了後の料金請求までの、一連の作業を実行するまでに必要十分なシステム図の実施例である。 本実施例のシステムでの作業フローの内、機器修理の受付のためのフローチャート（１／３）である。 本実施例のシステムでの作業フローの内、機器修理の受付のためのフローチャート（２／３）である。 本実施例のシステムでの作業フローの内、機器修理の受付のためのフローチャート（３／３）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（１／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（２／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（３／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（４／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（５／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（６／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（７／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（８／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（９／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（１０／１１）である。 本実施例のシステムでの作業フローの内、機器修理の現場作業のためのフローチャート（１１／１１）である。 本実施例のシステムでの作業フローの内、機器修理の部品発注承認・取消のためのフローチャート（１／２）である。 本実施例のシステムでの作業フローの内、機器修理の部品発注承認・取消のためのフローチャート（２／２）である。

図１は、本実施の形態に係る業務分担システム１０の概略図である。

業務分担システム１０は、例えば、業務支援管理サーバー８４と、提携店１４に設置された顧客対応端末装置１６とを備えている。

業務支援管理サーバー８４と、顧客対応端末装置１６とは、ネットワーク２０を介して接続され、相互に情報の通信が可能となっている。

また、提携店１４には、前記顧客対応端末装置１６と同等の機能を有し、業務遂行担当者が業務遂行現場まで携帯することが可能な、通信携帯端末２２が具備されている。

通信携帯端末２２は、業務遂行現場を通信エリアとする無線通信基地２０Ａを介して、提携店１４の顧客対応端末装置１６と通信する他、直接、ガス管理者側（例えば、業務支援管理サーバー８４）へもアクセス可能となっている。

ここで、顧客２４は、例えば、顧客端末２６から、提携店１４に対して、ガス機器等の修理依頼を行うと、提携店１４では、当該修理依頼を受け付ける（受付部１６Ａ）。

なお、図１では、顧客端末２６として、スマートホンをイメージして図示しているが、携帯電話や固定電話等の他の通信機器であってもよい。

また、顧客２４は、提携店１４に修理を依頼せず、直接ガス管理者側のお客様センター（図１では、図示省略）へ連絡してもよいし、顧客２４が所持するＰＣ（パーソナルコンピュータ、図１では、図示省略）を用いて、ネット通信で修理を依頼してもよい。

顧客２４から提携店１４へ修理依頼があり、これを受け付けると、顧客対応端末装置１６の業務分担部１６Ｂでは、業務遂行担当者を選出する。

提携店１４では、顧客２４との対応において、受け付けた修理の業務遂行の日時等を決定し、業務遂行指示書として登録する。

業務遂行指示書は、選出した業務遂行担当者の中から確定した業務遂行担当者に割り当てられ、スケジュール管理がなされる。

ここで、業務遂行担当者は、業務遂行指示書に従い業務を遂行すると、当該業務遂行後に業務遂行結果報告書を作成するようになっている。業務遂行結果報告書は、顧客に対する請求書として性質が含まれている。言い換えれば、業務遂行結果報告書の内容に基づいて、顧客に対する請求書が作成されることになる。

しかしながら、遂行した業務の中には、当該業務の請求先が異なる場合がある、また、同一業務であっても、請求者によって請求料金が異なる場合がある。

一例として、顧客の契約状況や、各種保証、リコール等、様々な条件が要因となり、料金請求先（ガス管理会社、お客様、メーカー、契約メンテナンス店、施工店等）が変わる。この場合、業務遂行現場（業務遂行担当者）は、それぞれの料金請求先へ適切な請求金額を計算し、請求しなければならない。

なお、業務内容によっては、上記要因に関係なく統一料金が設定され、統一の費用価格（請求）となる場合もある。

業務遂行現場における業務遂行担当者にとって、業務遂行結果報告書及び請求書の作成、特に請求書における料金請求先特定は、複雑な料金体系を理解し、かつ、遅滞なく正確に料金を請求する必要があり、煩雑な作業を強いられることになる。

そこで、本実施の形態では、上位制御部としての業務支援管理サーバー８４、中位制御部としての顧客対応端末装置１６、及び下位制御部としての通信携帯端末２２のそれぞれを連携し、複雑な料金体系の下、遅滞なく正確に料金請求先を特定する機能（請求書作成機能）を構築した。なお、業務遂行結果報告書と請求書とはセットで作成することになるが、以下では、請求書に着目して説明する。

図１に示される如く、本実施の形態では、顧客対応端末装置１６に請求書作成部１６Ｃ及び条件情報データベース１６ＤＢが設けられている。

請求書作成部１６Ｃでは、通信携帯端末２２から受けた業務情報及び業務遂行結果報告書に基づく請求書の作成指示に対して起動し、条件情報データベース１６ＤＢに格納された料金体系に関する情報に基づき、業務情報に応じた請求書が作成されるようになっている。なお、業務情報とは、業務の実施内容及びその結果に関する情報をいう。

なお、上位制御部である業務支援管理サーバー８４には、条件情報データベース８４ＤＢが設けられている。すなわち、本実施の形態では、条件情報データベース１６ＤＢ及び条件情報データベース８４ＤＢが存在することになる。

本実施の形態では、条件情報データベース１６ＤＢでは、各提携店１４が管轄するエリア単位の条件情報（ローカルな条件情報）を格納し、条件情報データベース８４ＤＢでは、全てのエリアで適用される条件情報（グローバルな条件情報）を格納している。地域毎に設定した料金サービス等が存在する場合があるためである。

なお、条件情報データベース８４ＤＢに、各提携店１４におけるローカルな条件情報を格納してもよい。この場合、各提携店１４には、条件情報データベース１６ＤＢは不要であり、各提携店１４から業務支援管理サーバー８４へアクセスして、グローバルな条件情報と共に、ローカルな条件情報を取得するようにすればよい。

図２（Ａ）は、本実施の形態に係り、顧客対応端末装置１６（中位制御部）に設けられた請求書作成部１６Ｃでの制御を機能別に説明する機能ブロック図である。

通信携帯端末２２（下位制御部）は、業務情報出力部３０、作成指示部３２、受領部３４、及び了承確認部３５を備えている。

業務遂行担当者は、業務遂行現場での業務が終了すると、業務情報出力部３０を介して業務情報を顧客対応端末装置１６へ出力する。

顧客対応端末装置１６では、業務情報出力部３０から出力された情報を、業務情報取得部３６で取得し、一時的に記憶する。

業務遂行担当者は、通信携帯端末２２の業務情報出力部３０を介して業務情報を出力すると、時系列で、作成指示部３２を介して請求書の作成指示を顧客対応端末装置１６へ出力する。

顧客対応端末装置１６では、作成指示部３２から指示された作成指示を、作成部３８で受け付ける。

作成部３８は、作成指示を受け付けると、業務情報取得部３６で取得した業務情報に基づいて請求書を作成する。このとき、業務毎（又は、１業務内の各項目毎）に料金請求先が異なる場合がある。

そこで、作成部３８は、条件情報取得部４０に条件情報を問い合わせる。

条件情報取得部４０は、条件情報データベース１６ＤＢ、及び業務支援管理サーバー８４（上位制御部）に設けられた条件情報データベース８４ＤＢに接続されており、問い合わせのあった業務（又は項目）に対応する条件情報を読み出し、料金請求先判定部４２へ通知する。条件情報としては、例えば、保証判定情報、ガス契約先情報、少なくともメンテナンスを含むサービス加入状況情報、機器情報、修理方法情報、及び、リコール・瑕疵情報等の料金の算出、請求先の算出に必要な情報が挙げられる。

料金請求先判定部４２では、業務（又は項目）毎に料金及び料金請求先を判定し、出力部４４へ送出する。

出力部４４では、通信携帯端末２２の受領部３４へ請求書を出力する。

通信携帯端末２２では、受領部３４で受領した請求書を、出力デバイスに出力する。

本実施の形態では、出力デバイスによる出力としてタッチパネル画面へ表示する。このとき、了承確認部３５では、顧客に表示画面を確認してもらい、所謂電子サインによって顧客の業務遂行に対する了承確認を依頼する。

顧客は、タッチパネル画面に表示される請求書を閲覧し、その一部の領域に設けられサイン入力領域に、タッチペン等でサインを行うことで、業務遂行が完了したことを了承し確認する。

了承確認部３５は、顧客対応端末装置１６の業務遂行完了認定部４６に送出され、業務遂行完了と顧客の了承確認とを業務支援管理サーバー８４へ通知することで、当該業務が完結したこととなる。

以上により、業務遂行現場で業務を遂行した業務遂行担当者は、複雑な料金体系を十分に理解していなくても、業務及び項目毎に料金の請求先が明確となった請求書を入手することができ、顧客に対する請求書の発行を、遅滞なく、かつ正確に行うことができる。

以下に、本実施の形態の作業を、図３のフローチャートに従い説明する。

ステップ５０では、業務情報を取得したか否かを判断する。このステップ５０で否定判定された場合は、このルーチンは終了する。また、ステップ５０で肯定判定された場合は、ステップ５２へ移行する。

ステップ５２では、請求書作成の指示があったか否かを判断する。このステップ５２で、否定判定された場合は待機し、肯定判定されると、請求書作成の指示があったと判断し、ステップ５４へ移行する。

ステップ５４では、条件情報データベース１６ＤＢ及び／又は条件情報データベース８４ＤＢへアクセスし、次いで、ステップ５６へ移行して、請求書の作成を開始する。

次のステップ５８では、業務情報に対応する条件情報を取得し、次いでステップ６０へ移行して料金請求先を判定し、ステップ６２へ移行して、請求書に反映させる。

次のステップ６４では、請求書の作成が終了したか否かを判断し、否定判定された場合は、ステップ５８へ戻り、上記工程を繰り返す。

また、ステップ６４で肯定判定されると、ステップ６６へ移行して、請求書を通信携帯端末２２へ出力し、ステップ６８へ移行する。

ステップ６８では、通信携帯端末２２へ送出した請求書に基づき、顧客から了承確認のサイン（顧客サイン）を受けたか否かを判断する。

このステップ６８で否定判定された場合は顧客サインを待ち、肯定判定されると、ステップ７０へ移行して、業務遂行完了処理を実行し、このルーチンは終了する。

なお、何らかの理由で顧客サインを受けることができない場合は、その旨に理由等を、請求書と共に作成する業務遂行結果報告書に記載し、業務遂行完了処理を行わず、業務遂行現場での業務を一旦終了する場合もある。

以上説明した如く、本実施の形態では、現場で業務を遂行した業務遂行担当者は、当該業務における業務遂行結果報告書を作成し、料金請求先を判断し、請求書を作成する必要がある。料金は、様々な条件によって、請求先が異なる。例えば、保証期間であれば、顧客への請求は不要であり、メンテナンスサービス等に加入している場合は、メンテナンス契約の範疇か否かを判断する必要がある。

そこで、業務遂行担当者は、業務情報を業務遂行担当者の派遣元である提携店１４へ通知し、請求書の作成を指示する。この指示に基づき、条件情報取得部４０では、提携店１４の業務遂行部署で遂行された業務に関わる条件情報を取得し、条件情報に基づいて、業務情報の作業項目毎の料金請求先を自動判定し、顧客へ通知する請求書を作成して、現場の業務遂行担当者が携帯する通信端末装置へ出力する。これにより、現場の業務遂行担当者の負担を軽減することができる。

また、中位制御部では、この請求書の通知に対する顧客からの応答（例えば、下位制御部への電子サイン入力等）によって、業務遂行の完了を認定することができる。

なお、本実施の形態では、図２（Ａ）に示される如く、業務遂行担当者の通信携帯端末２２を下位制御部とし、提携店１４等の業務遂行部署に設置された顧客対応端末装置１６を中位制御部としたが、通信携帯端末２２と顧客対応端末装置１６とを、同位の制御部として扱ってもよい。

図２（Ｂ）に示すように、下位制御部（通信携帯端末２２）が、中位制御部（顧客対応端末装置１６）を介さず、直接、上位制御部（業務支援管理サーバー８４）へアクセスして、業務情報を受信する構成であってもよい。

また、本実施の形態において、業務を遂行するに際し、請求書が発行されるが、当該請求書に基づき、業務遂行の際に使用した部品を抽出し、各提携店１４での在庫状況を管理するようにしてもよい。

在庫管理は、図１に点線で示す在庫管理サーバー８６によって実行される。在庫管理サーバー８６には、在庫情報データベース８６ＤＢが設けられている。在庫情報データベース８６ＤＢには、各部品と当該部品を管理している提携メンテナンス店との相関を示すデータが格納されており、作成された請求書に基づいて、各提携店１４の在庫状況を確認し、補充するべき部品を抽出して、補充することで、各提携店１４での在庫の過不足を解消することができる。

さらに、本発明に係る請求書発行管理制御装置は、本実施の形態で説明した修理業務における業務に限定されるものではない。すなわち、本発明に係る請求書発行管理制御装置は、修理に関する業務以外に、定期保安巡回に関する業務、開閉栓に関する業務、機器等の販売に関する販売等の、他の業務にも流用可能である。

以下、実施例として、本実施の形態の業務分担システムで修理業務を受け付けたときの請求書発行の流れを説明する。本実施の形態の情報収集は、図１４のステップ６５０Ａ〜６５６Ａ、図１５のステップ７０４Ａ、７０６Ａ、及び図１６のステップ７０８Ａ〜７１６Ａ等の各ステップの作業に関連して実行されるものである。

図４は、本発明の請求書発行管理制御装置における、顧客の業務履歴情報の活用のみならず、修理等の業務受付から業務完了後の料金請求までの、一連の作業を実行するまでに必要十分なシステムの構築した実施例である。

なお、本実施の形態（図１参照）で説明した構成と重複する部分は、同一の符号を付すこととする。

図４に示される如く、ガス管理者８０側は、例えば、ＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）等のイントラネット８２が構築されている。

イントラネット８２には、顧客管理サーバー１２、業務支援管理サーバー８４、在庫管理サーバー８６、順路最適化管理サーバー８８、お客様センター管理サーバー９０、及びインターネット等のネットワーク２０と接続するためのルーター９１を備えている。

なお、図４では、図示は省略したが、顧客管理サーバー１２、業務支援管理サーバー８４、在庫管理サーバー８６、順路最適化管理サーバー８８、及び、お客様センター管理サーバー９０には、それぞれの機能を実現するために必要な情報がデータベースに格納されており、イントラネット８２を介して、相互に情報のやりとりが可能となっている。

インターネット２０には、提携店１４に設置された顧客対応端末装置１６が接続されると共に、無線通信基地２０Ａを介して、業務遂行担当者がそれぞれ所持する通信端末装置２２がインターネット２０にアクセス可能となっている。

また、インターネット２０には、顧客所有のＰＣ９２が接続され、修理依頼等を、インターネット２０を介して申し込むことができる。

また、顧客は、電話回線９４を用いて、顧客端末２６（例えば、電話）により顧客対応端末装置１６が設置された部署（提携店１４）、お客様センター管理サーバー９０が設置された部署（管理するお客様センター）、及び、業務支援管理サーバー８４が設置された部署へ修理依頼を申し込むことができる。

以下に、本実施例の作用を説明する。

まず、顧客から業務依頼（ここでは、修理業務を例にとる）があった場合に実行される、提携店１４に設置された顧客対応端末装置１６、業務遂行担当者が所持する通信端末装置２２、及びイントラネット８２に接続された何れかのサーバーとの間での業務受付に関する処理手順を示す。なお、作業フローには、制御プログラムによる処理と、担当者等の手作業による処理とが混在するが、以下の条件の下、三者を時系列に関連付けた作業フローとして説明する。

（条件１） 顧客対応端末装置１６（提携店１４に据置）での処理には、ステップ番号の末尾に符号「Ａ」を付す。

（条件２） 通信端末装置２２（業務遂行担当者携帯）での処理には、ステップ番号の末尾に符号「Ｂ」を付す。

（条件３） イントラネット８２に接続された何れかのサーバーのデータベースへのアクセスでの処理には、ステップ番号の末尾に符号「Ｃ」を付す。

（条件４） 顧客からは、電話（携帯電話、スマホ、固定電話等）を用いた通話により業務依頼がある場合と、通信装置（ＰＣ、スマホ、タブレット型通信端末装置等）を用いた通信による業務依頼がある場合とがあるが、ここでは、総称して、「ＰＣ９２」での処理として、ＰＣ９２での処理には、ステップ番号の末尾に符号「Ｄ」を付す。なお、例外として、ステップ番号の末尾に符号「Ｄ」を付した処理の中には、顧客による簡易処置の実施が含まれるものとする（後述するステップ２０６Ｄ参照）。

『機器修理の受付』

図５〜図７は、本実施の形態に係る、『業務の受付』の際に、ＰＣ９２、顧客対応端末装置１６、業務遂行担当者が所持する通信端末装置２２、及び顧客管理サーバー１２の間で実行される作業フローである。

（図５作業フロー）

顧客から業務依頼（例えば、顧客からの申し出、電話等）があると（ステップ１００Ｄ）、イントラネット８２に接続された何れかのサーバーのデータベース（例えば、図４に示す、顧客管理サーバー１２の顧客固有情報データベース）へアクセスして（ステップ１０２Ｃ）、お客様を特定する（ステップ１０４Ａ）。

この特定の際、該当する顧客があるか否か（既に登録済か否か）を判断し（ステップ１０６Ａ）、否定判定の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１０８Ｃ）、お客様登録を実行する（ステップ１１０Ａ）。

一方、ステップ１０６Ａで肯定判定の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１１２Ｃ）、お客様情報を確認して（ステップ１１４Ａ）、ステップ１１６Ａへ移行する。ステップ１１６Ａには、ステップ１１０Ａでお客様登録が完了した場合にも移行し、お申し出業務の内容を確認する。

次に、業務内容が、特定の業務（ここでは、修理、コール点検とする）か否かを判断し（ステップ１１８Ａ）、否定判定の場合は、他業務の受付へ移行する（ステップ１２０Ａ）。

一方、ステップ１１８Ａで肯定判定の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１２２Ｃ）、過去の業務、接点履歴、予定案件の確認を行う（ステップ１２４Ａ）。

ステップ１２４Ａでの確認後、新規受付（ここでは、修理依頼）を実行し（ステップ１３０Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１３２Ｃ）、顧客（お申し出者）の確認及び報告を行い（ステップ１３４Ａ）、処理継続点Ａ１に従い移行する（図６のステップ１６６Ａへ移行）。

（図６の作業フロー「処理継続点Ａ１以降の作業フロー」）

図６の作業フローは、図５のステップ１３４Ａからの継続となる。

まず、対象機器を確認し（ステップ１６６Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１６８Ｃ）、お客様所有機器リストにより選択する（ステップ１７０Ａ）。ステップ１７０Ａにおいて、選択できた場合は（ステップ１７２Ａの肯定判定）、故障内容を確認する（ステップ１７４Ａ）。

選択できない場合は（ステップ１７２Ａの否定判定）、イントラネット８２に接続された何れかのサーバーのデータベース（例えば、図４に示す、業務支援管理サーバー８４で管理する機器マスターデータベース）へアクセスして（ステップ１７６Ｃ）、機器マスター一覧から選択する（ステップ１７８Ａ）。ステップ１７８Ａにおいて、選択できた場合は（ステップ１８０Ａの肯定判定）、故障内容を確認する（ステップ１７４Ａ）。

選択できない場合は（ステップ１８０Ａの否定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１８１Ｃ）、機器種別のみ選択し（ステップ１８２Ａ）、故障内容を確認する（ステップ１７４Ａ）。ステップ１７８Ａにおいて、選択できた場合は（ステップ１８０Ａの肯定判定）、故障内容を確認する（ステップ１７４Ａ）。

ステップ１７４Ａで故障内容を確認すると、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１８８Ｃ）、故障内容を報告する（ステップ１９０Ａ）。

故障内容の報告後、簡易処置方法がない場合は（ステップ１９２Ａの否定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１９４Ｃ）、作業業務箇所を確認し（ステップ１９６Ａ）、担当店の変更の要否を判断する（ステップ１９８Ａ）。

担当者の変更が必要ない場合は（ステップ１９８Ａの否定判定）、処理継続点Ｃ１に従い移行する（図７のステップ２１４Ａへ移行）。

また、担当者の変更が必要な場合は（ステップ１９８Ａの肯定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２００Ｃ）、作業業務箇所の変更を通知し（ステップ２０２Ａ）、処理継続点Ｃ１に従い移行する（図７のステップ２４０Ａへ移行）。

一方、ステップ１９０Ａで故障内容の報告後、簡易処置方法がある場合は（ステップ１９２Ａの肯定判定）、顧客に対して、簡易処置方法を説明し、実施を依頼することで（ステップ２０４Ａ）、顧客は、簡易処置を実施する（ステップ２０６Ｄ）。顧客は、簡易処置の実施により、トラブルが解消したか否かを顧客対応端末装置１６へ報告する。

トラブルが解消した場合は（ステップ２０８Ｄの肯定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２１０Ｃ）、電話対応完了報告を行い（ステップ２１２Ａ）、処理継続点Ｄ１に従い移行する（図７のステップ２６８Ａへ移行）。

また、顧客による簡易処置の実施で、トラブルが解消しない場合は（ステップ２０８Ｄの否定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ１９４Ｃ）、作業業務箇所を確認し（ステップ１９６Ａ）、担当者の変更の要否を判断する（ステップ１９８Ａ）。

担当者の変更が必要ない場合は、処理継続点Ｃ１に従い移行する（図７のステップ２４０Ａへ移行）。

また、担当者の変更が必要な場合は（ステップ１９８Ａの肯定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２００Ｃ）、作業業務箇所の変更を通知し（ステップ２０２Ａ）、処理継続点Ｃ１に従い移行する（図７のステップ２４０Ａへ移行）。

図７は、処理継続点Ｃ１を介して、図６のステップ１９８Ａから処理が移行され、まず、ステップ２４０Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２４２Ｃ）、契約情報等のお客様情報を確認し、顧客に出張修理の了承を確認する（ステップ２４４Ａ）。顧客から了承が得られない場合は（ステップ２４６Ｄの否定判定）、当該作業での受け付けを完了する（ステップ２４８Ａ）。また、顧客から了承を得た場合は（ステップ２４６Ｄの肯定判定）、有償修理の可能性の有無を判断する（ステップ２５０Ａ）。

有償修理の可能性がある場合は（ステップ２５０Ａの肯定判定）、請求先情報を確認し（ステップ２５２Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２５４Ｃ）、請求先情報を報告して（ステップ２５６Ａ）、作業希望日時を確認する（ステップ２５８Ａ）。また、有償修理の可能性ない場合（ステップ２５０Ａの否定判定）は、ステップ２５８Ａへ移行して、作業希望日時を確認する。

次に、ステップ２５８Ａでの作業希望日時確認の回答に際し、業務遂行担当者との調整の要否を判断する（ステップ２６０Ａ）。

調整が必要な場合（ステップ２６０Ａの肯定判定）は、後ほど現場作業員から日時連絡することを顧客に説明し（ステップ２６２Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２６４Ｃ）、作業予定日時を報告して（ステップ２６６Ａ）、ステップ２６８Ａへ移行する。

一方、調整が不要（日時決定）な場合（ステップ２６０Ａの否定判定）は、作業予定日時を回答し（ステップ２７０Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ２７２Ｃ）、作業定日時を報告し（ステップ２７４Ａ）、ステップ２６８Ａへ移行する。なお、このステップ２６８Ａには、処理継続点Ｄ１を介して、図６のステップ２１２Ａからの移行もある。

ステップ２６８Ａでは、他業務の受け付けの有無を判断する。他業務の受け付けがない場合は（ステップ２６８Ａの否定判定）、受け付けを完了し（ステップ２７６Ａ）、他業務の受け付けがある場合は（ステップ２６８Ａの肯定判定）、処理継続点Ｅ１に従い移行する（図５ステップ１１６Ａへ移行）。

『機器修理の現場作業』

図８〜図１８は、本実施の形態に係る、『業務遂行現場対応』の際に、ＰＣ９２、顧客対応端末装置１６、業務遂行担当者が所持する通信端末装置２２、及び顧客管理サーバー１２の間で実行される作業フローである。なお、業務遂行現場対応は、基本的に、業務遂行担当者が所持する通信端末装置２２と、顧客管理サーバー１２とのやりとりが主体となる。

（図８の作業フロー）

業務遂行担当者は、通信端末装置２２を所持しており（ステップ４００Ａ）、まず、訪問先の顧客が在宅か否かを判断する（ステップ４０２Ａ）。

不在の場合は（ステップ４０２Ａの否定判定）、事務所に連絡して不在票Ｐ１を発行し（ステップ４０４Ａ及びステップ４０６Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４０８Ｃ）、不在状況の報告を実行し（ステップ４１０Ａ）、処理継続点Ｑ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

一方、在宅の場合（ステップ４０２Ａの肯定判定）、又は、処理継続点Ｓ２を介して、後述する図１５のステップ６８２Ａから処理が移行された場合、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４１２Ｃ）、作業開始報告を実行する（ステップ４１４Ａ）。

次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４１６Ｃ）、修理対象機器情報を確認し（ステップ４１８Ａ）、顧客に対して問診を行う（ステップ４２０Ａ）。

問診後は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４２２Ｃ）、対象機器を確認し（ステップ４２３Ａ）、確認の結果、機器が特定されない（未特定）、又は特定違いか否かを判断する（ステップ４２４Ａ）。

機器が特定されない（未特定）、又は特定違いであった場合（ステップ４２４Ａで肯定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４２６Ｃ）、機器を再特定し（ステップ４２８Ａ）、機器の登録の要否を判断する（ステップ４３０Ａ）。

機器の登録が必要な場合（ステップ４３０Ａの肯定判定）は、所有機器管理小分類の名称へ変更し（ステップ４３２Ａ）、機器の登録が不要な場合（ステップ４３０Ａの否定判定）は何もせず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４３４Ｃ）、製造番号・製造年月の確認及び報告を実行する（ステップ４３６Ａ）。

また、機器が特定された場合（ステップ４２４Ａの否定判定）においても、ステップ４３６Ａへ移行して、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４３４Ｃ）、製造番号・製造年月の確認及び報告を実行する。

次に、業務遂行担当者は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４３８Ｃ）、故障診断を実行する（ステップ４４０Ａ）。故障診断後、技術情報の確認の要否を判断する（ステップ４４２Ａ）。

技術情報が必要な場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４４４Ｃ）、修理統計情報の確認（ステップ４４６Ａ）、機器情報サービスの確認（ステップ４４８Ａ）、及び「テクガイ情報（テクニカルガイド情報）」の確認（ステップ４５０Ａ）を行うと共に、イントラネット８２に接続された何れかのサーバーのデータベース（例えば、図４に示す業務支援管理サーバー８４で管理する特定メンテナンスツール供給データベース）へアクセスして（ステップ４５２Ｃ）、特定メンテナンスツールを取得し（ステップ４５４Ａ）、処理継続点Ｂ２に従い移行する（後述する図９のステップ４５８Ａへ移行）。

また、技術情報が不要な場合（ステップ４４２Ａの否定判定）は、処理継続点Ｂ２に従い移行する（後述する図９のステップ４５８Ａへ移行）。

（図９の作業フロー）

図９は、処理継続点Ｂ２を介して、図８のステップ４４２Ａ又はステップ４５６Ａから処理が移行され、まず、有償修理か否かを判断する（ステップ４５８Ａ）。無償修理の場合は（ステップ４５８Ａの否定判定）、別処理となり、処理継続点Ｒ２に従い移行する（後述する図１１のステップ５５４Ａへ移行）。

有償処理の場合（ステップ４５８Ａの肯定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４６０Ｃ）、請求先（異名義情報の確認）を取得して（ステップ４６２Ａ）、顧客へ請求先（異名義）の確認を行い（ステップ４６４Ａ）、請求先情報に変更がある場合（ステップ４６６Ａの肯定判定）は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４６８Ｃ）、請求先情報を登録し（ステップ４７０Ａ）、ステップ４７２Ａへ移行する。

また、請求先情報に変更がない場合（ステップ４６４Ａの否定判定）は、ステップ４７２Ａへ移行する。

ステップ４７２Ａでは、見積もりの必要性の確認を行い、要否の判定を委ねる（ステップ４７４Ｄ）。

見積もりが不要な場合（ステップ４７４Ｄの否定判定）は、別処理となり、処理継続点Ｒ２に従い移行する（後述する図１１のステップ５５４Ａへ移行）。

一方、見積もりが必要な場合（ステップ４７４Ｄの肯定判定）は、技術情報の確認が必要か否かを判断する（ステップ４７６Ａ）。このステップ４７６Ａには、処理継続点Ｆ２を介して、後述する図１０のステップ５２８Ａから処理が移行される。

ステップ４７６Ａで技術情報の確認が必要であると判断した場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４７８Ｃ）、特別指示の仮指定を実行し（ステップ４８０Ａ）、ステップ４８２Ａへ移行する。ステップ４７６Ａで技術情報の確認が必要ではないと判断した場合は、ステップ４８２Ａへ移行する。

ステップ４８２Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４８４Ｃ）、診断内容を仮報告し、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ４８６Ｃ）、保証自動判定を実施し（ステップ４８８Ａ）、処理継続点Ｄ２に従い移行する（図１０のステップ５０８Ａへ移行）。

（図１０の作業フロー）

図１０は、処理継続点Ｄ２を介して、図９のステップ４９０Ａ又は５０４Ａから処理が移行され、まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５０６Ｃ）、種類ランク自動判定を実行し（ステップ５０８Ａ）、次いで、ランク入力修正の要否を判断する（ステップ５１０Ａ）。

ステップ５１０Ａで必要と判定された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５１２Ｃ）、修理ランクを手入力し、訂正し（ステップ５１４Ａ）、ステップ５１６Ａへ移行する、

また、ステップ５１０Ａで不要と判定された場合は、ステップ５１６Ａへ移行する。

ステップ５１６Ａでは、部品使用の要否を判断する。ステップ５１６Ａで必要と判定された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５１８Ｃ）、使用部品を報告する（ステップ５２０Ａ）。

次いで、ステップ５２２Ａで部品金額に変更があると判断された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５２４Ｃ）、部品金額の変更を通知し（ステップ５２６Ａ）、ステップ５２８Ａへ移行する。

また、ステップ５２２Ａにおいて部品金額に変更がないと判断された場合は、ステップ５２８Ａへ移行する。

ステップ５２８Ａでは、他作業の有無を判断し、他作業が有る場合は、処理継続点Ｆ２に従い移行する（前述した図９のステップ４７６Ａへ移行）。また、他作業の無い場合は、ステップ５３０Ａへ移行する。

ステップ５３０Ａでは、割増報告の有無を判断し、割増報告が有る場合（ステップ５３０Ａの肯定判定）は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５３２Ｃ）、割増報告を実行し（ステップ５３４Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５３６Ｃ）、修理費を自動計算して通知し（ステップ５３８Ａ）、処理継続点Ｅ２に従い移行する（後述する図１１のステップ５４２Ａへ移行）。

また、割増報告が無い場合（ステップ５３０Ａの否定判定）は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５３６Ｃ）、修理費を自動計算して通知し、処理継続点Ｅ２に従い移行する（後述する図１１のステップ５４２Ａへ移行）。

（図１１の作業フロー）

図１１は、処理継続点Ｅ２を介して、図１０のステップ５３８Ａから処理が移行され、まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５４０Ｃ）、修理費見積書の発行を通知し（ステップ５４２Ａ）、次いで、顧客に対して修理費の説明を実行する（ステップ５４４Ａ）。

顧客は、例えば、見積書Ｐ２を見ながら修理費を確認し（ステップ５４６Ｄ）、作業着手を了承するか否かを判断する（ステップ５４８Ｄ）。

ステップ５４８Ｄにおいて、作業着手を了承しない場合（ステップ５４８Ｄの否定判定）は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５５０Ｃ）、修理作業拒否報告を実施し（ステップ５５２Ａ）、処理継続点Ｑ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

また、ステップ５４８Ｄにおいて、作業着手を了承した場合（ステップ５４８Ｄの肯定判定）は、部品使用の有無を判断する（ステップ５５４Ａ）。なお、ステップ５５４Ａには、処理継続点Ｒ２を介して、前述した図９のステップ４５８Ａ又はステップ４７４Ｄから移行する場合がある。

ステップ５５４Ａ以降の作業手順は以下の手順１〜手順４に分類される。

（手順１） ステップ５５４Ａにおいて、部品使用有りと判定され、部品保有が無く、部品当日調達が不可の場合（ステップ５５４Ａの肯定判定→ステップ５５６Ａの否定判定→ステップ５５８Ａの否定判定）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５６０Ｃ）、部品を発注し（ステップ５６２Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５６４Ｃ）、部品納入日を確認し（ステップ５６６Ａ）、顧客に対して、部品納品後の修理となることを説明し（ステップ５６８Ａ）、処理継続点Ａ２に従い移行する（後述する図１８のステップ７８６Ａへ移行）。

（手順２）

ステップ５５４Ａにおいて、部品使用有りと判定され、部品保有が無く、部品当日調達が可能な場合（ステップ５５４Ａの肯定判定→ステップ５５６Ａの否定判定→ステップ５５８Ａの肯定判定）、顧客に対して、部品を本日中に手配する旨を説明し（ステップ５７０Ａ）、修理作業を実行すると共に（ステップ５７２Ａ）、ステップ５７４Ａにおいて、作業が半成と判定された場合は、処理継続点Ａ２に従い移行し（後述する図１８のステップ７８６Ａへ移行）、ステップ５７４Ａにおいて作業が完了と判定された場合は、処理継続点Ｈ２に従い移行する（後述する図１２のステップ５７８Ａへ移行）。

（手順３）

ステップ５５４Ａにおいて、部品使用有りと判定され、部品保有有りと判定された場合（ステップ５５４Ａの肯定判定→ステップ５５６Ａの肯定判定）、修理作業を実行すると共に（ステップ５７２Ａ）、ステップ５７４Ａにおいて作業が半成と判定された場合は、処理継続点Ａ２に従い移行し（後述する図１８のステップ７８６Ａへ移行）、ステップ５７４Ａにおいて作業が完了と判定された場合は、処理継続点Ｈ２に従い移行する（後述する図１２のステップ５７８Ａへ移行）。

（手順４）

ステップ５５４Ａにおいて、部品使用無しと判定された場合（ステップ５５４Ａの否定判定）、修理作業を実行すると共に（ステップ５７２Ａ）、ステップ５７４Ａにおいて作業が半成と判定された場合は、処理継続点Ａ２に従い移行し（後述する図１８のステップ７８６Ａへ移行）、ステップ５７４Ａにおいて作業が完了と判定された場合は、処理継続点Ｈ２に従い移行する（後述する図１２のステップ５７８Ａへ移行）。

（図１２の作業フロー）

図１２は、処理継続点Ｈ２を介して、図１１のステップ５７４Ａから処理が移行され、まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５７６Ｃ）、作業完了状況を報告し（ステップ５７８Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５８０Ｃ）、ＣＯ測定器の結果を報告し（ステップ５８２Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５８４Ｃ）、漏洩検査実施の報告し（ステップ５８６Ａ）、ステップ５８８Ａへ移行する。ステップ５８８Ａには、処理継続点Ｌ２を介して、後述する図１４のステップ６６２Ａから移行する場合がある。

ステップ５８８Ａは、仮登録と同じか否かを判断する。同じ場合（ステップ５８８Ａの肯定判定）、補充部品の発注の有無を判断し（ステップ５９０Ａ）、発注有り（ステップ５９０Ａの肯定判定）の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５９２Ｃ）、補充部品を発注し（ステップ５９４Ａ）、処理継続点Ｍ２に従い移行する（後述する図１５のステップ６７６Ａ）。また、発注無し（ステップ５９０Ａの否定判定）の場合は、処理継続点Ｍ２に従い移行する（後述する図１５のステップ６７６Ａ）。

一方、ステップ５８８Ａで否定判定（仮登録と異なると判定）された場合は、特別指示作業か否かを判断する（ステップ５９６Ａ）。

ステップ５９６Ａで特別指示作業であると判定（肯定判定）された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ５９８Ｃ）、特別指示選択を報告し（ステップ６００Ａ）、ステップ６０２Ａへ移行する。ステップ５９６Ａで特別指示作業ではないと判定（否定判定）された場合は、ステップ６０２Ａへ移行する。

ステップ６０２Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６０４Ｃ）、作業内容を報告し、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６０６Ｃ）、保証自動判定を実行し（ステップ６０８Ａ）、処理継続点Ｊ２に従い移行する（後述する図１３のステップ６１０Ａ）。

（図１３の作業フロー）

図１３は、処理継続点Ｊ２を介して、図１２のステップ６０８Ａから処理が移行され、まず、保証自動判定の結果（図１２のステップ６０８Ａ）において、判定不能又は変更必要か否かを判断する（ステップ６１０Ａ）。

ステップ６１０Ａで、判定が可能であり、変更の必要がないと判断された場合は（ステップ６１０Ａの否定判定）、ステップ６１２Ａへ移行する。

また、ステップ６１０Ａで判定不能又は変更必要と判断された場合（ステップ６１０Ａの肯定判定）は、ステップ６１４Ａ、ステップ６１６Ａ、ステップ６１８Ａ、ステップ６２０Ａ、及びステップ６２２Ａにおいて、以下の処理を実行し、ステップ６１２Ａへ移行する。すなわち、ステップ１４Ａ、ステップ６１６Ａ、ステップ６１８Ａ、ステップ６２０Ａ、及びステップ６２２Ａは、修理ランクを判定できない場合において、既存情報が正しくない可能性があるために行う処理である。

・ステップ６１４Ａ→修理点検履歴確認（修理点検履歴で、修理点検済みか否かを確認する。）
・ステップ６１６Ａ→システム・所有機器情報確認（所有機器情報が間違っていないか確認する。）
・ステップ６１８Ａ→その他情報確認
・ステップ６２０Ａ→保証請求先判断（保証請求先が間違っていないかを確認する。）
・ステップ６２２Ａ→保証自動判定結果訂正（ステップ６２０Ａでの判断結果に基づき、自動判定結果そのものを訂正する必要がある場合に訂正を行う。）

ステップ６１０Ａの否定判定、又はステップ６２２Ａから移行するステップ６１２Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６３４Ｃ）、修理ランクを自動判定し、ランク入力・修正が必要か否かを判断する（ステップ６３６Ａ）。

ステップ６３６Ａにおいて、ランク入力・修理が必要と判定された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６３８Ｃ）、修理ランクを手入力で訂正し（ステップ６４０Ａ）、処理継続点Ｋ２に従い移行する（後述する図１４のステップ６４２Ａ）。

また、ステップ６３０Ａにおいて、ランク入力・修理が不要と判定（否定判定）された場合は、処理継続点Ｋ２に従い移行する（後述する図１４のステップ６４２Ａ）。

（図１４の作業フロー）

図１４は、処理継続点Ｋ２を介して、図１３のステップ６３６Ａ又は６４０Ａから処理が移行され、まず、業務遂行（修理）に際し、部品を使用したか否か（ステップ６４２Ａ）、及び、部品情報を参照したか否かを判断する（ステップ６４４Ａ）。

部品不使用（ステップ６４２Ａの否定判定）の場合は、ステップ６６２Ａへ移行する。

部品使用（ステップ６４２Ａの肯定判定）、かつ部品情報参照しない場合（ステップ６４４Ａの否定判定）は、ステップ６４６Ａへ移行する。

部品使用（ステップ６４２Ａの肯定判定）、かつ部品情報参照する場合（ステップ６４４Ａの肯定判定）は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６４８Ｃ）、部品展開図を参照すると共に（ステップ６５０Ａ）、共通部品を参照し（ステップ６５２Ａ）、ステップ６４６Ａへ移行する。なお、ステップ６５０Ａ及びステップ６５２Ａを総称し、参照ステップ６５４Ａとする。

ステップ６４６Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６４９Ｃ）、使用部品を報告し、ステップ６５０Ａへ移行する。

ステップ６５０Ａでは補充部品を発注したか否かを判断し、ステップ６５０Ａで肯定判定の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６５２Ｃ）、補充部品発注を通知し（ステップ６５４Ａ）、ステップ６５６Ａへ移行する。ステップ６５０Ａで否定判定の場合は、ステップ６５６Ａへ移行する。

ステップ６５６Ａでは、部品金額の変更の要否を判断し、ステップ６５６Ａで肯定判定（必要）の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６５８Ｃ）、部品金額変更を通知し（ステップ６６０Ａ）、ステップ６６２Ａへ移行する。ステップ６５６Ａで否定判定（不要）の場合は、ステップ６６２Ａへ移行する。

ステップ６６２Ａでは、他作業の有無を判断し、肯定判定（他作業有り）の場合は、処理継続点Ｌ２に従い移行する（前述した図１２のステップ５８８Ａへ移行）。

ステップ６６２Ａで否定判定（他作業無し）の場合は、割増し設定の要否を判断する（ステップ６６４Ａ）。

ステップ６６４Ａで肯定判定（割増し設定必要）の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６６６Ｃ）、割増し設定を通知し（ステップ６６８Ａ）、ステップ６７０Ａへ移行する。

ステップ６６４Ａで否定判定（割増し設定不要）の場合は、ステップ６７０Ａへ移行する。

ステップ６７０Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６７２Ｃ）、修理費を計算し、処理継続点Ｍ２に従い移行する（後述する図１５のステップ６７６Ａへ移行）。

（図１５の作業フロー）

図１５は、処理継続点Ｍ２を介して、図１２のステップ５９０Ａ，ステップ５９４Ａ、又は、図１４のステップ６７０Ａから処理が移行され、まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６７４Ｃ）、請求先別金額を確認し（ステップ６７６Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６７８Ｃ）、修理結果のお知らせを発行し（ステップ６８０Ａ）、ステップ６８２Ａへ移行する。

ステップ６８２Ａでは、同一の顧客（お客さま）で他件名の有無を判断する。ステップ６８２Ａで肯定判定された場合は、処理継続点Ｓ２に従い移行する（前述した図８のステップ４１４Ａへ移行）。また、ステップ６８２Ａで否定判定された場合は、顧客に対して修理結果を説明する（ステップ６８４Ａ）。

次のステップ６８６Ｄでは、修理結果のお知らせＰ３を見ながら、顧客が作業結果を確認する。次に、承諾取得を依頼すると（ステップ６８８Ａ）、顧客はサイン了承するか否かを判断する（ステップ６９０Ｄ）。このステップ６９０Ｄで肯定判定された場合は、顧客はサインし（ステップ６９２Ｄ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ６９４Ｃ）、サインが通知され、ステップ７０４Ａへ移行する。

また、ステップ６９０Ｄでサインを了承しない場合は（ステップ６９０Ｄの否定判定）、印鑑了承するか否かを判断する（ステップ６９６Ｄ）。

ステップ６９６Ｄで肯定判定された場合は、顧客に修理結果のお知らせに押印してもらい（ステップ６９８Ｄ）、ステップ７００Ａへ移行する。また、ステップ６９６Ｄで否定判定された場合は、ステップ７００Ａへ移行する。

ステップ７００Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７０２Ｃ）、サイン未取得理由を報告し、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

ステップ７０４Ａでは、顧客（お客さま）への請求の有無を判断し、ある場合（ステップ７０４Ａの肯定判定）は請求先が異名義か否かを判断する（ステップ７０６Ａ）。

ステップ７０４Ａで否定判定（顧客（お客さま）への請求無し）、又はステップ７０６Ａで肯定判定（請求先が異名義である）の場合は、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

また、ステップ７０４Ａで肯定判定（顧客（お客さま）への請求有り）、かつ、ステップ７０６Ａで否定判定（請求先が異名義ではない）の場合は、処理継続点Ｎ２に従い移行する（後述する図１６のステップ７０８Ａへ移行）。

（図１６の作業フロー）

図１６は、処理継続点Ｎ２を介して、図１５のステップ７０６Ａから処理が移行され、まず、顧客に対して請求金額を説明し（ステップ７０８Ａ）、次いで、値引きの有無を判断する（ステップ７１０Ａ）。

ステップ７１０Ａで肯定判定（値引き有り）された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７１２Ｃ）、値引き金額を報告し（ステップ７１４Ａ）、ステップ７１６Ａへ移行する。ステップ７１０Ａで否定判定（値引き無し）された場合は、ステップ７１６Ａへ移行する。

ステップ７１６Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７１８Ｃ）、支払い方法を確認し、次いで、請求書の発行要否を判断する（ステップ７２０Ａ）。

ステップ７２０Ａで肯定判定（請求書発行必要）された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７２２Ｃ）、請求書Ｐ４及び明細書Ｐ５を発行し（ステップ７２４Ａ）、ステップ７２６Ａへ移行する。また、ステップ７２０Ａで否定判定（請求書発行不要）された場合は、ステップ７２６Ａへ移行する。

ステップ７２６Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７２８Ｃ）、支払い方法を報告し、次いで、支払い方法によって処理を振り分ける（ステップ７３０Ａ）。

（支払い方法が現金の場合）

ステップ７３０Ａからステップ７３２Ａへ移行して当日集金か後日集金かを判断する。ステップ７３２Ａで当日集金と判定された場合は、顧客（お客さま）にお支払いをしていただき（ステップ７３４Ｄ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７３６Ｃ）、集金情報を報告し（ステップ７３８Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７４０Ｃ）、領収書Ｐ６を発行し（ステップ７４２Ａ）、ステップ７４６Ａへ移行して、明細書が発行済か否かを判断する。

ステップ７４６Ａにおいて、明細書発行済の場合は、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。また、明細書発行未済の場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７４８Ｃ）、明細書Ｐ７を発行し（ステップ７５０Ａ）、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

一方、ステップ７３２Ａにおいて、後日集金と判定された場合は、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

（支払い方法がクレジットカードの場合）

ステップ７３０Ａからステップ７５２Ａへ移行してカード決済を行い、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７５４Ｃ）、カード決済番号を報告して（ステップ７５６Ａ）、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

（支払い方法が銀行振込の場合）

ステップ７３０Ａからステップ７５８Ａへ移行して振込先を説明し、処理継続点Ｏ２に従い移行する（後述する図１７のステップ７７８Ａへ移行）。

（図１７の作業フロー）

図１７は、処理継続点Ｏ２を介して、図１５のステップ７０４Ａ又はステップ７０６Ａ、或いは、図１６のステップ７４６Ａ、ステップ７５０Ａ、ステップ７３２Ａ、ステップ７５６Ａ、又はステップ７５８Ａから処理が移行され、まず、ステップ７７８Ａにおいて、作業終了報告を実行し、現場作業を完了する（ステップ７８２Ａ）。
なお、ステップ７７８Ａには、図８のステップ４１０Ａ、図１１のステップ５５２Ａ、又は図１８の処理継続点Ｑ２を介して移行する場合がある。

（図１８の作業フロー）

図１８は、処理継続点Ａ２を介して、図１１のステップ５６８Ａ又はステップ５７４Ａから処理が移行され、まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７８４Ｃ）、作業未完了理由を報告し（ステップ７８６Ａ）、次いで、ステップ７８８Ａへ移行して次回希望日を確認し、顧客に対して希望日回答を委ねる（ステップ７９０Ｄ）。

次のステップ７９２Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ７９４Ｃ）、希望日分担状況を確認し、ステップ７９６Ａにおいて、作業予定日が確定したか否かを判断する。

ステップ７９６Ａで肯定判定（作業予定日確定）された場合は、次回作業予定日を確認し（ステップ７９８Ａ）、ステップ８００へ移行する。ステップ７９６で否定判定（作業予定日未確定）された場合は、作業日を追って連絡することを説明し（ステップ８０２Ａ）、ステップ８００Ａへ移行する。

ステップ８００Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８０４Ｃ）、次回の作業予定日を報告し、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８０６Ｃ）、半成メモを報告して（ステップ８０８Ａ）、処理継続点Ｑ２に従い移行する（前述した図１７のステップ７７８Ａへ移行）。

『機器修理の部品発注承認・取消』

図１９及び図２０は、本実施の形態に係る、『業務の分担（部品発注の承認・取消）』の際に、顧客対応端末装置１６、業務遂行担当者が所持する通信端末装置２２、及び顧客管理サーバー１２の間で実行される作業フローである。

（図１９の作業フロー）

図１９は、現場での発注依頼報告に関する作業フローである。

まず、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８１０Ｃ）、発注願の一覧を確認し（ステップ８１２Ａ）、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８１４Ｃ）、発注願がなされている部品を選択し（ステップ８１６Ａ）、在庫を確認する（ステップ８１８Ａ）。

次のステップ８２０Ａでは、イントラネット８２に接続された何れかのサーバーのデータベース（例えば、在庫管理サーバー８６で管理する在庫管理データベース）にアクセスして（ステップ８２２Ａ）、入荷予定部品の確認を行う。ステップ８２０Ａの入荷予定部品の確認後は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８２４Ｃ）、関連する作業件名を確認し（ステップ８２６Ａ）、ステップ８２８Ａへ移行する。

ステップ８２８Ａでは、発注承認の判断を行い、ステップ８３０Ａへ移行して承認の有無を判断する。

ステップ８３０Ａで肯定判定（承認有り）された場合は、ステップ８３２Ａで、発注数量の変更の有無を判断する。

ステップ８３２Ａで発注数量の変更が必要と判定された場合は、ステップ８３４Ａで発注数量を変更し、ステップ８３６Ａへ移行する。また、ステップ８３２Ａで発注数量の変更は不要と判定された場合は、ステップ８３６Ａへ移行する。

ステップ８３６Ａでは、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８３８Ｃ）、承認を報告し、次いで、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８４０Ｃ）、発注書Ｐ８を発行し（ステップ８４２Ａ）、発注完了とする（ステップ８４４Ａ）。

一方、ステップ８３０Ａで否定判定（非承認）された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８４６Ｃ）、作業件名に部品発注非承認を報告し（ステップ８４８Ａ）、次いで、担当者に連絡し（ステップ８５０Ａ）、承認終了とする（ステップ８５２Ａ）。

（図２０の作業フロー）

図２０は、部品発注取消しの必要性に関する作業フローである。

まず、取り消し対象部品情報を確認し（ステップ８５４Ａ）、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８５６Ｃ）、発注承認実施状況を確認し（ステップ８５８Ａ）、ステップ８６０Ａへ移行して、顧客管理サーバー１２で承認済か承認未済かを判断する。

ステップ８６０Ａで承認済と判定された場合は、在庫管理データベース８６ＤＢへアクセスして（ステップ８６２Ｃ）、発注状況を確認し（ステップ８６４Ａ）、取り消しの可否を判断する（ステップ８６６Ａ）。ステップ８６６Ａで取り消し可能と判定された場合は、在庫管理データベース８６ＤＢへアクセスして（ステップ８６８Ｃ）、取り消しの報告を行い（ステップ８７０Ａ）、発注取り消し完了とする（ステップ８７２Ａ）。また、ステップ８６６Ａで取り消し不可能と判定された場合は、発注取り消し不能とする（ステップ８７４Ａ）。

一方、ステップ８６０Ａで承認未済と判定された場合は、イントラネット８２に接続された何れかのサーバーのデータベースへアクセスして（ステップ８７６Ｃ）、非承認を報告し（ステップ８７８Ａ）、発注取り消し完了とする（ステップ８７２Ａ）。

１０ 業務分担システム
１４ 提携店
１６ 顧客対応端末装置（中位制御部）
１６Ａ 受付部
１６Ｂ 業務分担部
１６Ｃ 請求書作成部
２０ ネットワーク
２２ 通信携帯端末(下位制御部）
２０Ａ 無線通信基地
２４ 顧客
２６ 顧客端末
８４ 業務支援管理サーバー(上位制御部）
８４ＤＢ 条件情報データベース
３０ 業務情報出力部
３２ 作成指示部
３４ 受領部
３５ 了承確認部
３６ 業務情報取得部(受付部）
３８ 作成部（取得部）
４０ 条件情報取得部（取得部）
４２ 料金請求先判定部(判定部）
４４ 出力部（認定部）
４６ 業務遂行完了認定部（認定部）
８６ 在庫管理サーバー
８６ＤＢ 在庫情報データベース
（実施例）
８０ ガス管理者
８２ イントラネット
８８ 順路最適化管理サーバー
９０ お客様センター管理サーバー
９１ ルーター
９２ ＰＣ（顧客所有）
９４ 電話回線

Claims (5)

1. 業務遂行担当者の業務遂行後に業務情報を受け付ける受付部と、
   前記受付部で受け付けた前記業務情報の受け付け後に、請求書作成指示があった場合に、遂行された業務に関わる条件情報を取得する取得部と、
   前記取得部で取得した前記条件情報に基づいて、前記業務情報の作業項目毎の料金請求先を自動判定する判定部と、
   前記業務情報の内、顧客に対して、業務遂行にかかった費用に基づく料金を請求する請求項目を抽出した請求書を出力すると共に、出力された請求書に対する前記顧客からの確認応答により、業務遂行の完了を認定する認定部と、
   を有する請求書発行管理制御装置。
2. 業務遂行による結果情報を一括管理する上位制御部と、業務遂行担当者が携帯し得る下位制御部と、複数の前記下位制御部を管理する中位制御部と、を備え、
   前記受付部、前記取得部、前記判定部、及び前記認定部による請求書発行管理制御が、前記上位制御部又は前記中位制御部によって実行されることを特徴とする請求項１記載の請求書発行管理制御装置。
3. 前記中位制御部の各々が、業務遂行に必要な部品の在庫を所有しており、前記上位制御部は、前記中位制御部で所有している部品の在庫情報を集約して一括して管理し、前記中位制御部の各々への在庫補充、及び、前記中位制御部間での在庫の振り分けを実行することを特徴とする請求項２記載の請求書発行管理制御装置。
4. 前記条件情報が、保証判定情報、ガス契約先情報、少なくともメンテナンスを含むサービス加入状況情報、機器情報、修理方法情報、及びリコール・瑕疵情報の少なくとも１つを含むことを特徴とする請求項１〜請求項３の何れか１項記載の請求書発行管理制御装置。
5. コンピュータを、
   請求項１〜請求項４の何れか１項記載の請求書発行管理制御装置の受付部、取得部、判定部、及び認定部として動作させる、
   請求書発行管理制御プログラム。