JP5113864B2 - 報告情報収集システム、方法及びプログラム - Google Patents

Description

本発明は、報告情報収集システム、方法及びプログラムに関し、特に、複数の部署等からの報告情報を所定の入力形式のファイルにより収集する業務を支援するための報告情報収集システム、方法及びプログラムに関する。

複数の部署や拠点（以下、「部拠点」という。）を有する企業において、当該企業の本部が複数の部拠点に対して、営業成績や各種通達の回答等の報告を要請又は依頼し、当該複数の部拠点から報告情報を収集することが多い。以下では、本部を依頼部、部拠点を報告部と呼ぶこととする。

また、依頼部が報告情報を収集するためには、当該企業の情報システムを介して各報告部から報告情報を受け付けることが一般的である。ここで、受け付けた報告情報の二次的利用を考慮して、データベースに格納し、管理することが多い。その場合、情報システムにおいて、報告情報ごとに対応した入出力インタフェースを作成し、報告情報を蓄積するためのデータベースを構築することとなる。そのため、報告情報の種類が増加するか、形式が変更される度に、システム開発者による入出力インタフェースの改修やデータベースの再構築作業が必要となり、変更の反映のためには、情報システムの稼働を停止する必要がある。

特許文献１には、上述したデータベースの再構築作業を不要とするためのデータベース登録管理方法に関する技術が開示されている。特許文献１にかかるデータベース登録管理方法は、商品コード、商品名及び価格等といった登録要求データにおける構成内容に基づいて、データベースのテーブルの追加又は変更を行うものである。

また、上述した報告情報ごとに対応した入出力インタフェースは、システム開発者による開発ではなく、業務部門である依頼部の担当者自身がいわゆる表計算ソフトにより作成することが多い。すなわち、報告情報の形式としては、表計算ソフトで編集可能であり、複数のセルからなる２次元の表形式のファイルが利用されることが多い。

特許文献２には、複数の入力項目が定義された表形式のファイルに入力されたデータを、作成済みのデータベースに格納する場合に、当該ファイルにおける複数の入力項目と当該データベースのテーブルの定義との差異を判定し、差異に応じて前記データベースのテーブルの定義に項目の追加又は削除のいずれかを行うデータ登録装置に関する技術が開示されている。

尚、特許文献３には、表形式のファイルにおけるセルの幅を入力文字列の長さに応じて決定するセル長決定方式に関する技術が開示されている。

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

しかしながら、表形式のファイルにより入力された報告情報を収集する情報システムにおいては、報告情報の仕様が変更された場合にデータベースの構成を変更するだけでは対応するのが困難であり、また、対応には大きな手間がかかるという問題がある。

第１の理由は、報告情報の仕様は、単にテーブルの定義に限らず、同一テーブル内の項目間の整合性や依存関係といった業務上の複雑な条件も発生しうるからである。当該テーブルに入力されるデータが複雑な条件を満たすかを確認するには、データのチェックを行うチェックプログラムをテーブル毎に作成する必要がなる。そのため、報告情報の仕様を変更する場合、テーブル定義の更新作業と共にチェックプログラムの改修も必要となる。また、テーブル定義の更新内容が複雑な場合には、データベースの再構成等も必要となり、結果的に、システム停止が必要となる。

第２の理由は、報告情報の種類は、多岐に渡り、事業規模の大きさや部署数により、頻繁に多数の報告部へ報告の依頼をする必要が生じるためである。また、報告情報の項目の追加や、テーブル定義には影響しない報告情報のタイトルの変更等の微修正が発生する。そのため、必然的に修正の頻度も多くなる。よって、細かい修正の度に、システムの停止が必要となり、業務への影響が大きい。または、システムの停止が頻繁に行えない場合、修正の反映が迅速に行えないため、やはり業務への影響が大きい。

特許文献１及び２では、テーブルの定義自体を必ず変更しなければならないため、上述した問題に対応することが困難である。

本発明は、このような問題を解決するためになされたものであり、所定の入力形式のファイルにより複数の報告情報を収集する場合において、報告情報の入力形式の変更に柔軟に対応するための報告情報収集システム、方法及びプログラムを提供することを目的とする。

本発明の第１の態様にかかる報告情報収集システムは、複数の項目を含む表形式のファイルに入力された報告情報を収集する報告情報収集システムであって、前記報告情報を管理するためのデータベースと、前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成し、当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報登録手段と、前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定し、前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報登録手段と、を備える。

また、前記定義情報登録手段は、前記定義情報の更新を受け付けた場合に、当該更新が前記第２の制約条件にかかるものであるときには前記テーブルを更新せず、当該更新後の定義情報により前記定義情報記憶部を更新することが望ましい。

さらに、前記制約条件は、前記複数の項目のそれぞれについて、項目に課される制約の定義を含み、前記報告情報収集システムは、任意の項目に入力されるデータが、複数の前記制約の定義のいずれかに対応する制約を満たすか否かを検査する複数の検査手段をさらに備え、前記報告情報登録手段は、前記定義情報記憶部に格納された定義情報に含まれる前記制約条件を参照し、当該受け付けたファイルに含まれる項目から当該項目に課される制約の定義を特定し、前記複数の検査手段の中から、当該特定された制約の定義に対応する制約を検査する検査手段を選択し、当該選択された検査手段を用いて当該項目に入力されたデータを検査することが望ましい。

また、前記制約条件は、前記複数の項目の一部に入力される値に基づいて他の項目に入力されるデータを制限する条件を含むとよい。

さらに、前記表形式のファイルは、前記複数の項目が同一である複数のスプレッドシートを含み、前記報告情報登録手段は、前記複数のスプレッドシートに異なる報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力されたスプレッドシート毎の報告情報を同一の前記テーブルに異なるレコードとして格納するとよい。

さらに、前記定義情報登録手段は、第１の言語に基づく前記複数の項目を定義した項目情報及び当該複数の項目に入力されるデータに課される制約条件を含む第１定義情報と、当該第１の言語に基づく項目情報及び制約条件に対応し、当該第１の言語とは異なる第２の言語に基づく前記複数の項目を定義した項目情報及び当該複数の項目に入力されるデータに課される制約条件を含む第２定義情報とを受け付けた場合に、当該第１の言語に基づく項目情報を用いて前記データベース内に前記テーブルを生成し、当該受け付けた第１定義情報及び第２定義情報を前記定義情報記憶部へ格納し、前記報告情報登録手段は、前記第２の言語に基づく報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報を、前記第１の言語に基づく項目情報に対応付けて前記テーブルに格納するとよい。

さらに、前記定義情報登録手段は、前記報告情報が入力されていない前記表形式のファイルをさらに受け付けた場合、当該受け付けたファイルと前記受け付けた定義情報とが前記第１の制約条件において一致するか否かを判定し、一致すると判定された場合に、前記受け付けた定義情報の一部を用いて前記テーブルを前記データベース内に生成し、前記受け付けた定義情報と当該受け付けたファイルの表形式とを関連付けて前記定義情報記憶部へ格納し、複数の報告元へ前記報告情報の要求を送信し、前記報告情報登録手段は、前記複数の報告元のそれぞれから、前記報告情報が入力された複数の前記表形式のファイルを受け付けた場合に、当該受け付けた複数のファイルの表形式と関連付けられた定義情報を前記定義情報記憶部から特定し、当該受け付けた複数のファイルが当該特定された定義情報を満たすか否かを判定するとよい。

さらに、前記定義情報登録手段は、前記受け付けた定義情報が前記複数の項目の一部の定義を変更する場合、前記テーブルの当該変更される項目を末尾に移動し、変更後の項目を変更前の項目の位置に挿入するように前記テーブルを更新するとよい。

また、前記表形式のファイルは、前記複数の項目を列方向に定義し、前記報告情報を行方向に入力させる形式であり、前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行に、行の高さが所定値以下である行が存在するか否かを判定し、存在すると判定された場合、その旨を当該受け付けたファイルの入力元へ通知することが望ましい。

さらに、前記報告情報登録手段は、前記受け付けたファイルの内、可視行であることを示す情報が設定された行数が、全行数未満である場合に、前記行の高さが所定値以下である行が存在すると判定するとよい。

または、前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行に入力された文字の属性に応じて前記所定値を行ごとに決定し、各行の高さが当該行ごとに決定された所定値であるか否かを判定するとよい。

さらに、前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行の高さが所定値以下であり、かつ、当該行にデータが入力されていない場合には、前記判定の対象から除くとよい。

さらに、前記報告情報登録手段は、前記通知する場合に、行の高さが所定値以下である行を前記所定値の高さとし、かつ、当該行を強調して表示するとよい。

本発明の第２の態様にかかる報告情報収集方法は、複数の項目を含む表形式のファイルに入力された報告情報を管理するためのデータベースと、前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、を備えるコンピュータにおける前記報告情報を収集する処理を実行するための報告情報収集方法であって、前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成するテーブル生成ステップと、当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報格納ステップと、前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定する第１の判定ステップと、前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報格納ステップと、を含む。

本発明の第３の態様にかかる報告情報収集プログラムは、複数の項目を含む表形式のファイルに入力された報告情報を管理するためのデータベースと、前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、を備えるコンピュータに前記報告情報を収集する処理を実行させる報告情報収集プログラムであって、前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成するテーブル生成処理と、当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報格納処理と、前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定する第１の判定処理と、前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報格納処理と、を含む。

本発明によれば、所定の入力形式のファイルにより複数の報告情報を収集する場合において、報告情報の入力形式の変更に柔軟に対応するための報告情報収集システム、方法及びプログラムを提供することができる。

本発明の実施の形態１にかかる報告情報収集システムの全体構成を示すブロック図である。 本発明の実施の形態１にかかる制約条件の例を示す図である。 本発明の実施の形態１にかかる入力形式ファイルの例を示す図である。 本発明の実施の形態１にかかる定義情報ファイルの例を示す図である。 本発明の実施の形態１にかかる報告情報収集システムのハードウェア構成を示すブロック図である。 本発明の実施の形態１にかかる報告情報収集処理の流れを示すシーケンス図である。 本発明の実施の形態１にかかる定義情報登録処理の流れを示すフローチャートである。 本発明の実施の形態１にかかる項目情報の例を示す図である。 本発明の実施の形態１にかかる制約情報の例を示す図である。 本発明の実施の形態１にかかる作成されるテーブルの例を示す図である。 本発明の実施の形態１にかかる報告情報登録処理の流れを示すフローチャートである。 本発明の実施の形態１にかかる報告情報が入力済みの入力形式ファイルの例を示す図である。 本発明の実施の形態１にかかるテーブルに格納されるデータの例を示す図である。 本発明の実施の形態２にかかるテーブル更新処理の流れを示すフローチャートである。 本発明の実施の形態２にかかる項目を変更する場合の定義情報ファイルの例を示す図である。 本発明の実施の形態２にかかるテーブルの項目の定義が変更された場合の例を示す図である。 本発明の実施の形態３にかかる定義情報登録処理の流れを示すフローチャートである。 本発明の実施の形態３にかかる複数シートの入力形式ファイルの例を示す図である。（ａ）は、先頭のシートの例であり、（ｂ）は、二番目のシートの例である。 本発明の実施の形態３にかかる複数シートで共通のテーブルを使用する場合の定義情報ファイルの例を示す図である。（ａ）は、先頭のシートの例であり、（ｂ）は、二番目のシートの例である。 本発明の実施の形態３にかかる報告情報登録処理の流れを示すフローチャートである。 本発明の実施の形態４にかかる二言語の定義情報登録処理の流れを示すフローチャートである。 本発明の実施の形態４にかかる二言語の入力形式を扱う処理の概念を示す図である。（ａ）は、二言語の入力形式で共通のテーブルを作成する場合である。（ｂ）は、二言語の報告情報を共通のテーブルに格納する場合である。 本発明の実施の形態５の実施例１にかかる非表示行を検出する報告情報登録処理の流れを示すフローチャートである。 本発明の実施の形態５の実施例２にかかる入力形式ファイルの行の制約違反を検出する報告情報登録処理の流れを示すフローチャートである。 本発明の実施の形態５の実施例２にかかる強調表示の例を示す図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

