JP2018092568A - 発注処理装置および発注処理方法 - Google Patents

Abstract

【課題】チケット利用会社のタクシーチケットの発注状況を管理するための事務作業の負担を軽減することができる発注処理装置を提供する。【解決手段】発注処理装置１は、複数の通信端末１１、１２を有するチケット利用会社１０１からのタクシーチケットの発注を処理する発注処理装置であって、チケット利用会社１０１の通信端末１１、１２からタクシーチケットの発注を受け付ける発注受付部１ａと、発注受付部１ａが受け付けた発注の履歴が記録された発注履歴データベース１ｃと、チケット利用会社１０１からの発注履歴の照会要求に応じて、発注履歴データベース１ｃを参照して、チケット利用会社１０１の複数の通信端末１１，１２からの発注の履歴データを取得し、当該履歴データをチケット利用会社１０１に送信する照会処理部１ｄと、を備える。【選択図】図１

Description

本発明は、タクシーチケットの発注を処理する発注処理装置、発注処理方法、発注処理プログラムおよび記録媒体に関する。

従来から、タクシーチケットがタクシー料金の支払いに用いられている。タクシーチケットは、タクシーを利用した際にタクシー料金の支払いを現金で行う必要がなく便利である。そのため、例えば製薬会社などでは、医師などの医療関係者を対象とした催事や講演会などを開催することが多く、その際に、医療関係者に講演会などへの参加を促すために、会場までの交通手段としてタクシーチケットを渡すことが慣例で行われている。しかし、タクシーチケットの使用に制限がないと、講演会参加以外の目的でタクシーチケットが使用されるおそれがある。そのため、乗車指定日や利用限度額などの情報をタクシーチケットに印字したうえで、利用者に配布することで、講演会参加以外の目的での使用を抑制する措置が通常行われている。

このようなタクシーチケットに関しては、タクシーチケットの発行及び管理などの各種処理を行うための装置及びシステムに関する様々な技術が提案されている（例えば、特許文献１〜２）。図２６は、従来の典型的なタクシーチケット処理システムの全体構成を示すブロック図である。このタクシーチケット処理システムは、チケット発行会社１００が有する発行処理装置１１０と、チケット利用会社１０１（会員）が有する発注管理端末１１１及び社員端末１１２と、を備えている。チケット利用会社１０１が例えば製薬企業であるとすると、発注管理端末１１１は、社内のタクシーチケットの発注状況を管理する発注責任者が使用する端末であり、社員端末１１２は、医薬情報担当者（以下、ＭＲ）が使用する端末である。また、発行処理装置１１０は、発注受付部１１０ａ、発注データ記憶部１１０ｂ及び発行処理部１１０ｃを備えている。

図２６において、チケット利用会社１０１のＭＲがタクシーチケットを必要とする場合、社員端末１１２を用いて発注管理端末１１１にタクシーチケットの発注依頼を行う。発注依頼は、例えば、ＭＲがタクシーチケットに印字したい情報を示すエクセルデータを作成し、そのデータを社員端末１１２から発注管理端末１１１に送信する。発注責任者は、発注管理端末１１１を用いて、社員端末１１２から受信したデータを、所定のフォーマットの発注データに加工して、チケット発行会社１００に送信する。送信された発注データは、発行処理装置１１０の発注受付部１１０ａによって受け付けられ、発注データ記憶部１１０ｂに格納される。その後、発行処理部１１０ｃが発注データ記憶部１１０ｂに格納された発注データに基づいて、タクシーチケットに印字される情報を含むチケットデータを生成する。当該情報が所定の用紙に印字されることにより、タクシーチケットが発行される。

発行されたタクシーチケットは、チケット利用会社１０１に郵送され、チケット利用者１０２に配布される。チケット利用者１０２はタクシー１０３を利用した場合に、タクシーチケットを使用してタクシー料金の仮払いを行う。使用されたタクシーチケットは、タクシー会社１０４により回収され、タクシー会社１０４はタクシー料金を集計して、チケット発行会社１００に請求する。チケット発行会社１００は、チケット利用会社１０１に代わってタクシー料金をタクシー会社１０４に支払い、その後、支払ったタクシー料金をチケット利用会社１０１に請求している。

特開２００３−２９６７６７号公報 特開２００７−１８３０４号公報

図２６に示す従来のタクシーチケット処理システムでは、発注管理端末１１１を操作する発注責任者は、社内全体のチケット発注状況をＭＲごとに把握するために、各社員端末１１２からの発注依頼及びチケット発行会社１００への発注状況に基づいて、発注管理データベース１１１ａを作成する必要があった。そのため、タクシーチケットの発注責任者の事務作業の負担が大きいという問題があった。

本発明は、上記問題を解決するためになされたものであって、チケット利用会社のタクシーチケットの発注状況を管理するための事務作業の負担を軽減することができる発注処理装置を提供することを課題とする。

上記課題を解決するために、本発明に係る発注処理装置は、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理装置であって、前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付部と、前記発注受付部が受け付けた発注の履歴が記録された発注履歴データベースと、前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理部と、を備えることを特徴とする。

本発明に係る発注処理装置では、前記照会処理部は、前記複数の通信端末のうち、少なくとも特定の端末からの照会要求を受け付けることが好ましい。

本発明に係る発注処理装置では、前記特定の端末は、前記チケット利用会社のタクシーチケットの発注状況を管理する発注責任者が使用する端末であることが好ましい。

本発明に係る発注処理装置では、前記照会処理部が前記発注履歴データベースを参照するための参照条件を受け付ける参照条件受付部をさらに備え、前記照会処理部は、前記参照条件受付部が受け付けた前記参照条件に従って取得した履歴データを前記チケット利用会社に送信することが好ましい。

本発明に係る発注処理方法は、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法であって、前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、を備えることを特徴とする。

本発明に係る発注処理プログラムは、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法をコンピュータに実行させる発注処理プログラムであって、前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、をコンピュータに実行させる。

本発明に係る記録媒体は、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法をコンピュータに実行させる発注処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記発注処理プログラムは、前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、をコンピュータに実行させる記録媒体である。

本発明に係る発注処理装置によれば、タクシーチケットの発注責任者の事務作業の負担を軽減することができる。

