JP2014174754A - プログラム及び帳票処理装置 - Google Patents

Abstract

【課題】次の処理段階に進める案件についての処理待ち状態の帳票が優先的に処理されやすくする。
【解決手段】案件の１つの処理段階で複数の帳票への処理が必要な場合、それら複数の帳票の数を全帳票数として取得し、案件ＩＤと対応づけて案件管理部１０４に登録する。また、案件管理部１０４は、案件ごとに、注目する処理段階における処理済み帳票数と処理待ち帳票数とを保持し、これら各帳票数を、帳票の入力や帳票の処理が済む毎に更新する。ジョブ表示部１０７は、注目する処理段階にある、処理待ちの帳票のリストを生成し、ユーザに提示する。このリストの生成では、処理待ち帳票数と処理済み帳票数の合計が全帳票数に一致する案件の帳票を、そうでない案件の帳票よりもリストの上位に配置する。
【選択図】図１

Description

本発明は、プログラム及び帳票処理装置に関する。

業務管理システムには、各担当者が実行すべき作業（ジョブ）のリストを表示する機能を持つものが多い。リスト表示では、優先度が高いジョブほど担当者の目につきやすいリストの上位位置に配列されることが一般的である。

特許文献１には、訂正を待つ多量の帳票イメージの読取結果が存在する場合であっても、訂正端末で目的の読取結果を容易に見つけ出し、その訂正作業に素早く移行するためのシステムが開示される。このシステムでは、訂正端末において、訂正対象のバッチのステータスや重要属性等の絞り込み条件を設定しておき、この条件に従ってバッチ一覧表示画面に訂正対象のバッチを絞り込んで表示する。絞り込み条件には、ＯＣＲ（光学文字認識）の認識精度（認識精度が悪い場合、修正に時間を要するので早めに処理に着手することが必要）、納期などが指定できる。この構造により数多くの訂正待ちのバッチが存在する場合であっても、訂正端末で目的のバッチの選択を容易に行うことができる。

特許文献２には、１つの業務で取り扱う複数の帳票データを関連づけて管理するために、１つの組として取り扱われる複数の帳票データを１つの表紙データでひとくくりにして管理するシステムが開示されている。

特許文献３には、複数の文書が連結して作成を完了する文書の作成を滞りなく行なうためのシステムが開示される。このシステムでは、複数の文書間で連結関係にある文書を表示する際に、複数の文書のうちの一の文書を表示するとともに、表示した文書と連結関係にある他の文書の作成状況と文書の作成状況を表示した文書を呼び出す指示である呼び出し指示、すなわちリンクとを表示し、連結する文書間で文書の作成状況を表示して文書の作成を促す。

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

本発明は、次の処理段階に進める案件についての処理待ち状態の帳票が優先的に処理されやすくすることを目的とする。

請求項１に係る発明は、コンピュータを、案件毎に、当該案件の案件識別子、当該案件の全帳票数、及び、入力された帳票がそれぞれ処理待ち状態又は処理済み状態のいずれであるかを示す状態情報、を記憶する記憶手段、帳票が入力されると、当該帳票から案件識別子を検出し、検出した案件識別子に対応づけて当該帳票が処理待ち状態であることを示す状態情報を前記記憶手段に登録する登録手段、前記記憶手段に処理待ち状態を表す状態情報が登録された帳票の処理が完了した場合に、前記記憶手段内の当該帳票に対応する前記状態情報を処理済み状態へと更新する更新手段、各案件についての処理待ち状態の帳票を優先度の順に並べたリストを生成するリスト生成手段であって、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、優先度を高くするリスト生成手段、として機能させるためのプログラムである。

請求項２に係る発明は、前記リスト生成手段は、生成する前記リストにおいて、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票については、同一案件に属する帳票が連続して並ぶようにする、ことを特徴とする請求項１に記載のプログラムである。

請求項３に係る発明は、前記コンピュータを、帳票を当該帳票の対象である要素数に基づき管理する要素数管理方式を採用する案件については、当該案件の案件識別子に対応づけて、要素数管理方式を採用する旨、当該案件の全要素数、当該案件についての入力済み要素数、を記憶する第２の記憶手段、入力された帳票から検出された案件識別子に対応づけて、前記第２の記憶手段に前記要素数管理方式を採用する旨が記憶されている場合、当該帳票に記載された要素数を検出し、検出した要素数を、前記第２の記憶手段内の当該案件の前記入力済み要素数に加算する加算手段、として更に機能させるとともに、前記リスト生成手段は、前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票を、前記入力済み要素数が前記全要素数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、ことを特徴とする請求項１又は２に記載のプログラムである。

請求項４に係る発明は、前記リスト生成手段は、前記合計が前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記入力済み要素数が前記全要素数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、ことを特徴とする請求項３に記載のプログラムである。

請求項５に係る発明は、前記リスト生成手段は、前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、ことを特徴とする請求項３又は４に記載のプログラムである。

請求項６に係る発明は、前記リスト生成手段は、案件毎の付加属性を記憶する手段から、各案件のあらかじめ定めた付加属性の値を取得し、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票の前記リストにおける配列順序を、取得した各案件の付加属性の値に基づいて決定する、ことを特徴とする請求項１〜５のいずれか１項に記載のプログラムである。

請求項７に係る発明は、前記リスト生成手段は、案件毎の付加属性を記憶する手段から、各案件の付加属性を取得し、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票、及び前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票の前記リストにおける配列順序を、取得した各案件の付加属性に基づいて決定する、ことを特徴とする請求項３〜５のいずれか１項に記載のプログラムである。

請求項８に係る発明は、案件毎に、当該案件の案件識別子、当該案件の全帳票数、及び、入力された帳票がそれぞれ処理待ち状態又は処理済み状態のいずれであるかを示す状態情報、を記憶する記憶手段と、帳票が入力されると、当該帳票から案件識別子を検出し、検出した案件識別子に対応づけて当該帳票が処理待ち状態であることを示す状態情報を前記記憶手段に登録する登録手段と、前記記憶手段に処理待ち状態を表す状態情報が登録された帳票の処理が完了した場合に、前記記憶手段内の当該帳票に対応する前記状態情報を処理済み状態へと更新する更新手段と、各案件についての処理待ち状態の帳票を優先度の順に並べたリストを生成するリスト生成手段であって、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、優先度を高くするリスト生成手段と、を備える帳票処理装置である。

請求項１又は８に係る発明によれば、この発明を用いない場合よりも、次の処理段階に進める案件についての処理待ち状態の帳票が優先的に処理されやすくすることができる。

請求項２に係る発明によれば、この発明を用いない場合よりも、次の処理段階に進める案件についての処理待ち状態の帳票が早く処理されるようにすることができる。

