JP2001331761A

JP2001331761A - 申請処理システム

Info

Publication number: JP2001331761A
Application number: JP2000147006A
Authority: JP
Inventors: Satoshi Sakurai; 智櫻井; Masaki Aeba; 正樹饗庭
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2000-05-18
Filing date: 2000-05-18
Publication date: 2001-11-30

Abstract

(57)【要約】【課題】責任者による申請情報の検証・認可処理の負
担を軽減でき、しかも検証のもれや誤りを確実に防止で
きる申請処理システムを提供すること。【解決手段】申請情報生成時に、旅費申請情報におけ
る運賃情報について、申請者が申請者端末２０から手入
力した情報と運賃データベース１４から転記された情報
とを区別する区分情報を付加しておく。そして、検証・
認可時には、この区分情報に基づき、運賃データベース
１４から転記された運賃情報と申請者が手入力した運賃
情報とが区別できる形式で責任者端末３０に表示させ
る。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、会社等の組織にお
いて申請者が入力したデータ（たとえば出張旅費）を責
任者がその正当性を検証する作業を支援する申請処理シ
ステムに関するものである。

【０００２】

【従来の技術】会社等の組織においては、例えば出張旅
費の申請・認可（精算）などのように、申請者がある申
請をして、責任者が当該申請の妥当性を検証して申請内
容に誤りがないか判定するという業務が日常的に発生し
ており、そうした申請内容の検証業務を支援するための
申請処理システムも広く利用されている。

【０００３】こうしたシステムを、コンピュータ及びネ
ットワークを利用して実現する技術として、たとえば、
出張旅費の精算処理を行うシステムが、特開平９−２６
９９９号の公報に記載されている。これは、あるオンラ
イン端末から申請者が入力した出張旅費について、責任
者が別の端末上で内容確認と認可／却下の決定を行い、
認可された申請については旅費管理データベースに格納
された上で精算が行われるというものである。

【０００４】出張旅費の精算にあたって、正しく旅費精
算が行われるためには、申請時に各種運賃（鉄道運賃、
航空機運賃のような交通機関の運賃）が正しく入力され
ていることが必須である。そのために、申請者は運賃を
極力誤りなく入力するよう努め、責任者も、申請内容の
うち特に運賃部分については入念な検証を行うのが普通
である。

【０００５】こうした申請者、責任者双方の運賃入力／
検証の負担を軽減するための方法として、申請者が運賃
を直接入力するのではなく、各種交通機関に関する検証
済みの運賃情報を格納した運賃データベースをシステム
が保持し、申請者は交通機関の種別および乗車（乗船、
航空機への搭乗も含む）地点、降車地点の情報を入力す
るだけで、前記データベース内の検証済み運賃が申請書
（申請用電子フォーマット）に転記される、というもの
がある。

【０００６】

【発明が解決しようとする課題】しかしながら、前記の
検証済み運賃データベースから運賃情報のように検証済
み情報を転記する方法を用いるとしても、発生しうる全
ての状況を網羅したデータベース（運賃の例で言えば、
地方のバス料金などまで含めて国内外のすべての交通機
関の運賃情報を格納したデータベース）を作成し維持す
るのは困難であり、実際のところ、データベースに格納
される情報は、使用頻度の高い一部の情報に限定される
のが一般的である。

【０００７】そのため、検証済みデータを転記する方法
を用いて生成された申請書であっても、すべてがデータ
ベースから転記された検証済み情報とは限らず、一部が
データベースから転記された情報であり、残りが申請者
により入力された情報である場合が多い。すると、ある
情報がデータベースから転記された検証済み情報か、そ
れとも申請者が手入力し、別途検証を必要とする情報で
あるか判断がつかない事態が生じ、そうなると責任者
は、申請書に入力された全ての情報について念のため改
めて検証を行うこととなる。すると、データベースから
転記された検証済み情報に対して不要な検証が行われる
場合も発生して、検証作業の負荷軽減という検証済み運
賃データベース導入の効果が損なわれてしまう。また、
逆に、検証の必要な手入力の運賃情報を、検証済み情報
と誤解して必要な検証が行われず、不正な申請が誤って
認可される事態も起こりうる。

【０００８】本発明は上記課題に鑑み、責任者による申
請情報（運賃情報など）検証の負担を確実に軽減できる
とともに、検証のもれや誤りも確実に防止することので
きる申請処理システムを提供することを目的とする。

【０００９】

【課題を解決するための手段】上記の目的を達成するた
めに、本発明の申請処理システムは、申請者からの指示
に応じて複数の項目データから成る申請データを生成
し、責任者による当該申請データの検証を支援する申請
処理システムであって、予め正当性を検証された検証済
みデータを保持する保持手段と、申請者からの指示に従
って前記保持手段が保持する検証済みデータを転記する
ことで前記申請データ中に転記項目データを設定する転
記手段と、申請者が入力した入力データを前記申請デー
タ中に手入力項目データとして設定する入力受付手段
と、前記申請データ中に設定された項目データの各々に
ついて、転記項目データであるか手入力項目データであ
るかの区別を表す識別情報を付加する付加手段と、申請
データを責任者に提示する際、前記識別情報に応じ、前
記転記項目データと前記手入力項目データとを異なる形
式で提示する提示手段とを有することを特徴としてい
る。これによって、責任者は申請データの検証を行う
際、検証の必要な項目データと検証の不要な項目データ
とを容易に区別できるので、検証の不要な項目データに
対してまで検証を行うといった無意味な作業による負荷
が発生することはなくなり、また、検証の必要な項目デ
ータの検証もれという事態も防止できるので、責任者に
よる申請情報検証の負担を確実に軽減できるとともに、
検証のもれや誤りも確実に防止できる。

【００１０】また、上記の目的を達成するために、本発
明の申請処理方法は、申請者からの指示に応じて複数の
項目データから成る申請データを生成し、責任者による
当該申請データの検証を支援する申請処理方法であっ
て、予め正当性を検証された検証済みデータを保持する
保持ステップと、申請者からの指示に従って前記検証済
みデータを転記することで前記申請データ中に転記項目
データを設定する転記ステップと、申請者が入力した入
力データを前記申請データ中に手入力項目データとして
設定する入力受付ステップと、前記申請データ中に設定
された項目データの各々について、転記項目データであ
るか手入力項目データであるかの区別を表す識別情報を
付加する付加ステップと、前記識別情報に応じ、前記転
記項目データと前記手入力項目データとを異なる形式で
責任者に提示する提示ステップと、を有することを特徴
とする。

