JP2006018721A - 帳票定義管理システム、帳票定義開発システム、及び、帳票定義管理方法 - Google Patents

Abstract

【課題】 帳票の更新・登録作業工数の削減が可能な帳票定義管理システム、及び、帳票定義管理方法を、更には、帳票定義開発システム提供する。
【解決手段】 帳票定義管理システムは、帳票定義の更新を行う帳票定義開発ツール１０２と、開発された帳票定義を管理する帳票定義マスタ管理モジュール１０５と、それを保存する帳票定義マスタデータベース１０９からなる開発環境と、そして、帳票定義を要求し、表示された帳票の項目にデータを入力して送信するクライアント１１６と共に、開発環境に接続された実行環境用帳票定義管理データベース１１８を備え、クライアントの要求に応じて帳票定義を提供すると共に、クライアントから送信されたデータの処理を行うサーバとから構成される実行環境とを備えており、開発環境において、帳票定義マスタ管理モジュール１０５は、帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理１０７を備えている。
【選択図】 図１

Description

本発明は、電子帳票を管理するための帳票定義管理システム及び帳票定義管理方法に関し、特に、開発環境において作成又は更新された帳票定義を実行環境に配置するための帳票定義管理システム及び帳票定義管理方法に関し、更には、帳票定義を作成又は更新するための帳票定義開発システムに関する。

近年におけるコンピュータの広範な普及に伴って、従来の紙に印刷した帳票類に代って、電子帳票を利用したシステムが広く知られ、かつ、実用化されてきている。例えば、近年では、電子政府の普及に伴って、県や市町村等の地方行政機関が公開するホームページ上に申請帳票を表示し、住民がネットワーク上に接続された電子端末から申請帳票を取り出し（ダウンロード）、この帳票に直接入力し、所望の申請を行うことを可能とする、所謂、電子申請システムが普及しつつある。

また、上記の電子政府に限らず、その他、企業などの組織内においても、この電子帳票を利用して、例えば、旅費申請、通勤手当申請など、申請業務や、又は、稟議書の承認など、ワークフロー業務が構築されつつある。

以上のような電子帳票システムの中には、数百〜数千にも及び種類の帳票を利用する大規模なものもあり、また、このような大規模なシステムでは、通常、新たに帳票が作成され、また、利用する帳票の一部についても、定期又は不定期的に更新される。一方、かかる電子帳票システムでは、そこで利用される電子帳票は、その定義だけではなく、さらに、各帳票の呼び出しや、当該帳票に入力されたデータの受信処理などを行うためのプログラムから構成されている。即ち、これら帳票定義と上記の処理プログラムは、互いに連携しており、そのため、帳票定義の変更内容によっては、上記のプログラムの変更も併せて必要な場合が生じることがある。

また、上述したような大規模なシステムでは、そこで利用される帳票の開発には複数の開発者が必要となり、そのため、帳票定義を頻繁に更新する。そこで、複数の開発者が参照・更新する、例えば、リポジトリのようなシステムが必要になる。

また、このように、開発者が不定期に帳票定義を更新・登録すると、実際、利用者が帳票を参照（ダウンロード）して利用する実行環境においては、実行環境におけるシステムの動作や性能が安定しなくなる。そのため、通常、実行環境と開発環境を分離し、夜間バッチジョブなどにより、開発環境上の帳票定義を実行環境に移行することが行われている。

また、従来、例えば、以下の特許文献１によれば、本発明が関わる帳票とは異なるが、電子化された文書の文章管理方法および装置が既に知られている。この特許文献１によれば、複数の開発者の成果物である電子文書を管理する方法として、文書管理方法が知られており、帳票システムにおいても、リポジトリとして使用可能である。また、この従来技術により知られる文章管理方法および装置によれば、通常の文書管理方法に加え、新規文書／登録済み文書に関わらずに、同様の操作によって、文書を登録でき、また、更新対象の文書の取得時にロックをかけるといった煩雑な処理が不要になるものである。

加えて、以下の特許文献２によれば、ファイル配布方法が開示されており、このファイル配布方法では、複数が多重層で接続されたコンピュータシステムにおいて、プログラムおよびファイルの配布をスケジューリング可能とし、１回の指示で、分割配布を可能とし、配布作業と配布管理の簡易化、誤りの防止を図っている。なお、かかるファイル配布方法は、本発明が関わる帳票システムにおいても、開発環境から実行環境への帳票定義の移行の際に、利用可能な技術である。
特開２００２−１８２９５６号公報 特開平１１−３５３２９４号公報

しかしながら、上述したように、数百〜数千の帳票定義を取り扱う帳票システムにおいては、当該定期／不定期的に更新される帳票の更新・登録作業における工数の削減が重要な課題となっているが、しかしながら、上記の従来技術では、かかる帳票の更新・登録作業工数の削減については述べられていない。

ところで、一般に、帳票システムは、帳票定義と、それに関連するプログラムから構成されており、その関連するプログラムとは、例えば、帳票定義の一覧表示プログラムや、申請データの受信プログラムなどである。また、帳票定義の更新は、これらの関連プログラムの更新を伴うものと、他方、関連プログラムの更新を伴わないものに分類することが出来る。そして、関連プログラムの更新を伴わない更新であれば、これを実行環境の帳票定義と入れ替えても、不整合を生じることはないが、しかしならが、他方、上記プログラムの更新を伴う更新であれば、更新した帳票定義を入れ替えると、プログラムのエラーなどを発生することとなる。ところで、これらの判別は困難ではあるが、実行時に不整合が生じないか否かの検証作業が必要となる。しかし、更新される帳票定義が数千〜数万にも及ぶ場合、これら検証作業の工程を削減することが大きな課題となる。

なお、上記従来技術１で述べた文書管理方法及び装置では、文書IDに基づき、既存文書の更新とするか、又は、新規登録とするかの判別はできるが、その文書を実行環境に移行した場合に、他のプログラムと不整合を生じるか否かといった高度な判別を行うことはできない。また、上記従来技術２で述べたファイル配布方法では、毎回異なる可能性のある配布対象を選抜することは出来ない。

