JP2014139751A - 文書の登録を行う装置、方法、プログラム - Google Patents

Abstract

【課題】 電子的なワークフローシステムが存在する環境において、ワークフローシステム外から取得した紙文書の添付が必要な申請の場合、原本が必ずしも必要ではない申請についても紙文書での申請が必要であった。
【解決手段】 ワークフロー情報を格納した２次元コード付き申請書を用いることで、紙文書の原本が必要なケースと、必ずしも必要ではないケースのどちらであっても、ケースに即した申請が可能なワークフローシステムを提供する。
【選択図】 図４

Description

本発明は、文書の登録を行う装置、方法、プログラムに関する。

近年、企業では文書の多くが電子化されている。領収書のように法律で紙文書の保管が義務付けられている文書であっても、電子文書法（ｅ−文書法）の施行により、一定の条件を満たせば電子的に保管が可能になったこともあり、文書の電子化は一般的になっている。
また、企業内で行われる各種申請もワークフローシステムを用いて電子的に行われることが多くなってきている。例えば、個人で立て替えた経費の決算システムをペーパーレスで実現する仕組みが開示されている（例えば、特許文献１参照）。

特開２００２−２７９１４６

しかしながら、上述した従来技術においては、領収書が必要なケースではワークフローシステムでの申請に併せ、紙文書での申請が必要になっている。つまり、領収書というワークフローシステム外からの紙文書を伴う申請の場合、電子文書法により領収書の電子的な保管が可能な場合であっても、常に紙文書での申請が必要になってしまうという問題があった。

本発明は、このような事情に鑑みてなされたものであり、ワークフローシステム外からの紙文書が必要な申請において、２次元コードを用いることで、ユーザの利便性を向上させたワークフローシステムを提供することを目的とする。２次元コードを用いたワークフローシステムは、紙文書の原本が必要なケースと、必ずしも必要ではないケースのどちらであっても、ケースに即した申請の方法を提供する。

サーバへの文書の登録指示が所定のユーザによりなされたか判定する判定手段と、サーバへの文書の登録指示が所定のユーザによりなされたと判定した場合に、前記文書を前記サーバに本登録する本登録手段と、 サーバへの文書の登録指示が前記所定のユーザとは異なるユーザによりなされたと判定した場合に、前記文書を前記サーバに仮登録し、さらに前記所定のユーザが本登録の承認を行うための情報を前記所定のユーザに送信する送信手段とを有することを特徴とする装置。

本発明の効果によれば、ワークフローシステム外からの紙文書が必要な申請において、２次元コードを用いることで、ユーザの利便性を向上させたワークフローシステムを提供することができる。２次元コードを用いたワークフローシステムは、紙文書の原本が必要なケースと、必ずしも必要ではないケースのどちらであっても、ケースに即した申請の方法を提供する。

実施例１のワークフローシステムの構成の一例を示すブロック図。 実施例１のＭＦＰ１０１のハードウェア構成の一例を示すブロック図。 実施例１の申請者ＰＣ１０２、承認者ＰＣ１０３、ＷＦサーバ１０４、承認サーバ１０５のハードウェア構成の一例を示すブロック図。 実施例１のワークフローシステムにおける処理の一例を示すシーケンス図。 実施例１のＷＦサーバ１０４におけるソフトウェア構成の一例を示すブロック図。 実施例１のＭＦＰ１０１におけるソフトウェア構成の一例を示すブロック図。 実施例１のＷＦサーバ１０４における処理の一例を示すフローチャート。 実施例１のＷＦ情報の一例。 実施例１のＭＦＰ１０１における処理の一例を示すフローチャート。 実施例１のＭＦＰ１０１における処理の一例を示すフローチャート。 実施例１のＷＦサーバ１０４における処理の一例を示すフローチャート。 実施例２のＭＦＰ１０１における処理の一例を示すフローチャート。 実施例２のＷＦ情報の一例。

以下、本発明を実施するための実施例について図面を用いて説明する。以下では、ワークフローシステム外からの紙文書が必要な申請として、個人で立て替えた出張費の清算申請を例に本発明のワークフローシステムの説明を行う。ただし、本発明は出張費の清算処理に限定されるものではない。