【００１１】

【発明の実施の形態】以下、本発明の申請処理システム
に関する実施の形態を、旅費申請システムを例に、図面
を参照しながら説明する。（全体の構成）まず、図１は、本実施の形態発明に係る
旅費申請システムの全体構成を示すブロック図である。
当該旅費申請システム１は、旅費申請に関わる処理およ
び情報を管理する旅費管理サーバ１０、申請者が旅費申
請を入力するのに用いる申請者端末２０、責任者が旅費
申請の検証・認可を行うのに用いる責任者端末３０、経
理部門が認可済み旅費申請の精算の処理を行うのに用い
る管理部門端末４０が、通信ネットワークＮにより相互
に接続されて構成されている。申請者端末２０および責
任者端末３０はシステム上に複数存在するが、ここでは
作図の便宜上１つだけ図示してある。

【００１２】先ず、旅費申請システム１上で行われる旅
費申請から認可、精算までの処理の概要を説明してお
く。当該処理は大きく３つの手順に分かれる。（１）出張者が申請者用クライアント１００上で申請書
（電子フォーマット）を作成し、旅費管理サーバ１０に
送信する。このとき、申請書に記入される旅費情報（出
張に使用した交通機関の運賃を示す情報）の一部または
全部は、旅費管理サーバ１０が保持する運賃データベー
ス１４から転記される。（２）いったん旅費管理サーバ１０に格納された申請書
は、責任者用端末３０に送信され、責任者による検証、
認可を受ける。責任者は端末上で検証を終えた申請書に
認可を与えて旅費管理サーバ１０に返送する。（３）責任者が認可した申請書は旅費管理サーバ１０に
いったん格納された後、管理部門端末４０に送信され、
この認可済み申請書を元に、管理部門（経理部門）の担
当者が出張旅費の精算を行う。

【００１３】本実施の形態の旅費申請システム１の特徴
は、（１）の手順において、申請書に入力された旅費情
報を、運賃データベース１４からの転記分と申請者によ
る手入力分とで区別し、（２）の手順において、責任者
に申請書の内容を提示する際、転記による旅費情報と手
入力による旅費情報とを区別できる形で提示する、とい
う点である。以下に、申請者が申請に用いる申請書の構
成を、申請手続き開始時の初期状態と、責任者に提示さ
れる際の状態とで図示する。

【００１４】図２（ａ）、（ｂ）は、それぞれ、上記
（１）〜（３）の旅費申請処理に用いられる申請書３０
０の初期状態（申請者が入力を行う前の状態）と責任者
による検証時点での状態とを示す図である。申請書フォ
ーマット３００は端末の表示装置上に表示され、申請者
は端末の入力装置を介して入力を行う。図２（ａ）に示
す申請書３００は、上記（１）の手順において申請者
が、行先、目的等を入力する出張情報入力部３１０と出
張に利用した交通機関に関する複数項目の情報（特に運
賃）を入力する旅費情報入力部３２０とからなり、その
他、旅費管理サーバ１０から付加された申請書の通し番
号３０１が表示されているとともに、申請者が運賃情報
転記を要求するのに用いる運賃転記ボタン３４０、入力
した申請情報を旅費管理サーバ１０に転送するのに用い
る送信ボタン３３０がある。

【００１５】旅費情報入力部３２０には、ある交通機関
を利用しての移動とその結果発生した運賃とを示す旅費
情報が入力される。旅費情報は「利用年月日」、「交通
機関」、「乗車地」、「降車地」、「座席種別」、「運
賃」の項目から成り、「運賃」の項目（運賃欄３２６）
のみ運賃データベース１４からの情報転写で値を設定で
きる。

【００１６】申請者は、旅費情報入力部３２０におい
て、運賃欄３２６以外の情報を入力した上で、運賃転記
ボタン３４０を押下（クリック）すると、旅費管理サー
バ１０から、入力された「交通機関」、「乗車地」、
「降車地」、「座席種別」の情報に対応する運賃情報が
送られてきて、運賃欄３２６に転記される。ただし、該
当する運賃情報が旅費管理サーバ１０側に存在しない場
合は、申請者が手入力で運賃欄３２６にデータを入力す
る。この時、「運賃」の項目（運賃欄３２６）に入力さ
れた個々の運賃情報（「運賃」項目データ）について
は、それぞれ「転記」によって設定されたものか、「手
入力」によって設定されたものかを示す情報が申請者端
末２０で生成され、申請書３００に入力された各種情報
とともに旅費管理サーバ１０に送られる。

【００１７】図２（ｂ）に示す申請書３００は、責任者
による認可を受ける段階なので、申請者によるデータ入
力は完了している。図２（ａ）における申請書３００に
比べると、いくつか違いがある。認可ボタン３５０が設
けられている他、旅費情報入力部３２０内の各運賃情報
のうち転記によって入力された運賃情報に対し、転記マ
ーク７００「●」が付加されている。これは、運賃欄３
２６の運賃情報について、責任者が転記によって設定さ
れたものを手入力によって設定にされたものと区別でき
るようにするためのもので、転記された運賃情報に限っ
て付加される。これにより、責任者は、各運賃情報が転
記か手入力かを識別でき、検証の必要な手入力データに
対してだけ検証を行うことができる。（各部の構成）次いで、旅費申請システム１の各構成部
について説明する。

【００１８】申請者用端末２０は、申請者が出張旅費申
請を入力する端末であり、入出力部２１、ＷＷＷブラウ
ザ２２などを有する。ＷＷＷブラウザ２２は、旅費管理
サーバ１０との間に通信を確立し、各種の要求およびデ
ータの送受信を行う。具体的には、初期状態の申請書３
００（図２（ａ））のデータを旅費管理サーバ１０から
受信して入出力部２１に渡し、申請者にデータ入力を行
わせた後、入力された情報を旅費管理サーバ１０に返送
する。また、申請者からの運賃情報転記要求を入出力部
２１経由で受け付けて旅費管理サーバ１０に送信し、返
送されてくる運賃情報を入出力部２１に渡す。

【００１９】入出力部２１は、WWWブラウザ２２から渡
される申請書３００をディスプレイ上に表示し、ここに
申請者が入力する申請情報や運賃データ転記要求をＷＷ
Ｗブラウザ２２に渡して旅費管理サーバ１０に送信させ
る。申請責任者用クライアントは、責任者が、申請書３
００（図２（ｂ））の内容を検証・認可するための端末
であり、入出力部３１、ＷＷＷブラウザ３２、などを有
する。