請求項３に係る発明によれば、案件について入力される帳票数が決まっていない場合でも、その案件の帳票群で取り扱う要素の総数、すなわち全要素数が既知の場合には、そのような案件のうち次の処理段階に進める案件についての処理待ち状態の帳票が優先的に処理されやすくすることができる。

請求項４又は５に係る発明によれば、全帳票数を用いて優先度を定める案件と、全要素数を用いて優先度を定める案件とが混在する場合でも、次の処理段階に進める案件についての処理待ち状態の帳票が優先的に処理されやすくすることができる。

請求項６又は７に係る発明によれば、次の処理段階に進める案件が複数存在する場合に、それら案件間の処理待ち状態の帳票同士のリスト上での順序を、付加属性の値に基づき決定することができる。

実施形態の装置構成の一例を示す図である。 案件管理部が管理する案件の管理情報の一例を示す図である。 ジョブ管理部が管理するジョブの管理情報の一例を示す図である。 複数の依頼先に見積依頼を行って回答を得、購入先を決定するという複数の処理段階を説明するための図である。 各々１以上の見積依頼を行った複数の案件についての、見積確認段階の進捗状況の具体例を示す図である。 図５に例示した進捗状況での、従来のジョブ管理情報を例示する図である。 図５に例示した進捗状況での、従来の見積確認段階の担当者に提示されるジョブリストを例示する図である。 図５に例示した進捗状況において、実施形態の案件管理部が保持する管理情報（案件管理テーブル）を示す図である。 図５に例示した進捗状況において、実施形態のジョブ管理部が保持する管理情報（ジョブ管理テーブル）を示す図である。 図５に例示した進捗状況において、実施形態のジョブ表示部から見積確認段階の担当者に提示されるジョブリストを例示する図である。 図５に例示した進捗状況のあと更に新たな帳票が入力された時点（図５の時点の処理待ちジョブは１つも処理されていない）で、案件管理部が保持する管理情報を示す図である。 図１１の案件の管理情報に対応する、ジョブ管理部が保持する管理情報を示す図である。 図１２の管理情報に基づいてジョブ表示部が見積確認段階の担当者に提示するジョブリストを例示する図である。 実施形態の装置の処理手順の一部を例示する図である。 実施形態の装置の処理手順の残りの部分を例示する図である。 変形例の案件管理部が保持する管理情報（案件管理テーブル）を示す図である。 変形例の見積確認段階の担当者に提示するジョブリストを例示する図である。 第２の変形例が対象とする、案件に関する帳票数が事前にわからないケースを例示する図である。 図１８の状況に対応する、検収段階の進捗状況の一例を示す図である。 図１９の状況において案件管理部が保持する管理情報（案件管理テーブル）を示す図である。 第２の変形例の処理手順の一部を例示する図である。 第２の変形例の処理手順の残りの部分を例示する図である。

以下、図面を参照して、本発明の実施形態について説明する。

図１に、本実施形態の帳票処理装置１００の機能構成の一例を示す。この明細書において、「帳票」とは、業務の遂行のために用いられる文書のことであり、例えば見積書や納品書などがその一例である。帳票は、紙に印刷されたものであってもよいし、スプレッドシートやワードプロセッサなどのアプリケーションで作成された文書データであってもよい。帳票には、本実施形態の案件管理のために、案件ＩＤ（識別子）が付加されている。紙の帳票の場合、案件ＩＤは、例えば、バーコードやＱＲコード（登録商標）などの画像コード、あるいは文字列画像の形で帳票に印刷される。

案件ＩＤは案件を一意に識別する識別子である。ここで、案件とは、帳票処理装置１００で管理する１単位の業務のことである。帳票に含まれる案件ＩＤは、その帳票がその案件ＩＤの示す案件で用いられる帳票であることを示す。

案件は、１以上の処理段階を含んでおり、それら処理段階は基本的に順番に実行されていく。案件に含まれる処理段階の中には、１以上の帳票を用いるものが含まれる場合がある。

帳票処理装置１００が備える帳票入力部１０１は、帳票データの入力を受け付ける手段である。一つの例では、入力される帳票データは、スキャナによって読み取られた帳票の画像データである。また、別の例では、入力される帳票データは、アプリケーションで作成された文書データある。また、スキャン画像データ及びアプリケーションデータの両方の形態の帳票データの入力を受け付けるようにしてもよい。

案件ＩＤ抽出部１０２は、帳票入力部１０１から入力された帳票データから案件ＩＤを抽出する。入力された帳票データがスキャン画像データである場合、案件ＩＤ抽出部１０２はその画像データを解析し、その画像に画像コード又は文字列画像として含まれている案件ＩＤを認識する。入力された帳票データがアプリケーションデータの場合は、その帳票データに含まれる案件ＩＤ属性の値を認識する。

全帳票数取得部１０３は、帳票入力部１０１から入力された帳票データに対応する案件が用いる全帳票数の情報を取得する。ここでいう「全帳票数」とは、案件全体（複数の処理段階を含む場合もある）で用いる帳票の総数ではなく、案件の中の１つの処理段階で用いる帳票の総数のことである。本実施形態では、案件に含まれる１以上の処理段階を順に１段階ずつ進めていくことを想定しており、案件の進捗の中で最新の処理段階、すなわち現在の処理対象である処理段階、で用いる帳票の総数が「全帳票数」である。一つの例では「全帳票数」の情報が各帳票に印刷され（あるいは属性データとして含まれ）ており、全帳票数取得部１０３は、帳票データから画像解析（光学文字認識）等により全帳票数を読み取る。別の例では、業務進捗（ワークフロー）全体を管理する業務システム３００に、案件ＩＤに対応づけて「全帳票数」を登録しておき、全帳票数取得部１０３は、案件ＩＤ抽出部１０２が抽出した案件ＩＤに対応する全帳票数を業務システム３００から取得する。

案件管理部１０４は、帳票処理装置１００が管理する各案件の管理情報を管理する。図２に示す例では、案件の管理情報（以下「案件管理テーブル」とも呼ぶ）は、案件ＩＤ、全帳票数、処理済みの帳票数、処理待ちの帳票数を含んでいる。前述の通り、全帳票数は、案件ＩＤが表す案件の現在処理対象の処理段階で用いる帳票の総数である。また、処理済み帳票数は、その全帳票数のうち、現在処理対象の処理が済んだ状態（「処理済み状態」と呼ぶ）の帳票の数を示す。そして、処理待ち帳票数は、その全帳票数のうち、現在処理対象の処理を待っている状態（「処理待ち状態」と呼ぶ）の帳票の数を示す。本実施形態では、帳票が帳票入力部１０１に入力されて初めて、その帳票を「処理待ち状態」とする。帳票が帳票入力部１０１に入力される前は、その帳票は「処理待ち状態」以前の状態である。この「処理待ち状態」以前の状態は、例えば着手不能状態と呼んでもよい。帳票が入力されて初めて、現在処理対象の処理段階の担当者は、その帳票を処理可能な状態となるので、この「処理可能な状態」のことをこの明細書では「処理待ち状態」と呼び、着手不能状態と区別している。処理待ち状態の帳票に対し、担当者が現在処理対象の処理段階の処理を実行すると、その帳票は処理済み状態となる。