本発明では、例えば、次のような業務を対象として説明する。ここでは、複数の部拠点（以下、「報告部」という。）と、各報告部から営業成績や各種通達の回答等の報告情報を収集する本部（以下、「依頼部」という。）と、を有する企業があるとする。このとき、まず、依頼部の担当者は、表計算ソフト等を用いて、報告情報を入力するための入力形式を定義した表形式のファイルを作成する。そして、依頼部の担当者は、ワークフローシステム等を介して表形式のファイルを各報告部へ配布する。次に、各報告部の担当者は、配布されたファイル内に自己の部拠点における報告情報を入力形式に従って入力する。その後、各報告部の担当者は、ワークフローシステム等を介して入力済みのファイルを依頼部へ送信する。本発明にかかる報告情報収集システムは、上述したワークフローシステムとして適用可能なものである。但し、以下では、一般的なワークフローシステムに関する説明は省略し、本発明にかかる報告情報収集システムに特有の機能を中心に説明を行う。

＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる報告情報収集システム４を含む全体構成を示すブロック図である。報告情報収集システム４は、ネットワーク３を介して、依頼部端末１並びに報告部端末２ａ、２ｂ、・・・及び２ｎと接続され、各報告部端末から送信される報告情報を収集する報告情報収集処理を行う情報システムである。ここで、報告情報とは、複数の項目に対応するデータの組み合わせである。そして、報告情報は、複数の項目を含む表形式のファイルに入力された情報を指すものとする。報告情報の例としては、各報告部における営業成績や各種通達の回答等があるが、これに限定されない。また、依頼部は、少なくとも一つ以上の報告部からの報告情報を収集するものとする。

報告情報収集システム４は、報告情報収集サーバ４１と、データベース４２と、定義情報記憶部４３とを備える。データベース４２は、報告情報４２２を管理するための記憶装置である。データベース４２は、ＤＢＭＳ（DataBase Management System）等により記憶装置が制御されることにより実現される。具体的には、データベース４２は、上述した複数の項目がスキーマとして定義されたテーブル４２１により、報告情報４２２を格納する。

定義情報記憶部４３は、報告情報４２２の入力形式が定義された定義情報４３１を記憶する記憶装置である。ここで、定義情報４３１は、複数の項目を定義した項目情報４３２と、複数の項目に入力されるデータに課される制約条件４３３とを含む。制約条件４３３は、複数の項目のそれぞれについて、項目に課される制約の定義を含む。制約条件４３３は、制約種別と条件値とを含む。制約種別は、制約の内容を示す情報であり、制約の定義を識別する情報である。条件値は、項目に入力される入力値が制約の内容を満たすか否かを判定するための比較値である。但し、制約種別の内容によっては、条件値が不要となる場合もある。

ここで、図２は、本発明の実施の形態１にかかる制約条件の例を示す図である。図２では、９つの制約種別を例示しており、これらは単独項目の制約条件と関連項目の制約条件とに分けられる。単独項目の制約条件とは、他の項目の入力値に影響を受けない制約条件である。例えば、制約種別が大小関係の内、「ＧＥ」であり、条件値が「１０」である場合、単独項目の制約条件は、「入力値が１０以上であること」となる。また、関連項目の制約条件とは、複数の項目の一部に入力される値に基づいて他の項目に入力されるデータを制限する条件である。例えば、項目Ｂに単独項目の制約条件が定義され、さらに、関連項目として項目Ａについて制約種別の「存在」が定義されている場合、関連項目Ａの入力値が存在しない場合には、項目Ｂの入力値に関わらず制約条件を満たさないこととなる。これにより、同一テーブル内の項目間のデータの関連といった詳細な制約条件を定義することができる。

また、制約種別は、後述する検査手段５３ａ、５３ｂ、・・・及び５３ｍのいずれかに対応付けられている。すなわち、制約種別は、検査手段を識別する制約識別子である。そのため、制約識別子により、検査手段を特定することができる。さらに、制約条件４３３は、一項目当たり複数の制約を定義することができる。尚、データベース４２及び定義情報記憶部４３は、ハードディスクドライブ、フラッシュメモリ等の不揮発性の記憶装置であることが望ましい。

図１に戻り、報告情報収集サーバ４１は、汎用的なコンピュータシステムであり、報告情報４２２の収集処理を実行する制御部５０を少なくとも備える。尚、報告情報収集サーバ４１の具体的なハードウェア構成については、図５にて後述する。制御部５０は、定義情報登録手段５１と、報告情報登録手段５２と、検査手段５３ａ、５３ｂ、・・・及び５３ｍとして機能する。

定義情報登録手段５１は、依頼部端末１からネットワーク３を介して定義情報４３１を受け付けた場合に、受け付けた定義情報４３１の一部を用いて、受け付けた定義情報４３１により課される制約よりも小さい制約のテーブル４２１をデータベース４２内に生成し、受け付けた定義情報４３１を定義情報記憶部４３へ格納する。そして、報告情報登録手段５２は、報告部端末２ａ、２ｂ、・・・及び２ｎのいずれかからネットワーク３を介して報告情報４２２が入力された表形式のファイルを受け付けた場合に、受け付けたファイルに入力された報告情報４２２が定義情報記憶部４３に格納された定義情報４３１を満たすか否かを判定する。そして、定義情報４３１を満たすと判定した場合に、報告情報登録手段５２は、受け付けたファイルに入力された報告情報４２２をテーブル４２１に格納する。これにより、まず、依頼部の担当者が所望の項目を定義した定義情報４３１を登録することにより、当該項目に対応するテーブル４２１を自動的に作成することができる。そのため、報告情報を蓄積するためのデータベースの構築作業が不要となり、情報システムの稼働を停止する必要がなくなる。また、定義情報４３１を定義情報記憶部４３に保持しておくことにより、受け付けたファイルに入力された報告情報４２２について、保持された定義情報４３１を用いて、テーブル４２１に入力されるデータのチェックを行うことができる。そのため、テーブル４２１に専用のチェックプログラムの開発及び改修が必要ない。また、報告情報の仕様を変更する場合には、変更を加えた定義情報４３１を再登録することにより、適宜、変更箇所に対応してテーブル４２１が自動的に変更される。さらに、テーブル４２１は、受け付けた定義情報４３１の一部を用いて作成される。そのため、例えば、報告情報の仕様の変更内容がテーブル４２１の作成に用いられていない定義情報４３１の内容である場合、テーブル４２１を変更する必要がなく、報告情報の仕様の変更に柔軟に対応できる。

また、定義情報登録手段５１は、定義情報４３１を受け付けた場合に、当該受け付けた定義情報４３１に含まれる項目情報４３２を用いてテーブル４２１をデータベース４２内に生成する。そして、報告情報登録手段５２は、報告情報４２２が入力された表形式のファイルを受け付けた場合に、受け付けたファイルに含まれる項目と当該項目に入力されたデータとが定義情報記憶部４３に格納された定義情報４３１に含まれる項目情報４３２及び制約条件４３３を満たすか否かを判定する。これにより、項目情報４３２に対応するテーブル４２１が作成され、複雑な条件設定を含む制約条件４３３については、テーブル４２１の作成には用いられない。一方、受け付けた報告情報４２２に対しては、テーブル４２１に課される制約より大きい制約によりチェックを行うことで、テーブル４２１に登録されるデータは、テーブル４２１に課される制約を満たすことができる。そして、制約条件４３３が変更された場合には、テーブル４２１の定義に影響を与えないため、テーブルの変更回数が減り、データベースの再構成の回数を抑えることができる。

さらに、定義情報登録手段５１は、報告情報４２２が入力されていない表形式のファイルつまり、入力形式ファイルを受け付けた場合、受け付けたファイルと既に受け付けた定義情報４３１との整合性があるか否かを判定する。続いて、定義情報登録手段５１は、整合性があると判定された場合に、受け付けた定義情報４３１の一部を用いて、テーブル４２１をデータベース４２内に生成し、受け付けた定義情報４３１と受け付けたファイルの表形式とを関連付けて定義情報記憶部４３へ格納する。その後、定義情報登録手段５１は、複数の報告元である報告部端末２ａ、２ｂ、・・・及び２ｎへ報告情報の要求を送信する。または、依頼部端末１からネットワーク３を介して当該報告情報の要求先の報告部端末の指定及び入力形式ファイルを受け付けた場合に、定義情報登録手段５１は、当該報告情報の要求を送信するようにしてもよい。

この後、報告情報登録手段５２は、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれから、報告情報４２２が入力された複数の表形式のファイルを受け付けた場合に、受け付けた複数のファイルの表形式と関連付けられた定義情報４３１を定義情報記憶部４３から特定する。そして、報告情報登録手段５２は、受け付けた複数のファイルが特定された定義情報４３１を満たすか否かを判定する。これにより、入力形式ファイルと定義情報との項目等の整合性を保って管理することができる。また、複数の報告元から収集した情報の整合性を保つことができる。

検査手段５３ａ、５３ｂ、・・・及び５３ｍは、任意の項目に入力されるデータが、複数の制約の定義のいずれかに対応する制約を満たすか否かを検査する。また、上述したように、検査手段５３ａ、５３ｂ、・・・及び５３ｍは、制約種別に対応付けられている。そして、報告情報登録手段５２は、定義情報記憶部４３に格納された定義情報４３１に含まれる制約条件４３３を参照し、受け付けたファイルに含まれる項目から当該項目に課される制約の定義を特定する。そして、報告情報登録手段５２は、複数の検査手段５３ａ、５３ｂ、・・・及び５３ｍの中から、特定された制約の定義に対応する制約を検査する検査手段を選択する。その後、報告情報登録手段５２は、選択された検査手段を用いて当該項目に入力されたデータを検査する。これにより、複雑な制約条件の検査処理を検査手段という形で予め実装しておき、項目毎の制約条件の定義に従い、適宜、検査手段を選択的に実行するため、制約条件の変更に柔軟に対応できる。