そこで、本発明の目的は、上記の従来技術における問題点に鑑み、複数の設計者が、帳票定義を共有しながら、その更新を繰り返し、更新した帳票定義を実行環境に配置することの可能な帳票定義管理システム、及び、帳票定義管理方法を、更には、帳票定義開発システム提供するものであって、帳票の更新・登録作業工数の削減が可能な帳票定義管理システム、及び、帳票定義管理方法を、更には、帳票定義開発システム提供するものである。

そこで、本発明によれば、上述した本発明の目的を達成するため、まず、帳票定義の作成又は更新を行う帳票定義開発ツールと、当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースから構成される開発環境と、前記帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて、前記開発環境において、前記帳票定義マスタ管理モジュールは、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理部を有する帳票定義管理システムが提供される。

また、本発明によれば、前記に記載した帳票定義管理システムにおいて、前記帳票定義マスタ管理モジュールは、前記実行環境において配置しても不整合生じないと判定された作成又は更新された帳票定義を、前記開発環境から前記実行環境部に移行するバージョンアップ帳票定義配置処理部を有することが好ましく、又は、前記帳票定義マスタ管理モジュールの前記バージョンアップ帳票定義配置処理部は、前記帳票定義の使用可能な期間についても判定処理して、作成又は更新された帳票定義を前記開発環境から前記実行環境部に移行するものであることが好ましい。

加えて、本発明によれば、前記に記載した帳票定義管理システムにおいて、前記帳票定義開発ツールは、当該ツールによって更新された帳票定義における変更を、当該更新作業の前後における内容を表示して確認する手段を備えていることが好ましく、又は、前記実行環境を構成するサーバは、上記クライアントからの要求に応じて前記帳票定義の呼び出し処理と共に、前記クライアントから送信されるデータの受信処理を行う提供サービスプログラムと、前記提供サービスプログラム部からの要求に応じて、前記帳票定義の提供と共に、前記提供サービスプログラム部が受信したデータの検証を行う帳票提供サービスとを備えており、かつ、前記開発環境を構成する前記帳票定義マスタ管理モジュールにおける前記バージョンアップ判定処理部は、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても、前記実行環境を構成するサーバにおいて前記帳票定義の呼び出し処理を行う提供サービスプログラムと不整合生じないか否か判別することが好ましい。

さらに、本発明によれば、前記に記載した帳票定義管理システムにおいて、前記実行環境を構成するサーバの前記帳票提供サービスは、前記クライアントから要求された前記帳票定義を、前記帳票定義マスタデータベースから取得する帳票定義取得処理部を備えており、更には、前記実行環境を構成するサーバの前記帳票提供サービスは、更に、その初期化において、前記帳票定義マスタデータベース内に保存された帳票定義の識別子情報のみを取得するものであることが好ましい。

また、本発明によれば、やはり上記に目的を達成するため、帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて前記帳票定義の作成又は更新を行うための帳票定義開発システムであって、帳票定義の作成又は更新を行う帳票定義開発ツールと、当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースとを備えており、かつ、前記帳票定義マスタ管理モジュールは、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理部を有する帳票定義開発システムが提供される。

さらに、本発明によれば、やはり上記に目的を達成するため、帳票定義の作成又は更新を行う帳票定義開発ツールと、当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースから構成される開発環境と、そして、前記帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて前記帳票定義を管理する帳票定義管理方法において、前記開発環境における前記帳票定義開発ツールによって作成又は更新された帳票定義に対し、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理を行い、その判定結果により、前記作成又は更新された帳票定義を前記実行環境において配置する帳票定義管理方法が提供される。

なお、本発明では、前記に記載した帳票定義管理方法において、前記バージョンアップ判定処理では、前記実行環境帳票定義管理データベースに保存された実行環境帳票定義管理テーブルと、前記帳票定義マスタデータベースに保存された帳票定義マスタテーブルのレコードとを比較し、該実行環境帳票定義管理テーブルの各レコードが、該帳票定義マスタテーブルの中の、使用可能な最新バージョンの帳票定義か否か検証し、使用可能な最新のバージョンではない場合には、使用可能な最新バージョンに更新する処理を行うことが好ましい。

以上に述べたように、本発明になる帳票定義管理システム、及び、帳票定義管理方法を、更には、帳票定義開発システムによれば、定期／不定期に、大量の帳票定義が更新・登録される電子帳票システムにおける帳票定義の開発を行う開発者による帳票定義の更新・登録作業において、その検証工数を削減すると同時に、上記電子帳票システムにおけるメインテナンス工数を削減するという優れた効果が得られる。

以下、本発明を実施するための最良の形態について、添付の図面に基づいて、詳細に説明する。
添付の図２には、本発明の一の実施形態になる帳票定義管理方法を実現するための帳票定義管理システム全体について、そのハードウェア構成の一例を示す。即ち、本発明を実現するための帳票定義管理システムは、一台以上の帳票定義装置７０１と、帳票定義マスタ管理装置７０２及び帳票定義マスタデータベース（以下、単に、「ＤＢ」と記す）１０９と、一台以上の利用プログラム装置７０４と、一台以上の帳票提供装置７０５と、実行環境用帳票定義管理ＤＢ７０６と、一台以上の帳票提供装置７０５とから構成されている。

そして、図からも明らかなように、帳票定義装置７０１、帳票定義マスタ管理装置７０２、帳票定義マスタデータベース１０９は、ＬＡＮ（Local Area Network）を介して、利用プログラム装置７０４、帳票提供装置７０５、そして、実行環境用帳票定義管理ＤＢ７０６に接続されている。また、一方、利用プログラム装置７０４は、インターネットを介して、一台以上の帳票利用装置７０３に接続されている。なお、上記の各帳票定義装置７０１、帳票定義マスタ管理装置７０２、各帳票利用装置７０３、各利用プログラム装置７０４、各帳票提供装置７０５は、ここでは図示しないが、それぞれ、例えば、表示装置、入力装置、ＣＰＵ、必要なプログラムなどを動作させるためのメモリワークエアリア、必要なプログラムやデータ等を保持するための記憶装置などから構成されている。