優先度判定部１０５は、案件管理部１０４に保持される案件ＩＤごとの処理状態を確認し、案件ごとの優先度を判定する。

ジョブ管理部１０６は、処理段階ごと（あるいは各処理段階を担当する担当者ごと）に、その処理段階にある各帳票（ジョブ）の状態（ステータス）を管理する。帳票入力部１０１に入力された帳票は、担当者により現在の処理段階に対応する処理を受けることになるが、その「処理」のことをジョブと呼ぶ。言い換えれば、ある案件の帳票が入力されると、その案件の現在処理対象（すなわち進捗上最新）の処理段階の担当者には、その帳票に対してその処理段階の処理を実行するというジョブが割り当てられることになる。ジョブ管理部１０６は、このようなジョブの管理を行うのである。

ジョブ管理部１０６が保持するジョブの管理情報（以下「ジョブ管理テーブル」とも呼ぶ）の一例を図３に示す。この例では、ジョブの管理情報には、ジョブを一意に識別するジョブＩＤに対応づけて、そのジョブ（入力された帳票に対応）に対応する案件の案件ＩＤ、そのジョブのステータス、そのジョブの優先度の情報が含まれる。

ジョブのステータスは、そのジョブ（帳票）が処理待ち、処理済みのいずれであるかを示す。なお、この例では、帳票が入力される前は、その帳票に対応するジョブは、現在処理対象の処理段階のジョブとしては存在しないものとみなしている。したがって、未入力の帳票に対応するジョブは、ジョブ管理部１０６におけるジョブの管理情報には登録されていない。

ジョブの優先度は、担当者に提示するジョブリストでのジョブの配列順における優先度を示す。本実施形態では、現在処理対象の処理段階で用いる帳票がすべて入力済みである案件のジョブは、そうでない（すなわち現在処理対象の処理段階で用いる帳票のうちの１以上が未入力である）案件のジョブよりも、ジョブリストにおける表示順位を高くする。用いる帳票が１つでも未入力である案件は、入力済みの帳票をいくら早く処理しても、その未入力の帳票が入力されるまでは、次の処理段階に進めない。逆に、用いる帳票が全て入力済みの案件は、入力済みの帳票を全て処理すれば、次の処理段階に進める。このように、用いる帳票が全て入力済みの案件の帳票を担当者に優先的に作業させた方が、複数の案件全体での処理効率の向上に寄与することがわかる。そこで、本実施形態では、用いる帳票が全て入力済みの案件の優先度を、そうでない案件の優先度よりも高くすることで、前者の案件が後者の案件よりもジョブリストの上位に表示されようにする。

なお、「ジョブリスト」とは、担当者が実行すべきジョブ（すなわち「処理待ち」状態のジョブ）を、各ジョブの優先順位（あるいは優先度）に従って上から順位配列した一覧（リスト）である。

ジョブ管理部１０６が管理する「優先度」は、以上に説明した、案件で用いる帳票が全て入力済みか否か、に基づく優先度である。図示例では優先度は、「高」（案件で用いる帳票が全て入力済み）と「低」（案件で用いる帳票のうち１以上が未入力）の２段階である。

なお、図３に示されるのは、１つの処理段階（例えば後で例示する「見積確認」段階）に該当するジョブ（帳票）群のジョブ管理テーブルであり、この処理段階の担当者には、このテーブルに基づいて生成されたジョブリストが提示される。ジョブ管理部１０６は、同様のジョブ群の管理テーブルを、処理段階ごとに保持している。例えば、見積依頼段階、見積確認段階、見積決定段階の３段階を含んだ業務において、見積依頼段階まで進んでいる案件が４件、見積確認段階まで進んでいる案件が３件、見積決定段階まで進んでいる案件が２件ある場合、見積依頼段階のジョブ管理情報にはそれら４件の各ジョブの情報が、見積確認段階のジョブ管理テーブルにはそれら３件の各ジョブの情報が、見積決定段階のジョブ管理テーブルにはそれら２件の各ジョブの情報が、それぞれ含まれる。

ジョブ表示部１０７は、ジョブ管理部１０６に保持されるジョブを優先度に従って、各処理段階の担当者に提供するジョブリストを生成する。ある処理段階のジョブリストは、その処理段階にある各ジョブのリストである。本実施形態では、案件で用いる帳票が全て入力済みの案件（優先度「高」）は、そうでない案件（優先度「低」）よりも、ジョブリストでの配列順位を高くする。

付加属性取得部２０１は、後述する変形例の装置の構成要素であり、納期や帳票構成などといった帳票の付加属性を、業務システムから取得して案件管理部１０４に保存する。

図１に例示した帳票処理装置１００は、例えば、デジタル複合機（コピー機、プリンタ、スキャナなどの複数の機能を兼ね備えた多機能装置）内に例えばソフトウエアとして組み込まれてもよいし、デジタル複合機やスキャナに接続されたＰＣ（パーソナルコンピュータ）にソフトウエアとして実装されてもよい。

業務システム３００は、帳票処理装置１００が設置される企業等の組織における業務を管理する基幹システムであり、それら業務のワークフロー管理を行う。帳票処理装置１００は、業務システム３００から各案件の情報（全帳票数や進捗状況など）を受け取ったり、各案件（の各ジョブ）の進捗状況を業務システム３００に通知したりする。

以下、具体例を交えつつ、本実施形態の帳票処理装置１００が実行する処理の例を説明する。

まず、１つの処理段階で複数の帳票を用いる例を、図４を参照して説明する。

図４に示す例では、相見積もりの依頼先として、Ａ社とＢ社の２社を選定している。見積依頼書はＡ社とＢ社のそれぞれに送付し（「見積依頼」段階）、それら各社から見積書を受領（「見積回答」段階）する。見積書を紙の書面の形で受領した場合、受領担当者がその見積書をスキャナでスキャンして電子化する。

この電子化では、スキャン結果の画像に対して光学文字認識（ＯＣＲ）処理を施すことで、見積書に含まれる各項目の数値情報や文字情報を自動認識し、認識した各種情報を見積書の電子フォーマットにおける各項目の値としてセットすることで、電子見積書データを構成する。ＯＣＲは１００％正確とはいえないので、ＯＣＲにより認識された数値や文字列が紙の見積書に記載されたものと一致しているかどうか人間（確認作業の担当者）が確認し、認識結果に誤りがある場合には電子見積書データに修正を加える。このスキャン及び確認の段階を経て生成された各電子見積書データが、見積決定段階の担当者に送られ、その担当者はそれら各見積書のデータをみて、いずれの社に発注するかを決定する。

