(57)【要約】【課題】領収書を集中的に管理し、公正な再発行や他の業務系システムとの連動を可能にする。【解決手段】コンピュータとネットワークで結ばれた領収書発行端末より利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信しデータベースに格納するステップと、前記領収書発行端末より利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付けるステップと、前記データベースより前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出するステップと、前記抽出した領収書に関し前記データベースにおける領収書再発行の履歴情報を更新するステップと、領収書再発行の処理を実行すべく前記抽出した領収書の情報を前記領収書発行端末に送信するステップと、を実行する。【選択図】      図５
2004220430.tif 000002
【特許請求の範囲】
【請求項１】
商取引に際して発行される領収書の発行管理をコンピュータにより実行する方法であって、前記コンピュータが、
当該コンピュータとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納するステップと、
前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付けるステップと、
前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出するステップと、
前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新するステップと、
領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信するステップと、
を含むことを特徴とする領収書発行管理方法。
【請求項２】
前記領収書発行端末、その他の端末、および前記コンピュータのインターフェイスのいずれかより、利用者の属性情報または領収書の属性情報を含む領収書発行証明の指定を受け付けるステップと、
前記受け付けた利用者または領収書の属性情報に応じて、前記データベースより対応する該当領収書の情報を抽出するステップと、
領収書発行証明の処理を実行すべく、前記抽出した領収書の情報、または当該情報と前記領収書発行証明の指定に際し受け付けた証明対象の領収書の情報との照合結果を、前記端末またはインターフェイスに送信するステップと、
を含むことを特徴とする請求項１に記載の領収書発行管理方法。
【請求項３】
前記利用者の属性情報または領収書の属性情報に応じて抽出した領収書の情報を、対応する前記領収書発行端末、その他の端末、および当該コンピュータのインターフェイスのいずれかに送信すると共に、処理単位となる領収書群の分類指定を受け付けるステップと、
前記領収書群を構成する領収書に関し、前記データベースにおける分類情報を前記分類指定に応じて更新するステップと、
前記分類指定された領収書群を前記領収書再発行または領収書発行証明の処理対象とするステップと、
を含むことを特徴とする請求項１または２のいずれかに記載の領収書発行管理方法。
【請求項４】
前記領収書群の分類指定を受け付ける処理に代わり、
前記コンピュータが、前記利用者の属性情報または領収書の属性情報に応じて抽出した領収書の情報を、領収書の属性情報と処理単位としてグループ化する属性情報との関係を記述したテーブルに照合し、前記領収書群を分類を実行するステップと、
を含むことを特徴とする請求項３に記載の領収書発行管理方法。
【請求項５】
商取引に際して発行される領収書の発行管理を実行するシステムであって、
前記システムとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納する手段と、
前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付ける手段と、
前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出する手段と、
前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新する手段と、
領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信する手段と、
を含むことを特徴とする領収書発行管理システム。
【請求項６】
商取引に際して発行される領収書の発行管理をコンピュータに実行するさせるためのプログラムであって、
前記コンピュータとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納するステップと、
前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付けるステップと、
前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出するステップと、
前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新するステップと、
領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信するステップと、
を含むことを特徴とする領収書発行管理プログラム。
【請求項７】
請求項６に記載の領収書発行管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項８】
領収書の内容に応じたサービスの可否を判定する領収書の審査システムであって、
商取引に際して発行される領収書の発行管理システムより、領収書の情報もしくは領収書群の情報を審査対象情報として受け付ける手段と、
前記審査対象情報を、領収書の属性に応じたサービス可否を定めた認可テーブルに照合し、サービスの可否を判定する手段と、
前記判定結果を前記発行管理システムまたは当該サービスの申請者が備える端末に送信する手段と、
を備えることを特徴とする領収書審査システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、領収書発行管理方法、システム、プログラム、記録媒体、並びに領収書審査システムに関する。
【０００２】
【従来の技術】
商取引に際しては商品・サービスの購入を行う利用者に対して、商品・サービスの販売者側からレシート等の領収書が発行されるのが一般的である。この領収書には請求内容とそれに対する支払い内容が印字され、前記利用者が後に参照すればどのような商取引を行ったのか認識可能なものである。よって、このような領収書を、企業等における従業員が経費立替の証明書類として利用したり、或いは事業主等が納税処理時の添付書類として利用することとなる。
しかし、当該領収書が紙などの軽便な媒体上に印字されたものであることから、扱いが手軽な反面、紛失しやすく、また偽造もそれほど困難ではなかった。
【０００３】
そこで例えば、レポート（領収書）再発行時に、再発行されたレポートであることを示す情報、および再発行指示した操作者の履歴情報を印字することにより、再発行されたレポートであることを認識することができ、また再発行指示の許可されていない操作者の指示操作履歴を知ることができる販売管理装置を実現するとの目的で、レポート再発行キーが押下されたとき、現在の操作者コードを記憶手段に追加記憶するとともに、該操作者がレポートの再発行を許可されていれば、レポートを再発行するとともに、レポートの再発行を示すロゴテキストおよび前記記憶された操作者コードを印字するレポート再発行機能搭載の販売管理装置が提供されている（特許文献１参照）。
【０００４】
【特許文献１】
特開２００２−２４９４３号公報
【０００５】
【発明が解決しようとする課題】
しかしながら従来手法には改善点が存在した。すなわち、店舗毎に設置される領収書の発行端末がネットワーク上に広範に分布する状況下で、しかも領収書を利用する個人や企業の端末も多岐に亘る場合に対応していない課題である。つまり、発行された領収書の情報を集中管理し、様々なインターフェイスからの再発行や発行証明の要求に応えることが難しかったのである。
【０００６】
また、医療費控除の処理装置など外部装置と連携して領収書情報の授受や各種処理の実行を行うことが想定されていなかった。従って、たとえ領収書の再発行ができるとしても、所定の申告用などに提出すれば他の申請用などに再度使用できない場合も多かった。勿論、外部装置での処理に合わせて領収書の情報の加工や選択を可能とする機能も提供されていなかった。更に、企業や行政、あるいは各個人の求めに応じて領収書の真正性を識別し、領収書の偽造や不正な再発行を抑制する手だても充分ではなかった。
【０００７】
そこで本発明はこのような経緯に基づいてなされたもので、領収書を集中的に管理し、公正な再発行や他の業務系システムとの連動を可能にする領収書発行管理方法、システム、プログラム、記録媒体、ならびに領収書審査システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成する本発明の領収書発行管理方法は、商取引に際して発行される領収書の発行管理をコンピュータにより実行する方法であって、前記コンピュータが、当該コンピュータとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納するステップと、前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付けるステップと、前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出するステップと、前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新するステップと、領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信するステップと、を含むことを特徴とする。
【０００９】
また、商取引に際して発行される領収書の発行管理を実行するシステムであって、前記システムとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納する手段と、前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付ける手段と、前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出する手段と、前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新する手段と、領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信する手段と、を含むことを特徴とする領収書発行管理システムにかかる。
【００１０】
更に、商取引に際して発行される領収書の発行管理をコンピュータに実行するさせるためのプログラムであって、前記コンピュータとネットワークで結ばれた領収書発行端末より、利用者の商取引に際した領収書発行に伴って当該領収書の情報を受信し、データベースに格納するステップと、前記領収書発行端末より、利用者の属性情報または領収書の属性情報を含む領収書再発行の指定を受け付けるステップと、前記データベースより、前記受け付けた利用者または領収書の属性情報に対応する該当領収書の情報を抽出するステップと、前記抽出した領収書に関し、前記データベースにおける領収書再発行の履歴情報を更新するステップと、領収書再発行の処理を実行すべく、前記抽出した領収書の情報を前記領収書発行端末に送信するステップと、を含むことを特徴とする領収書発行管理プログラムにかかる。このプログラムは、前記各ステップの動作を行うためのコードから構成されている。
【００１１】
また、前記領収書発行管理プログラムを記録したコンピュータ読み取り可能な記録媒体にかかる。
【００１２】
更に、領収書の内容に応じたサービスの可否を判定する領収書の審査システムであって、商取引に際して発行される領収書の発行管理システムより、領収書の情報もしくは領収書群の情報を審査対象情報として受け付ける手段と、前記審査対象情報を、領収書の属性に応じたサービス可否を定めた認可テーブルに照合し、サービスの可否を判定する手段と、前記判定結果を前記発行管理システムまたは当該サービスの申請者が備える端末に送信する手段と、を備えることを特徴とする領収書審査システムにかかる。
【００１３】
その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄及び図面により明らかにされる。
【００１４】
【発明の実施の形態】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態における領収書発行管理システムを含むネットワーク構成図である。領収書発行管理システムとしての領収書発行管理サーバ１００（以下、管理サーバ１００）は、本発明の領収書発行管理方法を実現するプログラムを例えばＲＯＭに格納し、前記プログラムに基づいて領収書の発行管理方法を実行する演算装置（図示せず）、ネットワーク１０５と接続してデータ通信を行う通信装置（図示せず）、および発行管理データベース１０２および分類テーブル１０３からなるデータベース群１０１から構成されている。
【００１５】
この管理サーバ１００は、例えば領収書の発行管理を共同で行うとした企業同士で共同運営するか、或いは領収書発行管理サービスを行う企業が備えて管理運営することが想定できる。また、適宜な通信装置によりインターネットやイントラネット、或いは公衆回線網など各種想定可能な前記ネットワーク１０５と接続してそのプロトコルに則ったデータ通信を実行する。当該管理サーバ１００はネットワーク１０５を介して、領収書発行端末１０６、１０８、１１０や、領収書審査システム１２０、１２２、および利用者端末１３０、１３１らとデータ通信し、領収書情報の授受、領収書の再発行や発行証明要求の受付、領収書審査結果等を授受可能とする。
【００１６】
なお、当該管理サーバ１００は、ファイヤウォールサーバとして外部からの不正進入を抑止したり、ＷＷＷサーバとして機能するものでもあるし、データ通信相手とのコミュニケーションを図るメールサーバーとしても機能可能なものとできる。
【００１７】
ここで前記発行管理データベース１０２のデータ構造について説明する。図２は本実施形態における発行管理データベースの構造例である。本データベース１０２は、実際に領収書を発行する領収書発行端末（病院用会計端末１０６や店舗内レジ端末１０８、車載端末１１０など）より、領収書発行に伴って受信した領収書の情報（以下、領収書情報）をレコードとして格納したものである。従って、領収書毎にユニークなレシートＩＤを付してこれをキーとし、以下、当該領収書の発行対象たる利用者に割り当てられた顧客ＩＤ、領収書の属性を示す分類ＩＤ、発行日時、領収書の発行場所や発行端末を特定する発行場所ＩＤ、当該領収書の発行対象が顧客ＩＤ該当者の家族である場合の当該家族を特定するサービス利用者ＩＤおよびそのコメント、商取引されたサービスや商品を特定するサービスメニューＩＤ、数量、単価、レシート再発行情報、および申請情報等が関連付けられている。
【００１８】
前記レシート再発行情報は、当該領収書の再発行がなされた場合の発行番号、発行日時、および発行場所ＩＤの情報から構成される。また、前記申請情報は、領収書審査システム（医療費控除システムサーバ１２０など）における当該領収書に対するサービス認可結果を示す情報である。領収書審査システムが医療費控除システムサーバ１２０であるならば、医療費控除が認可されたか否かが当該申請情報に記録されることとなる。
【００１９】
前記管理サーバ１００は、前記病院用会計端末１０６らの領収書発行端末や前記利用者端末１３０等から分類要求を受けて、領収書の分類処理を受付ける。この分類処理は、領収書再発行または領収書発行証明の処理対象とする領収書をその属性毎に分類する処理を意味する。例えば、領収書の発行日時が近似で発行場所が同じ場合、同じ病院等での診療行為等に起因する領収書として分類することが出来る。また、それに伴う通院時の交通費も同様に同じ分類を行うことができる。
【００２０】
また上記とは異なり、前記管理サーバ１００は、分類テーブル１０３を備えて、領収書の分類を実行することも可能である。図３は本実施形態における分類テーブル１０３の構造例である。前記分類要求を受ける代わりに、管理サーバ１００が月締め或いは期締めといった領収書管理の所定契機をカレンダー機能等で知見するとしてもよい。この場合、その契機毎に領収書情報における利用者の属性情報（例えば前記顧客ＩＤ、サービス利用者ＩＤなど）または領収書の属性情報（例えば前記レシートＩＤ、発行日時、発行場所ＩＤ、サービスメニューＩＤ、数量、単価など）に応じて領収書情報を抽出する。そしてこの領収書情報を、領収書の属性情報と処理単位としてグループ化する属性情報との関係を記述した前記分類テーブル１０３に照合し、処理単位としての領収書群を分類する。
【００２１】
上記のような管理サーバ１００に対し、ネットワーク１０５を通じて領収書情報を適宜なタイミングで送信し、またその後の領収書に対する様々な処理に伴うインターフェイスとなりうるのが領収書発行端末である。本実施形態においては、この領収書発行端末として、病院の会計窓口等に設置される病院用会計端末１０６、その他一般の店舗にそれぞれ設置されている店舗内レジ端末１０８を想定する。これらはそれぞれ領収書を出力するプリンタ１０７、１０９を備える。またタクシーなどのサービス提供車両に搭載される車載端末１１０も想定できる。この場合、タクシーの料金メータと連動し領収書をプリントアウト出来る決済端末となる。
【００２２】
更に、前記管理サーバ１００と連携して領収書の審査を行うのが領収書審査システムである。本実施形態においては、この領収書審査システムとして医療費控除システムサーバ１２０及びその他のサービス提供サーバ１２２を想定する。例えば前記病院用会計端末１０６で発行された領収書を添付資料（電子データの）として、医療費控除の申請がなされた場合、当該申請を受理した官庁等における医療費控除システムサーバ１２０は、この領収書情報を認識する。そして、この領収書情報を認可テーブル１２１に照合し、医療費控除を認めてもよいのか否か判定することとなる。
【００２３】
図４は本実施形態における認可テーブルの構造例である。この図で示した認可テーブル１２１は医療費控除システムサーバ１２０が備えるものである。領収書情報の属性を例えば処方薬、施術、交通手段といった属性（大）と、胃腸薬、コラーゲン、外傷縫合、タクシーといった属性（小）とに分けて、それぞれキーとなし、これに応じた認可の可否を関連付けた構造となっている。また、認可の可否判定の例外条件として考慮すべき例えば特定疾病や処方年齢などの条件も加えられている。
【００２４】
ネットワーク１０５には他に利用者端末１３０や携帯端末１３１も接続されている。これら利用者端末１３０らは、領収書の発行対象となっている利用者が備えるものであり、管理サーバ１００に対して領収書の分類要求や再発行要求、領収書発行証明要求などを発し、またその処理結果を受信する。
【００２５】
なお、前記データベース群１０１を構成する発行管理データベース１０２および分類テーブル１０３は、管理サーバ１００に一体に備わっている例だけでなく、別の装置に付帯しながらもネットワークを介して一体に稼動するとしてもよい。
【００２６】
また、管理サーバ１００、データベース群１０１、領収書発行端末（病院用会計端末１０６など）、領収書審査システム（医療費控除システムサーバ１２０など）、および利用者端末１３０（携帯端末１３１含む）らをそれぞれつなぐネットワークに関しては、専用回線やインターネットの他に、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ、電灯線ネットワーク、無線ネットワーク、公衆回線網、携帯電話網など様々なネットワークを採用することも出来る。また、ＶＰＮなど仮想専用ネットワーク技術を用いれば、インターネットを採用した際にセキュリティ性を高めた通信が確立され好適である。
【００２７】
図５は本実施形態における領収書発行管理方法の処理手順を示すフロー図である。以下、本発明の領収書発行管理方法の実際手順について、会計（領収書発行時）、領収書情報の格納、領収書の分類、領収書の再発行、領収書の発行証明、および領収書審査の各フェーズに分けて説明を行う。そのため、図５に示すフローに加えて、各フェーズを説明する図６以降のフローおよびビジネスモデルを適宜参照することとする。なお、以下で説明する管理サーバ１００の各種の動作は、管理サーバ１００の備えるＲＯＭに格納されたプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００２８】
まず、領収書を発行するに際してはその起因となる商取引が行われている。そして、その商取引の決済に伴って会計処理が行われることとなる。そこでまずは、会計処理に伴う領収書発行について簡単に説明しておく。図６は本実施形態における会計フェーズ例のフロー図であり、図７は本実施形態における会計フェーズ例のビジネスモデルである。
【００２９】
当該会計フェーズが例えば病院で行われるものである場合、該病院での診療行為や治療薬の処方に対して患者（利用者）からその代金が支払われる。この支払い行為を受け付けて処理する病院用会計端末１０６は、管理サーバ１００に対して当該患者に対する請求内容とそれに応じた支払い内容の情報とを送信する（ｓ５００、ｓ６００）。ここで送信される情報としては、既に図２に基づき説明した発行管理データベース１０２のデータ項目に沿った情報となる。
【００３０】
一方、管理サーバ１００ではこの情報を受信して（ｓ５０１、ｓ６０１）、発行管理データベース１０２におけるレコードとして追加・格納する（ｓ５０２）。この時、発行管理データベース１０２において正常な登録処理がなされた否かが病院用会計端末１０６に通知される（ｓ６０２）。病院用会計端末１０６ではこれを受けて、正常処理であるか判定し（ｓ６０３）、判定結果が正常であれば領収書（レシート）を発行する（ｓ５０３、ｓ６０４）。他方、前記判定結果が正常でなかった場合、その旨を出力し（ｓ６０５）、処理を終了する。或いは会計処理を再実行する。
【００３１】
発行される領収書は、例えば図８に示す会計画面例がプリンタ１０７にて出力されたものとなる。ここでは、複数あった受診科名毎に発行される領収書が一体となった領収書の例を示している。いわば、領収書群と認識できる。もちろん、会計対象となる領収書が１つだけであれば、この領収書群は領収書と同意となる。
【００３２】
次に、上述の如く発行管理データベース１０２に格納されていく領収書情報について実行する分類処理について説明する。図９は本実施形態における領収書の分類フェーズ例のビジネスモデルである。分類処理は、領収書再発行または領収書発行証明の処理対象とする領収書をその属性毎に分類する処理を意味する。例えば、発行日時が近似で発行場所が同じ領収書が存在する場合、同じ病院等での診療行為等に起因する領収書として分類し、ひとまとめに扱うことが出来る。また、それに伴う通院時の交通費も同様に同じ分類を行うことができるのである。
【００３３】
そこで、例えば前記病院で領収書の発行を受けた患者が、利用者端末１３０等により、或いは病院用会計端末１０６を介して、自身の顧客ＩＤ（利用者の属性情報）等を管理サーバ１００に送信する（ｓ５０４）。この顧客ＩＤの送信には分類処理の要求が含まれるものとする。
【００３４】
管理サーバ１００ではこれを受信して領収書情報の分類契機を認識する（ｓ５０５）。或いは日締め、期締めといった分類契機の到来をカレンダー機能等で自ら知見する。そして、前記顧客ＩＤなどの利用者の属性情報（または発行日付や発行場所ＩＤなどの領収書の属性情報）に基づいて、発行管理データベース１０２における該当領収書情報の抽出を実行する（ｓ５０６）。前記したように管理サーバ１００自身が分類テーブル１０３を利用して領収書の分類を行う、いわゆる自動分類を実行する場合（ｓ５０７：ＹＥＳ）、前記分類テーブルと前記抽出した領収書情報とを照合して分類し（ｓ５０８）、各領収書情報について分類情報を更新する（ｓ５１３）。
【００３５】
他方、自動分類ではない場合（ｓ５０７：ＮＯ）、前記抽出した領収書情報を利用者端末１３０等に返信する（ｓ５０９）。利用者端末１３０等ではこれを受信し（ｓ５１０）、適宜なインターフェイス上に出力する。そこで前記患者からの分類指定を受け付けて、その結果を管理サーバ１００に送信する（ｓ５１１）。図１０は本実施形態における領収書の分類画面例である。この図１０で示すように、当該画面においては、顧客ＩＤをキーとして未分類の領収書をリスト表示し、それぞれの領収書について分類指定を受付ける入力インターフェイス（例：プルダウンメニューなど）が設けられている。
【００３６】
この画面での分類指定を適正なものとするため、例えば、前記分類テーブル１０３と当該画面の入力や選択動作とを適宜なタイミングで迅速に照合させると好適である。つまり、ひとまとめに分類出来ない領収書について同分類にしようとの前記入力インターフェイスでの操作がなされれば、管理サーバ１００もしくはこれからの指示を受けた病院用会計端末１０６や利用者端末１３０が警告表示を直ちに行って当該操作を無効とすることもできる。
【００３７】
上記の如く分類指定を受け付けた利用者端末１３０等から送信された指定結果は管理サーバ１００にて受信される（ｓ５１２）。この受信された分類指定の結果は、発行管理データベース１０２における該当領収書情報の分類情報に反映されることとなる（ｓ５１３）。
【００３８】
発行された領収書の領収書情報は、前記のような分類処理を経て例えば医療費控除の申請データとして利用されることが想定される。本実施形態においては管理サーバ１００とネットワークで結ばれた領収書審査システムとしての医療費控除システムサーバ１２０を想定し、該管理サーバ１００と連携可能としている。
【００３９】
所定のタイミングで医療費控除システムサーバ１２０から医療費控除の申請受け付け開始が管理サーバ１００に通知されたとする。或いは、管理サーバ１００か利用者端末１３０から医療費控除の申請が医療費控除システムサーバ１２０に対してなされたとする。いずれにしても医療費控除に関する領収書の審査処理の開始契機となる。
【００４０】
以下に医療費控除に関する領収書の審査処理について説明する。図１１は本実施形態における医療費控除システムとの連携フェーズ例のビジネスモデルであり、図１２は本実施形態における連携フェーズ例のフロー図である。
【００４１】
前述したように、例えば医療費控除システムサーバ１２０が医療費控除の申請受け付けを開始する旨を管理サーバ１００に通知すると（ｓ１２００）、管理サーバ１００ではこれを認識する。そして、申請対象（審査対象情報）となりうる利用者または領収書の属性（例：発行日時など）に該当する領収書（レシート）の領収書情報を発行管理データベース１０２から抽出する（ｓ１２０１）。
抽出した領収書情報については顧客ＩＤの昇順で並べ替えを実行する。また、処理中顧客ＩＤとして最小の顧客ＩＤを設定する（ｓ１２０２）。この処理中顧客ＩＤの領収書情報を抽出して医療費控除システムサーバ１２０に送信する（ｓ１２０３）。
医療費控除システムサーバ１２０ではこれを受信し、審査処理を実行する（ｓ１２０４）。審査結果については管理サーバ１００に返信する（ｓ１２０５）。
【００４２】
管理サーバ１００では、領収書情報の抽出と送信の前記処理を前記処理中顧客ＩＤの全てについて繰り返し行うよう判定を行い（ｓ１２０６、ｓ１２０７）、医療費控除の申請をバッチ処理する。
医療費控除システムサーバ１２０では前記審査処理をどのように行うのか説明する。図１３は本実施形態における領収書の審査過程を示すフロー図である。医療費控除システムサーバ１２０は、審査対象情報としての領収書情報（未分類のものと分類処理済みのものどちらも想定可能）を受信する（ｓ５５０）。
受信した領収書情報は、前記認可テーブル１２１と照合し（ｓ５５１、ｓ１３００）、その一致を判定する（ｓ１３０１）。また既に図４で示したような例外事項についても考慮を行い（ｓ５５２、ｓ１３０２）、最終判定を下す（ｓ５５３、ｓ１３０３）。
【００４３】
最終判定の結果は管理サーバ１００に通知される（ｓ５５４、ｓ１３０４）。そして管理サーバ１００は、この結果を、発行管理データベース１０２における該当領収書情の申請情報として記録する（ｓ１３０８）。前記判定結果が医療費控除不認可であった場合には、その情報を管理サーバ１００または利用者端末１３０に送信する（ｓ１３０５）。利用者端末１３０ではこれを受けて（ｓ５１４）適宜なインターフェイスに出力し（ｓ１３０６）、前記患者に通知を行う。
【００４４】
図１４は本実施形態における拒否リスト画面例である。医療費控除不認可となった領収書については、これを例えば拒否リストとして表示させる。この図１４ではこの拒否リストの例を示している。認可が拒否される領収書としては、例えば、医療行為とは認められない行為に対する領収書であったり、あるいは医療行為を受けるに必要な交通費とは認めがたい交通費の領収書であったりする。ただし、このような拒否された領収書についても前記患者が利用者端末１３０を通じて不服を申し立てるとしてもよい（ｓ１３０７）。この場合、例えば前記拒否リストにおける該当領収書についてクリック動作をすれば不服申立用の画面やメーラーの定型フォーム等が管理サーバ１００または医療費控除システムサーバ１２０から提供されることが想定できる。
【００４５】
従来、病院で一度発行された領収書を上記のような医療費控除申請に使用した場合、返還されることがなく、他の用途に使用することができなかった。そこで、本発明においては領収書の再発行を可能にする。図１５は本実施形態における領収書再発行フェーズ例のフロー図であり、図１６は本実施形態における領収書再発行フェーズ例のビジネスモデルである。
【００４６】
病院用会計端末１０６や利用者端末１３０を通じて、再発行を望む前記患者から領収書再発行要求が、管理サーバ１００に通知されるとする（ｓ５１５、ｓ１５００、ｓ１５０１）。なお、この要求には当該患者の顧客ＩＤや再発行を望む領収書の属性情報が含まれるとする。
【００４７】
管理サーバ１００ではこの要求を受信してそれに含まれる利用者属性や領収書属性を認識する（ｓ５１６、ｓ５１７）。そして認識したこの属性に応じて発行管理データベース１０２から該当する領収書情報を抽出する（ｓ５１８）。抽出した領収書情報が１つである場合など、前記患者の選択を受付ける必要がなければ、該当領収書について発行管理データベース１０２におけるレシート再発行情報（履歴）を更新し（ｓ５１９）、病院用会計端末１０６等に送信する（ｓ５２０）。
【００４８】
他方、前記抽出した領収書情報が複数あるなど前記患者の選択を受け付けるべき状況であれば、この領収書情報を病院用会計端末１０６等に送信する（ｓ１５０３）。病院用会計端末１０６等ではこれを受信して適宜なインターフェイスに出力する（ｓ１５０４）。そこで前記患者から選択を受け付けた領収書についてそのレシートＩＤを管理サーバ１００に返す（ｓ１５０５）。
管理サーバ１００ではこれを受信し、該当する領収書情報を発行管理データベース１０２から抽出して病院用会計端末１０６等に返信する（ｓ１５０６）。
病院用会計端末１０６等では、管理サーバ１００から領収書情報を受信し（ｓ５２１）、これをプリンタ１０７等で出力処理し領収書の再発行を完了する（ｓ５２２、ｓ１５０７）。
【００４９】
企業等においては、従業員から精算を求められた領収書が真正なものなのか認証する状況も想定できる。このような状況に対応する本発明においては、領収書発行証明の処理を可能にしている。図１７は本実施形態における領収書発行証明フェーズのフロー図であり、図１８は本実施形態における領収書発行証明フェーズのビジネスモデルである。
【００５０】
病院用会計端末１０６や利用者端末１３０などの端末（図中ではレシート情報確認用端末）を通じて、領収書の発行証明を望む前記患者もしくはこれの雇用主から領収書発行証明要求が、管理サーバ１００に通知されるとする（ｓ５２３、ｓ１７００）。なお、この要求には当該患者の顧客ＩＤや発行証明を望む領収書の属性情報が含まれるとする。
【００５１】
管理サーバ１００ではこの要求を受信してそれに含まれる利用者属性や領収書属性を認識する（ｓ５２４、ｓ５２５）。そして認識したこの属性に応じて発行管理データベース１０２から該当する領収書情報を抽出する（ｓ５２６）。抽出した領収書情報は、証明対象となる領収書情報を前記患者等から予め受信していない場合（ｓ５２７：ＮＯ）、病院用会計端末１０６等に送信する（ｓ５２８）。
【００５２】
病院用会計端末１０６等ではこれを受信して（ｓ５２９）、証明対象となる前記患者申告の領収書内容と照合する（ｓ５３０、ｓ１７０２、ｓ１７０３）。そして、この照合判定の一致あるいは不一致である旨を（ｓ１７０４、ｓ１７０５）適宜なインターフェイスに出力し処理は完了する（ｓ５３４）。或いは、管理サーバ１００が前記患者が申告した領収書内容の情報を受信済みであったならば（ｓ５２７：ＹＥＳ）、上記の照合処理を管理サーバ１００にて実行し（ｓ５３１）、その照合結果を病院用会計端末１０６らに通知する（ｓ５３２）。病院用会計端末１０６ではこの照合結果を受信し（ｓ５３３）、出力処理する（ｓ５３４）。
【００５３】
本発明の実施の形態によれば、次の効果を奏する。
本発明の領収書発行管理方法等によれば、店舗毎に設置される領収書の発行端末がネットワーク上に広範に分布する状況下で、しかも領収書を利用する個人や企業の端末も多岐に亘る場合にも対応可能となる。従って、発行された領収書の情報を集中管理し、様々なインターフェイスからの再発行や発行証明の要求に応えることが容易となるのである。
【００５４】
また、医療費控除の処理装置など外部装置と連携して領収書情報の授受や各種処理の実行を行うことが可能で、外部装置での処理に合わせて領収書の情報の加工や選択を可能とする機能も提供できる。更に、企業や行政、あるいは各個人の求めに応じて領収書の真正性を識別し、領収書の偽造や不正な再発行を抑制できることとなる。
つまり、領収書を集中的に管理し、公正な再発行や他の業務系システムとの連動を可能にするのである。
【００５５】
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００５６】
【発明の効果】
本発明によれば、領収書を集中的に管理し、公正な再発行や他の業務系システムとの連動を可能にする。
【図面の簡単な説明】
【図１】本実施形態における領収書発行管理システムを含むネットワーク構成図である。
【図２】本実施形態における発行管理データベースの構造例である。
【図３】本実施形態における分類テーブルの構造例である。
【図４】本実施形態における認可テーブルの構造例である。
【図５】本実施形態における領収書発行管理方法の処理手順を示すフロー図である。
【図６】本実施形態における会計フェーズ例のフロー図である。
【図７】本実施形態における会計フェーズ例のビジネスモデルである。
【図８】本実施形態における会計画面例である。
【図９】本実施形態における領収書の分類フェーズ例のビジネスモデルである。
【図１０】本実施形態における領収書の分類画面例である。
【図１１】本実施形態における医療費控除システムとの連携フェーズ例のビジネスモデルである。
【図１２】本実施形態における連携フェーズ例のフロー図である。
【図１３】本実施形態における領収書の審査過程を示すフロー図である。
【図１４】本実施形態における拒否リスト画面例である。
【図１５】本実施形態における領収書再発行フェーズ例のフロー図である。
【図１６】本実施形態における領収書再発行フェーズ例のビジネスモデルである。
【図１７】本実施形態における領収書発行証明フェーズのフロー図である。
【図１８】本実施形態における領収書発行証明フェーズのビジネスモデルである。
【符号の説明】
１００  領収書発行管理システム、領収書発行管理サーバ、管理サーバ
１０１  データベース群
１０２  発行管理データベース、データベース
１０３  分類テーブル
１０５  ネットワーク
１０６  病院用会計端末、領収書発行端末
１０７、１０９  プリンタ
１０８  店舗内レジ端末、領収書発行端末
１１０  車載端末、領収書発行端末
１２０  医療費控除システムサーバ、領収書審査システム
１２１  認可テーブル
１３０  利用者端末
１３１  携帯端末
【図１】
2004220430.tif 000003
【図２】
2004220430.tif 000004
【図３】
2004220430.tif 000005
【図４】
2004220430.tif 000006
【図５】
2004220430.tif 000007
【図６】
2004220430.tif 000008
【図７】
2004220430.tif 000009
【図８】
2004220430.tif 000010
【図９】
2004220430.tif 000011
【図１０】
2004220430.tif 000012
【図１１】
2004220430.tif 000013
【図１２】
2004220430.tif 000014
【図１３】
2004220430.tif 000015
【図１４】
2004220430.tif 000016
【図１５】
2004220430.tif 000017
【図１６】
2004220430.tif 000018
【図１７】
2004220430.tif 000019
【図１８】
2004220430.tif 000020