また、本実施例では、文書に含まれる２次元コードとして、ＱＲコード（登録商標）を使用する。これはあくまで本実施例の場合であり、これ以外の２次元コードを使用しても良い。

（実施例１）
図１は、本実施形態のワークフローシステムのシステム構成の一例を示す図である。本システムは、ＬＡＮ１１０を介して接続されるＭＦＰ１０１、申請者ＰＣ１０２、承認者ＰＣ１０３、ＷＦサーバ１０４と認証サーバ１０５から構成される。

ＭＦＰ１０１は、コピー機能を有する。それと共に、ＭＦＰ１０１は、原稿画像を読み取り、読み取って得られた文書データを、ＷＦサーバ１０４に送信するデータ送信機能を有する。申請者ＰＣ１０２は、ワークフローの申請者が用いるＰＣで、ＷＦサーバ１０４が提供するワークフローシステムのウェブページを閲覧するためのウェブブラウザがインストールされている。承認者ＰＣ１０３は、ワークフローの承認者が用いるＰＣで、申請者ＰＣ１０２同様、ウェブブラウザがインストールされている。

ＷＦサーバ１０４は、ワークフローを管理するためのサーバである。ＷＦサーバ１０４では、ワークフローシステムを管理するためのウェブアプリケーションが稼働しており、申請者ＰＣ１０２および承認者ＰＣ１０３はウェブブラウザを使用してワークフローシステムを利用する。また、ＷＦサーバ１０４はワークフローに添付された文書データを管理する文書管理システムを有する。なお、本実施例ではＷＦサーバ１０４が、ワークフローシステムと文書管理システムの両方を有するが、システム毎に別のサーバで管理するようにしてもよい。

認証サーバ１０５は、システム内で統一された認証を実現するためのサーバである。ＭＦＰ１０１やＷＦサーバ１０４に対する認証は、認証サーバ１０５へ中継され、認証サーバ１０５で認証の可否を処理する。

なお、本実施形態では、上述した装置の数に限られることはない。

図２は、ＭＦＰ１０１の構成を示すブロック図である。ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１０１全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２１４は、画像データや各種プログラムを記憶する。ＨＤＤ２１４には図９および図１０のフローチャートに示される処理を実行するためのプログラムが記憶されている。ＣＰＵ２１１がこのプログラムをＲＡＭ２１３に読み出し、解析、実行することで、図９および図１０のフローチャートの処理が実行される。

操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。

プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データはプリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ２２０に転送され、プリンタ２２０において記録媒体上に印刷される。

スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。ネットワークＩ／Ｆ２１８は、制御部２１０（ＭＦＰ１０１）をＬＡＮ１１０に接続する。

図３は、ＷＦサーバ１０４の構成を示すブロック図である。なお、申請者ＰＣ１０２、承認者ＰＣ１０３および認証サーバ１０５は、ＷＦサーバ１０４と同様の構成を有しているため、ここで合わせて説明する。

ＣＰＵ３１１を含む制御部３１０は、ＷＦサーバ１０４全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラムおよび各種管理テーブルを記憶する。ＷＦサーバ１０４のＨＤＤ３１４には、図７および図１１のフローチャートに示される処理を実行するためのプログラムが記憶されている。ＣＰＵ３１１がこのプログラムをＲＡＭ３１３に読み出し、解析、実行することで、図７および図１１のフローチャートの処理が実行される。

表示部Ｉ／Ｆ３１５は、表示部３１８と制御部３１０とを接続する。キーボードＩ／Ｆ３１６は、キーボード３１９と制御部３１０とを接続する。ＣＰＵ３１１は、キーボード３１９を介したユーザからの指示を認識し、認識した指示に応じて表示部３１８に表示する画面を遷移させる。

ネットワークＩ／Ｆ３１７は、制御部３１０をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ３１７は、ＬＡＮ１１０上の他の装置との間で各種情報を送受信する。

次に図４を用いて、本実施例のワークフローシステムにおける処理の概要を説明する。図４は、本実施例のワークフローシステムにおける処理のシーケンス図で、個人で立て替えた出張費の清算申請において、申請から承認までの一連の処理を表す。