依頼部端末１並びに報告部端末２ａ、２ｂ、・・・及び２ｎは、キーボードやマウス等の入力装置（不図示）と、画面等の表示装置（不図示）とを備える端末装置であり、表形式のファイルを編集可能な、いわゆる表計算ソフトが動作するものとする。例えば、依頼部端末１並びに報告部端末２ａ、２ｂ、・・・及び２ｎは、通信機能を備え、ＷＥＢブラウザ等の表示アプリケーションを備えたパーソナルコンピュータであるとよい。

ここで、依頼部端末１は、依頼部の担当者が操作する端末である。依頼部端末１は、報告情報を入力するために複数の項目を定義した入力形式ファイルと、当該報告情報の入力形式が定義された定義情報を含む定義情報ファイルとを表計算ソフトにより作成する。そして、依頼部端末１は、入力形式ファイルと定義情報ファイルとをネットワーク３を介して報告情報収集システム４へ送信し、登録要求を行う。ここで、入力形式ファイル及び定義情報ファイルは、共に、複数のセルからなる２次元の表形式のファイルとし、複数の項目の名称及び順序すなわち列位置が対応しているものとする。これにより、依頼部の担当者は、一般的な表計算ソフトを用いて容易に報告情報の入出力インタフェースと、その制約条件とを定義することができる。入力形式ファイルは、報告部の担当者により報告情報を入力するための入力フォーマットそのものである。

ここで、図３は、本発明の実施の形態１にかかる入力形式ファイルの例を示す図である。図３に示す入力形式ファイルは、ヘッダ領域６０１とデータ領域６０２とを含む。ヘッダ領域６０１は、報告情報のタイトルや当該報告情報の複数の項目の名称及び順序の定義を含む領域である。項目の名称は、項目の識別情報である。ここでは、例として、３行目に項目の名称が"ItemA"、"ItemB"、"ItemC"、"ItemD"の順序により定義されていることを示す。また、データ領域６０２は、報告情報が入力される領域である。ここでは、４行目以降に、１行当たり１報告情報とし、１報告情報当たり各項目に１データが対応付けられることを示す。尚、項目の名称については、ＡＳＣＩＩ（American Standard Code for Information Interchange）文字で表現されるものとする。また、ヘッダ領域６０１には、項目の説明等の情報を含めても構わない。

また、図４は、本発明の実施の形態１にかかる定義情報ファイルの例を示す図である。図４に示す定義情報ファイルは、ヘッダ領域６０３と制約条件領域６０４とを含む。ヘッダ領域６０３は、入力形式ファイルと同じ項目の名称及び順序の定義を含む領域である。ここでは、例として、２行目に項目の名称が"ItemA"、"ItemB"、"ItemC"、"ItemD"の順序により定義されていることを示す。また、制約条件領域６０４は、制約条件４３３に対応する領域である。ここでは、例として、"ItemA"の制約条件として、属性が日付型であることを示す。また、"ItemB"の制約条件として、属性が文字型であり、入力が必須かつ桁数が"１０"であることを示す。尚、上述した項目情報４３２は、少なくとも項目の名称及び順序を含む情報である。尚、本発明の実施の形態１では、項目情報４３２は、さらに属性及び桁数を含むものとする。また、制約条件４３３は、項目ごとの制約種別及び条件値を表す情報である。尚、本発明の実施の形態１にかかる入力形式ファイル及び定義情報ファイルは、いわゆるスプレッドシート（以下、「シート」という。）が一つの場合として説明する。

また、図１に戻り、報告部端末２ａ、２ｂ、・・・及び２ｎは、複数の部拠点にそれぞれ設置された端末であり、複数の報告部のそれぞれの担当者が操作するものである。報告部端末２ａ、２ｂ、・・・及び２ｎは、報告情報収集システム４等から配布される入力形式ファイルを受信し、自己の部拠点における報告情報を入力形式ファイルに表計算ソフトにより入力する。すなわち、報告部端末２ａ、２ｂ、・・・及び２ｎは、入力形式ファイルを更新する。その後、報告部端末２ａ、２ｂ、・・・及び２ｎは、報告情報が入力された入力形式ファイル、つまり、入力済みファイルを報告情報収集システム４へ送信し、登録要求を行う。

その後、依頼部端末１は、報告情報収集システム４から入力済みファイルを取得するか、後述するテーブル４２１を参照するなどにより、各報告部からの報告情報を確認又は加工等の処理を行うことができる。

ネットワーク３は、インターネット、公衆網、専用線及び移動体通信網等の通信ネットワークである。

図５は、本発明の実施の形態１にかかる報告情報収集システムのハードウェア構成を示すブロック図である。報告情報収集サーバ４１は、ＣＰＵ（Central Processing Unit）４１１と、ＲＡＭ（Random Access Memory）４１２と、ＲＯＭ（Read Only Memory）４１３と、通信部４１４と、ハードディスク４１５とを備える。また、ハードディスク４１５は、不揮発性記憶装置であり、ＯＳ（Operating System）５１０及び報告情報収集プログラム５２０が格納されている。尚、ハードディスク４１５は、データベース４２及び定義情報記憶部４３をさらに含むものであってもよい。

報告情報収集プログラム５２０は、定義情報登録処理及び報告情報登録処理が実装されたコンピュータプログラムである。具体的には、報告情報収集プログラム５２０は、定義情報登録モジュール５２１、報告情報登録モジュール５２２、検査モジュール５２３ａ、５２３ｂ、・・・及び５２３ｍを含む。ここで、定義情報登録モジュール５２１は、上述した定義情報登録手段５１における処理が実装されたコンピュータプログラムである。報告情報登録モジュール５２２は、上述した報告情報登録手段５２における処理が実装されたコンピュータプログラムである。検査モジュール５２３ａ、５２３ｂ、・・・及び５２３ｍのそれぞれは、上述した検査手段５３ａ、５３ｂ、・・・及び５３ｍのそれぞれにおける処理が実装されたコンピュータプログラムである。

特に、検査モジュール５２３ａ、５２３ｂ、・・・及び５２３ｍは、関数やＡＰＩ（Application Program Interface）等で実現されるものであり、例えば、図２に示した複数の制約種別の一つに対応付けられたものである。そして、検査モジュール５２３ａ、５２３ｂ、・・・及び５２３ｍは、対応付けられた制約種別に相当する処理が実装されている。例えば、検査モジュール５２３ａが「大小関係（ＧＥ）」に対応付けられている場合、検査モジュール５２３ａは、入力値が条件値以上であるか否かを判定し、入力値が条件値以上である場合に「ＯＫ」、入力値が条件値未満である場合に「ＮＧ」を戻り値とする処理が実装されていることとなる。そのため、報告情報登録モジュール５２２は、ある項目における制約条件４３３の制約種別から、検査モジュールのいずれかを選択し、当該項目の入力値と条件値とを選択された検査モジュールに入力し、戻り値により、当該入力値が制約条件を満たすか否かを判定することができる。

ＣＰＵ４１１は、報告情報収集サーバ４１における各種処理、ＲＡＭ４１２、ＲＯＭ４１３、通信部４１４及びハードディスク４１５へのアクセス等を制御する。通信部４１４は、データベース４２及び定義情報記憶部４３並びにネットワーク３を介して依頼部端末１、報告部端末２ａ、２ｂ、・・・及び２ｎとの通信を行う。報告情報収集サーバ４１は、ＣＰＵ４１１が、ＲＡＭ４１２、ＲＯＭ４１３又はハードディスク４１５に格納されたＯＳ５１０及び報告情報収集プログラム５２０を読み込み、実行する。これにより、報告情報収集サーバ４１は、定義情報登録処理及び報告情報登録処理を行うことができる。尚、報告情報収集サーバ４１は、複数台に分散して実現されても構わない。

図６は、本発明の実施の形態１にかかる報告情報収集処理の流れを示すシーケンス図である。まず、依頼部端末１は、入力形式ファイル及び定義情報ファイルを報告情報収集サーバ４１に対して送信し、登録要求を行う（Ｓ１１）。

次に、報告情報収集サーバ４１は、定義情報登録処理を行う（Ｓ１２）。すなわち、報告情報収集サーバ４１は、依頼部端末１から受け付けた入力形式ファイル及び定義情報ファイルについて検査を行い（Ｓ１２１）、その後、データベース４２内にテーブル４２１を作成する（Ｓ１２２）。尚、定義情報登録処理の詳細は、図７に後述する。

続いて、報告情報収集サーバ４１は、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれへ報告情報の入力依頼を通知する（Ｓ１３）。ここでは、報告情報収集サーバ４１は、通知に併せて、依頼部端末１から受け付けた入力形式ファイルを送信する。尚、報告情報収集サーバ４１は、必ずしも入力形式ファイルを送信しなくても構わない。その場合、通知を受けた報告部端末が、報告情報収集サーバ４１に対して入力形式ファイルの取得要求を行い、ダウンロードしてもよい。または、別途、ワークフローシステム等を介して依頼部端末１から入力形式ファイルを取得しても構わない。

そして、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれは、取得した入力形式ファイルに自己の部拠点における報告情報を入力する（Ｓ１４）。その後、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれは、入力済みファイルを報告情報収集サーバ４１に対して送信し、登録要求を行う（Ｓ１５）。

続いて、報告情報収集サーバ４１は、報告情報登録処理を行う（Ｓ１６）。すなわち、報告情報収集サーバ４１は、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれから受け付けた入力済みファイル及び当該ファイルに入力されたデータの検査を行い（Ｓ１６１）、報告情報を格納する（Ｓ１６２）。尚、報告情報登録処理の詳細は、図１１に後述する。

そして、報告情報収集サーバ４１は、依頼部端末１へ報告情報を登録した旨を通知する（Ｓ１７）。このとき、報告情報収集サーバ４１は、通知に併せて、入力済みファイルを送信してもよい。

これにより、依頼部の担当者は、データベース４２にアクセスすることによりテーブル４２１から各部拠点の報告情報を取得し、確認又は加工等の任意の処理を行うことができる。このとき、取得される報告情報は、定義情報４３１を満たすものであるため、依頼部の担当者によるデータ入力誤りの確認作業を必要とすることなく、正確な情報を得ることができる。

図７は、本発明の実施の形態１にかかる定義情報登録処理の流れを示すフローチャートである。まず、報告情報収集サーバ４１の定義情報登録手段５１は、依頼部端末１から入力形式ファイル及び定義情報ファイルを受け付ける（Ｓ２１）。

次に、定義情報登録手段５１は、ファイル制約及び２ファイル間の整合性を確認する（Ｓ２２）。ここで、ファイル制約の確認とは、入力形式ファイル及び定義情報ファイルそれぞれが、ファイル単体として形式を満たしているか否かを判定することをいう。入力形式ファイルの場合、ヘッダ領域６０１とデータ領域６０２とを備えているか否かを判定する。また、定義情報ファイルの場合、ヘッダ領域６０３と制約条件領域６０４とを備えているか否かを判定する。さらに、定義情報ファイルの場合、定義情報が図２を満たしているか否かの判定も含まれる。