なお、図４の例において、見積依頼書及び見積書に含まれる「見積依頼番号」は、この発注業務案件の案件ＩＤである。また、見積依頼書の表題（「見積依頼書」という文字列）の右側にあるＱＲコード（登録商標）は、その見積依頼番号（＝案件ＩＤ）を表している。また、「見積管理番号」は、この発注業務案件の見積依頼段階で発行した帳票（すなわち見積依頼書）の総数（すなわちこの案件の見積依頼段階の全帳票数）を示している。この見積依頼書の総数は、各社から回答される見積書の総数と等しい。なお、この実施形態では、依頼元と依頼先との間で見積依頼書と見積書のフォーマットが取り決められており、見積依頼書に含まれる「見積依頼番号」と「見積管理番号」が見積書にも含まれるようになっているものとする。

このような相見積もりによる発注プロセスが３件同時に進行中の案件進捗状況の一例を図５に示す。

図５には、案件ＩＤがそれぞれ「Ｍ０００１」、「Ｍ０００２」及び「Ｍ０００３」である３つの案件の進捗状況が例示されている。この例の発注プロセスでは、開発部門等の依頼元部門が物品を購入しようとする場合に購買部門に対して購入依頼（「購入依頼」段階）を行い、これに応じて購買部門が、対象物品を取り扱う１以上の業者に対して見積依頼書を送付する（「見積依頼」段階）。その後、依頼先の各業者から、依頼に対する回答として見積書が送付され（「見積回答」段階）、購買部門の受付担当者は、その見積書を帳票処理装置１００に入力する。ここで、見積書が紙である場合、受付担当者は、その見積書をスキャナに読み取らせ、スキャン結果の画像に対するＯＣＲ結果を紙の帳票と照合することで、ＯＣＲ結果である電子化見積書の各項目の値が正しいか確認する（「見積確認」段階）。確認済みの各電子化見積書は見積決定の担当者に送られ、この担当者は、相見積もりの各見積書の内容を検討し、いずれの業者に発注するかを決定する（「見積決定」段階）。帳票処理装置１００は、それら各段階の内、購買部門の担当する段階である見積確認段階を管理しているとする（このほかに、見積依頼段階や見積決定段階を管理するようにしてもよい）。

図５の例では、案件「Ｍ０００１」については２社に見積依頼を行っており、そのうち１社（Ａ社）から見積書を受け取り済みであるが、その見積書についての「見積確認」はまだ済んでいない。案件「Ｍ０００２」については、３社に見積依頼を行っており、そのうち２社（Ｃ及びＤ社）から見積書を受け取り済みであり、Ｃ社の見積書については「見積確認」が済んでいるが、Ｄ社の見積書については「見積確認」がまだ済んでいない。案件「Ｍ０００３」については１社に見積依頼を行っており、その１社（Ｆ社）から見積書を受け取り済みであるが、その見積書についての「見積確認」はまだ済んでいない。

帳票処理装置１００は、見積確認段階の対象である帳票（すなわち見積書）が入力されると、その帳票についての「見積確認」というジョブを生成（すなわち、新たなジョブＩＤをその「見積確認」作業に割り当て）する。図示例では、ジョブＩＤは、ジョブを表す文字「Ｊ」の後に４桁の通し番号を付したものである。通し番号の部分は、帳票が入力された順序を示す。

図５の例では、３つの案件で用いられる見積書のうちの４つが帳票処理装置１００に入力済みであり、それら入力済みの各見積書に対して入力順に「Ｊ０００１」〜「Ｊ０００４」のジョブＩＤが割り当てられている。そして、それら４つのうちジョブＩＤ「Ｊ０００１」の見積書は、（たまたま確認担当者に空き時間があり、その見積書を前倒しで処理可能であったなどの理由で）確認処理が完了しているが、残りの３つの見積書はまだ確認処理がなされていない。

従来の一般的な業務管理システムの場合、図５の状況における「見積確認」段階のジョブ管理情報は、例えば図６に示すようなものになるであろう。すなわち、従来技術でも、ジョブＩＤに対応する案件ＩＤ（すなわちその見積書がどの案件のものかを示す情報）、及びそのジョブＩＤに対応する見積書に対する見積確認処理が完了している（「処理済み」）か否（「処理待ち」）かの情報は管理するであろう。しかし、案件で用いる帳票が全て入力済みか否かは、従来技術では管理していない。したがって、従来技術において見積確認段階の担当者に提示するジョブリストでは、ジョブの配列順序を、納期や帳票到着順などのような、「案件で用いる帳票が全て入力済みか否か」以外の情報に基づいて決定することとなる。図６のジョブ管理情報に含まれるジョブのうち、処理待ちのジョブを見積書の到着順に従って配列した場合のジョブリストの表示例を図７に示す。この例では、処理待ちの各ジョブが、ジョブＩＤの番号の若い順に、案件ＩＤと共にリスト表示されている。

このジョブリストを見た見積確認の担当者は、優先順位が最上位の「Ｊ０００２」から順に作業を行うであろう。しかし、「Ｊ０００２」を早く処理しても、同じ案件「Ｍ０００１」の別の見積書（Ｂ社のもの）がまだ到着していないので、次の「見積決定」段階の処理は行えない。

同じ状況（図５参照）に対して本実施形態の案件管理部１０４及びジョブ管理部１０６が管理する案件管理テーブル及びジョブ管理テーブルを、図８及び図９にそれぞれ示す。

図８に示すように、この状況では、案件「Ｍ０００１」は、全帳票数２のうち処理済み帳票数が０、処理待ち帳票数が１であり（残り１つの帳票は未入力）、案件「Ｍ０００２」は、全帳票数３のうち処理済み帳票数が１、処理待ち帳票数が１である（残り１つの帳票は未入力）。また、案件「Ｍ０００３」は、全帳票数１のうち処理済み帳票数が１、処理待ち帳票数が０である。

本実施形態では、前述の通り、当該処理段階で用いる帳票が全て入力済みの案件の優先度を、そうでない案件の優先度よりも相対的に高くする。当該処理段階で用いる帳票が全て入力済みとは、言い換えれば、処理済み帳票数と処理待ち帳票数の和が、全帳票数に一致するということである。処理段階で用いる帳票が１つでも未入力であれば、処理済み帳票数と処理待ち帳票数の和は、全帳票数よりも小さい値となる。