まず申請者ＰＣ１０２は、申請者の申請情報を入力として受け取り、受け取った申請情報を出力としてＷＦサーバ１０４に送信する（ステップＳ４０１）。申請情報を受け取ったＷＦサーバ１０４は、申請情報の内容に不備や矛盾がないかをチェックする（ステップＳ４０２）。ＷＦサーバ１０４は、問題がなければ申請を受理し、領収書の添付が必要な申請であれば（ステップＳ４０３）、申請書を電子ファイルとして生成する（ステップＳ４０４）。

申請書の電子ファイル（以降、申請書データ）はＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）として生成される。これはあくまで本実施例の場合であり、これ以外のフォーマットを使用しても良い。また、申請書データには、申請情報の他にワークフローシステムの処理に必要な各種情報（以降、ＷＦ情報）がメタデータとして格納されている。ＷＦ情報には、申請を特定する申請ＩＤや承認者ユーザを示す承認者ＩＤなどが含まれている。

なお、領収書の添付が必要な申請とは、高額な旅費の申請や少額であってもタクシーなど公共交通機関以外を利用した場合の申請などが該当する。一方、領収書の添付が不要な申請とは、公共交通機関を利用した少額の旅費の申請などが該当する。

ＷＦサーバ１０４は、申請の受付が完了した旨を申請者ＰＣ１０２に通知する（ステップＳ４０５）。このとき、領収書の添付が必要な申請の場合、ＷＦサーバ１０４は、併せて申請書データが生成され、申請者ＰＣ１０２から取得可能になった旨も申請者ＰＣ１０２に通知する。通知を受けた申請者ＰＣ１０２は、ＷＦサーバ１０４から申請書データを取得する（ステップＳ４０６）。

領収書の添付が不要な申請の場合、ＷＦサーバ１０４は承認者ＰＣ１０３に承認依頼通知を送付し、承認者ＰＣ１０３から承認を受け取るとワークフローを完了する（不図示）。

一方、領収書の添付が必要な申請の場合、申請者ＰＣ１０２はＭＦＰ１０１に対して、申請書データを送付し、申請書データの印刷を指示する（ステップＳ４０７）。ＭＦＰ１０１は、受け取った申請書データを印刷する（ステップＳ４０８）。このとき、申請書データに埋め込まれたメタデータは符号化および画像化され、ＱＲコード（登録商標）として印刷される。

次に、ＭＦＰ１０１はステップＳ４０８で印刷された申請書と、申請書に対応する領収書を一緒にスキャンする指示をユーザから受け取る（ステップＳ４０９）。

ここで、ＭＦＰ１０１にスキャンの指示を行うユーザ（以降、スキャンユーザ）は、領収書の原本が不要な申請か、必要な申請かによって異なる。領収書の原本が不要な申請の場合は申請者がＭＦＰ１０１でスキャンを行う。結果として、申請書と領収書の原本は申請者の手元に残ったままになる。一方、領収書の原本が必要な申請の場合は、申請者が申請書と領収書の原本を承認者に手渡しや社内便など物理的な手段によって渡し、承認者は受け取った申請書と領収書の原本をＭＦＰ１０１でスキャンする。このとき、申請者が使用するＭＦＰ１０１と承認者が使用するＭＦＰ１０１は、同一の個体であってもよいし、別の個体であってもよい。

なお、申請に際し、領収書の原本が必要か否かの条件は、法律や社内規則など環境によって異なるが、例えば、電子文書法では額面３万円未満の領収書の場合は、電子的な保存が可能となっている。

スキャンユーザ（即ち、申請書や領収書などの文書の登録指示を行ったユーザ。）より指示を受け取ったＭＦＰ１０１は、申請書と領収書をスキャンして、申請書と領収書の原稿画像を生成する（ステップＳ４１０）。次に、ＭＦＰ１０１は、申請書の原稿画像からＱＲコード（登録商標）を見つけ出して、見つけ出したＱＲコード（登録商標）を情報化して埋込情報を得る。この埋込情報を復号してＷＦ情報を得る（ステップＳ４１１）。ＭＦＰ１０１は、申請書と領収書の原稿画像をＷＦサーバ１０４が扱えるフォーマット（例えばＰＤＦ）に変換して、申請書データと領収書データを生成する。そして、ステップＳ４１１で得たＷＦ情報と、スキャンユーザを特定する情報をメタデータとして申請書データに埋め込む（ステップＳ４１２）。ＭＦＰ１０１は、生成した申請書データと領収書データをＷＦサーバ１０４へ送信する（ステップＳ４１３）。