本発明の一実施形態に係るタクシーチケット発行システムのブロック図である。 発注の履歴データの一例を示す。 ログイン画面の一例を示す。 発注者情報入力画面の一例を示す。 発注内容入力画面の一例を示す。 発注内容確認画面の一例を示す。 発注完了画面の一例を示す。 シートの平面図である。 タクシーチケットの平面図である。 発行装置及びその周辺機器の斜視図である。 発行装置のブロック図である。 チケット発行情報の一例を示す。 管理装置及びその周辺機器の斜視図である。 管理装置のブロック図である。 使用済チケット情報の一例を示す。 チケット利用情報の一例を示す。 未回収チケット情報の一例を示す。 目的外使用チケット情報の一例を示す。 チケット発行会社からチケット利用会社に提供されるチケット利用状況情報の一例を示す。 本発明の一変形例に係るタクシーチケット処理システムの一部を示すブロック図である。 検索条件指定画面の一例を示す。 検索条件が入力された検索条件指定画面の一例を示す。 検索条件に従って絞り込まれた履歴データの一例を示す。 本発明の他の変形例に係るタクシーチケット処理システムの一部を示すブロック図である。 会員情報の一例を示す。 従来のタクシーチケット発行システムのブロック図である。

以下、本発明の一実施形態について添付図面を参照して説明する。図１は、本実施形態に係るタクシーチケット処理システム１０のブロック図である。タクシーチケット処理システム１０は、チケット発行会社１００がチケット利用会社１０１にタクシーチケットの発行及びチケット代金の精算を行うためのシステムであり、チケット発行会社１００が有する発注処理装置１、発行装置２及び管理装置４と、チケット利用会社１０１が有する複数の通信端末、すなわち、発注管理端末１１及び社員端末１２と、を備えている。

本実施形態では、チケット利用会社１０１は製薬企業であるとする。なお、本明細書において、「会社」とは、法上の会社（株式会社、合同会社、合名会社及び合資会社）に限らず、社団法人、財団法人などの法人格を有する団体、及び、組合、学会など法人格を有しない団体をも含む概念である。

チケット発行会社１００が発行したタクシーチケットは、チケット利用会社１０１に郵送等の手段により送付され、医療関係者等のチケット利用者１０２に配布される。チケット利用者１０２はタクシーに乗車した際に、タクシーチケットに運賃等を記入して乗務員に手渡す。その後、使用済みのタクシーチケットは乗務員からタクシー会社１０４に回収され、タクシー会社１０４は、使用済みのタクシーチケットをチケット発行会社１００に送付する。チケット発行会社１００は、使用済みのタクシーチケットに基づいてチケット利用会社１０１に発行したチケットの利用額の集計を行い、定期的にチケット利用会社１０１に請求を行う。

なお、図１において、実線枠のブロックは、コンピュータ又はコンピュータが有する機能を表すブロックであり、破線枠のブロックは、個人又は企業を表すブロックである。また、実線の矢印は、電子データの流れを表しており、破線の矢印は、有体物であるタクシーチケットの流れを表している。

発注管理端末１１及び社員端末１２と発注処理装置１とは、インターネットなどの通信ネットワークを介して通信可能となっている。

発注管理端末１１は、社内のタクシーチケットの発注状況を管理する発注責任者が使用する端末であり、特許請求の範囲に記載の「特定の端末」に対応する。社員端末１２は、発注責任者以外の一般社員が使用する端末であり、本実施形態では、医薬情報担当者（以下、ＭＲ）が使用する端末である。

発注管理端末１１及び社員端末１２の台数は特に限定されないが、通常、発注管理端末１１は社内に１台設けられ、社員端末１２は社内に複数台設けられる。発注管理端末１１及び社員端末１２は、通信機能を有するコンピュータであれば特に限定されず、汎用のパーソナルコンピュータであってもよいし、スマートフォン等の携帯型の端末であってもよい。なお、本明細書において、「チケット利用会社１０１が有する通信端末」とは、チケット利用会社１０１が利用可能な通信端末であればよく、例えば、リース契約によってチケット利用会社１０１に貸与された通信端末であってもよい。

発注処理装置１は、チケット利用会社１０１からのタクシーチケットの発注を処理する装置である。発注処理装置１は、ハードウェア構成として、図示しないＣＰＵ、メモリ及び補助記憶装置（ＨＤＤ）などを備えている。ＨＤＤは、コンピュータ内に含まれていてもよいし、コンピュータの外部装置として置かれてもよく、また、コンピュータがＨＤＤを含んだうえでさらに外部に別のＨＤＤを有していてもよい。

本実施形態では、発注処理装置１は、クラウド上のサーバとして設けられが、発注処理装置１の設置形態は特に限定されない。例えば、発注処理装置１を他の装置（発行装置２及び／又は管理装置４）と一体的に構成してもよい。また、発注処理装置１、発行装置２及び管理装置４は、チケット発行会社１００が利用可能な装置であればよく、必ずしもチケット発行会社１００が所有権を有している装置でなくてもよい。

図２６に示す従来のタクシーチケット処理システムとは異なり、本実施形態に係るタクシーチケット処理システム１０では、チケット利用会社１０１のＭＲは、各社員端末１２から発注処理装置１に対し、直接タクシーチケットの発注を行うことが可能となっている。本実施形態では、発注責任者が所定のユーザＩＤ及びパスワードＰＷをＭＲに通知しておき、ＭＲがタクシーチケットの発注を行う際に、発注処理装置１から提供されるログイン画面にユーザＩＤ及びパスワードＰＷを入力することで、タクシーチケットの発注が可能となる。なお、ユーザＩＤ及びパスワードＰＷは、あらかじめ発注責任者がチケット発行会社１００から取得したものであり、これらは社員端末１２ごとに異なってもよいし、同じであってもよい。また、発注管理端末１１からもタクシーチケットの発注は可能である。

発注処理装置１は、発注受付部１ａ、認証情報データベース１ｂ、発注履歴データベース１ｃ及び照会処理部１ｄを備えている。発注受付部１ａ及び照会処理部１ｄは、発注処理装置１の図示しないＣＰＵが本発明に係る発注処理プログラムを実行することにより実現される機能ブロックである。発注処理プログラムは、発注処理装置１の図示しないＨＤＤに記憶されており、当該プログラムを記録したコンピュータ読み取り可能な記録媒体（フラッシュメモリ、ＳＤカード、ＣＤ−ＲＯＭなど）を介して発注処理装置１に供給されてもよいし、インターネットなどの通信ネットワークを介して発注処理装置１に供給されてもよい。また、発注処理装置１の機能ブロックの少なくとも一部を、集積回路などのハードウェアによって実現してもよい。