この処理方式に図８の各案件の管理情報を当てはめると、案件「Ｍ０００１」は、処理済み帳票数（＝０）と処理待ち帳票数（＝１）の和（＝１）は、全帳票数（＝２）よりも小さい。したがって、この案件の帳票のうち少なくとも１つが未入力であることがわかり、この案件の優先度は「低」となる。同様に案件「Ｍ０００２」の優先度も「低」となる。これに対し、案件「Ｍ０００３」は、処理済み帳票数（＝０）と処理待ち帳票数（＝１）の和（＝１）は、全帳票数（＝１）と等しいので、全帳票が入力済みであることとなり、この案件の優先度は「高」となる。

図９に示すジョブ管理部１０６の管理情報では、各ジョブの「優先度」に、当該ジョブが属する案件の優先度の値が設定されている。例えば、ジョブ「Ｊ０００２」には、案件「Ｍ０００１」の優先度の値「低」が設定され、ジョブ「Ｊ０００４」には、案件「Ｍ０００３」の優先度の値「高」が設定されている。

ジョブ表示部１０７は、図９に示した各ジョブのステータス及び優先度を参照し、ステータスが「処理待ち」の各ジョブを、優先度「高」の各ジョブが「低」のジョブよりも上位となる順序で配列したジョブリスト情報を生成し、これを見積確認の担当者が見る画面（例えば見積担当者が操作するＰＣやデジタル複合機の画面）上に表示する。

図９の情報に従って表示されたジョブリスト画面の一例を図１０に示す。図１０の例では、処理すべき全ての帳票が入力済みである案件「Ｍ０００３」のジョブ「Ｊ０００４」がジョブリストの最高位に位置し、これよりも下位に、一部の帳票が未入力である案件「Ｍ０００１」及び「Ｍ０００２」のジョブ「Ｊ０００２」及び「Ｊ０００３」が位置している。見積確認の担当者がこのジョブリストを見て、ジョブ「Ｊ０００４」を優先的に処理すると、案件「Ｍ０００３」の全ての見積書（１つだけ）の電子化及び内容確認が済み、案件「Ｍ０００３」は次の「見積決定」段階に進めることになる。

図７に例示した従来のジョブリスト画面の場合、担当者はジョブ「Ｊ０００２」及び「Ｊ０００３」の後にジョブ「Ｊ０００４」を処理するので、案件「Ｍ０００３」の「見積決定」が可能になるのは、ジョブ「Ｊ０００２」及び「Ｊ０００３」の処理の後である。これに対し、本実施形態では、ジョブ「Ｊ０００４」が先に処理されるので、案件「Ｍ０００３」の「見積決定」が可能になるタイミングが早くなる。逆に、ジョブ「Ｊ０００２」及び「Ｊ０００３」については、対応案件の見積書が全て揃うまで見積確認をしても先に進めないので、ジョブ「Ｊ０００４」より後回しにしたとしても見積決定に進むのが遅れることにはならない。

次に、更なる具体例として、図５の状況で更に案件「Ｍ０００２」におけるＥ社への見積依頼に対し、Ｅ社から見積書が到来した場合を考える。図５の状況の後、この見積書の到来までの間に、他の見積書は到来せず、また処理待ちのジョブの処理は１つも行われていないとする。

このＥ社からの見積書が担当者により帳票処理装置１００に入力されると、その見積書に対する「見積確認」のジョブ「Ｊ０００５」がジョブ管理部１０６に登録される。また、案件管理部１０４が保持する案件「Ｍ０００２」の管理情報の処理待ち帳票数が、１増やされる。この時点で案件管理部１０４及びジョブ管理部１０６が保持する管理情報は、それぞれ図１１及び図１２に示すものとなる。

Ｅ社からの見積書の入力により、案件「Ｍ０００２」で見積確認の対象となる全ての見積書が入力済みとなったので、案件「Ｍ０００２」の優先度が「高」に変更される。その結果、図１２に示すジョブ管理情報のうち、案件「Ｍ０００２」に含まれる各ジョブ「Ｊ０００１」、「Ｊ０００３」及び「Ｊ０００５」の優先度が「高」に設定される。

ジョブ表示部１０７は、図１２のジョブ管理情報に基づき、図１３に例示するジョブリスト表示を生成する。図１３のジョブリスト表示では、「処理待ち状態」かつ優先度が「高」のジョブ「Ｊ０００３」、「Ｊ０００４」及び「Ｊ０００５」が、優先度が「低」のジョブ「Ｊ０００２」よりも高い順位に位置している。

また、図１３の例では、同じ優先度のジョブが案件ＩＤごとにグループ化され、同じグループに属するジョブは連続して配置されている。すなわち、優先度が「高」のジョブを仮に入力順に配列すると、ジョブリストには「Ｊ０００３」、「Ｊ０００４」、「Ｊ０００５」の順にジョブが配列されることになる。これに対し、図１３の例では、同じ案件ＩＤ「Ｍ０００２」に属するジョブ「Ｊ０００３」及び「Ｊ０００５」が１つのグループとなるので、それらジョブ「Ｊ０００３」及び「Ｊ０００５」がジョブリストの中で連続し、別の優先度「高」の案件「Ｍ０００３」のグループ（ジョブ「Ｊ０００４」のみ）はその後に並ぶことになる。図１３の例では、優先度「高」のグループ同士の配列順序は、各グループ中の入力順が最も早いジョブ同士の入力順に従って決定されている。ただし、グループ同士の配列順序の決め方はこれに限らない。このかわりに、後述する付加属性に基づいた決め方を採用してもよい。

図１３の例では、優先度「高」の同じ案件に属するジョブがジョブリストの中で連続するので、ジョブリストの順序に従って担当者がジョブを処理すれば、優先度「高」の同じ案件に属するジョブを連続させない場合よりも、案件をより素早く次の処理段階に進めることが可能になる。

次に、図１４及び図１５を参照して、帳票処理装置１００が実行する処理手順の例を説明する。

まず、帳票が到来すると、図１４に示すように、担当者がその帳票をスキャナで読み取り、スキャン結果の帳票画像とそのＯＣＲ結果を帳票入力部１０１から帳票処理装置１００内に取り込む（Ｓ１０）。次に、案件ＩＤ抽出部１０２が、帳票画像又はそのＯＣＲ結果から、案件ＩＤを抽出する（Ｓ１２）。次に、案件管理部１０４が、抽出された案件ＩＤ（原理には、その案件ＩＤに対応する「全帳票数」）が案件管理テーブルから検索し（Ｓ１４）、検索できたかどうかを判定する（Ｓ１６）。