申請書データと領収書データを受け取ったＷＦサーバ１０４は、申請書データのメタデータに格納されているＷＦ情報（承認者ＩＤ。）とスキャンユーザの情報を取り出し、スキャンユーザが承認者（即ち、所定のユーザ）だった場合、ステップＳ４１８に処理を進める（ステップＳ４１４）。

スキャンユーザが承認者でなかった場合、ＷＦサーバ１０４は、領収書データをステップＳ４０１で行った申請に対する仮の添付書類として登録する。（ステップＳ４１５）。仮の添付書類として登録された領収書データは、閲覧できるユーザに制限があったり、メタデータによる検索ができなかったりなどの各種制限が掛かった状態となる。なお、領収書データ（即ち、スキャンデータ）の登録に際しては、登録指示したユーザを示す情報や登録日時と関連付けて登録を行う。

次にＷＦサーバ１０４は、承認者ＰＣ１０３へ承認の依頼を通知する（ステップＳ４１６）。承認者ＰＣ１０３は、承認者の操作に従って、ＷＦサーバ１０４へアクセスし、申請の承認を行う（ステップＳ４１７）。

スキャンユーザが承認者だった場合、または、申請者ＰＣ１０３から申請の承認通知を受け取った場合、ＷＦサーバ１０４は、ステップＳ４１８へ処理を進める。ステップＳ４１８で、ＷＦサーバ１０４は申請を承認して、領収書データにメタデータとしてＷＦ情報とタイムスタンプを付与することで、領収書データをステップＳ４０１で行った申請に対する正式な添付書類として登録する。最後に、ＷＦサーバ１０４は、申請者ＰＣ１０２に承認結果を通知する（ステップＳ４１９）。

図５は、本実施例のＷＦサーバ１０４におけるソフトウェア構成図である。ＷＦサーバ１０４のＨＤＤ３１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ３１１がＲＡＭ３１３に読み出し、解析、実行することで、図７および図１１のフローチャートの処理が実行される。

ワークフロー管理部５０１は、ワークフローの管理を行う。ワークフロー管理部５０１は、申請者ＰＣ１０２の申請を受け付けて申請ＩＤを発番したり、申請書データを生成したりする。また、ワークフロー管理部５０１は、ＭＦＰ１０１より受け取った申請書データと領収書データによって、ワークフローの処理を制御したりする。

ユーザ管理部５０２は、ユーザの管理を行う。ユーザ管理部５０２は、ＷＦサーバ１０４にアクセスするユーザを認証したり、文書へのアクセス制御を行ったりする。また、ユーザ管理部５０２は、ユーザ認証を認証サーバ１０５へ中継することによって認証処理を実現する。

通知部５０３は、申請者ＰＣ１０２に申請の受付通知や承認結果通知を行ったり、承認者ＰＣ１０３へ承認の依頼通知を行ったりする。

ドキュメント管理部５０４は、ＭＦＰ１０１から受け取った申請書データや領収書データを管理し、メタデータによる文書検索など文書管理システムとしての機能を提供する。

図６は、本実施例のＭＦＰ１０１におけるソフトウェア構成図である。ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで、図９および図１０のフローチャートの処理が実行される。

ユーザ管理部６０１は、ＭＦＰ１０１のユーザ認証を管理する。また、ユーザ管理部６０１は、ユーザ認証を認証サーバ１０５へ中継することによって認証処理を実現する。ＭＦＰ１０１とＷＦサーバ１０４は認証サーバ１０５を利用することで同一のユーザＩＤ、パスワードを用いて認証が可能となっている。

印刷処理部６０２は、印刷を処理する。例えば、印刷処理部６０２は、申請者ＰＣ１０２から申請書データを受け取って印刷する。

スキャン処理部６０３は、スキャンを処理する。例えば、スキャン処理部６０３は、ユーザの指示により申請書データと領収書データをスキャンして原稿画像を生成する。

送信処理部６０４は、スキャン処理部６０３で生成した原稿画像をＰＤＦのような一般的なフォーマットに変換して、ＷＦサーバ１０４に送信するための処理を行う。