発注受付部１ａは、チケット利用会社１０１の通信端末（発注管理端末１１及び社員端末１２）からのタクシーチケットの発注を受け付ける機能ブロックである。また、認証情報データベース１ｂには、あらかじめチケット利用会社１０１に通知したユーザＩＤ及びパスワードＰＷが登録されている。発注受付部１ａが社員端末１２からタクシーチケットの発注要求を受信すると、発注を受け付けるための所定の画面を社員端末１２に表示する。社員端末１２に表示される画面の詳細については、後述する。

発注受付部１ａが受け付けた発注の内容は、発注履歴データベース１ｃに転送される。発注履歴データベース１ｃには、所定期間（例えば、過去６ヶ月間）におけるチケット利用会社１０１からの発注の履歴が記録されている。図２は、発注の履歴データの一例である。

照会処理部１ｄは、チケット利用会社１０１からの発注履歴の照会要求に応じて、チケット利用会社１０１の発注の履歴データをチケット利用会社１０１に送信する。本実施形態では、発注履歴の照会要求は、発注管理端末１１の発注履歴照会部１１ａから送信される。照会処理部１ｄは、当該照会要求を受け付けると、発注履歴データベース１ｃを参照して、チケット利用会社１０１の全ての通信端末（すなわち、発注管理端末１１及び全ての社員端末１２）からの発注の履歴データを取得し、当該履歴データを発注履歴照会部１１ａに送信する。送信された履歴データは、発注管理端末１１に表示される。

これにより、チケット利用会社１０１において、発注管理端末１１を操作する発注責任者は、図２６に示す発注管理データベース１１１ａを自ら作成することなく、社内全体のチケット発注状況をＭＲごとに把握することができる。よって、チケット利用会社１０１のタクシーチケットの発注状況を管理するための事務作業の負担を軽減することができる。

照会処理部１ｄは、少なくとも発注管理端末１１からの照会要求を受け付けることが好ましく、本実施形態において照会処理部１ｄは、発注管理端末１１からの照会要求のみを受け付けている。このような照会要求の制限は、照会処理部１ｄが照会要求を受信したときに、ＩＤやパスワードの入力を要求すること等によって実現できる。

なお、照会処理部１ｄは、発注管理端末１１以外の端末からの照会要求を受け付けてもよく、例えば、ＭＲを統括する営業拠点担当者の端末からの照会要求を受け付けるようにしてもよい。また、ＭＲが使用する社員端末１２は、タクシーチケットの発注は可能である一方、発注履歴の照会は不可としてもよい。このように、営業担当、営業拠点担当および発注管理担当の各部門について異なる権限を設定することにより、各部門の役割に応じて適正な操作を行わせることができる。

また、発注履歴の照会要求は、発注履歴データベース１ｃに記録されているチケット利用会社１０１の全発注履歴を指定するものであってもよいし、所望の期間（例えば、２０１６年６月１日〜２０１６年６月３０日のみ）における発注履歴を指定するものであってもよい。発注履歴を絞り込む態様については、後述する。また、チケット利用会社１０１に送信する履歴データに含まれる発注受付日、発注者名等の情報は、図２に示すものに限定されず、チケット利用会社１０１の発注責任者が社内のチケット発注状況の把握に必要な情報を含むものであればよい。

続いて、チケット発注の受付処理の一例について具体的に説明する。

ＭＲがタクシーチケットを発注する場合、例えば、社員端末１２を用いてウェブ上のチケット発行会社１００の発注用ＵＲＬにアクセスする。これにより、社員端末１２から発注受付部１ａに、タクシーチケットの発注の要求が送信され、発注受付部１ａは、図３に示すログイン画面を社員端末１２に表示させる。ログイン画面には、ユーザＩＤ及びパスワードの各入力欄が設けられている。ＭＲが、発注責任者から通知されたユーザＩＤ及びパスワードを入力して、ログインボタン１３１を選択すると、発注受付部１ａは、認証情報データベース１ｂを参照して、入力されたユーザＩＤ及びパスワードＰＷが正しいか判定する。

ユーザＩＤ及びパスワードＰＷが正しい場合、発注受付部１ａは、図４に示す発注者情報入力画面を社員端末１２に表示させる。発注者情報入力画面には、発注者及び配布責任者の社員コード、ならびに配布枚数の入力欄が設けられている。なお、発注者と配布責任者が同一である場合、配布責任者の社員コードの入力は省略可能である。また、社員コードの代わりに、氏名を入力可能としてもよい。

さらに、発注者情報入力画面では、発注者にあらかじめ発注したタクシーチケットが発送及び到着する予定日に関する情報が表示されている。これにより、発注者は、タクシーチケットの到着予定日が把握できるため、使用期限が到着予定日前であるタクシーチケットを発注するといったミスを防ぐことができる。また、チケット発行会社１００への電話やメールなどによるチケット到着予定日の問合せを低減させることができる。

なお、図４では、チケットの発送予定日および到着予定日をそれぞれ「注文受付日の翌営業日」、「注文受付日の翌々営業日」と表示しているが、具体的な日付を表示してもよい。特に、ユーザにとって重要な到着予定日については、文字サイズを大きくするなど、強調して表示することが好ましい。

ＭＲが発注者情報入力画面における社員コード等の入力を完了して、「発注内容の入力へ進む」ボタン１３２を選択すると、発注受付部１ａは、図５に示す発注内容入力画面を社員端末１２に表示させる。発注内容入力画面には、使用者が参加予定の会合企画を示す情報、タクシーチケットの限度額、乗車指定日、施設名及び利用者名の各入力欄、ならびに印字可否を選択するトグルボタンが設けられている。会合企画は、会合企画を示す番号を入力してもよいし、企画の名称を入力可能としてもよい。限度額の入力は、ドロップダウンリストによって複数の金額（例えば、３千、５千、８千、１万、３万など）を表示させて選択することによって行ってもよいし、任意の金額を直接入力可能としてもよい。乗車指定日は、カレンダーを表示させて所望の年月日を選択させてもよいし、年月日を直接入力可能としてもよい。乗車指定日については、タクシーチケットの到着予定日より前の日を指定できないようにすることが望ましい。