次に、添付の図１には、上記にそのハードウェア構成を説明した本発明になる帳票定義管理システムにおける機能構成を示している。即ち、本発明になる帳票定義管理システムは、基本的には、以下にその詳細に説明するが、開発環境と実行環境とによって構成される。

この図１及び上記図２を参照しながら、本発明を実現するための帳票定義管理システムでは、実行環境は、それぞれ申請者１１７が利用する一台以上の帳票利用装置７０３により構成されるクライアント１１６と、そして、利用プログラム装置７０４、帳票提供装置７０５、そして、実行環境用帳票定義管理ＤＢ７０６により構成されるサーバとによって構成されている。

かかる実行環境では、帳票を利用する申請者１１７は、上記クライアント１１６を構成する帳票利用装置７０３を利用して、帳票定義１１４を参照する（ダウンロードする）。なお、この時、上記サーバ内において作動する提供サービス利用プログラム１１３、更には、上記利用プログラム装置７０４及び帳票提供装置７０５において作動する帳票提供サービス１１０により、上記実行環境用帳票定義管理ＤＢ１１８から、上記帳票定義１１４を参照する。その後、所定の記入項目にデータを入力し、入力されたデータは、ＸＭＬ（eXtensible Markup Language）文書ファイル（データ）１１５として、上記サーバを構成する利用プログラム装置７０４において作動する提供サービス利用プログラム１１３へ転送され、提供サービス利用プログラムにおいて所定の処理が実行される。

一方、開発環境は、それぞれ帳票設計者１０１が利用し、帳票定義ツールが稼動する一台以上の帳票定義装置７０１と共に、上記帳票定義マスタ管理装置７０２と帳票定義マスタデータベース１０９とにより構成されている。この開発環境について簡単に説明すると、上記した一台以上の帳票定義装置７０１のそれぞれにおいては、帳票定義ツール１０２が動作する。即ち、帳票設計者１０１は、帳票定義ツール１０２を利用して帳票定義１０３を参照し（ダウンロードし）、帳票（Application Form）の作成又は更新作業を行なう。また、帳票定義マスタ管理装置７０２及び帳票定義マスタＤＢ１０９では、帳票定義マスタ管理モジュール１０５が動作しており、このモジュールには後に説明するバージョンアップ判定処理１０６とバージョンアップ帳票定義配置処理１０７とを含んでいる。また、帳票定義マスタ管理装置７０２及び帳票定義マスタＤＢ１０９は、作成又は更新作業を行なった帳票定義１０４を登録する。また、図中の符号１０８は、ＳＩ管理者を示している。

なお、上記の説明では、帳票定義装置７０１、帳票定義マスタ管理装置７０２、帳票定義マスタＤＢ１０９、利用プログラム装置７０４、帳票提供装置７０５、実行環境用帳票定義管理ＤＢ７０６（１１８）は、通常、ＬＡＮを介して互いに接続されているとして説明した。しかしながら、本発明はこれに限定することなく、これらの装置は、例えば、インターネットで接続されていてもよい。一方、帳票利用装置７０３、利用プログラム装置７０４は、通常、インターネットを介して接続されるが、しかしながら、本発明では、ＬＡＮにより接続されていてもよい。なお、上記の構成では、一台以上の帳票定義装置７０１が、共通の帳票定義マスタ管理装置７０２を利用することにより、他の帳票設計者が開発した帳票定義を参照することも可能となっている。また、一台以上の帳票提供装置７０５が、共通の実行環境用帳票定義管理ＤＢ７０６を利用することによれば、複数の帳票提供装置７０５間において、例えば、ダウンロードされた帳票のバージョンに不一致が発生するなどの問題が発生することから防止することが出来る。

以上のように、本発明になる帳票定義管理システムは、基本的には、開発環境と実行環境とによって構成されており、帳票（Application Form）の作成又は更新作業を行なう開発環境は、具体的には、一台以上の帳票定義装置７０１により構成される帳票定義ツール１０２と、上記帳票定義マスタ管理装置７０２に搭載された帳票定義マスタ管理モジュール１０５、そして、帳票定義マスタＤＢ１０９とを備えている。この開発環境において、帳票設計者１０１は、上記の帳票定義ツール１０２を利用して、帳票（Application Form）の作成又は更新作業を行なう。そして、この開発環境で開発した帳票定義は、その変更履歴と共に、上記帳票定義マスタＤＢ１０９に登録される。なお、上記の図１では、一例として、帳票設計者１０１が、帳票定義マスタ管理モジュール１０５内に管理されている帳票定義１０３を参照し（即ち、ダウンロードし）、上記帳票定義ツール１０２上で当該読み出した帳票定義に対して必要な変更を加えた後、これを新たに帳票定義１０４として登録する例について示している。

そして、本発明になる帳票定義管理システムでは、上記のように、既存の帳票定義を利用して、新たに帳票定義１０４を作成し、これを更新登録する時には、上記帳票定義マスタ管理モジュール１０５内に設けられたバージョンアップ判定処理１０６が実行され、その結果、バージョンアップが認められた場合には、既存の帳票（定義）のバージョンアップとして、上記の帳票定義マスタＤＢ１０９に登録されることとなる。なお、このバージョンアップ判定処理１０６の詳細については、後に詳細に説明する。

また、本発明になる帳票定義管理システムでは、上記帳票定義マスタ管理モジュール１０５内に設けられたバージョンアップ帳票定義配置処理１０７は、定期的に実行環境に移行すべき帳票定義１０３を検索し、後に説明する実行環境用帳票定義管理ＤＢ１１８に配置するための処理を実行する。なお、この配置対象帳票検索処理１０７の詳細についても、後に詳細に説明する。