ＱＲコード（登録商標）処理部６０５は、印刷時およびスキャン時にＱＲコード（登録商標）に関する処理を行う。印刷時には、文書データのメタデータを符号化および画像化して、ＱＲコード（登録商標）として印刷する。スキャン時には、原稿画像からＱＲコード（登録商標）を見つけ出して、見つけ出したＱＲコード（登録商標）を情報化して埋込情報を得る。

図７は、図４のシーケンス図におけるステップＳ４０１からステップＳ４０５を処理するためのＷＦサーバ１０４におけるフローチャートである。

まずユーザ管理部５０２は、申請者ＰＣ１０２から申請者の認証要求を受け付ける（ステップＳ７０１）。認証要求には申請者ＰＣ１０２で申請者が入力した認証情報（ユーザＩＤ、パスワードなど）が含まれている。ユーザ管理部５０２は、受け取った認証情報を認証サーバ１０５へ認証を中継することで認証の可否を判定し（ステップＳ７０２）、認証がＯＫなら次のステップＳ７０３へ処理を進める。ユーザ管理部５０２は、認証がＮＧなら認証失敗を申請者ＰＣ１０２へ通知して（ステップＳ７１１）、処理を終了する。すなわち、ここでユーザ管理部５０２はワークフローの申請を行う申請者を認証する申請者認証手段として機能する。

ステップＳ７０３で、ワークフロー管理部５０１は申請画面を生成して、申請者ＰＣ１０２へ送信する。ワークフロー管理部５０１は、申請者ＰＣ１０２より送信される申請情報を待ち受け（ステップＳ７０４）、受け付けると次のステップＳ７０５に処理を進める。すなわち、ここでワークフロー管理部５０１はワークフロー申請受付手段として機能する。

ワークフロー管理部５０１は、ステップＳ７０４で受け付けた申請情報の内容に不備や矛盾がないかをチェックし、内容に問題がなければ次のステップＳ７０６に処理を進める。ワークフロー管理部５０１は、内容に問題があれば申請情報に問題がある旨を申請者ＰＣ１０２に通知して（ステップＳ７２１）、申請情報の待ち受け（ステップＳ７０４）に戻る。

ステップＳ７０６で、ワークフロー管理部５０１は、申請を一意に識別するための申請ＩＤを発番する。次にワークフロー管理部５０１は、申請情報の内容から添付書類（領収書）が必要な申請か、不要な申請かを判別し（ステップＳ７０７）、領収書が必要な申請であればステップＳ７０８へ処理を進め、領収書が不要な申請であればステップＳ７０９へ処理を進める。

ステップＳ７０８で、ワークフロー管理部５０１は、申請情報の内容をもとに申請書をＰＤＦ（以降、申請書データ）として生成する。そして、ワークフロー管理部５０１は、申請書データに、ワークフローシステムの処理に必要な各種情報（以降、ＷＦ情報）をメタデータとして格納する（ステップＳ７０９）。すなわち、ここでワークフロー管理部５０１は申請書データ生成手段として機能する。

メタデータに含まれるＷＦ情報を図８に示す。メタデータには、申請を特定する申請ＩＤ８０１、申請者のユーザＩＤを示す申請者ＩＤ８０２、承認者のユーザＩＤを示す承認者ＩＤ８０３が含まれている。なお、承認者ＩＤ８０３は、承認者が複数いる場合は承認者のユーザＩＤを列挙してもよいし、承認者がグループの場合は承認者のロールを指定してもよい。

最後に、通知部５０３は、申請の受付が完了した旨を申請者ＰＣ１０２に通知して処理を終了する（ステップＳ７１０）。このとき、ステップＳ７０４で受け付けた申請によって申請書データが生成されていた場合は、通知部５０３は、併せて申請データが生成され取得可能になった旨を申請者ＰＣ１０２に通知する。

図９は、図４のシーケンス図におけるステップＳ４０７からステップＳ４０８を処理するためのＭＦＰ１０１におけるフローチャートである。

まず印刷処理部６０２は、申請者ＰＣ１０２より図７のフローチャートの処理によって生成された申請書データの印刷要求を受け付ける（ステップＳ９０１）。

次にＱＲコード（登録商標）処理部６０５は、申請書データに埋め込まれたメタデータを符号化および画像化してＱＲコード（登録商標）画像を生成する（ステップＳ９０２）。すなわち、ここでＱＲコード（登録商標）処理部６０５は２次元コード生成手段として機能する。