【００２０】ＷＷＷブラウザ３２は、旅費管理サーバ１
０との間に通信を確立し、各種の要求およびデータ（申
請書３００）の送受信を行う。具体的には、責任者から
の要求に応じて、データ入力が終った申請書３００（図
２（ｂ））のデータを旅費管理サーバ１０から受信して
入出力部３１に渡し、当該申請に対する責任者に検証・
認可が終れば、旅費管理サーバ１０に認可完了を通知す
る。入出力部３１は、上記の申請書３００をディスプレ
イ上に表示して責任者から認可処理に関する入力を受け
付けた後、入力内容をＷＷＷブラウザ３２に返す。

【００２１】管理部門端末４０は、経理担当者が旅費精
算を行うために、認可済み申請の内容を確認するのに用
いる端末であり、入出力部４１、ＷＷＷブラウザ４２な
どを有する。ＷＷＷブラウザ４２は、旅費管理サーバ１
０との間に通信を確立し、各種の要求およびデータ（申
請書３００）の送受信を行う。具体的には、認可済みか
つ未精算の申請書３００のデータを旅費管理サーバ１０
から受信して入出力部４１に渡し、経理担当者に提示さ
せる。入出力部４１は、経理担当者からの申請書表示要
求をWWWブラウザ４２に伝え、それに対して送られてく
る上記申請書３００をディスプレイ上に表示する。

【００２２】旅費管理サーバ１０は、ＷＷＷサーバとデ
ータベースサーバを連携させた構成を用い、各種端末
（申請者端末２０、責任者端末３０、管理部門端末４
０）からの要求を受けて内蔵するデータベース内に保持
する旅費申請関連の各種情報を検索のうえ送信したり、
または内容を更新したりする。そのための構成として、
ＷＷＷサーバ１１、データベース管理部（ＤＢ管理部）
１２、３種類のデータベース（個々の旅費申請の情報
（申請情報）が格納される申請情報データベース１３、
転記用の検証済み運賃データが格納された運賃データベ
ース１４、旅費申請を行う申請者と申請を検証・認可す
る責任者との対応関係を示す情報が格納された責任者デ
ータベース１５）を有している。

【００２３】ＷＷＷサーバ１１は、申請者端末２０、責
任者端末３０または管理部門端末４０から受け付けた旅
費関連情報に対する検索・更新などの要求を、データベ
ース操作用の言語であるＳＱＬ（Structured Query Lan
guage）文に変換してＤＢ管理部１２に渡す。そして、
検索の場合は、その実行結果をＤＢ管理部１２から受け
取って、端末側で画面表示できるＨＴＭＬ（Hypertext
Makeup Language）形式に変換した上で上記の各種端
末に送信する。

【００２４】ここで、ＷＷＷサーバ１１と、各種端末
（申請者端末２０、責任者端末３０、管理部門端末４
０）のＷＷＷブラウザ（図面では申請者端末２０のＷＷ
Ｗブラウザ２２のみ表示）との通信形式について説明し
ておく。図３は、旅費申請システム１上での端末内のWW
Wブラウザと旅費管理サーバ１０内のＷＷＷサーバ１１
及びＤＢ管理部１２との間の要求、データのやり取りの
仕組みを示す図である。まず、ＷＷＷブラウザからの要
求に応じて両者の間で通信が確立すると、ＷＷＷサーバ
１１は、端末からの要求、データ入力受け付けのための
入力フォーム（申請書３００用）および必要なスクリプ
トなどをＨＴＭＬ形式でＷＷＷブラウザに送信する。そ
して、申請者からのデータあるいは要求がWWWブラウザ
から送信されてくると、これをもとにＤＢ操作用ＳＱＬ
文を生成し、入力データや要求の内容に基づいて各種デ
ータベースを操作する（申請情報データベース１３への
申請情報の追加、運賃データベース１４の運賃情報の検
索など）。

【００２５】ＤＢ管理部１２は、ＷＷＷサーバ１１から
渡されるＳＱＬ文を実行して、申請情報データベース１
３及び運賃データベース１４、責任者情報データベース
１５内の情報の検索、更新などデータベース操作を行
い、その結果をWWWサーバ１１に返す。（各種データベースの説明）次に、旅費管理サーバ１０
が申請処理のために保持する各種データベースについて
説明する。

【００２６】先ず、申請情報データベース（申請情報Ｄ
Ｂ）１３には、旅費申請の内容とその認可・精算状況と
を示す申請情報が納められる。図４は、上記申請情報デ
ータベース１３に納められる申請情報の構成と内容の一
部とを表形式で示す図である。申請情報は、申請番号欄
４１０、申請者欄４２０、責任者欄４３０、許可フラグ
欄４４０、出張精算データ欄４５０、交通費データ欄４
６０とから成る。

【００２７】申請番号欄４１０には、申請ごとに旅費管
理サーバ１０が付加する固有の通し番号が格納される。
申請者欄４２０、責任者欄４３０には、それぞれ申請者
名、責任者名が格納される。認可フラグ欄４４０には、
当該申請について責任者が認可をしたかどうかを示すフ
ラグ（１：認可済み、０：未認可）が格納される。出張
精算データ欄４５０には、申請者が申請書３００の出張
情報入力部３１０（図２参照）に入力した出張内容の詳
細が格納されるのに加え、当該申請について管理部門に
よる精算が完了したかどうかを示す精算フラグが格納さ
れる。

【００２８】出張精算データ欄４５０は、出張目的の情
報が格納される目的欄４５１、行き先の情報が格納され
る行先欄４５２、出張の出発日、帰着日の情報がそれぞ
れ格納される出発日欄４５３、帰着日欄４５４、出張に
伴なう精算金額の情報が格納される精算金額欄４５５、
精算フラグが格納される精算フラグ欄４５６から成る。

【００２９】交通費データ欄４６０には、申請者が申請
書３００の旅費情報入力部３２０（図２参照）に入力し
た出張旅費の詳細に関する情報が格納される。交通費デ
ータ欄４６０は、利用された交通機関の名称が格納され
る交通機関欄４６１、当該交通機関によってどこからど
こまで移動したかを示す情報が格納される乗車地欄４６
２、降車地欄４６３、どのタイプの座席を利用したかを
示す情報が格納される座席種別欄４６４、利用した日付
が格納される利用日欄４６５、支払った運賃が格納され
る運賃欄４６６を有する。