また、２ファイル間の整合性の確認とは、入力形式ファイルと定義情報ファイルとについて、項目の名称及び順序が一致するか否かを判定することをいう。但し、項目の名称の重複を許可しないため、項目の順序については、必ずしも順序が一致しなくても構わない。尚、ファイル制約の確認及び２ファイル間の整合性の確認の実行順序については、これに限定されず、同時並行に実行しても構わない。

ステップＳ２２により整合性を満たしていないと判定された場合、定義情報登録手段５１は、登録要求元である依頼部端末１へエラーを通知する（Ｓ２５）。例えば、定義情報登録手段５１は、ファイル制約又は２ファイル間の整合性の内、満たしていない内容と該当する行列番号、セル位置等をエラーメッセージと共に通知する。

また、ステップＳ２２により整合性を満たしていると判定された場合、定義情報登録手段５１は、定義情報記憶部４３に定義情報４３１を登録する（Ｓ２３）。具体的には、まず、定義情報登録手段５１は、定義情報ファイルから項目情報４３２及び制約条件４３３を抽出する。そして、定義情報登録手段５１は、抽出した項目情報４３２及び制約条件４３３を定義情報記憶部４３に格納する。併せて、定義情報登録手段５１は、定義情報４３１と入力形式ファイルとを関連付けて定義情報記憶部４３へ格納する。

図８は、本発明の実施の形態１にかかる項目情報の例を示す図である。ヘッダ項目６１０は、フォーマット、バージョン、シートの各列であり、項目情報４３２と入力形式ファイルとを関連付けるための項目である。データ項目６１１は、項目情報４３２に対応する項目である。また、図９は、本発明の実施の形態１にかかる制約条件の例を示す図である。ヘッダ項目６１２は、ヘッダ項目６１０と同様の項目である。データ項目６１３は、制約条件４３３に対応する項目である。尚、ヘッダ項目６１０及び６１２の値は、ステップＳ２３において定義情報登録手段５１により生成される。

図７に戻り、その後、定義情報登録手段５１は、データベース４２内にテーブル４２１を作成する（Ｓ２４）。具体的には、定義情報登録手段５１は、項目情報４３２に含まれる項目の名称、順序、属性及び桁数を用いてテーブル４２１を作成する。つまり、定義情報登録手段５１は、テーブル４２１の作成において、定義情報４３１の全ての情報を用いず、定義情報４３１の一部である項目情報４３２を用いる。項目情報４３２は、定義情報４３１の内、テーブル４２１を作成するために最小限の情報である。そのため、項目情報４３２は、制約条件４３３に含まれる制約条件よりも制約が小さい。すなわち、テーブル４２１は、定義情報４３１により課される制約よりも小さい制約のテーブルとして作成される。尚、ステップＳ２３及びＳ２４の順序は、逆であっても、同時並行であっても構わない。

図１０は、本発明の実施の形態１にかかる作成されるテーブルの例を示す図である。キー項目６１４は、格納される報告情報４２２を一意に特定するための主キーの項目である。尚、キー項目６１４には、更新日時及び時刻の情報も含まれる。データ項目６１５は、報告情報４２２を格納するための項目である。

図１１は、本発明の実施の形態１にかかる報告情報登録処理の流れを示すフローチャートである。まず、報告情報収集サーバ４１の報告情報登録手段５２は、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれから報告情報の入力済みファイルを受け付ける（Ｓ３１）。図１２は、本発明の実施の形態１にかかる報告情報が入力済みの入力形式ファイルの例を示す図である。

次に、図１１に戻り、報告情報登録手段５２は、ファイル制約を確認する（Ｓ３２）。すなわち、報告情報登録手段５２は、入力済みファイルについて、図７のステップＳ２２におけるファイル制約の確認を行う。

ステップＳ３２によりファイル制約を満たしていると判定された場合、報告情報登録手段５２は、定義情報記憶部４３を参照し、入力形式を特定する（Ｓ３３）。すなわち、報告情報登録手段５２は、定義情報記憶部４３を参照し、入力済みファイルのヘッダ領域６０１に対応する表形式を特定する。

続いて、報告情報登録手段５２は、定義情報記憶部４３から定義情報４３１を取得する（Ｓ３４）。すなわち、報告情報登録手段５２は、特定された入力形式に関連付けられた定義情報４３１を定義情報記憶部４３から取得する。

そして、報告情報登録手段５２は、報告情報を検査する（Ｓ３５）。具体的には、まず、報告情報登録手段５２は、入力済みファイルのデータ領域６０２の先頭行から最終行について、各行の列ごと、すなわち処理対象の項目毎に入力値を取得する。次に、報告情報登録手段５２は、定義情報４３１に含まれる制約条件４３３から、処理対象の項目に対応する制約種別を特定する。そして、報告情報登録手段５２は、検査手段５３ａ、５３ｂ、・・・５３ｍの中から、特定された制約種別に対応する検査手段を選択する。その後、報告情報登録手段５２は、選択された検査手段に対して、取得した入力値と処理対象の項目の制約種別における条件値とを入力する。そして、報告情報登録手段５２は、当該検査手段から戻り値を検査結果として受け付ける。報告情報登録手段５２は、入力済みファイルのデータ領域６０２の全ての行列に対して、これらの処理を実行する。

その後、報告情報登録手段５２は、全ての検査結果が正常であるか否かを判定する（Ｓ３６）。すなわち、報告情報登録手段５２は、入力済みファイルのデータ領域６０２の全ての入力値が、制約条件４３３により課される制約を満たすか否かを検査する。

ステップＳ３６により全ての検査結果が正常であると判定された場合、報告情報登録手段５２は、報告情報４２２をデータベース４２のテーブル４２１に格納する（Ｓ３７）。図１３は、本発明の実施の形態１にかかるテーブルに格納されるデータの例を示す図である。図１３は、図１０の例に、図１２の入力値が報告情報として格納されたことを示す。このとき、テーブル４２１に格納されるデータは、テーブル４２１に課される制約よりも大きい制約を満たしたデータであるため、テーブル４２１の定義に反するデータは格納されず、報告情報自体に起因する格納時のエラーを防ぐことができる。そのため、今後、制約条件４３３の定義の内、項目情報４３２に関わらない部分が変更されたとしても、テーブル４２１の定義には影響を与えず、引き続き、報告情報を格納し続けることができる。尚、キー項目６１４の値は、ステップＳ３７において報告情報登録手段５２により生成される。

図１１に戻り、ステップＳ３２によりファイル制約を満たしていないと判定された場合、又は、ステップＳ３６によりいずれかの検査結果が正常でないと判定された場合、報告情報登録手段５２は、登録要求元である報告部端末２ａ、２ｂ、・・・及び２ｎのいずれかへエラーを通知する（Ｓ３８）。例えば、報告情報登録手段５２は、ファイル制約又は報告情報の内、満たしていない内容と該当する行列番号、セル位置等をエラーメッセージと共に通知する。

このように、本発明の実施の形態１により、所定の入力形式のファイルにより複数の報告情報を収集する場合において、報告情報の入力形式の変更に柔軟に対応することができる。テーブルの定義には、項目の名称、順序、属性及び桁数のみを用いるが、項目が必須であることなどは、テーブルの定義とすることが可能であるにもかかわらず、定義に用いていない。さらに、入力値の大小関係や関連項目の制約条件など複雑な制約条件について、トリガー等で設定しない。そのため、項目情報４３２に含まれない制約条件４３３を変更した場合は、システムの改修作業が不要となり、項目情報４３２を変更した場合は、データベースの再構築が不要となり、いずれの場合もシステム停止等は不要となる。また、制約条件４３３についての微修正についてもテーブルの定義には影響を与えずに変更することができる。

＜発明の実施の形態２＞
報告情報の仕様については、業務上、様々な変更の要望が起こり得る。そこで、報告情報を登録するためのテーブルの定義の変更が生じ得る。しかし、稼働中の情報システムにおけるデータベースのテーブルの定義を更新することは、本来、専門的な知識や豊富な運用経験を必要とするなど、難易度が高いものである。そのため、特許文献２のように、要求に応じて逐次、テーブルの定義の更新を自動的に行ってしまうと、テーブルに格納済みのデータとの間で不整合が生じるなど危険性が伴う。例えば、テーブルの属性の桁数を減らす場合、既に格納済みのデータに変更後の桁数を上回るデータがあると、単純に属性の変更を行うことはできない。また、データの入力が必須ではない属性について、データの入力が必須とする属性へ変更する場合、当該属性にデータが未入力のレコードが存在する場合もやはり単純に属性の変更を行うことはできない。これらの場合、予め格納済みのデータを調査し、システム作業等により必要な措置を取らなければならない。

また、報告情報の仕様が変更されたとしても、過去の入力されたデータを参照することは業務上あり得る。そのため、テーブルに格納済みのデータについても残し、変更後に参照可能とする必要がある。また、ユーザによる報告情報の仕様の管理を容易にさせるためにも、上述したように仕様変更に制限をかけることは望ましくない。そこで、本発明の実施の形態２では、報告情報の仕様の変更がテーブルの定義に影響を与える場合であっても、格納済みのデータを残しつつ、テーブルに格納済みのデータとの間で不整合が生じないようにテーブルの更新を行うものである。

具体的には、本発明の実施の形態２にかかる報告情報収集システムは、本発明の実施の形態１にかかる報告情報収集システム４の定義情報登録手段５１に変更を加えたものである。本発明の実施の形態２にかかる定義情報登録手段５１は、受け付けた定義情報４３１が複数の項目の一部の定義を変更する場合、テーブル４２１の当該変更される項目を末尾に移動し、変更後の項目を変更前の項目の位置に挿入するようにテーブル４２１を更新する。これにより、項目情報４３２の定義が変更された場合であっても、以前の項目を残すことができるため、過去のデータを参照し続けることができる。さらに、他からの参照などによるデータ不整合を防ぐことができる。また、頻繁な定義情報４３１の変更に対応できる。尚、本発明の実施の形態２にかかる報告情報収集システムは、本発明の実施の形態１と比べて、上述した以外の構成に変更がない。以下、実施の形態１との違いを中心に説明し、実施の形態１と同等の構成及び処理については、詳細な説明を省略する。

図１４は、本発明の実施の形態２にかかるテーブル更新処理の流れを示すフローチャートである。以下の説明において、図７又は図１１と同等の処理については、適宜、説明を省略する。まず、定義情報登録手段５１は、依頼部端末１から更新対象の入力形式ファイル及び定義情報ファイルを受け付ける（Ｓ４１）。

図１５は、本発明の実施の形態２にかかる項目を変更する場合の定義情報ファイルの例を示す図である。図１５の変更項目６０５は、上述の図４に示した定義情報ファイルの内、"ItemC"についての制約条件４３３が変更されたことを示す。また、図示を省略するが、入力形式ファイルについてもヘッダ領域６０１の項目が同様に変更される。