最後に、印刷処理部６０２は、申請書データを画像化したあと、その画像にステップＳ９０２で生成したＱＲコード（登録商標）を合成してプリンタ２２０で印刷を実行する（ステップＳ９０３）。すなわち、ここで印刷処理部６０２は申請書印刷手段として機能する。

図１０は、図４のシーケンス図におけるステップＳ４０９からステップＳ４１３を処理するためのＭＦＰ１０１におけるフローチャートである。

まずユーザ管理部６０１は、ＭＦＰ１０１を使用するユーザの認証要求を受け付ける（ステップＳ１００１）。認証要求にはユーザが操作部２１９から入力した認証情報（ユーザＩＤ、パスワードなど）が含まれている。ユーザ管理部６０１は、受け取った認証情報を認証サーバ１０５へ認証を中継することで認証の可否を判定し（ステップＳ１００２）、認証がＯＫなら次のステップＳ１００３へ処理を進める。ユーザ管理部６０１は、認証がＮＧなら認証失敗を操作部２１０に表示して（ステップＳ１０２１）、処理を終了する。すなわち、ここでユーザ管理部６０１はスキャンを実行するスキャンユーザを認証するスキャンユーザ認証手段として機能する。

ステップＳ１００３で、スキャン処理部６０２はステップＳ１００２で認証したユーザ（以降、スキャンユーザ）から申請書と領収書をスキャンする指示を受け取る（ステップＳ１００３）。ここで、スキャンする申請書は図９で印刷された申請書であり、スキャンする領収書は申請書に対応する領収書である。

スキャンユーザより指示を受け取ったスキャン処理部６０２は、スキャナ２２１で申請書と領収書を読み取り、申請書と領収書の原稿画像を生成する（ステップＳ１００４）。すなわち、ここでスキャン処理部６０２はスキャン手段として機能する。

次に、ＱＲコード（登録商標）処理部６０５は、申請書の原稿画像からＱＲコード（登録商標）を見つけ出して、見つけ出したＱＲコード（登録商標）を情報化して埋込情報を得る。この埋込情報を復号してＷＦ情報を得る（ステップＳ１００５）。すなわち、ここでＱＲコード（登録商標）処理部６０５は２次元コード解析手段として機能する。

ステップＳ１００５でＷＦ情報が得られた場合、スキャン処理部６０２は、次のステップＳ１００７へ処理を進める（ステップＳ１００６）。ステップＳ１００５でＷＦ情報が得られなかった場合、スキャン処理部６０２は処理が続行できない旨を操作部２１０に表示して（ステップＳ１０３１）、処理を終了する。

送信処理部６０４は、申請書と領収書の原稿画像をＷＦサーバ１０４が扱えるフォーマット（例えばＰＤＦ）に変換して、申請書データと領収書データを生成する（ステップＳ１００７）。そして、送信処理部６０４は、申請書データにステップＳ１００５で取得したＷＦ情報をメタデータとして埋め込む（ステップＳ１００８）。すなわち、ここで送信処理部６０４はワークフロー情報付与手段として機能する。

次に送信処理部６０４は、スキャンユーザを特定する情報（ステップＳ１００１で受け取ったユーザＩＤ。以降、スキャンユーザＩＤ）を申請書データのメタデータに追加する（ステップＳ１００９）。すなわち、ここで送信処理部６０４はスキャンユーザ情報付与手段として機能する。

最後に、送信処理部６０４は、生成した申請書データと領収書データをＷＦサーバ１０４へ送信して（ステップＳ１０１０）処理を終了する。すなわち、ここで送信処理部６０４はデータ送付手段として機能する。

なお、ＷＦサーバ１０４へスキャンユーザの情報を渡すためにステップＳ１００９で申請書のメタデータにスキャンユーザＩＤを追加しているが、申請書のメタデータではなく、単純に情報として渡すようにしてもよい。

図１１は、図４のシーケンス図におけるステップＳ４１３からステップＳ４１９を処理するためのＷＦサーバ１０４におけるフローチャートである。

まずワークフロー管理部５０１は、ＭＦＰ１０１より送信された申請書データと領収書データを受信する（ステップＳ１１０１）。すなわち、ここでワークフロー管理部５０１はデータ受信手段として機能する。