次に、上述した実行環境の詳細について、以下に説明する。上記図１にも明らかなように、この実行環境は、上記帳票利用装置７０３である一台以上のクライアント１１６と、一台以上の利用プログラム装置７０４からなるサーバとにより構成されており、かかる構成においては、１つ以上の帳票提供サービス１１０が存在する。これらの帳票提供サービス１１０は、上記クライアント１１６から要求される帳票定義１１４を、提供サービス利用プログラム１１３を介して、クライアント１１６に提供し、又は、クライアント１１６から送信されるＸＭＬ（eXtensible Markup Language）文書ファイル（データ）１１５の検証処理などを行う働きをする。なお、この帳票提供サービス１１０は、その初期化処理１１１において、実行環境用帳票定義管理ＤＢ１１８（７０６）から帳票定義１１４を取得する。なお、この帳票定義１１４の表示イメージが、例えば、添付の図３（ａ）に示されており、また、この帳票定義１１４のソースファイルであるＸＭＬ文書ファイル（データ）１１５が、添付の図３（ｂ）に示されている。

ここで、申請者１１７は、例えば、提供サービス利用プログラム１１３に含まれる帳票を特定するための識別子情報である「FormID」を指定することによって、帳票定義１１４をダウンロードするプログラムを選択すると、上記の帳票提供サービス１１０が呼び出され、上述した初期化処理１１１と、以下に説明する帳票定義取得処理１１２とを実行することにより、上記帳票定義１１４が選択されて、クライアント１１６に提供される。なお、この初期化処理１１１では、実行環境用帳票定義管理ＤＢ１１８からは、その全レコードの「FormID」の値のみを取得する。そして、その実行環境帳票定義管理テーブル内に、上記提供サービス利用プログラム１１３が指定した「FormID」が含まれていなければ、提供サービス利用プログラム１１３に対してエラーメッセージを返し、他方、当該「FormID」が含まれていれば、その「FormID」を帳票定義取得処理１１２に引き渡す。なお、上記の実行環境用帳票定義管理ＤＢ１１８内の実行環境用帳票定義管理テーブルの一例が、添付の図４（ｂ）に示されており、この帳票定義取得処理１１２では、上記で取得した「FormID」をキーとして、実行環境用帳票定義管理ＤＢ１１８、具体的には、上記図４（ｂ）に示した実行環境帳票定義管理テーブルから、「帳票定義」を取り出し、提供サービス利用プログラム１１３へ引き渡すこととなる。

また、申請者１１７が、上記クライアント１１６の表示装置上に提供される上記図３（ａ）に示した帳票の表示イメージの所定の入力欄にデータを入力し、帳票定義の送信ボタン（例えば、図の「ＯＫ」ボタン）をクリックすると、そのＸＭＬデータ１１５は、上記提供サービス利用プログラム１１３に送信される。なお、このＸＭＬデータ１１５は、上記図３（ｂ）のデータ項目２０２において、各タグ（＜＞）の間にデータが挿入されたものに、「FormID」を含むヘッダ情報が追加されたものである。なお、このＸＭＬデータは、個々の構成要素について、その先頭位置と末尾位置を示すマークであるタグを付加することにより記述するものであり、開始タグは「＜」と「＞」で要素名を囲み、終了タグは「＜／」と「＞」で要素名を囲む。そして、同じ要素名である開始タグと終了タグとで囲まれた部分を内容文字列という。

次に、上記においてその構成を説明した開発環境において、帳票定義を更新登録する処理について説明する。
まず、上記の図３（ａ）には、上述のように、本形態の説明に利用する帳票の画面表示イメージの一例を示している。即ち、図３（ａ）に示す通り、本帳票には、例えば、「ID」、「Name」、「Address」の３つの入力項目が設けられており、この帳票は、上記の実行環境において、申請者１１７によりこれらの３つの項目に、それぞれ、データを入力した上で、申請が実行されることとなる。

また、図３（ｂ）は、上記図３（ａ）に示した帳票のファイルフォーマット（ソースファイル）である。即ち、図に示す通り、本ファイルフォーマットは、モデル表示２０１、データ項目２０２、データ送信先プログラム２０３、制約条件２０４、及び、背景２０５から構成される。なお、モデル表示２０１には、各入力項目に対応する入力領域のサイズと位置情報が記述される。データ項目２０２には、申請されるデータ項目が記述される。具体的には、申請者１１７が入力したデータは、このデータ項目２０２内に記入される。更に、データ送信先プログラム２０３には、申請者１１７が帳票の「ＯＫ」ボタンをクリックした時に呼び出すプログラム名を記述する。これは、具体的には、上記提供サービス利用プログラム１１３の中から選択することによって記述する。そして、制約条件２０４には、データ型、入力不可など、入力されるデータに対する制限や、必須入力など、申請するための条件が記述される。さらに、背景２０５には、帳票の背景画像のデータがバイナリ-形式で記述される。なお、図３（ａ）における「Application Form」「ID」「Name」「Address」などの固定文字列は、本例では、帳票の背景画像に含まれている。

続いて、上記本発明になる帳票定義管理システムにおける開発環境を構成する帳票定義マスタＤＢ１０９について説明する。この帳票定義マスタＤＢ１０９には、本システムで利用される、または、利用された帳票定義、更には、これらに関連する情報が格納される。図４（ａ）には、この帳票定義マスタＤＢ１０９に格納される帳票定義マスタテーブルの一例を示す。

図からも明らかなように、この帳票定義マスタテーブルでは、各帳票定義ファイルの「FormID」、バージョン情報である「Version」、帳票定義の実体であるソースファイル（図３（ｂ）を参照）、その名称である「FormName」、作成した日付を示す「Creation Date」、作成者を示す「Author」、更には、「使用可能フラグ」、また、例えば、法令の改正などに伴って帳票が使用可能となる日時を示す「使用可能日時」、「制約条件判定基準」が管理される。

より具体的には、「FormID」は、上記の実行環境において、帳票定義を特定するためのＩＤ情報である。また、「Version」は、同一の「FormID」を持つ帳票定義に対して付与されるバージョン情報である。「FormName」は、帳票定義に対して、帳票設計者１０１が自由に指定できる名称であり、「Creation Date」は、開発された上記帳票定義が、実際に、帳票定義マスタ管理モジュール１０５に登録された年月日である。そして、「Author」には、例えば、帳票設計者１０１自身の名前を入力する。更に、「使用可能フラグ」は、上記の実行環境にて使用可能な状態であるか否かを示すフラグであり、「使用可能日時」は、開発された帳票が上記の実行環境において、実際に、使用可能になる日時を示しており、そして、「制約条件判定基準」は、バージョンアップ判定処理１０６において利用される判定基準である。なお、上記の各項目において、特に、その「FormID」と「Version」との組合せが、上記図４（ａ）に示した帳票定義マスタテーブルにおいて、そのレコードを特定するための主キーとなっている。