ＭＲが各入力欄に情報を入力して、「発注内容を確認する」ボタン１３３を選択すると、発注受付部１ａは、図６に示す発注内容確認画面を社員端末１２に表示させる。発注内容確認画面には、図４及び図５に示す各入力画面に入力された情報が表示される。

ＭＲが発注内容確認画面の「発注を確定する」ボタン１３４を選択すると、発注受付部１ａは、図７に示す発注完了画面を社員端末１２に表示させ、発注の受付が完了したことをＭＲに通知する。なお、図３〜図７に示す各画面は汎用のウェブブラウザによって表示されてもよいし、専用のアプリケーション画面に表示されてもよい。

以上のように発注受付部１ａは、社員端末１２からタクシーチケットの発注を受け付ける。発注受付部１ａが受け付けた発注データは、発注履歴データベース１ｃに記録されるとともに、定期的に発行装置２に取り込まれる。発行装置２では、発注データに基づき、汎用のプリンタ（印刷装置３）を用いて、図８に示すようなタクシーチケットの用紙１３が横２枚×縦４枚に連ねられた印字用シート１４に各種情報が印字される。これにより、図９に示すようなタクシーチケット１５が発行される。

なお、ＭＲによる発注の受付が完了した場合であっても、ＭＲの上長の承認を条件にタクシーチケットを発行するようにしてもよい。例えば、ＭＲの上長がタクシーチケットの発注責任者である場合、ＭＲが図６に示す発注内容確認画面の「発注を確定する」ボタン１３４を選択した後、発注責任者が使用する発注管理端末１１に、ＭＲからタクシーチケットの発注を受け付けた旨をメールで通知する。当該メールには、発注を承認するか否かを選択させるためのウェブ画面のリンクが含まれており、ウェブ画面において承認が選択されたことを条件に、発注受付部１ａが受け付けた発注データが発行装置２に取り込み可能となるようにしてもよい。

以下、発行装置２および管理装置４について具体的に説明する。

発行装置２は、図１０及び図１１に示すように、制御手段２０、入力手段２１及び表示手段２２を備えている。制御手段２０は、プロセッサ（ＣＰＵ）及びＣＰＵの制御下にあるメモリを含むコンピュータである。制御手段２０は、ハードウェア構成として、ＣＰＵ及びメモリの他、補助記憶装置（ＨＤＤ）、他の装置（入力手段２１、表示手段２２、印刷装置３）との各インターフェースやインターネット接続のためのインターフェースなどを有している。ＨＤＤは、コンピュータ内に含まれていてもよいし、コンピュータの外部装置として置かれてもよく、また、コンピュータがＨＤＤを含んだうえでさらに外部に別のＨＤＤを有していてもよい。

ＣＰＵは、入出力各部の動作を一連に制御するとともに、メモリ又はＨＤＤに記憶されているコンピュータプログラムを実行する。メモリ又はＨＤＤには、タクシーチケット１５を発行するためのチケット発行用のアプリケーションソフトウェアの他、各種データファイルを作成するためのアプリケーションソフトウェアや、管理装置４との間で所望のデータファイル・情報を送受信するためのアプリケーションソフトウェア、オペレーティングシステムなど、各種コンピュータプログラムが記憶されている。ＨＤＤには、また、各種のデータファイルが記憶される。チケット発行用のコンピュータプログラムは、チケットに印字する各種情報の入力を受け付けて印字用シート１４に印字されるように印刷装置３を動作させるなど、以下に説明する手順をＣＰＵに実行させるためのコンピュータプログラムである。ＣＰＵは、当該コンピュータプログラムに対応して各種手順を実行することで、表示手段２２、印刷装置３、ＨＤＤなどの発行装置２全体の動作を制御する。当該コンピュータプログラムは、当該コンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体（フラッシュメモリ、ＳＤカード、ＣＤ−ＲＯＭなど）を介して制御手段２０に供給されてもよいし、インターネットなどの通信ネットワークを介して制御手段２０に供給されてもよい。

入力手段２１は、例えばキーボードやマウス、タッチパネル装置などで構成される。また、表示手段２２は、例えば液晶ディスプレイなどで構成される。なお、入力手段２１及び表示手段２２は、上述のようにそれぞれ別個の機器であってもよいが、一つのユニットとして構成されていてもよい。例えば、ディスプレイ上にタッチスクリーンを重ねて配置したタッチパネルを用いることもでき、その場合は、ディスプレイが表示手段２２として機能し、タッチスクリーンが入力手段２１として機能する。

図１１は、発行装置２のブロック図である。制御手段２０は、記憶部２００の他、機能ブロックとして、取込部２０１、設定部２０２、動作部２０３、チケット発行情報作成部２０４を備えている。各機能ブロックは、ＣＰＵがコンピュータプログラムを実行することによりソフトウェア的に実現される。

取込部２０１は、図１に示す発注処理装置１の発注履歴データベース１ｃから、チケット利用会社１０１からの発注データを定期的に（例えば、毎日午前９時に）取り込む。設定部２０２は、取り込み順に自動的に識別番号の採番を行う。動作部２０３は、印字用シート１４の用紙１３毎に設定された識別番号及び取り込んだ発注データなどを印刷装置３に出力して順番に用紙１３に印字されるように印刷装置３を動作させる。

チケット発行情報作成部２０４は、発行装置２により発行したタクシーチケット１５について、例えば図１２に示すように、タクシーチケット１５に印字した情報、さらにはチケット発行日や発注者などの各種情報を識別番号毎に関連付けたチケット発行情報を作成する。なお、チケット発行情報に含まれる項目（情報）は、必ずしもこれらに限られず、他の項目（情報）が付け加えられていてもよい。チケット発行情報作成部２０４によって生成されたチケット発行情報は、記憶部２００に記憶される。

印刷装置３は、チケット発行会社より提供されたタクシーチケット１５の元となる用紙１３に、各種情報を文字などで印字するものである。印刷装置３としては、任意のプリンタを用いることができる。

一方で、管理装置４は、図１３及び図１４に示すように、制御手段４０、入力手段４１及び表示手段４２を備えている。制御手段４０は、プロセッサ（ＣＰＵ）及びＣＰＵの制御下にあるメモリを含むコンピュータである。制御手段４０は、ハードウェア構成として、ＣＰＵ及びメモリの他、補助記憶装置（ＨＤＤ）、他の装置（入力手段４１、表示手段４２、読取装置５）との各インターフェースやインターネット接続のためのインターフェースなどを有している。ＨＤＤは、コンピュータ内に含まれていてもよいし、コンピュータの外部装置として置かれてもよく、また、コンピュータがＨＤＤを含んだうえでさらに外部に別のＨＤＤを有していてもよい。

