JP2010134561A - 業務文書処理装置 - Google Patents

Abstract

【課題】証憑記載内容の不備が生じないよう、十分に確認を行って証憑を作成・管理を行う。
【解決手段】証憑に対して論理構造解析を行って記載内容の解析を行い、内部統制で用意されたＲＣＭ（リスクコントロールマトリックス）に従って、証憑記載項目が定められた関係を満たしているか、および、一連の業務で発生する証憑について定められた関係を満たしているか確認し、警告表示および修正入力を受付けることを特徴とする。
【選択図】図１

Description

本発明は、業務文書の記載内容を確認処理し、データベースに登録する業務文書処理装置に関し、例えば、文書の論理構造解析を利用した業務文書の登録・確認に関するものである。

日本版ＳＯＸ法（金融商品取引法）の施行に伴い、企業の営業活動における証憑の取扱いに関心が高まっている。これに対し、特に企業における営業証憑は下記の二つの理由から不定型の紙文書が現在でも多く用いられており、管理上の課題となっている。

まず一つ目の理由は、営業証憑のうち社外取引先（顧客・提携先・発注先など）とやり取りするものについては、取引先で定義された形式に合わせて証憑を作成しなくてはならない場合があるからである。このため、定型業務であっても固定帳票を用いることができない場合が残り、電子化・自動化しきれない。

二つ目の理由は、証憑のうち企業内の管理部門への申請などに用いる文書は、法制度・ビジネス環境の変化・経営方針などに応じて、新設・統廃合・形式の変更の必要が生じるためである。このため、形式の変更が頻発してしまい、電子化・自動化がなかなか進まない。

一方で、内部統制においては証憑記載内容の正確性および証憑の適切な保存が重要である。証憑記載内容の不備が生じないよう、下記に列挙するような項目（ＲＣＭ（Risk Control Matrix））について十分に確認を行って証憑を作成・管理する必要がある。

確認項目例１：取引額が顧客に対して設定した与信限度額内であるか。
確認項目例２：取引間隔に応じた与信限度額の再設定が行われているか。
確認項目例３：取引金額や種別ごとに規定された職位以上の決裁を得ているか。
確認項目例４：証憑の作成日付より保管日付の方が先になっていないか。
確認項目例５：確認項目例４とは逆に、証憑の作成日付から保管日付まで期間があきすぎていないか。
確認項目例６：見積書・注文書・注文請書・納品書・検収書・請求書・領収書などの間で企業名・金額・納品期日・納品条件・検収期日・支払期日・支払条件などが合致しているか。
確認項目例７：発注書や納品書作成部署と入金や出金手続き部署は異なるか。
確認項目例８：証憑の作成日付は業務フローに定められた順序に沿っているか。

ところが、紙文書を用いた業務処理においてはユーザの目視確認に頼らざるを得ない。ヒューマンエラーやユーザの認識不徹底に由来する管理不測が原因で監査時に証憑の不備が指摘されたり、内部統制に問題があると指摘されたりするリスクがある。

また、当初一件の見積書だった案件がその後の様々な事情により分割受注案件になったり、ＦＡＸで先に内容の確認を行い後日正式な証憑を受領したりする等、証憑の扱いが変則的になる場合がある。そのような場合は後日理由（変則的になった理由）を説明できるようにしておかなくてはならないが、これを怠っていると監査時には担当者の記憶があいまいになってしまい、確認工数を増大させる一因となる。

そこで、企業内の文書を管理するシステムとして、非特許文献１乃至４に示されるようなものが考え出されている。

また、証憑の内容を確認するためには、紙文書のスキャン画像に対して論理構造解析を行い、どのような項目に対してどのような値が記載されているのか自動的に抽出を行う必要があるが、このような技術としては特許文献１乃至３に示されるようなものある。

Documentum（ECMジャパン株式会社）http://japan.emc.com/products/family/documentum-family.htm ：DocumentBroker（株式会社日立製作所）http://www.hitachi.co.jp/Prod/comp/soft1/docbro/ Ridoc（株式会社リコー）http://www.ricoh.co.jp/ridoc_ds/rds/ FileNet（日本アイ・ビー・エム株式会社）http://www.ibm.com/developerworks/jp/ysl/library/db2/y-db2-filenetp8-1/ 特願平７−３４１９８３号公報 特願平１０−６４４３１号公報 特願２０００−１６３７８４号公報