一方、上記実行環境におけるサーバを構成する実行環境用帳票定義管理ＤＢ１１８について、以下に、その詳細を説明する。この実行環境用帳票定義管理ＤＢ１１８は、上記の実行環境において、帳票提供サービス１１０が利用する帳票定義を管理するものであり、図４（ｂ）には、この実行環境用帳票定義管理ＤＢ１１８内に格納される実行環境帳票定義管理テーブルの一例を示す。

即ち、この実行環境帳票定義管理テーブルでは、「FormID」、「Version」、「帳票定義」、「更新フラグ」、「Counter」の各項目が管理される。なお、これら「FormID」、「Version」、「帳票定義」の意味は、上記の帳票定義マスタテーブルと同様である。なお、ここで、「更新フラグ」は、同一の「FormID」の帳票定義に関し、上記開発環境を構成する帳票定義マスタＤＢ１０９の帳票管理マスタテーブル内に、実行環境用帳票定義管理ＤＢ１１８の実行環境帳票定義管理テーブルよりもVersionが新しい帳票定義が存在するか否かを示す。さらに、「Counter」は、各帳票定義を利用している提供サービス１１０の個数を示している。すなわち、この「Counter」の値により、レコードを削除しても提供サービスや提供サービス利用プログラムに問題を生じないか否かを判別することが可能となる。なお、この実行環境帳票管理テーブルにおける主キーは、「FormID」である。

続いて、本発明になる帳票定義管理システムにおいて、その開発環境を構成する帳票定義マスタ管理モジュール１０５（図１を参照）上で実行されるバージョンアップ判定処理１０６の詳細について、添付の図５を参照しながら説明する。このバージョンアップ判定処理１０６は、帳票設計者１０１が更新登録を試行している帳票定義に対して、バージョンアップを認めるか否かを判定する。なお、ここでバージョンアップが認められるケースとは、例えば、上記の実行環境で利用されている帳票定義を入れ替えたとしても、それに関連するプログラムを変更する必要がない場合を意味している。

この図５には、このバージョンアップ判定処理１０６のフローチャートが示されており、まず、帳票定義ダウンロード処理４０１では、帳票設計者１０１による帳票定義のダウンロードに伴って、帳票定義マスタ管理モジュールから、帳票定義をダウンロードし、上記の帳票定義ツール１０２上で編集可能な状態とする。続いて、帳票定義更新処理４０２では、帳票設計者１０１により、上記の帳票定義ツール１０２上で、帳票定義の一部が更新される。更に、帳票定義バージョンアップ依頼４０３では、帳票設計者１０１により、帳票定義マスタ管理モジュール１０６に対して、帳票定義のバージョンアップを依頼する。次いで、更新前帳票定義取得処理４０４では、帳票定義マスタ管理モジュール１０６が、バージョンアップか否かを判定するために、帳票設計者１０１がダウンロードした帳票定義を取得する。

上記の処理の後、更に、送信先プログラム名検証処理４０５、データ項目検証処理４０６、及び制約条件検証処理４０７では、帳票設計者１０１がダウンロードした更新前の帳票定義と、バージョンアップ依頼をしている更新後の帳票定義とを比較検証する。より詳細には、まず、送信先プログラム名検証処理４０５では、更新前と更新後の帳票定義の送信先プログラム２０３の記述内容が同一であるか否かを検証する。具体的には、上記図３（ｂ）に示す送信先プログラム２０３におけるタグ<xforms:submission action=…>の中で、「action」の値が同一であるか否か検証する。なお、この検証の結果、同一である場合には、処理４０６に進み、同一でない場合には、処理４１０に進む。

次に、データ項目検証処理４０６では、上記図３（ｂ）に示すデータ項目２０２の記述内容が同一か否か検証する。具体的には、データ項目２０２のタグ<xforms:model>と</xforms:model>とで囲まれた要素である内容文字列が同一か否かを検証する。なお、ここで検証するのは、要素のリストのみであり、各要素の値（内容文字列）は検証の対象外である。例えば、上記図３（ｂ）に示す例では、タグ<ID></ID>が、<ID_Number></ID_Number>に変更されていた場合には、データ項目２０２の記述内容が同一でないと判断するが、しかしながら、例えば、<ID>10</ID>のように、上記図３（ａ）の表示イメージの「ID」の項目に数字「１０」を挿入するなど、内容文字列が追加、あるいは、変更されている場合には、同一であると判断する。そして、この判断の結果、同一である場合には、処理４０７に進み、他方、同一でない場合には、上記の処理４１０に進む。

制約条件検証処理４０７では、上記図３（ｂ）に示す制約条件２０４の記述内容が同一か否か検証する。具体的には、制約条件２０４の各タグの内容が同一か否か検証する。なお、この場合、各タグ内に記載されている内容が逐一同一であるか否かを検証する。その結果、同一である場合には、バージョンアップ登録処理４０８に進み、他方、同一でない場合には、バージョンアップ確認処理４０９に進む。

なお、この制約条件検証処理４０７では、帳票設計者１０１が登録した上記図３（ｂ）に示す許容条件を考慮に入れることも可能である。この許容条件とは、例えば、上記の制約条件２０４の中で、予め登録されたタグの属性に関しては、たとえその値が変更されても、そのバージョンアップを認めることを可能とする、等である。

図６（ａ）には、上述した許容条件の一例を示す。この図の例では、例えば、<xforms:bind ref=祢D readonly>属性の値が変更されていても、バージョンアップを認めることを意味している。すなわち、<xforms:bind ref=祢D readonly=杷alse #62;が、<xforms:bind ref=祢D readonly=杯rue #62;に変更されても、バージョンアップを認める。ここで、この「readonly」属性は、書き込みの可／不可を規定しており、具体的には、<xforms:bind ref=祢D readonly=杯rue #62;とは、項目「ID」への入力は不可であることを示しており、これにより、例えば、上記図３（ａ）の帳票（Application Form）において、項目「ID」に該当するテキスト領域に対する入力を禁止することが可能となる。