ＣＰＵは、入出力各部の動作を一連に制御するとともに、メモリ又はＨＤＤに記憶されているコンピュータプログラムを実行する。メモリ又はＨＤＤには、用紙１３を管理するためのチケット管理用のアプリケーションソフトウェアの他、各種データファイルを作成するためのアプリケーションソフトウェアや、発行装置２との間で所望のデータファイル・情報を送受信するためのアプリケーションソフトウェア、オペレーティングシステムなど、各種コンピュータプログラムが記憶されている。ＨＤＤには、また、各種のデータファイルが記憶される。チケット管理用のコンピュータプログラムは、使用済タクシーチケット１５の券面を読み取るように読取装置５を動作させ、取得した情報をデータ化したりするなど、以下に説明する手順をＣＰＵに実行させるためのコンピュータプログラムである。ＣＰＵは、当該コンピュータプログラムに対応して各種手順を実行することで、表示手段４２、読取装置５、ＨＤＤなどの管理装置４全体の動作を制御する。当該コンピュータプログラムは、当該コンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体（フラッシュメモリ、ＳＤカード、ＣＤ−ＲＯＭなど）を介して制御手段４０に供給されてもよいし、インターネットなどの通信ネットワークを介して制御手段４０に供給されてもよい。

入力手段４１は、例えばキーボードやマウス、タッチパネル装置などで構成される。また、表示手段４２は、例えば液晶ディスプレイなどで構成される。なお、入力手段４１及び表示手段４２は、上述のようにそれぞれ別個の機器であってもよいが、一つのユニットとして構成されていてもよい。例えば、ディスプレイ上にタッチスクリーンを重ねて配置したタッチパネルを用いることもでき、その場合は、ディスプレイが表示手段４２として機能し、タッチスクリーンが入力手段４１として機能する。

図１４は、管理装置４のブロック図である。制御手段４０は、記憶部４００の他、機能ブロックとして使用済チケット情報取得部４０１、チケット利用情報作成部４０２、未回収チケット情報作成部４０３、目的外使用チケット情報作成部４０４を備えている。各機能ブロックは、ＣＰＵがコンピュータプログラムを実行することによりソフトウェア的に実現される。なお、管理装置４および発行装置２を一つのコンピュータとして構成してもよい。

使用済チケット情報取得部４０１は、チケット発行会社がタクシー会社より回収した使用済タクシーチケット１５について、読取装置５で読み取った複数のタクシーチケット１５に記入の情報を、識別番号毎の一連のデータとしてまとめた使用済チケット情報を作成する。使用済チケット情報には、例えば図１５に示すように、使用済タクシーチケット１５の回収日、タクシーの利用金額が含まれている。なお、使用済タクシーチケット情報に含まれる項目（情報）は、必ずしもこれらに限られず、他の項目（情報）が付け加えられていてもよい。使用済チケット情報取得部４０１によって取得された使用済チケット情報は、記憶部４００に記憶される。

チケット利用情報作成部４０２は、前記使用済チケット情報に基づき、チケット利用会社毎に、回収した使用済タクシーチケット１５の利用情報を作成する。チケット利用情報は、例えば図１６に示すように、使用済タクシーチケット１５の回収日、タクシーの乗車日、タクシーの利用金額、乗降地、タクシー会社名が識別番号毎に関連付けられたものである。なお、タクシー利用情報に含まれる項目（情報）は、必ずしもこれらに限られず、他の項目（情報）が付け加えられていてもよい。チケット利用情報作成部４０２によって生成されたチケット利用情報は、記憶部４００に記憶される。

未回収チケット情報作成部４０３は、発行装置２から受け取った前記チケット発行情報及び前記利用情報を照合し、乗車指定日が印字されたタクシーチケット１５について乗車指定日を過ぎても回収されていないタクシーチケット１５を検出した未回収チケット情報を作成する。記憶部４００には、チケット利用会社毎の前記チケット発行情報が記憶されている。このチケット発行情報は、発行装置２より管理装置４にネットワークを介して送信される。未回収チケット情報は、例えば図１７に示すように、チケット利用会社毎に、前記チケット発行情報に示されているチケット利用会社発行のタクシーチケット１５のうち、乗車指定日（例えば２０１６／９／３０）から一定期間を過ぎてもチケット発行会社に使用済タクシーチケット１５として回収されていないタクシーチケット１５の識別番号、乗車指定日、イベント名、利用者、配布責任者などの情報がまとめられたものである。なお、未回収チケット情報に含まれる項目（情報）は、必ずしもこれらに限られず、他の項目（情報）が付け加えられていてもよい。未回収チケット情報作成部４０３によって生成された未回収チケット情報は、記憶部４００に記憶される。

目的外使用チケット情報作成部４０４は、発行装置２から受け取った前記チケット発行情報及び前記利用情報を照合し、乗車指定日が印字されたタクシーチケット１５について乗車指定日外（乗車指定日が所定の日（例えば２０１６年９月３０日）であればその日（２０１６年９月３０日）とは異なる日、乗車指定日が所定の期間（例えば２０１６年９月１５日〜２０１６年９月３０日）であればその期間外）に使用されたタクシーチケットを検出した目的外使用チケット情報を作成する。目的外使用チケット情報は、例えば図１８に示すように、チケット利用会社毎に、回収した使用済タクシーチケット１５のうち、実際の乗車日が乗車指定日（例えば２０１６／９／３０）外であってチケット利用会社が意図した使用目的外に使用されたタクシーチケット１５の識別番号、乗車指定日、乗車日、利用金額などの情報がまとめられたものである。この目的外使用チケット情報は、チケット利用会社毎のチケット発行情報及び利用情報を照合することで作成することもできるし、図１６に示す使用済タクシーチケット１５の利用情報に乗車指定日の項目を追加することで、前記利用情報に基づき作成することもできる。なお、目的外使用チケット情報に含まれる項目（情報）は、必ずしもこれらに限られず、他の項目（情報）が付け加えられていてもよい。また、目的外使用チケット情報としては、乗車指定日内に使用されたタクシーチケット１５であっても、実際にタクシーを利用した際の乗車地及び降車地が、タクシーチケット１５に予め印字されたイベントの開催場所と明らかに異なる場合にも、チケット利用会社が意図した使用目的外で使用されたタクシーチケット１５として検出するようにしてもよい。目的外使用チケット情報作成部４０４によって生成された目的外使用チケット情報は、記憶部４００に記憶される。