しかし、非特許文献１乃至４に示された何れのシステムも文書をただ保管するだけに留まり、文書中に記載された内容の解釈、意味の入力については何も処理を行わないものである。したがって、内容についての処理は全てユーザが行わなくてはならず、煩雑さの点については目視による確認と何ら変わりがない。

また、特許文献１乃至３に示された何れの技術も応用としては文書の整理や検索性向上に留まっているため、意味を踏まえた処理や判断は全てユーザが行わなくてはならない。

本発明はこのような状況に鑑みてなされたものであり、ユーザの目視に頼らずに自動で業務文書の記載内容を確認することができる業務文書処理装置を提供するものである。

上記課題を解決するために、発明者らは、企業内で発生する証憑の種類は限定的であること、記載項目は証憑ごとに固定的であること、内部統制で用意された確認項目データ（例えば、ＲＣＭ（リスクコントロールマトリックス））にその企業において発生する証憑について定められた関係が整理・記載されていることに着目した。特に、ＲＣＭに記載される証憑についての関係は、単一の証憑の記載項目に関するもの（上記の確認項目例１〜５）と、一連の業務で発生する証憑の間での記載項目に関するもの（上記の確認項目例６〜８）に大別することができる。

つまり、本発明による業務文書処理装置は、入力された業務文書の構造を解析し、複数の記載項目によって構成される論理構造データを生成する入力文書解析部と、業務文書の確認項目事項データであって、入力された業務文書の前記論理構造データに含まれる文書種別データに対応する確認項目データを、確認項目データを格納するデータベースから取得する確認項目データ取得部と、入力された業務文書の論理構造データと確認項目データ取得部によって取得された確認項目データとを比較して、入力された業務文書の記載内容を確認する記載項目確認処理部と、記載項目確認処理部が入力された業務文書の論理構造データに不適合記載を確認した場合には、警告表示を行う警告表示部と、を備える。ここで、確認項目データは、業務文書の確認項目事項を含むＲＣＭ（リスクコントロールマトリックス）データや、顧客データである。

また、記載項目確認処理部は、入力された業務文書における記載項目が前記確認項目データに定められた関係を充足するか否か確認する。

確認項目データ取得部は、確認項目データが入力された業務文書に関連する他の種類の文書の種別データを含む場合に、当該他の種類の文書に対応する論理構造データを論理構造データベースから取得する。このとき、記載項目確認処理部は、入力された業務文書の論理構造データに含まれる記載項目と、他の種類の文書の論理構造データに含まれる記載項目が、確認項目データに定められた関係を充足するか否かを確認する。

上記業務文書処理装置は、さらに、警告表示に含まれる不適合記載の修正、又は不適合記載が生じた理由を含む付加情報の入力を受け付け、入力された業務文書の論理構造データに反映するデータ修正反映部と、修正又は付加情報が反映された論理構造データを論理構造データベースに登録するデータ登録部と、を備える。

さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。

本発明の業務文書処理装置によれば、ユーザの目視に頼らずに自動で業務文書の記載内容を確認することができるようになる。

以下、添付図面を参照しながら、本発明の業務文書処理装置を実施するための最良の形態を詳細に説明する。図１〜図１１は、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表し、基本的な構成及び動作は同様であるものとする。

＜業務文書処理装置の構成＞
図１は、本発明の実施形態による業務文書処理装置の内部構成を概略的に示す機能ブロック図である。この業務文書処理装置は、各種文書についてのＲＣＭ（リスクコントロールマトリックス）を格納しているＲＣＭ_ＤＢ１００と、顧客データを格納している顧客ＤＢ１０１と、証憑の論理構造を格納している証憑論理構造ＤＢ１０２と、データを表示するための表示装置１０３と、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード１０４と、マウスなどのポインティングデバイス１０５と、必要な演算処理及び制御処理等を行う中央処理装置１０６と、中央処理装置１０６での処理に必要なプログラムを格納するプログラムメモリ１０７と、中央処理装置１０６での処理に必要なデータを格納するデータメモリ１０８と、を備えている。

中央処理装置１０６は、証憑に記載された項目が定められた関係を満たすかを確認し、ユーザに警告表示を行うと共に修正および付加情報の入力を受付ける、単一証憑記載項目確認処理部１０９と、一連の業務で発生する証憑の間で、記載項目が定められた関係を満たすかを確認し、ユーザに警告表示を行うと共に修正および付加情報の入力を受付ける、証憑間記載項目確認処理部１１０と、を含んでいる。