【００３０】さらに、このうち運賃欄４６６には、申請
者がみずから手入力した値（正しい値かどうか検証され
ていない値）が格納される場合と、運賃データベース１
４に保持される検証済み運賃情報が転記される場合とが
ある。そこで交通費データ欄４６０は、この手入力と転
記との区別を示すフラグが格納される転記区分欄４６７
を更に含む。なお、転記区分を示す情報が運賃情報に対
してだけ設けられているのは、ここで転記可能な情報が
運賃情報に限られるからである。運賃以外の項目で転記
可能な項目があれば、各項目ごとに転記区分を示す情報
を格納する欄が設けられることになる。

【００３１】ここで、図４に示す具体的な申請情報の内
容を見てみる。先ず、申請情報４０１は、ＩＤ「mori」
を有する申請者が申請したものであって、ＩＤ「tanak
a」を有する責任者による認可が下りて精算も完了して
いる（認可フラグ欄４４０、精算フラグ欄４５６を参
照）。つまり、上述の申請処理手順（１）〜（３）が全
て完了した申請に関する申請情報である。

【００３２】申請データ４０２は、ＩＤ「horikawa」を
有する申請者が申請したものであるが認可が下りておら
ず、精算も終っていない（認可フラグ欄４４０、精算フ
ラグ欄４５６を参照）。つまり、上述の申請処理手順
（１）が完了し、（２）の開始を待っている状態の申請
に関する申請情報である。次に、各種交通機関について
検証済みの運賃情報を納めた運賃データベース１４に納
められた運賃情報について説明する。

【００３３】図５は、運賃データベース１４に格納され
た運賃情報の構成と内容の一部とを表形式で示す図であ
る。運賃データベース１４に格納された運賃情報は、申
請手順（１）において申請者からの要求に応じて検索さ
れ、申請者がデータ入力中の申請書３００に転記され
る。運賃情報は、交通機関欄５１０、乗車地欄５２０、
降車地欄５３０、座席区分欄５４０、運賃欄５５０から
なり、交通機関欄５１０で示す交通機関を用いて、乗車
地欄５２０で示す地点から降車地欄５３０で示す地点ま
で、座席区分欄５４０で示す座席を利用して移動した場
合の運賃を、運賃欄５５０に示す、というものである。

【００３４】例えば、図５に示す運賃データ５０１は、
「新幹線」を使って「東京」から「京都」まで「指定」
席で移動した場合の運賃が「１３２２０円」であること
を示す。次に、責任者情報データベース１４に納められ
た、旅費申請者と当該申請者による申請に許可を与える
責任者との対応関係を示す責任者情報について説明す
る。

【００３５】図６は、責任者情報の構成と内容の一部と
を示す図である。責任者情報は、大きく申請者情報欄６
１０と責任者情報欄６２０とに分かれる。申請者情報欄
６１０には、出張旅費申請を行う申請者の情報が、責任
者情報欄６２０には、当該申請者について申請を許可す
る責任者の情報が格納される。申請者欄６１０は、さら
に氏名欄６１１、ＩＤ欄６１２とに分かれ、申請者名と
これに対応する申請者ＩＤとが格納される。責任者欄６
２０も同様に、氏名欄６２１、ＩＤ欄６２２とに分かれ
ている。申請者ＩＤ、責任者ＩＤは、それぞれ、申請処
理、申請許可処理において、申請者、責任者が用いるパ
スワードである。

【００３６】なお、責任者情報データベース６００内の
情報は、予め管理者によって入力されたものであり、申
請処理に伴なって内容が変化することはない。（動作）次に、旅費申請システム１の動作について、図
面を参照しながら説明する。ここで申請の対象となる出
張の内容は、申請者（氏名：堀川一郎、ＩＤ：horikaw
a）が、販売促進打ち合わせを目的として、２０００年
９月１日に東京から京都市内の二条城近くの営業所へ、
新幹線及び（京都）市バスを使用して行った日帰り出張
である。

【００３７】図７は、申請者が申請書３００にデータを
入力して旅費管理サーバ１０に送信するまでの処理（上
述の旅費申請手順（１））における旅費申請システム１
の動作を示すフローチャートである。まず、申請者によ
って起動された申請者端末２０が、申請者から申請処理
開始指示の入力（旅費管理サーバ１０のＵＲＬと申請者
のユーザＩＤ「horikawa」の入力）を受け付けて旅費管
理サーバ１０と通信を確立し、前記ユーザＩＤを旅費管
理サーバ１０に送信する（Ｓ７０１：Yes）。

【００３８】旅費管理サーバ１０側では、ＷＷＷサーバ
１１が受信したユーザＩＤを条件とした検索用ＳＱＬ文
を生成する。そして、ＤＢ管理部１２がこれを用いて責
任者情報データベース１５を検索して、当該ユーザＩＤ
に関する責任者情報が存在するかどうか（有効な申請者
かどうか）チェックし、当該ユーザＩＤに対応する申請
者名（「堀川一郎」）を得てＷＷＷサーバ１１に返す。
ここで、ＷＷＷサーバ１１は、この申請者名を、内蔵メ
モリ（図示せず）から読み出した申請書３００用フォー
ムおよび運賃転記要求用スクリプト、申請情報追加用ス
クリプトとともに、ＨＴＭＬ文書形式で申請者端末２０
に送信する。そして、申請者端末２０は、受信した申請
書３００用フォームをもとに、申請書３００をディスプ
レイに表示する（Ｓ７０２）。

【００３９】図８は、この時点での申請書３００の内容
を示す図である。通し番号欄３０１に通し番号「００
３」が、申請者名欄３１１に申請者名「堀川一郎」が表
示されているほかは空欄である。ここで、申請者端末２
０は、申請者から出張情報入力部３１０への出張情報の
入力を受け付ける。具体的には、行先欄３１２に「京都
二条城前」を、目的欄３１３に「販売促進打ち合わ
せ」を、出発日欄３１４に「2000.9.1」を、帰着日欄３
１５に「2000.9.1」という内容である（Ｓ７０３）。

【００４０】そして、旅費情報入力部３２０のうち、利
用年月日欄３２１、交通機関欄３２２、乗車地欄３２
３、降車地欄３２４、座席種別欄３２５に申請者の入力
を受け付けた時点で、申請者端末２０は、運賃データの
転記要求が受け付け可能となる。図９（ａ）は、申請者
からの上記の情報入力を受け付けた時点での申請書３０
０の内容を示す図である。