読取装置５は、回収された使用済タクシーチケット１５の券面を読み取り、管理装置４で管理できるようにデータ化するものである。そのため、読取装置５は、タクシーチケット１５に記入される文字や数字を認識してデータ化する文字認識機能を有している。また、読取装置５はタクシーチケット１５の券面の画像データを作成する機能をさらに有していることが好ましい。

本実施形態では、チケット発行会社１００が発行したタクシーチケット１５は、上述のように、チケット利用会社１０１に送付される。あるいは、図８に示すような印字用シート１４をチケット利用会社１０１に送付するとともに、タクシーチケットの印字用データをチケット利用会社１０１に送信し、チケット利用会社１０１が印字用シート１４に印字を行うことにより、タクシーチケット１５を取得してもよい。

タクシーチケット１５は、チケット利用者１０２に配布され、チケット利用者１０２によりタクシーの乗車に際して使用されることで、タクシー会社１０４に回収される。そして、タクシー会社１０４からチケット発行会社１００に利用金額の請求とともに、使用済タクシーチケット１５が送付される。

チケット発行会社１００では、使用済タクシーチケット１５を回収すると、担当者などが使用済タクシーチケット１５を読取装置５にセットする。使用済タクシーチケット１５のセット後、管理装置４を用い、入力手段４１によって、使用済タクシーチケット１５の利用情報の読み取りを行う。読み取り操作が行われると、制御手段４０のＣＰＵは、セットされた使用済タクシーチケット１５の券面に記載の情報の読み取り動作が行われるように読取装置５に読み取り動作を実行させる。読取装置５によって読み取られてデータ化された使用済チケット情報は、記憶部４００に保存される。

チケット発行会社１００の管理装置４においては、担当者などの所定の操作に基づき、制御手段４０のＣＰＵが使用済チケット情報から、チケット利用会社毎に使用済タクシーチケット１５の利用情報を作成し、記憶部４００に保存する。また、チケット発行会社の管理装置４においては、担当者などの指令に基づき、制御手段４０のＣＰＵが、使用済チケット情報から、未回収チケット情報、目的外使用チケット情報などの情報を作成し、記憶部４００に保存する。また、未回収チケット情報、目的外使用チケット情報を、メールなどでネットワークを介してチケット利用会社１０１の発注管理端末１１に送信する。チケット利用会社１０１では、発注管理端末１１が受信した情報を図示しない記憶部に保存する。また、チケット発行会社１００は、タクシーの利用金額を、所定期間単位、例えば１ヶ月単位でまとめて請求書を発行し、チケット利用会社１０１に請求する。

以上のように、本実施形態のタクシーチケット処理システム１０では、チケット発行会社１００の発注処理装置１がチケット利用会社１０１からのタクシーチケットの発注を受け付けると、当該発注内容の履歴を発注履歴データベース１ｃに記録する。さらに、発注処理装置１は、チケット利用会社１０１からの照会要求に応じて、チケット利用会社１０１の全ての通信端末からの発注の履歴データを発注履歴データベース１ｃから取得し、チケット利用会社１０１に送信する。これにより、チケット利用会社１０１において、発注管理端末１１を操作する発注責任者は、社内全体のチケット発注状況をＭＲごとに把握するために、発注管理データベースを自ら作成する必要がない。よって、発注責任者の事務作業の負担を軽減することができる。

加えて、本実施形態のタクシーチケット処理システム１０では、チケット発行会社１００において、チケット利用会社１０１毎に、乗車指定日を過ぎても回収されていないタクシーチケット１５に関する未回収チケット情報、さらには、乗車指定日外に使用されたタクシーチケット１５に関する目的外使用チケット情報を作成し、チケット利用会社１０１に提供している。そのため、チケット利用会社１０１では、発行したタクシーチケット１５について、チケット利用者１０２に過剰に配布されていないか、あるいは、チケット利用者１０２に不適正に使用されていないかを確認することができる。これにより、チケット利用会社１０１では、未使用チケットや目的外使用チケットの発注を行った発注者や配布責任者に対して、適切な指導を行うことができる。

以上、本発明の実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて、種々の変更が可能である。

本発明は上記の実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、実施形態に開示された技術的手段を適宜組み合わせて得られる形態も本発明の技術的範囲に含まれる。

例えば、本実施形態では、チケット発行会社１００がチケット利用会社１０１に提供するタクシーチケット１５の使途に関する情報として、管理装置４を用いて未回収チケット情報及び目的外使用チケット情報を作成し、発注管理端末１１に送付している。これに加えて、図１９に示すように、タクシーチケット１５に印字されたイベント名毎に、チケット利用会社が発行したタクシーチケット１５の発行枚数、過去何カ月（図示例では４カ月）の使用済タクシーチケット１５の回収枚数を表示したチケット利用状況情報をチケット発行会社１００の管理装置４で作成して、チケット利用会社１０１の発注管理端末１１に送付してもよい。これにより、チケット利用会社１０１では、各種イベントへの参加を促すためにチケット利用者１０２に配布したタクシーチケット１５の利用状況が一目で把握でき、チケット利用者１０２に過剰に配布されていないか、あるいは、チケット利用者１０２に不適正に使用されていないかを確認することができる。

図２０は、本発明の一変形例に係るタクシーチケット処理システムにおける発注処理装置１’および発注管理端末１１’のブロック図である。当該タクシーチケット処理システムの発注処理装置１’および発注管理端末１１’以外の構成要素については、図１に示すタクシーチケット処理システム１０と同一であるので、図示および説明を省略する。

発注処理装置１’は、図１に示す発注処理装置１において、参照条件受付部１ｅをさらに備えた構成であり、発注管理端末１１’は、図１に示す発注管理端末１１において、参照条件指定部１１ｂをさらに備えた構成である。発注処理装置１’の参照条件受付部１ｅは、照会処理部１ｄが発注履歴照会部１１ａからの発注履歴の照会要求に応じて発注履歴ＤＢ１ｃを参照するための参照条件を受け付ける機能ブロックであり、発注処理装置１’の図示しないＣＰＵが本発明に係る発注処理プログラムを実行することにより実現される。発注管理端末１１’の参照条件指定部１１ｂは、前記参照条件を発注管理端末１１’のユーザ（発注責任者）の操作に応じて指定する機能ブロックである。