データメモリ１０８は、ＲＣＭ_ＤＢ１００から取得してきた、読み込んだ証憑文書に使用するＲＣＭデータを保持するＲＣＭデータ（保持部）１１１と、顧客ＤＢ１０１から取得してきた対象の顧客データを保持する顧客データ（保持部）１１２、証憑の論理構造ＤＢ１０２から取得した証憑論理構造データを保持する証憑の論理構造データ（保持部）１１３と、を含んでいる。

＜各データの構造＞
図２乃至４は、データメモリ１０８に含まれる、ＲＣＭデータ１１１、顧客データ１１２および証憑の論理構造データ１１３のデータ構造（例）を示す図である。図１１は、別の証憑のＲＣＭデータ例と論理構造データ例を示している。

図２Ａに示されるＲＣＭデータは、証憑のＩＤ２００、証憑の種別２０１、証憑の確認項目２０２、関連証憑の種別２０３、関連証憑の確認項目２０４、関係２０５、適用条件２０６を含んでいる。適用条件については、２０７〜２０８に示すＲＣＭの適用条件節データの配列で保持される。図２の例では、受領書と納品書との間の関係を確認するためのＲＣＭデータとなっている。つまり、「『受領書』が適用条件を満たす場合、同一案件に属する証憑『受領書』と『納品書』について、『受領書』に記載されている『品名』と『納品書』に記載されている『品名』は『等しい』」という関係を意味する。関連証憑の種別２０３については、単一の証憑に対する確認項目の場合はＮＵＬＬが設定されている。

図２Ｂに示されるＲＣＭの適用条件節データは、証憑の条件項目２０７および条件２０８を含んでいる。図２の例は、「『金額』が『１０００万円以上』」という条件を意味する。例えば、後述するように、この金額に関する条件によって決裁者に権限があるか否か判断されるようになっている。

図１１Ａの例では、関連証憑の種別１１０３はＮＵＬＬになっている。従って、後述するように（図７参照）、単一の証憑に対する確認処理のみが行われるＲＣＭデータの例であり、「『契約書』が適用条件を満たす場合、記載されている『決済者』は『部長以上である』」という関係を意味する。

図３に示される顧客データは、顧客名３００、最終与信確認日３０１、与信限度額３０２を含んでいる。図３の例は、「顧客『○×△□株式会社』の与信限度額は『５０００万円』であり、この与信限度額を最後に確認したのは『２００８年２月１１日』である」という情報を意味する。

図４に示される証憑論理構造データは、証憑が読み込まれたときに付与される案件ＩＤ４００、証憑の種別４０１、企業名４０２、決裁者４０３、金額４０４、納品期日４０５、納品条件４０６、支払期日４０７、支払条件４０８、明細４０９、証憑作成日４１０、付加情報４１１、最終与信確認日４１２、与信限度額４１３を含んでいる。４００〜４１０までは証憑を読み込んだ時に既に設定されており、４１１〜４１３はその後の処理で設定する値である。ただし、４０２〜４０８の情報は証憑の種類によっては存在したり存在しなかったりする。図４の例は、「案件ＩＤが『２００８Ａ＿０１２３４』で、証憑の種別が『受領書』である証憑では、企業名が『○×△□株式会社』であり、決裁者が『購買部 部長 日立花子』であり、納品期日が『２００９年３月３１日』であり、明細が『業務文書処理装置 １式』であり、証憑作成日が『２００９年３月３０日』である」という情報を意味する。

図１１Ｂの例では、「案件ＩＤが『２００８Ａ＿０１２３０』であり、証憑の種別が『契約書』である証憑では、企業名が『○×□△株式会社』であり、決裁者が『営業部主任 日立太郎』であり、証憑作成日が『２００９年３月３０日』である」という情報を意味する。

＜具体的処理内容＞
１）全体的処理
上述のように構成された本実施形態の業務文書処理装置において行われる処理について説明する。図５は、業務文書処理装置における全体的処理の流れを概略的に示すフローチャートである。