【００４１】ここで、申請者が運賃転記ボタン３４０を
クリックして運賃転記を要求すると（Ｓ７０４：Ye
s）、申請者端末２０は、転記要求とともに旅費情報入
力部３２０への入力情報（「交通機関＝新幹線」、「乗
車地＝東京」、「降車地＝京都」、「座席区分＝指
定」）を旅費管理サーバ１０に送信する。これに対し、
旅費管理サーバ１０側では、転記要求を受信したＷＷＷ
サーバ１１が、併せて受信した前記入力データを条件に
した検索用ＳＱＬ文を生成して、ＤＢ管理部１２に送
り、運賃データベース１４を検索させる（Ｓ７０５）。
図５に示すように、運賃データベース１４内の運賃情報
の中には、「新幹線」、「東京」、「京都」、「指定」
に対応する運賃情報５０１が存在するので（Ｓ７０６：
Yes）、当該運賃情報における運賃欄５５０の値「１３
２２０」が検索結果として得られる。この「１３２２
０」という値はＷＷＷサーバ１１経由で申請者端末２０
に送信される。申請者端末２０は、この運賃「１３２２
０」を転記した形で申請書３００を再表示する（Ｓ７０
７）。

【００４２】図９（ｂ）は、運賃情報の転記が完了した
段階での申請書３００の状態を示す図である。空欄だっ
た運賃欄３２６に「１３２２０」円という転記データが
表示されている。続いて、申請者端末２０は、申請者か
ら２件目の旅費情報を旅費情報入力部３２０に受け付け
る。

【００４３】図１０（ａ）は、２件目の旅費情報を受け
付けた状態の申請書３００を示す。具体的には、利用年
月日欄３２１に「2000.9.1」、交通機関欄３２２に「京
都市バス」、乗車地欄３２３に「京都」、降車地欄３２
４に「二条城前」、座席種別欄３２５に「普通」という
内容である。ここで、申請者による転記要求ボタン３４
０のクリックを受付けることで、この２件目の旅費情報
も上記の１件目と同様、旅費管理サーバ１０に送信さ
れ、運賃情報の検索が行われるが（Ｓ７０５）、運賃デ
ータベース１４内には、「京都市バス」の運賃情報は格
納されていない。そのため、旅費管理サーバ１０から申
請者端末２０への応答は、「データなし」となる（Ｓ７
０６：No）。

【００４４】申請者端末２０は、「データなし」の応答
を受けた場合、入出力部が予め保持している、申請者に
旅費の手入力を促すメッセージを申請書３００に表示す
る（Ｓ７０８）。図１０（ｂ）は、転記すべきデータが
ない旨のメッセージ５１０が表示された申請書３００を
示す。これに対して申請者は、過去の出張記録を参照す
るか、別途資料を調べるなどして、「京都市バス」の運
賃「２２０」円を得て申請書３００に手入力する（Ｓ７
０９）。

【００４５】さらに、申請者からの旅費情報入力（３件
目の情報として京都市バス、４件目の情報として新幹
線）と転記要求とを受け付け、上記の手順と同様に運賃
情報の検索、転記を繰り返す（ステップＳ７０４〜Ｓ７
０９）。図１１は、申請者が全ての旅費情報を入力し終
えた時点での（Ｓ７１１：Yes）、申請書３００の内容
を示す図である。全項目に情報の入力が完成している。
なお、表示はされていないが、申請者端末２０（入出力
部２１）は、入力された旅費情報の各々について、それ
が転記されたか手入力されたかを示す情報を記憶してい
る。この情報は、申請情報の転記区分欄４６７に格納さ
れる情報で、転記ならば「１」、手入力なら「０」の値
となるフラグである。フラグは入出力部２１が管理し、
旅費情報が１件入力されるたびに初期状態「０」で生成
する。そして、入出力部２１は、当該旅費情報に対して
申請者が転記要求を行い、しかもそれに対して運賃デー
タが旅費管理サーバ１０から送信されてきた場合にの
み、フラグの値を「１」に書き換える（Ｓ７１０）。

【００４６】図１１の状態から、申請者が送信ボタン３
３０をクリックするのを受けて、申請者端末２０は、図
１１に示す申請書３００への入力内容に「転記区分情
報」を加えた内容を、申請情報登録の要求とともに旅費
管理サーバ１０に送信する。旅費管理サーバ１０側で
は、受け付けた申請書入力内容（各旅費の転記区分情報
も含む）を申請情報として追加するＳＱＬ文を生成して
ＤＢ管理部１２に渡し、申請情報データベース１３への
申請情報追加を行わせる。（Ｓ７１２）。

【００４７】こうして申請情報データベース１３に追加
された申請情報は、図４の申請情報４０２のようにな
る。申請者が入力した情報が格納されているとともに、
転記区分欄４６７には申請者端末２０が設定した転記区
分の情報が格納されている。そして、認可フラグ欄４４
０と精算フラグ欄４５６とが空欄となっている。（認可処理時の動作）次いで、申請者が行った申請に対
する申請責任者の検証・認可の手順（旅費申請手順
（２））を実行する際の旅費申請システム１の動作を、
図面に従って説明する。

【００４８】図１２は、責任者による申請の認可作業に
おける旅費申請システム１の動作の流れを示すフローチ
ャートである。この処理に関係するのは旅費管理サーバ
１０および責任者端末３０である。先ず、責任者端末３
０は、責任者から認可処理開始指示の入力（旅費管理サ
ーバ１０のＵＲＬと責任者のユーザＩＤ「suzuki1」の
入力）を受け付けて旅費管理サーバ１０と通信を確立
し、前記ユーザＩＤを旅費管理サーバ１０に送信する
（Ｓ１２０１）。

【００４９】旅費管理サーバ１０のＷＷＷサーバ１１
は、この要求を受け付けると、先ずユーザＩＤを条件に
した検索用ＳＱＬ文を生成してＤＢ管理部１２に渡し、
責任者情報データベース１５（図６参照）を検索させ
て、当該ＩＤに対応する責任者名および当該責任者が認
可を担当する申請者のユーザＩＤを得る。次いで、ＷＷ
Ｗサーバ１１は、前記の申請者ユーザＩＤを条件に申請
情報データベース１３から当該申請者に関する未認可の
申請情報（申請者欄４２０のＩＤが一致し、認可フラグ
欄４４０の値が「０」のもの）を検索するＳＱＬ文を生
成、ＤＢ管理部１２に渡して検索を実行させて、当該責
任者が認可すべき未認可の申請情報を得る（Ｓ１２０
２：Yes）。その後、ＷＷＷサーバ１１は、１件の未認
可申請情報、および認可処理用の申請書３００のフォー
ム、申請データ認可処理用スクリプトをＨＴＭＬ文書形
式で管理部門端末４０に送信する（Ｓ１２０３）。