図２０に示す構成では、照会処理部１ｄが発注履歴の照会要求を受け付けると、上記の実施形態と同様に、発注履歴データベース１ｃを参照して、タクシーチケット発注の履歴データを取得し、当該履歴データを発注履歴照会部１１ａに送信する。この履歴データには、チケット利用会社１０１の全ての通信端末からの発注の履歴が含まれているが、発注責任者がタクシーチケットの発注漏れの有無を調べたい場合、発注件数が多いほど、発注漏れの有無の確認に手間がかかる。

そこで、本変形例では、発注管理端末１１’に表示される履歴データの画面に、「検索条件」というボタンが表示される。「検索条件」とは、履歴データを絞り込むための条件を意味しており、発注処理装置１’の照会処理部１ｄが発注履歴ＤＢ１ｃを参照するための参照条件と同義である。ユーザが「検索条件」のボタンを選択すると、図２１に示す検索条件指定画面がポップアップ表示される。検索条件指定画面には、乗車指定日、会合企画Ｎｏ．、会合企画名および配布責任者名を入力するための欄が設けられている。乗車指定日は、タクシーチケットの乗車指定日であり、会合企画Ｎｏ．および会合名は、医療関係者にタクシーチケットの利用を促す会合企画の番号および名称であり、配布責任者名は、タクシーチケットを利用者に配布する責任を有する者の氏名である。なお、検索条件はこれらに限定されず、会合企画が行われる施設名、タクシーチケットの利用者、タクシーチケットの限度額などを検索条件としてもよい。

例えば図２に示す履歴データから、乗車指定日が２０１６年３月２９日〜２０１６年３月３１日であるタクシーチケットの発注履歴のみを絞り込みたい場合、ユーザは、図２２に示すように、検索条件指定画面の乗車指定日の欄に、「2016/03/29」および「2016/03/31」と入力し、「ＯＫ」ボタン１３５を選択する。これにより、図２０に示す参照条件指定部１１ｂは、乗車指定日を含む参照条件を発注処理装置１’に送信する。発注処理装置１’の参照条件受付部１ｅは、参照条件指定部１１ｂからの参照条件を受け付けると、当該参照条件に従って発注履歴ＤＢ１ｃを参照するよう、照会処理部１ｄに指示する。これにより、照会処理部１ｄは、乗車指定日が２０１６年３月２９日〜２０１６年３月３１日であるタクシーチケットの発注履歴データを発注履歴ＤＢ１ｃから取得し、当該履歴データを発注履歴照会部１１ａに送信する。これにより、図２３に示すように、乗車指定日が２０１６年３月２９日〜２０１６年３月３１日であるタクシーチケットの履歴データが発注管理端末１１’に表示される。このように、乗車指定日を参照条件として指定することにより、発注責任者は、例えば、乗車指定日が近日中に到来するタクシーチケットが漏れなく発注されているか否かを、容易に確認することができる。

なお、参照条件指定部１１ｂによる参照条件の指定は、発注履歴照会部１１ａによる照会要求と同時に行ってもよい。また、発注管理端末１１’に表示されたタクシーチケットの履歴データを、ｃｓｖファイル等に変換して発注処理装置１’にダウンロードできるようにしてもよい。

図２４は、本発明の他の変形例に係るタクシーチケット処理システムの一部を示すブロック図である。当該タクシーチケット処理システムは、図１に示すタクシーチケット処理システム１０において、発注管理端末１１、社員端末１２および管理装置４をそれぞれ発注管理端末１１”、社員端末１２’および管理装置４’に置き換え、管理用サーバ６をさらに備えた構成である。発注管理端末１１”は、図１に示す発注管理端末１１において、チケット利用情報編集部１１ｃおよび会員情報編集部１１ｄをさらに備えた構成であり、社員端末１２’は図１に示す社員端末１２において、チケット利用情報取得部１２ａをさらに備えた構成である。管理装置４’は、図１４に示す管理装置４において、制御手段４０がチケット利用情報更新部４０５および会員情報更新部４０６をさらに備え、記憶部４００に会員情報がさらに格納された構成である。利用情報更新部４０５および会員情報更新部４０６は、ＣＰＵがコンピュータプログラムを実行することによりソフトウェア的に実現される。

また、管理用サーバ６は、記憶部６０を備えたコンピュータである。管理用サーバ６は、インターネットなどの通信ネットワークを介して、発注管理端末１１”、社員端末１２’および管理装置４と通信可能となっている。本変形例において、管理用サーバ６は、クラウド上の独立したサーバとして設けられているが、例えば、図１に示す発注処理装置１と一体的に構成してもよい。

図２４に示す構成では、チケット利用情報作成部４０２によって生成されたチケット利用情報は、記憶部４００に記憶されるとともに、管理用サーバ６にも送信（アップロード）され、記憶部６０に記憶される。さらに、発注管理端末１１”のチケット利用情報編集部１１ｃおよび社員端末１２’のチケット利用情報取得部１２ａは、記憶部６０に記憶されたチケット利用情報をダウンロードする機能を有している。ダウンロードされたチケット利用情報を図示しないディスプレイに表示することにより、発注管理端末１１”および社員端末１２’のユーザは、タクシーチケットの利用実績をウェブ上で確認することができる。特に、発注管理端末１１”のユーザである発注責任者は、チケット利用情報を確認することにより、配布されたタクシーチケットが適正に利用されているか（例えば、実際の利用日が乗車指定日であるか、実際の利用金額が限度額以内であるか）を把握することができる。

本変形例においてチケット利用情報は、図１６に示すように、使用済タクシーチケットの識別番号、回収日、タクシーの乗車日、タクシーの利用金額、乗降地、タクシー会社名を含むものであってもよいが、これらに限定されず、企画会合名、施設名、利用者名などを含んでもよい。

また、発注管理端末１１”のチケット利用情報編集部１１ｃは、記憶部６０に記憶されたチケット利用情報をｃｓｖファイルに変換してダウンロードすることができる。仮に、チケット利用情報の内容に誤りがあった場合、発注管理端末１１”のユーザは、ｃｓｖ形式のチケット利用情報を修正することができる。チケット利用情報の修正が完了すると、チケット利用情報編集部１１ｃは、修正後のチケット利用情報を管理用サーバ６の記憶部６０にアップロードする。その後、管理装置４’において、チケット利用情報更新部４０５が修正後のチケット利用情報を管理用サーバ６からダウンロードして、記憶部４００に格納する。これにより、チケット利用会社側でチケット利用情報を修正することが可能となる。