または、<xforms:bind required>は、全ての参照先に関して、「required」属性の値が変更されても、バージョンアップを認めることを意味している。すなわち、<xforms:bind required=true>が、<xforms:bind required=false>に変更されていても、バージョンアップを認めることを意味する。ここで、「required」属性により、入力が必須であることを指定することができ、例えば、「required=true」であれば、参照先の項目に何らかの値が入力されていなければ、その送信時などに、エラーを出すことが出来る。例えば、上記の「Name」に対して、「required=true」を設定した場合、上記図３（ａ）に示す帳票において、その「Name」のテキスト領域に値を入れずに「OK」ボタンをクリックすると、エラーメッセージが表示されることとなる。

更に、上記のバージョンアップ登録処理４０８では、更新後の帳票定義を、更新前の帳票定義のバージョンアップとして、開発環境を構成する帳票定義マスタ管理モジュール１０５に登録する。具体的には、帳票定義マスタテーブルの更新前の帳票定義のレコードをコピーし、その「Version」を１つカウントアップし、一方、その「FormName」及び「Creation Date」については、更新後の帳票定義から取得した値に変更して、更新後の帳票定義としてレコードに追加する。

また、上記のバージョンアップ確認処理４０９では、更新前と更新後の帳票定義の差異を、開発環境を構成する帳票定義ツール１０２の表示装置上に表示することにより、帳票設計者１０１に呈示する。これにより、帳票設計者１０１に対して、更新前と更新後の帳票定義の差異を明示してその変更内容の確認を可能にし、もって、更新後の帳票定義をバージョンアップ登録するか否かの決定を促がす。なお、図６（ｂ）には、このバージョンアップ確認において、帳票設計者に対して表示される画面の一例を示している。

即ち、このバージョンアップ確認用の画面には、「更新前」と「更新後」の制約条件の内容が、「許容条件外」と「許容条件内」に分類され、更に、画面の上下に１対１に並べられて表示される。特に、この図示のような表示画面によれば、帳票設計者１０１は、「更新前」と「更新後」における変更内容、即ち、これらの間の差異を容易に確認することが可能となり、もって、バージョンアップ登録をすべきか否かを確実に判断することが可能となる。なお、この図６（ｂ）の右下に表示される「Yes」ボタンをクリックした場合には、処理は上記したバージョンアップ登録処理４０８に進み、他方、「No」を選択した場合には、処理４１０に進むこととなる。また、「許容条件外」における差異が存在する場合には、当該バージョンアップ確認用画面における「Yes」ボタンを不活性にすることにより、バージョンアップ登録が出来ないように設定することも可能である。

続いて、処理４１０では、ユーザである帳票設計者１０１に対して、更新後の帳票定義を新規登録するか否かを確認する。その結果、帳票設計者１０１が、新規登録を選択した場合には、新規登録処理４１１に進み、新規登録を選択しなかった場合には、上記の帳票定義更新処理４０２に戻る。ここで、新規登録処理４１１とは、上記帳票定義マスタＤＢ１０９の帳票定義マスタテーブルに、新規にレコードを追加することである。なお、この新規に追加されるレコードでは、その「FormID」は新規の番号が採番され、また、その「Version」は「１」に設定される。更に、その「FormName」及び「Creation Date」は、更新後の帳票定義から取得した値とし、また、帳票定義は更新後の帳票定義とする。

また、以上のようにして新規登録した帳票定義を、実行環境において申請者１１７が利用できるようにするためには、上記新規登録した帳票を呼び出し、申請されたデータを処理する提供サービス利用プログラム１１３を開発して登録する必要がある。なお、この提供サービス利用プログラム１１３は、例えば、Java（登録商標）などのプログラム開発言語を用いて開発することが可能である。

次に、添付の図７には、バージョンアップ前（更新前）と、バージョンアップ後（更新後）における帳票（表示イメージ）の一例を示す。なお、この図７に示すバージョンアップの変更点は、次の通りである。
・帳票のタイトルである「Application Form」のフォントサイズを大きくし、下線により修飾を加えている。
・「ID」「Name」「Address」のフォントを斜文字に変更し、下線により修飾を加え、表示位置を変更している。
・「ID」「Name」「Address」の右横にあったテキストエリアの表示位置を、各文字の下に変更している。
・「ID」右横にあったテキストエリアを小さくしている。
・「Address」右横にあったテキストエリアを大きくしている。

なお、以上の変更は、全て帳票の表示上の変更であり、そのため、その「データ送信先プログラム」２０３（図３（ｂ）を参照）、「データ項目」２０２には変更が加えられていない。また、その「制約条件」２０４については、例えば、上記図５（ｂ）に示したバージョンアップ確認用画面に示された様な変更が加えられているが、帳票設計者は、そのバージョンアップ確認用画面を参照した上で、バージョンアップすることを決定している（上記図６（ｂ）の画面で「Ｙｅｓ」をクリックした）ものとする。

次に、本発明になる帳票定義管理システムにおいて、その開発環境を構成する帳票定義マスタ管理モジュール１０５（図１を参照）上で実行されるバージョンアップ帳票定義配置処理１０７の詳細について、添付の図８を参照しながら説明する。なお、この帳票定義のバージョンアップは上記のＬＡＮを介して、例えば、夜間バッチ処理などにより、実行環境における実行環境用帳票定義管理ＤＢ１１８に格納された実行環境用帳票定義管理テーブル（上記図４（ｂ）を参照）のレコードを更新することにより行う。