案件管理テーブル内にその案件ＩＤがない場合、Ｓ１０で読み取った帳票は当該案件の帳票の中で最初に読み取ったものである。この場合、全帳票数取得部１０３がその案件ＩＤに対応する全帳票数を取得する（Ｓ１８）。１つの例では、帳票中に画像コード又は文字列画像として含まれる案件ＩＤを全帳票数取得部１０３が読み取る。別の例では、現処理段階（例えば図５の「見積確認」）の前の処理段階（例えば図５の「見積依頼」）で業務システム３００に登録済みである全帳票数を、全帳票数取得部１０３が取得する。

そして、案件管理部１０４が、その案件ＩＤと全帳票数のペアを案件管理テーブルに登録する（Ｓ２０）。この時点では、その案件ＩＤに対応する処理待ち帳票数及び処理済み帳票数の値は共に０に初期化されている。次に、案件管理部１０４は、その案件ＩＤに対応する処理待ち帳票数の値を１増加させる（Ｓ２２）。これは、今回入力した帳票が処理待ちとして登録されたことを意味する。そして、ジョブ管理部１０６が、今回入力した帳票に対してジョブＩＤを付与し、ジョブ管理テーブルに対し、そのジョブＩＤに対応づけて、案件ＩＤ及びステータス値「処理待ち」を登録する（Ｓ２４）。この時点では、そのジョブＩＤに対応する「優先度」の欄は空である。

Ｓ１２で抽出した案件ＩＤが案件管理テーブルにある場合は、すでにその案件ＩＤのレコードが存在すると言うことなので、Ｓ１８及びＳ２０の処理は行わず、Ｓ２２及びＳ２４の処理を行う。

Ｓ２４の後、処理は図１５のフローに進む。図１５のフローでは、優先度判定部１０５が、案件管理テーブルから、Ｓ１２で抽出した案件ＩＤに対応する全帳票数、処理済み帳票数及び処理待ち帳票数を読み出し、処理済み帳票数と処理待ち帳票数の和が全帳票数と一致しているかどうかを判定する（Ｓ２６）。一致していれば、優先度判定部１０５は、その案件の優先度を「高」と判定し、ジョブ管理テーブル内のその案件ＩＤに対応する全てのジョブの優先度を「高」に設定する（Ｓ２８）。そして、案件管理テーブルからその案件ＩＤのレコードを削除する（Ｓ３０）。削除するのは、当該案件ＩＤに対応する全ての帳票が入力済みとなったので、今後そのレコードを参照してＳ２６の判定を行う必要がなくなったからである。

Ｓ２６で処理済み帳票数と処理待ち帳票数の和が全帳票数と一致していないことがわかった場合、優先度判定部１０５は、その案件の優先度を「低」と判定し、ジョブ管理テーブル内の今回生成したジョブの優先度を「低」に設定する（Ｓ３２）。

Ｓ３０又はＳ３２の後、ジョブ表示部１０７が、処理待ち状態のジョブを優先度に従って配列したジョブリストを生成し（Ｓ３４）、生成したジョブリストを画面に表示する（Ｓ３６）。例えば、帳票処理装置１００がデジタル複合機に組み込まれている場合、そのデジタル複合機のスキャナ機能により帳票をスキャンすると、そのデジタル複合機が備えるディスプレイ装置の画面に、ジョブリストが表示される。

以上に説明した処理手順では、スキャンした帳票に対応するジョブに優先度を設定（Ｓ３０又はＳ３２）後、続けてジョブリストの生成（Ｓ３４）と表示（Ｓ３６）を行ったが、これは一例に過ぎない。このかわりに、帳票をスキャンしたときにはＳ１０からＳ３０又はＳ３２までの処理（すなわち案件管理テーブル及びジョブ管理テーブルへのジョブの登録及びこれに応じた各種情報の更新）のみを行うようにし、担当者からジョブリストの表示要求があった場合に、ジョブ表示部１０７がその時点でのジョブ管理テーブルのステータスや優先度等の情報からジョブリストを生成し、担当者の操作する端末に提供するようにしてもよい。

以上、本発明の１つの実施形態を説明した。次に、上記実施形態の変形例を説明する。

この変形例では、ジョブリストにおけるジョブの配列順序を定めるに当たり、案件の全ての帳票が入力済みであるか否かに基づく優先度が同じジョブ同士の順序を、そのジョブの付加属性（すなわちその優先度以外の属性情報）に基づき決定する。言い換えれば、ジョブの配列順序の第１のソートキーとして優先度を用い、優先度が同じジョブ同士の順序を決める第２のソートキーとして各ジョブの付加属性を用いる。付加属性としては、例えばジョブ又は案件の納期、ＯＣＲの認識精度などを用いる。例えば納期が早いジョブ又は案件ほどジョブリストでの順位を高くする。また、ＯＣＲ認識精度が低いジョブほど（手直しに時間がかかると見込まれるので）、早く着手されるようジョブリストでの順位を高くする。

例えば、案件ごとの納期が図１６に示すように設定されていたとする。図１６は、案件管理テーブルであり、このテーブルに納期属性が付加されている。案件の納期は、業務システム３００から取得され、案件管理テーブルに登録される。ジョブ管理テーブルは、図１２に例示したものと同じであるとする。この場合、ジョブ表示部１０７は、同じ優先度「高」のジョブを案件ごとにグループ分けし、グループ同士の順序を、対応する案件の納期の早い順とする。したがって、この例のジョブリストでは、図１７に示すように、優先度が「高」のジョブ「Ｊ０００３」、「Ｊ０００４」及び「Ｊ０００５」のうち、納期が最も早い案件「Ｍ０００３」のジョブ「Ｊ０００４」が最高位となり、その後にそれより納期が遅い案件「「Ｍ０００２」のジョブ「Ｊ０００３」及び「Ｊ０００５」が続くこととなる。

この変形例では、第２ソートキーとしてどの付加属性を用いるのかをユーザが定め、定めた第２ソートキーの情報を設定情報として帳票処理装置１００に登録しておく。そして、ジョブ表示部１０７がジョブリストを生成する際、付加属性取得部２０１がそれら各案件の第２ソートキーに該当する付加属性の値を業務システム３００から取得する。ジョブ表示部１０７は、案件で使用する全帳票が入力済みであるか否かに基づく優先度（第１ソートキー）に従って、処理待ちの各ジョブをソートした後、同じ優先度のジョブ群をその第２ソートキーの値に従って更にソートする。そして、ソート結果のジョブリストをユーザに提示する。

次に、第２の変形例として、案件であらかじめ決まっている帳票数ではなく、動的に変わる帳票内のデータでジョブ管理テーブルの優先度を決定する例を説明する。