図５において、まず、中央処理装置（制御部）１０６は、図示しないスキャナ等によって入力された証憑の論理構造データを取得し、証憑の論理構造データ１１３として保持する（ステップＳ５００）。なお、証憑のスキャンイメージから論理構造データを得る手法については、特許文献１乃至３に開示された文書論理構造解析技術が利用可能である。証憑の論理構造データ１１３の値４００〜４１０のうち、証憑に記載されていなかったものはＮＵＬＬで保持する。このとき、入力された文書論理構造解析の結果得られた証憑の種別４０１に基づいて、確認処理に使用されるＲＣＭデータ（図２参照）がＲＣＭ_ＤＢ１００から取得され、ＲＣＭデータ保持部１１１に保持される。ＲＣＭデータは複数あり、１つのＲＣＭデータを１要素という。従って、例えば、ＲＣＭデータが３つある場合には、要素数は３となる。

次に、中央処理装置１０６は、データ変更フラグをＦＡＬＳＥに設定する（ステップＳ５０１）。このフラグは初期値のようなものであり、入力された証憑の論理構造データについてはまずＦＡＬＳＥに設定される。そして、中央処理装置１０６は、図３を参照し、企業名の情報に基づいて最終与信確認日と与信限度額の情報を取得する（ステップＳ５０２）。つまり、中央処理装置１０６は、顧客ＤＢ１０１に格納されている顧客データ１１２の要素のうち、顧客名３００が証憑の論理構造データ１１３の企業名４０２と同じものを探す。そして、中央処理装置１０６は、そのような要素における最終与信確認日３０１を、証憑の論理構造データ１１３の最終与信確認日４１２の欄に、与信限度額３０２を与信限度額４１３の欄に転記する。

その後、単一証憑記載項目確認処理部１０９は、入力された証憑データ内において証憑記載項目が定められた関係を満たすか否か確認する（ステップＳ５０３）。この処理は、単一証憑記載項目確認処理部１０９が、例えば、上述の確認項目例１〜５に挙げたような確認を行うものである。詳細については、図７を用いて説明する。

また、証憑間記載項目確認処理部１１０は、一連の業務で発生する証憑の間で、記載項目が定められた関係を満たすか否か確認する（ステップＳ５０４）。つまり、これは、既に発生している証憑と入力証憑との間で条件を満たすものがあるかを確認する処理である。証憑間記載項目確認処理部１１０が、例えば、上述の確認項目例６〜８に挙げたような確認を行う。詳細については、図９を用いて説明する。

その後、中央処理装置１０６は、証憑の論理構造データの確認表示を表示装置１０３上に行い、ユーザによる修正入力を受付ける（ステップＳ５０５）。ここで表示する画面は、図６に示すようなものである。図６において６００に示すように、論理構造データの内容の表示が行われる。これに対してユーザは修正を行ってから値を登録する旨ボタン６０１を押下することや、修正を行わずに値を登録する旨ボタン６０１を押下することができる。修正があると、この時点でフラグはＴＲＵＥとなる。

ユーザが修正を行ってからボタン６０１を押下した場合は、中央処理装置１０６は、変更内容を証憑の論理構造データ１１３に反映させると共にデータ変更フラグをＴＲＵＥに設定する（ステップＳ５０６）。さらに、中央処理装置１０６は、データ変更フラグがＴＲＵＥかどうかを調べ（ステップＳ５０７）、ＴＲＵＥであればステップＳ５０１に戻って処理をやり直す。フラグがＴＲＵＥということは、修正がなされたことを意味するので、再度確認するためである。

ステップＳ５０７においてＦＡＬＳＥだった場合は、中央処理装置１０６は、証憑の論理構造データ１１３に保持している内容を証憑の論理構造ＤＢ１０２に格納し（ステップＳ５０８）、処理を終了する。

２）単一証憑内における記載項目確認処理
図７は、図５のステップＳ５０３における、証憑記載項目が定められた関係を満たすか確認する処理の詳細につい説明するためのフローチャートである。図７において、各ステップの処理主体は、特に断らない限り、単一証憑記載項目確認処理部１０９である。

まず、インデックス変数ｉを１で初期化する（ステップＳ７００）。次に、ＲＣＭ_ＤＢ１００に格納されているＲＣＭデータ１１１の要素数がｉ未満であるかどうかを調べ、ｉ未満であれば処理を終了する（ステップＳ７０１）。ｉ以上であった場合はさらにステップＳ７０２移行の処理が実行され、ｉ未満だった場合（最初の場合は１未満）には処理は終了する。この場合には、確認すべきＲＣＭの要素がもう存在しないからである。