この図８に示す帳票定義のバージョンアップでは、まず、更新するレコードを選択するために、開発環境における帳票定義マスタテーブル（帳票定義マスタＤＢ１０９内に格納）と、実行環境における実行環境用帳票定義管理テーブル（実行環境用帳票定義管理ＤＢ１１８内に格納）とにおいて、同一の「FormID」を持つレコードを比較し、実行環境下にある実行環境用帳票定義管理テーブルの各レコードが、最新の「Version」の帳票定義を利用しているか否か検証する。その結果、最新のバージョンを使用していないとされたレコードについては、これを最新のバージョンに更新する。以下に、図６のフローチャートを用いて、この帳票定義のバージョンアップの詳細を説明する。

まず、処理６０１では、実行環境帳票定義管理テーブル内に未処理レコードがあるか否か確認する。その結果、未処理レコードが存在する（「Yes」）場合には、処理６０２に進み、他方、存在しないと（「No」と）判断された場合には、処理６０４に進み、その処理を終了する。

一方、実行環境帳票定義管理テーブル内に未処理レコードが存在すると判断された場合、処理６０２では、上記実行環境帳票定義管理テーブルの中から、未処理のレコードを１つ選択する。さらに、処理６０３では、上記処理６０２で選択したレコードと、帳票管理マスタテーブルの全レコードを比較し、帳票管理マスタテーブルのレコードの中から、「FormID」が同一で、かつ、その「使用可能フラグ」の値が「１」であるレコードの中から、その「Version」の値が最大のレコード（即ち、最新のバージョン）を選択し、上記処理６０２で選択したレコードの「更新フラグ」の値を「１」に設定する。この処理を、上記実行環境帳票定義管理テーブル内に未処理レコードがなくなるまで繰り返す。

最後に、処理６０４では、実行環境帳票管理テーブルのレコードの中で、「Counter」の値が「０」より大きく、かつ、「更新フラグ」の値が「１」である帳票定義について更新を行う。例えば、その各項目の値を、上記帳票管理マスタテーブルの中で「FormID」が同一で、かつ、その「使用可能フラグ」の値が「１」であるレコードの中で「Version」の値が最大であるレコードの帳票定義で更新する。また、同時に、その「更新フラグ」は「０」に更新する。

なお、ここで、上述した図４（ｂ）に示した例では、「FormID=001」のレコードの「Version」が、「１」から「２」に更新され、一方、その「更新フラグ」が「１」から「０」に更新された例について示している。また、この例では、帳票定義が、「Version=1」の定義から「Version=2」の定義に更新されているものを示している。

また、ここで、上記「使用可能フラグ」の設定方法について説明すると、この「使用可能フラグ」は、ＳＩ管理者１０８により、直接、設定又は変更できるものである。また、予め、各々の帳票定義ごとに、その使用可能日時を設定することによれば、開発環境を構成する帳票定義マスタ管理装置７０２のタイマーに従って、随時、その時刻（設定した使用可能日時）に達した帳票定義の「使用可能フラグ」を「０」から「１」に変更し、その後の当該帳票の使用を可能にすることもできる。

加えて、上記図５に示したバージョンアップ判定処理は、以上の実施例に代えて、以下のように変更して実施することも可能である。
・第１に、上記図５に示した制約条件検証処理４０７において、制約条件に差異が認められた場合、上述したバージョンアップ確認処理４０９を介さずに、直接、判断処理４１０に進むようにする。
・第２に、上記の制約条件検証処理４０７において、制約条件の差異が予め登録された許容条件に含まれる場合には、直接、バージョンアップ登録処理４０８に進むようにする。

・第３に、上記図５に示すバージョンアップ判定処理において、送信先プログラム名検証処理４０５及びデータ項目検証処理４０６においても、上記制約条件検証処理４０７と同様に、確認された差異が、予め定義された許容条件に含まれる場合には、バージョンアップ確認処理４０９に進むようにする。
・第４に、上記図５に示すバージョンアップ判定処理の制約条件検証処理４０７で、許容条件の代わりに、バージョンアップを認めない条件を記述する。例えば、<xforms:bind ref=祢D readonly>とした場合、<xforms:bind ref=祢D readonly=杯rue #62;が、<xforms:bind ref=祢D readonly=杷alse #62;に変更されていれば、他の制約条件が全て等しくても、バージョンアップ確認処理４０９に進む。

以上に述べたように、本発明の実施の形態になる帳票定義管理システムでは、開発環境において作成／更新されて登録を試行している帳票定義が、実行環境において、既存の帳票定義と入れ替えても、関連するプログラムと不整合を生じないか否かを検証する手段を有している。そして、この検証手段により検証した結果、不整合を生じないと判断された帳票定義が、予め設定されたタイミングで実行環境に移行される。また、検証した結果、不整合を生じると判断された帳票定義については、登録者に修正箇所を提示されることとなる。そのため、特に、定期／不定期に、大量の帳票定義が更新・登録される電子帳票システムにおける帳票定義の開発を行う開発者による帳票定義の更新・登録作業において、その検証工数を削減すると同時に、上記電子帳票システムにおけるメインテナンス工数を削減することが可能となる。

本発明の一実施の形態になる帳票定義管理システムにおける機能構成を示す図である。 上記本発明の帳票定義管理システム全体について、そのハードウェアの全体構成の一例を示す図である。 上記本発明の帳票定義管理システムで利用する帳票定義の表示イメージ図とファイルフォーマットの一例を示す図である。 上記本発明の帳票定義管理システムで利用する帳票定義マスタテーブルと実行環境用帳票定義管理テーブルの一例を示す図である。 上記本発明の帳票定義管理システムで実行されるバージョンアップ判定処理の詳細を示すフローチャート図である。 上記バージョンアップ判定処理にける制約条件検証処理を説明するため、バージョンアップを認める許容条件の例と、バージョンアップ確認画面の表示例を示す図である。 上記本発明の帳票定義管理システムにおける、更新前と更新後の帳票の表示イメージの一例を示す図である。 上記本発明の帳票定義管理システムで実行されるバージョンアップ帳票定義配置処理の詳細を示すフローチャート図である。

符号の説明