図１４に戻り、定義情報登録手段５１は、ファイル制約及び２ファイル間整合性を確認する（Ｓ４２）。ここでは、図７のステップＳ２２と同様に、受け付けたファイル自体についての確認を行う。また、ステップＳ４２によりファイル制約及び２ファイル間の整合性を満たしていないと判定された場合、定義情報登録手段５１は、ステップＳ２５と同様に、登録要求元である依頼部端末１へエラーを通知する（Ｓ４９）。

また、ステップＳ４２によりファイル制約及び２ファイル間の整合性を満たしていると判定された場合、定義情報登録手段５１は、図１１のステップＳ３３と同様に、入力形式を特定する（Ｓ４３）。

続いて、定義情報登録手段５１は、定義情報記憶部４３から更新前の定義情報４３１を取得する（Ｓ４４）。すなわち、定義情報登録手段５１は、特定された表形式に関連付けられた定義情報４３１を定義情報記憶部４３から取得する。

そして、定義情報登録手段５１は、更新前後の差分を抽出する（Ｓ４５）。具体的には、まず、定義情報登録手段５１は、受け付けた定義情報ファイルから更新後の項目情報４３２及び制約条件４３３を抽出する。次に、定義情報登録手段５１は、抽出した更新後の項目情報４３２及び制約条件４３３と、取得した更新前の定義情報４３１に含まれる項目情報４３２及び制約条件４３３とを比較し、差分を抽出する。

そして、定義情報登録手段５１は、更新の種類を判定する（Ｓ４６）。すなわち、まず、定義情報登録手段５１は、更新前後の項目情報４３２に差分があるか否かを判定し、差分があると判定した場合、項目が追加、削除、変更のいずれであるかを判定する。尚、差分が複数の項目に渡る場合は、項目毎にステップＳ４６、Ｓ４７１、Ｓ４７２、Ｓ４７３及びＳ４７４の処理を適宜、繰り返し実行する。例えば、図１５のように、"ItemC"の列位置に"ItemCC"が存在する場合は、"ItemC"が削除され、"ItemCC"が追加されたため、変更と判定する。尚、項目名が一致しても属性が変更しているか、桁数が減少しているなどの場合、定義情報登録手段５１は、受け付けた定義情報ファイルが適切でないものと判断して、ステップＳ４９と同様に、登録要求元である依頼部端末１へエラーを通知することが望ましい。または、項目名が一致しても桁数が増加する場合は、変更と判定しても構わない。すなわち、定義情報登録手段５１は、少なくとも格納済みのデータが保持されるような項目の変更については、変更と判定しても構わない。

ステップＳ４６により追加と判定された場合、定義情報登録手段５１は、差分の項目をテーブル４２１へ挿入する（Ｓ４７１）。すなわち、定義情報登録手段５１は、更新後の項目情報４３２の情報において追加された列位置に、列を挿入してデータベース４２内のテーブル４２１の定義を更新する。

ステップＳ４６により削除と判定された場合、定義情報登録手段５１は、差分の項目をテーブル４２１の末尾へ移動する（Ｓ４７２）。すなわち、定義情報登録手段５１は、更新後の項目情報４３２の情報において削除された項目の列位置をテーブル４２１における末尾の列位置へ移動する。すなわち、削除対象の項目であっても、実際には、削除をせずテーブル４２１内に残す。これにより、必要に応じて、過去のデータを再利用することができる。さらに、仮に削除対象の項目が他の項目における関連項目である場合や、他のテーブルとの間でリレーションシップが定義されていた場合などであっても、不整合を発生させることなく、テーブルの定義を更新することができる。

ステップＳ４６により変更と判定された場合、定義情報登録手段５１は、ステップＳ４７２と同様に、差分の項目をテーブル４２１の末尾へ移動する（Ｓ４７３）。すなわち、定義情報登録手段５１は、更新後の項目情報４３２の情報において変更された項目について、変更前の項目の列位置をテーブル４２１における末尾の列位置へ移動する。また、定義情報登録手段５１は、ステップＳ４７１と同様に、差分の項目をテーブル４２１へ挿入する（Ｓ４７４）。すなわち、定義情報登録手段５１は、更新後の項目情報４３２の情報において変更された列位置に、列を挿入してデータベース４２内のテーブル４２１の定義を更新する。つまり、変更前の項目の名称、属性又は桁数に変更を加えるのではなく、変更前の項目を列ごと末尾へ残し、変更後の項目を新たに追加する。これにより、過去のデータを参照することができる。また、格納済みのデータとの間で不整合が生じることを防ぐことができる。

尚、定義情報登録手段５１は、上記のステップＳ４６〜Ｓ４７４については、項目毎に、以下の処理に置き換えても構わない。まず、定義情報登録手段５１は、項目が削除されたか否かを判定し、削除されたと判定した場合に、ステップＳ４７２の処理を行う。その後、項目が追加されたか否かを判定し、追加されたと判定した場合に、ステップＳ４７１の処理を行う。これにより、上記の変更の場合、ステップＳ４７２の処理の後、ステップＳ４７１の処理が行われることとなり、上記のステップＳ４６〜Ｓ４７４と同じ結果が得られる。

この後、定義情報登録手段５１は、更新後の定義情報４３１により更新する（Ｓ４８）。すなわち、定義情報登録手段５１は、抽出した更新後の項目情報４３２及び制約条件４３３を定義情報記憶部４３に格納する。また、ステップＳ４６により更新前後の項目情報４３２に差分がないと判定された場合も、定義情報登録手段５１は、同様に更新後の定義情報４３１により更新する（Ｓ４８）。

図１６は、本発明の実施の形態２にかかるテーブルの項目の定義が変更された場合の例を示す図である。図１６は、図１３の例に、図１５の項目の変更が反映され、その後に、報告情報が追加登録されたことを示す。つまり、追加項目６０６の上位５行には、データがなく、下位２行のみにデータが格納される。一方、削除項目６０７には、上位５行に更新前のデータが残され、下位２行にはデータが格納されない。

以上のように、本発明の実施の形態２により、システム停止を行うことなく、テーブルの更新を行うことができる。

＜発明の実施の形態３＞
報告情報の種類は、多岐に渡るため、一ファイルに複数種類の報告情報を異なる入力形式により入力させたいというニーズがある。一方、同じ入力形式であっても、業種ごと等に別々に収集し、同一のテーブルに格納させたいというニーズもある。これらの場合、一ファイル内の複数のスプレッドシートにそれぞれ報告情報を入力させることが考えられる。そこで、本発明の実施の形態３にかかる報告情報収集システムは、一ファイルに複数のスプレッドシートを含み、各スプレッドシートにそれぞれ報告情報を入力させる場合を対象とする。

具体的には、本発明の実施の形態３にかかる報告情報収集システムは、本発明の実施の形態１にかかる報告情報収集システム４の定義情報登録手段５１及び報告情報登録手段５２に変更を加えたものである。まず、本発明の実施の形態３にかかる表形式のファイルは、複数の項目が同一である複数のスプレッドシートを含む。そして、本発明の実施の形態３にかかる報告情報登録手段５１は、複数のスプレッドシートに異なる報告情報が入力された表形式のファイルを受け付けた場合に、受け付けたファイルに入力されたスプレッドシート毎の報告情報を同一のテーブルに異なるレコードとして格納する。これにより、同一の入力形式の複数種類の報告情報をまとめて管理することができる。尚、本発明の実施の形態３にかかる報告情報収集システムは、本発明の実施の形態１と比べて、上述した以外の構成に変更がない。以下、実施の形態１との違いを中心に説明し、実施の形態１と同等の構成及び処理については、詳細な説明を省略する。

図１７は、本発明の実施の形態３にかかる定義情報登録処理の流れを示すフローチャートである。以下の説明において、図７と同等の処理については、適宜、説明を省略する。まず、定義情報登録手段５１は、依頼部端末１から複数シートの入力形式ファイル及び定義情報ファイルを受け付ける（Ｓ５１）。

図１８は、本発明の実施の形態３にかかる複数シートの入力形式ファイルの例を示す図である。図１８（ａ）は、入力形式ファイルの先頭のシートであるシート６２０の例である。また、図１８（ｂ）は、二番目のシートであるシート６２１の例である。ここでは、シート６２０及び６２１は、同一の入力形式であるものとする。つまり、ヘッダ領域６０１における項目の名称及び順序が共通している。

図１９は、本発明の実施の形態３にかかる複数シートで共通のテーブルを使用する場合の定義情報ファイルの例を示す図である。図１９（ａ）は、定義情報ファイルの先頭のシートであるシート６２２の例である。図１９（ｂ）は、定義情報ファイルの二番目のシートであるシート６２３の例である。特に、シート６２３は、ヘッダ領域６０１の１行目にテーブルタイプ６２４を含む。ここでは、"Ｓ"が入力されることにより、シート６２３の以下の定義は、シート６２２と同等であることを示し、シート６２３内の定義は無視される。そのため、シート６２３は、テーブルタイプ６２４以外の定義は不要となる。尚、テーブルタイプ６２４に"Ｓ"以外が入力されている場合は、他のシートとは独立した報告情報の定義情報として認識される。

尚、図１８の入力形式ファイルにおける"Work1"というシートは、報告情報が入力されないワークシートである。そのため、図１９の定義情報ファイルにおける"Work1"というシートには、当該シートが報告情報の入力対象外として扱う旨を定義する。例えば、スプレッドシートにテーブルタイプ６２４自体が設定されていないことにより、ワークシートとして扱うようにするとよい。つまり、本発明の実施の形態３にかかる入力形式ファイル及び定義情報ファイルは、複数のスプレッドシートの内、報告情報が入力されないワークシートを含んでも構わない。

図１７に戻り、定義情報登録手段５１は、ファイル制約及び２ファイル間のシート名の整合性を確認する（Ｓ５２）。ここでは、まず、ファイル制約の確認として、定義情報登録手段５１は、各ファイルのシートの名称やシート単独の記載が形式を満たしているか否かを判定する。次に、２ファイル間のシート名の整合性の確認として、定義情報登録手段５１は、入力形式ファイルと定義情報ファイルとについて、シートの名称及び順序が一致するか否かを判定する。尚、ファイル制約の確認及び２ファイル間のシート名の整合性の確認の実行順序については、これに限定されず、同時並行に実行しても構わない。また、定義情報登録手段５１は、ワークシートについてはシート名以外の整合性の確認を行わないものとする。

ステップＳ５２により整合性を満たしていると判定された場合、定義情報登録手段５１は、複数シートで共通の形式であるか否かを判定する（Ｓ５３）。具体的には、定義情報登録手段５１は、受け付けた定義情報ファイルのテーブルタイプ６２４に"Ｓ"が入力されているか否かを判定する。

ステップＳ５３により複数シートで共通の形式であると判定された場合、定義情報登録手段５１は、入力形式ファイルのシート間の項目の整合性を確認する（Ｓ５４ａ）。例えば、定義情報登録手段５１は、図１８のシート６２０及び６２１の項目が整合性を満たすか否かを判定する。