【００５０】責任者端末３０は、この未認可申請情報の
内容を示す申請書３００をディスプレイに表示する。図
１３は、検証・認可処理の対象となる未認可申請情報が
表示された申請書３００を示す図である。認可ボタン３
６０が設けられているとともに、旅費情報入力部３２０
の運賃欄３２６に表示された運賃情報のうち、運賃デー
タベース１４からの転記によって設定されたものに転記
マーク７００が付加されて表示されている。

【００５１】すなわち、運賃データベース１４内の運賃
情報が転記された旅費情報、すなわち、往路・復路の新
幹線運賃の箇所には運賃データベース１４から転記され
た検証済みデータであることを示す転記マーク７００
（「●」）が表示され、申請者が手入力した運賃情報
（京都市バス）は、他の入力項目（交通機関名、乗車
地、降車地など）と同様、転記マークなしで表示されて
いる。こうした転記マーク７００は、旅費管理サーバ１
０側で、図１３の申請書３００表示用ＨＴＭＬ文書を生
成・送信する段階でＨＴＭＬ文書内に設定しておいた転
記マーク表示の命令（「申請情報の転記区分欄４６７の
値が「１」の場合は対応する旅費情報の箇所（賃金情
報）に転記マーク７００を付加して、表示用申請書３０
０を生成する」という内容）に従って、責任者端末３０
側の入出力部３１が表示させるものである。

【００５２】責任者は、この転記マーク７００によっ
て、当該旅費情報に含まれる運賃情報が検証済みのデー
タベースから転記されたもので検証を要しないか、申請
者が手入力したもので入念な検証を要するか一目瞭然に
判別できる。責任者は、転記マーク７００が付加されて
いない情報（特に、運賃情報）についてのみ検証を行
い、検証を終えると認可ボタン３６０をクリックする。
すると、責任者端末３０は、当該申請情報の通し番号
（申請番号欄４１０の内容）および責任者ＩＤとともに
認可完了の通知を旅費管理サーバ１０に送信する（Ｓ１
２０４：Yes）。

【００５３】旅費管理サーバ１０は、前記送信内容をか
ら申請情報更新用のＳＱＬ文（「通し番号に対応する申
請情報について、認可フラグ欄４４０に「１」を、責任
者欄４３０に責任者ＩＤを格納する」という内容）を生
成して、データベース管理部１２に転送し、申請情報の
更新を行わせる（Ｓ１２０５）。以上のステップＳ１２
０３〜Ｓ１２０５の処理は、当該責任者が担当する申請
者に関わる申請情報に未認可のものがなくなるまで繰り
返される（Ｓ１２０２：No）。（精算処理時の動作）次いで、責任者が認可した申請情
報に基づく経理担当者の精算（旅費申請手順（３））が
実行される際の旅費申請システム１の動作を、図面に従
って説明する。

【００５４】図１４は、経理担当者による旅費精算作業
における旅費申請システム１の動作の流れを示すフロー
チャートである。この処理に関係するのは旅費管理サー
バ１０および管理部門端末４０である。先ず、経理担当
者からの指示に従い、管理部門端末４０のＷＷＷブラウ
ザ４２が起動して、旅費管理サーバ１０に接続し、未精
算の申請情報の検索要求を送信する（Ｓ１４０１）。

【００５５】旅費管理サーバ１０のＷＷＷサーバ１１
は、この要求を受け付けると、申請情報データベース１
３内の申請情報のうち、認可フラグ欄４４０の内容が
「１」であり、しかも精算フラグ欄４５６の値が「０」
である申請情報を検索するＳＱＬ文を生成し、ＤＢ管理
部１２に転送する。ＤＢ管理部１２は前記ＳＱＬ文によ
る検索を実行して、該当する申請情報を検索し、ＷＷＷ
サーバ１１に送出する（Ｓ１４０２：Yes）。ＷＷＷサ
ーバ１１は当該申請情報を、精算確認用スクリプトのＨ
ＴＭＬ文とともに管理部門端末４０に送信する（Ｓ１４
０３）。

【００５６】管理部門端末４０は、この未精算申請情報
の内容を示す申請書３００をディスプレイに表示し、経
理担当者はその内容に基づいて、銀行口座への旅費振り
込みなどの精算処理を行う。図１５は、管理部門端末４
０に表示される申請書３００の内容である。責任者名欄
３１６と精算確認を通知するための確認ボタン３７０と
が追加されており、経理担当者は申請者とともに当該申
請を認可した責任者についても確認できるようになって
いる。

【００５７】この認可済み未精算申請の内容を確認し、
精算処理を行った経理担当者は、確認ボタン３７０をク
リックする。すると、管理部門端末４０は、当該申請情
報の通し番号（当該申請情報の申請番号欄４１０の内
容）と精算確認通知とをデータ旅費管理サーバ１０に送
信する（Ｓ１４０４：Yes）。旅費管理サーバ１０側で
は、ＷＷＷサーバ１１が受信した申請の通し番号に該当
する申請情報について精算済みフラグ欄４５６の値を
「１」に設定し、精算金額欄４５５に当該申請情報の運
賃欄４６６の金額の合計値を格納する旨の更新用ＳＱＬ
文を生成してＤＢ管理部１２に送り、申請情報の更新を
実行させる（Ｓ１４０５）。

【００５８】上記のステップＳ１４０３〜Ｓ１４０５の
処理は、認可済み未精算の申請情報がなくなるまで繰り
返される（Ｓ１４０２：No）。上記の通り、本実施の形
態の旅費申請システム１では、責任者が申請情報の内容
を検証する際、申請情報中の各項目の情報、特に運賃情
報について、運賃データベースから転記されたものか申
請者が入力したものか、転記マークによって一目瞭然に
識別できるので、運賃が正しいか否かを検証するための
責任者の労力を軽減することができ、しかも検証の必要
な情報に対する検証がもれるといった事態も防止でき
る。

【００５９】なお、旅費精算システムを例にとって説明
したが、他の同種システムすなわち、申請者が入力した
データを検証してその後当該データを利用するシステム
において、申請のたびに必ず入力される情報をデータベ
ースに納めて転記する処理を行う場合は、同様の効果を
発揮する。例えば、文房具などの所定の備品を定期的に
購入する際の購入申請の場合、品名を入力するだけで、
数量、単価などが転記される、というものが考えられ
る。