また、ＲＣＭデータ１１１のｉ番目の要素の適用条件２０６（条件節データ）を満たすかどうかを調べる（ステップＳ７０２）。満たさない場合、処理は、ステップＳ７０７に移行し、満たす場合は、ステップＳ７０３に移行する。つまり、ＲＣＭデータ１１１のｉ番目の要素の関連証憑の種別２０３はＮＵＬＬであるかどうかを調べる（ステップＳ７０３）。ＮＵＬＬではなかった場合は証憑間の関係を記述している要素なので対象外であり、処理はステップＳ７０７に移行する。

ＮＵＬＬだった場合は、処理はステップＳ７０４に移行する。そして、ＲＣＭデータ１１１のｉ版目の要素の証憑の確認項目２０２は、関係２０５で保持している関係を満たすかどうか調べる（ステップＳ７０４）。満たしていない場合は、処理はステップＳ７０５に移行し、満たす場合には、処理はステップＳ７０７に移行する。

ステップＳ７０５においては、中央処理装置１０６は、警告表示を表示装置１０３上に行い、ユーザからの修正・付加情報の入力を受付ける（ステップＳ７０５）。

ステップＳ７０５で表示され警告表示画面は、例えば、図８に示すようなものとなる。図８において、８００に示すように、中処理装置１０６は、ＲＣＭデータのｉ番目の要素に記述されている関係を満たしていないことの説明を、ＩＤ１１００（図８の例では「契約書＿００１」）、証憑の種別１１０１（図８の例では「契約書」）、証憑の確認項目１１０２（図８の例では「決裁者」）、関係１１０５（図８の例では「部長以上である」）、証憑の論理構造データ１１３の対応する項目の値（図８の例では「営業部主任 日立 太郎」）を埋め込んだ形で、表示装置１０３上に表示する。なお、図８の例では、ＲＣＭデータのi番目の要素では、「契約書（証憑の種別１１０１）と関連付けて確認するべき」として指定されている証憑は存在しないとして関連証憑の種別１１０３はＮＵＬＬとなっている。また、証憑の確認項目１１０２が”決裁者”であり、本来決裁者が「部長以上である」のに、図８では「主任」となっているので、警告表示８００が表示されている。

そして、中央処理装置１０６は、８０１に示すように論理構造データ１１０７〜１１１７、１１１８〜１１２０の内容の表示を行い、８０２に示すように付加情報入力のための領域を表示する。ユーザは、８０１に対する修正や８０２に対する入力を行ってから値を登録する際にボタン８０３を押下することや、修正・入力を行わずに値を登録する際にボタン８０３を押下することができるようになっている。

図８は、８０１の決裁者の欄にプロンプトが表示されており、ユーザが修正を行っている様子を例示している。このような修正を行うことにより、特許文献１乃至３の文書論理構造解析の技術に示される、証憑のスキャンイメージから論理構造データを得る過程でエラーが生じていても、修正を行うことができる。

ユーザが修正・入力を行ってからボタン８０３を押下した場合は、修正・付加情報の入力内容を証憑の論理構造データ１１３に反映させると共にデータ変更フラグをＴＲＵＥに設定する（ステップＳ７０６）。ここで、付加情報としてユーザが８０２に入力を行った場合は、付加情報１１１８で保持する。

その後、インデックス変数ｉを１増やし（ステップＳ７０７）、ステップＳ７０１に戻って処理をやり直す。

３）証憑間における記載項目確認処理
図９は、図５のステップＳ５０４における、一連の業務で発生する証憑の間で、記載項目が定められた関係を満たすか確認する処理の詳細を説明するためのフローチャートである。図９において、各ステップの処理主体は、特に断らない限り、証憑間記載項目確認処理部１１０である。

まず、インデックス変数ｉを１で初期化する（ステップＳ９００）。次に、ＲＣＭ_ＤＢ１００に格納されているＲＣＭデータ１１１の要素数がｉ未満であるかどうかを調べ、ｉ未満であれば処理を終了する（ステップＳ９０１）。ｉ以上であった場合はさらにステップＳ９０２移行の処理が実行され、ｉ未満だった場合（最初の場合は１未満）には処理は終了する。この場合には、確認すべきＲＣＭの要素がもう存在しないからである。

ＲＣＭデータ１１１のｉ番目の要素の適用条件２０６を満たすかどうかを調べる（ステップＳ９０２）。満たさない場合はステップＳ９０８に処理は移行する。