この変形例では、図１８に示すような納品業務の流れを考える。図１８の例では一つの案件「Ｍ００１１」について１通の注文書を１つの依頼先に送付しているが、注文数「１５」に対して、初回の納品が納品数「１０」の分納となっており、２回目の納品で注文数「１５」すべてが揃い、次の製造のステップに進むことが可能になる。この例では、依頼先に対して分納を認めているため、１通の注文書に対して何回の分納がなされるか（すなわち納品書が何通来るか）は依頼元では事前にはわからない。このため、帳票数を用いた上記実施形態の管理方式は機能しない。

そこで、この変形例では、帳票数の代わりに、帳票が取り扱う要素の数を用いてジョブリストにおける表示優先度を切り替えるモードを用意する。帳票が取り扱う要素とは、上述の例では、依頼先に注文する物品のことである。したがって、要素数は、上述の例では注文数又は納品数のことである。そして、案件ごとに、入力された１以上の帳票に記載された要素数の合計を管理し、その合計が事前に登録されているその案件の全要素数より少ない間は、当該案件の優先度を「低」とし、合計が全要素数に一致すると、当該案件の優先度を「高」に上げる。

図１８の例では、注文書に記載した注文数が全要素数に該当し、その注文に対応する個々の分納時の納品書に記載された納品数が、分納された要素数である。

図１８の例で、依頼先のＡ社から２回に分けて分納された際の各納品書に対する検収（納品書と納品された物品とつきあわせ、物品の種類や納品数が合っているかを確認する作業）の作業を考える。ここで、図１９に示すように、１回目の分納については検収が済んでおり、２回目の分納については、納品は済んでいるが検収はまだ行われていないとする。この場合、この案件「Ｍ００１１」についての「検収」段階についての案件管理テーブルの内容は、図２０に示すものとなる。

図２０に示す案件管理テーブルには、案件ＩＤに対応づけて、全要素数、処理済み要素数、処理待ち要素数が登録されている。図１８及び図１９に示す状況では、全要素数（すなわち「注文数」）は１５、処理済み要素数（検収済みの１回目の納品数）は１０、処理待ち要素数（納品済みであるが未検収である２回目の納品数）は５である。

また、図２０の案件管理テーブルには、案件ＩＤに対応する管理方式を規定する「帳票構成」属性も含まれる。案件「Ｍ００１１」の帳票構成は「要素数」となっており、これは、当該案件の優先度は、（帳票数に基づく上述の実施形態の方式ではなく）要素数に基づくこの変形例の方式で判定することを意味する。この変形例では、「要素数」方式と、上記実施形態で用いた帳票数に基づく管理方式（例えば「帳票数」方式と名付ける）のうち、どちらの方式を用いるかを案件ごとにユーザが選択できるようにする。すなわち、ユーザは、案件の業務内容に応じ、その案件の帳票管理をそれら２方式のいずれで行うかを決定し、決定した方式を特定する情報を、その案件の案件ＩＤに対応づけて業務システム３００又は帳票処理装置１００に登録する。この方式の情報が、案件管理テーブルに当該案件のレコードを作成する際に、そのレコードの１項目として登録される。

帳票管理方式を選択可能とする場合、案件管理テーブル（図８及び図１６参照）の左から３番目及び４番目の欄は、「帳票数」方式の場合は「処理済み帳票数」及び「処理待ち帳票数」と解釈し、「要素数」方式の場合は「処理済み要素数」及び「処理待ち要素数」と解釈すればよい。

図２１及び図２２に、この変形例の処理手順の一例を示す。図２１において、図１４の手順のステップと同様のステップには同一符号を付し、重複する説明は省略する。

この例では、案件管理部１０４は、スキャンした帳票から検出した案件ＩＤに対応する帳票管理方式が「要素数」方式又は「帳票数」方式のどちらであるかを判定する（Ｓ４０）。この判定は、その案件ＩＤに対応づけて業務システム３００又は案件管理テーブルに登録されている帳票管理方式の情報を参照して行う。

帳票管理方式が「帳票数」方式であると判定した場合、案件管理部１０４は、すでに説明したＳ１６〜Ｓ３６（図１４及び図１５参照）の処理を実行する。

帳票管理方式が「要素数」方式であると判定した場合、案件管理部１０４は、Ｓ１２で検出した案件ＩＤに対応するレコードが案件管理テーブル内にすでに存在するかどうかを判定する（Ｓ４２）。存在しない場合、案件管理部１０４は、帳票の画像又はＯＣＲ結果から、その帳票に記載された全要素数の値を読み取る（Ｓ４４）。このために、あらかじめ帳票を発行する側（図１８の例では依頼先）と受け取る側（図１８の例では依頼元）との間で、その帳票に対してあらかじめ定めた態様で「全要素数」を記載することを取り決めておく。例えば図１８の例では、注文書の「注文数」の値を納品書に「注文数」という項目名に対応づけて記載するよう取り決められている。

そして、案件管理部１０４が、Ｓ１２で検出した案件ＩＤとその全要素数のペアを含んだ新規レコードを案件管理テーブルに登録する（Ｓ４６）。この時点では、その案件ＩＤに対応する処理待ち要素数及び処理済み要素数の値は共に０に初期化されている。

次に、案件管理部１０４は、帳票の画像又はＯＣＲ結果から、その帳票に記載された要素数（すなわち全要素数のうちその帳票が取り扱う対象要素の数。例えば注文数に対する実際の納品数）を検出する（Ｓ４８）。このために、あらかじめ帳票を発行する側と受け取る側との間で、その帳票に対してあらかじめ定めた態様で「要素数」を記載することを取り決めておく。例えば図１８の例では、納品書と共に実際に納品する対象物品の数を、「納品数」という項目名に対応づけて納品書に記載するよう取り決められている。この取り決めに従って、帳票から要素数を認識する。

そして、案件管理部１０４は、案件管理テーブルにおけるその案件ＩＤに対応する処理待ち要素数の値に対し、Ｓ４８で検出した要素数を加算する（Ｓ５０）。そして、ジョブ管理部１０６が、今回入力した帳票に対してジョブＩＤを付与し、ジョブ管理テーブルに対し、そのジョブＩＤに対応づけて、案件ＩＤ及びステータス値「処理待ち」を登録する（Ｓ５２）。この時点では、そのジョブＩＤに対応する「優先度」の欄は空である。

Ｓ４２の判定結果がＹｅｓ、すなわちＳ１２で抽出した案件ＩＤが案件管理テーブルにある場合は、すでにその案件ＩＤのレコードが存在すると言うことなので、Ｓ４４及びＳ４６の処理は行わず、Ｓ４８〜Ｓ５２の処理を行う。