【００６０】また、本実施の形態では、転記された運賃
情報に転記マークを付加することで、転記情報とそうで
ない情報とを区別しているが、区別のための手法はマー
クの付加に限定されない。例えば、字体を変える（例：
手入力情報は斜体）、あるいは色を変える（例：手入力
情報は赤色表示）などしてもよい。また、本実施の形態
では、交通機関、乗車地、降車地、座席種別をキーに検
索した運賃情報を転記することとしているが、転記の対
象となる情報およびそれを検索するキーはこれに限定さ
れない。例えば、出張の目的および行先に応じて、使用
する交通機関や利用経路が決まっている場合は、行先欄
のみ入力した上で運賃転記ボタンをクリックすると、旅
費情報入力部３２０の内容がすべて転記される、といっ
た形も考えられる。さらには、検索条件についても、必
ずしも申請情報の項目を条件とする必要はない。例え
ば、申請要求時、出張パターン（例えば「京都・日帰
り」）を申請者に入力させ、これにキーにして対応する
申請情報の内容（「行く先」、使用交通機関および運
賃）をデータベースから読み出し、申請情報に転記する
という形もありうる。この場合、検索キーである出張パ
ターンは申請情報以外の情報である。（変形例）以下に示す本変形例における旅費申請システ
ム１は、いったん転記されたデータに申請者が誤りを見
つけて修正した、あるいは、転記データのうえに申請者
が誤って別の値を上書きした、などの原因で「転記後修
正」という区分のデータが発生した場合に対応するもの
である。すなわち、情報の区分を「手入力」、「転
記」、「転記後修正」の３つの分けた申請情報を生成
し、責任者端末３０および管理部門端末４０に申請情報
を表示する際も、３つの区分に応じて表示するものであ
る。

【００６１】図１６は、申請者が申請書３００上で行う
運賃情報の転記後修正の概要を示す図である。同図
（ａ）の申請書３００では、転記後の運賃データ１６０
０（「地下鉄」の「運賃」、２００円）が誤っていると
する。これを申請者が手入力で修正した結果が同図
（ｂ）となる。運賃欄４６７の内容は転記された値「２
００」から「２３０」に書き換えられている。

【００６２】図１７は、図１６の申請書を元に生成され
た申請情報１７００の内容を示す図である。転記区分欄
４６７には、上記実施の形態における転記区分「０」、
「１」とは異なる、「２」（転記後変更の場合）が追加
されている。この場合の内部的な処理は、おおよそ以下
の通りである。すなわち、申請者端末２０の入出力部２
１が転記データについて、修正の有無を示す情報（フラ
グなど）を保持しておき、申請者による書き換えを受け
付けた時点で当該情報の内容を「修正」を表すものに更
新する。そして、旅費管理サーバ１０の側では、この情
報を元に「転記後修正」の情報を認識し、転記区分欄４
６７に「２」の値を設定する。

【００６３】このように転記区分が３種類となること
で、責任者による認可、経理担当者による精算の際に責
任者端末３０、管理部門端末４０に表示される際の申請
書３００の表示内容（転記マーク）も変わってくる。図
１８は、本変形例において責任者端末３０のディスプレ
イに表示される申請書３００を示す図である。転記を示
す「●」とは異なる転記マーク、すなわち、転記後修正
を示す「△」が表示されている。これは、転記区分
「２」に対応しており、責任者端末３０の入出力部３１
によって表示されたものである。

【００６４】責任者は、転記マーク１８００によって運
賃情報の３種類の区分を認識でき、検証の必要な「手入
力（無印）」、「転記後修正（△）」の情報のみ検証す
る。このように、本変形例によれば、運賃データベース
１４の内容に何らかの誤りがあるなどして、転記データ
が修正された場合でも、責任者がこれを認識でき、転記
後修正されたデータが検証の対象からもれることはな
い。

【００６５】

【発明の効果】以上の説明から明らかなように、本発明
の申請処理システムは、申請者からの指示に応じて複数
の項目データから成る申請データを生成し、責任者によ
る当該申請データの検証を支援する申請処理システムで
あって、予め正当性を検証された検証済みデータを保持
する保持手段と、申請者からの指示に従って前記保持手
段が保持する検証済みデータを転記することで前記申請
データ中に転記項目データを設定する転記手段と、申請
者が入力した入力データを前記申請データ中に手入力項
目データとして設定する入力受付手段と、前記申請デー
タ中に設定された項目データの各々について、転記項目
データであるか手入力項目データであるかの区別を表す
識別情報を付加する付加手段と、申請データを責任者に
提示する際、前記識別情報に応じ、前記転記項目データ
と前記手入力項目データとを異なる形式で提示する提示
手段とを有することを特徴とする。これによって、申請
の検証・認可を行う責任者は、個々のデータ項目につい
て提示の形式から検証を要するか否かを容易に知ること
ができるので、その検証の作業負荷は軽減され、検証の
必要な項目に対する検証もれも発生しない。

【００６６】また、上述の効果は、前記転記手段が、前
記申請データに設定された項目データの値を検索キーと
して前記保持手段が保持する検証済みデータを検索し、
検索結果の検証済みデータを転記して転記項目データを
設定すること、という特徴を有する申請処理システムに
おいても得られる。また、前記転記手段は、申請者から
検索条件を受け付ける条件受付手段を更に有し、前記条
件受付手段が受け付けた検索条件を検索キーとして前記
保持手段が保持する検証済みデータを検索し、検索結果
の検証済みデータを転記して転記項目データを設定する
こと、としてもよく、それによって、申請データ内の項
目データ以外の値を条件とした、検証済みデータの検
索、転記項目データの生成も可能となる。

【００６７】また、前記転記項目データに対する申請者
の更新指示を受け付けて転記項目データの値を更新する
更新手段を更に有し、前記付加手段は、前記更新手段に
よって更新された転記項目データに対し転記項目データ
および手入力項目データとは異なる固有の識別情報を付
加し、前記提示手段は、前記識別情報に応じ、前記更新
手段によって更新された転記項目データを、前記転記項
目データおよび前記手入力項目データとは異なる形式で
提示すること、とすることもできる。これによって、転
記されたデータが何らかの原因で書き換えられた場合に
ついても、責任者が正しく認識できるので、転記後書き
換えられたデータに対する検証もれを防止できる。