ステップＳ５４ａにより整合性を満たすと判定された場合、定義情報登録手段５１は、定義情報ファイルの先頭シートと入力形式ファイルの全シートとの項目の整合性を確認する（Ｓ５５ａ）。例えば、定義情報登録手段５１は、図１９のシート６２２の項目と、図１８のシート６２０及び６２１の項目とが整合性を満たすか否かを判定する。

ステップＳ５５ａにより整合性を満たすと判定された場合、定義情報登録手段５１は、先頭シートの定義情報を登録する（Ｓ５６ａ）。具体的には、まず、定義情報登録手段５１は、定義情報ファイルのシート６２２から項目情報４３２及び制約条件４３３を抽出する。そして、定義情報登録手段５１は、抽出した項目情報４３２及び制約条件４３３を定義情報記憶部４３に格納する。併せて、定義情報登録手段５１は、定義情報４３１と入力形式ファイルとを関連付けて定義情報記憶部４３へ格納する。

その後、定義情報登録手段５１は、データベース４２内にシート間で共通のテーブル４２１を作成する（Ｓ５７ａ）。具体的には、定義情報登録手段５１は、先頭シートの項目情報４３２に含まれる項目の名称、順序、属性及び桁数を用いてテーブル４２１を作成する。

一方、ステップＳ５３により複数シートで共通の形式でないと判定された場合、定義情報登録手段５１は、２ファイル間のシート毎の項目の整合性を確認する（Ｓ５４ｂ）。例えば、定義情報登録手段５１は、入力形式ファイルと定義情報ファイルの１番目のシート同士の項目の整合性を確認し、続いて、２番目、３番目、・・・最終シート同士の項目が整合性を満たすか否かを判定する。

ステップＳ５４ｂにより整合性を満たすと判定された場合、定義情報登録手段５１は、シートごとに定義情報を登録する（Ｓ５６ｂ）。具体的には、まず、定義情報登録手段５１は、定義情報ファイルの各シートから項目情報４３２及び制約条件４３３を抽出する。そして、定義情報登録手段５１は、抽出した項目情報４３２及び制約条件４３３を定義情報記憶部４３に格納する。併せて、定義情報登録手段５１は、各シートの定義情報４３１と入力形式ファイルの各シートとを関連付けて定義情報記憶部４３へ格納する。

その後、定義情報登録手段５１は、データベース４２内のシートごとに異なるテーブル４２１を作成する（Ｓ５７ｂ）。具体的には、定義情報登録手段５１は、各シートの項目情報４３２に含まれる項目の名称、順序、属性及び桁数を用いてそれぞれのテーブル４２１を作成する。尚、ステップＳ５６ｂ及びＳ５７ｂの処理は、シート単位にまとめて実行し、全てのシートについて繰り返しても構わない。

尚、ステップＳ５２、Ｓ５４ａ、Ｓ５５ａ又はＳ５４ｂにより整合性を満たさないと判定された場合、定義情報登録手段５１は、ステップＳ２５と同様に、登録要求元である依頼部端末１へエラーを通知する（Ｓ５８）。

図２０は、本発明の実施の形態３にかかる報告情報登録処理の流れを示すフローチャートである。以下の説明において、図１１又は図１７と同等の処理については、適宜、説明を省略する。まず、報告情報登録手段５２は、報告部端末２ａ、２ｂ、・・・及び２ｎのそれぞれから報告情報の複数シートの入力済みファイルを受け付ける（Ｓ６１）。

次に、報告情報登録手段５２は、ファイル制約を確認する（Ｓ６２）。すなわち、報告情報登録手段５２は、入力済みファイルのシートの名称やシート単独の記載が形式を満たしているか否かを判定する。ステップＳ６２によりファイル制約を満たしていると判定された場合、報告情報登録手段５２は、定義情報記憶部４３を参照し、入力形式を特定する（Ｓ６３）。

続いて、報告情報登録手段５２は、複数シートで共通の形式であるか否かを判定する（Ｓ６４）。例えば、報告情報登録手段５２は、定義情報記憶部４３を参照し、特定された入力形式が複数シートで共通の形式であるか否かを判定する。

ステップＳ６４により複数シートで共通の形式であると判定された場合、報告情報登録手段５２は、定義情報記憶部４３から全シートに共通の定義情報４３１を取得する（Ｓ６５ａ）。すなわち、報告情報登録手段５２は、特定された入力形式に関連付けられた定義情報４３１を定義情報記憶部４３から取得する。

続いて、報告情報登録手段５２は、共通の定義情報により全シートの報告情報を検査する（Ｓ６６ａ）。例えば、報告情報登録手段５２は、各シートに共通の定義情報を用いて、ステップＳ３５と同様の処理を実行する。その後、報告情報登録手段５２は、ステップＳ３６と同様に、全ての検査結果が正常であるか否かを判定する（Ｓ６７ａ）。ステップＳ６７ａにより全ての検査結果が正常であると判定された場合、報告情報登録手段５２は、全シートの報告情報をデータベース４２の共通のテーブルに格納する（Ｓ６８ａ）。

一方、ステップＳ６４により複数シートで共通の形式でないと判定された場合、報告情報登録手段５２は、シート毎に異なる定義情報を取得する（Ｓ６５ｂ）。続いて、報告情報登録手段５２は、シート毎の定義情報により各シートの報告情報を検査する（Ｓ６６ｂ）。その後、報告情報登録手段５２は、ステップＳ３６と同様に、全ての検査結果が正常であるか否かを判定する（Ｓ６７ｂ）。ステップＳ６７ｂにより全ての検査結果が正常であると判定された場合、報告情報登録手段５２は、各シートの報告情報をシート毎のテーブルに格納する（Ｓ６８ｂ）。尚、ステップＳ６５ｂ乃至Ｓ６８ｂの処理は、シート単位にまとめて実行し、全てのシートについて繰り返しても構わない。

尚、ステップＳ６２、Ｓ６７ａ又はＳ６７ｂによりファイル制約又は整合性を満たさないと判定された場合、報告情報登録手段５２は、ステップＳ３８と同様に、登録要求元である報告部端末２ａ、２ｂ、・・・及び２ｎのいずれかへエラーを通知する（Ｓ６９）。

以上のように、発明の実施の形態３により、一ファイルに複数のスプレッドシートを含み、各スプレッドシートにそれぞれ報告情報を入力させる場合に対応することができ、依頼部及び報告部において複数の入力形式ファイルを使い分けるといった処理の煩雑さを軽減することができる。

＜発明の実施の形態４＞
企業における部拠点が複数の国に存在する場合、各報告部において使用される言語が異なる場合がある。このとき、業務上は、同一の種類の報告情報であっても、入力形式ファイル及びその定義情報ファイルは、言語ごとに個別に定義する必要がある。一方、言語が異なったとしても、報告情報の種類としては同一であるため、共通のテーブルにて管理したいというニーズがある。そこで、本発明の実施の形態４にかかる報告情報収集システムは、複数の言語による報告情報を収集する場合を対象とする。

具体的には、本発明の実施の形態４にかかる報告情報収集システムは、本発明の実施の形態１にかかる報告情報収集システム４の定義情報登録手段５１及び報告情報登録手段５２に変更を加えたものである。本発明の実施の形態４にかかる定義情報登録手段５１は、第１の言語に基づく項目情報及び制約条件を含む第１定義情報と、当該第１の言語に基づく項目情報及び制約条件に対応し、当該第１の言語とは異なる第２の言語に基づく項目情報及び制約条件を含む第２定義情報とを受け付けた場合に、当該第１の言語に基づく項目情報を用いてデータベース４２内にテーブル４２１を生成し、当該受け付けた第１定義情報及び第２定義情報を定義情報記憶部４３へ格納する。そして、本発明の実施の形態４にかかる報告情報登録手段５２は、第２の言語に基づく報告情報が入力された表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報を、第１の言語に基づく項目情報に対応付けてテーブル４２１に格納する。これにより、異なる言語で共通する報告情報をまとめて管理することができる。

図２１は、本発明の実施の形態４にかかる二言語の定義情報登録処理の流れを示すフローチャートである。以下の説明において、図７又は図１７と同等の処理については、適宜、説明を省略する。まず、定義情報登録手段５１は、二言語の入力形式ファイル及び定義情報ファイルを受け付ける（Ｓ７１）。例えば、日本語を第１の言語、英語を第２の言語とした場合を考える。日本語の定義情報ファイルは、日本語に基づく項目情報及び制約条件を含む第１の定義情報である。英語の定義情報ファイルは、英語に基づく項目情報及び制約条件を含む第２の定義情報である。つまり、ここでは、日英の二言語による入力形式ファイル及び定義情報ファイルを受け付けるため、ここでは、４ファイルを受け付けることとなる。但し、入力形式ファイルにおける日本語に基づく項目情報及び英語に基づく項目情報は、項目の名称については、上述したようにＡＳＣＩＩ文字により表現されているものとし、各項目の説明や入力値の例の表現が各言語であるものとする。

図２２は、本発明の実施の形態４にかかる二言語の入力形式を扱う処理の概念を示す図である。図２２（ａ）は、二言語の入力形式で共通のテーブルを作成する場合の例である。ステップＳ７１では、まず、定義情報登録手段５１は、日本語の入力形式ファイルＦＡ及び定義情報ファイルＤｅｆＡ並びに英語の入力形式ファイルＦＢ及び定義情報ファイルＤｅｆＢを受け付ける。

次に、定義情報登録手段５１は、ファイル制約及び同一言語内の入力形式ファイルと定義情報ファイル間の整合性を確認する（Ｓ７２）。具体的には、まず、定義情報登録手段５１は、４ファイルそれぞれがファイル単体として形式を満たしているか否かを判定する。次に、定義情報登録手段５１は、日本語である入力形式ファイルＦＡと定義情報ファイルＤｅｆＡとが整合性及び英語である入力形式ファイルＦＢと定義情報ファイルＤｅｆＢとが整合性を満たしているか否か判定する。

ステップＳ７２により整合性を満たしていると判定された場合、定義情報登録手段５１は、二言語のファイル間の整合性を確認する（Ｓ７３）。具体的には、まず、定義情報登録手段５１は、入力形式ファイルＦＡと入力形式ファイルＦＢとの項目の名称及び順序が一致するか、シート間の整合性を満たすか否かを判定する。次に、定義情報登録手段５１は、定義情報ファイルＤｅｆＡと定義情報ファイルＤｅｆＢとの項目情報が一致するか、シート間の整合性を満たすか否かを判定する。

ステップＳ７３により整合性を満たしていると判定された場合、定義情報登録手段５１は、二言語分の定義情報を登録する（Ｓ７４）。具体的には、まず、定義情報登録手段５１は、定義情報ファイルＤｅｆＡ及びＤｅｆＢからそれぞれ項目情報４３２及び制約条件４３３を抽出する。そして、定義情報登録手段５１は、抽出した項目情報４３２及び制約条件４３３を言語に対応付けて定義情報記憶部４３に定義情報４３１Ａ及び４３１Ｂとして格納する。併せて、定義情報登録手段５１は、日英の定義情報４３１と入力形式ファイルＦＡ及びＦＢとを関連付けて定義情報記憶部４３へ格納する。