次にワークフロー管理部５０１は、申請書データに含まれるメタデータを取り出し、ＷＦ情報とスキャンユーザＩＤを取得する（ステップＳ１１０２）。すなわち、ここでワークフロー管理部５０１はメタデータ抽出手段として機能する。

ワークフロー管理部５０１は、ＷＦ情報の承認者ＩＤ８０３とスキャンユーザＩＤが一致するか否かをチェックすることで、スキャンユーザが申請者かどうかを判断する。ワークフロー管理部５０１は、スキャンユーザが承認者だった場合ステップＳ１１０８に処理を進め、スキャンユーザが承認者ではなかった場合ステップＳ１１０４に処理を進める（ステップＳ１１０３）。すなわち、ここでワークフロー管理部５０１はスキャンユーザ判別手段として機能する。

ステップＳ１１０４で、ドキュメント管理部５０４は、領収書データをＷＦ情報の申請ＩＤ８０１で示される申請に対する仮の添付書類として登録する。すなわち、ここでドキュメント管理部５０４は添付書類仮登録手段として機能する。仮の添付書類として登録された領収書データは、閲覧できるユーザに制限があったり、メタデータによる検索ができなかったりなどの各種制限が掛かった状態となる。

次に通知部５０３は、承認者ＰＣ１０３へ承認の依頼を通知する（ステップＳ１１０５）。

ワークフロー管理部５０１は、通知を受け取った承認者が承認者ＰＣ１０３より入力した承認の可否を受け付ける（ステップＳ１１０６）。

ワークフロー管理部５０１は、承認が否だった場合はステップＳ１１２１へ処理を進め、承認が可だった場合はステップＳ１１０８へ処理を進める（ステップＳ１１０７）。

ステップＳ１１２１では、通知部５０３が申請者ＰＣ１０２に申請が却下された旨を通知して処理を終了する。

ステップＳ１１０８では、ワークフロー管理部５０１は、ＷＦ情報の申請ＩＤ８０１で示される申請を承認する。次に、ドキュメント管理部５０４は、領収書データにメタデータとしてＷＦ情報とタイムスタンプを付与することで、領収書データをＷＦ情報の申請ＩＤ８０１で示される申請に対する正式な添付書類として登録する（ステップＳ１１０９）。すなわち、ここでドキュメント管理部５０４は添付書類本登録手段として機能する。

最後に、通知部５０３は、申請者ＰＣ１０２に申請が承認された旨を通知する（ステップＳ１１１０）。

以上、第１の実施例において説明した手順により、紙文書の原本（領収書）が必要なケースと、必ずしも必要ではないケースのどちらであっても、ケースに即した申請の手順を提供でき、ユーザの利便性が向上する。

（実施例２）
次に、本発明に係る第２の実施例について説明する。第１の実施例では、領収書の原本の要否によってＭＦＰ１０１で申請書と領収書をスキャンするユーザが異なる運用を想定していた。領収書の原本が不要な申請では、申請者が自らＭＦＰ１０１で申請書と領収書の原本をスキャンする。一方、領収書の原本が必要な申請の場合は、申請者が申請書と領収書の原本を承認者に手渡しや社内便など物理的な手段によって渡し、承認者は受け取った申請書と領収書の原本をＭＦＰ１０１でスキャンする。

これは、領収書の原本が必要な場合には申請者が、申請書と領収書の原本を必ず承認者に渡すという前提に立っている。しかし、領収書の原本が必要なすべての申請において申請者が間違いなく承認者に申請書と領収書の原本を渡してくれるという保証はない。仮に、申請書と領収書の原本を承認者に送付する必要がある旨を、ステップＳ７０９の申請完了通知時に申請者に伝えたり、ステップＳ７０８で生成される申請書データに記載したりして、注意を促したとしても、申請者が間違える可能性はゼロにはならない。

そこで、第２の実施例では、領収書の原本が必要な申請時に、申請者が間違えてＭＦＰ１０１で申請書と領収書の原本をスキャンした際に、申請者が間違いに気づくことができるようにした実施例を説明する。

第２の実施例は、第１の実施例を拡張したものであるため、第１の実施例との差分のみ説明する。