Ｓ５２の後、処理は図２２のフローに進む。図２２のフローでは、優先度判定部１０５が、案件管理テーブルから、Ｓ１２で抽出した案件ＩＤに対応する全要素数、処理済み要素数及び処理待ち要素数を読み出し、処理済み要素数と処理待ち要素数の和が全要素数と一致しているかどうかを判定する（Ｓ５４）。一致していれば、優先度判定部１０５は、その案件の優先度を「高」と判定し、ジョブ管理テーブル内のその案件ＩＤに対応する全てのジョブの優先度を「高」に設定する（Ｓ５６）。そして、案件管理テーブルからその案件ＩＤのレコードを削除する（Ｓ５８）。

Ｓ５４で処理済み要素数と処理待ち要素数の和が全要素数と一致していないことがわかった場合、優先度判定部１０５は、その案件の優先度を「低」と判定し、ジョブ管理テーブル内の今回生成したジョブの優先度を「低」に設定する（Ｓ６０）。

Ｓ５８又はＳ６０の後、ジョブ表示部１０７が、処理待ち状態のジョブを優先度に従って配列したジョブリストを生成し（Ｓ６２）、生成したジョブリストを画面に表示する（Ｓ６４）。

なお、この第２の変形例では、「帳票数」方式の場合の優先度「高」と、「要素数」方式の場合の優先度「高」は、同じ値として取り扱う。どちらの場合も、優先度「高」の案件の処理待ちジョブを処理すれば、その案件が次の処理段階に進めるからである。優先度「高」である「帳票数」方式及び「要素数」方式の各案件間のジョブリスト上での順位付けは、納期等の付加属性に基づいて行えばよい。

以上の第２の変形例の説明では、案件の「処理済み要素数」と「処理待ち要素数」を記録し、案件に対応する帳票の入力に応じて更新したが、これは一例に過ぎない。「処理済み要素数」と「処理待ち要素数」とに分けて記録する代わりに、それら両者の合計を、帳票処理装置１００に入力された要素数を表す「入力済み要素数」として記録するようにすてもよい。この例では、案件の「入力済み要素数」の初期値を０とし、その案件に対応する帳票をスキャンする毎に、その帳票から読み取った要素数を「入力済み要素数」に加算していく。そして、優先度判定部１０５は、案件の「入力済み要素数」が「全要素数」に一致すれば、その案件の優先度を「高」とし、そうでなければその案件の優先度を「低」にする。この「入力済み要素数」を記録する方式は、優先度の判定に関しては、上述の「処理済み要素数」と「処理待ち要素数」を記録する方式と等価である。

上述した帳票処理装置１００は、例えば、汎用のコンピュータ（例えばＰＣやデジタル複合機に内蔵されたもの）に上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶装置）、二次記憶装置（ハードディスクドライブ、ソリッドステートドライブ、フラッシュメモリなど）、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、例えばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

１００ 帳票処理装置、１０１ 帳票入力部、１０２ 案件ID抽出部、１０３ 全帳票数取得部、１０４ 案件管理部、１０５ 優先度判定部、１０６ ジョブ管理部、１０７ ジョブ表示部、２０１ 付加属性取得部、３００ 業務システム。

Claims (8)

1. コンピュータを、
   案件毎に、当該案件の案件識別子、当該案件の全帳票数、及び、入力された帳票がそれぞれ処理待ち状態又は処理済み状態のいずれであるかを示す状態情報、を記憶する記憶手段、
   帳票が入力されると、当該帳票から案件識別子を検出し、検出した案件識別子に対応づけて当該帳票が処理待ち状態であることを示す状態情報を前記記憶手段に登録する登録手段、
   前記記憶手段に処理待ち状態を表す状態情報が登録された帳票の処理が完了した場合に、前記記憶手段内の当該帳票に対応する前記状態情報を処理済み状態へと更新する更新手段、
   各案件についての処理待ち状態の帳票を優先度の順に並べたリストを生成するリスト生成手段であって、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、優先度を高くするリスト生成手段、
   として機能させるためのプログラム。
2. 前記リスト生成手段は、生成する前記リストにおいて、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票については、同一案件に属する帳票が連続して並ぶようにする、ことを特徴とする請求項１に記載のプログラム。
3. 前記コンピュータを、
   帳票を当該帳票の対象である要素数に基づき管理する要素数管理方式を採用する案件については、当該案件の案件識別子に対応づけて、要素数管理方式を採用する旨、当該案件の全要素数、当該案件についての入力済み要素数、を記憶する第２の記憶手段、
   入力された帳票から検出された案件識別子に対応づけて、前記第２の記憶手段に前記要素数管理方式を採用する旨が記憶されている場合、当該帳票に記載された要素数を検出し、検出した要素数を、前記第２の記憶手段内の当該案件の前記入力済み要素数に加算する加算手段、
   として更に機能させるとともに、
   前記リスト生成手段は、前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票を、前記入力済み要素数が前記全要素数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、
   ことを特徴とする請求項１又は２に記載のプログラム。
4. 前記リスト生成手段は、前記合計が前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記入力済み要素数が前記全要素数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、
   ことを特徴とする請求項３に記載のプログラム。
5. 前記リスト生成手段は、前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、前記優先度を高くする、
   ことを特徴とする請求項３又は４に記載のプログラム。
6. 前記リスト生成手段は、案件毎の付加属性を記憶する手段から、各案件のあらかじめ定めた付加属性の値を取得し、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票の前記リストにおける配列順序を、取得した各案件の付加属性の値に基づいて決定する、ことを特徴とする請求項１〜５のいずれか１項に記載のプログラム。
7. 前記リスト生成手段は、案件毎の付加属性を記憶する手段から、各案件の付加属性を取得し、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票、及び前記入力済み要素数が前記全要素数と一致する案件に対応する処理待ち状態の帳票の前記リストにおける配列順序を、取得した各案件の付加属性に基づいて決定する、ことを特徴とする請求項３〜５のいずれか１項に記載のプログラム。
8. 案件毎に、当該案件の案件識別子、当該案件の全帳票数、及び、入力された帳票がそれぞれ処理待ち状態又は処理済み状態のいずれであるかを示す状態情報、を記憶する記憶手段と、
   帳票が入力されると、当該帳票から案件識別子を検出し、検出した案件識別子に対応づけて当該帳票が処理待ち状態であることを示す状態情報を前記記憶手段に登録する登録手段と、
   前記記憶手段に処理待ち状態を表す状態情報が登録された帳票の処理が完了した場合に、前記記憶手段内の当該帳票に対応する前記状態情報を処理済み状態へと更新する更新手段と、
   各案件についての処理待ち状態の帳票を優先度の順に並べたリストを生成するリスト生成手段であって、処理待ち状態の帳票と処理済み状態の帳票の数の合計が当該案件の前記全帳票数と一致する案件に対応する処理待ち状態の帳票を、前記合計が前記全帳票数より少ない案件に対応する処理待ち状態の帳票よりも、優先度を高くするリスト生成手段と、
   を備える帳票処理装置。

Images