続いて、定義情報登録手段５１は、一言語の定義情報によりテーブル４２１を作成する（Ｓ７５）。例えば、定義情報登録手段５１は、日本語の定義情報である定義情報４３１Ａによりデータベース４２内にテーブル４２１を作成する。これにより、複数の言語による定義情報であっても、同一のテーブルに対応付けられる。

尚、ステップＳ７２又はＳ７３により整合性を満たさないと判定された場合、定義情報登録手段５１は、ステップＳ５８と同様に、登録要求元である依頼部端末１へエラーを通知する（Ｓ７６）。

図２２（ｂ）は、二言語の報告情報を共通のテーブルに格納する場合である。例えば、日本語の報告情報ＲＡが入力された入力済みファイルを受け付けた場合、テーブル４２１が日本語の定義情報４３１Ａにより作成されているため、報告情報登録手段５２は、テーブル４２１に報告情報４２２Ａとして格納する。一方、英語の報告情報ＲＢが入力された入力済みファイルを受け付けた場合であっても、報告情報登録手段５２は、英語の報告情報ＲＢを日本語の定義情報４３１Ａに含まれる項目情報に対応付けて、同一のテーブル４２１に報告情報４２２Ｂとして格納する。

以上のように、本発明の実施の形態４により、異なる言語で共通する報告情報をまとめて管理することができる。

＜発明の実施の形態５＞
上述した本発明の実施の形態１乃至４における入力形式ファイルは、報告部端末２ａ、２ｂ、・・・及び２ｎを用いて各担当者により報告情報が入力されるものである。そのため、各報告部の担当者が入力する際に、入力形式を維持したまま報告情報が入力される保証がない。上述した本発明の実施の形態１乃至４では、報告情報の種類に依存するいわば業務上の制約条件について満たさないデータを検出するものであった。しかしながら、表計算ソフトを用いて入力形式ファイルを編集する場合、例えば、行又は列を非表示にして保存することが可能である。この場合、依頼部の担当者が収集された入力済みファイル自体を直接閲覧する場合、非表示にされた行又は列を見落とす可能性がある。また、非表示にされた行又は列に入力された値は、入力者自身が見落とす場合が多く、本来削除すべきデータが残っているなど、データの内容として誤りである可能性も高い。従来は、これらを防ぐため、依頼部の担当者が目視により非表示の行又は列を検出していたため、大変煩雑な作業であり、見落としもあった。また、非表示の行に入力された誤ったデータがそのまま登録されてしまうという問題もあった。そこで、本発明の実施の形態５では、上述した目視確認の煩雑さを解消することを目的とする。

具体的には、本発明の実施の形態５にかかる報告情報収集システムは、本発明の実施の形態１にかかる報告情報収集システム４の報告情報登録手段５２に変更を加えたものである。まず、本発明の実施の形態５にかかる表形式のファイルは、複数の項目を列方向に定義し、報告情報を行方向に入力させる形式であるものとする。そして、本発明の実施の形態５にかかる報告情報登録手段５２は、受け付けたファイル内の報告情報が入力されるべき行に、行の高さが所定値以下である行が存在するか否かを判定し、存在すると判定された場合、その旨を当該受け付けたファイルの入力元へ通知する。これにより、入力元の報告部により通知された行について確認することができ、適宜、修正を行うことができる。そのため、依頼部の担当者による目視確認の煩雑さを解消することができる。尚、本発明の実施の形態５にかかる報告情報収集システムは、本発明の実施の形態１と比べて、上述した以外の構成に変更がない。以下、実施の形態１との違いを中心に説明し、実施の形態１と同等の構成及び処理については、詳細な説明を省略する。

まず、本発明の実施の形態５の実施例１について説明する。実施例１にかかる報告情報登録手段５２は、受け付けたファイルの内、可視行であることを示す情報が設定された行数が、全行数未満である場合に、非表示行が存在すると判定する。表計算ソフトで編集可能な表形式のファイルには、各行の属性として行の高さと共に、可視行であることを示す情報がフラグ情報として設定されている。そのため、報告情報登録手段５２は、各行が非表示行であるか否かを判定する場合に、全ての行の高さを確認することに比べて、判定処理を高速に行うことができる。

図２３は、本発明の実施の形態５の実施例１にかかる非表示行を検出する報告情報登録処理の流れを示すフローチャートである。以下の説明において、図１１と同等の処理については、同一の符号を付し、適宜、説明を省略する。まず、報告情報登録手段５２は、ステップＳ３１及びＳ３２の処理を実行する。ステップＳ３２によりファイル制約を満たしていないと判定された場合、ステップＳ３８の処理を実行する。

ステップＳ３２によりファイル制約を満たしていると判定された場合、報告情報登録手段５２は、入力済みファイルの全行数Ｘをカウントする（Ｓ８１）。続いて、報告情報登録手段５２は、入力済みファイルの可視行数Ｙをカウントする（Ｓ８２）。具体的には、報告情報登録手段５２は、上述したように、入力済みファイルの各行の属性から可視行であることを示す情報であるフラグ情報をカウントする。尚、ステップＳ８１及びＳ８２の処理は、並列に実行しても構わない。

その後、報告情報登録手段５２は、全行数Ｘが可視行数Ｙより大きいか否かを判定する（Ｓ８３）。ステップＳ８３により全行数Ｘが可視行数Ｙより大きいと判定された場合、報告情報登録手段５２は、入力元である報告部端末２ａ、２ｂ、・・・２ｎのいずれかへ入力済みファイルに非表示行が存在する旨を通知する（Ｓ８４）。

ステップＳ８３により全行数Ｘが可視行数Ｙより大きくないと判定された場合、報告情報登録手段５２は、図１１のステップＳ３３乃至Ｓ３５（Ｓ８５）、Ｓ３６及びＳ３７又はＳ３８を実行する。可視行数Ｙが全行数Ｘを上回ることはないため、全行数Ｘと可視行数Ｙとが等しく、非表示行がないといえるからである。

このように、本発明の実施の形態５の実施例１により簡易な方法で非表示行の判定を行うことができるため、報告情報登録処理を高速に実行することができる。

続いて、本発明の実施の形態５の実施例２について説明する。実施例１では、非表示行ではないが、行の高さが目視で判別困難な高さである場合には検出できない。行の高さが目視で判別困難な高さである行は、実質的には、非表示行と同じといえる。そこで、実施例２にかかる報告情報登録手段５２は、受け付けたファイル内の報告情報が入力されるべき行に入力された文字の属性に応じて、所定値を行ごとに決定し、各行の高さが当該行ごとに決定された所定値であるか否かを判定する。これにより、非表示行、つまり、行自体が完全に見えない場合でなくとも、依頼部の担当者による目視確認し難い行を検出することができる。

図２４は、本発明の実施の形態５の実施例２にかかる入力形式ファイルの行の制約違反を検出する報告情報登録処理の流れを示すフローチャートである。以下の説明において、図１１と同等の処理については、同一の符号を付し、適宜、説明を省略する。まず、報告情報登録手段５２は、ステップＳ３１及びＳ３２の処理を実行する。ステップＳ３２によりファイル制約を満たしていないと判定された場合、ステップＳ３８の処理を実行する。

ステップＳ３２によりファイル制約を満たしていると判定された場合、報告情報登録手段５２は、入力済みファイルの先頭行を選択する（Ｓ９１）。ここで、先頭行とは、入力済みファイル内の報告情報が入力されるべき行、つまり、ヘッダ領域６０１の先頭行であるものとする。次に、報告情報登録手段５２は、選択行内にデータが存在するか否かを判定する（Ｓ９２）。ステップＳ９２により選択行内にデータが存在すると判定された場合、報告情報登録手段５２は、選択行の文字属性に応じて比較値Ｚを決定する（Ｓ９３）。例えば、文字属性としては、フォントのサイズがある。その場合、報告情報登録手段５２は、当該フォントにおける標準的な文字の高さ又は当該標準的な文字の高さより少し大きい値を比較値Ｚとして決定してもよい。

続いて、報告情報登録手段５２は、選択行の高さＨが比較値Ｚより小さいか否かを判定する（Ｓ９４）。ステップＳ９４により選択行の高さＨが比較値Ｚより小さいと判定された場合、報告情報登録手段５２は、選択行をエラーとする（Ｓ９５）。例えば、ＲＡＭ４１２内に当該選択行の行番号と対応付けてエラーフラグを保持するとよい。その後、報告情報登録手段５２は、選択行が最終行であるか否かを判定する（Ｓ９６）。

ステップＳ９２により選択行内にデータが存在すると判定された場合、ステップＳ９４により選択行の高さＨが比較値Ｚ以上と判定された場合、又は、ステップＳ９６により選択行が最終行でないと判定された場合、報告情報登録手段５２は、次の行を選択する（Ｓ９７）。そして、ステップＳ９２以降を実行し、選択行が最終行となるまで繰り返す。

ステップＳ９６により選択行が最終行であると判定された場合、報告情報登録手段５２は、入力済みファイルの各行のいずれかにエラーがあったか否かを判定する（Ｓ９８）。すなわち、報告情報登録手段５２は、入力済みファイル内に行の高さが目視で判別困難な高さである行が存在するか否かを判定する。例えば、報告情報登録手段５２は、ＲＡＭ４１２を参照し、エラーフラグが存在するか否かを判定する。

ステップＳ９８により、エラーがあったと判定された場合、報告情報登録手段５２は、入力元である報告部端末２ａ、２ｂ、・・・２ｎのいずれかへ入力済みファイルに目視で判別困難な行が存在する旨をエラー通知し、非表示行の高さを比較値Ｚとし、強調して表示するように指示する（Ｓ９９）。言い換えると、報告情報登録手段５２は、通知する場合に、行の高さが所定値以下である行を所定値の高さとし、かつ、当該行を強調して表示する。

図２５は、本発明の実施の形態５の実施例２にかかる強調表示の例を示す図である。ここでは、入力済みファイルの内６行目が非表示又は目視で判別困難であった場合とする。そして、実施例２にかかる報告情報登録手段５２により、６行目が所定の高さかつ他のセルと異なる背景色により強調表示６３０として入力元の報告部端末において表示されることを示す。これにより、報告部の担当者は、該当行を容易に認識し、該当行のデータが適切なものか判断し、誤っていれば修正又は行ごと削除等の対応をすることができる。

図２４に戻り、ステップＳ９８によりエラーがなかったと判定された場合、報告情報登録手段５２は、図１１のステップＳ３３乃至Ｓ３５（Ｓ８５）、Ｓ３６及びＳ３７又はＳ３８を実行する。

尚、上述した図２４のステップＳ９２及びＳ９４を言い換えると、報告情報登録手段５２は、受け付けたファイル内の報告情報が入力されるべき行の高さが所定値以下であり、かつ、当該行にデータが入力されていない場合には、前記判定の対象から除く。これにより、報告情報でない行を検出しなくなり、判定処理を高速に行うことができる。