図１３に第２の実施例で使用するＷＦ情報１３００を示す。ＷＦ情報１３００は図８のＷＦ情報８００を拡張したものである。ＷＦ情報１３００には、ＷＦ情報８００に原本要否１３０１が追加されている。

ＷＦ情報１３００を作成するために図７のフローチャートを拡張する。第１の実施例と異なるステップのみ説明する。ステップＳ７０９で、ワークフロー管理部５０１は申請情報の内容をもとに原本要否１３０１を決定（例えば、額面３万円以上の申請は領収書の原本が必要とする、など）し、ＷＦ情報１３００を申請書データにメタデータとして格納する。すなわち、ここでワークフロー管理部５０１は原本要否判別手段および原本要否メタデータ付与手段として機能する。

図１２は、図１０のフローチャートを拡張したフローチャートである。図１０と同じステップ番号を持つステップは、図１０のフローチャートで説明した各ステップと同様の処理が行われるため説明は省略する。

図１０と異なるのは、ステップＳ１００６とステップＳ１００７の間に原本要否１３０１をチェックする処理を追加した点である。

ステップＳ１２０１で、スキャン処理部６０２は、ＷＦ情報１３０１の原本要否１３０１をチェックし、原本が必要な申請であればステップＳ１２０２へ処理を進め、原本が不要な申請であればステップＳ１００７へ処理を進める。すなわち、ここでスキャン処理部６０２は原本要否確認手段として機能する。

ステップＳ１２０２で、スキャン処理部６０２は、スキャンユーザのユーザＩＤとＷＦ情報１３０１の承認者ＩＤ８０３が一致するかをチェックすることで、スキャンユーザが承認者であるかを判別する。スキャンユーザが承認者であれば、スキャン処理部６０２は、ステップＳ１００７へ処理を進める。すなわち、ここでスキャン処理部６０２はスキャンユーザチェック手段として機能する。

一方、スキャンユーザが承認者でなければ、スキャン処理部６０２は、操作部２１０に領収書の原本を承認者に渡す必要がある旨を表示して（ステップＳ１２１１）、処理を終了する。すなわち、ここでスキャン処理部６０２は原本必須通知手段として機能する。

以上、第２の実施例において説明した手順により、領収書の原本が必要な申請時に、申請者が間違えてＭＦＰ１０１で申請書と領収書の原本をスキャンした際に、申請者が間違いに気づくことができるワークフローシステムを提供できる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (7)

1. サーバへの文書の登録指示が所定のユーザによりなされたか判定する判定手段と、
   サーバへの文書の登録指示が所定のユーザによりなされたと判定した場合に、前記文書を前記サーバに本登録する本登録手段と、
   サーバへの文書の登録指示が前記所定のユーザとは異なるユーザによりなされたと判定した場合に、前記文書を前記サーバに仮登録し、さらに前記所定のユーザが本登録の承認を行うための情報を前記所定のユーザに送信する送信手段とを有することを特徴とする装置。
2. 前記文書は、印刷物のスキャンデータとなっており、
   前記スキャンデータに二次元コードとして前記所定のユーザを示す情報が含まれていることを特徴とする請求項１に記載の装置。
3. 前記文書の登録の際には、
   前記文書の登録指示を行ったユーザを示す情報を前記文書に関連付けて登録することを特徴とする請求項１又は２に記載の装置。
4. サーバへの文書の登録指示が所定のユーザによりなされたか判定する判定工程と、
   サーバへの文書の登録指示が所定のユーザによりなされたと判定した場合に、前記文書を前記サーバに本登録する本登録工程と、
   サーバへの文書の登録指示が前記所定のユーザとは異なるユーザによりなされたと判定した場合に、前記文書を前記サーバに仮登録し、さらに前記所定のユーザが本登録の承認を行うための情報を前記所定のユーザに送信する送信工程とを有することを特徴とする方法。
5. 前記文書は、印刷物のスキャンデータとなっており、
   前記スキャンデータに二次元コードとして前記所定のユーザを示す情報が含まれていることを特徴とする請求項４に記載の方法。
6. 前記文書の登録の際には、
   前記文書の登録指示を行ったユーザを示す情報を前記文書に関連付けて登録することを特徴とする請求項４又は５に記載の方法。
7. 請求項４乃至６の何れか１項に記載の方法をコンピュータに実行させるためのプログラム。

Images