【００６８】また、前記申請データは交通費の申請のた
めのものであり、前記保持手段が保持する検証済みデー
タは、交通機関の運賃データであること、とすることも
できる。これによって、会社において出張などで発生す
る旅費の申請・認可の手続きにおいて、認可責任者の検
証処理の負担を軽くできるとともに、検証漏れも防止で
きる。

【図面の簡単な説明】

【図１】本発明に関わる申請処理システムの実施の形態
における構成を示す図である。

【図２】同実施の形態において旅費申請処理に用いられ
る申請書の初期状態と責任者による検証時点での状態と
を示す図である。

【図３】同実施の形態において端末内のWWWブラウザと
旅費管理サーバ内のＷＷＷサーバ１１及びＤＢ管理部と
の間で行われる要求、データのやり取りの概要を示す図
である。

【図４】同実施の形態における申請情報の構成と内容の
一部とを表形式で示す図である。

【図５】同実施の形態における運賃情報の構成と内容の
一部とを表形式で示す図である。

【図６】同実施の形態における責任者情報の構成と内容
の一部とを示す図である。

【図７】同実施の形態における旅費申請情報生成の際の
旅費申請システムの動作を示すフローチャートである。

【図８】同実施の形態における申請書の初期状態での内
容を示す図である。

【図９】同実施の形態において、運賃情報の転記が行わ
れる前後の申請書の内容を示す図である。

【図１０】同実施の形態において、運賃情報の転記が実
行できなかった場合の申請書の内容を示す図である。

【図１１】同実施の形態において、申請者が全ての旅費
情報を入力し終えた時点での申請書３００の内容を示す
図である。

【図１２】同実施の形態において、責任者による認可作
業実行時の旅費申請システムの動作を示すフローチャー
トである。

【図１３】同実施の形態において、検証・認可処理の対
象となる申請情報が表示された申請書を示す図である。

【図１４】同実施の形態において、旅費精算作業実行の
際の旅費申請システムの動作を示すフローチャートであ
る。

【図１５】同実施の形態において、管理部門端末に表示
される申請書の内容を示すである。

【図１６】同実施の形態の変形例において、申請者によ
る転記情報の更新が行われる前後の申請書を示す図であ
る。

【図１７】同変形例において、責任者端末に表示される
認可処理対象の申請書を示す図である。

【図１８】同変形例において、申請者による転記情報の
更新が行われた申請情報の内容を示す図である。

【符号の説明】

１旅費申請システム１０旅費管理サーバ１１ＷＷＷサーバ１２データベース管理部１３申請情報データベース１４運賃データベース１５責任者情報データベース２０申請者端末３０責任者端末４０管理部門端末３００申請書７００，１８００転記マーク

Claims

【特許請求の範囲】

【請求項１】申請者からの指示に応じて複数の項目デ
ータから成る申請データを生成し、責任者による当該申
請データの検証を支援する申請処理システムであって、予め正当性を検証された検証済みデータを保持する保持
手段と、申請者からの指示に従って前記保持手段が保持する検証
済みデータを転記することで前記申請データ中に転記項
目データを設定する転記手段と、申請者が入力した入力データを前記申請データ中に手入
力項目データとして設定する入力受付手段と、前記申請データ中に設定された項目データの各々につい
て、転記項目データであるか手入力項目データであるか
の区別を表す識別情報を付加する付加手段と、申請データを責任者に提示する際、前記識別情報に応
じ、前記転記項目データと前記手入力項目データとを異
なる形式で提示する提示手段とを有することを特徴とす
る申請処理システム。
【請求項２】前記転記手段は、前記申請データに設定
された項目データの値を検索キーとして前記保持手段が
保持する検証済みデータを検索し、検索結果の検証済み
データを転記して転記項目データを設定すること、を特徴とする請求項１に記載の申請処理システム。
【請求項３】前記転記手段は、申請者から検索条件を
受け付ける条件受付手段を更に有し、前記条件受付手段
が受け付けた検索条件を検索キーとして前記保持手段が
保持する検証済みデータを検索し、検索結果の検証済み
データを転記して転記項目データを設定すること、を特徴とする請求項１に記載の申請処理システム。
【請求項４】前記転記項目データに対する申請者の更
新指示を受け付けて転記項目データの値を更新する更新
手段を更に有し、前記付加手段は、前記更新手段によって更新された転記
項目データに対し転記項目データおよび手入力項目デー
タとは異なる固有の識別情報を付加し、前記提示手段は、前記識別情報に応じ、前記更新手段に
よって更新された転記項目データを、前記転記項目デー
タおよび前記手入力項目データとは異なる形式で提示す
ること、を特徴とする請求項１乃至３のいずれかに記載の申請処
理システム。
【請求項５】前記申請データは交通費の申請のための
ものであり、前記保持手段が保持する検証済みデータは、交通機関の
運賃データであること、を特徴とする請求項１乃至４のいずれかに記載の申請処
理システム。
【請求項６】申請者からの指示に応じて複数の項目デ
ータから成る申請データを生成し、責任者による当該申
請データの検証を支援する申請処理方法であって、予め正当性を検証された検証済みデータを保持する保持
ステップと、申請者からの指示に従って前記検証済みデータを転記す
ることで前記申請データ中に転記項目データを設定する
転記ステップと、申請者が入力した入力データを前記申請データ中に手入
力項目データとして設定する入力受付ステップと、前記申請データ中に設定された項目データの各々につい
て、転記項目データであるか手入力項目データであるか
の区別を表す識別情報を付加する付加ステップと、前記識別情報に応じ、前記転記項目データと前記手入力
項目データとを異なる形式で責任者に提示する提示ステ
ップとを有することを特徴とする申請処理方法。
【請求項７】申請者からの指示に応じて複数の項目デ
ータから成る申請データを生成し、責任者による当該申
請データの検証を支援する申請処理システムに用いられ
るプログラムを記録したコンピュータ読み取り可能な記
録媒体であって、前記プログラムは、予め正当性を検証された検証済みデータを保持する保持
ステップと、申請者からの指示に従って前記検証済みデータを転記す
ることで前記申請データ中に転記項目データを設定する
転記ステップと、申請者が入力した入力データを前記申請データ中に手入
力項目データとして設定する入力受付ステップと、前記申請データ中に設定された項目データの各々につい
て、転記項目データであるか手入力項目データであるか
の区別を表す識別情報を付加する付加ステップと、前記識別情報に応じ、前記転記項目データと前記手入力
項目データとを異なる形式で責任者に提示する提示ステ
ップとを含むことを特徴とするコンピュータ読み取り可
能な記録媒体。