以上のように、本発明の実施の形態５により、報告情報として正常なデータをテーブル４２１に格納することができる。また、依頼部の担当者による目視確認の煩雑さを解消することができる。

＜その他の発明の実施の形態＞
尚、上述した発明の実施の形態１では、入力形式ファイルの登録を行っていたが、必ずしも入力形式ファイル自体を登録しなくても構わない。その場合、依頼部端末１は、少なくとも定義情報ファイルに含まれる定義情報を報告情報収集システム４へ送信すればよい。そして、定義情報登録手段５１は、項目の名称、順序及び配置等のヘッダ領域６０１に関する情報を定義情報４３１と関連付けて定義情報記憶部４３へ格納してもよい。また、入力形式ファイルについて、例えば、依頼部端末１は、一般的なワークフローシステムの機能や電子メール等を用いて、報告部端末２ａ、２ｂ、・・・及び２ｎへ入力形式ファイルを配布するようにしてもよい。

または、報告情報収集システム４が定義情報４３１に含まれる項目情報４３２に基づいて入力形式ファイルを自動生成し、報告部端末２ａ、２ｂ、・・・２ｎに提供しても構わない。これにより、依頼部の担当者は、入力形式ファイルを作成する必要がなく、少なくとも定義情報４３１を作成し、登録要求すればよくなる。そのため、報告情報の収集業務全体の効率が向上する。また、これに伴い、定義情報登録手段５１において、２ファイル間の整合性の確認処理や入力形式ファイルと定義情報との関連付け処理等が不要となり、処理効率が高まる。

尚、上述した発明の実施の形態１にかかる定義情報ファイルは、必ずしも表形式のファイルである必要はない。定義情報ファイルは、ＣＳＶ（Comma Separated Values）、ＸＭＬ（Extensible Markup Language）等の形式であってもよく、少なくとも定義情報の内容が含まれていればよい。この場合、定義情報を汎用的に用いることができる。

尚、上述した発明の実施の形態１乃至５にかかる定義情報ファイルは、ヘッダ領域６０３に、入力形式ファイルのデータ領域６０２の開始行を指定する情報を含んでも構わない。これにより、入力形式ファイルごとに任意のデータ領域６０２を設定することができる。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

１ 依頼部端末
２ａ 報告部端末
２ｂ 報告部端末
２ｎ 報告部端末
３ ネットワーク
４ 報告情報収集システム
４１ 報告情報収集サーバ
４１１ ＣＰＵ
４１２ ＲＡＭ
４１３ ＲＯＭ
４１４ 通信部
４１５ ハードディスク
４２ データベース
４２１ テーブル
４２２ 報告情報
４２２Ａ 報告情報
４２２Ｂ 報告情報
４３ 定義情報記憶部
４３１ 定義情報
４３１Ａ 定義情報
４３１Ｂ 定義情報
４３２ 項目情報
４３３ 制約条件
５０ 制御部
５１ 定義情報登録手段
５２ 報告情報登録手段
５３ａ 検査手段
５３ｂ 検査手段
５３ｍ 検査手段
５１０ ＯＳ
５２０ 報告情報収集プログラム
５２１ 定義情報登録モジュール
５２２ 報告情報登録モジュール
５２３ａ 検査モジュール
５２３ｂ 検査モジュール
５２３ｍ 検査モジュール
６０１ ヘッダ領域
６０２ データ領域
６０３ ヘッダ領域
６０４ 制約条件領域
６０５ 変更項目
６０６ 追加項目
６０７ 削除項目
６１０ ヘッダ項目
６１１ データ項目
６１２ ヘッダ項目
６１３ データ項目
６１４ キー項目
６１５ データ項目
６２０ シート
６２１ シート
６２２ シート
６２３ シート
６２４ テーブルタイプ
６３０ 強調表示
ＦＡ 入力形式ファイル
ＦＢ 入力形式ファイル
ＤｅｆＡ 定義情報ファイル
ＤｅｆＢ 定義情報ファイル
ＲＡ 報告情報
ＲＢ 報告情報

Claims (15)

1. 複数の項目を含む表形式のファイルに入力された報告情報を収集する報告情報収集システムであって、
   前記報告情報を管理するためのデータベースと、
   前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、
   前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成し、当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報登録手段と、
   前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定し、前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報登録手段と、
   を備える報告情報収集システム。
2. 前記定義情報登録手段は、前記定義情報の更新を受け付けた場合に、当該更新が前記第２の制約条件にかかるものであるときには前記テーブルを更新せず、当該更新後の定義情報により前記定義情報記憶部を更新することを特徴とする請求項１に記載の報告情報収集システム。
3. 前記制約条件は、前記複数の項目のそれぞれについて、項目に課される制約の定義を含み、
   前記報告情報収集システムは、任意の項目に入力されるデータが、複数の前記制約の定義のいずれかに対応する制約を満たすか否かを検査する複数の検査手段をさらに備え、
   前記報告情報登録手段は、
   前記定義情報記憶部に格納された定義情報に含まれる前記制約条件を参照し、当該受け付けたファイルに含まれる項目から当該項目に課される制約の定義を特定し、
   前記複数の検査手段の中から、当該特定された制約の定義に対応する制約を検査する検査手段を選択し、
   当該選択された検査手段を用いて当該項目に入力されたデータを検査することを特徴とする請求項２に記載の報告情報収集システム。
4. 前記制約条件は、前記複数の項目の一部に入力される値に基づいて他の項目に入力されるデータを制限する条件を含むことを特徴とする請求項２又は３に記載の報告情報収集システム。
5. 前記表形式のファイルは、前記複数の項目が同一である複数のスプレッドシートを含み、
   前記報告情報登録手段は、前記複数のスプレッドシートに異なる報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力されたスプレッドシート毎の報告情報を同一の前記テーブルに異なるレコードとして格納することを特徴とする請求項１乃至４のいずれか１項に記載の報告情報収集システム。
6. 前記定義情報登録手段は、第１の言語に基づく前記複数の項目を定義した項目情報及び当該複数の項目に入力されるデータに課される制約条件を含む第１定義情報と、当該第１の言語に基づく項目情報及び制約条件に対応し、当該第１の言語とは異なる第２の言語に基づく前記複数の項目を定義した項目情報及び当該複数の項目に入力されるデータに課される制約条件を含む第２定義情報とを受け付けた場合に、当該第１の言語に基づく項目情報を用いて前記データベース内に前記テーブルを生成し、当該受け付けた第１定義情報及び第２定義情報を前記定義情報記憶部へ格納し、
   前記報告情報登録手段は、前記第２の言語に基づく報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報を、前記第１の言語に基づく項目情報に対応付けて前記テーブルに格納することを特徴とする請求項１乃至５のいずれか１項に記載の報告情報収集システム。
7. 前記定義情報登録手段は、前記報告情報が入力されていない前記表形式のファイルをさらに受け付けた場合、当該受け付けたファイルと前記受け付けた定義情報とが前記第１の制約条件において一致するか否かを判定し、一致すると判定された場合に、前記受け付けた定義情報の一部を用いて前記テーブルを前記データベース内に生成し、前記受け付けた定義情報と当該受け付けたファイルの表形式とを関連付けて前記定義情報記憶部へ格納し、複数の報告元へ前記報告情報の要求を送信し、
   前記報告情報登録手段は、前記複数の報告元のそれぞれから、前記報告情報が入力された複数の前記表形式のファイルを受け付けた場合に、当該受け付けた複数のファイルの表形式と関連付けられた定義情報を前記定義情報記憶部から特定し、当該受け付けた複数のファイルが当該特定された定義情報を満たすか否かを判定することを特徴とする請求項１乃至５のいずれか１項に記載の報告情報収集システム。
8. 前記定義情報登録手段は、前記受け付けた定義情報が前記複数の項目の一部の定義を変更する場合、前記テーブルの当該変更される項目を末尾に移動し、変更後の項目を変更前の項目の位置に挿入するように前記テーブルを更新することを特徴とする請求項１乃至６のいずれか１項に記載の報告情報収集システム。
9. 前記表形式のファイルは、前記複数の項目を列方向に定義し、前記報告情報を行方向に入力させる形式であり、
   前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行に、行の高さが所定値以下である行が存在するか否かを判定し、存在すると判定された場合、その旨を当該受け付けたファイルの入力元へ通知することを特徴とする請求項１乃至８のいずれか１項に記載の報告情報収集システム。
10. 前記報告情報登録手段は、前記受け付けたファイルの内、可視行であることを示す情報が設定された行数が、全行数未満である場合に、前記行の高さが所定値以下である行が存在すると判定することを特徴とする請求項９に記載の報告情報収集システム。
11. 前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行に入力された文字の属性に応じて前記所定値を行ごとに決定し、各行の高さが当該行ごとに決定された所定値であるか否かを判定することを特徴とする請求項９に記載の報告情報収集システム。
12. 前記報告情報登録手段は、前記受け付けたファイル内の前記報告情報が入力されるべき行の高さが所定値以下であり、かつ、当該行にデータが入力されていない場合には、前記判定の対象から除くことを特徴とする請求項９又は１１に記載の報告情報収集システム。
13. 前記報告情報登録手段は、前記通知する場合に、行の高さが所定値以下である行を前記所定値の高さとし、かつ、当該行を強調して表示することを特徴とする請求項９乃至１２のいずれか１項に記載の報告情報収集システム。
14. 複数の項目を含む表形式のファイルに入力された報告情報を管理するためのデータベースと、
    前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、
    を備えるコンピュータにおける前記報告情報を収集する処理を実行するための報告情報収集方法であって、
    前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成するテーブル生成ステップと、
    当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報格納ステップと、
    前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定する第１の判定ステップと、
    前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報格納ステップと、
    を含む報告情報収集方法。
15. 複数の項目を含む表形式のファイルに入力された報告情報を管理するためのデータベースと、
    前記報告情報の入力形式として前記複数の項目に入力されるデータに課される複数の制約条件であって、少なくとも前記項目の名称及び順序を含む第１の制約条件と、少なくとも前記項目ごとの制約種別及び条件値を示す第２の制約条件と、が定義された定義情報を記憶する定義情報記憶部と、
    を備えるコンピュータに前記報告情報を収集する処理を実行させる報告情報収集プログラムであって、
    前記定義情報を受け付けた場合に、当該受け付けた定義情報に含まれる前記第１の制約条件に従ってテーブルを前記データベース内に生成するテーブル生成処理と、
    当該受け付けた定義情報を前記定義情報記憶部へ格納する定義情報格納処理と、
    前記報告情報が入力された前記表形式のファイルを受け付けた場合に、当該受け付けたファイルに入力された報告情報が前記定義情報記憶部に格納された定義情報に含まれる全ての制約条件を満たすか否かを判定する第１の判定処理と、
    前記定義情報を満たすと判定した場合に、当該受け付けたファイルに入力された報告情報を前記テーブルに格納する報告情報格納処理と、
    を含む報告情報収集プログラム。

Images