１０１…帳票設計者
１０２…帳票定義ツール
１０３…帳票定義（更新前）
１０４…帳票定義（更新後）
１０５…帳票定義マスタ管理モジュール
１０６…バージョンアップ判定処理
１０７…バージョンアップ帳票定義配置処理
１０８…ＳＩ管理者
１０９…帳票定義マスタＤＢ
１１０…帳票提供サービス
１１１…初期化処理
１１２…帳票定義取得処理
１１３…提供サービス利用プログラム
１１４…帳票定義
１１５…ＸＭＬデータ
１１６…クライアント
１１７…申請者
１１８…実行環境用帳票定義管理ＤＢ

Claims (14)

1. 帳票定義の作成又は更新を行う帳票定義開発ツールと、当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースから構成される開発環境と、
   前記帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて、
   前記開発環境において、前記帳票定義マスタ管理モジュールは、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理部を有することを特徴とする帳票定義管理システム。
2. 前記請求項１に記載した帳票定義管理システムにおいて、前記帳票定義マスタ管理モジュールは、前記実行環境において配置しても不整合生じないと判定された作成又は更新された帳票定義を、前記開発環境から前記実行環境部に移行するバージョンアップ帳票定義配置処理部を有することを特徴とする帳票定義管理システム。
3. 前記請求項２に記載した帳票定義管理システムにおいて、前記帳票定義マスタ管理モジュールの前記バージョンアップ帳票定義配置処理部は、前記帳票定義の使用可能な期間についても判定処理して、作成又は更新された帳票定義を前記開発環境から前記実行環境部に移行することを特徴とする帳票定義管理システム。
4. 前記請求項１に記載した帳票定義管理システムにおいて、前記帳票定義開発ツールは、当該ツールによって更新された帳票定義における変更を、当該更新作業の前後における内容を表示して確認する手段を備えていることを特徴とする帳票定義管理システム。
5. 前記請求項１に記載した帳票定義管理システムにおいて、前記実行環境を構成するサーバは、上記クライアントからの要求に応じて前記帳票定義の呼び出し処理と共に、前記クライアントから送信されるデータの受信処理を行う提供サービスプログラムと、前記提供サービスプログラム部からの要求に応じて、前記帳票定義の提供と共に、前記提供サービスプログラム部が受信したデータの検証を行う帳票提供サービスとを備えており、かつ、前記開発環境を構成する前記帳票定義マスタ管理モジュールにおける前記バージョンアップ判定処理部は、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても、前記実行環境を構成するサーバにおいて前記帳票定義の呼び出し処理を行う提供サービスプログラムと不整合生じないか否か判別することを特徴とする帳票定義管理システム。
6. 前記請求項１に記載した帳票定義管理システムにおいて、前記実行環境を構成するサーバの前記帳票提供サービスは、前記クライアントから要求された前記帳票定義を、前記帳票定義マスタデータベースから取得する帳票定義取得処理部を備えていることを特徴とする帳票定義管理システム。
7. 前記請求項５に記載した帳票定義管理システムにおいて、前記実行環境を構成するサーバの前記帳票提供サービスは、更に、その初期化において、前記帳票定義マスタデータベース内に保存された帳票定義の識別子情報のみを取得することを特徴とする帳票定義管理システム。
8. 帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて前記帳票定義の作成又は更新を行うための帳票定義開発システムであって、
   帳票定義の作成又は更新を行う帳票定義開発ツールと、
   当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、
   当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースとを備えており、かつ、前記帳票定義マスタ管理モジュールは、前記帳票定義開発ツールによって作成又は更新された帳票定義が、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理部を有することを特徴とする帳票定義開発システム。
9. 前記請求項８に記載した帳票定義開発システムにおいて、前記帳票定義マスタ管理モジュールは、前記実行環境において配置しても不整合生じないと判定された作成又は更新された帳票定義を、前記開発環境から前記実行環境部に移行するバージョンアップ帳票定義配置処理部を有することを特徴とする帳票定義開発システム。
10. 前記請求項８に記載した帳票定義開発システムにおいて、前記帳票定義開発ツールは、当該ツールによって更新された帳票定義における変更を、当該更新作業の前後における内容を表示して確認する手段を備えていることを特徴とする帳票定義開発システム。
11. 帳票定義の作成又は更新を行う帳票定義開発ツールと、当該帳票定義開発ツールにより開発された帳票定義又は帳票定義の変更履歴を管理する帳票定義マスタ管理モジュールと、当該帳票定義とその更新履歴を保存する帳票定義マスタデータベースから構成される開発環境と、そして、前記帳票定義を要求し、表示された帳票の所定の項目にデータを入力して送信を行うクライアントと共に、その一部に、前記開発環境に接続された実行環境用帳票定義管理データベースを備え、前記クライアントからの要求に応じて、前記帳票定義を提供すると共に、前記クライアントから送信されたデータの受信処理を行うサーバとから構成される実行環境とを備えた帳票定義管理システムにおいて前記帳票定義を管理する帳票定義管理方法において、前記開発環境における前記帳票定義開発ツールによって作成又は更新された帳票定義に対し、前記実行環境において配置しても不整合生じないか否か判別するバージョンアップ判定処理を行い、その判定結果により、前記作成又は更新された帳票定義を前記実行環境において配置することを特徴とする帳票定義管理方法。
12. 前記請求項１１に記載した帳票定義管理方法において、前記バージョンアップ判定処理では、前記帳票定義の使用可能な期間についても判定処理することを特徴とする帳票定義管理方法。
13. 前記請求項１１に記載した帳票定義管理方法において、前記実行環境を構成するサーバの前記帳票提供サービスは、更に、その初期化において、前記帳票定義マスタデータベース内に保存された帳票定義の識別子情報のみを取得することを特徴とする帳票定義管理方法。
14. 前記請求項１１に記載した帳票定義管理方法において、前記バージョンアップ判定処理では、前記実行環境帳票定義管理データベースに保存された実行環境帳票定義管理テーブルと、前記帳票定義マスタデータベースに保存された帳票定義マスタテーブルのレコードとを比較し、該実行環境帳票定義管理テーブルの各レコードが、該帳票定義マスタテーブルの中の、使用可能な最新バージョンの帳票定義か否か検証し、使用可能な最新のバージョンではない場合には、使用可能な最新バージョンに更新する処理を行うことを特徴とする帳票定義管理方法。
    

Images