データ修正管理プログラム及びデータ修正管理方法
【課題】複数のシステムでレコードデータの二重管理を行う場合に、レコードデータの修正を効率よく行うことを課題とする。
【解決手段】データ修正管理装置１は、修正許可者記憶部２と、修正許可判定部３とを有する。修正許可者記憶部２は、レコードデータの項目ごとにそのレコードデータの修正を許可されている修正許可者がレコードデータを入力した入力者であるか、または入力者を含むグループ員のいずれであるかを対応付けて記憶する。修正許可判定部３は、レコードデータの修正要求を受け付けた場合に、修正要求を行う修正要求者にレコードデータの修正を許可するか否か判定する。この修正許可判定部３は、修正対象とされる項目に対応付けて修正許可者記憶部２に記憶された修正許可者が入力者またはグループ員であるかに基づき、修正要求者にレコードデータの修正を許可するか否か判定する。
【解決手段】データ修正管理装置１は、修正許可者記憶部２と、修正許可判定部３とを有する。修正許可者記憶部２は、レコードデータの項目ごとにそのレコードデータの修正を許可されている修正許可者がレコードデータを入力した入力者であるか、または入力者を含むグループ員のいずれであるかを対応付けて記憶する。修正許可判定部３は、レコードデータの修正要求を受け付けた場合に、修正要求を行う修正要求者にレコードデータの修正を許可するか否か判定する。この修正許可判定部３は、修正対象とされる項目に対応付けて修正許可者記憶部２に記憶された修正許可者が入力者またはグループ員であるかに基づき、修正要求者にレコードデータの修正を許可するか否か判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ修正管理プログラム及びデータ修正管理方法に関する。
【背景技術】
【０００２】
複数のシステム（system）によって共通の項目を含んで構成されるレコードデータ（record data）が同一であることを担保しながら二重に管理する二重管理が行われている。このような二重管理の下、２つのシステムで管理されるレコードデータの内容が一部異なる状態、すなわちシステム間でレコードデータが不整合となる状態が発生した場合には、一方のシステムで整合性が担保されるようにレコードデータの修正がなされる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−２０３３６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、複数のシステムでレコードデータの二重管理を行う場合には、レコードデータの入力を行った入力者単位でしかレコードデータの修正を行うことができず、レコードデータの修正を効率よく行うには自ずから限界があった。
【０００５】
すなわち、上記のレコードデータの修正は、原則として、レコードデータの入力を行った入力者により実行される。なぜなら、入力者以外の者は、レコードデータが入力された経緯を把握しておらず、どのような修正を行えばよいかを判断できないからである。このようにレコードデータの修正を実行させる修正実行者を入力者に固定した場合には、入力者がレコードデータの修正を実行するまでシステム間のレコードデータの不整合状態を放置する他なく、レコードデータの修正が滞ってしまう。
【０００６】
開示の技術は、上記に鑑みてなされたものであって、複数のシステムでレコードデータの二重管理を行う場合にレコードデータの修正を効率化できるデータ修正管理プログラム及びデータ修正管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示するデータ修正管理プログラムは、複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用される。前記データ修正管理プログラムは、前記データ修正管理装置を修正許可者記憶部として機能させる。前記修正許可記憶部は、レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する。前記データ修正管理プログラムは、前記データ修正管理装置に、前記レコードデータの修正要求を受け付けた場合に、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定手順を実行させる。前記修正許可判定手順は、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求者に当該レコードデータの修正を許可するか否か判定する。
【発明の効果】
【０００８】
本願の開示するデータ修正管理プログラムの一つの態様によれば、複数のシステムでレコードデータの二重管理を行う場合にレコードデータの修正を効率よく行うことができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１に係るデータ修正管理システムに含まれるデータ修正管理装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るデータ修正管理システムのシステム構成を示す図である。
【図３】図３は、実施例２に係る予算管理サーバの構成を示すブロック図である。
【図４】図４は、担当者テーブルに記憶される情報の構成例を示す図である。
【図５】図５は、項目テーブルに記憶される情報の構成例を示す図である。
【図６Ａ】図６Ａは、予算管理レコードの一例を示す図である。
【図６Ｂ】図６Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図７Ａ】図７Ａは、予算管理レコードの一例を示す図である。
【図７Ｂ】図７Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図８Ａ】図８Ａは、予算管理レコードの一例を示す図である。
【図８Ｂ】図８Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図９Ａ】図９Ａは、予算管理レコードの一例を示す図である。
【図９Ｂ】図９Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図１０】図１０は、エラー管理テーブルに対する検索画面の一例を示す図である。
【図１１】図１１は、エラー管理テーブルの検索結果画面の一例を示す図である。
【図１２】図１２は、修正画面の一例を示す図である。
【図１３】図１３は、同意画面の一例を示す図である。
【図１４】図１４は、修正同意画面の一例を示す図である。
【図１５】図１５は、実施例２に係るエラー通知制御処理の手順を示すフローチャートである。
【図１６】図１６は、実施例２に係るマッチング処理の手順を示すフローチャートである。
【図１７】図１７は、実施例２に係る修正許可判定処理の手順を示すフローチャートである。
【図１８】図１８は、実施例３に係るデータ修正管理プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１０】
以下に、本願の開示するデータ修正管理プログラム及びデータ修正管理方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１１】
図１は、実施例１に係るデータ修正管理システムに含まれるデータ修正管理装置の構成を示すブロック図である。図１に示すデータ修正管理装置１は、複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるものである。図１に示すように、データ修正管理装置１は、修正許可者記憶部２と、修正許可判定部３とを有する。
【００１２】
このうち、修正許可者記憶部２は、レコードデータの項目ごとにそのレコードデータの修正が許可されている修正許可者がレコードデータを入力した入力者であるか、または入力者を含むグループ員のいずれであるかを対応付けて記憶する。
【００１３】
修正許可判定部３は、レコードデータの修正要求を受け付けた場合に、修正要求を行う修正要求者にレコードデータの修正を許可するか否か判定する。この修正許可判定部３は、修正対象とされる項目に対応付けて修正許可者記憶部２に記憶された修正許可者が入力者またはグループ員であるかに基づき、修正要求者にレコードデータの修正を許可するか否か判定する。
【００１４】
すなわち、データ修正管理装置１は、レコードデータの中でも特に重要ではない項目に関する修正については入力者を含むグループ員を修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、入力者によってレコードデータが修正されるのを待たずともグループ員の誰かにレコードデータを修正させることができる。
【００１５】
また、データ修正管理装置１は、レコードデータの中でも重要な項目に関する修正については入力者だけを修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、レコードデータが入力された経緯を把握していない者に修正が実行されることによりレコードデータの重要な項目に間違いが生じることもない。
【００１６】
このように、本実施例に係るデータ修正管理システムでは、レコードデータの重要な項目に間違いを生じさせることなく、レコードデータの修正が滞る期間を低減させることができる。したがって、本実施例に係るデータ修正管理システムによれば、複数のシステムでレコードデータの二重管理を行う場合に、レコードデータの修正を効率よく行うことが可能になる。
【実施例２】
【００１７】
続いて、実施例２に係るデータ修正管理システムについて説明する。なお、以下では、官庁会計事務データ通信システム（ＡＤＡＭＳ：governmental Accounting affairs Data communication Management Systems）及び予算管理システムによって共通の項目を含んで構成される歳出データが二重管理される場合を想定する。
【００１８】
［データ修正管理システムの構成］
図２は、実施例２に係るデータ修正管理システムのシステム構成を示す図である。図２に示すように、データ修正管理システム１００には、国庫に関する歳入処理及び歳出処理などの会計事務を電子化したＡＤＡＭＳ２００と、ＡＤＡＭＳ２００の歳出処理を補助する予算管理システム３００とが含まれる。
【００１９】
これらＡＤＡＭＳ２００及び予算管理システム３００により、国庫の歳出に関する共通の項目を含んで構成されるマスタデータ（master data）が二重管理される。このような二重管理がなされる背景には、ＡＤＡＭＳ端末２５に搭載されるソフトウェアのカスタマイズ（customize）が困難であること、ＡＤＡＭＳ端末２５の設置台数が官署の人員に比較して少数しか配設されないことなどが挙げられる。
【００２０】
このことから、ＡＤＡＭＳ２００のデメリットを補うために予算管理システム３００が導入される。この予算管理システム３００の導入により、各官署では、ＡＤＡＭＳ２００のマスタデータには登録できない独自の項目をマスタデータに追加したり、官署の担当者が自身の端末で歳出データを作成したりすることができる。
【００２１】
図２に示すＡＤＡＭＳ２００は、財務省会計センタに設けられるＡＤＡＭＳサーバ２０と、各官署に設けられるＡＤＡＭＳ端末２５とを有する。なお、図２の例では、官署に設けられるＡＤＡＭＳ端末２５を１つとする場合を例示したが、官署の規模に応じて複数のＡＤＡＭＳ端末２５が設けられることとしてもよい。
【００２２】
これらＡＤＡＭＳサーバ２０及びＡＤＡＭＳ端末２５は、ネットワーク２３を介して相互に通信可能に接続される。なお、ネットワーク２３は、専用回線であって公衆回線であってもかまわない。
【００２３】
ＡＤＡＭＳサーバ２０は、各官署の歳出データ及び歳入データを統括管理するサーバ装置である。このＡＤＡＭＳサーバ２０は、ＡＤＡＭＳ端末２５から収集した歳出データに基づき、国庫から支出先の口座への振込み決済などを図示しない日本銀行に設けられた銀行サーバに依頼する機能を有する。
【００２４】
ＡＤＡＭＳ端末２５は、官署内の歳出データを記憶する端末である。一例として、ＡＤＡＭＳ端末２５は、自装置の入力デバイス（device）を介して歳出データを受け付ける。他の一例として、ＡＤＡＭＳ端末２５は、記録媒体４０に記録された歳出データを読取装置を介して取得する。なお、ＡＤＡＭＳ端末２５は、自装置に記憶した歳出データをＣＳＶ（Comma Separated Values）データとして記録媒体４０へ出力することもできる。
【００２５】
かかる記録媒体４０には、フレキシブルディスク（ＦＤ：Flexible Disk）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ（Digital Versatile Disc）ディスク、光磁気ディスクやＩＣ（Integrated Circuit）カードなどを適用できる。
【００２６】
また、図２に示す予算管理システム３００は、端末３０Ａ及び端末３０Ｂと、予算管理サーバ１０とを有する。これら端末３０Ａ及び端末３０Ｂと予算管理サーバ１０とは、図示しないＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）を介して相互に通信可能に接続される。
【００２７】
端末３０Ａ及び端末３０Ｂは、予算管理用のソフトウェアがインストール（install）された端末装置である。一例としては、官署の担当者によって使用されるパーソナルコンピュータ（ＰＣ：Personal Computer）などのコンピュータ（computer）が挙げられる。
【００２８】
予算管理サーバ１０は、各端末３０によって生成された歳出データを管理するサーバ装置である。この予算管理サーバ１０は、端末３０を使用する官署の担当者のログイン（login）認証をＩＤや暗証番号の入力を通じて行った上で自装置へのアクセスを許可するサーバとしての基本機能の他にも、上記の実施例１に係るデータ修正管理装置１の機能をさらに有する。なお、詳細については図３を用いて後述する。
【００２９】
なお、本実施例では、２つのシステムで取り扱われる歳出データを区別するために、ＡＤＡＭＳ２００により扱われる歳出データを「ＡＤＡＭＳデータ」と呼び、予算管理システム３００により扱われる歳出データを「予算管理データ」と呼ぶこととする。また、ＡＤＡＭＳデータのレコードデータを指して説明を行う場合には「ＡＤＡＭＳレコード」と呼び、また、予算管理データのレコードデータを指して説明を行う場合には「予算管理レコード」と呼ぶこととする。
【００３０】
また、本実施例では、ＡＤＡＭＳ端末２５がシステム外部の装置とは直接通信によるデータ授受を実行しないものとして以下の説明を行う。すなわち、ＡＤＡＭＳ端末２５が記憶する歳出データをシステム外部の装置に使用させる場合やシステム外部の装置が記憶する歳出データをＡＤＡＭＳ端末２５に使用させる場合には、記憶媒体４０を介して歳出データが授受される。なお、ここでは、ＡＤＡＭＳ端末２５とシステム外部の装置との間における直接通信によるデータ授受を禁止する場合を説明するが、直接通信によるデータ授受を行う場合にも開示のシステムを同様に適用できる。
【００３１】
［予算管理サーバの構成］
続いて、本実施例に係る予算管理サーバの構成について説明する。図３は、実施例２に係る予算管理サーバの構成を示すブロック図である。図３に示すように、予算管理サーバ１０は、記録媒体読取部１１と、通信制御Ｉ／Ｆ（interface）部１２と、メール配信部１３と、記憶部１４と、制御部１５とを有する。なお、予算管理サーバ１０は、図３の例では図示していないが、既存のサーバ装置が有するハードウェア、例えば入力デバイスや表示デバイス、さらには、ソフトウェアを有するものとする。
【００３２】
このうち、記録媒体読取部１１は、記録媒体４０に記録された情報を読み取る読取装置である。一例としては、ＦＤドライブ（drive）、ＣＤ−ＲＯＭドライブ、ＤＶＤディスクドライブ、光磁気ディスクドライブやＩＣカードのリーダライタ（reader/writer）などが挙げられる。
【００３３】
通信制御Ｉ／Ｆ部１２は、他の装置、例えば端末３０との間で通信を行うためのインタフェースである。また、メール配信部１３は、後述のエラー通知制御部１５ｂの指示に基づき、電子メールの作成や送受信を行う処理部である。
【００３４】
記憶部１４は、例えば、フラッシュメモリ（flash memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。なお、記憶部１４は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。
【００３５】
この記憶部１４は、制御部１５で実行されるＯＳ（Operating System）などの各種プログラム及びそのプログラムの実行に必要なデータを記憶する。例えば、記憶部１４は、予算管理テーブル１４ａと、担当者テーブル１４ｂと、項目テーブル１４ｃと、エラー管理テーブル１４ｄとを併せて記憶する。
【００３６】
このうち、予算管理テーブル１４ａは、入力番号、入力者、整理番号、日付、予算科目、業者、金額や備考などの項目が対応付けられた予算管理データを記憶したテーブルである。ここで、予算管理テーブル１４ａは、ＡＤＡＭＳレコードの全項目を含むように定義される。上記の８項目を含んでなる予算管理レコードのうち入力番号を除く残りの７項目は、ＡＤＡＭＳレコードとの間で共通する。
【００３７】
なお、「入力番号」は、予算管理レコードが生成された場合に採番される識別番号を指す。また、「入力者」は、予算管理レコードの作成を担当した担当者を指す。また、「整理番号」は、ＡＤＡＭＳレコードが生成された場合に採番される識別番号を指す。また、「日付」は、予算管理レコードが作成された日付を指す。また、「予算科目」は、予算の区分を指す。また、「業者」は、予算の支出先の業者を指す。また、「金額」は、予算として計上された金額を指す。また、「備考」は、予算管理レコードに関する補足事項を指す。
【００３８】
担当者テーブル１４ｂは、テーブル内のレコードの連番ごとに担当者が所属する部署の名称、担当者の氏名、メールアドレス（mail address）及び担当者が属するグループを対応付けて記憶したテーブルである。
【００３９】
図４は、担当者テーブルに記憶される情報の構成例を示す図である。図４に示す例では、連番１〜連番３に登録されている総務課に所属の総務太郎、総務花子及び総務次郎の３名はともに担当者グループが「Ａ」であり、各々のメールアドレスが「aaa@zzz.co.jp」、「bbb@zzz.co.jp」、「ccc@zzz.co.jp」であることを示す。また、連番４〜連番５に登録されている会計課に所属の会計太郎及び会計花子の２名はともに担当者グループが「Ｂ」であり、各々のメールアドレスが「ddd@zzz.co.jp」、「eee@zzz.co.jp」であることを示す。さらに、連番６に登録されている人事課に所属の人事次郎は担当者グループが「Ｃ」であり、メールアドレスが「fff@zzz.co.jp」であることを示す。
【００４０】
項目テーブル１４ｃは、テーブル内のレコードの連番ごとに項目名及び修正許可者を対応付けて記憶したテーブルである。ここで言う「修正許可者」は、予算管理レコードの修正を許可する担当者の種別を指す。
【００４１】
図５は、項目テーブルに記憶される情報の構成例を示す図である。図５に示す例では、連番１〜連番４に登録されている項目「日付」、「金額」、「業者」及び「予算科目」の修正許可者が入力者であり、連番５に登録されている「備考」の修正許可者が入力者を含むグループ員であることを示す。
【００４２】
エラー管理テーブル１４ｄは、予算管理レコードのエラーを管理するためのテーブルである。このエラー管理テーブル１４ｄは、テーブル内の連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者や進捗状況などのスキームを有する。ここで、エラー管理テーブル１４ｄは、予め定義されたテーブルではなく、後述のマッチング処理部１５ａによって動的に作成されるものである。このようにしてテーブルが生成された後には、後述のエラー通知制御部１５ｂ及び後述の修正処理部１５ｄにより進捗状況が更新される。
【００４３】
ここで、ＡＤＡＭＳサーバ２０が銀行サーバへ決済を依頼する場合には、ＡＤＡＭＳ端末２５に入力された歳出データが使用される。このため、ＡＤＡＭＳレコードには、最終確定した内容が規定されている可能性が高い。それゆえ、本実施例では、ＡＤＡＭＳレコード及び予算管理レコードの内容が一部異なる場合には、ＡＤＡＭＳレコードが「真」であるものとしてＡＤＡＭＳレコードとの間で整合性が担保されるように予算管理レコードが入力者により修正される場合を想定する。
【００４４】
上記の「入力者（１）」は、予算管理レコードを作成した入力者を指し、「入力者（２）」は、ＡＤＡＭＳレコードを作成した入力者を指す。また、「エラー項目」は、ＡＤＡＭＳレコードとの間で整合性が取れていない予算管理レコードの項目を指す。また、「修正実行者」は、予算管理レコードの修正を実行した担当者を指す。この修正実行者のフィールドは予算管理レコードの修正が実行されるまではブランクの状態にある。
【００４５】
また、「同意要否」は、予算管理レコードの入力者（１）による修正にＡＤＡＭＳレコードの入力者（２）の同意を要するか否かを示すフィールドである。この同意要否のフィールドには、エラー項目に対応する修正許可者としてグループ員が許容されずに入力者のみが規定されているか、または入力者（１）と入力者（２）とが別人である場合にも「要」が設定される。それ以外の場合には、同意要否のフィールドに「不要」が設定される。
【００４６】
また、「進捗状況」は、予算管理レコードのエラーが検出されてから修正が完了したとみなされるまでの進捗を「メール送信」、「メール受信」、「データ修正」、「修正同意」、「最終」の５段階に分けて管理される。
【００４７】
これを説明すると、マッチング処理部１５ａによりエラー管理テーブル１４ｄが生成された初期段階では、５つの段階全てが「未完了」とされている。例えば、後述のエラー通知制御部１５ｂによって予算管理レコードの修正を促すエラー通知メールが入力者（１）へ送信された場合には、メール送信の進捗が「完了」に更新される。また、端末３０でエラー通知メールの受信確認がなされた場合には、メール受信の進捗が「完了」に更新される。さらに、入力者（１）が使用する端末３０または入力者（１）を含むグループ員が使用する端末３０から予算管理レコードの修正を受け付けた場合には、データ修正の進捗が「完了」に更新される。また、入力者（２）が使用する端末３０から入力者（１）が行った修正内容に対する同意入力を受け付けた場合には、修正同意の進捗が「完了」に更新される。最後に、同意要否が「不要」に設定されている場合には、後述の修正処理部１５ｄによりデータ修正の進捗が「完了」に更新された段階で最終の進捗も「完了」に更新される。また、同意要否が「要」に設定されている場合には、後述の修正処理部１５ｄにより修正同意の進捗が「完了」に更新された段階で最終の進捗も「完了」に更新される。
【００４８】
制御部１５は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路またはＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。
【００４９】
この制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５は、図３に示すように、マッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄとを有する。
【００５０】
マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードをマッチングすることによりシステム間で共通する項目のデータが所定の修正条件を満たす予算管理レコードをマッチング結果として抽出する処理部である。
【００５１】
これを説明すると、マッチング処理部１５ａは、例えば、記録媒体４０に記録されたＡＤＡＭＳデータが記録媒体読取部１１により読み取られた場合には、ＡＤＡＭＳデータに含まれるＡＤＡＭＳレコードを１つ取り出す。そして、マッチング処理部１５ａは、このようにして取り出したＡＤＡＭＳレコードに含まれる整理番号と同一の整理番号を持つ予算管理レコードの抽出を試行する。このとき、同一の整理番号を持つ予算管理レコードが存在する場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一であるか否かをさらに判定する。
【００５２】
そして、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一である場合には、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合性が取れていると判別する。
【００５３】
一方、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する項目のいずれかのデータが非同一である場合には、２つのシステム間でレコードデータの整合がないと判別する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードと一致しない項目をエラー項目として特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者及び進捗状況が対応付けられたエラー管理レコードを生成する。なお、この時点では、修正は実行されていないので、修正実行者のフィールドはブランクとされる。
【００５４】
図６Ａは、予算管理レコードの一例を示す図である。図６Ｂは、ＡＤＡＭＳレコードの一例を示す図である。図６Ａ及び図６Ｂの例で言えば、ＡＤＡＭＳレコード及び予算管理レコードの整理番号が同一であり、かつ両レコード間で「日付」及び「備考」が非同一である。したがって、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合がないと判別する。この場合には、マッチング処理部１５ａは、エラー項目を「日付、備考」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「30000」とし、入力番号を「00003」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「日付、備考」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００５５】
また、同一の整理番号を持つ予算管理レコードが存在しない場合には、マッチング処理部１５ａは、先のＡＤＡＭＳレコードとの間で所定の一致度を有する予算管理レコードが存在するか否かをさらに判定する。一例としては、マッチング処理部１５ａは、両レコードで共通する項目から整理番号を除いた７項目のうち６項目のデータが一致する一致度を有する予算管理レコードが存在するか否かを判定する。なお、ここでは、不一致を許容する項目数を１項目としたが、任意の項目数であってかまわない。例えば、項目数に所定のパラメータを乗算または除算することとしてもよい。また、不一致項目が金額であった場合には、両者のズレが「\50,000」以内などのように更なる条件を付加することとしてもかまわない。
【００５６】
そして、所定の一致度を有する予算管理レコードが存在しない場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードの対となる予算管理レコードが存在しないと判別する。この場合には、担当者が、ＡＤＡＭＳレコードがＡＤＡＭＳ端末２５で直接入力されたまま、対となる予算管理レコードを事後的に登録し忘れた可能性が高い。このため、マッチング処理部１５ａは、予算管理レコードの登録し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請する。かかる要請を受け付けたエラー通知制御部１５ｂによりＡＤＡＭＳレコードに含まれる入力者に対応するメールアドレスが担当者テーブル１４ｂから抽出される。そして、エラー通知制御部１５ｂにより予算管理レコードの登録し忘れを注意喚起するメールが先のメールアドレスへ送信制御される。
【００５７】
一方、所定の一致度を有する予算管理レコードが存在する場合には、マッチング処理部１５ａは、少数の項目の入力間違いがあったものと判別する。この場合には、マッチング処理部１５ａは、予算管理レコードのうち整理番号を除いて一致しなかった項目をエラー項目と判別する。その上で、マッチング処理部１５ａは、連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者及び進捗状況が対応付けられたエラー管理レコードを生成する。なお、この時点では、修正は実行されていないので、修正実行者のフィールドはブランクとされる。
【００５８】
図７Ａ、図８Ａ及び図９Ａは、予算管理レコードの一例を示す図である。図７Ｂ、図８Ｂ及び図９Ｂは、ＡＤＡＭＳレコードの一例を示す図である。図７Ａ及び図７Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「30000」に対応する予算管理レコードはないが、整理番号と備考を除く他の項目で一致する予算管理レコードが存在する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードを一対のレコードと推定し、エラー項目を「整理番号未採番、備考」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「30000」とし、入力番号を「00003」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「整理番号未採番、備考」とし、同意要否を「不要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００５９】
また、図８Ａ及び図８Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「40000」に対応する予算管理レコードはないが、整理番号と日付を除く他の項目で一致する予算管理レコードが存在する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードを一対のレコードと推定し、エラー項目を「整理番号未採番、日付」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「40000」とし、入力番号を「00004」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「整理番号未採番、日付」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの同意要否、修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００６０】
さらに、図９Ａ及び図９Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「50000」に対応する予算管理レコードはないが、整理番号と金額を除く他の項目で一致する予算管理レコードが３つ存在する。また、不一致項目である金額についても「\50,000」以内に収まる。この場合には、マッチング処理部１５ａは、１つのＡＤＡＭＳレコードに対し、予算管理レコードが３つも登録されており、３つのうちいずれかの予算管理レコードがＡＤＡＭＳレコードと一対になるものと推定する。そして、マッチング処理部１５ａは、エラー項目を「整理番号未採番、金額」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を各予算管理レコードごとに採番する。その上で、マッチング処理部１５ａは、採番した番号それぞれを連番とし、整理番号を「50000」とし、入力番号を「00005」とし、入力者（１）及び入力者（２）を「担当者Ｃ」とし、エラー項目「整理番号未採番、金額」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを３つ生成する。このように、１つのＡＤＡＭＳレコードに対し、予算管理レコードが３つも登録されている場合には、１つの予算管理レコードが最終の進捗が「完了」に更新されたこともって他の２つの予算管理レコードを自動的に削除させることもできる。
【００６１】
このように、マッチング処理部１５ｃは、ＡＤＡＭＳデータに含まれる全てのＡＤＡＭＳレコードを上記のマッチングが終了するまで繰り返し行う。このとき、全てのＡＤＡＭＳレコードを対象にマッチングが終了した場合には、予算管理レコードの対となるＡＤＡＭＳレコードが存在しない。このため、ＡＤＡＭＳレコードとペアリングされずに残った予算管理レコードは、対となるＡＤＡＭＳレコードがＡＤＡＭＳ端末２５にも登録されたはずであったが事情変更により削除された場合が想定される。よって、マッチング処理部１５ａは、予算管理レコードの削除し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請する。かかる要請を受け付けたエラー通知制御部１５ｂにより予算管理レコードに含まれる担当者に対応するメールアドレスが担当者テーブル１４ｂから抽出される。そして、エラー通知制御部１５ｂにより予算管理レコードの削除し忘れを注意喚起するメールが先のメールアドレスへ送信制御される。
【００６２】
なお、本実施例では、ＡＤＡＭＳレコード及び予算管理レコードの内容が一部異なる場合にＡＤＡＭＳレコードが「真」であると仮定することとしたが、予算管理レコードが「真」であると仮定することとしてもかまわない。例えば、ＡＤＡＭＳレコードが「真」であると仮定とした場合には、ＡＤＡＭＳレコードとペアリングされずに残った予算管理レコードは、ＡＤＡＭＳ端末２５にも登録されるはずであったが登録し忘れられた場合も想定される。このような場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードの登録し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請することもできる。
【００６３】
エラー通知制御部１５ｂは、入力者またはグループ員が使用する端末３０に対して、予算管理レコードのエラー内容を通知する処理部である。
【００６４】
これを説明すると、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるエラー管理レコードを取得する。そして、エラー通知制御部１５ｂは、項目テーブル１４ｃを参照して、先に取得したエラー管理レコードに含まれるエラー項目に対応する修正許可者が入力者またはグループ員のいずれであるかを判定する。
【００６５】
このとき、修正許可者がグループ員であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）が所属する担当者グループ全員のメールアドレスを担当者テーブル１４ｂからそれぞれ読み出す。そして、エラー通知制御部１５ｂは、担当者グループ全員のメールアドレスに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。
【００６６】
また、修正許可者が入力者であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）が別人であるか否かをさらに判定する。この結果、入力者（１）及び入力者（２）が別人であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）のメールアドレスを担当者テーブル１４ｂからそれぞれ読み出す。そして、エラー通知制御部１５ｂは、入力者（１）及び入力者（２）のメールアドレスそれぞれに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。なお、入力者（２）に通知するメールには、修正が最終確定するまでに入力者（２）による同意入力を要する旨を追加するようにしてもよい。
【００６７】
一方、入力者（１）及び入力者（２）が同一人であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）のメールアドレスを担当者テーブル１４ｂから読み出す。そして、エラー通知制御部１５ｂは、入力者（１）のメールアドレスに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。
【００６８】
このようにエラー通知メールを配信させた後には、エラー通知制御部１５ｂは、エラー管理レコードに含まれるデータ送信の進捗を「未完了」から「完了」へ更新する。そして、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるエラー管理レコードがなくなるまで、エラー通知メールをメール配信部１３に配信させる。
【００６９】
修正許可判定部１５ｃは、予算管理レコードに対する修正要求を受け付けた場合に、修正要求者に予算管理レコードの修正を許可するか否か判定する処理部である。
【００７０】
このように端末３０から修正要求がなされる前に修正要求者のログイン認証が予算管理サーバ１０により実行される。予算管理サーバ１０は、端末３０に予算管理サーバ１０の予算管理テーブル１４ａへアクセスさせる前に、端末３０を使用する担当者のログイン認証をＩＤや暗証番号の入力を通じて行った上でアクセスを許可する。このようなログイン認証の実行後には、予算管理サーバ１０は、ログイン認証時に発行したセッションＩＤを追跡することにより、どの担当者が使用する端末３０からアクセスを受け付けているのかを特定できる。
【００７１】
その後、端末３０を使用する修正要求者は、エラー管理テーブル１４ｄを検索することにより、自分、自分が所属する担当者グループまたは全担当者の中から任意の参照範囲で修正が注意喚起されている予算管理レコードの進捗状況を参照することができる。
【００７２】
図１０は、エラー管理テーブルに対する検索画面の一例を示す図である。図１０に示す検索画面５０では、エラー管理テーブル１４ｄに対する検索条件として、予算管理レコードの修正を促されている修正担当者、修正内容の同意入力を促されている同意担当者、最終進捗に関する検索範囲を指定できる。また、検索画面５０では、コンボボックス５１のボタン５１ａをクリックすることにより「全担当者」、「自所属の担当者グループ」及び「自分のみ」がプルダウン表示され、これらの中から修正担当者の検索範囲を指定できる。また、検索画面５０では、コンボボックス５２のボタン５２ａをクリックすることにより「全担当者」、「自所属の担当者グループ」及び「自分のみ」がプルダウン表示され、これらの中から同意担当者の検索範囲を指定できる。さらに、検索画面５０では、コンボボックス５３のボタン５３ａをクリックすることにより「全データ」、「未完了のみ」及び「完了のみ」がプルダウン表示され、これらの中から最終進捗の検索範囲を指定できる。これらコンボボックス５１〜５３を用いて検索範囲を指定した後にＯＫボタン５５をクリックすることにより、全２７通りの中から任意の検索条件でエラー管理テーブルに検索を実行できる。なお、閉じるボタン５４がクリックされた場合には、検索画面５０が閉じられる。
【００７３】
図１１は、エラー管理テーブルの検索結果画面の一例を示す図である。図１１に示す連番「1」には、整理番号「11111」、入力番号「00010」、入力者（１）「総務太郎」、入力者（２）「総務次郎」、エラー項目「金額」、同意要否「要」及び修正実行者「総務太郎」が対応付けられている。この連番「1」の予算管理レコードの修正は最終の進捗が「完了」であるので、「メール送信」、「メール受信」、「データ修正」、「修正同意」などの過程が既に終了し、修正が完結している状態を示す。
【００７４】
図１１に示す連番「2」には、整理番号「22222」、入力番号「00025」、入力者（１）「総務太郎」、入力者（２）「総務太郎」、エラー項目「備考」、同意要否「不要」及び修正実行者「総務太郎」が対応付けられている。この連番「2」の予算管理レコードの修正は最終の進捗が「完了」であるので、「メール送信」、「メール受信」、「データ修正」などの過程が既に終了し、修正が完結している状態を示す。
【００７５】
図１１に示す連番「3」には、整理番号「33333」、入力番号「00053」、入力者（１）「総務太郎」、入力者（２）「総務太郎」、エラー項目「予算科目」、同意要否「要」及び修正実行者「総務太郎」が対応付けられている。この連番「3」の予算管理レコードの修正はメール受信までの進捗が「完了」であるので、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７６】
図１１に示す連番「4」には、整理番号「-」、入力番号「00065」、入力者（１）「会計花子」、入力者（２）「総務次郎」、エラー項目「整理番号未付与」、同意要否「要」及び修正実行者「-」が対応付けられている。この連番「4」の予算管理レコードの修正はメール送信までの進捗が「完了」であるので、「メール受信」、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７７】
図１１に示す連番「5」には、整理番号「-」、入力番号「00066」、入力者（１）「会計花子」、入力者（２）「会計花子」、エラー項目「整理番号未付与」、同意要否「不要」及び修正実行者「-」が対応付けられている。この連番「5」の予算管理レコードの修正はメール送信までの進捗が「完了」であるので、「メール受信」、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７８】
ここで、図１１に示す検索結果画面６０にていずれかのエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、端末３０は、修正要求者により指定されたレコードが含む入力番号に対応する予算管理レコードへアクセスを要求する。なお、閉じるボタン６１がクリックされた場合には、検索結果画面６０が閉じられる。また、検索ボタン６２がクリックされた場合には、図１０に示した検索画面５０に戻る。
【００７９】
一方、予算管理サーバ１０の修正許可判定部１５ｃは、アクセス要求を受け付けた予算管理レコードの同意要否、入力者（１）及び入力者（２）をエラー管理テーブル１４ｄから取得する。そして、同意要否が「要」である場合には、修正許可判定部１５ｃは、修正要求者、入力者（１）及び入力者（２）が同一人であるか否かを判定する。
【００８０】
この結果、修正要求者、入力者（１）及び入力者（２）と同一人である場合には、修正許可判定部１５ｃは、修正要求者が修正担当者であるとともに同意担当者でもあるので、予算管理レコードの修正及びその修正内容に対する同意入力を許可する。
【００８１】
一方、修正要求者、入力者（１）及び入力者（２）が同一人ではない場合には、修正許可判定部１５ｃは、修正要求者が入力者（２）と同一人であるか否かをさらに判定する。このとき、修正要求者が入力者（２）と同一人である場合には、修正許可判定部１５ｃは、修正要求者が同意担当者であるので、予算管理レコードの修正内容に対する同意入力を許可する。
【００８２】
また、修正要求者が入力者（２）と同一人でない場合には、修正許可判定部１５ｃは、修正要求者が入力者（１）と同一人であるか否かをさらに判定する。この結果、修正要求者が入力者（１）と同一人である場合には、修正要求者が修正担当者であるので、予算管理レコードの修正を許可する。
【００８３】
修正処理部１５ｄは、予算管理レコードに対する修正処理を行う処理部である。これを説明すると、修正処理部１５ｄは、修正許可判定部１５ｃにより予算管理レコードの修正が許可された修正要求者の端末３０に対して、アクセス要求を受け付けた予算管理レコードを予算管理テーブル１４ａから読み出して送信する。
【００８４】
例えば、図１１に示す検索結果画面６０にて入力番号「00010」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、修正要求者が修正担当者であった場合に、修正処理部１５ｄは、図１２に示す修正画面を端末３０へ送信する。
【００８５】
図１２は、修正画面の一例を示す図である。図１２に示す修正画面７０には、予算管理レコードに含まれる各項目が表示される。この場合には、修正担当者「総務太郎」、同意担当者「総務次郎」、整理番号「11111」、日付「2009/11/30」、予算科目「一般会計 ○○局 庁費」、金額「\20,000」、業者「イ」及び備考「AAAA」が修正画面７０に表示される。
【００８６】
ここで、修正処理部１５ｄは、エラー項目である金額の欄は他の項目とは異なる表示態様で端末３０に表示させる。一例としては、図１２に示すように、金額「\20,000」を反転表示させる。そして、修正担当者により端末３０の入力デバイスを介して図１２に示したエラー項目の部分がＡＤＡＭＳレコードの値と同一になるように予算管理レコードの修正がなされる。
【００８７】
その後、修正画面７０上の修正ボタン７１がクリックされた場合には、端末３０により予算管理レコードが修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともにエラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」に更新する。この場合、修正処理部１５ｄは、同意要否が「要」であるので、最終の進捗は「未完了」のままとする。
【００８８】
なお、一時保存ボタン７３がクリックされた場合には、端末３０で起動する予算管理用のソフトウェアがメモリ等に一時記憶させる。また、閉じるボタン７２がクリックされた場合には、予算管理レコードの修正を中断して修正画面７０が閉じられる。
【００８９】
また、図１１に示す検索結果画面６０にて入力番号「00010」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、修正要求者が同意担当者であった場合には、修正処理部１５ｄは、図１３に示す同意画面を端末３０へ送信する。
【００９０】
図１３は、同意画面の一例を示す図である。図１３に示す修正画面８０は、図１２に示した修正画面７０に比較して、修正ボタン７１及び一時保存ボタン７３の代わりに、同意ボタン８１及び却下ボタン８２が表示される点が異なる。そして、修正画面８０上の同意ボタン８１がクリックされた場合には、端末３０により修正内容に同意する旨の通知が修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、エラー管理テーブル１４ｄにおける修正同意の進捗を「完了」に更新するとともに最終の進捗を「完了」に更新する。なお、却下ボタン８２がクリックされた場合には、修正処理部１５ｄは、エラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」から「未完了」に差し戻す更新を実行する。
【００９１】
また、図１１に示す検索結果画面６０で入力番号「00053」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３が操作されると、修正要求者が同意担当者であった場合に、修正処理部１５ｄは、図１４に示す修正同意画面を端末３０へ送信する。
【００９２】
図１４は、修正同意画面の一例を示す図である。図１４に示す修正同意画面９０は、図１２に示した修正画面７０に比較して、修正ボタン７１の代わりに、修正同意ボタン９１及び却下ボタン８２が表示される点が異なる。そして、修正同意画面９０上の修正同意ボタン９１がクリックされた場合には、端末３０により予算管理レコードとともに修正内容に同意する旨の通知が修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正、修正同意及び最終の進捗を「完了」に更新する。
【００９３】
［処理の流れ］
次に、本実施例に係る予算管理サーバの処理の流れを説明する。ここでは、予算管理サーバ１０によって実行される（１）エラー通知制御処理、（２）マッチング処理、（３）修正許可判定処理の順に説明することとする。
【００９４】
（１）エラー通知制御処理
図１５は、実施例２に係るエラー通知制御処理の手順を示すフローチャートである。このエラー通知制御処理は、記録媒体４０に記録されたＡＤＡＭＳデータが記録媒体読取部１１により読み取られた場合や予算管理サーバ１０の入力デバイスを介してＡＤＡＭＳデータが手入力された場合など、任意のタイミングで開始できる。なお、ＡＤＡＭＳデータの取得経路は必ずしも記録媒体４０経由で取得する必要はなく、通信により取得することとしてもかまわない。
【００９５】
図１５に示すように、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードをマッチングすることにより、エラー管理テーブル１４ｄの生成を試行する（ステップＳ１０１）。このとき、所定の修正条件を満たす予算管理レコードがなく、エラー管理テーブル１４ｄが生成されなかった場合（ステップＳ１０２否定）には、そのまま処理を終了する。
【００９６】
一方、エラー管理テーブル１４ｄが生成された場合（ステップＳ１０２肯定）に、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が未完了であるレコードを取得する（ステップＳ１０３）。
【００９７】
そして、エラー通知制御部１５ｂは、項目テーブル１４ｃを参照して、先に取得したエラー管理レコードに含まれるエラー項目に対応する修正許可者が入力者またはグループ員のいずれであるかを判定する（ステップＳ１０４）。
【００９８】
このとき、修正許可者がグループ員であった場合（ステップＳ１０４否定）には、エラー通知制御部１５ｂは、入力者（１）が所属する担当者グループ全員のメールアドレスに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０５）。
【００９９】
また、修正許可者が入力者であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）が別人であるか否かをさらに判定する（ステップＳ１０６）。
【０１００】
この結果、入力者（１）及び入力者（２）が同一人であった場合（ステップＳ１０６否定）には、エラー通知制御部１５ｂは、入力者（１）のメールアドレスに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０７）。
【０１０１】
一方、入力者（１）及び入力者（２）が別人であった場合（ステップＳ１０６肯定）に、エラー通知制御部１５ｂは、入力者（１）及び入力者（２）のメールアドレスそれぞれに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０８）。
【０１０２】
このエラー通知メールの配信後に、エラー通知制御部１５ｂは、エラー管理レコードに含まれるデータ送信の進捗を「未完了」から「完了」へ更新する（ステップＳ１０９）。そして、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるレコードがなくなるまで（ステップＳ１１０否定）、上記のステップＳ１０３〜Ｓ１０９までの処理を繰り返し行う。
【０１０３】
その後、メール送信の進捗が「未完了」であるエラー管理レコードがなくなった場合（ステップＳ１１０肯定）には、そのまま処理を終了する。
【０１０４】
（２）マッチング処理
図１６は、実施例２に係るマッチング処理の手順を示すフローチャートである。このマッチング処理は、図１５に示したステップＳ１０１で実行される処理である。図１６に示すように、マッチング処理部１５ａは、ＡＤＡＭＳデータに含まれるＡＤＡＭＳレコードを１つ取得する（ステップＳ２０１）。そして、マッチング処理部１５ａは、このようにして取り出したＡＤＡＭＳレコードに含まれる整理番号と同一の整理番号を持つ予算管理レコードを取得する（ステップＳ２０２）。
【０１０５】
このとき、同一の整理番号を持つ予算管理レコードが存在する場合（ステップＳ２０３肯定）、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードの間の共通項目のいずれかのデータが非同一であるか否かを判定する（ステップＳ２０４）。
【０１０６】
そして、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一である場合（ステップＳ２０４否定）には、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合性が取れていると判別する。この場合には、ステップＳ２０５を実行することなく、ステップＳ２０６へ移行する。
【０１０７】
一方、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する項目のいずれかのデータが非同一である場合（ステップＳ２０４肯定）には、マッチング処理部１５ａは、エラー管理レコードを生成する（ステップＳ２０５）。
【０１０８】
また、同一の整理番号を持つ予算管理レコードが存在しない場合（ステップＳ２０３否定）には、マッチング処理部１５ａは、先のＡＤＡＭＳレコードとの間で所定の一致度を有する予算管理レコードが存在するか否かをさらに判定する（ステップＳ２０７）。
【０１０９】
そして、所定の一致度を有する予算管理レコードが存在しない場合（ステップＳ２０７否定）には、マッチング処理部１５ａは、予算管理レコードの登録し忘れを注意喚起する旨をエラー通知制御部１５ｂに通知させる（ステップＳ２０８）。
【０１１０】
一方、所定の一致度を有する予算管理レコードが存在する場合（ステップＳ２０７肯定）には、マッチング処理部１５ａは、エラー管理レコードを生成する（ステップＳ２０５）。そして、マッチング処理部１５ｃは、ＡＤＡＭＳデータに含まれる全てのＡＤＡＭＳレコードを対象に上記のマッチングが終了するまで（ステップＳ２０６否定）、上記のステップＳ２０１〜Ｓ２０８の処理を繰り返し行う。
【０１１１】
その後、全てのＡＤＡＭＳレコードを対象に上記のマッチングが終了すると（ステップＳ２０６肯定）、マッチング処理部１５ａは、予算管理レコードの削除し忘れを注意喚起する旨をエラー通知制御部１５ｂに通知させ（ステップＳ２０９）、処理を終了する。
【０１１２】
（３）修正許可判定処理
図１７は、実施例２に係る修正許可判定処理の手順を示すフローチャートである。この修正許可判定処理は、修正要求者により指定されたレコードが含む入力番号に対応する予算管理レコードへアクセス要求を受け付けた場合に起動する。
【０１１３】
図１７に示すように、修正許可判定部１５ｃは、アクセス要求を受け付けた予算管理レコードの同意要否、入力者（１）及び入力者（２）をエラー管理テーブル１４ｄから取得する（ステップＳ３０１）。
【０１１４】
そして、同意要否が「要」である場合（ステップＳ３０２肯定）には、修正許可判定部１５ｃは、修正要求者、入力者（１）及び入力者（２）が同一人であるか否かを判定する（ステップＳ３０３）。なお、同意要否が「不要」である場合（ステップＳ３０２否定）には、ステップＳ３０９へ移行する。
【０１１５】
この結果、修正要求者、入力者（１）及び入力者（２）と同一人である場合（ステップＳ３０３肯定）には、修正処理部１５ｄは、端末３０から予算管理レコードの修正及び修正内容に対する同意入力を受け付ける（ステップＳ３０４）。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正、修正同意及び最終の進捗を「完了」に更新し（ステップＳ３０５）、処理を終了する。
【０１１６】
一方、修正要求者、入力者（１）及び入力者（２）が同一人ではない場合（ステップＳ３０３否定）には、修正許可判定部１５ｃは、修正要求者が入力者（２）と同一人であるか否かをさらに判定する（ステップＳ３０６）。このとき、修正要求者が入力者（２）と同一人である場合（ステップＳ３０６肯定）には、修正処理部１５ｄは、端末３０から修正内容に対する同意入力を受け付ける（ステップＳ３０７）。そして、修正処理部１５ｄは、エラー管理テーブル１４ｄにおける修正同意及び最終の進捗を「完了」に更新し（ステップＳ３０８）、処理を終了する。
【０１１７】
また、修正要求者が入力者（２）と同一人でない場合（ステップＳ３０６否定）には、修正許可判定部１５ｃは、修正要求者が入力者（１）と同一人であるか否かをさらに判定する（ステップＳ３０９）。
【０１１８】
この結果、修正要求者が入力者（１）と同一人である場合（ステップＳ３０９肯定）には、修正処理部１５ｄは、端末３０から予算管理レコードの修正を受け付ける（ステップＳ３１０）。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」に更新し（ステップＳ３１１）、処理を終了する。
【０１１９】
なお、修正要求者が入力者（１）と同一人ではない場合（ステップＳ３０９否定）には、修正要求者が修正担当者、同意担当者、これら両方の兼任のいずれでもないので、予算管理レコードの修正は許可せず、そのまま処理を終了する。
【０１２０】
［実施例２の効果］
上述してきたように、本実施例に係る予算管理サーバ１０は、レコードデータの中でも特に重要ではない項目に関する修正については入力者を含むグループ員を修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、入力者によってレコードデータが修正されるのを待たずともグループ員の誰かにレコードデータを修正させることができる。
【０１２１】
また、本実施例に係る予算管理サーバ１０は、レコードデータの中でも重要な項目に関する修正については入力者だけを修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、レコードデータが入力された経緯を把握していない者に修正が実行されることによりレコードデータの重要な項目に間違いが生じることもない。
【０１２２】
このように、本実施例に係るデータ修正管理システム１００では、レコードデータの重要な項目に間違いを生じさせることなく、レコードデータの修正が滞る期間を低減させることができる。したがって、本実施例に係るデータ修正管理システム１００によれば、複数のシステムでレコードデータの二重管理を行う場合に、レコードデータの修正を効率よく行うことが可能である。
【０１２３】
また、本実施例に係る予算管理サーバ１０は、レコードデータの入力者がシステム間で異なり、かつ修正対象とされる項目に対応付けて記憶された修正許可者が入力者である場合に、予算管理レコードの入力者に修正を許可する判定を実行する。さらに、本実施例に係る予算管理サーバ１０は、レコードデータの修正内容に同意する旨の入力を受け付け、同意担当者による同意入力が受け付けられることを条件に修正担当者による予算管理レコードの修正が完了したとみなす。
【０１２４】
このため、本実施例に係るデータ修正管理システム１００によれば、予算管理レコードに対する修正内容を修正担当者とともに同意担当者にも二重にチェックさせることができ、レコードデータの修正に間違いが生じることを効果的に防止できる。
【０１２５】
さらに、本実施例に係る予算管理サーバ１０は、各システムのレコードデータをマッチングすることによりシステム間で共通する項目のデータが所定の修正条件を満たすレコードデータをマッチング結果として抽出する。その上で、本実施例に係る予算管理サーバ１０は、マッチング結果として抽出されたレコードデータの入力者が使用する端末装置に対して、当該レコードデータの修正を要する旨を通知する。
【０１２６】
それゆえ、本実施例に係るデータ修正管理システム１００によれば、システム間でレコードデータが不整合となる状態が発生した場合にその入力者本人に修正を促すことができ、レコードデータが不整合となる期間を低減することが可能である。
【０１２７】
また、本実施例に係る予算管理サーバ１０は、予算管理レコードの入力者と、予算管理レコードの修正に関する修正内容と、予算管理レコードの修正に関する進捗状況とを対応付けて記憶する。そして、本実施例に係る予算管理サーバ１０は、マッチング結果が抽出された場合に、予算管理レコードの入力者及び予算管理レコードの修正内容を登録するとともに、進捗状況としてマッチングが完了した段階にある旨を登録する。続いて、本実施例に係る予算管理サーバ１０は、通知が行われた場合に、進捗状況として修正通知が完了した段階にある旨を登録する。その後、本実施例に係る予算管理サーバ１０は、修正担当者による予算管理レコードの修正内容が受け付けられた場合に、進捗状況として修正内容の受付が完了した段階にある旨を登録する。さらに、本実施例に係る予算管理サーバ１０は、同意担当者による同意入力が受け付けられた場合に、進捗状況として同意入力の受付が完了した段階にある旨を登録する。
【０１２８】
このように、本実施例に係るデータ修正管理システム１００によれば、予算管理レコードの修正に関する進捗状況を段階的に収集することができ、例えば進捗が滞っている修正担当者に修正を督促することも可能である。
【実施例３】
【０１２９】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１３０】
また、上記の実施例２では、予算管理サーバ１０が制御部１５内の各機能部及び記憶部１４内のテーブルを有する場合を説明したが、担当者が使用する端末３０それぞれに制御部１５内の各機能部及び記憶部１４内のテーブルを持たせることもできる。この場合にも上記の実施例２と同様の効果を得ることができる。
【０１３１】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の間で歳出データが二重管理される場合を説明したが、開示のシステムはこれに限定されるものではない。例えば、設計段階のレコードデータを管理するシステムと、施工段階のレコードデータを管理するシステムとが併存する場合が挙げられる。このように、システム間で管理するレコードデータの守備範囲が異なりつつもその一部が重複する場合やシステム間で管理するレコードデータの対象は共通するが管理に時間的なズレが生じる場合に開示のシステムを同様に適用することができる。
【０１３２】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の２つのシステムでレコードデータが二重管理される場合を説明したが、３つ以上のシステムで任意のレコードデータが多重管理される場合にも開示のシステムを同様に適用できる。
【０１３３】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の間で二重管理させる共通の項目のデータを完全一致させる場合を説明したが、一方の項目データが他方の項目データの部分集合となる場合を同一とみなすこととしてもよい。
【０１３４】
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、マッチング処理部１５ａ、エラー通知制御部１５ｂ、修正許可判定部１５ｃ、修正処理部１５ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の予算管理サーバの機能を実現するようにしてもよい。また、記憶部に記憶される予算管理テーブル１４ａ、担当者テーブル１４ｂ、項目テーブル１４ｃ、エラー管理テーブル１４ｄの全部または一部を別の装置がそれぞれ有するように構成する。その上で、ネットワーク接続されて協働することで、上記の予算管理サーバの機能を実現するようにしてもかまわない。
【０１３５】
［データ修正管理プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１８を用いて、上記の実施例と同様の機能を有するデータ修正管理プログラムを実行するコンピュータの一例について説明する。なお、図１８は、実施例３に係るデータ修正管理プログラムを実行するコンピュータの一例について説明するための図である。
【０１３６】
図１８に示すように、実施例３におけるコンピュータ５００は、操作部５１０ａと、マイク５１０ｂと、スピーカ５１０ｃと、ディスプレイ５２０と、通信部５３０とを有する。さらに、このコンピュータ５００は、ＣＰＵ５５０と、ＲＯＭ５６０と、ＨＤＤ（Hard Disk Drive）５７０と、ＲＡＭ（Random Access Memory）５８０と有する。これら５１０〜５８０の各部はバス５４０を介して接続される。
【０１３７】
ＲＯＭ５６０には、上記の実施例３で示したマッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ５６０には、図１８に示すように、マッチング処理プログラム５６０ａと、エラー通知制御プログラム５６０ｂと、修正許可判定プログラム５６０ｃと、修正処理プログラム５６０ｄとが記憶される。なお、これらのプログラム５６０ａ〜５６０ｄについては、図２に示した予算管理サーバの各構成要素と同様、適宜統合又は分離しても良い。
【０１３８】
そして、ＣＰＵ５５０が、これらのプログラム５６０ａ〜５６０ｄをＲＯＭ５６０から読み出して実行する。これによって、ＣＰＵ５５０は、図１８に示すように、各プログラム５６０ａ〜５６０ｄについては、マッチング処理プロセス５５０ａ及びエラー通知制御プロセス５５０ｂとして機能するようになる。さらに、ＣＰＵ５５０は、修正許可判定プロセス５５０ｃ及び修正処理プロセス５５０ｄとして機能するようになる。なお、各プロセス５５０ａ〜５５０ｄは、図３に示した、マッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄとにそれぞれ対応する。
【０１３９】
そして、ＨＤＤ５７０には、予算管理テーブル５７０ａと、担当者テーブル５７０ｂと、項目テーブル５７０ｃと、エラー管理テーブル５７０ｄとが設けられる。なお、これら予算管理テーブル５７０ａ、担当者テーブル５７０ｂ、項目テーブル５７０ｃ及びエラー管理テーブル５７０ｄは、図３に示した予算管理テーブル１５ａ、担当者テーブル１５ｂ、項目テーブル１５ｃ及びエラー管理テーブル１５ｄに対応する。
【０１４０】
そして、ＣＰＵ５５０は、予算管理テーブル５７０ａ、担当者テーブル５７０ｂ、項目テーブル５７０ｃ及びエラー管理テーブル５７０ｄを読み出してＲＡＭ５８０に格納する。さらに、ＣＰＵ５５０は、ＲＡＭ５８０に格納された予算管理データ５８０ａと、担当者データ５８０ｂと、項目データ５８０ｃと、エラー管理データ５８０ｄとを用いて、データ修正管理プログラムを実行する。
【０１４１】
なお、上記したデータ修正管理プログラムについては、必ずしも最初からＨＤＤ５７０やＲＯＭ５６０に記憶させておく必要はない。例えば、コンピュータ５００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ５００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ５００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１４２】
１ データ修正管理装置
２ 修正許可者記憶部
３ 修正許可判定部
１０ 予算管理サーバ
１１ 記録媒体読取部
１２ 通信制御Ｉ／Ｆ部
１３ メール配信部
１４ 記憶部
１４ａ 予算管理テーブル
１４ｂ 担当者テーブル
１４ｃ 項目テーブル
１４ｄ エラー管理テーブル
１５ 制御部
１５ａ マッチング処理部
１５ｂ エラー通知制御部
１５ｃ 修正許可判定部
１５ｄ 修正処理部
２０ ＡＤＡＭＳサーバ
２５ ＡＤＡＭＳ端末
３０Ａ，３０Ｂ 端末
４０ 記録媒体
１００ データ修正管理システム
２００ ＡＤＡＭＳ
３００ 予算管理システム
【技術分野】
【０００１】
本発明は、データ修正管理プログラム及びデータ修正管理方法に関する。
【背景技術】
【０００２】
複数のシステム（system）によって共通の項目を含んで構成されるレコードデータ（record data）が同一であることを担保しながら二重に管理する二重管理が行われている。このような二重管理の下、２つのシステムで管理されるレコードデータの内容が一部異なる状態、すなわちシステム間でレコードデータが不整合となる状態が発生した場合には、一方のシステムで整合性が担保されるようにレコードデータの修正がなされる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−２０３３６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、複数のシステムでレコードデータの二重管理を行う場合には、レコードデータの入力を行った入力者単位でしかレコードデータの修正を行うことができず、レコードデータの修正を効率よく行うには自ずから限界があった。
【０００５】
すなわち、上記のレコードデータの修正は、原則として、レコードデータの入力を行った入力者により実行される。なぜなら、入力者以外の者は、レコードデータが入力された経緯を把握しておらず、どのような修正を行えばよいかを判断できないからである。このようにレコードデータの修正を実行させる修正実行者を入力者に固定した場合には、入力者がレコードデータの修正を実行するまでシステム間のレコードデータの不整合状態を放置する他なく、レコードデータの修正が滞ってしまう。
【０００６】
開示の技術は、上記に鑑みてなされたものであって、複数のシステムでレコードデータの二重管理を行う場合にレコードデータの修正を効率化できるデータ修正管理プログラム及びデータ修正管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示するデータ修正管理プログラムは、複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用される。前記データ修正管理プログラムは、前記データ修正管理装置を修正許可者記憶部として機能させる。前記修正許可記憶部は、レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する。前記データ修正管理プログラムは、前記データ修正管理装置に、前記レコードデータの修正要求を受け付けた場合に、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定手順を実行させる。前記修正許可判定手順は、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求者に当該レコードデータの修正を許可するか否か判定する。
【発明の効果】
【０００８】
本願の開示するデータ修正管理プログラムの一つの態様によれば、複数のシステムでレコードデータの二重管理を行う場合にレコードデータの修正を効率よく行うことができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１に係るデータ修正管理システムに含まれるデータ修正管理装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るデータ修正管理システムのシステム構成を示す図である。
【図３】図３は、実施例２に係る予算管理サーバの構成を示すブロック図である。
【図４】図４は、担当者テーブルに記憶される情報の構成例を示す図である。
【図５】図５は、項目テーブルに記憶される情報の構成例を示す図である。
【図６Ａ】図６Ａは、予算管理レコードの一例を示す図である。
【図６Ｂ】図６Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図７Ａ】図７Ａは、予算管理レコードの一例を示す図である。
【図７Ｂ】図７Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図８Ａ】図８Ａは、予算管理レコードの一例を示す図である。
【図８Ｂ】図８Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図９Ａ】図９Ａは、予算管理レコードの一例を示す図である。
【図９Ｂ】図９Ｂは、ＡＤＡＭＳレコードの一例を示す図である。
【図１０】図１０は、エラー管理テーブルに対する検索画面の一例を示す図である。
【図１１】図１１は、エラー管理テーブルの検索結果画面の一例を示す図である。
【図１２】図１２は、修正画面の一例を示す図である。
【図１３】図１３は、同意画面の一例を示す図である。
【図１４】図１４は、修正同意画面の一例を示す図である。
【図１５】図１５は、実施例２に係るエラー通知制御処理の手順を示すフローチャートである。
【図１６】図１６は、実施例２に係るマッチング処理の手順を示すフローチャートである。
【図１７】図１７は、実施例２に係る修正許可判定処理の手順を示すフローチャートである。
【図１８】図１８は、実施例３に係るデータ修正管理プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１０】
以下に、本願の開示するデータ修正管理プログラム及びデータ修正管理方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１１】
図１は、実施例１に係るデータ修正管理システムに含まれるデータ修正管理装置の構成を示すブロック図である。図１に示すデータ修正管理装置１は、複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるものである。図１に示すように、データ修正管理装置１は、修正許可者記憶部２と、修正許可判定部３とを有する。
【００１２】
このうち、修正許可者記憶部２は、レコードデータの項目ごとにそのレコードデータの修正が許可されている修正許可者がレコードデータを入力した入力者であるか、または入力者を含むグループ員のいずれであるかを対応付けて記憶する。
【００１３】
修正許可判定部３は、レコードデータの修正要求を受け付けた場合に、修正要求を行う修正要求者にレコードデータの修正を許可するか否か判定する。この修正許可判定部３は、修正対象とされる項目に対応付けて修正許可者記憶部２に記憶された修正許可者が入力者またはグループ員であるかに基づき、修正要求者にレコードデータの修正を許可するか否か判定する。
【００１４】
すなわち、データ修正管理装置１は、レコードデータの中でも特に重要ではない項目に関する修正については入力者を含むグループ員を修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、入力者によってレコードデータが修正されるのを待たずともグループ員の誰かにレコードデータを修正させることができる。
【００１５】
また、データ修正管理装置１は、レコードデータの中でも重要な項目に関する修正については入力者だけを修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、レコードデータが入力された経緯を把握していない者に修正が実行されることによりレコードデータの重要な項目に間違いが生じることもない。
【００１６】
このように、本実施例に係るデータ修正管理システムでは、レコードデータの重要な項目に間違いを生じさせることなく、レコードデータの修正が滞る期間を低減させることができる。したがって、本実施例に係るデータ修正管理システムによれば、複数のシステムでレコードデータの二重管理を行う場合に、レコードデータの修正を効率よく行うことが可能になる。
【実施例２】
【００１７】
続いて、実施例２に係るデータ修正管理システムについて説明する。なお、以下では、官庁会計事務データ通信システム（ＡＤＡＭＳ：governmental Accounting affairs Data communication Management Systems）及び予算管理システムによって共通の項目を含んで構成される歳出データが二重管理される場合を想定する。
【００１８】
［データ修正管理システムの構成］
図２は、実施例２に係るデータ修正管理システムのシステム構成を示す図である。図２に示すように、データ修正管理システム１００には、国庫に関する歳入処理及び歳出処理などの会計事務を電子化したＡＤＡＭＳ２００と、ＡＤＡＭＳ２００の歳出処理を補助する予算管理システム３００とが含まれる。
【００１９】
これらＡＤＡＭＳ２００及び予算管理システム３００により、国庫の歳出に関する共通の項目を含んで構成されるマスタデータ（master data）が二重管理される。このような二重管理がなされる背景には、ＡＤＡＭＳ端末２５に搭載されるソフトウェアのカスタマイズ（customize）が困難であること、ＡＤＡＭＳ端末２５の設置台数が官署の人員に比較して少数しか配設されないことなどが挙げられる。
【００２０】
このことから、ＡＤＡＭＳ２００のデメリットを補うために予算管理システム３００が導入される。この予算管理システム３００の導入により、各官署では、ＡＤＡＭＳ２００のマスタデータには登録できない独自の項目をマスタデータに追加したり、官署の担当者が自身の端末で歳出データを作成したりすることができる。
【００２１】
図２に示すＡＤＡＭＳ２００は、財務省会計センタに設けられるＡＤＡＭＳサーバ２０と、各官署に設けられるＡＤＡＭＳ端末２５とを有する。なお、図２の例では、官署に設けられるＡＤＡＭＳ端末２５を１つとする場合を例示したが、官署の規模に応じて複数のＡＤＡＭＳ端末２５が設けられることとしてもよい。
【００２２】
これらＡＤＡＭＳサーバ２０及びＡＤＡＭＳ端末２５は、ネットワーク２３を介して相互に通信可能に接続される。なお、ネットワーク２３は、専用回線であって公衆回線であってもかまわない。
【００２３】
ＡＤＡＭＳサーバ２０は、各官署の歳出データ及び歳入データを統括管理するサーバ装置である。このＡＤＡＭＳサーバ２０は、ＡＤＡＭＳ端末２５から収集した歳出データに基づき、国庫から支出先の口座への振込み決済などを図示しない日本銀行に設けられた銀行サーバに依頼する機能を有する。
【００２４】
ＡＤＡＭＳ端末２５は、官署内の歳出データを記憶する端末である。一例として、ＡＤＡＭＳ端末２５は、自装置の入力デバイス（device）を介して歳出データを受け付ける。他の一例として、ＡＤＡＭＳ端末２５は、記録媒体４０に記録された歳出データを読取装置を介して取得する。なお、ＡＤＡＭＳ端末２５は、自装置に記憶した歳出データをＣＳＶ（Comma Separated Values）データとして記録媒体４０へ出力することもできる。
【００２５】
かかる記録媒体４０には、フレキシブルディスク（ＦＤ：Flexible Disk）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ（Digital Versatile Disc）ディスク、光磁気ディスクやＩＣ（Integrated Circuit）カードなどを適用できる。
【００２６】
また、図２に示す予算管理システム３００は、端末３０Ａ及び端末３０Ｂと、予算管理サーバ１０とを有する。これら端末３０Ａ及び端末３０Ｂと予算管理サーバ１０とは、図示しないＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）を介して相互に通信可能に接続される。
【００２７】
端末３０Ａ及び端末３０Ｂは、予算管理用のソフトウェアがインストール（install）された端末装置である。一例としては、官署の担当者によって使用されるパーソナルコンピュータ（ＰＣ：Personal Computer）などのコンピュータ（computer）が挙げられる。
【００２８】
予算管理サーバ１０は、各端末３０によって生成された歳出データを管理するサーバ装置である。この予算管理サーバ１０は、端末３０を使用する官署の担当者のログイン（login）認証をＩＤや暗証番号の入力を通じて行った上で自装置へのアクセスを許可するサーバとしての基本機能の他にも、上記の実施例１に係るデータ修正管理装置１の機能をさらに有する。なお、詳細については図３を用いて後述する。
【００２９】
なお、本実施例では、２つのシステムで取り扱われる歳出データを区別するために、ＡＤＡＭＳ２００により扱われる歳出データを「ＡＤＡＭＳデータ」と呼び、予算管理システム３００により扱われる歳出データを「予算管理データ」と呼ぶこととする。また、ＡＤＡＭＳデータのレコードデータを指して説明を行う場合には「ＡＤＡＭＳレコード」と呼び、また、予算管理データのレコードデータを指して説明を行う場合には「予算管理レコード」と呼ぶこととする。
【００３０】
また、本実施例では、ＡＤＡＭＳ端末２５がシステム外部の装置とは直接通信によるデータ授受を実行しないものとして以下の説明を行う。すなわち、ＡＤＡＭＳ端末２５が記憶する歳出データをシステム外部の装置に使用させる場合やシステム外部の装置が記憶する歳出データをＡＤＡＭＳ端末２５に使用させる場合には、記憶媒体４０を介して歳出データが授受される。なお、ここでは、ＡＤＡＭＳ端末２５とシステム外部の装置との間における直接通信によるデータ授受を禁止する場合を説明するが、直接通信によるデータ授受を行う場合にも開示のシステムを同様に適用できる。
【００３１】
［予算管理サーバの構成］
続いて、本実施例に係る予算管理サーバの構成について説明する。図３は、実施例２に係る予算管理サーバの構成を示すブロック図である。図３に示すように、予算管理サーバ１０は、記録媒体読取部１１と、通信制御Ｉ／Ｆ（interface）部１２と、メール配信部１３と、記憶部１４と、制御部１５とを有する。なお、予算管理サーバ１０は、図３の例では図示していないが、既存のサーバ装置が有するハードウェア、例えば入力デバイスや表示デバイス、さらには、ソフトウェアを有するものとする。
【００３２】
このうち、記録媒体読取部１１は、記録媒体４０に記録された情報を読み取る読取装置である。一例としては、ＦＤドライブ（drive）、ＣＤ−ＲＯＭドライブ、ＤＶＤディスクドライブ、光磁気ディスクドライブやＩＣカードのリーダライタ（reader/writer）などが挙げられる。
【００３３】
通信制御Ｉ／Ｆ部１２は、他の装置、例えば端末３０との間で通信を行うためのインタフェースである。また、メール配信部１３は、後述のエラー通知制御部１５ｂの指示に基づき、電子メールの作成や送受信を行う処理部である。
【００３４】
記憶部１４は、例えば、フラッシュメモリ（flash memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。なお、記憶部１４は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。
【００３５】
この記憶部１４は、制御部１５で実行されるＯＳ（Operating System）などの各種プログラム及びそのプログラムの実行に必要なデータを記憶する。例えば、記憶部１４は、予算管理テーブル１４ａと、担当者テーブル１４ｂと、項目テーブル１４ｃと、エラー管理テーブル１４ｄとを併せて記憶する。
【００３６】
このうち、予算管理テーブル１４ａは、入力番号、入力者、整理番号、日付、予算科目、業者、金額や備考などの項目が対応付けられた予算管理データを記憶したテーブルである。ここで、予算管理テーブル１４ａは、ＡＤＡＭＳレコードの全項目を含むように定義される。上記の８項目を含んでなる予算管理レコードのうち入力番号を除く残りの７項目は、ＡＤＡＭＳレコードとの間で共通する。
【００３７】
なお、「入力番号」は、予算管理レコードが生成された場合に採番される識別番号を指す。また、「入力者」は、予算管理レコードの作成を担当した担当者を指す。また、「整理番号」は、ＡＤＡＭＳレコードが生成された場合に採番される識別番号を指す。また、「日付」は、予算管理レコードが作成された日付を指す。また、「予算科目」は、予算の区分を指す。また、「業者」は、予算の支出先の業者を指す。また、「金額」は、予算として計上された金額を指す。また、「備考」は、予算管理レコードに関する補足事項を指す。
【００３８】
担当者テーブル１４ｂは、テーブル内のレコードの連番ごとに担当者が所属する部署の名称、担当者の氏名、メールアドレス（mail address）及び担当者が属するグループを対応付けて記憶したテーブルである。
【００３９】
図４は、担当者テーブルに記憶される情報の構成例を示す図である。図４に示す例では、連番１〜連番３に登録されている総務課に所属の総務太郎、総務花子及び総務次郎の３名はともに担当者グループが「Ａ」であり、各々のメールアドレスが「aaa@zzz.co.jp」、「bbb@zzz.co.jp」、「ccc@zzz.co.jp」であることを示す。また、連番４〜連番５に登録されている会計課に所属の会計太郎及び会計花子の２名はともに担当者グループが「Ｂ」であり、各々のメールアドレスが「ddd@zzz.co.jp」、「eee@zzz.co.jp」であることを示す。さらに、連番６に登録されている人事課に所属の人事次郎は担当者グループが「Ｃ」であり、メールアドレスが「fff@zzz.co.jp」であることを示す。
【００４０】
項目テーブル１４ｃは、テーブル内のレコードの連番ごとに項目名及び修正許可者を対応付けて記憶したテーブルである。ここで言う「修正許可者」は、予算管理レコードの修正を許可する担当者の種別を指す。
【００４１】
図５は、項目テーブルに記憶される情報の構成例を示す図である。図５に示す例では、連番１〜連番４に登録されている項目「日付」、「金額」、「業者」及び「予算科目」の修正許可者が入力者であり、連番５に登録されている「備考」の修正許可者が入力者を含むグループ員であることを示す。
【００４２】
エラー管理テーブル１４ｄは、予算管理レコードのエラーを管理するためのテーブルである。このエラー管理テーブル１４ｄは、テーブル内の連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者や進捗状況などのスキームを有する。ここで、エラー管理テーブル１４ｄは、予め定義されたテーブルではなく、後述のマッチング処理部１５ａによって動的に作成されるものである。このようにしてテーブルが生成された後には、後述のエラー通知制御部１５ｂ及び後述の修正処理部１５ｄにより進捗状況が更新される。
【００４３】
ここで、ＡＤＡＭＳサーバ２０が銀行サーバへ決済を依頼する場合には、ＡＤＡＭＳ端末２５に入力された歳出データが使用される。このため、ＡＤＡＭＳレコードには、最終確定した内容が規定されている可能性が高い。それゆえ、本実施例では、ＡＤＡＭＳレコード及び予算管理レコードの内容が一部異なる場合には、ＡＤＡＭＳレコードが「真」であるものとしてＡＤＡＭＳレコードとの間で整合性が担保されるように予算管理レコードが入力者により修正される場合を想定する。
【００４４】
上記の「入力者（１）」は、予算管理レコードを作成した入力者を指し、「入力者（２）」は、ＡＤＡＭＳレコードを作成した入力者を指す。また、「エラー項目」は、ＡＤＡＭＳレコードとの間で整合性が取れていない予算管理レコードの項目を指す。また、「修正実行者」は、予算管理レコードの修正を実行した担当者を指す。この修正実行者のフィールドは予算管理レコードの修正が実行されるまではブランクの状態にある。
【００４５】
また、「同意要否」は、予算管理レコードの入力者（１）による修正にＡＤＡＭＳレコードの入力者（２）の同意を要するか否かを示すフィールドである。この同意要否のフィールドには、エラー項目に対応する修正許可者としてグループ員が許容されずに入力者のみが規定されているか、または入力者（１）と入力者（２）とが別人である場合にも「要」が設定される。それ以外の場合には、同意要否のフィールドに「不要」が設定される。
【００４６】
また、「進捗状況」は、予算管理レコードのエラーが検出されてから修正が完了したとみなされるまでの進捗を「メール送信」、「メール受信」、「データ修正」、「修正同意」、「最終」の５段階に分けて管理される。
【００４７】
これを説明すると、マッチング処理部１５ａによりエラー管理テーブル１４ｄが生成された初期段階では、５つの段階全てが「未完了」とされている。例えば、後述のエラー通知制御部１５ｂによって予算管理レコードの修正を促すエラー通知メールが入力者（１）へ送信された場合には、メール送信の進捗が「完了」に更新される。また、端末３０でエラー通知メールの受信確認がなされた場合には、メール受信の進捗が「完了」に更新される。さらに、入力者（１）が使用する端末３０または入力者（１）を含むグループ員が使用する端末３０から予算管理レコードの修正を受け付けた場合には、データ修正の進捗が「完了」に更新される。また、入力者（２）が使用する端末３０から入力者（１）が行った修正内容に対する同意入力を受け付けた場合には、修正同意の進捗が「完了」に更新される。最後に、同意要否が「不要」に設定されている場合には、後述の修正処理部１５ｄによりデータ修正の進捗が「完了」に更新された段階で最終の進捗も「完了」に更新される。また、同意要否が「要」に設定されている場合には、後述の修正処理部１５ｄにより修正同意の進捗が「完了」に更新された段階で最終の進捗も「完了」に更新される。
【００４８】
制御部１５は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路またはＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。
【００４９】
この制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５は、図３に示すように、マッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄとを有する。
【００５０】
マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードをマッチングすることによりシステム間で共通する項目のデータが所定の修正条件を満たす予算管理レコードをマッチング結果として抽出する処理部である。
【００５１】
これを説明すると、マッチング処理部１５ａは、例えば、記録媒体４０に記録されたＡＤＡＭＳデータが記録媒体読取部１１により読み取られた場合には、ＡＤＡＭＳデータに含まれるＡＤＡＭＳレコードを１つ取り出す。そして、マッチング処理部１５ａは、このようにして取り出したＡＤＡＭＳレコードに含まれる整理番号と同一の整理番号を持つ予算管理レコードの抽出を試行する。このとき、同一の整理番号を持つ予算管理レコードが存在する場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一であるか否かをさらに判定する。
【００５２】
そして、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一である場合には、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合性が取れていると判別する。
【００５３】
一方、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する項目のいずれかのデータが非同一である場合には、２つのシステム間でレコードデータの整合がないと判別する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードと一致しない項目をエラー項目として特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者及び進捗状況が対応付けられたエラー管理レコードを生成する。なお、この時点では、修正は実行されていないので、修正実行者のフィールドはブランクとされる。
【００５４】
図６Ａは、予算管理レコードの一例を示す図である。図６Ｂは、ＡＤＡＭＳレコードの一例を示す図である。図６Ａ及び図６Ｂの例で言えば、ＡＤＡＭＳレコード及び予算管理レコードの整理番号が同一であり、かつ両レコード間で「日付」及び「備考」が非同一である。したがって、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合がないと判別する。この場合には、マッチング処理部１５ａは、エラー項目を「日付、備考」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「30000」とし、入力番号を「00003」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「日付、備考」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００５５】
また、同一の整理番号を持つ予算管理レコードが存在しない場合には、マッチング処理部１５ａは、先のＡＤＡＭＳレコードとの間で所定の一致度を有する予算管理レコードが存在するか否かをさらに判定する。一例としては、マッチング処理部１５ａは、両レコードで共通する項目から整理番号を除いた７項目のうち６項目のデータが一致する一致度を有する予算管理レコードが存在するか否かを判定する。なお、ここでは、不一致を許容する項目数を１項目としたが、任意の項目数であってかまわない。例えば、項目数に所定のパラメータを乗算または除算することとしてもよい。また、不一致項目が金額であった場合には、両者のズレが「\50,000」以内などのように更なる条件を付加することとしてもかまわない。
【００５６】
そして、所定の一致度を有する予算管理レコードが存在しない場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードの対となる予算管理レコードが存在しないと判別する。この場合には、担当者が、ＡＤＡＭＳレコードがＡＤＡＭＳ端末２５で直接入力されたまま、対となる予算管理レコードを事後的に登録し忘れた可能性が高い。このため、マッチング処理部１５ａは、予算管理レコードの登録し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請する。かかる要請を受け付けたエラー通知制御部１５ｂによりＡＤＡＭＳレコードに含まれる入力者に対応するメールアドレスが担当者テーブル１４ｂから抽出される。そして、エラー通知制御部１５ｂにより予算管理レコードの登録し忘れを注意喚起するメールが先のメールアドレスへ送信制御される。
【００５７】
一方、所定の一致度を有する予算管理レコードが存在する場合には、マッチング処理部１５ａは、少数の項目の入力間違いがあったものと判別する。この場合には、マッチング処理部１５ａは、予算管理レコードのうち整理番号を除いて一致しなかった項目をエラー項目と判別する。その上で、マッチング処理部１５ａは、連番、整理番号、入力番号、入力者（１）、入力者（２）、エラー項目、同意要否、修正実行者及び進捗状況が対応付けられたエラー管理レコードを生成する。なお、この時点では、修正は実行されていないので、修正実行者のフィールドはブランクとされる。
【００５８】
図７Ａ、図８Ａ及び図９Ａは、予算管理レコードの一例を示す図である。図７Ｂ、図８Ｂ及び図９Ｂは、ＡＤＡＭＳレコードの一例を示す図である。図７Ａ及び図７Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「30000」に対応する予算管理レコードはないが、整理番号と備考を除く他の項目で一致する予算管理レコードが存在する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードを一対のレコードと推定し、エラー項目を「整理番号未採番、備考」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「30000」とし、入力番号を「00003」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「整理番号未採番、備考」とし、同意要否を「不要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００５９】
また、図８Ａ及び図８Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「40000」に対応する予算管理レコードはないが、整理番号と日付を除く他の項目で一致する予算管理レコードが存在する。この場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードを一対のレコードと推定し、エラー項目を「整理番号未採番、日付」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を新たに採番する。その上で、マッチング処理部１５ａは、採番した番号を連番とし、整理番号を「40000」とし、入力番号を「00004」とし、入力者（１）及び入力者（２）を「担当者Ｂ」とし、エラー項目「整理番号未採番、日付」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの同意要否、修正実行者及び進捗状況をブランクとしてエラー管理レコードを生成する。
【００６０】
さらに、図９Ａ及び図９Ｂの例で言えば、ＡＤＡＭＳレコードの整理番号「50000」に対応する予算管理レコードはないが、整理番号と金額を除く他の項目で一致する予算管理レコードが３つ存在する。また、不一致項目である金額についても「\50,000」以内に収まる。この場合には、マッチング処理部１５ａは、１つのＡＤＡＭＳレコードに対し、予算管理レコードが３つも登録されており、３つのうちいずれかの予算管理レコードがＡＤＡＭＳレコードと一対になるものと推定する。そして、マッチング処理部１５ａは、エラー項目を「整理番号未採番、金額」と特定してエラー管理テーブル１４ｄにおけるテーブル内の連番を各予算管理レコードごとに採番する。その上で、マッチング処理部１５ａは、採番した番号それぞれを連番とし、整理番号を「50000」とし、入力番号を「00005」とし、入力者（１）及び入力者（２）を「担当者Ｃ」とし、エラー項目「整理番号未採番、金額」とし、同意要否を「要」とする。さらに、マッチング処理部１５ａは、残りの修正実行者及び進捗状況をブランクとしてエラー管理レコードを３つ生成する。このように、１つのＡＤＡＭＳレコードに対し、予算管理レコードが３つも登録されている場合には、１つの予算管理レコードが最終の進捗が「完了」に更新されたこともって他の２つの予算管理レコードを自動的に削除させることもできる。
【００６１】
このように、マッチング処理部１５ｃは、ＡＤＡＭＳデータに含まれる全てのＡＤＡＭＳレコードを上記のマッチングが終了するまで繰り返し行う。このとき、全てのＡＤＡＭＳレコードを対象にマッチングが終了した場合には、予算管理レコードの対となるＡＤＡＭＳレコードが存在しない。このため、ＡＤＡＭＳレコードとペアリングされずに残った予算管理レコードは、対となるＡＤＡＭＳレコードがＡＤＡＭＳ端末２５にも登録されたはずであったが事情変更により削除された場合が想定される。よって、マッチング処理部１５ａは、予算管理レコードの削除し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請する。かかる要請を受け付けたエラー通知制御部１５ｂにより予算管理レコードに含まれる担当者に対応するメールアドレスが担当者テーブル１４ｂから抽出される。そして、エラー通知制御部１５ｂにより予算管理レコードの削除し忘れを注意喚起するメールが先のメールアドレスへ送信制御される。
【００６２】
なお、本実施例では、ＡＤＡＭＳレコード及び予算管理レコードの内容が一部異なる場合にＡＤＡＭＳレコードが「真」であると仮定することとしたが、予算管理レコードが「真」であると仮定することとしてもかまわない。例えば、ＡＤＡＭＳレコードが「真」であると仮定とした場合には、ＡＤＡＭＳレコードとペアリングされずに残った予算管理レコードは、ＡＤＡＭＳ端末２５にも登録されるはずであったが登録し忘れられた場合も想定される。このような場合には、マッチング処理部１５ａは、ＡＤＡＭＳレコードの登録し忘れを注意喚起するようにエラー通知制御部１５ｂへ要請することもできる。
【００６３】
エラー通知制御部１５ｂは、入力者またはグループ員が使用する端末３０に対して、予算管理レコードのエラー内容を通知する処理部である。
【００６４】
これを説明すると、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるエラー管理レコードを取得する。そして、エラー通知制御部１５ｂは、項目テーブル１４ｃを参照して、先に取得したエラー管理レコードに含まれるエラー項目に対応する修正許可者が入力者またはグループ員のいずれであるかを判定する。
【００６５】
このとき、修正許可者がグループ員であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）が所属する担当者グループ全員のメールアドレスを担当者テーブル１４ｂからそれぞれ読み出す。そして、エラー通知制御部１５ｂは、担当者グループ全員のメールアドレスに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。
【００６６】
また、修正許可者が入力者であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）が別人であるか否かをさらに判定する。この結果、入力者（１）及び入力者（２）が別人であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）のメールアドレスを担当者テーブル１４ｂからそれぞれ読み出す。そして、エラー通知制御部１５ｂは、入力者（１）及び入力者（２）のメールアドレスそれぞれに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。なお、入力者（２）に通知するメールには、修正が最終確定するまでに入力者（２）による同意入力を要する旨を追加するようにしてもよい。
【００６７】
一方、入力者（１）及び入力者（２）が同一人であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）のメールアドレスを担当者テーブル１４ｂから読み出す。そして、エラー通知制御部１５ｂは、入力者（１）のメールアドレスに対して、予算管理レコードの修正を促すメッセージやエラー項目を含んだエラー通知メールをメール配信部１３に配信させる。
【００６８】
このようにエラー通知メールを配信させた後には、エラー通知制御部１５ｂは、エラー管理レコードに含まれるデータ送信の進捗を「未完了」から「完了」へ更新する。そして、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるエラー管理レコードがなくなるまで、エラー通知メールをメール配信部１３に配信させる。
【００６９】
修正許可判定部１５ｃは、予算管理レコードに対する修正要求を受け付けた場合に、修正要求者に予算管理レコードの修正を許可するか否か判定する処理部である。
【００７０】
このように端末３０から修正要求がなされる前に修正要求者のログイン認証が予算管理サーバ１０により実行される。予算管理サーバ１０は、端末３０に予算管理サーバ１０の予算管理テーブル１４ａへアクセスさせる前に、端末３０を使用する担当者のログイン認証をＩＤや暗証番号の入力を通じて行った上でアクセスを許可する。このようなログイン認証の実行後には、予算管理サーバ１０は、ログイン認証時に発行したセッションＩＤを追跡することにより、どの担当者が使用する端末３０からアクセスを受け付けているのかを特定できる。
【００７１】
その後、端末３０を使用する修正要求者は、エラー管理テーブル１４ｄを検索することにより、自分、自分が所属する担当者グループまたは全担当者の中から任意の参照範囲で修正が注意喚起されている予算管理レコードの進捗状況を参照することができる。
【００７２】
図１０は、エラー管理テーブルに対する検索画面の一例を示す図である。図１０に示す検索画面５０では、エラー管理テーブル１４ｄに対する検索条件として、予算管理レコードの修正を促されている修正担当者、修正内容の同意入力を促されている同意担当者、最終進捗に関する検索範囲を指定できる。また、検索画面５０では、コンボボックス５１のボタン５１ａをクリックすることにより「全担当者」、「自所属の担当者グループ」及び「自分のみ」がプルダウン表示され、これらの中から修正担当者の検索範囲を指定できる。また、検索画面５０では、コンボボックス５２のボタン５２ａをクリックすることにより「全担当者」、「自所属の担当者グループ」及び「自分のみ」がプルダウン表示され、これらの中から同意担当者の検索範囲を指定できる。さらに、検索画面５０では、コンボボックス５３のボタン５３ａをクリックすることにより「全データ」、「未完了のみ」及び「完了のみ」がプルダウン表示され、これらの中から最終進捗の検索範囲を指定できる。これらコンボボックス５１〜５３を用いて検索範囲を指定した後にＯＫボタン５５をクリックすることにより、全２７通りの中から任意の検索条件でエラー管理テーブルに検索を実行できる。なお、閉じるボタン５４がクリックされた場合には、検索画面５０が閉じられる。
【００７３】
図１１は、エラー管理テーブルの検索結果画面の一例を示す図である。図１１に示す連番「1」には、整理番号「11111」、入力番号「00010」、入力者（１）「総務太郎」、入力者（２）「総務次郎」、エラー項目「金額」、同意要否「要」及び修正実行者「総務太郎」が対応付けられている。この連番「1」の予算管理レコードの修正は最終の進捗が「完了」であるので、「メール送信」、「メール受信」、「データ修正」、「修正同意」などの過程が既に終了し、修正が完結している状態を示す。
【００７４】
図１１に示す連番「2」には、整理番号「22222」、入力番号「00025」、入力者（１）「総務太郎」、入力者（２）「総務太郎」、エラー項目「備考」、同意要否「不要」及び修正実行者「総務太郎」が対応付けられている。この連番「2」の予算管理レコードの修正は最終の進捗が「完了」であるので、「メール送信」、「メール受信」、「データ修正」などの過程が既に終了し、修正が完結している状態を示す。
【００７５】
図１１に示す連番「3」には、整理番号「33333」、入力番号「00053」、入力者（１）「総務太郎」、入力者（２）「総務太郎」、エラー項目「予算科目」、同意要否「要」及び修正実行者「総務太郎」が対応付けられている。この連番「3」の予算管理レコードの修正はメール受信までの進捗が「完了」であるので、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７６】
図１１に示す連番「4」には、整理番号「-」、入力番号「00065」、入力者（１）「会計花子」、入力者（２）「総務次郎」、エラー項目「整理番号未付与」、同意要否「要」及び修正実行者「-」が対応付けられている。この連番「4」の予算管理レコードの修正はメール送信までの進捗が「完了」であるので、「メール受信」、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７７】
図１１に示す連番「5」には、整理番号「-」、入力番号「00066」、入力者（１）「会計花子」、入力者（２）「会計花子」、エラー項目「整理番号未付与」、同意要否「不要」及び修正実行者「-」が対応付けられている。この連番「5」の予算管理レコードの修正はメール送信までの進捗が「完了」であるので、「メール受信」、「データ修正」、「修正同意」などは未だ実行されていない状態を示す。
【００７８】
ここで、図１１に示す検索結果画面６０にていずれかのエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、端末３０は、修正要求者により指定されたレコードが含む入力番号に対応する予算管理レコードへアクセスを要求する。なお、閉じるボタン６１がクリックされた場合には、検索結果画面６０が閉じられる。また、検索ボタン６２がクリックされた場合には、図１０に示した検索画面５０に戻る。
【００７９】
一方、予算管理サーバ１０の修正許可判定部１５ｃは、アクセス要求を受け付けた予算管理レコードの同意要否、入力者（１）及び入力者（２）をエラー管理テーブル１４ｄから取得する。そして、同意要否が「要」である場合には、修正許可判定部１５ｃは、修正要求者、入力者（１）及び入力者（２）が同一人であるか否かを判定する。
【００８０】
この結果、修正要求者、入力者（１）及び入力者（２）と同一人である場合には、修正許可判定部１５ｃは、修正要求者が修正担当者であるとともに同意担当者でもあるので、予算管理レコードの修正及びその修正内容に対する同意入力を許可する。
【００８１】
一方、修正要求者、入力者（１）及び入力者（２）が同一人ではない場合には、修正許可判定部１５ｃは、修正要求者が入力者（２）と同一人であるか否かをさらに判定する。このとき、修正要求者が入力者（２）と同一人である場合には、修正許可判定部１５ｃは、修正要求者が同意担当者であるので、予算管理レコードの修正内容に対する同意入力を許可する。
【００８２】
また、修正要求者が入力者（２）と同一人でない場合には、修正許可判定部１５ｃは、修正要求者が入力者（１）と同一人であるか否かをさらに判定する。この結果、修正要求者が入力者（１）と同一人である場合には、修正要求者が修正担当者であるので、予算管理レコードの修正を許可する。
【００８３】
修正処理部１５ｄは、予算管理レコードに対する修正処理を行う処理部である。これを説明すると、修正処理部１５ｄは、修正許可判定部１５ｃにより予算管理レコードの修正が許可された修正要求者の端末３０に対して、アクセス要求を受け付けた予算管理レコードを予算管理テーブル１４ａから読み出して送信する。
【００８４】
例えば、図１１に示す検索結果画面６０にて入力番号「00010」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、修正要求者が修正担当者であった場合に、修正処理部１５ｄは、図１２に示す修正画面を端末３０へ送信する。
【００８５】
図１２は、修正画面の一例を示す図である。図１２に示す修正画面７０には、予算管理レコードに含まれる各項目が表示される。この場合には、修正担当者「総務太郎」、同意担当者「総務次郎」、整理番号「11111」、日付「2009/11/30」、予算科目「一般会計 ○○局 庁費」、金額「\20,000」、業者「イ」及び備考「AAAA」が修正画面７０に表示される。
【００８６】
ここで、修正処理部１５ｄは、エラー項目である金額の欄は他の項目とは異なる表示態様で端末３０に表示させる。一例としては、図１２に示すように、金額「\20,000」を反転表示させる。そして、修正担当者により端末３０の入力デバイスを介して図１２に示したエラー項目の部分がＡＤＡＭＳレコードの値と同一になるように予算管理レコードの修正がなされる。
【００８７】
その後、修正画面７０上の修正ボタン７１がクリックされた場合には、端末３０により予算管理レコードが修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともにエラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」に更新する。この場合、修正処理部１５ｄは、同意要否が「要」であるので、最終の進捗は「未完了」のままとする。
【００８８】
なお、一時保存ボタン７３がクリックされた場合には、端末３０で起動する予算管理用のソフトウェアがメモリ等に一時記憶させる。また、閉じるボタン７２がクリックされた場合には、予算管理レコードの修正を中断して修正画面７０が閉じられる。
【００８９】
また、図１１に示す検索結果画面６０にて入力番号「00010」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３がクリックされると、修正要求者が同意担当者であった場合には、修正処理部１５ｄは、図１３に示す同意画面を端末３０へ送信する。
【００９０】
図１３は、同意画面の一例を示す図である。図１３に示す修正画面８０は、図１２に示した修正画面７０に比較して、修正ボタン７１及び一時保存ボタン７３の代わりに、同意ボタン８１及び却下ボタン８２が表示される点が異なる。そして、修正画面８０上の同意ボタン８１がクリックされた場合には、端末３０により修正内容に同意する旨の通知が修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、エラー管理テーブル１４ｄにおける修正同意の進捗を「完了」に更新するとともに最終の進捗を「完了」に更新する。なお、却下ボタン８２がクリックされた場合には、修正処理部１５ｄは、エラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」から「未完了」に差し戻す更新を実行する。
【００９１】
また、図１１に示す検索結果画面６０で入力番号「00053」を含むエラー管理レコードが指定された状態でデータ表示ボタン６３が操作されると、修正要求者が同意担当者であった場合に、修正処理部１５ｄは、図１４に示す修正同意画面を端末３０へ送信する。
【００９２】
図１４は、修正同意画面の一例を示す図である。図１４に示す修正同意画面９０は、図１２に示した修正画面７０に比較して、修正ボタン７１の代わりに、修正同意ボタン９１及び却下ボタン８２が表示される点が異なる。そして、修正同意画面９０上の修正同意ボタン９１がクリックされた場合には、端末３０により予算管理レコードとともに修正内容に同意する旨の通知が修正処理部１５ｄへ送信される。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正、修正同意及び最終の進捗を「完了」に更新する。
【００９３】
［処理の流れ］
次に、本実施例に係る予算管理サーバの処理の流れを説明する。ここでは、予算管理サーバ１０によって実行される（１）エラー通知制御処理、（２）マッチング処理、（３）修正許可判定処理の順に説明することとする。
【００９４】
（１）エラー通知制御処理
図１５は、実施例２に係るエラー通知制御処理の手順を示すフローチャートである。このエラー通知制御処理は、記録媒体４０に記録されたＡＤＡＭＳデータが記録媒体読取部１１により読み取られた場合や予算管理サーバ１０の入力デバイスを介してＡＤＡＭＳデータが手入力された場合など、任意のタイミングで開始できる。なお、ＡＤＡＭＳデータの取得経路は必ずしも記録媒体４０経由で取得する必要はなく、通信により取得することとしてもかまわない。
【００９５】
図１５に示すように、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードをマッチングすることにより、エラー管理テーブル１４ｄの生成を試行する（ステップＳ１０１）。このとき、所定の修正条件を満たす予算管理レコードがなく、エラー管理テーブル１４ｄが生成されなかった場合（ステップＳ１０２否定）には、そのまま処理を終了する。
【００９６】
一方、エラー管理テーブル１４ｄが生成された場合（ステップＳ１０２肯定）に、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が未完了であるレコードを取得する（ステップＳ１０３）。
【００９７】
そして、エラー通知制御部１５ｂは、項目テーブル１４ｃを参照して、先に取得したエラー管理レコードに含まれるエラー項目に対応する修正許可者が入力者またはグループ員のいずれであるかを判定する（ステップＳ１０４）。
【００９８】
このとき、修正許可者がグループ員であった場合（ステップＳ１０４否定）には、エラー通知制御部１５ｂは、入力者（１）が所属する担当者グループ全員のメールアドレスに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０５）。
【００９９】
また、修正許可者が入力者であった場合には、エラー通知制御部１５ｂは、エラー管理レコードに含まれる入力者（１）及び入力者（２）が別人であるか否かをさらに判定する（ステップＳ１０６）。
【０１００】
この結果、入力者（１）及び入力者（２）が同一人であった場合（ステップＳ１０６否定）には、エラー通知制御部１５ｂは、入力者（１）のメールアドレスに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０７）。
【０１０１】
一方、入力者（１）及び入力者（２）が別人であった場合（ステップＳ１０６肯定）に、エラー通知制御部１５ｂは、入力者（１）及び入力者（２）のメールアドレスそれぞれに対して、エラー通知メールをメール配信部１３に配信させる（ステップＳ１０８）。
【０１０２】
このエラー通知メールの配信後に、エラー通知制御部１５ｂは、エラー管理レコードに含まれるデータ送信の進捗を「未完了」から「完了」へ更新する（ステップＳ１０９）。そして、エラー通知制御部１５ｂは、エラー管理テーブル１４ｄに記憶されたエラー管理レコードのうちメール送信の進捗が「未完了」であるレコードがなくなるまで（ステップＳ１１０否定）、上記のステップＳ１０３〜Ｓ１０９までの処理を繰り返し行う。
【０１０３】
その後、メール送信の進捗が「未完了」であるエラー管理レコードがなくなった場合（ステップＳ１１０肯定）には、そのまま処理を終了する。
【０１０４】
（２）マッチング処理
図１６は、実施例２に係るマッチング処理の手順を示すフローチャートである。このマッチング処理は、図１５に示したステップＳ１０１で実行される処理である。図１６に示すように、マッチング処理部１５ａは、ＡＤＡＭＳデータに含まれるＡＤＡＭＳレコードを１つ取得する（ステップＳ２０１）。そして、マッチング処理部１５ａは、このようにして取り出したＡＤＡＭＳレコードに含まれる整理番号と同一の整理番号を持つ予算管理レコードを取得する（ステップＳ２０２）。
【０１０５】
このとき、同一の整理番号を持つ予算管理レコードが存在する場合（ステップＳ２０３肯定）、マッチング処理部１５ａは、ＡＤＡＭＳレコード及び予算管理レコードの間の共通項目のいずれかのデータが非同一であるか否かを判定する（ステップＳ２０４）。
【０１０６】
そして、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する全ての項目のデータが同一である場合（ステップＳ２０４否定）には、マッチング処理部１５ａは、２つのシステム間でレコードデータの整合性が取れていると判別する。この場合には、ステップＳ２０５を実行することなく、ステップＳ２０６へ移行する。
【０１０７】
一方、ＡＤＡＭＳレコード及び予算管理レコードの間で共通する項目のいずれかのデータが非同一である場合（ステップＳ２０４肯定）には、マッチング処理部１５ａは、エラー管理レコードを生成する（ステップＳ２０５）。
【０１０８】
また、同一の整理番号を持つ予算管理レコードが存在しない場合（ステップＳ２０３否定）には、マッチング処理部１５ａは、先のＡＤＡＭＳレコードとの間で所定の一致度を有する予算管理レコードが存在するか否かをさらに判定する（ステップＳ２０７）。
【０１０９】
そして、所定の一致度を有する予算管理レコードが存在しない場合（ステップＳ２０７否定）には、マッチング処理部１５ａは、予算管理レコードの登録し忘れを注意喚起する旨をエラー通知制御部１５ｂに通知させる（ステップＳ２０８）。
【０１１０】
一方、所定の一致度を有する予算管理レコードが存在する場合（ステップＳ２０７肯定）には、マッチング処理部１５ａは、エラー管理レコードを生成する（ステップＳ２０５）。そして、マッチング処理部１５ｃは、ＡＤＡＭＳデータに含まれる全てのＡＤＡＭＳレコードを対象に上記のマッチングが終了するまで（ステップＳ２０６否定）、上記のステップＳ２０１〜Ｓ２０８の処理を繰り返し行う。
【０１１１】
その後、全てのＡＤＡＭＳレコードを対象に上記のマッチングが終了すると（ステップＳ２０６肯定）、マッチング処理部１５ａは、予算管理レコードの削除し忘れを注意喚起する旨をエラー通知制御部１５ｂに通知させ（ステップＳ２０９）、処理を終了する。
【０１１２】
（３）修正許可判定処理
図１７は、実施例２に係る修正許可判定処理の手順を示すフローチャートである。この修正許可判定処理は、修正要求者により指定されたレコードが含む入力番号に対応する予算管理レコードへアクセス要求を受け付けた場合に起動する。
【０１１３】
図１７に示すように、修正許可判定部１５ｃは、アクセス要求を受け付けた予算管理レコードの同意要否、入力者（１）及び入力者（２）をエラー管理テーブル１４ｄから取得する（ステップＳ３０１）。
【０１１４】
そして、同意要否が「要」である場合（ステップＳ３０２肯定）には、修正許可判定部１５ｃは、修正要求者、入力者（１）及び入力者（２）が同一人であるか否かを判定する（ステップＳ３０３）。なお、同意要否が「不要」である場合（ステップＳ３０２否定）には、ステップＳ３０９へ移行する。
【０１１５】
この結果、修正要求者、入力者（１）及び入力者（２）と同一人である場合（ステップＳ３０３肯定）には、修正処理部１５ｄは、端末３０から予算管理レコードの修正及び修正内容に対する同意入力を受け付ける（ステップＳ３０４）。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正、修正同意及び最終の進捗を「完了」に更新し（ステップＳ３０５）、処理を終了する。
【０１１６】
一方、修正要求者、入力者（１）及び入力者（２）が同一人ではない場合（ステップＳ３０３否定）には、修正許可判定部１５ｃは、修正要求者が入力者（２）と同一人であるか否かをさらに判定する（ステップＳ３０６）。このとき、修正要求者が入力者（２）と同一人である場合（ステップＳ３０６肯定）には、修正処理部１５ｄは、端末３０から修正内容に対する同意入力を受け付ける（ステップＳ３０７）。そして、修正処理部１５ｄは、エラー管理テーブル１４ｄにおける修正同意及び最終の進捗を「完了」に更新し（ステップＳ３０８）、処理を終了する。
【０１１７】
また、修正要求者が入力者（２）と同一人でない場合（ステップＳ３０６否定）には、修正許可判定部１５ｃは、修正要求者が入力者（１）と同一人であるか否かをさらに判定する（ステップＳ３０９）。
【０１１８】
この結果、修正要求者が入力者（１）と同一人である場合（ステップＳ３０９肯定）には、修正処理部１５ｄは、端末３０から予算管理レコードの修正を受け付ける（ステップＳ３１０）。そして、修正処理部１５ｄは、修正後の予算管理レコードを予算管理テーブル１４ａへ登録するとともに、エラー管理テーブル１４ｄにおけるデータ修正の進捗を「完了」に更新し（ステップＳ３１１）、処理を終了する。
【０１１９】
なお、修正要求者が入力者（１）と同一人ではない場合（ステップＳ３０９否定）には、修正要求者が修正担当者、同意担当者、これら両方の兼任のいずれでもないので、予算管理レコードの修正は許可せず、そのまま処理を終了する。
【０１２０】
［実施例２の効果］
上述してきたように、本実施例に係る予算管理サーバ１０は、レコードデータの中でも特に重要ではない項目に関する修正については入力者を含むグループ員を修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、入力者によってレコードデータが修正されるのを待たずともグループ員の誰かにレコードデータを修正させることができる。
【０１２１】
また、本実施例に係る予算管理サーバ１０は、レコードデータの中でも重要な項目に関する修正については入力者だけを修正許可者として、修正要求者にレコードデータの修正を許可するか否かを判定する。このため、レコードデータが入力された経緯を把握していない者に修正が実行されることによりレコードデータの重要な項目に間違いが生じることもない。
【０１２２】
このように、本実施例に係るデータ修正管理システム１００では、レコードデータの重要な項目に間違いを生じさせることなく、レコードデータの修正が滞る期間を低減させることができる。したがって、本実施例に係るデータ修正管理システム１００によれば、複数のシステムでレコードデータの二重管理を行う場合に、レコードデータの修正を効率よく行うことが可能である。
【０１２３】
また、本実施例に係る予算管理サーバ１０は、レコードデータの入力者がシステム間で異なり、かつ修正対象とされる項目に対応付けて記憶された修正許可者が入力者である場合に、予算管理レコードの入力者に修正を許可する判定を実行する。さらに、本実施例に係る予算管理サーバ１０は、レコードデータの修正内容に同意する旨の入力を受け付け、同意担当者による同意入力が受け付けられることを条件に修正担当者による予算管理レコードの修正が完了したとみなす。
【０１２４】
このため、本実施例に係るデータ修正管理システム１００によれば、予算管理レコードに対する修正内容を修正担当者とともに同意担当者にも二重にチェックさせることができ、レコードデータの修正に間違いが生じることを効果的に防止できる。
【０１２５】
さらに、本実施例に係る予算管理サーバ１０は、各システムのレコードデータをマッチングすることによりシステム間で共通する項目のデータが所定の修正条件を満たすレコードデータをマッチング結果として抽出する。その上で、本実施例に係る予算管理サーバ１０は、マッチング結果として抽出されたレコードデータの入力者が使用する端末装置に対して、当該レコードデータの修正を要する旨を通知する。
【０１２６】
それゆえ、本実施例に係るデータ修正管理システム１００によれば、システム間でレコードデータが不整合となる状態が発生した場合にその入力者本人に修正を促すことができ、レコードデータが不整合となる期間を低減することが可能である。
【０１２７】
また、本実施例に係る予算管理サーバ１０は、予算管理レコードの入力者と、予算管理レコードの修正に関する修正内容と、予算管理レコードの修正に関する進捗状況とを対応付けて記憶する。そして、本実施例に係る予算管理サーバ１０は、マッチング結果が抽出された場合に、予算管理レコードの入力者及び予算管理レコードの修正内容を登録するとともに、進捗状況としてマッチングが完了した段階にある旨を登録する。続いて、本実施例に係る予算管理サーバ１０は、通知が行われた場合に、進捗状況として修正通知が完了した段階にある旨を登録する。その後、本実施例に係る予算管理サーバ１０は、修正担当者による予算管理レコードの修正内容が受け付けられた場合に、進捗状況として修正内容の受付が完了した段階にある旨を登録する。さらに、本実施例に係る予算管理サーバ１０は、同意担当者による同意入力が受け付けられた場合に、進捗状況として同意入力の受付が完了した段階にある旨を登録する。
【０１２８】
このように、本実施例に係るデータ修正管理システム１００によれば、予算管理レコードの修正に関する進捗状況を段階的に収集することができ、例えば進捗が滞っている修正担当者に修正を督促することも可能である。
【実施例３】
【０１２９】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１３０】
また、上記の実施例２では、予算管理サーバ１０が制御部１５内の各機能部及び記憶部１４内のテーブルを有する場合を説明したが、担当者が使用する端末３０それぞれに制御部１５内の各機能部及び記憶部１４内のテーブルを持たせることもできる。この場合にも上記の実施例２と同様の効果を得ることができる。
【０１３１】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の間で歳出データが二重管理される場合を説明したが、開示のシステムはこれに限定されるものではない。例えば、設計段階のレコードデータを管理するシステムと、施工段階のレコードデータを管理するシステムとが併存する場合が挙げられる。このように、システム間で管理するレコードデータの守備範囲が異なりつつもその一部が重複する場合やシステム間で管理するレコードデータの対象は共通するが管理に時間的なズレが生じる場合に開示のシステムを同様に適用することができる。
【０１３２】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の２つのシステムでレコードデータが二重管理される場合を説明したが、３つ以上のシステムで任意のレコードデータが多重管理される場合にも開示のシステムを同様に適用できる。
【０１３３】
また、上記の実施例２では、ＡＤＡＭＳ２００及び予算管理システム３００の間で二重管理させる共通の項目のデータを完全一致させる場合を説明したが、一方の項目データが他方の項目データの部分集合となる場合を同一とみなすこととしてもよい。
【０１３４】
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、マッチング処理部１５ａ、エラー通知制御部１５ｂ、修正許可判定部１５ｃ、修正処理部１５ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の予算管理サーバの機能を実現するようにしてもよい。また、記憶部に記憶される予算管理テーブル１４ａ、担当者テーブル１４ｂ、項目テーブル１４ｃ、エラー管理テーブル１４ｄの全部または一部を別の装置がそれぞれ有するように構成する。その上で、ネットワーク接続されて協働することで、上記の予算管理サーバの機能を実現するようにしてもかまわない。
【０１３５】
［データ修正管理プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１８を用いて、上記の実施例と同様の機能を有するデータ修正管理プログラムを実行するコンピュータの一例について説明する。なお、図１８は、実施例３に係るデータ修正管理プログラムを実行するコンピュータの一例について説明するための図である。
【０１３６】
図１８に示すように、実施例３におけるコンピュータ５００は、操作部５１０ａと、マイク５１０ｂと、スピーカ５１０ｃと、ディスプレイ５２０と、通信部５３０とを有する。さらに、このコンピュータ５００は、ＣＰＵ５５０と、ＲＯＭ５６０と、ＨＤＤ（Hard Disk Drive）５７０と、ＲＡＭ（Random Access Memory）５８０と有する。これら５１０〜５８０の各部はバス５４０を介して接続される。
【０１３７】
ＲＯＭ５６０には、上記の実施例３で示したマッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ５６０には、図１８に示すように、マッチング処理プログラム５６０ａと、エラー通知制御プログラム５６０ｂと、修正許可判定プログラム５６０ｃと、修正処理プログラム５６０ｄとが記憶される。なお、これらのプログラム５６０ａ〜５６０ｄについては、図２に示した予算管理サーバの各構成要素と同様、適宜統合又は分離しても良い。
【０１３８】
そして、ＣＰＵ５５０が、これらのプログラム５６０ａ〜５６０ｄをＲＯＭ５６０から読み出して実行する。これによって、ＣＰＵ５５０は、図１８に示すように、各プログラム５６０ａ〜５６０ｄについては、マッチング処理プロセス５５０ａ及びエラー通知制御プロセス５５０ｂとして機能するようになる。さらに、ＣＰＵ５５０は、修正許可判定プロセス５５０ｃ及び修正処理プロセス５５０ｄとして機能するようになる。なお、各プロセス５５０ａ〜５５０ｄは、図３に示した、マッチング処理部１５ａと、エラー通知制御部１５ｂと、修正許可判定部１５ｃと、修正処理部１５ｄとにそれぞれ対応する。
【０１３９】
そして、ＨＤＤ５７０には、予算管理テーブル５７０ａと、担当者テーブル５７０ｂと、項目テーブル５７０ｃと、エラー管理テーブル５７０ｄとが設けられる。なお、これら予算管理テーブル５７０ａ、担当者テーブル５７０ｂ、項目テーブル５７０ｃ及びエラー管理テーブル５７０ｄは、図３に示した予算管理テーブル１５ａ、担当者テーブル１５ｂ、項目テーブル１５ｃ及びエラー管理テーブル１５ｄに対応する。
【０１４０】
そして、ＣＰＵ５５０は、予算管理テーブル５７０ａ、担当者テーブル５７０ｂ、項目テーブル５７０ｃ及びエラー管理テーブル５７０ｄを読み出してＲＡＭ５８０に格納する。さらに、ＣＰＵ５５０は、ＲＡＭ５８０に格納された予算管理データ５８０ａと、担当者データ５８０ｂと、項目データ５８０ｃと、エラー管理データ５８０ｄとを用いて、データ修正管理プログラムを実行する。
【０１４１】
なお、上記したデータ修正管理プログラムについては、必ずしも最初からＨＤＤ５７０やＲＯＭ５６０に記憶させておく必要はない。例えば、コンピュータ５００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ５００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ５００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１４２】
１ データ修正管理装置
２ 修正許可者記憶部
３ 修正許可判定部
１０ 予算管理サーバ
１１ 記録媒体読取部
１２ 通信制御Ｉ／Ｆ部
１３ メール配信部
１４ 記憶部
１４ａ 予算管理テーブル
１４ｂ 担当者テーブル
１４ｃ 項目テーブル
１４ｄ エラー管理テーブル
１５ 制御部
１５ａ マッチング処理部
１５ｂ エラー通知制御部
１５ｃ 修正許可判定部
１５ｄ 修正処理部
２０ ＡＤＡＭＳサーバ
２５ ＡＤＡＭＳ端末
３０Ａ，３０Ｂ 端末
４０ 記録媒体
１００ データ修正管理システム
２００ ＡＤＡＭＳ
３００ 予算管理システム
【特許請求の範囲】
【請求項１】
複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用されるデータ修正管理プログラムであって、
前記データ修正管理装置を、
レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する修正許可者記憶部として機能させ、
前記データ修正管理装置に、
前記レコードデータの修正要求を受け付けた場合に、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定手順
を実行させることを特徴とするデータ修正管理プログラム。
【請求項２】
前記修正許可判定手順は、
前記修正要求を受け付けたレコードデータの入力者がシステム間で異なり、かつ前記修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者である場合に、システム間で異なる入力者のうち所定の入力者に前記レコードデータの修正を許可する判定を実行し、
前記データ修正管理装置に、
前記レコードデータの修正内容に同意する旨の入力を受け付ける同意入力受付手順と、
前記所定の入力者以外の他の入力者による同意入力が前記同意入力受付手順によって受け付けられることを条件に前記所定の入力者によるレコードデータの修正が完了したとみなす修正処理手順と
をさらに実行させることを特徴とする請求項１に記載のデータ修正管理プログラム。
【請求項３】
複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用されるデータ修正管理方法であって、
前記データ修正管理装置を、
レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する修正許可者記憶部として機能させ、
前記データ修正管理装置が、
前記レコードデータの修正要求を受け付けた場合に、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定ステップ
を実行することを特徴とするデータ修正管理方法。
【請求項１】
複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用されるデータ修正管理プログラムであって、
前記データ修正管理装置を、
レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する修正許可者記憶部として機能させ、
前記データ修正管理装置に、
前記レコードデータの修正要求を受け付けた場合に、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定手順
を実行させることを特徴とするデータ修正管理プログラム。
【請求項２】
前記修正許可判定手順は、
前記修正要求を受け付けたレコードデータの入力者がシステム間で異なり、かつ前記修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者である場合に、システム間で異なる入力者のうち所定の入力者に前記レコードデータの修正を許可する判定を実行し、
前記データ修正管理装置に、
前記レコードデータの修正内容に同意する旨の入力を受け付ける同意入力受付手順と、
前記所定の入力者以外の他の入力者による同意入力が前記同意入力受付手順によって受け付けられることを条件に前記所定の入力者によるレコードデータの修正が完了したとみなす修正処理手順と
をさらに実行させることを特徴とする請求項１に記載のデータ修正管理プログラム。
【請求項３】
複数のシステムによって共通の項目を含んで二重に管理されるレコードデータ間の整合性を保つために実行されるレコードデータの修正要求を受け付けるデータ修正管理装置に適用されるデータ修正管理方法であって、
前記データ修正管理装置を、
レコードデータの項目ごとに、当該レコードデータの修正を許可されている修正許可者が前記レコードデータを入力した入力者であるか、または前記入力者を含むグループ員のいずれであるかを対応付けて記憶する修正許可者記憶部として機能させ、
前記データ修正管理装置が、
前記レコードデータの修正要求を受け付けた場合に、修正対象とされる項目に対応付けて前記修正許可者記憶部に記憶された修正許可者が前記入力者または前記グループ員であるかに基づき、前記修正要求を行う修正要求者に当該レコードデータの修正を許可するか否か判定する修正許可判定ステップ
を実行することを特徴とするデータ修正管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−１９２２１８（Ｐ２０１１−１９２２１８Ａ）
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願番号】特願２０１０−５９９８３（Ｐ２０１０−５９９８３）
【出願日】平成２２年３月１６日（２０１０．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願日】平成２２年３月１６日（２０１０．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]