なお、チケット利用情報編集部１１ｃは、チケット利用情報をｃｓｖファイルに変換してダウンロードしていたが、発注管理端末１１”で編集可能なファイル形式であれば、チケット利用情報を他のファイル形式に変換してもよい。また、チケット利用情報をチケット利用会社側で無制限に修正できるようにしてもよいが、修正可能な項目を、企画会合Ｎｏ．、企画会合名、施設名、利用者名といった利用金額以外の項目に限定することが望ましい。さらに、チケット利用情報が修正可能な期間を所定期間内に制限してもよい。

本変形例では、社員端末１２’のチケット利用情報取得部１２ａは、上述のチケット利用情報の編集機能は有していない。すなわち、社員端末１２’のユーザ（ＭＲ）は、チケット利用情報の閲覧のみが可能となっている。また、社員端末１２’が複数台存在する場合、一部の社員端末１２’のみに、チケット利用情報取得部１２ａの機能を設けてもよい。

なお、社員端末１２’にも、発注管理端末１１”のチケット利用情報編集部１１ｃと同等の機能を与えてもよいが、ＭＲなどの一般社員、チケットの発注責任者など、社内の権限に応じて、チケット利用情報の閲覧または編集が可能な範囲を制限することが望ましい。

図２５は、記憶部４００に記憶されている会員情報の一例である。会員情報は、チケット利用会社の社員に関する情報を含んでおり、本変形例では、社員コード、社員名、部門名およびメールアドレスを含んでいる。会員情報は、チケット利用会社がタクシーチケット利用を開始した時点（例えば、チケット発行会社と利用契約を結んだ時点）で、チケット利用会社からチケット発行会社に提供されたものであってもよいし、これまでにチケット発注を行ったことのある社員の情報を蓄積したものであってもよい。

本変形例では、記憶部４００に記憶されている会員情報は、会員情報更新部４０６によって、管理用サーバ６の記憶部６０にアップロードされる。さらに、発注管理端末１１”の会員情報編集部１１ｄは、記憶部６０に記憶された会員情報をｃｓｖファイルに変換してダウンロードすることができる。発注管理端末１１”のユーザは、ｃｓｖ形式の会員情報を修正することができ、会員情報の修正が完了すると、会員情報編集部１１ｄは、修正後の会員情報を管理用サーバ６の記憶部６０にアップロードする。その後、管理装置４’において、会員情報更新部４０６が修正後の会員情報を管理用サーバ６からダウンロードして、記憶部４００に格納する。これにより、新入社員の加入、社員の異動、退職等が発生した場合に、チケット利用会社側で会員情報を容易に変更することができる。

以上、本変形例では、チケット利用情報および会員情報をチケット利用会社側で変更する例について説明したが、チケット利用会社側で変更可能な情報はこれらに限定されない。例えば、チケット利用会社の部門に関する情報や、企画会合に関する情報を、管理装置４’および管理用サーバ６に登録しておき、必要に応じて、チケット利用会社が管理用サーバ６から変更したい情報をダウンロードして編集できるようにしてもよい。

１ 発注処理装置
１’ 発注処理装置
１ａ 発注受付部
１ｂ 認証情報データベース
１ｃ 発注履歴データベース
１ｄ 照会処理部
１ｅ 参照条件受付部
２ 発行装置
３ 印刷装置
４ 管理装置
４’ 管理装置
５ 読取装置
６ 管理用サーバ
１０ タクシーチケット処理システム
１１ 発注管理端末
１１’ 発注管理端末
１１” 発注管理端末
１１ａ 発注履歴照会部
１１ｂ 参照条件指定部
１１ｃ チケット利用情報編集部
１１ｄ 会員情報編集部
１２ 社員端末
１２’ 社員端末
１２ａ チケット利用情報取得部
１３ 用紙
１４ 印字用シート
１５ タクシーチケット
２０ 制御手段
２１ 入力手段
２２ 表示手段
４０ 制御手段
４１ 入力手段
４２ 表示手段
６０ 記憶部
１００ チケット発行会社
１０１ チケット利用会社
１０１ 発行処理装置
１０２ チケット利用会社
１０３ タクシー
１０４ タクシー会社
１１０ 発行処理装置
１１０ａ 発注受付部
１１０ｂ 発注データ記憶部
１１０ｃ 発行処理部
１１１ 発注管理端末
１１１ａ 発注管理データベース
１１２ 社員端末
１３１ ログインボタン
１３２ ボタン
１３３ ボタン
１３４ ボタン
１３５ ボタン
２００ 記憶部
２０１ 取込部
２０２ 設定部
２０３ 動作部
２０４ チケット発行情報作成部
４００ 記憶部
４０１ 使用済チケット情報取得部
４０２ チケット利用情報作成部
４０３ 未回収チケット情報作成部
４０４ 目的外使用チケット情報作成部
４０５ チケット利用情報更新部
４０６ 会員情報更新部

Claims (7)

1. 複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理装置であって、
   前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付部と、
   前記発注受付部が受け付けた発注の履歴を記録する発注履歴データベースと、
   前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理部と、
   を備えた発注処理装置。
2. 前記照会処理部は、前記複数の通信端末のうち、少なくとも特定の端末からの照会要求を受け付ける、請求項１に記載の発注処理装置。
3. 前記特定の端末は、前記チケット利用会社のタクシーチケットの発注状況を管理する発注責任者が使用する端末である、請求項２に記載の発注処理装置。
4. 前記照会処理部が前記発注履歴データベースを参照するための参照条件を受け付ける参照条件受付部をさらに備え、
   前記照会処理部は、前記参照条件受付部が受け付けた前記参照条件に従って取得した履歴データを前記チケット利用会社に送信する、請求項１〜３のいずれかに記載の発注処理装置。
5. 複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法であって、
   前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、
   前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、
   前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、
   を備えた発注処理方法。
6. 複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法をコンピュータに実行させる発注処理プログラムであって、
   前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、
   前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、
   前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、
   をコンピュータに実行させる、発注処理プログラム。
7. 複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法をコンピュータに実行させる発注処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   前記発注処理プログラムは、
   前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、
   前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、
   前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、
   をコンピュータに実行させる、記録媒体。