適用条件２０６を満たす場合は、ＲＣＭデータ１１１のｉ番目の要素の関連証憑の種別２０３がＮＵＬＬであるかどうかを調べる（ステップＳ９０３）。ＮＵＬＬだった場合は単一の証憑における関係を記述している要素なので対象外であり、処理はステップＳ９０８に移行する。

ステップＳ９０３でＮＵＬＬではないと判断された場合は、証憑の論理構造データ１１３における案件ＩＤ４００と同じ案件ＩＤを持ち、ＲＣＭデータ１１１のｉ番目の要素の関連証憑の種別２０３と同じ証憑の種別を持つような証憑が証憑の論理構造ＤＢ１０２に格納されているかどうかを調べる（ステップＳ９０４）。格納されていなかった場合、処理はステップＳ９０８に移行する。

該当する証憑が証憑論理構造ＤＢ１０２に格納されていた場合は、ＲＣＭデータのｉ番目の要素で保持している関係２０５を満たすかどうか調べる（ステップＳ９０５）。関係２０５を満たしていない場合は、中央処理装置１０６は、まず、警告表示を行い、ユーザによる修正・付加情報の入力を受付ける（ステップＳ９０６）。ここで表示する警告画面は、図１０に示すようなものである。１０００に示すように、ＲＣＭデータのｉ番目の要素に記述されている関係を満たしていないことの説明を表示される。なお、１０００のような警告文章テンプレートには空欄「」が設けられており、この中に該当項目が埋め込まれることによって条件不適合の場合の警告文章が生成される。例えば、ＩＤ２００（図１０の例では「受領書＿００１」）、証憑の種別２０１（図１０の例では「受領書」）、証憑の確認項目２０２（図１０の例では「企業名」）、関連証憑の種別２０３（図１０の例では「納品書」）、関連証憑の確認項目２０４（図１０の例では企業名）、関係２０５（図１０の例では「等しい」）、証憑の論理構造データ１１３の対応する項目の値（図１０の例では「○×△□株式会社」）、及び証憑の論理構造ＤＢ１０２に格納されている証憑の論理構造データの対応する項目の値（図１０の例では「○×株式会社」）が、警告文章テンプレート内の表示空欄「」に埋め込まれる。

また、１００１に示すように、論理構造データの内容の表示を行い、１００２に示すように、付加情報入力のための領域を表示する。ユーザは、１００１に対する修正・１００２に対する入力を行ってから値を登録する旨ボタン１００３を押下することや、修正・入力を行わずに値を登録する旨ボタン１００３を押下することができる。図１０は、１００２の付加情報入力のための領域にユーザが入力を行っている様子を例示している。このような入力を行うことにより、証憑登録の時点で証憑の変則的な扱いに対する理由を明示しておくことができ、監査の際には即座に説明を行って工数削減につなげることができる。

ユーザが修正・入力を行ってからボタン１００３を押下した場合は、修正・付加情報の入力内容を証憑の論理構造データ１１３に反映させると共にデータ変更フラグをＴＲＵＥに設定する（ステップＳ９０７）。ここで、付加情報としてユーザが１００２に入力を行った場合は、付加情報４１１で保持する。

その後、インデックス変数ｉを１増やし（ステップＳ９０８）、ステップＳ９０１に戻って処理をやり直す。

＜まとめ＞
本実施形態では、証憑の登録時に内容の確認を自動的に行い、ユーザに警告表示を行うと共に付加情報の入力を受付けることにより、記入間違いを未然に防ぐと同時に変則的な証憑の取扱いにおける理由の情報を確実に収集することができる。特に、その証憑記載項目は定められた条件を満たすか、一連の業務で発生する証憑の間で、記載項目が定められた関係を満たすか確認することにより、確認を確実に行うことができる。なお、一連の業務で発生する証憑は、確認対象の証憑について取得した確認項目データ（例えば、ＲＣＭデータ）に含まれる関連証憑の情報に基づいて特定される。

また、ＲＣＭを用いて証憑の内容の確認を行うことにより、企業ごとの業務内容に即した形で内容の確認を行うことができる。ＲＣＭは、内部統制において企業内で標準的に作成される書類であるため、システム構築および運用の工数を低減させることができる。ＲＣＭを基に加工した情報を用いて、証憑の内容の確認を行う場合も、同様の効果が期待できる。

さらに、顧客データを用いて証憑の内容の確認を行うことにより、取引案件に応じた形で内容の確認を行うことができる。

なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

本発明の実施形態による業務文書処理装置の概略構成を示す機能ブロック図である。 ＲＣＭデータのデータ構造例を示す図である。 顧客データのデータ構造例を示す図である。 証憑の論理構造データのデータ構造例を示す図である。 業務文書処理装置による処理全体を説明するためのフローチャートである。 確認表示画面の例である。 証憑記載項目が定められた関係を満たすか確認する処理の詳細を説明するためのフローチャートである。 証憑記載項目が定められた関係を満たさない場合の警告表示画面の例である。 一連の業務で発生する証憑の間で、記載項目が定められた関係を満たすか確認する処理の詳細を説明するためのフローチャートである。 一連の業務で発生する証憑の間で、記載項目が定められた関係を満たさない場合の警告表示画面の例である。 ＲＣＭデータの別の例を示す図および、証憑の論理構造データの別の例を示す図である。

符号の説明

１００・・・ＲＣＭ ＤＢ
１０１・・・顧客ＤＢ
１０２・・・証憑の論理構造ＤＢ
１０３・・・表示装置
１０４・・・キーボード
１０５・・・ポインティングデバイス
１０６・・・中央処理装置
１０７・・・プログラムメモリ
１０８・・・データメモリ

Claims (6)

1. 業務文書の記載内容を確認処理し、データベースに登録する業務文書処理装置であって、
   前記業務文書を入力する入力部と、
   前記入力された業務文書の構造を解析し、複数の記載項目によって構成される論理構造データを生成する入力文書解析部と、
   業務文書の確認項目事項データであって、前記入力された業務文書の前記論理構造データに含まれる文書種別データに対応する確認項目データを、確認項目データを格納するデータベースから取得する確認項目データ取得部と、
   前記入力された業務文書の前記論理構造データと前記確認項目データ取得部によって取得された前記確認項目データとを比較して、前記入力された業務文書の記載内容を確認する記載項目確認処理部と、
   前記記載項目確認処理部によって前記入力された業務文書の前記論理構造データに不適合記載が確認された場合には、警告表示を行う警告表示部と、
   を備えることを特徴とする業務文書処理装置。
2. 前記確認項目データは、業務文書の確認項目事項を含むＲＣＭ（リスクコントロールマトリックス）データであり、
   前記確認項目データ取得部は、前記入力された業務文書の前記論理構造データに含まれる文書種別データに対応するＲＣＭデータを、ＲＣＭデータベースから取得し、
   前記記載項目確認処理部は、前記入力された業務文書の前記論理構造データと前記確認項目データ取得部によって取得された前記ＲＣＭデータとを比較して、前記入力された業務文書の記載内容を確認することを特徴とする請求項１に記載の業務文書処理装置。
3. 前記確認項目データは、業務文書に含まれる顧客データであり、
   前記確認項目データ取得部は、前記入力された業務文書の前記論理構造データに含まれる文書種別データに対応する顧客データを、顧客データベースから取得し、
   前記記載項目確認処理部は、前記入力された業務文書の前記論理構造データと前記確認項目データ取得部によって取得された前記顧客データとを比較して、前記入力された業務文書の記載内容を確認することを特徴とする請求項１に記載の業務文書処理装置。
4. 前記記載項目確認処理部は、前記入力された業務文書における記載項目が前記確認項目データに定められた関係を充足するか否か確認する請求項１乃至３の何れか１項に記載の業務文書処理装置。
5. 前記確認項目データ取得部は、前記確認項目データが前記入力された業務文書に関連する他の種類の文書の種別データを含む場合に、当該他の種類の文書に対応する論理構造データを論理構造データベースから取得し、
   前記記載項目確認処理部は、前記入力された業務文書の前記論理構造データに含まれる記載項目と、前記他の種類の文書の論理構造データに含まれる記載項目が、前記確認項目データに定められた関係を充足するか否かを確認することを特徴とする請求項１乃至４の何れか１項に記載の業務文書処理装置。
6. さらに、前記警告表示に含まれる前記不適合記載の修正、又は前記不適合記載が生じた理由を含む付加情報の入力を受け付け、前記入力された業務文書の前記論理構造データに反映するデータ修正反映部と、
   前記修正又は前記付加情報が反映された前記論理構造データを論理構造データベースに登録するデータ登録部と、
   を備えることを特徴とする請求項１乃至５の何れか１項に記載の業務文書処理装置。

Images