JP2005327136A - 伝票管理システム及び伝票管理用ソフトウェア - Google Patents

伝票管理システム及び伝票管理用ソフトウェア Download PDF

Info

Publication number
JP2005327136A
JP2005327136A JP2004145647A JP2004145647A JP2005327136A JP 2005327136 A JP2005327136 A JP 2005327136A JP 2004145647 A JP2004145647 A JP 2004145647A JP 2004145647 A JP2004145647 A JP 2004145647A JP 2005327136 A JP2005327136 A JP 2005327136A
Authority
JP
Japan
Prior art keywords
slip
data
field
item
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004145647A
Other languages
English (en)
Inventor
Terubumi Wakamoto
光史 若本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to JP2004145647A priority Critical patent/JP2005327136A/ja
Publication of JP2005327136A publication Critical patent/JP2005327136A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】 データベース関連の設計／開発の負担を大幅に削減でき、企業ごとの多様な要求にも対応可能な業務処理システムを開発可能な伝票管理システムを提供する。
【解決手段】 伝票入力用インターフェイス提供手段を備えたクライアント装置と、伝票データの新規計上・修正計上・伝票１枚検索・伝票１項目検索をそれぞれ実行する手段を備えたデータサーバ装置と、伝票の種類・伝票に含まれる項目・伝票間のデータの依存関係を自由に定義出来るデータベースと伝票データを格納する伝票データベースと集計を行う伝票の種類・集計表の種類・集計表に含める項目・集計する伝票の項目と集計表の対応関係・集計計算の設定を自由に定義できる集計表定義データベースと集計表データベースとを備えた伝票管理データベースとで、伝票管理システムを構成した。
【選択図】 図１

Description

本発明は、企業内での販売管理や在庫管理、人事情報の管理など、業務処理に必要な様々な情報を利用し管理するために用いる伝票を管理し整理するための伝票管理用ソフトウェア及び伝票管理システムに関する。
ここで、「伝票」というと、通常は受発注管理のための「受注伝票」や売上管理のための「売上伝票」などを想定するが、本明細書で用いる「伝票」の概念は企業内で情報を利用し管理するためにクライアント−サーバ間でやりとりするデータのかたまりの一単位を指し、通常の「伝票」の概念より広く、数量や金額を含まない場合もある。
従来、データベースへのアクセスを伴う企業の業務処理システムの開発は、ＵＭＬ（The Unified Modeling Language オブジェクト指向に基づくソフトウェア開発における、プログラム設計図の統一表記法。）等を利用し、データベースの構造を設計することからはじめていた。このためユーザー毎あるいは受託開発案件毎にデータベースの構造が異なり、ある案件でのデータベースアクセスに係るユーザー固有の部分は再利用できないので、開発案件毎にデータベース関連の設計／開発工程を経なくはならず、データベースへのアクセスを伴う業務処理システムの開発には相当の時間とコストが必要であった。
このような問題を解決するために、例えば既存の販売管理ソフトやグループウェアを利用することも考えられる。しかし、グループウェアで取り扱うのは主として、会議室のスケジュールや社員各人の行き先であり、企業における情報の共有化を通じて効率的な業務を実現し収益の向上に寄与することは出来ても、収益に直接かかわる情報を扱うものではない。一方、既存の販売管理ソフトウェアを利用するためには、個々の企業の要望に沿うためにカスタマイズが必要であったり、カスタマイズにも限界があるという問題がある。また、このようなソフトウェアは用途が限定されていて汎用的な利用を目的としたものでないため、企業内での柔軟な利用は期待できないという問題がある。ここまでに記載した背景技術に関しては、下記の非特許文献１〜３に記載されている。
なお、背景技術に関する特許文献に関しては、本願発明者は直接関連する文献を本願発明時において特に知らなかったので、特許庁のホームページ上で提供されている特許電子図書館の公開特許公報フロントページ検索メニューで、「データ」ＡＮＤ「管理」あるいは「伝票」ＡＮＤ「管理」というキーワードで検索を行った。その結果、４５０件以上の公報がヒットしたが、直接本願発明の先行技術文献となる公報は見当たらず、多少関連はあると考えられる文献をピックアップして以下に記載した。伝票の入出力や作成方法に関する問題を解決するための技術として、特開平１１−５３４５３号、特開平１１−１４３９６２号、特開２０００−１４８８８４号、特開２００２−７４２５１号、特開２００３−３３１２１１号が挙げられるが、これらの技術は、企業ごとの多様な要求にも対応可能な業務処理システムを開発できる汎用伝票管理用ソフトウェア及び伝票管理システムを開示するものではない。また、伝票等を管理するデータベースに関連する技術として、特開２００２−１０８６６５号、特開２００２−１６３１３４号、特開２００２−２１６２５０号が挙げられるが、伝票のあらゆる項目の設定について柔軟に対応できるわけではなく、また、伝票の計上するデータの内容そのものの管理を提供するものでもない。
特開平１１−５３４５３号 特開平１１−１４３９６２号 特開２０００−１４８８８４号 特開２００２−７４２５１号 特開２００３−３３１２１１号 特開２００２−１０８６６５号 特開２００２−１６３１３４号 特開２００２−２１６２５０号 エリック・Ｊ・ナイバーグ、ロバート・Ａ・マクシムチャック著、長瀬嘉秀、今野睦監訳「データベース設計のためのＵＭＬ」翔泳社発行２００３年 小笠原泰、小野寺清人、森彪著「情報システム投資の基本がわかる本」日本能率協会発行２００３年 土呂須健一著「基幹業務システムの設計理論」日本図書刊行会発行２００１年
本発明は上記した従来技術の問題点を解決するためになされたもので、その目的は、データベースへのアクセスを伴う業務処理システムにおいて、開発案件毎に行っていたデータベース関連の設計／開発工程の負担を大幅に削減でき、企業ごとの多様な要求にも対応可能な業務処理システムを開発できる汎用の伝票管理用ソフトウェア及び伝票管理システムを提供することにある。
本発明による伝票管理システムは、クライアント装置と、クライアント装置とネットワークで接続されたデータベースサーバ装置と、データベースサーバ装置と接続された伝票管理データベースと、で構成されている。
クライアント装置は、必要に応じてデータベースサーバ装置を介して伝票管理データベースに格納された伝票データの提供を受けながら伝票データの入力・修正・計上・検索のためのインターフェイスを提供する機能と、入力された伝票データを所定の変換方式に従って変換してデータベースサーバ装置に送信する機能と、を有する、伝票入力用インターフェイス提供手段を備えている。
データベースサーバ装置は、クライアント装置から受信した新規計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの新規計上手段と、クライアント装置から受信した修正計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの修正計上手段と、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データを一件毎に検索しクライアント装置に送信する伝票一枚検索手段と、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データの項目を一項目毎に検索してクライアント装置に送信する伝票一項目検索手段と、を備えている。
伝票管理データベースは、個々の伝票に含まれるデータ中、計上されるデータを修飾するデータであるヘッダーの項目の種類と数を定義するデータを格納する伝票定義データベースと、伝票の種類と伝票間のデータの依存関係を定義するデータを格納する伝票関係定義データベースと、ヘッダーの項目で使用されるデータを格納するヘッダー用データ定義データベースと、個々の伝票に含まれるデータ中、計上の対象となる品目及びその属性を含む本体項目のデータを定義する本体項目用データ定義データベースと、クライアント装置から計上された伝票のデータを所定の方式に従って格納する伝票データベースと、を備えている。
本発明による伝票管理システムは、上述の構成を有することにより、クライアント装置からデータベースサーバ装置を介して計上され伝票管理データベースで管理する伝票の種類と伝票に含まれる項目と伝票間のデータの依存関係の設定とを、自由に設定可能にしたことを特徴とする。
本発明による伝票管理システムにおいて、前記伝票管理データベースに含まれる各データベースは、望ましい形態として、以下に述べる各デーブルを備えるように構成することが出来る。
すなわち、前記伝票定義データベースは、伝票のヘッダー項目を入力するための機能を提供する入力コントロールの種類を識別するコントロールＩＤとそのデータの型や入力方式を定義する入力コントロール定義テーブルと、伝票の種類別にどの入力コントロールを使用してヘッダー項目を入力するかをコントロールＩＤと伝票ＩＤに関連づけて定義する伝票別入力コントロール定義テーブルと、を含む。前記伝票関係定義データベースは、伝票の種類を定義する伝票ＩＤテーブルと、伝票管理データベースに対する伝票データの計上の種類を定義する計上ＩＤテーブルと、伝票データの処理の内容を伝票の種類と計上の種類と参照伝票の種類により一意に示す処理ＩＤを計上ＩＤと伝票ＩＤと参照する伝票ＩＤに関連づけて定義する処理ＩＤテーブルと、各処理ＩＤの処理において伝票の各ヘッダー項目の値を入力するための入力コントロールの参照関係を参照伝票ＩＤと被参照伝票ＩＤとデータを得るための参照伝票の入力コントロールと被参照伝票の入力コントロールに関連づけて定義する伝票間参照関係テーブルとを含む。前記ヘッダー用データ定義データベースは、ヘッダー項目に顧客データを入力するために参照する顧客コード・名称・住所を含む顧客テーブルの内容を定義する顧客テーブルと、ヘッダー項目に仕入先データを入力するために参照する仕入先コード・名称・住所を含む仕入先テーブルの内容を定義する仕入先テーブルと、ヘッダー項目に配送業者データを入力するために参照する配送業者コード・名称・住所を含む配送業者テーブルの内容を定義する配送業者テーブルと、ヘッダー項目に自社の担当者データを入力するために参照する社員コード・氏名・部署名を含む社員テーブルの内容を定義する社員テーブルと、ヘッダー項目に入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容が未確定であるときその旨記録する未登録項目テーブルと、ヘッダー項目に入力するデータが論理値でありその値が「Ｙｅｓ」又は「Ｎｏ」しかないときに選択肢の内容を定義するＹｅｓＮｏテーブルと、ヘッダー項目に入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容を定義する下位区分テーブルとを含む。前記本体項目用データ定義データベースは、計上の対象となる品目を識別する品目コードを定義する品目コードテーブルと、品目についての属性を入力するための属性コード・入力するデータのタイプ・単位を含む品目属性の内容を定義する品目属性定義テーブルと、どの品目にどの属性が対応するかを、品目コードと属性コードに関連づけて定義する品目コード品目属性対応テーブルと、本体項目に用いられる単位コードとその内容を定義する単位テーブルと、品目の上位区分の品目区分コードとその内容を定義する品目上位区分テーブルと、品目属性として入力するデータが論理値でありその値が「Ｙｅｓ」又は「Ｎｏ」しかないときに選択肢の内容を定義するＹｅｓＮｏテーブルと、品目について入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容を定義する下位区分テーブルと、どの区分にどの品目が含まれるかを、品目区分コードと品目コードに関連づけて定義する区分品目対応テーブルとを含む。
前記クライアント装置と前記データベースサーバ装置との間の伝票データの送受信や処理については、望ましくは以下に述べるように構成できる。
すなわち、前記クライアント装置の伝票入力用インターフェイス提供手段は、入力されたデータを所定の変換方式に従って変換することによって、データベースサーバ装置に対して処理の内容を指示するデータを伝票番号と処理コードと伝票ＩＤと処理ＩＤと項目番号に関連づけて記録する問合せ用データセクションと、計上する伝票を特定するための基本的なデータを伝票ＩＤと伝票番号とに関連づけて記録する伝票基本データセクションと、ヘッダー項目のデータを伝票番号とコントロールＩＤに関連づけて項目毎に記録するヘッダー項目データセクションと、ヘッダー用データがデータベース化されていない未登録のヘッダー項目のデータを伝票番号に関連づけて直接項目毎に記録するヘッダー未登録項目データセクションと、本体項目のデータを伝票番号に関連づけて項目毎に記録する本体項目データセクションと、１枚の伝票に含まれる本体項目を同時に修飾するヘッダーのデータを伝票番号と項目番号に関連づけて記録する本体項目備考データセクションと、本体項目の項目毎にデータを得た参照伝票と参照項目のデータを伝票番号と参照伝票ＩＤと参照伝票番号に関連づけて記録する関連伝票データセクションと、本体項目の項目毎に品目の属性データを、伝票番号に関連づけて記録する属性データセクションと、を含む各データセクションに振り分けて記録した伝票データとしてデータベースサーバ装置に送信する。
また、前記クライアント装置から伝票データを受信した前記データベースサーバ装置は、伝票データの処理の内容を、問合せデータセクションに記録された処理ＩＤと処理コードの値から判断し、伝票のデータを計上する処理であれば、伝票データの新規計上手段または伝票データの修正計上手段により伝票基本データセクション・ヘッダー項目データセクション・ヘッダー未登録項目データセクション・本体項目データセクション・本体項目備考データセクション・関連伝票データセクション及び属性データセクションの各データセクションに記録されたデータを、伝票基本データセクションに記録されたデータを格納する伝票基本データテーブルと、ヘッダー項目データセクションに記録されたデータを格納するヘッダー項目データテーブルと、ヘッダー未登録データセクションに記録されたデータを格納するヘッダー未登録項目データテーブルと、本体項目データセクションに記録されたデータを格納する本体項目データテーブルと、本体項目備考データセクションに記録されたデータを格納する本体項目備考データテーブルと、関連伝票データセクションに記録されたデータを格納する関連伝票データテーブルと、属性データセクションに記録されたデータを格納する属性データブルと、で構成される伝票データベースの各テーブルに振り分けて格納し、伝票１枚または伝票１項目の検索を必要とする処理であれば、伝票一枚検索手段または伝票一項目検索手段により、伝票データベースにアクセスして要求されたデータをクライアント装置に送信する。
さらに、前記伝票管理データベースは、各集計表を識別する集計ＩＤとその名称を含む集計表の基本的なデータを定義する集計表名テーブルと、集計表に含める個々のフィールドを識別する集計フィールドＩＤとその内容を、集計表の基礎となる伝票ＩＤに関連づけて定義する集計要素テーブルと、集計計算を実行するときに各集計表の各フィールドに対してどのような計算を実行するかを識別する集計計算要素ＩＤとその内容を、処理ＩＤと集計ＩＤと集計フィールドＩＤに関連づけて定義する集計計算要素テーブルと、集計計算の対象となるデータの出所がデータベースである場合にそのデータベースを、集計計算要素ＩＤに関連づけて定義する検索対象定義テーブルと、各集計表に対する処理ＩＤの集計計算のデータ処理の順番・対象・計算の内容を、集計ＩＤと処理ＩＤに関連づけて定義する集計動作定義テーブルと、各集計表を表示させるときの各フィールドの表示の順番・表示の有無・レコードの並び換えを含む表示特性を、集計ＩＤと集計フィールドＩＤとに関連づけて定義する集計表示要素テーブルと、を含む集計表定義データベースを、さらに備えることによって、集計を行う伝票の種類、集計表の種類、各集計表に含める項目、集計する伝票の項目と集計表の項目の対応関係、及び集計計算を実行するときにどの集計表に対して何を加算し減算するかを自由に設定できるように構成できる。
一方、伝票管理データベースに備えられた集計表定義データベースの各テーブルに設定した値に基づいて、各集計ＩＤ毎の集計データを記録するためのデータを抽出して各集計表テーブルを備えた集計表データベースを作成することができ、この集計表データベースをさらに備えることによって、各集計表の計算や管理や表示が可能となる。
次に、前記集計表定義データベースは、この集計表定義データベースに対する処理要求を行うことができる以下の第1〜第４のレコード抽出処理手段を備えることができる。すなわち、前記集計動作定義テーブルから、「処理ＩＤ」フィールドの値が指定された値と合致するレコードを抽出して「集計ＩＤ」フィールドの値に従って昇順に並び換え、同一の「集計ＩＤ」フィールドの値を有するレコードがある場合はさらに規定されたデータ処理の順番に並び換えることによって一連のレコードを取得する第１のレコード抽出処理手段と、前記集計動作定義テーブルから、「処理ＩＤ」フィールドの値及び「集計ＩＤ」フィールドの値がそれぞれ指定された値と一致するレコードを抽出し、規定されたデータ処理の順番に並び換えることによって一連のレコードを取得する第２のレコード抽出処理手段と、前記集計計算要素テーブルと前記集計要素テーブルとをそれぞれの「集計フィールドＩＤ」フィールドの値を基準に内部結合し、当該内部結合の結果得られたテーブルの全てのレコードが含まれるように、当該内部結合の結果得られたテーブルと前記検索対象定義テーブルとをそれぞれの「集計計算要素ＩＤ」フィールドの値を基準として外部結合し、当該外部結合によって作成されたレコードによって構成されるテーブルから、前記集計要素テーブルに由来する「集計ＩＤ」フィールドの値が指定された値と一致し、さらに前記集計計算要素テーブルに由来する「処理ＩＤ」フィールドの値が指定された値と一致する一連のレコードを取得する第３のレコード抽出処理手段と、前記集計表示要素テーブルと前記集計計算要素テーブルとをそれぞれの「集計フィールドＩＤ」フィールドの値を基準に内部結合し、当該内部結合の結果得られるテーブルから、前記集計表示要素テーブルに由来する「集計ＩＤ」フィールドの値が指定された値に一致するレコードを抽出し、前記集計表示要素テーブルに規定された順番に従って並び換えることによって一連のレコードを取得する第４のレコード抽出処理手段と、をさらに備えることによって、第１のレコード抽出処理手段によって伝票データに含まれる処理ＩＤ毎の集計動作を抽出し、第２のレコード抽出処理手段によって伝票データに含まれる処理ＩＤの集計動作中指定した集計ＩＤで特定される集計表に対する動作のみを抽出し、第３のレコード抽出処理手段によって指定した処理ＩＤを有する伝票計上処理においてその伝票データを集計ＩＤで特定される集計表に集計計算するときどのように計算するかを示すレコードセットを取得し、第４のレコード抽出処理手段によって指定した集計ＩＤで特定される集計表を表示するときにその集計表に含まれる各フィールドがどのような表示特性をもっているかを示すレコードセットを取得することが可能となる。
ここで、上で使用された「内部結合」及び「外部結合」の用語について説明する。「内部結合」とは、一方のテーブルのあるフィールドの値と、もう一方のテーブルのあるフィールドの値が同じレコードを結びつける結合を行う場合に、一方のテーブルのフィールドの値と、もう一方のテーブルのフィールドの値が同じレコードだけを結合することをいう。ＳＱＬ−９２（アメリカ標準化機構ＡＮＳＩによって制定されたＳＱＬの規格）では、ＩＮＮＥＲ ＪＯＩＮキーワードとＯＮキーワードで記述される。この内部結合では、複数のテーブル間で対応するフィールドの値が等しいものだけが結合され、結果として返されるので、どちらかにしか存在しない値を持つレコードは結合されない。
一方、処理の目的によっては、あるテーブルだけは必ず残したい、という場合がある。「外部結合」はこのような場合に用いられる。ＳＱＬ−９２（アメリカ標準化機構ＡＮＳＩによって制定されたＳＱＬの規格）では、ＯＵＴＥＲ ＪＯＩＮキーワードとＯＮキーワードで記述される。外部結合は結合の方向により、先に記述した左側のテーブルを優先して左側のテーブルに関してはすべてのレコードを残す左外部結合と、後で指定した右側のテーブルを優先して右側の表に関してはすべてのレコードを残す右外部結合がある。
なお、第１〜第４のレコード抽出手段をすべてクライアント装置側ではなくデータベース側に設けているのは、クライアント装置側の処理の負担を軽減し（クライアント装置ではデータベースサーバ装置側から返されるデータの結果を表示するだけでよい）、また、システム全体のメンテナンスの効率化と負担の軽減を図るためである。
次に、前記集計表定義データベースに含まれるテーブルについて、以下のようなフィールドが設けられた場合に、後述する第１〜第６のＳＱＬ文生成手段によって生成されたＳＱＬ文が実行された結果のデータ操作手段を集計表データベースに設けることができ、集計表の計算や表示のための操作手段をデータベース側に備えることが可能となる。すなわち、前記集計要素テーブルは、少なくとも、すべての集計表についてそれぞれの集計表の各フィールドの識別コードを記録する「集計フィールドＩＤ」フィールドと、各集計表を識別する集計ＩＤを記録する「集計ＩＤ」フィールドと、集計フィールドＩＤで識別される集計表の各フィールドの名称を記録する「フィールド名称」フィールドと、各フィールドのデータ型を記録する「フィールドタイプ」フィールドと、集計表に集計計算をするときに集計表の集計対象のレコードを選ぶ際の抽出条件としてその集計フィールドＩＤのフィールドを加えるか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「抽出条件」フィールドと、その集計フィールドＩＤのフィールドを抽出条件とするときのパラメータ名を記録する「パラメータ名称」フィールドと、集計計算のときその集計フィールドＩＤのフィールドに対して伝票データを上書きせずに加減算するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「集計対象」フィールドと、集計表からレコードを削除するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「レコード削除の真偽」フィールドと、集計表を表示するときにその集計フィールドＩＤのフィールドを表示すべきレコードとして抽出するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「表示用抽出条件」フィールドと、を備え、前記集計計算要素テーブルは、少なくとも、「処理ＩＤ」フィールドと、「集計ＩＤ」フィールドと、同一の行で定義されている「処理ＩＤ」フィールドの値で示す処理が同一の行で定義されている「集計ＩＤ」フィールドの値で示す集計表に対して伝票データ中のどのデータを集計するかを一意に識別するコードを記録する「集計計算要素ＩＤ」フィールドと、「集計フィールドＩＤ」フィールドと、その集計フィールドＩＤで特定されるフィールドに対して伝票のデータを集計するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「集計計算の有無」フィールドと、を備え、前記集計表示要素テーブルは、少なくとも、「集計ＩＤ」フィールドと、「集計フィールドＩＤ」フィールドと、集計表に含まれる各レコードを並べるときにそのレコードが指し示すフィールドの値により並び換えるか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「ＤｏＳｏｒｔ」フィールドと、並び換えを行うときに依存するフィールドが複数ある場合の優先順位を規定する「ＳｏｒｔＰｒｉｏｒｉｔｙ」フィールドと、並び換えが行われるときに依存するフィールドが複数ある場合の優先順位を昇順か降順かを表す値で記録する「ＡＳＣｏｒＤＥＳＣ」フィールドと、を備えるように構成できる。一方、前記データベースサーバは、操作の対象とする集計表を表す集計ＩＤを前記第４のレコード抽出処理手段に与えて取得した一連のレコード（以下「第４の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルから集計表を表示するために必要なデータを抽出するためのデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第４の取得レコードの「フィールド名称」フィールドに記録されている値が示すすべてのフィールドのデータを当該集計表テーブルから抽出するにあたり、第４の取得レコードの「表示用抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とを一致させ、当該条件に合致するレコードを当該集計表テーブルから抽出して、第４の取得レコードの「ＤｏＳｏｒｔ」フィールドの値がＴＲＵＥのレコードの「ＳｏｒｔＰｒｉｏｒｉｔｙ」フィールドで示される並び換えの条件の優先順位と「ＡＳＣｏｒＤＥＳＣ」フィールドで示される昇順あるいは降順の区別に従って並び換えるＳＱＬ文を表す文字列を生成し、第１のデータ操作手段として前記集計表データベースに保存するための、第１のＳＱＬ文生成手段と、集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを前記第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルから集計計算の対象となるレコードがあるか否かを確認するためのデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とが一致する当該集計表テーブルのレコードの任意のフィールドを抽出するＳＱＬ文を表す文字列を生成し、第２のデータ操作手段として前記集計表データベースに保存するための、第２のＳＱＬ文生成手段と、集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルからレコードを削除するデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「レコード削除の真偽」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値のいずれかが０または０以下となる当該集計表テーブルのレコードを削除するＳＱＬ文を表す文字列を生成し、第３のデータ操作手段とし前記集計表データベースに保存するための、第３のＳＱＬ文生成手段と、集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルに新たにレコードを追加するデータ操作手段を前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「パラメータ名称」フィールドに値が記録されているレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を新たに記録すべき値として当該集計表テーブルにレコードを追加するＳＱＬ文を表す文字列を生成し、第４のデータ操作手段として前記集計表データベースに保存するための、第４のＳＱＬ文生成手段と、集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルのレコードに計上した伝票のデータを加算又は減算するデータ操作手段を前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値が一致する当該集計表テーブルのレコードに対して加算または減算を行うために、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「集計対象」フィールドの値がＴＲＵＥである条件を満たすレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を加算または減算しさらに前記の条件を満たさず第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「集計対象」フィールドの値がＦＡＬＳＥであり「抽出条件」フィールドがＴＲＵＥである条件をも満たさないレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を新たな値として与えるＳＱＬ文を表す文字列を生成し、第５のデータ操作手段として前記集計表データベースに保存するための、第５のＳＱＬ文生成手段と、集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルのレコードに計上した伝票のデータを上書きするデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とが一致するレコードに対して上書きを行うために、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「パラメータ名称」フィールドに値のあるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドの保持している値をそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値によって置き換えるＳＱＬ文を表す文字列を生成し第６のデータ操作手段として前記集計表データベースに保存するための、第６のＳＱＬ文生成手段と、をさらに備えることができる。
次に、伝票管理システムにおける集計表の集計計算を実行するためには、前記集計表データベースに、前記第１のＳＱＬ文生成手段によって生成された第１のデータ操作手段と、前記第２のＳＱＬ文生成手段によって生成された第２のデータ操作手段と、前記第３のＳＱＬ文生成手段によって生成された第３のデータ操作手段と、前記第４のＳＱＬ文生成手段によって生成された第４のデータ操作手段と、前記第５のＳＱＬ文生成手段によって生成された第５のデータ操作手段と、前記第６のＳＱＬ文生成手段によって生成された第６のデータ操作手段と、をさらに有した伝票管理システムにおいて、パラメータとして、伝票データと、当該伝票データが新規計上又は参照計上と修正計上とのいずれであるかを示す識別子と、集計計算の対象となる集計表を表す集計ＩＤの値と、当該伝票データが修正計上に係る場合に前記伝票管理データベースから抽出された修正前の伝票データと、を受け取るステップ１と、ステップ１で受け取った伝票データの本体項目について、ステップ３以降の処理が全ての本体項目について終了しているか否か判断し、終了していなければステップ３の処理に進ませ、終了していれば終了処理に進ませるステップ２と、ステップ２でステップ３以降が未処理であると判断した本体項目の処理ＩＤを、修正計上に係るものであれば伝票データの問合せデータセクションから取得し新規計上又は参照計上にかかるものであれば伝票データの本体項目データセクションから取得して、その処理ＩＤを前記集計表を表す集計ＩＤの値によって前記第１のレコード抽出手段又は前記第２のレコード抽出手段に与えて第１のレコードセットを取得するステップ３と、ステップ３で取得した第１のレコードセットのレコードの数を知り、レコードの数の回数だけ以降の処理を繰り返すためすべてのレコードが以降の処理を終了しているか否か判断し、ステップ５以降の処理が未処理であれば処理を行うステップ５に進ませ、ステップ５以降の処理が終了していれば、レコード削除の有無を判断するステップ１５に進ませるステップ４と、取得した第１のレコードセットに含まれる集計ＩＤから集計計算の対象となる集計表テーブルを特定し、取得した第１のレコードセットに含まれる集計ＩＤと処理ＩＤを前記第３のレコード抽出手段に与えて第２のレコードセットを取得し、取得した第２のレコードセットに含まれるレコードの「処理対象」フィールドの値に従って処理対象の伝票データが計上された伝票データであるのか修正前の伝票データであるのかを選択するステップ５と、ステップ５で特定された集計表テーブルの親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致するか否か判断するステップ６と、ステップ６で親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致すると判断した場合に、第２のデータ操作手段にパラメータを与えて集計計算対象の集計表テーブルにレコードがあるかないか判断するステップ７と、ステップ７で集計計算対象の集計表テーブルにレコードがあると判断した場合に、第１のレコードセットの「データ処理動作」フィールドの記録された値に従って、前記第５のデータ操作手段または前記第６のデータ操作手段にパラメータを与えて、既存のレコードの上書き・加算・減算のいずれかを実行するステップ８と、ステップ７で集計計算対象の集計表テーブルにレコードがないと判断した場合に、第１のレコードセットの「データ処理動作」フィールドに記録された値に従って、前記第４のデータ操作手段にパラメータを与えて、レコードの新規追加を実行するステップ９と、ステップ６で親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致しないと判断した場合に、現在処理中の本体項目のデータに関連伝票データが含まれているか否か判断し、含まれていなければステップ４に戻らせ、含まれていればステップ１１に進ませるステップ１０と、ステップ１０で現在処理中の本体項目のデータに関連伝票データが含まれていると判断した場合に、ステップ５で特定された集計表テーブルの親の伝票ＩＤと処理中の本体項目が参照している伝票の伝票ＩＤとが一致するか否かを判断し、一致しなければステップ４に戻らせ、一致していればステップ１２に進ませるステップ１１と、ステップ１０で、ステップ５で特定された集計表テーブルの親の伝票ＩＤと処理中の本体項目が参照している伝票の伝票ＩＤとが一致すると判断した場合に、第２のデータ操作手段にパラメータを与えて集計計算対象の集計表テーブルにレコードがあるかないか判断するステップ１２と、ステップ１２で集計計算対象の集計表テーブルにレコードがあると判断した場合に、第１のレコードセットの「データ処理動作」フィールドの記録された値に従って、前記第５のデータ操作手段または前記第６のデータ操作手段にパラメータを与えて、既存のレコードの上書き・加算・減算のいずれかを実行するステップ１３と、ステップ１２で集計計算対象の集計表テーブルにレコードがないと判断した場合に、第１のレコードセットの「データ処理動作」フィールドに記録された値に従って、前記第４のデータ操作手段にパラメータを与えて、レコードの新規追加を実行するステップ１４と、ステップ４ですべてのレコードが以降の処理を終了していると判断した場合に、第１のレコードセットに含まれるレコードの数からその回数だけ第３のデータ操作手段により、集計表テーブルのレコード中削除条件に合致したものを削除するステップ１５と、を実行する。
なお、クライアント装置と、クライアント装置とネットワークで接続されたデータベースサーバ装置と、データベースサーバ装置と接続された伝票管理データベースと、で構成された伝票管理システムにおいて、伝票管理ソフトウェアは、必要に応じてデータベースサーバ装置を介して伝票管理データベースに格納された伝票データの提供を受けながら伝票データの入力・修正・計上・検索のためのインターフェイスを提供するステップと、入力された伝票データを所定の変換方式に従って変換してデータベースサーバ装置に送信するステップとを、クライアント装置に実行させ、クライアント装置から受信した新規計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの新規計上ステップと、クライアント装置から受信した修正計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの修正計上ステップと、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データを一件毎に検索しクライアント装置に送信する伝票一枚検索ステップと、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データの項目を一項目毎に検索してクライアント装置に送信する伝票一項目検索ステップとを、データベースサーバ装置に実行させ、個々の伝票に含まれるデータ中、計上されるデータを修飾するデータであるヘッダーの項目の種類と数を定義するデータを格納する伝票定義データベースと、伝票の種類と伝票間のデータの依存関係を定義するデータを格納する伝票関係定義データベースと、ヘッダーの項目で使用されるデータを格納するヘッダー用データ定義データベースと、個々の伝票に含まれるデータ中、計上の対象となる品目及びその属性を含む本体項目のデータを定義する本体項目用データ定義データベースと、クライアント装置から計上された伝票のデータを所定の方式に従って格納する伝票データベースと、で伝票を管理するデータベースとして伝票管理データベースを機能させるステップを実行させる。
本願発明によれば、管理する伝票の種類と伝票に含まれる項目、伝票間のデータの依存関係、伝票の集計表の種類とそれに含まれる項目、について、設定を変更するだけで自由に決定できるようになっているので、いかなる組織のいかなる伝票も同一の構造のデータベースに記録することができる。すなわち、従来は開発案件毎にデータベースの構造の設計から作業を開始しなければならかったものが、業務システムの主要な部分の開発が不要となり、また、同一構造のデータベースの使用により、システム全体の柔軟性を高めることができコスト削減が可能になる。本発明は、特にデータベースシステムの開発設計を受注するソフトウェアハウスの利用を念頭において開発したものであり、このようなソフトウェアハウスが利用することによって大きな効果を上げるものである。
図１は、本発明による伝票管理システムを実施するための構成全体を示すブロック図である。この伝票管理システムを実施するための主要なハードウェアは、ネットワーク７を介して通信するクライアントコンピュータ２とデータベースサーバ３であり、さらに必要に応じて各種の出力装置及び入力装置が接続される。クライアントコンピュータ２は新規のデータのアップロードあるいはデータの修正やデータ検索の指示を伝票データ５という一つのデータ形式でネットワーク７を介してデータベースサーバ３に送信し、伝票データ５を受信したデータベースサーバ３は、伝票データ５の内容に従って伝票管理データベース４に対するデータの追加・変更やデータの検索や各種出力データ等へのデータの追加・変更を実行する。なお、ユーザーに提供する各種出力データをここでは集計表といい、クライアントコンピュータ２から送信される伝票データ５に基づいてデータベースサーバ３側が行う集計表へのデータ更新処理をここでは集計計算という。また、データベースサーバ３は、必要な集計表をクライアントコンピュータ２側で表示させるための表示データ６をクライアントコンピュータ２に対して送信する。
ネットワーク７は、例えば、ＬＡＮ、公衆回線網、インターネット等の既存のネットワークである。本実施の形態では、クライアントコンピュータ２とデータベースサーバ３間でＴＣＰ／ＩＰとＨＴＴＰを使用して通信を行うようにしているので、インターネット経由でデータ通信が可能になっている。
クライアントコンピュータ２には、伝票のデータを入力しデータベースサーバ３へ送信するためのインターフェイスを提供するための伝票入力用インターフェイス提供ソフトウェア２１と集計表の表示を提供するための集計表表示用ソフトウェア２２が備えられる。
一方、データベースサーバ３には、クライアントコンピュータ２から送信された伝票データ５を伝票管理データベース４に記録する機能に関連する新規計上用ソフトウェア３１及び修正計上用ソフトウェア３２と、クライアントコンピュータ２からの要求に従って伝票管理データベース４の検索を行い必要なデータを抽出するための伝票１枚検索ソフトウェア３３及び伝票１項目検索ソフトウェア３４と、集計表を作成するための集計表作成ソフトウェア３６とが備えられる。
伝票管理システムとしては、上記に述べたソフトウェアが必須であり、伝票についての基本的な処理である追加・変更・検索・集計を実行することが可能であるが、実際の業務処理ではさらに伝票を印刷するための機能を提供する伝票印刷用ソフトウェア３８と、請求書発行ソフトウェア３９と、クライアントコンピュータ２側にはサーバのネットワーク上での位置を特定する情報を提供することを主要な機能とするネットワーク環境等の基本的な設定を管理するための基本設定管理ソフトウェア２３と、データベースサーバ３側には後述する図２及び図３に示すデータベースの内容を設定するためのユーザーインターフェイスを提供することを主たる機能とする基本設定管理ソフトウェア３７とがそれぞれ必要である。
ここで、伝票印刷用ソフトウェア３８は、図１ではデータベースサーバ３に備えられているが、伝票印刷はデータベースサーバ３側で行うことも出来るし、別途印刷専用のプリントサーバを設置してもよいし、クライアント２側で印刷することも可能であり、伝票印刷用ソフトウェア３８は必要に応じてクライアント２側に備えられてもよい。
一方、請求書発行ソフトウェア３９は、特定のコンピュータ１台にインストールされるものである。ここで、例えば、ネットワーク上の任意のコンピュータから任意のログインアカウントで請求書が発行できるとすると、請求書の多重発行が誰にとっても非常に容易になり、これにより何らかの不正を誘発する可能性があり、好ましくない。そこで、本発明によれば、請求書発行機能と伝票入力機能をそれぞれ請求書発行ソフトウェア３９と伝票データ入力用インターフェイス提供ソフトウェア２１に別々に持たせることにより、請求書発行ソフトウェア３９をインストールするコンピュータを１台に限定することを可能とし、さらにそのコンピュータへの物理的なアクセスの制限を推奨することにより、請求書の多重発行を防止するようにしている。
なお、図１には特に図示していないが、本発明によるシステムに、コンピュータシステムを効率よく処理するためにユーザーのプログラムやデータ、ハードウェアなどを管理する基本ソフト（ＯＳ：Operating System）や、データベースの管理・運用を行う専用のソフトウェアであるＤＢＭＳ（Database Management System）が備えられているのが前提である。
次に、伝票管理データベース４に含まれるデータベースの構造について説明する。図２及び図３は、伝票管理データベース４に含まれるデータベースの構成を示す図であり、図４は、本発明により管理される伝票の一例として、受注伝票の例を示した図である。図５は、本発明により管理される伝票の一例として、出荷伝票の例を示した図である。図６は、本発明により管理される伝票の一例として、売上伝票の例を示した図である。図２及び図３の説明にあたって、必要に応じて図４、図５、図６の例を参照する。
図２に示すのは、伝票に関する定義を行うデータベースであり、個々の伝票に含まれるヘッダーの項目の種類と数を定義する伝票定義データベース４１、伝票の種類及び伝票間のデータの依存関係を定義する伝票関係定義データベース４２、伝票のヘッダー部分で使用するデータを定義するヘッダー用データ定義データベース４３、伝票の本体の項目部分で使用するデータを定義する本体項目用データベース４４が含まれる。ここで、ヘッダーとは、伝票に含まれるデータのうち、計上されるデータを修飾するデータをいい、例えば図４に示す受注伝票中、矢印Ｊ１０７で示す受注日、矢印Ｊ１０３で示す担当者、矢印Ｊ１１１で示す受注請求先、矢印Ｊ１０４で示す納入先、矢印Ｊ１０８で示す納入日、矢印Ｊ２１５で示す貴発注Ｎｏ．などである。そして、これらヘッダーのデータを入力するための機能を提供するソフトウェアと、そのソフトウェアを識別するコントロールＩＤ、名称、タイプ等、後述する図７の入力コントロール定義テーブル４１ａの各フィールドのデータすべて又は一部とを合わせたものを入力コントロールという。一方、本体項目とは、計上の対象となる品目とその品目に対する属性等のひとかたまりのデータをいう。このデータに含まれるのは、品目の数量、単位、単価、金額、消費税等と備考と関連伝票のデータである。図４の受注伝票の例では、矢印Ｊ２１４やＪ２１３で示す項目等である。
図３に示すのは、伝票データ及び集計表に関するデータベースであり、伝票データを蓄積するための伝票データベース４５、集計表に関する定義を行う集計表定義データベース４６、各集計表のデータを蓄積する集計表データベース４７が含まれる。なお、図３に示すデータベースの詳細については後段で説明する。
以下、図２に示したデータベースの詳細について説明する。
〔伝票定義データベース〕
図２に示すように、伝票定義データベース４１は、伝票のヘッダー部分を入力するための入力コントロールを定義する入力コントロール定義テーブル４１ａとどの伝票にどの入力コントロールを含めるかを定義する伝票別入力コントロール定義テーブル４１ｂとを含む。
図７に入力コントロール定義テーブル４１ａの例を示す。図７に示した入力コントロール定義テーブル４１ａのフィールド中、「コントロールＩＤ」フィールドには各入力コントロールの識別番号を記録する。また、「名称」フィールドには、コントロールＩＤに対応する入力コントロールの名称を表すデータを記録する。「タイプ」フィールドには、それぞれの入力コントロールが受け入れるデータのタイプを示すコードを記録するものであり、ここでは、１は数値、２は論理値、３は他のデータベースを参照、４は文字列、５は日付、６は時刻、７は１〜７までの任意の個数のデータに何らかの操作を加えて得られる文字または記号で表すことの出来る値、と規定されている。なお、ここで、「タイプ」フィールドにおいて１で定義される数値について補足的な説明をすると、通常コンピュータプログラムで数値を扱うときには、その数値の値のほかに、その数値のもつデータ型（整数型、長整数型、倍精度型等々）を明らかにしないと不都合が起こることが多々あるため、本実施の形態においても、数値のもつデータ型が問題となる。一方、人間の意識では数値の型など問題にしないといってよく、１万分の１のような小さな小数や１０桁の大きな整数を同列に扱っている。そのため、本実施の形態では、利用者が数値で何事か表現したいと思ったときには、その数値のデータ型は意識されていないものという観点からシステム及びソフトウェアを構成している（仮に利用者にデータ型を明らかにするように求めても正しい型が指定されるとは限らないからである）。すなわち、利用者は数値のデータ型を意識しないでソフトウェアやシステムを利用することができるが、本実施の形態に係るソフトウェアの内部では、倍精度型が人間の意識に最も近いものであると判断して「数値」のデータは倍精度型で表現するようにしている。
図７に示した入力コントロール定義テーブル４１ａの各フィールドの説明の続きを行う。「表示」フィールドにはユーザーが入力を行うための入力画面上に表示する入力コントロールの名称データを記録するが、「名称」フィールドと同じ値でなくてもよい。「参照テーブル」フィールドは、「タイプ」フィールドの値が３、すなわち他のデータベースを参照するタイプの場合の参照されるテーブル名を定義する。「インデックス」フィールドには、「参照テ−ブル」フィールドの値、すなわち参照されるテーブルで使用されるインデックス名のデータを記録する。「連携実行コントロール」フィールドには、このテーブルで定義されている入力コントロールの値が変更されたときに実行するコンポーネント名データを記録する。ここで、コンポーネントとは、このソフトウェアから呼び出して実行させることのできるモジュール化したソフトウェアである。
図７に示したテーブル中で、すべてのフィールドに値が入力されているコントロールＩＤの５を例にとって説明すると、コントロールＩＤの５は、伝票中の請求先を入力するための入力コントロールであり、他のデータベースを参照してデータは入力され、参照テーブルは顧客テーブル、インデックスは五十音順、請求先として入力される値が変更されたときには入金日の計算を行う「入金計算」のコンポーネントが実行される。
図７のテーブルで定義される入力コントロールを図４の受注伝票を参照して説明すると、例えば、コントロールＩＤの７は矢印Ｊ１０７で示す受注日を入力するための入力コントロール、コントロールＩＤの３は矢印Ｊ１０３で示す担当者を入力するための入力コントロール、コントロールＩＤの４は矢印Ｊ１０４で示す納入先を入力するための入力コントロールである。
図８に、伝票別入力コントロール定義テーブル４１ｂの例を示す。図８に示した伝票別入力コントロール定義テーブル４１ｂのフィールド名中、「伝票ＩＤ」フィールドには後述する図９で示す伝票ＩＤテーブル４２ａで定義されている各伝票を識別するコードを記録するが、図９に示すとおり、１は売上伝票、２は受注伝票、３は出荷伝票を表すコードである。「入力コントロール表示順番」フィールドは、伝票ＩＤで特定されるある種類の伝票中、入力コントロールにより入力を行うそれぞれの項目が全入力項目中、第何番目に該当するかを記録する。また、「入力コントロール識別表示」フィールドは、伝票ＩＤで特定される一つの伝票中に同じタイプ（入力コントロール定義テーブル４１ａの「タイプ」フィールドの値が同じ）があった場合の識別子データを記録するもので、例えば図８中、コントロールＩＤ３〜６及び９は、図７で定義されているとおり全てタイプが３であるため、「入力コントロール識別表示」フィールドにおいて、１〜５の識別子が付与されている。「コントロールＩＤ」フィールドは、図７で定義されているコントロールＩＤのコードが記録されている。「非表示」フィールドには論理値（図８の例では−１がＴｒｕｅ、０がＦａｌｓｅを意味している。）が記録され、値がＴｒｕｅであれば、その値を含んでいるレコードが表している入力コントロールは、そのレコードが規定している伝票については画面に表示されない。例えば、図８で、伝票ＩＤが１で、コントロールＩＤが１２のレコードの非表示フィールドはー１となっている。これは、売上伝票（伝票ＩＤ＝１）の画面表示に際して、入力コントロールの「月次」（コントロールＩＤ＝１２）は表示されないことを意味する。
「本体送付」フィールドには、論理値（図８の例では−１がＴｒｕｅ、０がＦａｌｓｓｅを意味している。）が入り、値がＴｒｕｅであれば、その値を含んでいるレコードが表している入力コントロールが保持する値を本体項目備考データセクション５６（図２１参照）にも保持する。
図８の例では受注伝票（伝票ＩＤ＝２）の「貴発注Ｎｏ．」を表す入力コントロール(コントロールＩＤ＝２６)しかＴｒｕｅとなっていないが、これはこのソフトウェアの運用上の必要性からこうなっているのであり、この点については以下のように説明できる。この例では、受注伝票の本体の各項目に対して、発注者側の発注Ｎｏ．が記録される。この状態でこの受注伝票（仮に１０００番とする）と別の受注伝票（仮に１００１番とする。これも同じように本体の各項目に、発注者の発注Ｎｏ．が記録されているとする）の２枚を参照して出荷伝票を計上しようとしたとき、ヘッダーの項目の、発注者側の発注Ｎｏ．が受注伝票から出荷伝票にコピーされるような設定になっていると、出荷伝票のヘッダーには２枚の受注伝票のうち、いずれか先に参照した受注伝票（仮に１００１番の方ととする）のヘッダーがコピーされる。このときに、出荷伝票も受注伝票と同じように、ヘッダーに記録された発注者側の発注Ｎｏ．を本体の各項目に記録するようになっていると、出荷伝票のヘッダーに記録されたＮｏ．１００１番の受注伝票のデータが、本体の各項目に記録される。出荷伝票の本体項目の中には１０００番の受注伝票を参照したものもあったので、Ｎｏ．１０００番の受注伝票に基づく発注者側の発注Ｎｏ．をＮｏ．１００１番のデータで上書きすることになる。これは誤りなので、このような事態を避ける為に受注伝票の本体送付フィールドだけをＴｒｕｅにしているものである。
「位置情報」フィールドには、そのフィールドが含まれているレコードが表している入力コントロールを画面表示時にどの位置に表示するかの情報を記録する。図８に示した例では、「位置情報」という名称のフィールドを１つ提示してあるだけだが、入力コントロールの表示手法によっては１つのフィールドだけでは足りない場合もあるし、位置情報が不要な場合もある。どのような表示手法を選ぶかは、入力インターフェイスの外観に対する好みや使用感に対する好みによるので、「位置情報」フィールドをどのように扱うかを事前に確定的に決定することは出来ない。しかしながら、以下の８つの情報を保持できるようにフィールドを用意しておけばどのような表示手法をとるにしてもおおむね充分であると言って良いと考えられる。なお、図８で示された「位置情報」というフィールドは、これから説明する８つのフィールドを総称的に表しているといえる。すなわち、これら８つのフィールドは、入力コントロール定義テーブル４１ａの「表示」フィールドの値を表示する際の、表示位置の左端のX座標とY座標の値、表示領域の幅と高さを表す値、そして実際の値を入力する入力領域のX座標とY座標の値、その入力領域の幅と高さを表す値の８つである。
図８から、例えば、伝票ＩＤの１で特定される売上伝票には、コントロールＩＤの１、２、３、４、５、６、９、２６、１２及び２８で定義される入力コントロールが含まれる。そして、例えば、コントロールＩＤの９で特定される「貴担当」の項目を入力する機能を提供する入力コントロールは、伝票ＩＤの１で特定される売上伝票中、第７番目の入力項目「貴担当」の入力コントロールであり、売上伝票中他のデータベースを参照して入力する項目の５番目に該当する。
〔伝票関係定義データベース〕
伝票関係定義データベース４２は、伝票の種類及び伝票間のデータの依存関係を定義するデータベースで、図２で示すように、取り扱う伝票の種類を定義する伝票ＩＤテーブル４２ａ、データベースに対する伝票データの計上の種類を定義する計上ＩＤテーブル４２ｂ、データベースに記録される伝票データがどの伝票を参照した何の伝票であるかを一意に示す処理ＩＤを定義する処理ＩＤテーブル４２ｃ、ある処理のときにどの伝票のどの入力コントロールがどの伝票のどの入力コントロールを参照してデータを得るかを定義する伝票間参照関係テーブル４２ｄを含む。
図９に、取り扱う伝票の種類を定義する伝票ＩＤテーブル４２ａの例を示す。図９に示したテーブルのフィールド中、「伝票ＩＤ」フィールドは取り扱う個々の伝票の種類を識別するためのコードを記録する。「名称」フィールドは、伝票ＩＤに対応する伝票の名称データを記録するものであり、「ファイル名」フィールドは、伝票のデータを記録するデータベースファイル名を表すデータを記録する。「表示名」は、画面や印刷時に表示される場合の名称を定義するもので、「名称」フィールドと同一でなくてもよい。「修正動作」フィールドは、修正した伝票を参照している伝票がある場合、修正した値からその伝票を参照している伝票の値を引くか否かを表すデータを記録する。例えば、出荷伝票を参照している売上伝票がある場合、売上伝票の値を修正後の出荷伝票の値から引くか否かを表すもので、この例の場合は引くべきである。受注伝票や発注伝票のように常にシステムとはまったく関係なく数量が決定される伝票を修正した場合は、その伝票を参照している伝票の値は引かない。なぜならば、ユーザーは伝票の修正時には最初の受注数量はいくつで、その後いくつを出荷計上したかといった履歴を考慮せずに変更されてはならない最終的な値を修正時に入力するからである。このフィールドの値が−１ならば引き、０ならば何もしない。
図１０にデータベースに対する伝票データの計上の種類を定義する計上ＩＤテーブル４２ｂの例を示す。本発明による伝票管理ソフトウェアにおいて、伝票データの「計上」には４つの態様がある。
コードの１で特定されるのは「新規計上」であり、新規計上とは、計上される伝票データがユーザーのコンソール操作により与えられる場合をいう。
コードの２で特定されるのは「参照計上」であり、参照計上とは、計上される伝票データが他の種類の伝票を参照することにより得られた場合をいい、参照された伝票の数量は参照した側に移動される。すなわち、参照した伝票の方で計上した数量が、参照された側の伝票の数量から引かれることになる。例えば、出荷伝票で数量１００を計上してあるときに、その出荷伝票を参照して売上伝票を計上しようとすると、参照の結果、売上伝票にも数量１００が入力される。売上伝票に入力されたこの数量に変更が加えられずに計上されると、出荷伝票の数量から１００が引かれ、その結果数量は０となる。一方、何らかの理由で、入力された数量が８０に変更され計上された場合は、出荷伝票の数量は、１００から８０が引かれて２０となる。次の機会にこの出荷伝票を参照すると、当然ながらその時点での数量が得られる。前記の例の売上伝票の数慮が１００であった場合は０が得られるし、８０であった場合は、２０が得られる。なお、参照した結果得られた数量が０である場合は、何も参照しなかったのと事実上同じと考えられるので、その場合はエラーとして扱うことができる。
コードの３で特定されるのは「修正計上」であり、修正計上とは、計上される伝票データが同一種類の伝票を参照することにより得られる場合（すなわち、同一種類の伝票を参照するのはその伝票を修正することを目的としている場合である）をいう。
コードの４で特定されるのは「複写計上」であり、複写計上とは、計上される伝票データが他の種類の伝票のデータを転記することにより得られた場合で、複写された伝票のデータには何の変更も加えられない場合をいう。なお、通常の伝票管理を行う場合は、「新規計上」「参照計上」「修正計上」の３種類の計上によりデータの追加・変更・管理を行うことが可能であり、本実施の形態でも基本的にはこの３種類の計上を設定しておけば発明の実施が可能である。従って、「複写計上」は常に必須の要素とはいえないが、例えば、ある伝票を起点にして、伝票データの流れが分岐するような場合、具体的には、入庫伝票−仕入伝票とデータが流れるフローと、入庫伝票−出庫伝票−売上伝票とデータが流れるフローに分岐するような場合に、分岐の一方の流れを作り出すためには、入庫伝票を参照して計上する仕入伝票と出荷伝票のうちどちらかを複写計上とし、他方を参照計上とすればよい。このようにすれば、複写計上は、参照された伝票のデータに変更を加えないので、後に参照計上することが可能となり、データの流れが分岐される。このような業務の場合には、前記の３種類の計上に加えて「複写計上」を設定しておくとよい。
図１１に、データベースに記録される伝票データがどの伝票を参照した何の伝票であるかを一意に示す処理ＩＤを定義する処理ＩＤテーブル４２ｃの例を示す。 図１１に示されたテーブルのフィールド中、「処理ＩＤ」フィールドはデータベースに記録される伝票データがどの伝票を参照した何の伝票であるかを一意に示す処理ＩＤを識別するコードであり、処理ＩＤの個数は最大で、伝票の種類×（伝票の種類数−１＋３）となる（＋３は、新規計上の場合と修正計上の場合と複写計上の場合を追加するからである）。処理ＩＤは、伝票間に参照関係がない場合は存在しない。従って、処理ＩＤの個数は伝票の種類数からは判断できない。
図１１に示されたテーブルのフィールド中、「名称」フィールドはコードで識別されるそれぞれの処理ＩＤの名称データを記録し、「計上ＩＤ」フィールドは当該処理ＩＤで表される処理が該当する計上ＩＤのコードを記録し、「伝票ＩＤ」フィールドは当該処理ＩＤで表される処理を行う伝票ＩＤのコードを記録し、「トップ選択肢」フィールドは当該処理ＩＤで表される処理が同一の伝票内で最も選択される頻度が高いと思われるならばＴｒｕｅとして「−１」を記録し、そうでなければ「０」を記録する。「参照伝票ＩＤ」フィールドは当該処理ＩＤで表される処理のときにデータが参照される側の伝票の伝票ＩＤのコードを記録する。
ここで、図１１で示した処理ＩＤテーブル４２ｃの例に従って処理ＩＤの「１」を説明すると、処理ＩＤ「１」は、新規売上の処理であり、計上ＩＤとしては「１」すなわち新規計上であり、伝票は伝票ＩＤ「１」で定義する売上伝票であり、新規計上処理は売上伝票での処理では選択される頻度は最も高い処理ではなく、また新規売上処理は他の伝票を参照して行われる処理ではない。また、処理ＩＤ「３」を説明すると、処理ＩＤ「３」は、出荷参照売上の処理であり、計上ＩＤとしては「２」すなわち参照計上であり、伝票は伝票ＩＤ「１」で定義する売上伝票であり、出荷参照売上の処理は売上伝票での処理では選択される頻度は最も高く、また、出荷参照売上の処理は伝票ＩＤが「３」である出荷伝票を参照して行われる処理である。
図１２に、どの処理のときにどの伝票がどの伝票を参照してデータを得るかを定義する伝票間参照関係テーブル４２ｄの例を示す。図１２で示したテーブルのフィールド中、「処理ＩＤ」フィールドは図１１のテーブルで定義されている処理ＩＤのコードを記録している。「被参照伝票ＩＤ」フィールドは参照される側の伝票の伝票ＩＤのコードを記録し、「参照伝票ＩＤ」フィールドは被参照伝票において参照する伝票の伝票ＩＤのコードを記録する。
「被参照入力コントロール」フィールドは、参照される側の伝票でヘッダーの項目を入力するための入力コントロールであって、参照伝票の入力コントロールによって参照される入力コントロールを記録し、「参照入力コントロール」フィールドは、参照する伝票中の参照する入力コントロールを記録する。「コピー」フィールドは、伝票間で参照が行われるとき、ヘッダーの項目のデータが参照される伝票から参照する伝票へコピーされるか否かを定義するもので、コピーされるならば−１、そうでなければ０を記録する。
図１２で定義されている内容を図４、図５、図６に示す受注伝票、出荷伝票、売上伝票を例にして説明する。例えば、図１２の伝票間参照関係テーブルの１行目で定義されているのは、処理ＩＤが２である「受注参照売上」の処理（図１１参照）では、売上伝票（伝票ＩＤのコードが１）は、受注伝票（伝票ＩＤのコードが２）を参照する、売上伝票の２番目の入力コントロール（請求先を入力する機能を提供する入力コントロール）は、受注伝票の２番目の入力コントロールを参照し、そのヘッダーの項目がコピーされる、ということになる。また、例えば、図１２の伝票間参照関係テーブルの９行目で定義されているのは、処理ＩＤが３の「出荷参照売上」の処理では、売上伝票（伝票ＩＤのコードが１）は、出荷伝票（伝票ＩＤのコードが３）を参照する、売上伝票の８番目の入力コントロール（貴発注Ｎｏを入力する機能を提供する入力コントロール）は、出荷伝票の７番目の入力コントロール（貴発注Ｎｏを入力する機能を提供する入力コントロール）を参照し、そのヘッダーの項目がコピーされる、ということになる。
〔ヘッダー用データ定義データベース〕
ヘッダー用データ定義データベース４３は、伝票のヘッダー部分で使用するデータを定義するデータベースであり、図２に示すように、顧客テーブル４３ａ、仕入先テーブル４３ｂ、配送業者テーブル４３ｃ、社員テーブル４３ｄ、未登録項目テーブル４３ｅ、ＹｅｓＮｏテーブル４３ｆ、下位区分テーブル４３ｇ、任意テーブル４３ｈを含む。
顧客テーブル４３ａは、例えば、図７で定義される入力コントロール中、コントロールＩＤが４の納入先、コントロールＩＤが５の請求先、コントロールＩＤが１１の受注請求先を入力する場合に参照する顧客テーブルの内容を定義するもので、ここでは特に具体的な例は図示しないが、顧客を特定するコード、名称、名称の振り仮名、郵便番号、住所１、住所２、電話番号、ファクシミリ番号、担当者名、締切日、支払月、支払日、指定伝票の有無、発注番号の有無、当該コードのレコードを削除済みとして扱う為の識別子、業種によって消費税率が変更される場合の識別子、等のフィールドを含み、それぞれのフィールドに対し、データが入力される。
仕入先テーブル４３ｂ及び配送業者テーブル４３ｃは、同じ構造のテーブルを使用する。ここでは特に具体的な例は図示しないが、それぞれ仕入先または配送業者を特定するコード、名称、名称の振り仮名、郵便番号、住所１、住所２、電話番号、ファクシミリ番号、担当者名、締切日、支払月、支払日、当該コードのレコードを削除済みとして扱う為の識別子、消費税率が変わる場合の識別子、等のフィールドを含み、それぞれのフィールドに対し、データが入力される。仕入先については図７の例では登場していないが、配送業者については、例えば、図７の例で定義される入力コントロール中、コントロールＩＤが６の配送を入力する場合参照する配送業者テーブルの内容を定義するものである。
社員テーブル４３ｄは、例えば図７で定義される入力コントロール中、コントロールＩＤが３の自社の担当者を入力する場合に参照する社員テーブルの内容を定義するものであり、ここでは特に具体的な例は図示しないが、社員を特定するコード、氏名、振り仮名、郵便番号、住所１、住所２、電話番号、部署名、当該コードのレコードを削除済みとして扱う為の識別子、等のフィールドを含み、それぞれのフィールドに対し、データが入力される。
未登録項目テーブル４３ｅは、未登録（あるいはその同義語、例えば諸口、その他、等）という１つのレコードしか含まない。このテーブルは、データタイプが３の場合（他のデータベースを参照する場合）であって、さらに、用意するテーブルの内容が確定出来ない場合（その理由としては、変化が早くてすぐ陳腐化するなど）に記録すべきデータを一括して扱いたいときに使用する。
ＹｅｓＮｏテーブル４３ｆは、入力コントロールが受け入れるデータタイプが２の場合（論理値）のときに使用するものであり、選択の余地が２つしかない属性に対する選択肢を提供するテーブルであるが、データタイプが３の場合（他のデータベースを参照する場合）でデータが２つしかない場合と区別する必要がある。そこで、データタイプとして２をもつ入力コントロールは、その値として「はい」か「いいえ」のどちらしかもたないとし、ＹｅｓＮｏテーブル４３ｆによってその選ばれるべき選択肢を提供することにした。
下位区分テーブル４３ｇは、データタイプが３の場合（他のデータベースを参照する場合）使用するものである。この「他のデータベース」としてどのようなものが必要とされるかは予め予測できない。そこで、下位区分テーブル４３ｇは、コード、名称、振り仮名、当該レコードを削除済みとして扱う為の識別子、のフィールドを含み、テーブルの構造のみが規定されている。下位区分テーブル４３ｇは、データタイプが３の入力コントロールごとに必要とされるデータベースの内容が異なるので、最大で入力コントロールの数だけ用意されることになる。その場合、それぞれの下位区分テーブル４３ｇを区別するために使用されるのはテーブルの名称である。
任意テーブル４３ｈは、コード、名称、振り仮名、当該レコードを削除済みとして扱う為の識別子、のフィールドを含み、意味と名称を自由に設定出来るテーブルである。この任意テーブル４３ｈは、ソフトウェアの実装時に何らかの理由で想定外のテーブルが必要になったときに、予め構造を規定しているテーブルでその必要性を満たすことが出来るように用意されたものである。
〔本体項目用データベース〕
本体項目用データベース４４は、計上の対象となる伝票の本体の項目部分で使用するデータベースを定義するもので、図２に示すとおり、品目コードテーブル４４ａ、品目属性定義テーブル４４ｂ、品目コード品目属性対応テーブル４４ｃ、単位テーブル４４ｄ、品目上位区分テーブル４４ｅ、ＹｅｓＮｏテーブル４４ｆ、下位区分テーブル４４ｇ、区分品目対応テーブル４４ｈ、任意テーブル４４ｉを含む。
図１３に、計上の対象となる品目を識別する品目コードを定義する品目コードテーブル４４ａの例を示す。図１３に示すテーブルのフィールド中、「品目コード」フィールドは各品目を識別するために付与されたコードを定義するものであり、「名称」フィールドは品目の名称、「振り仮名」フィールドは品目の読みをそれぞれ表すデータを記録する。「標準単位」フィールドは当該コードで識別される品目を計るときに標準的に使用される単位のデータを記録するもので、具体的には後述する単位テーブル４４ｄで定義されるコードを用いる。「消費税率コード」フィールドは、品目の性質によって消費税率が変更される場合の識別子を記録するためのものである。また、「レコード削除」のフィールドは、当該レコードを削除済みとして扱う為の識別子のためのものであり、このレコードを削除とするならばＴｒｕｅとして「−１」を記録し、そうでなければ「０」を記録する。
図１４に、品目コードで特定される品目の属性を定義する品目属性定義テーブル４４ｂの例を示す。図１４に示すテーブルのフィールド中、「属性コード」フィールドは品目についての属性を特定するためのコードを定義する。「名称」フィールドは属性の名称を表すデータを記録するもので、「振り仮名」フィールドは属性名の読みを表すデータを記録するものである。「タイプ」フィールドはこの属性を入力する場合のデータのタイプのコードを記録する。ここでは、１は数値、２は論理値、３は他のデータベースを参照、４は文字列、５は日付、６は時刻、７は１〜７までの任意の個数のデータに何らかの操作を加えて得られる文字または記号で表すことの出来る値、としている。「参照テーブル」フィールドは、「タイプ」フィールドで値が３の場合に参照するテーブル名を定義する。「区切り記号」は、表示時に当該属性と他の属性を区切る区切り記号を定義する。「規定値」フィールドは、「タイプ」フィールドの値が２（論理値）だった場合の規定値を定義する。２（論理値）でない場合は、このフィールドの値は、参照されないのでなんでもよい。「単位」フィールドは、当該属性の単位を定義するもので、後述する図１６で示す単位テーブルのコードを利用するのではなく、単位の表示名を直接データとして保持する（従って、どのような単位でも規定可能である。）。「連携実行コントロール」フィールドは、当該属性の値が変更されたときに実行するコンポーネントの名前を定義する。
図１５に、どの品目にどの属性が含まれるかを定義する品目コード品目属性対応テーブル４４ｃの例を示す。図１５に示すテーブルのフィールド中、「品目コード」フィールドは品目コードテーブル４４ａで定義される品目コードを記録し、「属性順序」フィールドは同一品目内での属性の順番を定義する。「属性コード」フィールドは、当該品目の当該属性順に該当する属性コード（品目属性定義テーブル４４ｂで定義されている属性コード）を記録する。図１５で示されるテーブルの例の１行目から３行目では、品目コードの１で規定された異形棒の第１番目の属性は属性コードの２で規定された直径であり、異形棒の第２番目の属性は属性コードの３で規定された長さであり、異形棒の第３番目の属性は属性コードの４１で規定された重量である、ということを表している。
図１６に、単位のコードを定義する単位テーブル４４ｄの例を示す。図１６に示すテーブルのフィールド中、「単位コード」フィールドはそれぞれの単位を識別するためのコードを定義し、「名称」フィールドは当該単位の名称データを記録し、「振り仮名」フィールドは当該名称の振り仮名を表すデータを記録するものである。「レコード削除」のフィールドは、当該レコードを削除済みとして扱う為の識別子のためのものであり、このレコードを削除とするならばＴｒｕｅとして「−１」を入力し、そうでなければ「０」を記録する。
図１７に、品目の上位区分を定義する品目上位区分テーブル４４ｅの例を示す。図１７に示すテーブルのフィールド中、「品目区分コード」フィールドはそれぞれの上位区分を識別するために付与するコードを定義するものであり、「名称」フィールドは当該上位区分の名称を表し、「振り仮名」フィールドは当該名称の振り仮名を表す。「レコード削除」のフィールドは、当該レコードを削除済みとして扱う為の識別子のためのものであり、このレコードを削除とするならばＴｒｕｅとして「−１」を記録し、そうでなければ「０」を記録する。
ＹｅｓＮｏテーブル４４ｆは、図１４で示す品目属性定義テーブル４４ｂのフィールド中、品目属性フィールドのデータタイプが２の場合（論理値）のときに使用するものであり、選択の余地が２つしかない属性に対する選択肢を提供するテーブルであるが、データタイプが３の場合（他のデータベースを参照する場合）でデータが２つしかない場合と区別する必要がある。そこで、データタイプとして２をもつ品目は、その値として「はい」か「いいえ」のどちらしかもたないとし、ＹｅｓＮｏテーブル４４ｆによってその選ばれるべき選択肢を提供することにした。
下位区分テーブル４４ｇは、品目のデータタイプが３の場合（他のデータベースを参照する場合）使用するものである。この「他のデータベース」としてどのようなものが必要とされるかは予め予測できない。そこで、下位区分テーブル４４ｇは、コード、名称、振り仮名、当該レコードを削除済みとして扱う為の識別子、のフィールドを含み、意味と名称を自由に設定出来るように、テーブルの構造のみが規定されている。下位区分テーブル４４ｇは、データタイプが３の品目ごとに必要とされるデータベースの内容が異なるので、最大で品目の数だけ用意されることになる。その場合、それぞれの下位区分テーブル４４ｇを区別するために使用されるのはテーブルの名称である。図１８では、下位区分テーブル４４ｇの例として、図１４の品目属性定義テーブルの第２行目参照テーブルで「異形」と規定されている、「異形」テーブルの例として、二つのテーブル「径」、「ね規」の例を示した。
図１９に、どの区分にどの品目が含まれるかを定義する区分品目対応テーブル４４ｈの例を示す。図１９に示されたテーブルの「品目区分コード」フィールドには図１７で示した品目区分テーブル４４ｅで定義された品目区分コードが表され、「品目コード」フィールドには当該品目区分に該当する図１３に示した品目コードテーブル４４ａで定義された品目コードが表される。
なお、任意テーブル４４ｉは、コード、名称、振り仮名、当該レコードを削除済みとして扱う為の識別子、のフィールドを含み、意味と名称を自由に設定出来るテーブルである。この任意テーブル４３ｉは、ソフトウェアの実装時に何らかの理由で想定外のテーブルが必要になったときに、予め構造を規定しているテーブルでその必要性を満たすことが出来るように用意されたものである。
以上で、図２に示した伝票に関する定義を行う各データベースの説明を終了する。伝票管理データベース４（図１参照）には、さらに図３に示した伝票データ及び集計表に関するデータベースが含まれるが、図３についての説明を行う前提として、今度は伝票データ５（図１参照）について説明する。
〔伝票データの構造〕
図２０及び図２１は、伝票データ５（図１参照）の構造を模式的に示した図である。伝票データ５は、伝票管理データベース４（図１参照）に対するデータの追加・変更やデータの検索を実行するために、クライアントコンピュータ２からデータベースサーバ３に送信される一連のデータのかたまりであり、ユーザーが伝票入力用インターフェイス提供ソフトウェア２１を用いてデータの追加・変更あるいはデータの検索のための入力処理を行った後に、入力されたデータは常に図２０及び図２１に示す一定の形式のデータ構造に変換されて、データベースサーバ３に送信される。
図２０及び図２１に示すとおり、伝票データ５に含まれる種々のデータは、問合せ用データセクション５１、伝票基本データセクション５２、ヘッダー項目データセクション５３、ヘッダー未登録データセクション５４、本体項目データセクション５５、本体項目備考データセクション５６、関連伝票データセクション５７、属性データセクション５８の各データセクションに分かれて記録される。以下、各データセクションについて説明する。
問合せデータセクション５１に含まれるデータは、データベースサーバ３に対して検索の指示を行うために送信されるデータであり、このデータベースサーバ３への問合せは、図１０の計上ＩＤテーブル４２ｂで定義される計上ＩＤが２の参照計上または計上ＩＤが３の修正計上をユーザーが選択した場合に実行される。問合せデータセクション５１には、検索の対象とするのが１つの伝票単位なのか、あるいは伝票の１項目単位なのかを表すデータベースサーバ３側の処理コードが記録されるエリア５１ａ、エラーコード等データベースサーバ３側からのステータスコードを記録するためのエリア５１ｂ、検索の対象となる伝票の伝票ＩＤ（図９参照）を記録するためのエリア５１ｃ、検索する伝票の伝票番号を記録するためのエリア５１ｄ、検索する伝票の項目番号を記録するためのエリア５１ｅ（「項目番号」は、当該伝票の本体項目中、何番目の本体項目かを表す）、伝票をファックスするか否かを記録するためのエリア５１ｆ（ユーザーのファックス送信の要望がある場合に備えて設けてある）、伝票全体の処理ＩＤ（図１１参照）を記録するためのエリア５１ｇ、サーバー側からのエラーメッセージを記録するためのエリア５１ｈ、データベースサーバ３側での処理結果（すなわち、成功したか、エラーとなったか）を真か偽かで記録するためのエリア５１ｉ、将来何らかの必要が生じた場合に備えて設けられた予約の記録領域５１ｊが含まれている。
伝票データ基本データセクション５２は、計上する伝票の基本的なデータを記録するセクションであり、図９で定義されている伝票ＩＤを記録するためのエリア５２ａ、計上の対象となる伝票の伝票番号を記録するエリア５２ｂ（なお、新たに計上される伝票の伝票番号はデータベースサーバ３側の新規計上用ソフトウェア３１によって採番されるようになっている）、伝票計上の日付を記録するエリア５２ｃ、伝票の印刷回数を記録するエリア５２ｄ（印刷回数を記録するのは、不正操作を防止するためである）、伝票の実際の作成日を記録するためのエリア５２ｅが含まれている。伝票データ基本データセクション５２は、処理に係る伝票に関して、必ず１つのみに特定されるデータを記録するセクションである。
ヘッダー項目データセクション５３は、伝票のヘッダーについてのデータを項目毎に記録するものである。従って、どのような処理を行うか、あるいは伝票の種類によって、伝票データ５に含まれるヘッダー項目データセクション５３の個数は、０以上の任意の個数で構成される。ヘッダー項目データセクション５３には、伝票番号を記録するエリア５３ａ、図７で定義される入力コントロールＩＤのコードを記録するためのエリア５３ｂ、この項目が伝票内で何番目の項目かを示す項目の順序のデータを記録するエリア５３ｃ、入力コントロールによりヘッダー項目データとして実際に入力する項目の実体データを記録するエリア５３ｄ、この項目が有効か否かを示すデータを記録するためのエリア５３ｅを含んでいる。
なお、ここで、当該項目が有効か否かを示すデータを記録するためのエリア５３ｅについて、ここに記録されるデータがどのように使用されるかについての説明を補足する。クライアントコンピュータ２の伝票データ入力用インターフェイス提供ソフトウェア２１では、入力されたデータ（このデータはユーザーのコンソール操作によるものでも、データベースサーバ３から送られたものでもよい）を保持するために記憶領域をあらかじめ確保するが、その確保のときに、その時点で設定されている入力対象の伝票のヘッダーの構成に合わせて必要な数のヘッダー項目データセクションを確保し、この時点で確定しているデータ（エリア５３ｂに記録される「コントロールＩＤ」とエリア５３ｃに記録される「項目の順序」）を設定しさらにエリア５３ｅの値をＴｒｕｅ（有効）とする。つまり、クライアントコンピュータ２側は、現時点で設定されているヘッダー項目の構成に従い記憶領域を確保しており、その構成に従ったデータが入力されると期待している。しかし、以前の伝票を修正しようとして１枚の伝票を検索した場合は、その検索した伝票が計上された時点と現時点ではヘッダー項目の構成が異なる可能性がある。そこで、データベースサーバ３から送られてきた伝票データ５をクライアントコンピュータ２側で取り込むとき、まず確保された記憶領域の５３ｅの値をすべてＦａｌｓｅ（無効）とする。次に、データベースサーバ３から送られた最初のヘッダー項目データについてそのコントロールＩＤと現時点での設定の最初のヘッダー項目データのコントロールＩＤを比較し、この両者の値が一致し、さらに記憶領域５３ｅが無効である場合には、記憶領域の５３ｄ「この項目の実体データ」にデータベースサーバ３から送信されたデータをコピーし、記憶領域５３ｅの値をＴｒｕｅ（有効）とする。両者の値が一致しない場合、または一致するが記憶領域５３ｅの値がＴｒｕｅ（有効）となっている場合は、何もしない。この処理の結果、記憶領域５３ｅがＴｒｕｅ（有効）になっていれば、データベースサーバ３から送信されてきたデータのうち最初のヘッダー項についての処理は終了する。一方、有効でなければ二番目の現時点でのヘッダー項目と比較し、以下すべての現時点でのヘッダー項目との比較が終わるまで、この処理を繰り返す。（ただし、途中で記憶領域５３ｅがＴｒｕｅ（有効）になれば、その時点で処理を終了させる。この処理が終了した時点で、記憶領域５３ｅをＦａｌｓｅ（無効）からＴｒｕｅ（有効）へ変更させることがなかったデータベースサーバ３から送信されたヘッダー項目のデータは捨てられることになる。上記の処理はデータベースサーバ３から送られてきた最初のヘッダー項目について説明したものであるが、二番目以降のデータについても同様で、すべてのデータベースサーバ３から送信されたヘッダー項目のデータについて同じ処理を繰り返す。
その結果、以前のヘッダー項目と現時点でのヘッダー項目のうち同一のコントロールＩＤを持つものだけがコピーされ、以前のヘッダー項目にあり、現時点でのヘッダー項目にない項目のデータはクライアント側にとり込まれず、逆に、以前のヘッダー項目になく、現時点のヘッダー項目にある項目に関しては最初に記憶領域が確保された時の状態のままである。
ヘッダー未登録項目データセクション５４は、伝票のヘッダー中、未登録項目についてのデータを項目ごとに記録するものである。従って、ヘッダー項目データセクション５３と同様に、伝票データ５に含まれるヘッダー未登録項目データセクション５４の個数は、０以上の任意の個数で構成される。ヘッダー未登録項目データセクション５４は、データタイプが他のデータベースを参照する場合であって、用意するテーブルの内容が確定できない場合に、直接未登録項目のデータを記録するもので、伝票番号を記録するエリア５４ａ、この未登録項目が伝票の何番目のヘッダーの項目かを示すデータを記録するエリア５４ｂ、実際に入力される未登録項目の内容を記録するエリア５４ｃを含んでいる。
本体項目データセクション５５は、計上の対象となる伝票の本体の項目のデータを項目毎に記録するものである。従って、どのような処理を行うか、あるいは伝票の種類によって、伝票データ５に含まれる本体項目データセクション５５の個数は、０以上の任意の個数で構成される。本体項目データセクション５５には、伝票番号を記録するエリア５５ａ、項目番号を記録するエリア５５ｂ、画面に表示された伝票の何番目に表示される本体項目であるかを記録するエリア５５ｃ、伝票番号１番の１項目目から数えて通算何番目の項目に該当するかを示すシリアル番号を記録するエリア５５ｄ、図１７で定義される品目区分コードを記録するためのエリア５５ｅ、図１３で定義される品目コードを記録するためのエリア５５ｆ、項目の表示名を属性も含めて記録するためのエリア５５ｇ、この項目の数量を示すデータを記録するためのエリア５５ｈ、図１６で定義されている単位コードを記録するためのエリア５５ｉ、この項目の単価を示すデータを記録するためのエリア５５ｊ、この項目の金額のデータを記録するためのエリア５５ｋ、消費税のデータを記録するためのエリア５５ｌ、この項目の処理ＩＤのコードを記録するためのエリア５５ｍが含まれる。なお、数量、単位、単価、金額、消費税のデータを記録するエリア５５ｈ、５５ｉ、５５ｊ、５５ｋ、５５ｌは、伝票の性質によっては何もデータが記録されない場合がある。
本体項目備考データセクション５６は、１枚の伝票に含まれる全ての本体項目を同時に修飾するヘッダーのデータを各本体項目に関連づけて記録するものである。品目を修飾するという点では、「属性」データを記録する場合と同じだと考えられるが、個々の品目についての補足説明を行う場合の入力欄を設ける場合は属性のデータを記録することによって行うのに対し、本体項目備考データは、ヘッダーの項目のデータを本体項目を修飾するものとして個々の本体項目データに関連付けて記録するものである。
本体項目備考データとして記録することが必要な場合の一例を挙げる。例えば、受注伝票に発注者の発注番号を記録したいとすると、発注番号は、１枚の伝票に含まれる本体項目全てに対して共通なので、品目の属性として記録するよりも、ヘッダーの項目として記録する方がふさわしい。しかし、このように発注番号を記録した受注伝票を２枚以上参照して１枚の売上伝票を計上する場合、売上伝票の本体の１項目目は受注伝票１０００番の１項目目のデータで、売上伝票の本体の２項目目は受注伝票１００１番の１項目目のデータである、と言うような構成になる。この場合、受注伝票の１０００番と１００１番では、発注番号が異なるので、売上伝票の本体の１項目目の品目を修飾する発注番号と、２項目目の品目を修飾する発注番号は異なる。このような場合に正確に各項目の発注番号を売上伝票データに記録するために本体項目備考データを記録するセクションを設けたのである。
なお、ヘッダーの項目全てに対して本体項目備考データセクション５６にデータが記録されるわけではなく、必要と思われるデータを選択して指定することにより、本体項目備考データセクション５６にデータが記録される。従って、伝票の種類あるいは処理の種類により、伝票データ５に含まれる本体項目備考データセクション５６の個数は、０以上の任意の個数で構成される。
本体項目備考データセクション５６には、伝票番号を記録するエリア５６ａ、本体項目の項目番号を記録するエリア５６ｂ、ヘッダー項目データセクション５３のコントロールＩＤを記録するエリア５３ｂに記録される値に基づく入力コントロールテーブル４１ａから得られる「表示」フィールドの値と同じ値を「備考の名前」として記録するエリア５６ｃ、ヘッダー項目データセクション５３のコントロールＩＤを記録するエリア５３ｂに記録された値と同じ値を備考コードとして記録するエリア５６ｄ、ヘッダー項目データセクション５３のエリア５３ｄに記録された値かあるいはヘッダー未登録データセクション５４のエリア５４ｃに記録された値を備考内容データとして記録するエリア５６ｅ、本体項目が伝票番号１番の1項目目から数えて通算何番目の項目に該当するかを示すシリアル番号を記録するエリア５６ｆを含んでいる。なお、ヘッダー項目のデータを本体備考データセクション５６にも保持するか否かは、伝票別入力コントロール定義テーブル４１ｂの「本体送付」フィールドに論理値を記録ことにより行われる。
関連伝票データセクション５７は、本体項目にこの項目がどの伝票の何番目の項目を参照してデータを得ているかを記録するものである。そのため、伝票の種類あるいは処理の種類により、伝票データ５に含まれる関連伝票データセクション５７の個数は、０以上の任意の個数で構成される。関連伝票データセクション５７には、伝票番号を記録するエリア５７ａ、本体項目の項目番号を記録するエリア５７ｂ、本体項目が伝票番号１番の１番目から数えて通算何番目の項目に該当するかを示すシリアル番号を記録するエリア５７ｃ、参照されている伝票の項目とこの項目との関係を表す関連コードを記録するエリア５７ｄ、参照されている伝票の伝票ＩＤ（図９で定義されている）を記録するエリア５７ｅ、参照されている伝票の伝票番号を記録するエリア５７ｆ、参照されている伝票の項目番号を記録するエリア５７ｇ、参照されている項目が伝票番号１番の１番目から数えて通算何番目の項目に該当するかを示すシリアル番号を記録するエリア５７ｈを含んでいる。
なお、本実施例においては関連コードはまだ定義されていない。それはこのコードは現在の実施例では使用されておらず、将来の拡張に備えるために用意されたものであるからである。予定されているコードは例えば以下のようなものになる。関連コードの値が「１」である関連伝票データは、ある伝票データがそれ自身のデータを得る為に参照した伝票を指すデータである（例えば、売上伝票Ｎｏ．１０００が出荷伝票Ｎｏ．９５０を参照して計上されている場合には、売上伝票Ｎｏ．１０００は関連伝票データに出荷伝票Ｎｏ．９５０を指すデータを持つが、そのときの関連コードが１となる）。関連コードの値が「２」である関連伝票データは、関連コードの値が「１」の関連伝票データが指す伝票データが、そのデータを得る為に参照した伝票を指すデータである（例えば、上記の例で、出荷伝票Ｎｏ．９５０は受注伝票Ｎｏ．８００を参照しているとすると、売上伝票Ｎｏ．１０００は、関連伝票データに受注伝票Ｎｏ．８００を指すデータを持つが、そのときの関連コードは２となる）。関連コードの値が「３」である関連伝票データは、上記の関連コード「２」についての説明文において、関連コードの値の２を３に、１を２に読み替えたものとなり、関連コードの値が「４」以降についても同様の読み替えを順次行うことによって説明されるものである。
また、関連コードの値が「−１」である関連伝票データは、その関連伝票データを含む伝票データを参照してデータを得た伝票データを指す（例えば、上記の例で、受注伝票Ｎｏ．８００の伝票データは、関連伝票データに出荷伝票Ｎｏ．９５０を指すデータを持つが、そのときの関連コードは「−１」となる）。関連コードの値が「−２」である関連伝票データは、関連コードの値が「−１」である関連伝票データが指す伝票データを参照してデータを得た伝票データを指す（例えば、上記の例で、受注伝票Ｎｏ．８００の伝票データは、関連伝票データに売上伝票Ｎｏ．１０００を指すデータを持つが、その時の関連コードの値は「−２」となる）。関連コードの値が「−３」である関連伝票データは、上記の関連コード「−２」についての説明文において、関連コードの値の「−２」を「−３」に、「−１」を「−２」に読み替えたものとなり、関連コードの値が「−４」以降についても同様の読み替えを順次行うことによって説明されるものである。なお、値がマイナスの関連伝票データは、その関連伝票データを含む伝票データが計上された時点ではなく、その関連伝票データが指す伝票データが計上された時点でなければ、その内容を確定できない。
属性データセクション５８は、伝票に含まれる本体項目毎に品目の属性を記録するものであり、伝票の種類あるいは処理の種類により、伝票データ５に含まれる属性データセクション５８の個数は、品目ごとに０以上の任意の個数で構成され、さらにその品目が含まれる本体項目の数も０以上の任意の個数で構成される。属性データセクション５８は、伝票番号を記録するエリア５８ａ、項目番号を記録するエリア５８ｂ、本体項目データセクション５５に記録されているこの項目が伝票番号１番の１項目目から数えて通算何番目の項目に該当するかを示すシリアル番号を記録するエリア５８ｃ、本体項目データセクション５５に記録されている品目コードを記録するエリア５８ｄ、この属性はこの項目のなかで何番目であるかを記録するエリア５８ｅ、図１４で定義されている品目属性コードを記録するエリア５８ｆ、属性の値を記録するためのエリア５８ｇを含んでいる。
以上の伝票データ５の構造において、図示は省略したが、各伝票データセクションを区切るためのデータが別途付与されている。また、本体項目備考データセクション５６、関連伝票データセクション５７及び属性データセクション５８は、本体項目データセクション５５の下位に従属する構造になっている。図２０、図２１に示すように、伝票データ５に含まれるデータを、本来の計上する伝票に含まれるデータを記録した伝票基本データセクション５２以降のデータセクションのみならず、データベースサーバ３に対する検索の指示を行うためのデータを記録する問合せ用データセクション５１を常に含んだ構成にしたのは、そのような構成にすることにより、クライアントコンピュータ２とデータベースサーバ３との間でやりとりするすべてのデータが含まれることになるので、データベースサーバ３は伝票データ５を受領した時点で、送信されたデータが計上する伝票の内容に関わるデータなのかあるいは指示データであるのかを判断するためにデータ構造を解析する必要がなくなるからである。なお、図２０及び図２１には図示していないが、伝票データ５には、伝票データの先頭と末尾を示す識別子が含まれているので、例えば、問合せ用データセクション５１のデータしかデータベースサーバ３に送信しない場合は、問合せ用データセクション５１の直後にデータの末尾を示す識別子が付されることにより、存在しない伝票基本データセクション５２以降のデータにアクセスが試みられる場合はない。
計上する伝票に含まれるデータを記録した伝票基本データセクション５２以降のデータセクションに構造については、それぞれのデータセクションが一枚の伝票につき必ず１つあるか、０個以上の不定の数か、という点を考慮してデータセクションの区切りを定めてある。すなわち、伝票番号、伝票計上の日付、伝票の印刷回数、伝票の実際の作成日のデータは一枚の伝票についてそれぞれ必ず有するデータであるので、伝票基本データセクション５２に記録される。一方、ヘッダー項目やヘッダー未登録項目や本体項目は、一枚の伝票についてのデータ数が０個以上の不定の数であり、さらに本体項目の下層に展開される備考、関連伝票、属性のデータについても、一枚の伝票についてのデータ数が０個以上の不定の数である。これらのデータ数が不定なデータについては、それぞれが一枚の同一伝票に含まれるデータという点では共通だが、個々のデータの数については、それぞれ何ら関連性はない。したがって、これらのデータを１つのまとまったデータセクションとして記録するのではなく、ヘッダー項目データセクション５３、ヘッダー未登録項目データセクション５４、本体項目データセクション５５、本体項目データセクション５５の下層に展開する本体項目備考データセクション５６、関連伝票データセクション５７、属性データセクション５８、にそれぞれ項目毎に記録するようにした。これらのデータを１つのまとまったデータセクションとして記録すると、場合によってはデータを含まない空白の下層のデータエリアが多量に発生して非効率的であるからである。
なお、本実施の形態においては、伝票データ５をＸＭＬ形式に変換してデータベースサーバ３に送信するようにした。図２２及び図２３にそのＸＭＬ形式のデータの例を示す。図２２及び図２３において、各タグの右側に記載されている内容のデータをタグとタグに挟まれた間に記述する。なお、構造に特徴があるので、タグの名称については、どのような名称を用いても構わない。図２２及び図２３に示したタグの名称は単なる例である。
以上で伝票データの構造に関する説明を終了する。次に、データベースサーバ３に送信された伝票データ５に基づいて伝票データを蓄積し管理するための図３に示す伝票データベース４５の詳細について説明する。
〔伝票データベース〕
伝票データ５を伝票管理データベース４に記録するには、図２０及び図２１に示したデータセクション５２〜５８を、各データセクション毎に図３に示した伝票データベース４５の各テーブルに保存する。すなわち、伝票基本データセクション５２に記録されたデータは伝票基本データテーブル４５ａへ、ヘッダー項目データセクション５３に記録されたデータはヘッダー項目データテーブル４５ｂへ、ヘッダー未登録項目データセクション５４に記録されたデータはヘッダー未登録項目データテーブル４５ｃへ、本体項目データセクション５５に記録されたデータは本体項目データテーブル４５ｄへ、本体項目備考データセクション５６に記録されたデータは本体項目備考データテーブル４５ｅへ、関連伝票データセクション５７に記録されたデータは関連伝票データテーブル４５ｆへ、属性データセクション５８に記録されたデータは属性データテーブル４５ｇへ、それぞれ記録される。それぞれのデータセクションの各記録エリアがそれぞれのデータテーブルの各フィールドに割り当てられ、各記録エリアに記録されたデータがそのフィールドの値となる。
図２４〜図３０は、伝票データベース４５に属する各テーブルの例を示したものであり、これらの例は、図４に示す伝票ＩＤが２である受注伝票（図９参照）の伝票番号が１４（図４中矢印Ｊ４０１参照）の伝票データを含んだ例なので、図４、図２０〜２１を参照しながらこれらのテーブルの内容について説明する。
図２４に例を示す伝票基本データテーブル４５ａは、伝票ＩＤ、伝票番号、計上日、作成日、印刷回数の各フィールドに、伝票データ５の伝票基本データセクション５２の伝票ＩＤを記録するエリア５２ａ、伝票番号を記録するエリア５２ｂ、伝票計上の日付を記録するエリア５２ｃ、伝票の印刷回数を記録するエリア５２ｄ、伝票の作成日を記録するエリア５２ｅの各エリアに記録されたデータがそれぞれ記録される。図２４に示す伝票基本データテーブル４５ａの３行目に図４の受注伝票のデータが記録されている。すなわち、伝票ＩＤが２である受注伝票で、伝票番号が１４（図４中の矢印Ｊ４０１参照）、計上日及び作成日が２００３年４月１１日である。
図２５に例を示すヘッダー項目データテーブル４５ｂは、伝票番号、コントロールＩＤ、項目の順序、項目実体の各フィールドに、伝票データ５のヘッダー項目データセクション５３の伝票番号を記録するエリア５３ａ、コントロールＩＤを記録するエリア５３ｂ、項目の順序を記録するエリア５３ｃ、項目の実体データを記録するエリア５３ｄの各エリアに記録されたデータがそれぞれ記録される。図２５に示した例では、伝票番号１４のヘッダー項目の１番目から９番目までの項目のコントロールＩＤと項目に入力された実際の内容を示しており、例えば、第１行目は図４中矢印Ｊ１０７で示す部分を反映しており、伝票番号１４の第１番目のヘッダー項目は、コントロールＩＤが７である受注日の入力コントロールにより（図７参照）入力を行う項目であり、実際に入力されたデータは２００３／０４／１１である。
図２６に例を示すヘッダー未登録項目データテーブル４５ｃは、伝票番号、項目の順序、未登録項目の内容の各フィールドに、伝票データ５のヘッダー未登録項目データセクション５４の伝票番号を記録するエリア５４ａ、項目の順序を記録するエリア５４ｂ、未登録項目の内容として入力された内容を記録する５４ｃの各エリアに記録されたデータがそれぞれ記録される。図２６に示した例では、図２５に示した図中、第６行目の項目の順序が６番目の入力コントロールが９で参照テーブルとして未登録項目が指定されており（図７参照）、これが図２６の図中第３行目の未登録項目の内容である「室橋」に該当する。図４中、Ｊ４０６の矢印で示す部分である。
図２７に例を示す本体項目データテーブル４５ｄは、伝票番号、項目番号、シリアル番号、品目区分コード、品目コード、表示品名、数量、単位コード、金額、消費税、処理ＩＤの各フィールドに、伝票データ５の本体項目データセクション５５の伝票番号を記録するエリア５５ａ、項目番号を記録するエリア５５ｂ、シリアル番号を記録するエリア５５ｄ、品目区分コードを記録するエリア５５ｅ、品目コードを記録するエリア５５ｆ、項目の表示名を記録するエリア５５ｇ、数量を記録するエリア５５ｈ、単位コードを記録するエリア５５ｉ、単価を記録するエリア５５ｊ、金額を記録するエリア５５ｋ、消費税を記録するエリア５５ｌ、処理ＩＤを記録するエリア５５ｍの各エリアに記録されたデータがそれぞれ記録される。図２７に示した例は、図４に示す受注伝票中の、本体項目の１番目の項目（図４中、矢印J２１４で示す）及び本体項目の二番目の項目（図４中、矢印J２１４で示す）のデータを示したもので、処理ＩＤが５なので新規受注により（図１１参照）計上されたデータである（なお、図２７で、数量、金額、消費税が０となっているのは、図４で示した受注伝票Ｎｏ．１４を参照して図５の出荷伝票Ｎｏ．１が計上された後の時点のテーブルの状態を示したもので、出荷伝票で計上された数量が受注伝票から引かれるので、受注伝票の数量が０となる）。なお、伝票データ５の本体項目データセクション５５中の画面上で表示された順序のデータを記録するエリア５５ｃのデータは本体項目データテーブル４５ｄには記録しない。
図２８に例を示す本体項目備考データテーブル４５ｅは、伝票番号、項目番号、シリアル番号、備考の名称、備考コード、備考内容の各フィールドに、伝票データ５の本体項目備考データセクション５６の伝票番号を記録するエリア５６ａ、項目番号を記録するエリア５６ｂ、備考の名前を記録するエリア５６ｃ、備考コードを記録するエリア５６ｄ、シリアル番号を記録するエリア５６ｆの各エリアに記録されたデータがそれぞれ記録される。図２８に示した図の第３行目では、図４に示した受注伝票中、矢印Ｊ２１５で示す備考「貴発注Ｎｏ．」の内容が記録される。
図２９に例を示す関連伝票データテーブル４５ｆは、伝票番号、項目番号、シリアル番号、関連コード、参照ＩＤ、参照伝票番号、参照項目番号、参照シリアル番号の各フィールドに、伝票データ５の関連伝票データセクション５７の伝票番号を記録するエリア５７ａ、項目番号を記録するエリア５７ｂ、シリアル番号を記録するエリア５７ｃ、関連コードを記録するエリア５７ｄ、参照伝票ＩＤを記録するエリア５７ｅ、参照伝票番号を記録するエリア５７ｆ、参照項目番号を記録するエリア５７ｇ、参照シリアル番号を記録するエリア５７ｈに記録されたデータがそれぞれ記録される。なお、図２９は、受注伝票Ｎｏ．１４を参照して計上された出荷伝票Ｎｏ．５の関連伝票データを記入した例である。
図３０に示す属性データテーブル４５ｇは、伝票番号、項目番号、シリアル番号、品目コード、属性順序、属性コード、属性の値の各フィールドに、伝票データ５の属性データセクション５８の伝票番号を記録するエリア５８ａ、項目番号を記録するエリア５８ｂ、シリアル番号を記録するエリア５８ｃ、品目コードを記録するエリア５８ｄ、属性順序を記録するエリア５８ｅ、属性コードを記録するエリア５８ｆ、属性の値を記録するエリア５８ｇの各エリアに記録されたデータが記録される。図３０では、図4に示す受注伝票の項目番号が２である矢印Ｊ２１３で示す項目の属性データを記録しており、品目コード１３の属性について、図１４及び図１５で定義されている属性コード及び属性順序に従って、属性の値を記録している。
以上で伝票データ５の構造及び伝票データベース４５についての説明を終了する。次に、伝票データ５の入力及びデータベースサーバ３への計上を行うためのインターフェイスを提供する伝票入力用インターフェイス提供ソフトウェア２１（図１参照）の機能について説明する。
［伝票入力用インターフェイス提供ソフトウェア］
図３１は伝票入力用インターフェイス提供ソフトウェア２１が提供する機能の概要について図示したものであり、図３２〜図３６は、ユーザーがデータの入力や処理の選択等を行うために、伝票入力用インターフェイス提供ソフトウェア２１がコンピュータのディスプレイ上に表示させる各画面の例を示したものである。
伝票入力用インターフェイス提供ソフトウェア２１は、例えば、図３２（ａ）に示したメインメニューの「伝票計上」（矢印ｙ１）を選択し、図３２（ｂ）に示す「伝票計上」の下層プルダウンメニュー（矢印ｙ２）からユーザーが「○○伝票計上」を選択することでロードされる。ここで、下層ブルダウンメニューで「○○伝票計上」を選択するということは、計上の対象となる伝票の種類を選択する、すなわち、図９で定義している伝票ＩＤを選択することになる。この機能が図３１中、計上する伝票の伝票ＩＤの選択機能２１ａに該当する。
計上する伝票の伝票ＩＤの選択機能２１ａの提供により、ユーザーが計上する伝票の伝票ＩＤを選択すると、伝票データの入力用画面が表示される。図３３は、受注伝票計上を選択した場合の入力用画面の一例を示している。この伝票データの入力用画面表示機能２１ｂによって提供される画面（これを以下「入力待ち画面」という）は、計上ＩＤの選択機能２１ｃ、ヘッダー項目入力機能２１ｆ、本体項目の処理ＩＤの選択機能２１ｇ、本体項目入力機能２１ｋ、データベースサーバ４への計上用伝票データの送信機能２１ｎのそれぞれの機能がすべてこの画面を介して提供されることに特徴がある。
図３３中、矢印ｃで示す「伝票Ｎｏ．」のボタンは計上ＩＤの選択機能を提供するものであり（これを以下「伝票ボタン」という）、矢印ｆで示すウィンドーはヘッダー項目を入力するためのものであり、矢印ｇで示す各Ｎｏ．を表示するボタンは本体項目の処理ＩＤの選択機能を提供するもの（これを以下「Ｎｏ．Ｘ」ボタンという）であり、矢印ｋで示すウィンドーは本体項目を表示するためのものであり、矢印ｍで示すのは入力された伝票のデータを計上するためにデータベースサーバ４に送信するためのボタンである。なお、矢印ｎで示す「終了」ボタンはユーザーがこのメニューを終了させるためのボタンである。次に上記した各機能について、図３３〜図３６の画面の例を参照しながらより詳細に説明する。
以下の説明は、ユーザーが図３３に示す入力待ち画面を表示させて以降の動作を説明するものである。まず、ユーザーが伝票ボタンｃを押した場合について説明する。伝票ボタンｃが押されると、次に図３４に示す処理選択画面１のうち（ａ）の画面が表示される。図３４（ａ）では、「他の伝票を参照せず新規に受注伝票を計上する」の選択肢がデフォルトとして設定されている。これにＯＫボタンを押すことは、すなわち図１０で定義されている新規計上の計上ＩＤを選択することである。新規計上が選択された場合、すべての項目についてユーザーが独自に入力を行うことになるので、再び図３３の入力待ち画面が表示される。一方、処理内容選択画面１において、「以前の受注伝票を修正する」を選択した場合は、修正計上の計上ＩＤを選択したことになり、「見積書を参照して受注伝票を計上する」を選択した場合は、参照計上の計上ＩＤを選択したことになる。なお、図３４で示す画面が表示する段階で既に伝票ＩＤは選択されているので、ここで「新規計上」、「修正計上」または「参照計上」を選択するということは、すなわち、図１１で定義している処理ＩＤを選択することにもなる（ここで、図３４に示す処理選択画面１に表示される選択肢はあくまで例示であって、ここに表示される選択肢は、処理選択画面１が表示される時点ですでに選択されている伝票ＩＤにかかわる処理ＩＤ全てになる。従って、図１１に示す処理ＩＤテーブル４２ｃの内容が変れば、選択肢の数や内容はそれに応じて変ることになる）。
処理内容選択画面１において、修正計上あるいは参照計上を選択した場合には、すでに伝票管理データベース４に記録されている過去の伝票のデータを呼び出す必要がある。そこで、修正計上あるいは参照計上を選択した場合には、図３４（ｂ）の矢印ｘで示す伝票番号入力欄を表示させ、ユーザーの入力を促す（これは、図３１中、伝票番号入力機能２１ｄに該当する）。伝票番号の入力が行われ、ＯＫボタンが押されると、入力されたデータは図２０で示す伝票データの構造中、問合せ用データセクション５１に変換され、指定された伝票のデータを要求する伝票データ５として、データベースサーバ３に送信される（これは、図３１中、データベースサーバへの伝票１枚データ要求機能２１ｅに該当する）。そして、データベースサーバ３から返信された指定の伝票のデータはクライアントコンピュータ２側で表示等するために必要な処理が行われ、図３３に示す入力待ち画面中の矢印ｆやｋで示されるウィンドーに表示され、ユーザーの次の段階の入力を促すことになる。
新規計上あるいは修正計上や参照計上であっても、ヘッダー項目の入力は再び図３３に示す入力待ち画面に戻って、ｆで示すウィンドーを用いて行われる。修正計上や参照計上のためにすでに過去の伝票番号を指定してデータベースサーバ３に要求を行った場合は、図３３の例で示すように、指定された伝票のデータがｆのウィンドーに表示される。ｆのウィンドーの左側に各ヘッダー項目が表示され、ユーザーは各ヘッダー項目欄の右側にデータを入力していくが、修正計上や参照計上の場合は過去のデータを利用しながら、または、データベースサーバ３からヘッダー用定義データベース４３（図２参照）の各テーブルの内容が送信され画面上でスクロールすることによって入力するデータを選択できるようになっている。
次に、本体項目用データの入力に関する機能である本体項目の処理ＩＤの選択機能２１ｇ、本体項目入力機能２１ｋについて説明する。本体項目用データについての処理ＩＤの選択は図３３中の矢印ｇで示す各Ｎｏ．を示すボタンを選択することによって実行される。ここでのＮｏ．は、同一伝票番号内に複数の本体項目用データが含まれる場合に、伝票単位でデータをデータベースサーバ３から呼び出した場合には、項目の順にそれぞれのＮｏ．の右側のウィンドーに表示されるし、例えば特定の伝票の項目を指定してデータを呼び出した場合は、その指定に際して選択したＮｏ．を示すボタンの右側のウィンドーに表示される。
ここで、例えば図３４（ｂ）に示したように処理内容選択画面１で伝票番号を指定することによってデータベースサーバ３からすでに指定の伝票のデータが送信されている場合には、図３３中の矢印ｋで示すウィンドーに送信された本体項目のデータが表示されている。そのとき、本体項目のデータが表示されたＮｏ．Ｘボタンを選択すると、図３５に示す処理選択画面２のうち（ａ）に示す画面が表示される。ここでは、「表示されているデータを修正する」の選択肢がデフォルトとして設定されているので、ＯＫボタンを選択すると、図３６に示した本体項目入力画面が表示され、例示した（ａ）または（ｂ）のようにすでに送信されている本体項目のデータが本体項目の入力画面にロードされる。そして、ユーザーはこの画面を利用してデータの修正を行うことができる。
一方、図３５に示した処理内容選択画面２において、「他の伝票を参照せずに新規に受注伝票を計上する」を選択した場合には、図３３に示した入力待ち画面が再び表示される。また、図３５に示した処理内容選択画面２において、（ｂ）に示すように「見積書を参照して受注伝票を計上する」を選択した場合には、矢印ｘで示す伝票番号入力欄及び矢印ｙで示す項目番号入力欄を表示させ、ユーザーの入力を促す（図３１中、伝票番号と項目番号入力機能２１ｉに該当する）。伝票番号及び項目番号の入力が行われ、ＯＫボタンが押されると、入力されたデータは図２０で示す伝票データ５の構造中、問合せ用データセクション５１に変換され、指定された伝票のデータを要求する伝票データ５として、データベースサーバ３に送信される（図３１中、データベースサーバへの伝票１項目データ要求機能２１ｊに該当する）。そして、データベースサーバ３から返信された指定の伝票のデータは、図３３に示す入力待ち画面に表示され、ユーザーの次の段階の入力を促すことになる。
次に、図３３に示した入力待ち画面において、ユーザーが直接ｋのウィンドーを選択した場合について説明する。このとき、ｋのウィンドーにすでにデータベースサーバ３から送信されたデータが表示されている場合には、このウィンドーを選択することによって、表示されていたデータが図３６に示す本体項目入力画面にロードされるので、この画面においてユーザーがデータの修正等を行うことができる。一方、入力待ち画面のｋのウィンドーに何も表示がない場合には、これを選択することによって、空白の本体項目入力画面が表示され、ユーザーが新規に入力を行うことが出来る。なお、本体項目入力画面では、データベースサーバ３から本体項目用データベース４４（図２参照）の各テーブルの内容が送信されてスクロールすることによって入力するデータを選択できるようになっている。
ユーザーによる伝票の新規計上、参照計上、あるいは伝票の修正のための入力が完了すると、図３３で示す入力待ち画面の矢印ｍで示す計上ボタンを選択することにより、入力されたデータは図２０で示す伝票データの構造の伝票基本データセクション５２以下すべてのデータとして、データベースサーバ３に送信される。計上ボタンの選択により伝票データ５をデータベースサーバ３に送信する場合、問合せ用データセクション５１におけるサーバー側の処理コード５１ａのエリア及び伝票ＩＤ５１ｃのエリアの値が、計上の目的により変化する。すなわち、サーバー側の処理コード５１ａの値が、新規計上か、参照計上か、以前の伝票の修正か、の区別を表し、伝票ＩＤ５１ｃの値により、計上する伝票の伝票ＩＤを表す。伝票を計上する場合には、問合せ用データセクション５１においてこれ以外のデータは必要ない。データベースサーバ３側で計上に対してエラーが発生した場合には、サーバー側からのステータスコード５１ｂのエリアにエラーコードが、エラーメッセージ５１ｈのエリアにエラーメッセージが記録された問合せデータセクション５１の部分がデータベースサーバ３から送信される。一方、エラーが発生しなかった場合には、サーバー側からのステータスコード５１ｂのエリアに成功を示すコードが、新規計上と参照計上の場合には、伝票番号５１ｄのエリアに伝票番号が記録されてデータベースサーバ３から送信される。
さらに、ここで、参照計上あるいは修正計上のために、処理選択画面１（図３４参照）あるいは処理選択画面２（図３５参照）で伝票番号または伝票番号と項目番号を指定して、データベースサーバ３に指定の伝票のデータを要求する場合についても説明する。データベースサーバ３に送信される伝票データ５は、図２０で示す伝票データ５の構造中、問合せデータセクション５１とその直後に付されたデータの末尾を示す識別子のみであり、実際にデータとして含まれるのは、サーバー側の処理コードを記録するエリア５１ａに記録された検索が伝票１枚かあるいは伝票の１項目のどちらかを示すコード、伝票ＩＤを記録するエリア５１ｃに記録された検索の対象となる伝票のＩＤ、伝票番号を記録するエリア５１ｄに記録された検索の対象となる伝票番号、項目番号を記録するエリア５１ｅに記録された検索の対象となる伝票の項目番号、の４つである。なお、処理内容選択画面１を介して検索指示がデータベースサーバ３に送信される場合は、項目番号５１ｄにはデータは与えられない。
この問合せに対して、データベースサーバ３は、エラーが発生しなかった場合には伝票データ５の問合わせデータセクション５１及び伝票基本データセクション５２以下の必要なデータを送信する。一方、エラーが発生した場合には、サーバー側からのステータスコード５１ｂのエリアにエラーコードが、エラーメッセージ５１ｈのエリアにエラーメッセージが記録された問合せデータセクション５１の部分がデータベースサーバ３から送信される。次に、クライアントコンピュータ２からの要求に対してデータベースサーバ３から送信された伝票データ５がクライアントコンピュータ２側でどのように処理されるかについて説明する。
参照計上または修正計上を行うためにデータベースサーバ３に対する問合せが成功した場合、検索された伝票のデータがクライアントコンピュータ２に送信されるが、このデータをクライアントコンピュータ２側でそのまま受け入れてユーザーの処理の対象とすることは出来ない。受信したデータに対しては整形の必要があり、その整形の種類は４種類である。
参照計上を行うために、他の種類の伝票を１枚検索した場合には、ヘッダー項目に関する部分、伝票番号、項目番号、関連伝票に関する部分、の４点についてのデータについて以下のように整形を行う必要がある。図２０の伝票データの構造中、ヘッダー項目データセクション５３及びヘッダー未登録項目データセクション５４のヘッダー項目に関するデータについては、伝票の種類が異なると、ヘッダー部分の構成が異なるのでデータの取捨選択を行う。各データセクションの伝票番号については、データベースサーバ３に計上するために伝票のデータを送信したときにデータベースサーバ３側で決定するので０にクリアする。各データセクションの項目番号については、データベースサーバ３から送信された項目番号のデータが１から始まり連続しているかどうか保証されていないので（参照された伝票のデータはすでに別の機会に１項目の検索を受けており、そのデータがない場合もあるからである）、新たに送信されたデータの最初の本体の項目から１からの連番を割り当てる。なお、本体項目データセクション５５の画面上で表示された順序のエリア５５ｃの値は、項目番号に新たに番号を割り当てたので、その値と等しくなる。また、関連伝票に関する部分については、検索された伝票は計上されたときの関連伝票のデータがあればその関連伝票のデータも共に送信されてくるが、今度は検索された伝票が関連伝票として新たな伝票が計上されることになるので、もとの関連伝票に関するデータについては書換あるいは追加が必要となる。
修正計上を行うために以前の伝票を検索した場合には、同じ種類の伝票を検索するのでデータの整形の必要はなさそうであるが、以前の伝票と現在の伝票ではヘッダー項目の部分の構成が変更されている可能性があるので、変更の有無を確認し、必要があればヘッダー項目の部分の整形を行わなければならない。一方、参照計上の場合と異なり、項目番号には変更を加えない。なぜならば、例えば、送信された伝票のデータの本体項目が１つしかなくその項目番号が５番だとすると、この本体項目が最初のデータであるとして項目番号を１番に変更すると、修正計上として再びこの伝票のデータをデータベースサーバ３に送信したときに、クライアントコンピュータ２側では５番目の本体項目が修正されることを意図しているにも拘らず、指定された伝票番号の１番目の項目を修正してしまうことになるからである。但し、クライアントコンピュータ２側では、（例えば画面上で表示位置を決定するときなど）本体項目のデータの並ぶ順番を項目番号として扱いたいときもある。そこで、本体項目データセクション５５の画面上で表示された順序のエリア５５ｃに１から連続した順番を割り当てる。
修正計上のために以前の伝票の１項目を検索した場合には、参照計上の場合と同様の理由で、項目番号、本体項目データセクション５５の画面上で表示された順序のエリア５５ｃの値、及び関連伝票データセクション５７のデータを整形しなくてはならない。但し、項目番号と画面上で表示された順序のエリアに代入する値は、何項目目に検索したデータをコピーするか、というコピー先を示すデータとなる。
なお、複写計上のために伝票を１枚検索した場合は、検索した伝票が計上しようとしている伝票と同じ種類か否かにより処理が異なる。検索した伝票が計上しようとしている伝票と同じ種類の伝票の場合は、以前の伝票と現在の伝票との間でヘッダー項目の部分の変更の有無を確認し、必要があればヘッダー項目の部分の整形を行い、伝票番号を０にクリアした上、送信された伝票のデータの本体項目の最初の項目から項目番号を１から順番に割り当て、関連伝票に関するデータを削除する。また、検索した伝票が計上しようとしている伝票と別の種類の伝票である場合は、ヘッダー項目データセクション５３及びヘッダー未登録項目データセクション５４のヘッダー項目に関するデータについては、ヘッダー部分の構成が異なるのでデータの取捨選択を行い、各データセクションの伝票番号については０にクリアし、各データセクションの項目番号については、新たに送信されたデータの最初の本体の項目から１からの連番を割り当てる。また、関連伝票に関する部分のデータは削除する。
以上で伝票データ入力用インターフェイス提供ソフトウェア２１についての説明を終了する。次にクライアントコンピュータ２から伝票データ５を受信して、伝票データ５に含まれるクライアントコンピュータ２からの指示に従って伝票管理データベース４に対する操作を実行する、データベースサーバ３側に備えられた新規計上用ソフトウェア３１、修正計上用ソフトウェア３２、伝票１枚検索ソフトウェア３３、及び伝票１項目検索ソフトウェア３４について説明する。
〔新規計上用ソフトゥエア〕
新規計上用ソフトウェア３１は、新たに計上される伝票のデータを伝票管理データベースに対して追加する機能を提供するもので、新規計上、参照計上及び複写計上による場合を含む。その手順は以下のとおりである。
（１）受信した伝票データ５の問合せデータセクション５１の伝票ＩＤを記録するエリア５１ｃ（図２０参照）に記録された伝票ＩＤの値からどの伝票に対する計上かを判断し、伝票管理データベース４に設けられた伝票データベース４５を開く。
（２）伝票データ５の伝票基本データセクション５２のデータを記録する伝票基本データテーブル４５ａを排他モードで開き（すでに排他モードで開かれている場合には、排他モードで開けるまで開く動作を繰り返す）、最新の伝票番号を得てそれに１を加え、新たに計上する伝票の番号とする。
（３）その新たに取得した伝票番号を、受信した伝票データ５の各データセクションの伝票番号を記録するエリアにセットする。
（４）伝票データ５の記録されているデータを各データセクション毎に、伝票データベース４５の各データテーブル４５ａ〜４５ｇに追加する。
（５）参照計上の場合のみ、計上されたデータを参照伝票から引く。
〔修正計上用ソフトウェア〕
修正計上用ソフトウェア３２は、すでに伝票管理データベース４に記録されている伝票のデータを修正する機能を提供するものであり、修正計上によって伝票データ５をデータベースサーバ３にアップロードした場合に実行されるものである。その手順は以下のとおりである。
（１）受信した伝票データ５の問合せデータセクション５１の伝票ＩＤを記録するエリア５１ｃに記録された伝票ＩＤの値からどの伝票に対する修正かを判断し、伝票管理データベース４に設けられた伝票データベース４５の該当ファイルを開く。
（２）修正前の修正対象伝票を、伝票データ５の問合せ用データセクション５１に記録されている伝票番号及び項目番号から検索する。
（３）クライアントコンピュータ２から送信された修正後の各本体項目について以下の処理を実行する。
（４）本体項目データセクション５５のこの項目の処理ＩＤを記録するエリア５５ｍに記録されている処理ＩＤに基づいて、処理ＩＤテーブル４２ｃ（図１１参照）を検索する。
（５）処理ＩＤテーブル４２ｃでその処理ＩＤの計上ＩＤが参照計上に該当すれば、以下の処理を実行する。一方、その処理ＩＤが参照計上以外であれば（９）の処理に飛ぶ。
（６）修正対象伝票が参照している伝票のデータベースを開く。
（７）（２）で検索した修正前のデータを、修正対象伝票が参照している伝票に対して足す（つまり戻すことになる）。
（８）クライアントコンピュータ２から送信された修正後のデータを、修正対象伝票が参照している伝票から引く。
（９）クライアントコンピュータ２から送信された修正後のデータを（１）で開いた修正対象のデータベースに上書きする。
（１０）今処理している伝票に対する前方参照があるか否か調べる（ここで、「前方参照」とは、ある伝票を参照して計上されている伝票があるとき、参照されている伝票から見て、他の伝票が自分を参照していることをいう。例えば、受注伝票を参照して売上伝票を計上しているとき、受注伝票からみて売上伝票が自分を参照している場合をいう。）。具体的には、（１）の伝票ＩＤの値を参照伝票ＩＤのフィールドにもつレコードを処理ＩＤテーブル４２ｃ（図１１参照）から抽出する。レコードがあれば（レコードは１件とは限らない）前方参照はある。なお、この場合の「ある」は「定義上ある」の意味であって、実際に今処理している個別の伝票の前方参照が「ある」ことを意味しているわけではない。）
（１１）前方参照がある場合は、以下の処理をする。ない場合は（３）からの処理を繰り返す。
（１２）伝票ＩＤテーブル４２ａ（図９参照）で、（１）の伝票ＩＤの値を伝票ＩＤフィールドに持つレコードの修正時動作フィールドの値を調べ、Ｔｒｕｅ（−１）ならば、以下の処理を行う。ない場合は、（３）からの処理を繰り返す。
（１３）（１０）で得られた処理ＩＤテーブル４２ｃのレコードすべてについて以下の処理を行う。
（１４）修正対象伝票を参照している伝票のデータベースを開く。
（１５）修正対象伝票を参照している伝票（複数枚あるときはそれらの合計）の値を得る。
（１６）その値を修正対象伝票から引く。
（１７）（３）からの処理をすべての本体の項目について終わるまで繰り返す。
〔伝票１枚検索ソフトウェア〕
伝票１枚検索ソフトウェア３３は、クライアントコンピュータ２から問合せのため送信された伝票データ５の問合わせデータセクション５１のサーバー側の処理コードを記録するエリア５１ａの値が、伝票１枚を検索するコードであるときに、検索の対処となる伝票のＩＤを記録するエリア５１ｄの値及び伝票番号を記録するエリア５１ｃの値に基づいて、伝票データベース４５の各データテーブル４５ａ〜４５ｇ(図３参照)から検索の対象となる伝票１枚のデータを抽出し、伝票データ５の伝票基本データセクション５２以下の各データセクションのデータとして割り当てて、問合わせデータセクション５１とともにクライアントコンピュータ２に送信する。
〔伝票１項目検索ソフトウェア〕
伝票１項目検索ソフトウェア３４は、クライアントコンピュータ２から問合せのため送信された伝票データ５の問合わせデータセクション５１のサーバー側の処理コードを記録するエリア５１ａの値が、伝票１項目を検索するコードであるときに、検索の対処となる伝票のＩＤを記録するエリア５１ｄの値と伝票番号を記録するエリア５１ｄの値と伝票項目番号を記録するエリア５１ｅの値に基づいて、伝票データベース４５の各データテーブル４５ａ〜４５ｇ(図３参照)から検索の対象となる伝票１項目のデータを抽出し、伝票データ５の伝票基本データセクション５２以下の各データセクション中に必要な部分のデータを割り当てて問い合わせデータセクション５１とともにクライアントコンピュータ２に送信する。
以上で、伝票に関するデータの追加・変更や検索という基本的な操作を行うためのソフトウェア及びデータベースについての説明は終了する。次に説明するのは、集計表の作成や表示に必要なソフトウェア及びデータベースについてである。最初に、集計の基礎となる集計表定義データベース４６（図３参照）について説明する。
〔集計表定義データベース〕
図３に示すように、集計表定義データベース４６は、集計表の最も基本的な定義を行う集計表名テーブル４６ａ、集計表に含める個々のフィールドの定義を行う集計要素テーブル４６ｂ、集計計算を行うときに各集計表の各フィールドに対して処理ＩＤごとにどのような計算をするかを定義する集計計算要素テーブル４６ｃ、集計計算の対象となるデータの出所がデータベースである場合にデータを抽出するデータベースについての情報を記録する検索対象定義テーブル４６ｄ、集計動作について定義する集計動作定義テーブル４６ｅ、および集計表の各フィールドが表示時にどのような表示特性を有するかを定義する集計表示要素テーブル４６ｆ、集計表定義データベース４６に対する処理要求を行うモジュール的プログラムのクエリＱ１〜Ｑ４を含んでいる。以下、これらのテーブル及びクエリについて、図３７〜図４３を参照しながらより詳細に説明する。
集計表名テーブル４６ａは、集計表毎の基本的な定義を行うテーブルであり、図３７はその例を示したものである。図３７に示した集計表名テーブル４６ａのフィールド中、「集計ＩＤ」フィールドは各集計表を識別するコードを記録し、「集計表名称」フィールドは例示されている「顧客別売上高」、「製品別売上高」等のように各集計表の名称を記録し、「ファイル名」フィールドはこの集計表を記録するデータベースファイル名を記録し、「テーブル名」フィールドはこの集計表を記録するテーブル名を記録し、「実行コンポーネント」フィールドは、この集計表をダブルクリックすることによって他のソフトウェアを実行できる場合に、その実行するコンポーネント名を記録するものである。
「名称Ｐｏｓ」フィールドと「コードＰｏｓ」フィールドはともに、その集計表に対して集計計算をするときに、その集計表が伝票の情報（それが伝票が持つ情報全てであるか一部であるかを問わず）を何らかの基準で分類しその分類ごとの積算を何らかの順番で並べたものである場合において、その基準となるものが集計表内に含まれているときに、集計表内のフィールドのうちどれにあたるかを、左端のフィールドを０番目として数えはじめて何番目にあるかを記録するものである。「名称Ｐｏｓ」フィールドにはその基準となるものを表す名称が左端のフィールドから数えて何番目になるかの数値が記録され、「コードＰｏｓ」フィールドにはその基準となるものを表すコードが左端のフィールドから数えて何番目になるかの数値が記録される。基準となるものが集計表内に含まれていない場合には−１を記録する。集計表が伝票の情報（それが、伝票が持つ情報全てであるか一部であるかを問わず）を単に何らかの順番で並べたものである場合は「名称Ｐｏｓ」フィールドと「コードＰｏｓ」フィールドには−１を記録する。
前者の例としては、売上伝票から作成される顧客別売上高（これは顧客によって分類され積算される。）が挙げられる。顧客別売上高には顧客名が含まれているはずなので顧客名がその顧客別売上高では左端から数えて何番目の欄にあるかを「名称Ｐｏｓ」フィールドに記録する。多くの場合、顧客コードも顧客別売上高にはあるので、そのコードが左端から数えて何番目の欄にあるかを「コードＰｏｓ」フィールドに記録する。また、後者の例としては、受注伝票から作成される納入予定表が挙げられる。納入予定表の場合は、顧客別や製品別に積算することはないので、「名称Ｐｏｓ」フィールドと「コードＰｏｓ」フィールドには−１を記録する。
「コードＰｏｓ」フィールドの値から伝票を集計計算するときにその伝票の情報を何らかの基準で分類したその基準の具体的な値を知ることができる。また、「名称Ｐｏｓ」フィールドの値からはその基準の名称を知ることができる。先の顧客別売上高の例では画面上で選択されている行の顧客コードと顧客名にあたる。前述のダブルクリックしたときに実行するコンポーネントとして伝票検索をするものが選ばれているときに、検索のキーとなることを目的としてこの２つのフィールドから得られた値を渡す。また、別の実行コンポーネントに対してもこれらのデータを渡すことができるが、具体的にどのように利用されるかは実行コンポーネントによる。
また、「表示方法」フィールドはこの集計表の表示方法を定義するもので、その値が１ならばデータすべてを表示することを表し、その値が２ならば月次で抽出されたデータを表示することを表す。「親の伝票ＩＤ」フィールドは、どの伝票に基づいてこの集計表が作成されるかを示すためにその伝票ＩＤ（図９参照）を記録するものである。
図３７で示すテーブルの例で一行目を説明すると、集計ＩＤの１で識別されるのは、「顧客別売上高」という名称の集計表であり、この集計表を記録するデータベースファイル名は「売上顧客別」、この集計表を記録するテーブル名は「顧客別売上」、この集計表がダブルクリックされたときに実行するコンポーネント名は「伝票検索．Ｋｅ」である。「名称Ｐｏｓ」フィールドの値が０、「コードＰｏｓ」の値が１なので、顧客別売上高の集計表の左端にある顧客名フィールドと左端から２番目の顧客コードフィールドの値に基づいて、顧客毎の順番に並べる。また、この集計表は伝票ＩＤが１である「売上伝票」（図９参照）に基づいて作成されるものであり、この集計表の表示方法は、月次で抽出されたデータを表示する。ここまでで、集計表名テーブル４６ａの説明を終了する。
集計要素テーブル４６ｂは、各集計表に含める個々のフィールドの定義を行うためのものであり、図３８はその例を示したものである。図３８に示した集計要素テーブル４６ｂのフィールド中、「集計フィールドＩＤ」フィールドはすべての集計表のフィールドを対象としたときのそれぞれの集計表の各フィールドの識別コードを記録するものであり、当該識別コードは全集計表を通じて一意である。また、「集計ＩＤ」フィールドは図３７で示した集計表名テーブル４６ａで定義されている各集計表を識別するコードを記録し、「フィールド名称」フィールドは集計フィールドＩＤで識別される集計表の各フィールドの名称を記録し、「フィールドタイプ」フィールドはそのフィールドのデータ型（図７の入力コントロール定義テーブル４１ａの「タイプ」フィールドで用いたコードと同じ）を記録する。
続いて、「抽出条件」フィールドは、集計表に集計計算をするとき、集計表の集計対象のレコードを選ぶ際の抽出条件としてこの集計フィールドＩＤのフィールドを加えるか否かを表す値を記録するもので、その値が、Ｔｒｕｅであれば抽出条件として加える、Ｆａｌｓｅであれば抽出条件として加えない、を表す（図３８の集計要素テーブル４６ｂでは２がＴｒｕｅ、１がＦａｌｓｅとなっている。）。「パラメータ名称」フィールドは、この集計フィールドＩＤのフィールドを抽出条件とするときのパラメータ名を記録するものであり、「集計対象」フィールドは、集計表のこのフィールドに対しては、集計計算の時、伝票データを上書きするのではなく、加減算するか否かを表す値を記録するもので、その値がＴｒｕｅであれば加減算する、Ｆａｌｓｅであれば加減算しない、を表す。（図３８の集計要素テーブル４６ｂでは２がＴｒｕｅ、１がＦａｌｓｅとなっている。）「レコード削除の真偽」フィールドは、集計表からレコードを削除するか否かを表す値を記録するもので、その値が、Ｔｒｕｅのときはこの集計フィールドＩＤのフィールドの値が０になったら集計表からレコードを削除する、Ｆａｌｓｅのときは削除しない、ことを表す。（図３８の集計要素テーブル４６ｂでは−１がＴｒｕｅ、０がＦａｌｓｅとなっている。）「ＳＱＬ定義フィールドタイプ」フィールドは、ＳＱＬ定義によりフィールドタイプを表した値を記録するもので、ここに記録される値は、実装時に使用する開発言語やデータベースの操作手法の違いによって同じものを意味する場合でも違う値が入る場合がある。また、このフィールドの値は、「フィールドタイプ」のフィールドの値が意味するものと同じものを意味する値でなくてはならない。「表示用抽出条件」フィールドは、集計表を表示するときに、表示すべきレコードを抽出するが、その抽出条件にこの集計フィールドＩＤのフィールドを加えるか否かを表す値を記録するもので、その値が、Ｔｒｕｅであれば抽出条件として加える、Ｆａｌｓｅであれば抽出条件として加えない、を表す。（図３８の集計要素テーブル４６ｂでは２がＴｒｕｅ、１がＦａｌｓｅとなっている。）
図３８は、集計ＩＤが５である出荷済売上高未計上残高（図３７参照）の集計表の各フィールドについて定義している例であり、この出荷済売上高未計上残高の集計表の例は図４２に示してある。図３８の集計要素テーブル４６ｂの例の一行目で定義されているのは、集計ＩＤが５である出荷済売上高未計上残高の集計フィールドＩＤが３４である出荷伝票のフィールドは、「フィールドタイプ」の値が７であり、「抽出条件」の値はＴｒｕｅであるので集計表に集計計算をするときにこのフィールドは抽出条件とすることができ、抽出条件とするときの「パラメータ名称」はＰ１であり、「集計対象」の値がＦａｌｓｅであるので集計計算のとき伝票データを加減算の対象としない、「レコード削除の真偽」の値はＦａｌｓｅなのでレコード削除の対象とはなっていない、「ＳＱＬ定義フィールドタイプ」の値は「ｄｏｕｂｌｅ」であり、「表示用抽出条件」の値はＦａｌｓｅであるので集計表を表示するときにこのフィールドは表示用の抽出条件に加えない、ということになる。
集計計算要素テーブル４６ｃは、集計計算を行うときに各集計表の各フィールドに対して処理ＩＤ毎にどのような計算をするかを定義する。図３９は、その集計計算要素テーブル４６ｃの例を示したものである。図３９に示すフィールド中、「集計計算要素ＩＤ」フィールドは、同一の行で定義されている処理ＩＤの処理が、同一の行で定義されている集計フィールドＩＤに対して、伝票のなかのどのデータを集計するかを一意に識別するコードを記録するものである。ここで、集計計算要素テーブル４６ｃの「集計フィールドＩＤ」について、補足的に説明すると、集計フィールドＩＤは全集計表について一意であるから、処理ＩＤと集計フィールドＩＤで特定される組合せはどの集計表のものであるかは集計ＩＤを使用して示さなくてもわかるので、集計計算要素テーブル４６ｃに集計ＩＤを記録するフィールドが含まれているということは、テーブルの構造に冗長性があることになる。しかし、このテーブル中、ある集計表に関するレコード全てを取り出して操作したい時などは（例えばある集計表に関するデータをすべて削除したい時）、もし集計計算要素テーブル４６ｃに集計ＩＤのデータを持たせていないならば、あらかじめ集計要素テーブル４６ｂからどのレコードがどの集計ＩＤにかかわるものかを知らなくてはならない。一方、本実施の形態のように集計ＩＤがテーブル内にあれば、単純な操作で目的のレコードを得ることができる。要するにテーブルから冗長性を排除すればプログラムに煩雑性が生じ、逆にプログラムの煩雑性を除く為にはテーブルの構造に冗長性を出さざるを得なくなる。このソフトウエアの実装にあたっては、プログラムの煩雑性を減じる方が、テーブル構造の冗長性を除くよりも優先順位が高いと判断して集計計算要素テーブル４６ｃに集計ＩＤを加えたものである。
伝票データ中、どのデータであるかは、それより右側に表示されているフィールドで定義する。「集計計算の有無」フィールドの値がＦａｌｓｅであれば、この集計フィールドＩＤで特定されるフィールドには集計計算をせず、「集計計算の有無」のフィールドの値がＴｒｕｅであれば右側に表示されたフィールドで指定される伝票のデータを集計フィールドＩＤのフィールドに対して集計する（図３９の集計計算要素テーブル４６ｃでは−１がＴｒｕｅ、０がＦａｌｓｅとなっている。）。
図３９に示すフィールド中、「データタイプ」フィールドは、「集計フィールドＩＤ」フィールドに対して集計計算をするデータの出所を表す値を記録するもので、その値が１ならば処理対象データの値をコードと解釈して対応するデータベースを検索し、そのデータベースの指定されたフィールド(後述する検索対象定義テーブル４６ｄで定義される)の値を集計対象データとし、その値が２ならば処理対象データの値をそのまま集計対象のデータとする。
「データ名称」フィールドは処理対象データが図２０および図２１で示す伝票データの構造中、どのデータセクションに属するかを示すためにそのデータセクションの名称を記録するもので、「伝票基本」、「ヘッダー項目」、「ヘッダー未登録項目」、「本体項目」、「本体項目備考」、「関連伝票」、「属性」のいずれかの値が記録される。「項目の順番」フィールドは、「データ名称」フィールドの値が「ヘッダー項目」である場合に何番目のヘッダー項目であるかを記録するものである。なお、図３９の例で「項目の順番」フィールドの値がいずれも０であるのは、この例ではデータ名称にヘッダー項目がないからである。「抽出データ」フィールドは、「データ名称」フィールドの値が「伝票基本」、「本体項目」、「関連伝票」の場合は、それぞれのデータセクションに属するどのエリアからデータを取り出すかを記録するものである。「データ名称」フィールドの値が「属性」の場合は、「項目の順番」フィールドで指定された順番の属性データセクションに属するどのエリアからデータを取り出すかを記録するものである。「関連伝票ＩＤ」フィールドは、「データ名称」フィールドの値が「関連伝票」の場合に、その関連伝票の伝票ＩＤを記録するものである。
いま、図３９で示す集計計算要素テーブル４６ｃの例の１行目を説明すると、集計計算要素ＩＤのコード１８４で識別される処理は、処理ＩＤが８である「受注参照出荷」（図１１参照）の処理が行われるとき、集計ＩＤが５である集計表「出荷済売上高末計上残高」の集計フィールドＩＤが３４である「出荷伝票」欄に対して、伝票データ５のデータ中、本体項目データセクションの伝票番号のエリアに記録されたデータを集計する、ということがわかる。
検索対象定義テーブル４６ｄは、集計計算要素テーブル４６ｃの「データタイプ」フィールドの値が１のときに、検索対象となるデータベースについて定義するものである。図４０は、検索対象定義テーブル４６ｄの例を示したものであり、集計計算要素ＩＤのフィールドには、図３９に示す集計計算要素テーブル４６ｃで定義されているＩＤ中、データタイプのフィールドの値が１である集計計算要素ＩＤが記録され、「検索対象ファイル名」フィールドは検索対象となるデータベースファイル名を記録し、「テーブル名」フィールドは、検索の対象となるテーブル名を記録する。「インデックス名」フィールドは、検索に使用するインデックス名を記録し、インデックスを使用しない場合は空文字列を記録する。また、「フィールド名」フィールドは検索の対象となるテーブルのフィールド中データを取り出すフィールド名を記録するものである。
いま、図４０に示す検索対象定義テーブル４６ｄの例を説明すると、集計計算要素ＩＤが１８８の処理において、検索の対象となるファイル名は「\body」であり、そのテーブル名は「品目コードテーブル」（図１３参照）、検索に使用するインデックス名は「code Order 」、品目コードテーブルのフィールド中データを取り出すのは「名称」フィールドからである、となる。
集計動作定義テーブル４６ｅは、「処理ＩＤ」のフィールドで特定される処理ＩＤの処理が行われる場合の、「集計ＩＤ」フィールドで特定される集計ＩＤの集計表に対する集計計算でのデータの取扱について規定する。図４１は、集計動作定義テーブル４６ｅの例を示したものであり、「処理順番」フィールドは「集計ＩＤ」フィールドの値と「処理ＩＤ」フィールドの値が同じ組合せが複数ある場合の処理の順番を規定するものであり、「処理対象」フィールドは、集計計算を行うときに、クライアントコンピュータ２から送信されたデータを処理対象とするのか、あるいは伝票管理データベース４に記録されていたデータを処理対象とするのか、を示す値を記録するものである。その値が１ならばクライアントコンピュータ２から送信されたデータであり、その値が２ならば伝票管理データベース４に記録されていたデータである。「データ処理動作」フィールドは、処理対象のデータを加算するか、減算するか、上書きするか、を示す値を記録するもので、その値が１ならば加算、その値が−１ならば減算、その値が２ならば上書きである。例えば、図４１に図示した集計動作定義テーブル４６ｅの例の１行目は、処理ＩＤが３である「出荷参照売上」の処理を行うときの集計表「出荷済売上高末計上残高」への集計計算は、クライアントコンピュータ２から送信されたデータを処理対象とするもので、処理対象のデータを減算する、ということになる。
図４３に示す集計表示要素テーブル４６ｆは、集計表の各フィールドが表示時に、どのような表示特性を有するかを規定する。このテーブルに含めるフィールドは集計表の表示プログラムの構成によって変化するので、テーブルの構造は、「集計ＩＤ」フィールド、「集計フィールドＩＤ」フィールド、表形式で集計表を表示するときのフィールドを左側から右側へ並べる順番を表す「FieldOrder」フィールド（このフィールドの値は０から始まる）、集計表に含まれる各レコードを並べる時に、そのレコードが指し示すフィールドの値により並べかえるのか否かを表す「DoSort」フィールド（このフィールドの値がＴｒｕｅならば、そのレコードが指し示すフィールドの値によって並び換える）、並び換えが行われるときに依存するフィールドが複数ある場合の優先順位を示す「SortPriority」フィールド（このフィールドの値は１から始まる）、並べ換えるときに、昇順か降順かを示す「ASCorDESC」フィールド（このフィールの値が０ならば降順、−１ならば昇順）の６つのフィールドが必須であり、その他、表示用プログラムの必要性から他のフィールドを付加することもできる。図４３に示した例では、上述した６つのフィールドに加え、表示の有無を規定する「IsThisVisible」フィールドやフォーマットの有無を規定する「DoFormat」等８つのフィールドが付加されている。
以上で、集計の基礎となる集計表定義データベース４６に含まれる各テーブルについての説明は終了する。この集計表定義データベース４６の各テーブルに定義されたデータに従って、図３に示す集計表データベース４７に含まれる集計ＩＤ毎の集計データを記録する各集計表のテーブル（図３中、これらの集計表テーブルを代表して、集計表テーブル４７ｘとして表示している）を生成することになる。
次に、集計表定義データベース４６（図１参照）には含まれている、集計表定義データベース４６に対する処理要求を行うモジュール的プログラム（クエリ）、すなわち、クエリＱ１からＱ４（図３及び図４４参照）について説明する。なお、クエリＱ１からＱ４は、ＤＢＭＳ（Database Management System データベースを管理するための仕組みを提供するソフトウェア）の持つユーザーインターフェースを介して作成することもできるし（つまり人間がキーボードから打ち込む）、ソフトウェアがＤＢＭＳにそのＤＢＭＳが定める手法に従って指示を与えることにより作成することもできる。
クエリＱ１は、伝票データに含まれる処理ＩＤについて、処理ＩＤごとにどのような集計動作をするか抽出するクエリである。具体的には、集計動作定義テーブル４６ｅの「処理ＩＤ」のフィールド中、伝票データ中の処理ＩＤと一致する処理ＩＤのレコードを検索し、集計ＩＤの昇順、処理順番の昇順に並べた結果を得る。すなわち、伝票データで指定された処理ＩＤに従って実行される集計は、どの集計表の集計を行うのか、集計計算を行うときの処理対象とするデータは何か、また処理の順番はどう行うか、のデータを取得する。
クエリＱ２は、伝票データに含まれる処理ＩＤに基づいて行われる集計動作のなかで、指定した集計ＩＤで特定される集計表に対する動作のみを抽出するクエリである。具体的には、集計動作定義テーブル４６ｅの「処理ＩＤ」及び「集計ＩＤ」のフィールド中、伝票データ中の処理ＩＤ及び指定した集計ＩＤと一致するレコードを検索し、処理順番の昇順に並べた結果を取得する。
クエリＱ３は、指定した処理ＩＤを含む伝票計上処理が、その伝票のデータを、指定した集計ＩＤで特定される集計表に対して集計計算を行うとき、どのように計算するかを示す一連のレコードを得るクエリである。具体的には、集計要素テーブル４６ｂの「集計フィールドＩＤ」フィールドと集計計算要素テーブル４６ｃの「集計フィールドＩＤ」フィールドに同じ値を持つレコード同士を１つのレコードにまとめる（尚、この作業を後述する作業と区別するため、便宜的に１次結合と呼ぶ。）。集計要素テーブル４６ｂでは複数のレコードがそれぞれの「集計フィールドＩＤ」フィールドに同一の値を持つことは、定義により無く、また必ず何らかの値を保持している。一方、集計計算要素テーブル４６ｃでは複数のレコードが「集計フィールドＩＤ」フィールドに同一の値を持つことがあり、また、必ず値を保持している上に、その値は必ず集計要素テーブル４６ｂのいずれかのレコードが持つ「集計フィールドＩＤ」フィールドの値と一致する。１次結合の結果、集計計算要素テーブル４６ｃに含まれているのと同数のレコードが得られる。
次に、１次結合で得られたレコード各々について、集計計算要素テーブル４６ｃに由来する「集計計算要素ＩＤ」フィールドに記録されている値と同じ値を、「集計計算要素ＩＤ」フィールドに持つ検索対象定義テーブル４６ｄのレコードを１つにまとめる（この作業を便宜的に２次結合と呼ぶ。）。このとき、検索対象定義テーブル４６ｄには、１次結合の結果得られたレコードに対するレコードが必ずあるわけではない。対応するレコードが無い場合には、値を持たない空白のレコードを作成し、それをまとめる。従って２次結合の結果得られるレコードには、集計要素テーブル４６ｂ、集計計算要素テーブル４６ｃ、検索対象定義テーブル４６ｄのそれぞれのレコードに含まれるフィールドがすべて含まれることになる（ただし、前述のごとく、それらのフィールドのすべてが必ず値を持っているわけではない。）。
さらに、２次結合で得られたレコードの中から、集計要素テーブル４６ｂに由来する「集計ＩＤ」フィールドに指定された値を持ち、且つ集計計算要素テーブル４６ｃに由来する「処理ＩＤ」フィールドに指定された値を持つレコードのみを抽出する。以上の作業がクエリＱ３の作業である。
クエリＱ４は、指定した集計ＩＤで特定される集計表を表示するときに、その集計表に含まれる各フィールドがどのような表示特性をもっているかを示す一連のレコードを得るクエリである。具体的には、集計要素テーブル４６ｂの「集計フィールドＩＤ」フィールドと集計表示テーブル４６ｆの「集計フィールドＩＤ」フィールドに同じ値を持つレコードを１つにする。集計要素テーブル４６ｂと集計表示テーブル４６ｆにおいては共に「集計フィールドＩＤ」に記録される値は一意であるので、この作業の結果得られるレコード数は、集計要素テーブル４６ｂのレコードの数と同じである（この数は、集計表示テーブル４６ｆのレコード数でもある。）。これら複数のレコードから、「集計ＩＤ」フィールドに指定された値を持つレコードのみを抽出する（この場合、「集計ＩＤ」フィールドは集計要素テーブル４６ｂに由来するものと、集計表示テ−ブル４６ｆに由来するものの２つがあるが、同じ結果が得られるので、どちらを選んでも構わない。）。この作業の結果得られるレコードの数は、指定した集計ＩＤを持つ集計表の表示項目数と同じになる。そしてこの抽出された複数のレコードを「フィールド順番」フィールドに記録されている値に基づき昇順に並べ替える。以上がクエリＱ４の作業である。
次に、集計表データベースに保存するクエリＱ５〜Ｑ１０（図４４参照）の説明を行うが、その前提として、クエリＱ１〜Ｑ４までと、クエリＱ５〜Ｑ１０までは性質が違うので、その点を予め説明する。
Ｑ１からＱ４までは、集計表定義データベース４６（図３参照）の各種テーブルに記録されているデータに対して操作を行うものである。集計表定義データベース４６の内容はユーザー（この説明でいうユーザーとはこのソフトの利用者のことで以下同様。）によって異なるから、クエリＱ１からＱ４のクエリの実行結果も異なる。しかし、クエリＱ１からＱ４のクエリそのものは、あらかじめ用意されているので、ユーザーごとに異なるわけではなく、同一である。一方、クエリＱ５からＱ１０は、クエリＱ１からＱ４の結果に基づいて生成される（この生成は基本設定管理ソフトウエア３７が行う。）。クエリＱ１からＱ４の結果はユーザーによって異なるので、この結果に基づいて生成されるクエリＱ５からＱ１０もユーザーによって異なる。しかし、クエリＱ５からＱ１０をどのように生成するかは、ユーザーごとに異なるわけではなく基本設定ソフトウエア３７に規定されている。従って、後段では、この生成物であるクエリＱ５からＱ１０の内容についてではなく、その生成法についての規定に関して説明することになる。
なお、繰り返しになるが、生成されたクエリはデータベースにストアドプロシージャとして保存される。クエリＱ１からＱ４は集計表定義データベース４６保存され、クエリＱ５からＱ１０は、Ｑ１からＱ４の結果に基づいて生成され集計表データベース４７（図３参照）に保存される。
なお、この「クエリＱ１からＱ４の結果に基づいて」という表現は、必ずしも「クエリＱ１からＱ４の結果の全てに基づく」というわけでははく、「クエリＱ１からＱ４の結果の少なくとも１つに基づいて」という意味である。
次に集計表データベース４７に保存するクエリＱ５からＱ１０までの生成について説明する。ここでクエリの生成と言ったが、最終的には、そのクエリをストアドプロシージャとして集計表データベース４７に保存する。クエリをストアドプロシージャとして保存する方法は、使用するＤＢＭＳによって異なるので、ここではクエリであるＳＱＬ文の生成とどのようなＤＢＭＳでもストアドプロシージャの保存時に要求するであろうパラメータリストの生成とクエリの名称を表す文字列の生成について説明する。
クエリＱ５は、クエリＱ４の結果に基づいて生成されるクエリであり、その目的は集計表テーブル４７ｘ（図３参照）から画面に表示するレコードを抽出することにある。つまりＱ５はＳＱＬのSELECT文であり、次のような構成になっている。
「SELECT fieldlist FROM tablename WHERE criteria ORDER BY fieldlist」
前述のごとく、クエリＱ５は、クエリＱ４の結果（クエリＱ５の説明においては、これを便宜的に結果のレコードセットと呼ぶ）に基づき生成されるのであるが、上記の下線を施した部分が、クエリＱ４の結果の変化に応じて変化する。上記のSELECT文は４つの部分、すなわち、SELECT句、FROM句、WHERE句、ORDER BY句に分けられるので、これら４つの句とパラメータリストとクエリの名称の生成について以下に説明する。
SELECT句の構成は、集計表テーブル４７ｘに記録されているフィールドのうち、画面上に表示するフィールドを選び、文字列データを作成してfieldlistとすることで行われる。その選択は、クエリＱ４の結果のレコードセットの「フィールド名称」フィールドに値があれば、その値をfieldlistである文字列データにカンマで区切って追加する。図３８の集計要素テーブル４６ｂと図４３の集計表テーブル４６ｆの例に基づくと、この作業で生成されるSELECT句は次のようになる。
「SELECT 出荷伝票、出荷項目、受注伝票、受注項目、品名、内容、数量、単位、単価、金額、消費税、合計」
次にFROM句についてであるが、クエリＱ５は、元々集計表テーブル４７ｘからデータを抽出するのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからその集計ＩＤの値を持つレコードを抽出し、そのレコードの「テーブル名」フィールドの値を得ればよい。図３７で示した集計表名テーブル４６ａの例では、クエリＱ４の結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、図３７に示す例の集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。従って図３７の例に基づいたFROM句は次のようになる。
「FROM 出荷済売上」
次にWHERE句の生成について説明する。WHERE句は、クエリＱ４の結果のレコードセットのレコードのうち、「表示用抽出条件」フィールドの値がＴｒｕｅのものだけを参照して生成される。つまり結果のレコードセットに含まれるレコードすべてについて、「表示用抽出条件」フィールドの値を調べ、それがＴｒｕｅであればcriteriaである文字列に以下の要領で生成される文字列を加える。
そのレコードの「フィールド名称」フィールドの値 ＝
そのレコードの「パラメータ名称」フィールドの値
「表示用抽出条件」フィールドの値がＴｒｕｅになるレコードが複数あれば上記の要領で生成された文字列を「AND」という文字列でつなぐ。
図３８に示した集計要素テーブル４６ｂには「表示用抽出条件」フィールドの値がＴｒｕｅのものがないので、仮に、集計フィールドＩＤの値が３４と３５のレコードがＴｒｕｅであるとすると以下のようなWHERE句が生成されることになる。
「WHERE 出荷伝票＝Ｐ１ AND 出荷項目＝Ｐ２」
図３８の例のように「表示用抽出条件」フィールドの値がすべてＦａｌｓｅである場合は、WHERE句は生成されず、従って最終的に生成されるSELECT文にはWHERE句は含まれない。
次にORDER BY句について説明する。
結果のレコードセットから「DoSort」フィールドの値がＴｒｕｅのレコードだけを抽出し、「SortPriority」フィールドの値に従って昇順に並べた、絞り込んだレコードセットを作成する。このとき、「DoSort」フィールドの値がＴｒｕｅのレコードがなければ、ORDER BY句は生成されず、最終的に作成されるSELECT文にORDER BY句は含まれない。この絞り込んだレコードセットの各レコードの「ASCorDESC」フィールドの値を調べ、その値が０ならば「DESC」、−１ならば「ASC」という文字列を用意し、そのレコードの「フィールド名称」フィールドの値の後に付加する文字列を作成し、これをfieldlistとする。絞り込んだレコードセットに複数のレコードが含まれる場合は、作成した文字列をカンマでつなぐ。
図３８の集計要素テーブル４６ｂの例と図４３の集計表示テーブル４６ｆの例に基づくと、次のようなORDER BY句が得られる。
「ORDER BY 出荷伝票 DESC、出荷項目 ASC」
次にパラメータリストについて説明する。パラメータリストは前記WHERE句で使用されるパラメータに具体的な値を与える場合に備えてパラメータの名称、データ型等をＤＢＭＳに与えるために作成するものである。必要とされるパラメータリストの内容はＤＢＭＳによって異なるが、パラメータ名とデータ型はいずれのＤＢＭＳでも必須と言ってよく、更にデータの方向（そのパラメータはクエリに値を与えるためのものか、クエリの結果としての値を受取るためのものか、の区別）を要求するものもある。本実施の形態においては、クエリＱ５からクエリＱ１０のパラメータはすべてクエリに値を与えるためのものであるから、データの方向を示す必要があるときはその旨を意味する指示をすればよい。
クエリＱ５のパラメータリストの作成法は以下のようになる。
クエリＱ４の結果のレコードセットの各レコードの「表示用抽出条件」の値を調べ、その値がＴｒｕｅであれば、「パラメータ名称」フィールドの値をパラメータ名とし、「ＳＱＬ定義フィールドタイプ」フィールドの値をパラメータの型としてＤＢＭＳが要求する形式に整える。例えば、あるＤＢＭＳが要求する形式に従い、図３８の集計要素テーブル４６ｂの「集計フィールドＩＤ」フィールドの値が３４及び３５のレコードの「表示用抽出条件」フィールドの値がＴｒｕｅであると仮定するならば、次のようなパラメータリストが作成されることになる。
「PARAMETERS Ｐ１ double，Ｐ２ double」
次にクエリの名称の生成方法について説明する。クエリＱ５の名称は、いまクエリＱ５の生成にかかわっている集計ＩＤとは別の集計ＩＤを持つ集計表テーブル４７ｘにかかわるＱ５やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤを文字列化し、「５−Ｑ５」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたSELECT句、FROM句、WHERE句、ORDER BY句を１つに繋ぎあわせるとSELECT文が得られ、このSELECT文とパラメータリストと名称を、使用するＤＢＭＳに対してそれが規定する手法に従って与えるとＱ５のクエリがストアドプロシージャとして集計表データベース４７に保存される。以上でＱ５の作成手法につぃての説明を終える。
次にクエリＱ６の生成について説明する。クエリＱ６は、集計表テーブル４７ｘに対して集計計算を行うとき、これから集計しようとしているデータを集計表テーブル４７ｘに対して新規に追加すべきか、すでにあるデータに加算または減算すべきかを判断するために、集計表テーブル４７ｘにレコードがあるか否かを確かめるクエリである。クエリＱ６の生成に関してまず行うべきことは、クエリＱ６の生成が必要であるか否かの判断である。この判断は、クエリＱ３に集計表のＩＤと処理ＩＤをパラメータとして与えて実行した時に、その実行結果としてパラメータとして与えた処理ＩＤと集計ＩＤの組み合わせのときにどのような集計計算を行うかを示す一連のレコードが得られるか否かで行う。この一連のレコードをここでは便宜的に結果のレコードセットと呼ぶ。（クエリＱ５の説明においても結果のレコードセットという用語を用いたが、クエリＱ５の場合はクエリＱ４の実行結果に対してであり、今ここで言う結果のレコードセットはクエリＱ３の実行結果に対してであるので、別のものを指していることに注意されたい。）仮に、クエリＱ３を実行した結果として１つもレコードが得られなければ、指定した処理ＩＤの値を持つ処理は、指定した集計ＩＤの値を持つ集計表に集計計算を行わないということなので、クエリＱ６の生成は不要となる。なお、クエリＱ６は単に集計表テーブル４７ｘから後述するcriteriaで特定されるレコードの任意のフィールドを抽出するだけのクエリであるから、どのような集計ＩＤと処理ＩＤの組み合わせであっても同じものになる。したがって、集計ＩＤと処理ＩＤの組み合わせのうち最初に結果のレコードセットが得られた組み合わせについてのみクエリＱ６を生成する。以下の説明はクエリＱ６の生成が必要となる場合のものである。
前述のごとく、クエリＱ６は集計表テーブル４７ｘにすでにデータがあるか否かを判断するためのものであるが、その判断は特定のレコードを集計表テーブル４７ｘから抽出できるか否かで行う。つまり抽出できるのであれば、すでにデータはあるのであり、抽出できなければ、データはない。要するにクエリＱ６はSELECT文であり、その構成は以下のようになっている。
「SELECT field FROM table WHERE criteria」
クエリＱ６は、クエリＱ３を実行した結果のレコードセットに基づき生成されるのであるが、１つしか生成しないので、その結果のレコードセットの最初のレコードに基づき、上記の下線を施した部分を構成する。
以下SELECT句、FROM句、WHERE句、パラメータリスト、クエリの名称の生成手法について順次説明する。
まず、クエリＱ６のSELECT句について説明する。クエリＱ６の目的は、集計表に特定データがあるか否かを知ることで、その判断のためにレコードを抽出できるか否かという点に注目する。つまり、得られたレコードの値を利用しているわけではない。従ってSELECT句で指定するフィールドは、その集計表が持つフィールドすべてを指定する必要はなく、また、何か特定のフィールドである必要もない。従ってSELECT句に指定するフィールドは結果のレコードセットの最初のレコードの「フィールド名称」フィールドの値とする。図３８の集計要素テーブル４６ｂの例に従い、結果のレコードセットの最初のレコードが「集計フィールドＩＤ」フィールドの値が３４のレコードであるとするならば、次のようなSELECT句が得られることになる。
「SELECT 出荷伝票」
次にFROM句について説明する。クエリＱ６は、元々集計表テーブル４７ｘからデータを抽出するのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからそのその集計ＩＤの値を持つレコードを抽出し、そのレコードの「デーブル名」フィールドの値を得れば良い。この説明のための例（図３７参照）では結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。従って図３７の例に基づいたFROM句は次のようになる。
「FROM 出荷済売上」
次にWHERE句について説明する。WHERE句は、結果のレコードセットのレコードのうち、「集計計算の有無」フィールドがＴｒｕｅであるもののなかで「抽出条件」フィールドの値がＴｒｕｅのものだけを参照して生成される。つまり結果のレコードセットに含まれるレコードすべてについて、「集計計算の有無」フィールドがＴｒｕｅであるものの「抽出条件」フィールドの値を調べ、それがＴｒｕｅであればcriteriaである文字列に以下の要領で生成される文字列を加える。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「パラメータ名称」フィールドの値
「抽出条件」フィールドの値がＴｒｕｅになるレコードが複数あれば上記の要領で生成された文字列を「AND」という文字列でつなぐ。
図３８に示した集計要素テーブル４６ｂには「抽出条件」フィールドの値がＴｒｕｅのものは、集計フィールドＩＤが３４と３５のレコードであるので、以下のようなWHERE句が生成されることになる。
「WHERE 出荷伝票＝Ｐ１ AND 出荷項目＝Ｐ２」
次にパラメータリストについて説明する。パラメータリストは前記WHERE句で使用されるパラメータに具体的な値を与える場合に備えてパラメータの名称、データ型等をＤＢＭＳに与えるために作成するものである。パラメータリストの作成法は以下のようになる。
前記の結果のレコードセットの「集計計算の有無」フィールドがＴｒｕｅであるものの各レコードの「抽出条件」の値を調べ、その値がＴｒｕｅであれば、「パラメータ名称」フィールドの値をパラメータ名とし「ＳＱＬ定義フィールドタイプ」フィールドの値をパラメータの型としてＤＢＭＳが要求する形式に整える。例えば、あるＤＢＭＳが要求する形式に従い、図３８の集計要素テーブル４６ｂの例に従うならば、次のようなパラメータリストが作成されることになる。
「PARAMETERS Ｐ１ double，Ｐ２ double」
次にクエリの名称の生成方法について説明する。クエリＱ６の名称は、いまクエリＱ６の生成にかかわっている集計ＩＤとは別の集計ＩＤを持つ集計表テーブル４７ｘにかかわるクエリＱ６やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤを文字列化し、「５−Ｑ６」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたSELECT句、FROM句、WHERE句を１つに繋ぎあわせるとSELECT文が得られ、このSELECT文とパラメータリストと名称を使用するＤＢＭＳに対してそれが規定する手法に従って与えるとクエリＱ６がストアドプロシージャとして集計表データベース４７に保存される。以上でクエリＱ６の作成手法についての説明を終える。
次にクエリＱ７の生成について説明する。
クエリＱ７は、集計表テーブル４７ｘから指定された条件に合致するレコードを削除するクエリである。クエリＱ７の生成に関してまず行うべきことは、クエリＱ７の生成が必要であるか否かの判断である。この判断は、クエリＱ３に集計表のＩＤと処理ＩＤをパラメータとして与えて実行した時に、その実行結果としてパラメータとして与えた処理ＩＤと集計ＩＤの組み合わせのときにどのような集計計算を行うかを示す一連のレコードが得られるか否かで行う。この一連のレコードをここでは便宜的に結果のレコードセットと呼ぶ。仮に、クエリＱ３を実行した結果として１つもレコードが得られなければ、指定した処理ＩＤの値を持つ処理は、指定した集計ＩＤの値を持つ集計表に集計計算を行わないということなので、クエリＱ７の生成は不要となる。なお、クエリＱ７は単に集計表テーブル４７ｘから後述するcriteriaで特定されるレコードを削除するだけのクエリであるから、どのような集計ＩＤと処理ＩＤの組み合わせであっても同じものになる。したがって、集計ＩＤと処理ＩＤの組合せのうち、最初に結果のレコードセットが得られた組合せについてのみクエリＱ７を生成する。以下の説明はクエリＱ７の生成が必要となる場合のものである。
前述のごとくクエリＱ７はレコードを削除するクエリである。つまりクエリＱ７はＳＱＬのDELETE文であり、以下のような構成になっている。
「DELETE FROM tablename WHERE criteria」
Ｑ７のクエリは、クエリＱ３を実行した結果求められたレコードセットに基づき生成されるのであるが、１つしか生成しないので、結果のレコードセットの最初のレコードに基づき、上記の下線を施した部分を構成する。
以下、DELETE FROM 句、WHERE句、クエリの名称の生成手法について順次説明する。
まず、クエリＱ７のDELETE FROM 句について説明する。クエリＱ７は、元々集計表テーブル４７ｘからデータを削除するのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからその集計ＩＤの値を持つレコードを抽出し、そのレコードの「デーブル名」フィールドの値を得ればよい。この説明に用いる例では結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、図３７に示した例の集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。従って図３７の例に基づいたDELETE FROM 句は次のようになる。
「DELETE FROM 出荷済売上」
次にWHERE句について説明する。WHERE句は、クエリＱ３を実行した結果求めたレコードセットのレコードのうち「集計計算の有無」フィールドがＴｒｕｅであるレコードのなかで、「レコード削除の真偽」フィールドの値がＴｒｕｅ（図３８の例では−１がＴｒｕｅ、０がＦａｌｓｅとなっている）のものだけを参照して生成される。つまり結果のレコードセットに含まれるレコードすべてについて、「集計計算の有無」フィールドがＴｒｕｅであるレコードの「レコード削除の真偽」フィールドの値を調べ、それがＴｒｕｅであればcreteriaである文字列に以下の要領で生成される文字列を加える。
そのレコードの「フィールド名称」フィールドの値＝０
「レコード削除の真偽」フィールドの値がＴｒｕｅになるレコードが複数あれば上記の要領で生成された文字列を「OR」という文字列でつなぐ。図３８に示した集計要素テーブル４６ｂには「レコード削除の真偽」フィールドの値がＴｒｕｅのものは、集計フィールドＩＤが４０のレコードであるので、以下のようなWHERE句が生成されることになる。
「WHERE 数量＝０」
上記の例では「数量＝０」として、数量が０のときにレコードが削除されることを指定したが、集計表の持つ意味によっては「数量＜＝０」として、数量が０以下の場合に削除すべき場合もある。また、本発明の実施形態においては、数値はすべて倍精度型で扱うとしたので２進数による計算の誤差のため、「数量」フィールドの値が０.０にならず、「数量＝０」が成立しないときもある。これが予想されるときは０と比較される数値を比較前に丸める等の前処理が必要になる場合もある。
次にパラメータリストについてであるが、クエリＱ７においてはパラメータリストは必要ない。これはクエリの性質上パラメータの値は常に０に固定されているからである。
次にクエリの名称の生成方法について説明する。クエリＱ７の名称は、いまクエリＱ７の生成にかかわっている集計ＩＤとは別の集計ＩＤを持つ集計表テーブル４７ｘにかかわるＱ７やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤを文字列化し、「５−Ｑ７」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたDELETE FROM句、WHERE句を１つに繋ぎあわせるとDELETE文が得られ、このDELETE文と名称を使用するＤＢＭＳに対してそれが規定する手法に従って与えるとクエリＱ７がストアドプロシージャとして集計表データベース４７に保存される。以上でクエリＱ７の作成手法についての説明を終える。
次にクエリＱ８の生成について説明する。
クエリＱ８は、集計表テーブル４７ｘに新たにレコードを追加するクエリである。クエリＱ８の生成に関してまず行うべきことは、クエリＱ８の生成が必要であるか否かの判断である。この判断は、クエリＱ３に集計表のＩＤと処理ＩＤをパラメータとして与えて実行した時に、その実行結果としてパラメータとして与えた処理ＩＤと集計ＩＤの組み合わせのときにどのような集計計算を行うかを示す一連のレコードが得られるか否かで行う。この一連のレコードをここでは便宜的に結果のレコードセットと呼ぶ。仮に、Ｑ３を実行した結果として１つもレコードが得られなければ、指定した処理ＩＤの値を持つ処理は、指定した集計ＩＤの値を持つ集計表に集計計算を行わないということなので、クエリＱ８の生成は不要となる。一方、レコードが得られた場合であるが、集計ＩＤが同一であっても処理ＩＤが異なれば集計計算の対象となる伝票データの構成が異なるので、必ずクエリＱ８を生成する。つまり、レコードが得られた集計ＩＤと処理ＩＤの組み合わせごとに、クエリＱ８を生成しなくてはならない。以下の説明はクエリＱ８の生成が必要となる場合のものである。
前述のごとくクエリＱ８はレコードを追加するクエリである。つまりクエリＱ８はＳＱＬのINSERT文であり、以下のような構成になっている。
「INSERT INTO tablename (fieldlist) VALUES (values)」
クエリＱ８は、結果のレコードセットに基づき生成されるのであるが、上記の下線を施した部分が、結果のレコードセットの変化に応じて変化する。
以下、INSERT INTO句、VALUES句、パラメータリスト、クエリの名称の生成手法について順次説明する。
まず、INSERT INTO句のtablenameであるが、クエリＱ８は、元々集計表テーブル４７ｘにデータを追加するのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからそのその集計ＩＤの値を持つレコードを抽出し、そのレコードの「デーブル名」フィールドの値を得ればよい。この説明で用いる例では結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、図３７で示した例の集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。次にfieldlistであるが、これは、結果のレコードセットに含まれるレコードすべてについて、「集計計算の有無」フィールドがＴｒｕｅであるもののうち「パラメータ名称」フィールドに値が記録されているレコードの「フィールド名称」フィールドの値をカンマで区切って列記すればよい。従って集計ＩＤ＝５のときのINSERT INTO 句は次のようになる。
「INSERT INTO 出荷済売上 (出荷伝票，出荷項目，受注伝票，受注項目，品名，内容，数量，単位，単価，金額，消費税)」
次にVALUES句について説明する。valuesには、前記のfieldlistに列記したフィールドに入力する値を列記するのであるが、ここではパラメータを列記する。つまり結果のレコードセットに含まれるレコードすべてについて、「集計計算の有無」フィールドがＴｒｕｅであるものの「パラメータ名称」フィールドの値を調べ、値があればその値をカンマで区切って列記すればよい。従って集計ＩＤ＝５のときのVALUES句は次のようになる。
「VALUES (Ｐ１，Ｐ２，Ｐ３，Ｐ４，Ｐ５，Ｐ６，Ｐ７，Ｐ８，Ｐ９，Ｐ１０，Ｐ１１)」
次にパラメータリストについて説明する。パラメータリストは前記VALUES句で使用されるパラメータに具体的な値を与える場合に備えてパラメータの名称、データ型等をＤＢＭＳに与えるために作成するものである。
パラメータリストの作成法は以下のようになる。
前記の結果のレコードセットの各レコードの「集計計算の有無」フィールドがＴｒｕｅであるものの「パラメータ名称」フィールドの値をパラメータ名とし「ＳＱＬ定義フィールドタイプ」フィールドの値をパラメータの型としてＤＢＭＳが要求する形式に整える。例えば、あるＤＢＭＳが要求する形式に従い、図３８の集計要素テーブル４６ｂの例に従うならば、次のようなパラメータリストが作成されることになる。
「PARAMETERS Ｐ１ double，Ｐ２ double，Ｐ３ double，Ｐ４ double， Ｐ５ string，Ｐ６ string，Ｐ７ double，Ｐ８ string，Ｐ９ double，Ｐ１０ double，Ｐ１１ double」
次にクエリの名称の生成方法について説明する。クエリＱ８の名称は、いまクエリＱ８の生成にかかわっている集計ＩＤと処理ＩＤの組み合わせとは別の組み合わせにかかわるＱ８やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤと処理ＩＤを文字列化し、「５−３−Ｑ８」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたINSERT INTO句とVALUES句を１つに繋ぎあわせるとINSERT文が得られ、このINSERT文とパラメータリストと名称を使用するＤＢＭＳに対してそれが規定する手法に従って与えるとクエリＱがストアドプロシージャとして集計表データベース４７に保存される。
なお、上記のINSERT文の例で、図３８に例示されている集計要素テーブル４６ｂの「集計フィールドＩＤ」の値が４５のレコードがfieldlist、values、パラメータリストのそれぞれに含まれていない点についてここで説明する。このレコードは、この説明のための架空の設定における集計表の合計欄についてのものである。この合計欄には金額と消費税を加算したものを記録することを意図しているが、この合計のデータは伝票データには無いのでパラメータとして伝票データから受取ることはできない。このため、「集計計算の有無」フィールドの値がＦａｌｓｅとなっており、fieldlist、values、パラメータリストには含まれていないのである。したがって、このクエリによって集計表テーブル４７ｘに追加されたレコードの「合計」フィールドの値は０である。しかし、表示時には、集計表テーブルから表示すべきレコードを抽出するクエリ(本発明の実施形態においてはＱ５に相当する)のSELECT句のフィールドリストに加算を行う式を加えるか、表示用のソフトウエアによって加算を行うことによって合計を表示させることができる。(本発明の実施形態においては後者の手法を採っている)。以上でＱ８の作成手法につぃての説明を終える。
次にクエリＱ９の生成について説明する。
クエリＱ９は、集計表テーブル４７ｘの既存のレコードに、計上した伝票のデータを加算または減算するクエリである。クエリＱ９の生成に関してまず行うべきことは、クエリＱ９の生成が必要であるか否かの判断である。この判断は、クエリＱ３に集計表のＩＤと処理ＩＤをパラメータとして与えて実行した時に、その実行結果としてパラメータとして与えた処理ＩＤと集計ＩＤの組み合わせのときにどのような集計計算を行うかを示す一連のレコードが得られるか否かで行う。この一連のレコードをここでは便宜的に結果のレコードセットと呼ぶ。仮に、クエリＱ３を実行した結果として１つもレコードが得られなければ、指定した処理ＩＤの値を持つ処理は、指定した集計ＩＤの値を持つ集計表に集計計算を行わないということなので、クエリＱ９の生成は不要となる。一方、レコードが得られた場合であるが、集計ＩＤが同一であっても処理ＩＤが異なれば集計計算の対象となる伝票データの構成が異なるので、必ずクエリＱ９を生成する。つまり、レコードが得られた集計ＩＤと処理ＩＤの組み合わせごとに、クエリＱ９を生成しなくてはならない。以下の説明はクエリＱ９の生成が必要となる場合のものである。
なお、Ｑ９は「加算または減算のクエリ」としたが、これは加算か減算かどちらか一方というわけではない。加算のクエリと減算のクエリの生成方法は、後述のごとく演算子を＋にするか−にするかの違いしかないのでこの両者をまとめてクエリＱ９とし、あわせて説明するものであり、加算のクエリと減算のクエリを両方生成しなくてはならない。
前述のごとくクエリＱ９はレコードに対して加算または減算をするクエリである。つまりクエリＱ９はＳＱＬのUPDATE文であり、以下のような構成になっている。
「UPDATE tablename SET newvalue WHERE criteria」
クエリＱ９は、クエリＱ３を実行した結果のレコードセットに基づき生成されるのであるが、上記の下線を施した部分が、結果のレコードセットの変化に応じて変化する。
以下、UPDATE句、SET句、WHERE句、パラメータリスト、クエリの名称の生成手法について順次説明する。
まず、UPDATE句のtablenameであるが、クエリＱ９は、元々、集計表テーブル４７ｘにデータを加算または減算するのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからそのその集計ＩＤの値を持つレコードを抽出し、そのレコードの「デーブル名」フィールドの値を得ればよい。この説明のために用いる例では結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、図３７に示した例の集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。従って図３７の例に基づいたUPDATE句は次のようになる。
「UPDATE 出荷済売上」
次にSET句について説明する。SET句は、結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるものの各レコードが以下の３つの場合のいずれに分類されるか判断し、その分類に従って生成される。その３分類とは、「集計対象」フィールドの値がＴｒｕｅ（図３８の例では２がＴｒｕｅ、１がＦａｌｓｅとなっている）のもの（これを便宜的に第１分類と呼ぶ）、「集計対象」フィールドの値がＦａｌｓｅのものの中で「抽出条件」フィールドの値がＴｒｕｅ（図３８の例では２がＴｒｕｅ、１がＦａｌｓｅとなっている）のもの（これを第２分類と呼ぶ）、第１分類、第２分類いずれにも属さないもの（これを第３分類と呼ぶ）、の３つである。
結果のレコードセットのレコードのうち第１分類とされたものについては以下の要領で生成される文字列をnewvalueである文字列にカンマで区切って追加する。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「フィールド名称」フィールドの値＋
そのレコードの「パラメータ名称」フィールドの値
図３８に例示された集計要素テーブル４６ｂの「集計フィールドＩＤ」フィールドの値が４０のレコードの場合は以下のような文字列が得られることになる。
「数量＝数量＋Ｐ７」
第２分類とされたレコードについては、文字列は生成しない。（この理由は後述する。）
第３分類とされたレコードについては以下の要領で生成される文字列をnewvalueである文字列にカンマで区切って追加する。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「パラメータ名称」フィールドの値
図３８に例示された集計要素テーブル４６ｂの「集計フィールドＩＤ」フィールドの値が３８のレコードの場合は以下のような文字列が得られることになる。
「品名＝Ｐ５」
これら各分類から得られた文字列を構成して、SET句にするのであるが、図３８に例示された集計要素テーブル４６ｂのすべてのレコードについて処理した場合の例を示せば以下のようになる。
「SET 受注伝票＝Ｐ３，受注項目＝Ｐ４，品名＝Ｐ５，内容＝Ｐ６，数量＝数量＋Ｐ７，単位＝Ｐ８，単価＝Ｐ９，金額＝金額＋Ｐ１０，消費税＝消費税＋Ｐ１１」
ここで、各分類の意味について説明する。第１分類は、そのレコードが表す集計表テーブル４７ｘのフィールドが加減算の対象となることを指定する値が記録されているもので、この指定は他のフィールド（たとえば「抽出条件」フィールド）に記録されているどのような値よりも優先される。第２分類と第３分類は、そのレコードが表す集計表テーブル４７ｘのフィールドが加減算の対象ではない、という点においては同じであるが、第２分類はそのレコードが表す集計表テーブル４７ｘのフィールドが抽出条件として使用される。つまりこのフィールドは集計表テーブル４７ｘのレコードを何らかの基準に従って他と区別するために使われるものであるので「加減算の対象ではない」という点に着目して第３分類と同じ処理をすると、抽出条件の比較の対象となる値を書換えるということになる。もちろん抽出条件に対して使用されるので、書換え前と書換え後で値が異なることは予定されていないが、何らかの予期せぬ理由により書換え前後の値が異なることになると、集計表テーブル４７ｘのデータの一貫性が保てなくなる。このような可能性を極力排除するために第２分類においては何もしないようにした。第３分類は、そのレコードが表す集計表テーブル４７ｘのフィールドが加減算の対象でもなく、抽出条件として使用されることもないものである。このようなフィールドを例示したような「品名＝Ｐ５」というかたちの式で書き換える必要性は無いように思われるが、第３分類に分類されるレコードが表す集計表テーブル４７ｘのフィールドに対してデータの書換えを容認しなければ、第３分類のフィールドは訂正できないということになり不都合であるので、データの書換えを容認したのである。
なお、上記の例では「数量＝数量＋Ｐ７」というように加算の場合を例示したが、減算の場合のＱ９を生成するときは「数量＝数量−Ｐ７」とすればよい。
次にＱ９のWHERE句の生成について説明する。WHERE句は、結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるもののうち、「抽出条件」フィールドの値がＴｒｕｅ（図３８の例では２がＴｒｕｅ、１がＦａｌｓｅとなっている）のものだけを参照して生成される。つまり結果のレコードセットに含まれるレコードすべてについて、「抽出条件」フィールドの値を調べ、それがＴｒｕｅであればcriteriaである文字列に以下の要領で生成される文字列を加える。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「パラメータ名称」フィールドの値
「抽出条件」フィールドの値がＴｒｕｅになるレコードが複数あれば上記の要領で生成された文字列を「AND」という文字列でつなぐ。
図３８に示した集計要素テーブル４６ｂでは「抽出条件」フィールドの値がＴｒｕｅのものは、「集計フィールドＩＤ」フィールドの値が３４と３５のレコードであるので、以下のようなWHERE句が生成されることになる。
「WHERE 出荷伝票＝Ｐ１ AND 出荷項目＝Ｐ２」
次にパラメータリストについて説明する。パラメータリストは前記SET句とWHERE句で使用されるパラメータに具体的な値を与える場合に備えてパラメータの名称、データ型等をＤＢＭＳに与えるために作成するものである。パラメータリストの作成法は以下のようになる。
結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるもののうち、「パラメータ名称」フィールドの値をパラメータ名とし「ＳＱＬ定義フィールドタイプ」フィールドの値をパラメータの型としてＤＢＭＳが要求する形式に整える。例えば、あるＤＢＭＳが要求する形式に従い、図３８の集計要素テーブル４６ｂの例に従うならば、次のようなパラメータリストが作成されることになる。
「PARAMETERS Ｐ１ double，Ｐ２ double，Ｐ３ double，Ｐ４ double，Ｐ５ string，Ｐ６ string，Ｐ７ double，Ｐ８ string，Ｐ９ double，Ｐ１０ double，Ｐ１１ double」
次にクエリの名称の生成方法について説明する。クエリＱ９の名称は、いまクエリＱ９の生成にかかわっている集計ＩＤと処理ＩＤの組み合わせとは別の組み合わせにかかわるクエリＱ９やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤと処理ＩＤを文字列化し、「５−３−Ｑ９」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたUPDATE句、SET句、WHER句を１つに繋ぎあわせるとUPDATE文が得られ、このUPDATE文とパラメータリストと名称を使用するＤＢＭＳに対してそれが規定する手法に従って与えるとクエリＱ９がストアドプロシージャとして集計表データベース４７に保存される。
次にクエリＱ１０の生成について説明する。Ｑ１０は、集計表テーブル４７ｘの既存のレコードに、計上した伝票のデータを上書きするクエリである。クエリＱ１０の生成に関してまず行うべきことは、クエリＱ１０の生成が必要であるか否かの判断である。この判断は、クエリＱ３に集計表のＩＤと処理ＩＤをパラメータとして与えて実行した時に、その実行結果としてパラメータとして与えた処理ＩＤと集計ＩＤの組み合わせのときにどのような集計計算を行うかを示す一連のレコードが得られるか否かで行う。この一連のレコードをここでは便宜的に結果のレコードセットと呼ぶ。仮に、クエリＱ３を実行した結果として１つもレコードが得られなければ、指定した処理ＩＤの値を持つ処理は、指定した集計ＩＤの値を持つ集計表に集計計算を行わないということなので、クエリＱ１０の生成は不要となる。一方、レコードが得られた場合であるが、集計ＩＤが同一であっても処理ＩＤが異なれば集計計算の対象となる伝票データの構成が異なるので、必ずクエリＱ１０を生成する。つまり、レコードが得られた集計ＩＤと処理ＩＤの組み合わせごとに、クエリＱ１０を生成しなくてはならない。以下の説明はクエリＱ１０の生成が、必要となる場合のものである。
前述のごとくクエリＱ１０はレコードに対して上書きをするクエリである。つまりクエリＱ１０はＳＱＬのUPDATE文であり、以下のような構成になっている。
「UPDATE tablename SET newvalue WHERE criteria」
Ｑ１０のクエリは、結果のレコードセットに基づき生成されるのであるが、上記の下線を施した部分が、結果のレコードセットの変化に応じて変化する。
以下、UPDATE句、SET句、WHERE句、パラメータリスト、クエリの名称の生成手法について順次説明する。
まず、UPDATE句のtablenameであるが、クエリＱ１０は、元々、集計表テーブル４７ｘの既存のレコードを上書きするのが目的なのであるから、tablenameにあたる文字列には集計表テーブル４７ｘの名称を入れればよく、それは集計表名テーブル４６ａの「テーブル名」フィールドに記録されている。すでに集計ＩＤは指定されているのであるから集計表名テーブル４６ａからその集計ＩＤの値を持つレコードを抽出し、そのレコードの「デーブル名」フィールドの値を得ればよい。この説明のために用いる例では結果のレコードセットは、集計ＩＤ＝５の場合のものであるので、図３７に示した例の集計表名テーブル４６ａの場合では集計ＩＤ＝５のときのテーブル名は「出荷済売上」となる。従って図３７の例に基づいたUPDATE句は次のようになる。
「UPDATE 出荷済売上」
次にSET句について説明する。SET句は、結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるもののうち、「パラメータ名称」フィールドに値があるレコードについて以下の要領で生成される文字列をnewvalueである文字列にカンマで区切って追加することにより作成される。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「パラメータ名称」フィールドの値
図３８に例示された集計要素テーブル４６ｂの例に従えば次のような文字列が得られることになる。
「SET 出荷伝票＝Ｐ１，出荷項目＝Ｐ２，受注伝票＝Ｐ３，受注項目＝Ｐ４，品名＝Ｐ５，内容＝Ｐ６，数量＝Ｐ７，単位＝Ｐ８，単価＝Ｐ９，金額＝Ｐ１０，消費税＝Ｐ１１」
次にクエリＱ１０のWHERE句の生成について説明する。WHERE句は、結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるもののうち、「抽出条件」フィールドの値がＴｒｕｅ（図３８の例では２がＴｒｕｅ、１がＦａｌｓｅとなっている）のものだけを参照して生成される。つまり結果のレコードセットに含まれるレコードすべてについて、「抽出条件」フィールドの値を調べ、それがＴｒｕｅであればcriteriaである文字列に以下の要領で生成される文字列を加える。
そのレコードの「フィールド名称」フィールドの値＝
そのレコードの「パラメータ名称フィールドの値
「抽出条件」フィールドの値がＴｒｕｅになるレコードが複数あれば上記の要領で生成された文字列を「AND」という文字列でつなぐ。
図３８に示した集計要素テーブル４６ｂでは「抽出条件」フィールドの値がＴｒｕｅのものは、「集計フィールドＩＤ」フィールドの値が３４と３５のレコードであるので、以下のようなWHERE句が生成されることになる。
「WHERE 出荷伝票＝Ｐ１ AND 出荷項目＝Ｐ２」
次にパラメータリストについて説明する。パラメータリストは前記SET句とWHERE句で使用されるパラメータに具体的な値を与える場合に備えてパラメータの名称、データ型等をＤＢＭＳに与えるために作成するものである。パラメータリストの作成法は以下のようになる。
結果のレコードセットに含まれるすべてのレコードについて、「集計計算の有無」フィールドがＴｒｕｅであるものの「パラメータ名称」フィールドの値をパラメータ名とし「ＳＱＬ定義フィールドタイプ」フィールドの値をパラメータの型としてＤＢＭＳが要求する形式に整える。例えば、あるＤＢＭＳが要求する形式に従い、図３８の集計要素テーブル４６ｂの例に従うならば、次のようなパラメータリストが作成されることになる。
「PARAMETERS Ｐ１ double，Ｐ２ double，Ｐ３ double，Ｐ４ double，Ｐ５ string，Ｐ６ string，Ｐ７ double，Ｐ８ string，Ｐ９ double，Ｐ１０ double，Ｐ１１ double」
次にクエリの名称の生成方法について説明する。クエリＱ１０の名称は、いまクエリＱ１０の生成にかかわっている集計ＩＤと処理ＩＤの組み合わせとは別の組み合わせにかかわるクエリＱ１０やその他の集計表データベース４７に保存されるクエリと区別できるようにするため、一意でなければならない。一意でありさえすれば、どのようなものでもかまわないのであるが、わかりやすくするために例えば、集計ＩＤと処理ＩＤを文字列化し、「５−３−Ｑ１０」といった文字列を生成し、これを名称とすればよい。
これまでに説明してきた手法で得られたUPDATE句、SET句、WHER句を１つに繋ぎあわせるとUPDATE文が得られ、このUPDATE文とパラメータリストと名称を使用するＤＢＭＳに対してそれが規定する手法に従って与えるとクエリＱ１０がストアドプロシージャとして集計表データベース４７に保存される。以上で、クエリＱ１〜Ｑ１０についての説明を終了する。
次に、図３に示す集計表データベース４７に含まれる集計ＩＤ毎の集計データを記録する集計表のテーブルの生成について説明する。
まず、集計要素テーブル４６ｂから生成したい集計表テーブルの集計ＩＤの値を「集計ＩＤ」フィールドに持つレコードを抽出する。この抽出された状態を図３８に示されている集計要素テーブル４６ｂの例を使って説明する。図３８ではたまたま集計ＩＤが５のみのレコードしか表示されておらず、またこの例が仮定している設定における集計ＩＤ＝５のレコードはすべて含まれているので、指定された集計ＩＤが５の場合の抽出結果を表していることになる。生成される集計表テーブルは、図３８で示した例の１番上のレコードが表しているフィールドから１番下のレコードの表すフィールドまで１２個のフィールドを持つことになる。そしてその１２個のフィールドの各々の名称は、集計要素テーブル４６ｂの「フィールド名称」フィールドに記録されている値（この場合は文字列である）になる。図３８の１番上のレコードの場合、その値は「出荷伝票」であり、２番目の場合は「出荷項目」である。また、これら１２個のフィールドのデータタイプは、集計要素テーブル４６ｂの「ＳＱＬ定義フィールドタイプ」フィールドに記録されている値に従う。図３８の例では「品名」、「内容」、「単位」の３つのフィールドがstringで、残りのフィールドはすべてdoubleである。
図３８に示されたような抽出後のレコードセットから集計表テーブルを生成する場合、上記で説明したフィールドに付与する名称のデータとそのフィールドのデータタイプのデータを使用するＤＢＭＳが規定する手法に従って与え、テーブルを生成する。
以上で、集計表定義データベース４６と集計表データベース４７の作成についての説明を終了し、次に各集計表に対する集計計算の処理の流れについて、図４６〜図４８を用いて説明する。
次に、集計計算を行う集計表作成ソフトウェア３６の説明を行う。この説明においては、まず、集計表作成ソフトウェア３６全体の制御構造を図４６のフローチャートを参照しながら説明する。続いて、そのフローチャートの各ステップの概略を説明し、その後に、各ステップにおける処理の詳細について説明する。さらに、フローチャートの詳細を説明する際に保留した、クエリの実行に関する共通の手法についての説明を最後に行う。
図４６は、集計表作成ソフトウェア３６の全体の制御構造を示すフローチャートである。このフローチャートから明らかなように集計表作成ソフトウェア３６は、ステップＳ２の条件を判定基準とするループを構成し、そのループの内部には、さらにステップＳ４の条件を判定基準とするループを含む２重ループ構造を持っており、すべてのループ処理を終えると、ステップＳ１５の処理を行い終了する。
次に、図４６のフローチャートの各ステップについて、その処理の概略を、図５０及び図５１を参照しながら説明する。
集計表作成ソフトウェア３６は、新規計上ソフトウェア３１か、修正計上ソフトウェア３２のどちらかによって起動されることによって処理を開始する。
ステップＳ１では集計表作成ソフトウェア３６を起動したソフトウェアからパラメータを受け取る。受け取るパラメータの数は４つであり、これらを以下、ＰＲ１、ＰＲ２、ＰＲ３、ＰＲ４として説明する。なお、ＰＲ１は計上された伝票データである。これらのパラメータについての詳細は後段で説明する。
ステップＳ２では、受け取った伝票データの本体項目について、すべての本体項目についてステップＳ３以降の処理を受けているか否かを判断する。未処理の項目があれば、その項目に対してステップＳ３以降の処理に進み、未処理のものがなければ、つまりすべての本体項目について処理が終わっていれば、集計表作成ソフトウェア３６の処理の終了処理（ＥＮＤ）に進む。
ステップＳ３では、処理ＩＤをパラメータとしてクエリＱ１に与えて実行する。その結果、その処理ＩＤを持つ処理が、どの集計表に対して集計を行うかを示す一連のレコードが得られる。これを以後、Ｓ３のレコードセットと呼び、Ｓ３のレコードセットに含まれるレコードをＳ３のレコードと呼ぶ。
ステップＳ４では、Ｓ３のレコードセットのレコードのすべてについて、ステップＳ５以降の処理を受けているか否かを判断する。未処理のレコードがあればステップＳ５に進み、未処理のものがなければ、つまり、すべてのＳ３のレコードについて処理が終わっていれば、ステップＳ２へ戻り未処理の本体項目の有無について判断することになる。
ステップＳ５では、実際に集計計算を行うときに必要なデータを特定するための３つの処理を行う。第１の処理は、集計計算対象の集計表テーブル４７ｘを特定するものである。第２の処理は、クエリＱ３にいま処理中のＳ３のレコードの「集計ＩＤ」フィールドの値と「処理ＩＤ」フィールドの値をパラメータとして与えて実行することにより一連のレコードセットを得る処理である。この得られた一連のレコードを以後、Ｓ５のレコードセットと呼ぶ。第３の処理は、パラメータＰＲ１とＰＲ４のどちらを処理対象とするかを選択する処理である。
ステップＳ６では、ステップＳ５で特定された集計表テーブル４７ｘの親の伝票ＩＤと、いま集計計算の対象となっている伝票の伝票ＩＤが一致するか否か判断する。一致する場合は、ステップＳ７以降の処理に進む。一致しない場合は、ステップＳ１０以降の処理に進む。
ステップＳ７では、いま処理中のＳ５のレコードセットに基づいてクエリＱ６にパラメータを与え、ステップＳ５で明らかになった集計計算対象の集計表テーブル４７ｘにレコードがあるか否か判断する。レコードがあればステップＳ８に進み、なければステップＳ９に進む。
ステップＳ８では、集計計算の対象となる集計表テーブル４７ｘにすでにレコードがある場合の処理を行う。処理の終了後は、ステップＳ４へ戻り、未処理のＳ３のレコードがないか否かを判断することになる。
ステップＳ９では、集計計算の対象となる集計表テーブル４７ｘにレコードがない場合の処理を行う。処理の終了後は、ステップＳ４へ戻り、未処理のＳ３のレコードがないか否かを判断することになる。
一方、ステップＳ６で分岐したフローのステップＳ１０では、現在処理中の本体項目のデータに関連伝票データが含まれているか否かを判断する。含まれていなければ、何もせずにステップＳ４に戻り、未処理のＳ３のレコードがあるか否か判断する。一方、関連伝票データが含まれていれば、ステップ１１以降の処理に進む。
ステップ１１では、ステップＳ５で特定された集計表テーブル４７ｘの親の伝票ＩＤと、現在処理中の本体項目が参照している伝票の伝票ＩＤが一致するか否か判断する。一致する場合は、ステップ１２以降の処理に進み、一致しない場合は何もせずステップ４に戻り、未処理のＳ３のレコードがあるか否か判断する。
ステップ１２では、現在処理中のＳ５のレコードセットからクエリＱ６にパラメータを与え、ステップ５で明らかになった集計計算対象の集計表テーブル４７ｘにレコードがあるか否か判断する。レコードがあればステップ１３に進み、レコードがなければステップ１４に進む。
ステップ１３では、集計計算の対象となる集計表テーブル４７ｘにすでにレコードがある場合の処理を行う。処理の終了後は、ステップＳ４に戻り、未処理のＳ３のレコードがあるか否かを判断する。
ステップ１４では、集計計算の対象となる集計表テーブル４７ｘにレコードがない場合の処理を行う。処理の終了後はステップＳ４に戻り、未処理のＳ３のレコードがあるか否か判断する。
ステップＳ１５では、ステップＳ１４までで行われた集計計算の結果、集計表テーブル４７ｘのレコードのなかに削除条件に合致したレコードがないかを調べ、合致したレコードがある場合はそれを削除する処理を行い、ステップＳ２に戻る。そして、ステップ２において、全ての本体項目についての処理が終了したと判断すると、集計表作成ソフトウェア３６の終了処理（ＥＮＤ）に進む。
次に図４６のフローチャートの各ステップの詳細について図５０、図５１を参照して説明する。
まず、集計表作成ソフトウェア３６の開始（ＳＴＡＲＴ）について説明する。具体的な開始方法は、集計表作成ソフトウェア３６の実装方法の違いにより異なる。例えば、集計表作成ソフトウェア３６を呼び出し側のソフトウェアの一部として（つまりサブルーチンとして）実装すれば、サブルーチンの呼び出しというかたちで行われるし、呼び出し側とはまったく別の（他のＰＣ上でも実行可能な）ソフトウェアとして実装すれば（このような実装方法は一部有力企業や企業連合からいくつか提案されている）、その実装方法にあった呼び出し手順が求められる。本発明の実施方法では、後者の手法のなかから１つを採用したが、これは強制されるものではない。本実施の形態においては、新規計上ソフトウェア３１か、集計計上ソフトウェア３２によって起動される。
次に、ステップＳ１の詳細について説明する。ステップＳ１では、集計表作成ソフトウェア３６を起動したソフトウェアから４つのパラメータであるＰＲ１、ＰＲ２、ＰＲ３、ＰＲ４を受け取るので、このパラメータについて順番に説明する。
ＰＲ１は、計上された伝票データであり図２０、図２１に示す構造を持っている。ＰＲ２は、集計表作成ソフトウェア３６が受け取るＰＲ１の伝票データが、新規計上又は参照計上に関わる伝票データであるか、それとも修正計上に関わる伝票データであるか、を示す識別子である。この識別子によって両者が区別できればよいのであるから値は何でもよい。ＰＲ３は、集計計算の対象となる集計ＩＤである。通常は、集計表作成ソフトウェア３６は規定されているすべての集計表テーブル４７ｘに対して集計計算を行うので、ＰＲ３の値は０である。しかし、特定の集計表テーブル４７ｘのみに対して集計計算を行いたいときは、ＰＲ３に目的とする集計ＩＤが入る。ＰＲ４は、ＰＲ２によってＰＲ１が修正計上に関わる伝票データであると規定されている場合に必要となるパラメータであり、修正前の伝票データを伝票管理データベース４（図１参照）から検索してきたもので、図２０、図２１に示す構造を持っている。したがって、ＰＲ１が新規計上または参照計上にかかわる伝票データである場合にはＰＲ４は不要になる。この場合は、ＰＲ４に何もデータを入れずに空の状態で受け渡しを行うか、ＰＲ１が修正計上に関わる伝票データである場合はパラメータ数を４とし、新規計上または参照計上に関わる伝票データである場合はパラメータ数を３とすることのどちらかで対応する。
次にステップＳ２の詳細を説明する。ステップＳ２ではパラメータＰＲ１の伝票データに含まれる本体項目データセクション５５(図２０参照)の数を知り、その数の示す回数だけステップＳ３以降の処理が繰り返されるように集計表作成ソフトウェア３６の動作を制御する処理を行う。このときそれぞれの繰り返し処理において、個々の本体項目データセクション５５が処理対象となるようにする。したがって、毎回の繰り返し処理がステップＳ２で開始された時点でどの本体項目データセクション５５がステップＳ３以降の処理の対象となるかが決定されることになる。このとき、同じ本体項目データセクション５５が重複して処理されることのないようにする。そして、すべての本体項目データセクション５５に対する処理が終われば、集計表作成ソフトウェア３６を終了する。
ここで、本体項目データセクション５５を処理する順番は問わない。また、本体項目データセクション５５の数を得るときにＰＲ４でなくＰＲ１の伝票データに基づいたが、これはＰＲ１とＰＲ４は同じ伝票の修正前と修正後の伝票データであるので本体項目セクション５５の数に差異はない上に、ＰＲ１には必ず伝票データの実体があるが、ＰＲ４は空の伝票データである場合もあるからである。
次にステップＳ３の詳細を説明する。前述のステップＳ３の概略の説明では、クエリＱ１を実行するとしたが、パラメータＰＲ３の値によってはクエリＱ２を実行する。クエリＱ１を実行するのは、ＰＲ３の値が０のときで、このときは規定されているすべての集計表テーブル４７ｘに対して集計計算を行う。通常、パラメータＰＲ３の値は０であり、ＰＲ３の値が０以外で集計ＩＤを表すときは例外的な場合であるので、概略説明のときは省略したが、ＰＲ３の値が０以外で集計ＩＤを表すときはクエリＱ２を実行し、ＰＲ３の集計ＩＤが示す集計表テーブル４７ｘに対してのみ集計計算を行う。
ここで、クエリＱ１に与えるパラメータについて説明する。クエリＱ１に与えるパラメータは処理ＩＤであるが、その処理ＩＤは、パラメータＰＲ２が修正計上を意味するものであれば問い合わせデータセクション５１のエリア５１ｇ（図２０参照）からその値を得るものとし、パラメータＰＲが新規計上または参照計上を意味するものであればいま処理中の本体項目データセクション５５の「この項目の処理ＩＤ」を記録するエリア５５ｍ（図２０参照）からその値を得るものとする（なお、処理ＩＤが３の場合のＳ３のレコードセットの例を図４７に示す。）。
次に、クエリＱ２に与えるパラメータについて説明する。クエリＱ２に与えるパラメータは２つあり、１つは処理ＩＤであり、もう１つは集計ＩＤである。クエリＱ２に与える処理ＩＤは、クエリＱ１に与える処理ＩＤと同じものである。集計ＩＤについては、パラメータＰＲ３の値を集計ＩＤとして与えればよい。（なお、処理ＩＤが３で集計ＩＤが５の場合のＳ３のレコードセットの例を図４８に示す。）
クエリＱ１またはクエリＱ２を実行した結果、レコードが１つも得られない、ということは、集計表定義データベース４６の各テーブルの値が正しく設定されていれば起こらない。しかし万一、１つもレコードが得られなかった場合に備えるならば、ステップＳ２に戻り、次の本体項目についての判断をするようにすれば良い。（この点は、図４６のフローチャートには記載されていない。）
次に、ステップＳ４の詳細を説明する。ステップＳ４では、Ｓ３のレコードセットに含まれるレコードの数を知り、その数が示す回数だけステップＳ５からステップＳ１４までの処理が行われるように制御する。このときそれぞれの繰り返し処理において、個々のＳ３のレコードがステップＳ５以降の処理対象となるようにする。したがって、毎回の繰り返し処理がステップＳ４で開始された時点でどのＳ３のレコードがステップＳ５以降の処理の対象となるかが決定されることになる。このとき、同じＳ３のレコードが重複して処理されることのないようにする。Ｓ３のレコード全てについて処理が終われば、ステップ１５の処理を行って、ステップＳ２に戻り、次の本体項目についての判断を行う。なお、Ｓ３のレコードセットに含まれるレコードの順番は、クエリＱ１またはクエリＱ２に規定されているので、ステップＳ４では順番を意識する必要はない。
次にステップＳ５について詳細な説明を行う。ステップＳ５では、実際に集計計算を行うときに必要なデータを特定するための３つの処理を行う。
ステップＳ５で特定する１番目のデータは、集計計算の対象となる集計表テーブル４７ｘに関するデータである。これを特定するために、ステップＳ５ではいま処理中のＳ３のレコードの「集計ＩＤ」フィールドの値と同じ値を「集計ＩＤ」フィールドに持つ集計表名テーブル４６ａのレコードを抽出する。集計表定義データベース４６の各テーブルの値が正しく設定されていれば、この抽出の結果、必ずレコードが得られる。集計表名テーブル４６ａには、集計表のテーブル名が記録されているので、抽出されたレコードの集計表のテーブル名に基づきそのテーブルを開く。
ステップＳ５で特定する２番目のデータは、ステップＳ６以降の処理で実行するクエリのパラメータに与える値を得るために必要となるクエリＱ３を実行して得られる一連のレコードである。このため、ステップＳ５ではいま処理中のＳ３のレコードの「集計ＩＤ」フィールドの値と、「処理ＩＤ」フィールドの値をパラメータとしてクエリＱ３に与え実行する。前述のごとく、この結果得られた一連のレコードをＳ５のレコードセットと呼ぶ。
ステップＳ５で特定する３番目のデータは、集計計算対象の伝票データがＰＲ１とＰＲ４のパラメータのうちいずれであるか、である。このために、いま処理中のＳ３のレコードの、「処理対象」フィールドの値に従って、ＰＲ１とＰＲ４のパラメータのうちいずれかを選ぶ。集計表定義データベース４６の各テーブルの値が正しく設定されていれば、パラメータＰＲ２によってＰＲ１が修正計上にかかわるデータであると規定されておらず、従ってＰＲ４が与えられていないにもかかわらず、Ｓ３のレコードの「処理対象」フィールドの値がＰＲ４をステップＳ５以降の処理対象として指定することはない。
次にステップＳ６の詳細について説明する。ステップＳ６では伝票ＩＤの照合を行う。照合される伝票ＩＤの一方は、ステップＳ５で特定された集計表テーブル４７ｘ（この特定は、集計表テーブル４６ａの該当するレコードを抽出することによって行われる）の親の伝票ＩＤ（これは集計表テーブル４６aの「親の伝票」フィールドに記録されている）である。照合される他方の伝票ＩＤは、いま集計計算の対象となっている伝票の伝票ＩＤである。これらの伝票ＩＤが一致する場合はステップＳ７に進む。一方、これらの伝票ＩＤが一致しない場合はステップＳ１０以降の処理に進む。
次にステップＳ７の詳細について説明する。ステップＳ７は、いま処理中の伝票の本体項目データを、ステップＳ５で得られた集計表名定義テーブル４６ａのレコードが示す集計表テーブル４７ｘに対して集計計算するにあたり、そのテーブルにこれから行おうとする集計計算の対象となるレコードがすでに存在するか否かを確かめる処理である。このためにクエリＱ６にパラメータを与えて実行し、その結果に基づいて判断するのであるが、クエリＱ６の実行は後述の「クエリに与えるパラメータ値を得て実行する手法」による。この手法を実行するには４つのデータを事前に知っておく必要がある。それは、いま処理しているのは伝票データの何番目の本体項目であるかのデータ、いま処理しているＳ５のレコードセット、処理している伝票のデータ、クエリ名、の４つのデータである。
クエリ名を除く３つのデータは処理がステップＳ５を終了した時点にまで進んでくる過程で明らかになってきている。しかし、クエリ名については、クエリＱ６が集計表データベース４７に含まれる複数ある集計表テーブル４７ｘのそれぞれに対して１つ存在するので、不明である。そこでクエリ名を明らかにするために、クエリＱ６を生成したときにクエリ名もあわせて生成したが、そのクエリ名を生成した手法と同じ手法を用いて再度クエリ名を生成する。例えば、クエリＱ６の生成について説明したときの例では、集計ＩＤ（これはいま処理中のＳ３のレコードの「集計ＩＤ」フィールドに記録されている）の値を文字列化し、「５−Ｑ６」と例示した。
このようにして４つのデータが明らかになり、クエリＱ６が「クエリに与えるパラメータ値を得て実行する手法」によって実行される。クエリＱ６の実行の結果、レコードが得られれば、集計計算対象である集計表テーブル４７ｘにはレコードがあるのでステップＳ８に進み、レコードが得られなければステップＳ９に進む。
次にステップＳ８の詳細について説明する。ステップＳ８は集計計算の対象の集計表テーブル４７ｘにすでにレコードがある場合の処理を行う。この処理では、いま処理中のＳ３のレコードの「データ処理動作」フィールドの値にしたがって、次の３つの場合のいずれかの処理を行う。すなわち、既存のレコードに上書きをする場合、既存のレコードに加算する場合、既存のレコードから減算する場合、の３つである。
既存のレコードに上書きする場合はクエリＱ１０のパラメータに値を与えて実行する。クエリＱ１０は結果を返さないクエリであり、クエリＱ１０の実行が正常に終了すれば上書きの処理は成功したことになり、上書きのために必要な処理はすべて実行されたことになる。上書きのためにはクエリＱ１０にパラメータを与えて実行するのであるが、それは後述の「クエリに与えるパラメータ値を得て実行する手法」による。この手法を実行するには４つのデータを事前に知っておく必要がある。それは、いま処理しているのは伝票データの何番目の本体項目であるかのデータ、いま処理しているＳ５のレコードセット、処理している伝票のデータ、クエリ名、の４つのデータである。クエリ名を除く３つのデータは処理がステップＳ５を終了した時点にまで進んでくる過程で明らかになってきている。しかし、クエリ名については、クエリＱ１０が集計計算対象の集計表テーブル４７ｘに対して有効な集計ＩＤと処理ＩＤの組み合わせ数だけあるので不明である。そこでクエリ名を明らかにするために、クエリＱ１０を生成したときにクエリ名もあわせて生成したが、そのクエリ名を生成した手法と同じ手法を用いて再度クエリ名を生成する。例えば、クエリＱ１０の生成について説明したときの例では、集計ＩＤと処理ＩＤ（これはいま処理中のＳ３のレコードの「集計ＩＤ」フィールドと「処理ＩＤ」フィールドに記録されている）の値を文字列化し、「５−３−Ｑ１０」と例示した。
このようにして４つのデータが明らかになり、クエリＱ１０が「クエリに与えるパラメータ値を得て実行する手法」によって実行される。クエリＱ１０が正常に終了すれば上書き処理は終わったことになり、上書きを行う場合のステップＳ７の処理も終わり、ステップＳ４へ戻り未処理のＳ３のレコードの有無について判断する。
次に既存のレコードに対して加算または減算する場合について説明する。これらの場合はクエリＱ９を使用するが、加算と減算におけるクエリＱ９はその演算子が＋か−かの違いしかないので両者を同じものとして扱い同時に説明する。
加算または減算の場合はクエリＱ９のパラメータに値を与えて実行する。クエリＱ９は結果を返さないクエリであり、クエリＱ９の実行が正常に終了すれば加算または減算の処理は成功したことになり、加算または減算のために必要な処理はすべて実行されたことになる。加算または減算のためにはクエリＱ９にパラメータを与えて実行するのであるが、それは後述の「クエリに与えるパラメータ値を得て実行する手法」による。この手法を実行するには４つのデータを事前に知っておく必要がある。それは、いま処理しているのは伝票データの何番目の本体項目であるかのデータ、いま処理しているＳ５のレコードセット、処理している伝票のデータ、クエリ名、の４つのデータである。クエリ名を除く３つのデータは処理がステップＳ５を終了した時点にまで進んでくる過程で明らかになってきている。しかし、クエリ名については、クエリＱ９が集計計算対象の集計表テーブル４７ｘに対して有効な集計ＩＤと処理ＩＤの組み合わせ数だけあるので不明である。そこでクエリ名を明らかにするために、クエリＱ９を生成したときにクエリ名もあわせて生成したが、そのクエリ名を生成した手法と同じ手法を用いて再度クエリ名を生成する。例えば、クエリＱ９の生成について説明したときの例では、集計ＩＤと処理ＩＤ（これはいま処理中のＳ３のレコードの「集計ＩＤ」フィールドと「処理ＩＤ」フィールドに記録されている）の値を文字列化し、「５−３−Ｑ９」と例示した。
このようにして４つのデータが明らかになり、クエリＱ９が「クエリに与えるパラメータ値を得て実行する手法」によって実行される。クエリＱ９が正常に終了すれば加算または減算の処理は終わったことになり、加算または減算を行う場合のステップＳ８の処理も終わり、ステップＳ４へ戻り未処理のＳ３のレコードの有無について判断する。
次にステップＳ９の詳細について説明する。ステップＳ９は集計計算の対象の集計表テーブル４７ｘにレコードがない場合の処理を行う。この処理では、Ｓ３のレコードの「データ処理動作」フィールドの値にしたがって、次の３つの場合のいずれかの処理を行う。すなわち、レコードに上書きをする場合、レコードに加算する場合、レコードから減算する場合、の３つである。Ｓ５のレコードの「データ処理動作」フィールドの値に従った場合分けは３通りであるが、実際に行う処理は以下のようになる。
上書きする場合と加算する場合はそれぞれの処理対象となるレコードがないのであるから上書きも加算もできないので、新規にレコードを追加する処理を行う。減算する場合も処理対象となるレコードがないのであるから減算できないので、新規にレコードを追加した後で、Ｓ５のレコードの「集計対象」フィールドがＴｒｕｅであればそのレコードの「集計フィールドＩＤ」フィールドが示す欄の値に−１をかけて０から減算した格好にする。つまりステップＳ９の処理ではいずれの場合もレコードの新規追加の処理を行う。
新規にレコードを追加する場合はクエリＱ８のパラメータに値を与えて実行する。クエリＱ８は結果を返さないクエリであり、クエリＱ８の実行が正常に終了すれば新規追加の処理は成功したことになり、新規追加のために必要な処理はすべて実行されたことになる。新規追加のためにはクエリＱ８にパラメータを与えて実行するのであるが、それは後述の「クエリに与えるパラメータ値を得て実行する手法」による。この手法を実行するには４つのデータを事前に知っておく必要がある。それは、いま処理しているのは伝票データの何番目の本体項目であるかのデータ、いま処理しているＳ５のレコードセット、処理している伝票のデータ、クエリ名、の４つのデータである。クエリ名を除く３つのデータは処理がステップＳ５を終了した時点にまで進んでくる過程で明らかになってきている。しかし、クエリ名については、クエリＱ８が集計計算対象の集計表テーブル４７ｘに対して有効な集計ＩＤと処理ＩＤの組み合わせ数だけあるので不明である。そこでクエリ名を明らかにするために、クエリＱ８を生成したときにクエリ名もあわせて生成したが、そのクエリ名を生成した手法と同じ手法を用いて再度クエリ名を生成する。例えば、クエリＱ８の生成について説明したときの例では、集計ＩＤと処理ＩＤ（これはいま処理中のＳ３のレコードの「集計ＩＤ」フィールドと「処理ＩＤ」フィールドに記録されている）の値を文字列化し、「５−３−Ｑ８」と例示した。
このようにして４つのデータが明らかになり、クエリＱ８が「クエリに与えるパラメータ値を得て実行する手法」によって実行される。クエリＱ８が正常に終了すれば新規追加処理は終わったことになり、ステップＳ９の処理も終わり、ステップＳ４へ戻り未処理のＳ３のレコードの有無について判断する。
次に、ステップＳ６から分岐したステップ１０以降の説明に入る。まず、ステップＳ１０の詳細について説明する。ステップ１０では、現在処理中の本体項目のデータに関連伝票データが含まれているか否かを判断する。この判断は、伝票データに含まれている関連伝票データセクション５７（図２１参照）の数に基づいて行う。関連伝票データセクション５７の数が０であれば関連伝票データは含まれていないと判断し、関連伝票データセクション５７の数が１以上であれば関連伝票データが含まれていると判断する。関連伝票データが含まれていない場合は、何もせずにステップＳ４に戻り未処理のＳ３のレコードがあるか否か判断する。一方、関連伝票データが含まれている場合は、ステップ１１以降の処理に進む。
次にステップ１１の詳細について説明する。ステップＳ１１では伝票ＩＤの照合を行う。照合される伝票ＩＤの一方は、ステップＳ５で特定された集計表テーブル４７ｘ（この特定は、集計表テーブル４６ａの該当するレコードを抽出することによって行われる）の親の伝票ＩＤ（これは集計表テーブル４６aの「親の伝票」フィールドに記録されている）である。照合される他方の伝票ＩＤは、いま集計計算の対象となっている本体項目が参照している伝票の伝票ＩＤ（これは関連伝票データセクション５７（図２１参照）の「参照伝票ＩＤ」を記録するエリア５７ｅに記録されている）である。これらの伝票ＩＤが一致する場合はステップＳ１２以降の処理に進む。一方、これらの伝票ＩＤが一致しない場合は何もせずにステップＳ４に戻り、未処理のＳ３のレコードがあるか否か判断する。
次に、ステップ１２、ステップ１３及びステップ１４の詳細についての説明に入るわけだが、ステップ１２はステップ７と、ステップ１３はステップＳ８と、ステップ１４はステップＳ９と、それぞれ全く同一の処理を行うものなので、ここでは説明を省略する。
次にステップＳ１５の詳細について説明する。ステップＳ１５に制御が移ってくるのは、ステップＳ４が構成していた２重の繰り返し処理がすべて終わった後である。ステップＳ１５で行われるのは集計表テーブル４７ｘに対する集計計算の結果、削除条件に合致するようになったレコードを削除する処理である。ステップＳ１５では、Ｓ３のレコードセットに含まれるレコードの数を知り、その数が示す回数だけクエリＱ７が実行されるように制御する。このときそれぞれの繰り返し処理において、個々のＳ３のレコードの「集計ＩＤ」フィールドの値が示す集計表テーブル４７ｘがクエリＱ７の処理対象となるようにし、各回の繰り返し処理で、同じＳ３のレコードから処理対象の集計表テーブル４７ｘを得ないようにする。
クエリＱ７にはパラメータがないので、クエリＱ６、クエリＱ８、クエリＱ９、クエリＱ１０とは異なり、実行に際して後述の「クエリに与えるパラメータ値を得て実行する手法」にはよらない。クエリＱ７を実行するにはまず、クエリＱ７が集計表データベース４７に含まれる複数ある集計表テーブル４７ｘのそれぞれに対して１つ存在するので、クエリ名を明らかにすることで、どのクエリＱ７であるかを特定する。クエリ名を明らかにするためには、クエリＱ７を生成したときにクエリ名もあわせて生成したが、そのクエリ名を生成した手法と同じ手法を用いて再度クエリ名を生成する。例えば、クエリＱ７の生成について説明したときの例では、集計ＩＤ（これはいま処理中のＳ３のレコードの「集計ＩＤ」フィールドに記録されている）の値を文字列化し、「５−Ｑ７」と例示した。
このようにして、どのクエリＱ７であるかが明らかになり、クエリＱ７を実行できるようになった。具体的な実行方法は、使用するＤＢＭＳによって異なるのであるが、実行したいクエリ名と、そのクエリを実行するという旨をＤＢＭＳが定める手法に従ってＤＢＭＳに与えれば実行される。Ｓ３のレコード全てについて処理が終われば、必要な処理はすべて終わったことになる。
最後に、ＥＮＤについて説明する。ＥＮＤの段階で、集計表作成ソフトウェア３６の終了にあたって必要な処理を行う。たとえば使用していたメモリを解放するといった作業であるが、具体的に必要な作業は開始時の開始手法によって異なる。
なお、ここで、ステップＳ１１からステップＳ１４までの処理が必要となる理由について補足説明を行う。ステップＳ１２、ステップＳ１３、ステップＳ１４の三つの処理は、ステップＳ７、ステップＳ８、ステップＳ９の三つの処理とまったく同じ操作を行う処理であり、また、その操作の対象となるデータは、ステップＳ５までの過程で確定されている（つまり、ステップＳ６で処理のフローが分岐する前に確定されている）ので、両者の処理結果は同じものになる。しかし、特定の場合には、ステップＳ１０とステップＳ１１の判断に従い何らかの処理を行わないと、集計計算に不整合が生じエラーとなる。以下に、それはどのような場合であるかを具体的に伝票名を例示しながら説明するが、最初に不整合が生じない場合として出荷参照売上の例を示し、次に不整合が生じる場合として売上修正の例を示す。
例えば、売上伝票は、受注伝票を参照して計上される場合（受注参照売上）と、出荷伝票を参照して計上される場合（出荷計上売上）と、何も参照せずに計上される場合(新規売上)の３通りの計上方法が設定されているとする。新たに売上を計上する場合、それが出荷参照売上であったときはステップＳ３において、出荷参照売上に対応する処理ＩＤ（例では処理ＩＤは３である）を用いて参照売上の場合はどの集計表に対してどのような集計計算をするかが取得されたレコードセットから明らかになる。この内容は図４７のテーブルで示されているが、これは出荷参照売上を行う場合は、４つの集計表に対して集計計算を行うことを意味している。４つの集計表とは、すなわち、集計ＩＤが１の顧客別売上高、集計ＩＤが２の製品別売上高、集計ＩＤが４の入金予定表、集計ＩＤが５の出荷済売上高未計上残高、である。つまり、出荷参照売上の場合はステップＳ４の構成するループを４回まわることで、これら４つの集計表に対して集計計算をしている（なお、ステップＳ３はステップＳ２が構成するループの内側にあるので、伝票の本体項目が複数ありそれぞれの処理ＩＤが異なる場合でも、本体項目の数だけステップＳ２の構成するループをまわることにより各項目の処理ＩＤに従うことができる）。
ここで、図４７のテーブルの１行目と４行目に示された集計表に対する集計計算について考察する（２行目と３行目は後述するステップＳ６における照合の結果が１行目と同じになるという点で１行目と同一の性質を有しているので説明を省略する）。１行目は、集計ＩＤが１の顧客別売上高に対する集計計算を規定しているが、図３７の集計表名テーブル４６ａによれば顧客別売上高の親の伝票ＩＤは１である。伝票ＩＤの１は図９に示す伝票ＩＤテーブル４２ａで規定されているとおり売上伝票である。いま計上しているのは処理ＩＤが３である出荷参照売上であるから、当然処理している伝票ＩＤも売上伝票を示す１であり、ステップＳ６において照合される伝票ＩＤ同士は一致し、ステップＳ７以降の処理に進む。
一方、図４７のテーブルの４行目では集計ＩＤが５の出荷済売上高未計上に対する集計計算を規定しているが、図３７の集計表名テーブル４６ａによれば出荷済売上高未計上の親の伝票は３であり、図９で示す伝票ＩＤテーブル４２ａから出荷伝票であることを示している。いま計上しているのは出荷参照売上であるから、ステップＳ６において照合される伝票ＩＤは、売上伝票を示す１と出荷伝票を示す３となり、一致しないので、ステップＳ１０以降の処理に進むことになる。ステップＳ１０では、関連伝票のデータの有無を判断することになるが、ここでの例では出荷参照売上を処理しているので当然関連伝票データがあり、ステップＳ１１に進む。ステップＳ１１では、その関連伝票データの伝票ＩＤ（これは出荷参照売上を計上しているので、出荷伝票をさす値である３となる）と、親の伝票の伝票ＩＤ（図３７より３である）とを照合するが、その値は一致するので、ステップＳ１２に進む。この４行目の例では、仮にステップＳ６の条件判断を行わなくても、ステップＳ７以降の処理で問題を起すことはないので、ステップＳ６の条件判断は不要に思われるが、次の場合は不都合を生じる。
売上修正の場合を考察すると、これまでの例に従えば、売上伝票の修正時には次のような集計計算をする必要がある。受注参照売上の場合には、顧客別売上高と製品別売上高を入金予定表に対しては修正前の数量を引き、次に修正後の数量を加え、納入予定表に対しては修正前の数量を加え、次に修正後の数量を引く。出荷参照売上の場合には、顧客別売上高と製品別売上高と入金予定表に対しては修正前の数量を引き、出荷済売上高未計上残高に対しては修正前の数量を加え、次に修正後の数量を引く。新規計上の場合は、顧客別売上高と製品別売上高と入金予定表に対しては修正前の数量を引き、次に修正後の数量を加える。これを図４１の集計動作定義テーブル４６ｅから抽出されたＳ３のレコードセットとして表現すると、図４９のようになる。
つまり、この例では、売上修正時には図４９のテーブルの各行に従って処理をするためにステップＳ４の構成するループを１０回まわることになる。いま、出荷参照売上の修正が行われるとすると、図４９の５行目と６行目の処理を除いて問題なく実行されるが、５行目と６行目の処理に関しては次のようになる。なお、５行目と６行目はここで説明する趣旨からは同一の性質を持っているので５行目についてのみ説明する。
５行目の処理は、集計ＩＤ３の集計表（これは納入予定である。図３７参照）に対する処理であるが、この集計表の親の伝票の伝票ＩＤは２（受注伝票を意味する。図９参照）である。いま処理しているのは売上伝票なので、ステップＳ６で照合される伝票ＩＤの値は一致しない。ここで、仮にステップＳ６からステップＳ１０以降に移行する処理がないものとすれば、処理はステップＳ７に進む。ステップＳ７では「クエリに与えるパラメータ値を得て実行する手法」に従ってクエリＱ６を実行する。このとき、この手法ではＳ５のレコードセットを利用するが、このＳ５のレコードセットはクエリＱ３を実行した結果得られたものである。このときクエリＱ３にパラメータとして与えた値は集計ＩＤ（その値は３）と処理ＩＤ（その値は６）である。これは、納入予定表に対しては売上伝票修正時にどのように集計計算をすればよいかを規定したレコードセットであるので、ステップＳ６以降の処理では納入予定表に対する集計計算を行うことになる。
しかし、いま修正しているのは出荷参照売上の売上伝票であり、この伝票が最初に計上されたときは納入予定表に対する集計計算は行われなかった。したがって、この伝票の修正時に納入予定表に対する集計計算は必要ない。ところが前述のごとくＳ５のレコードセットは納入予定表に対する集計計算を促すものであり矛盾が生じている。このような矛盾を避けるために、ステップＳ６での分岐を設けているのである。
ステップＳ６の分岐で照合する伝票ＩＤが一致しなかった結果として、ステップＳ１０以降の処理をたどると以下のようになる。ステップＳ１０では、関連伝票データの有無を判断するが、この場合は出荷参照売上であるから関連伝票データは存在し、その結果処理はステップＳ１１に進む。ステップＳ１１では、集計表の親の伝票の伝票ＩＤ（その値は２である）と関連伝票の伝票ＩＤ（その値は３である）を照合し、両者は一致しないのでその結果ステップＳ１２以降の処理は実行されず、結果として何も集計計算は行われない。これは今までの説明で明らかになったように出荷参照売上の売上伝票の修正時に納入予定表に対する集計計算を回避したものであって、望ましい結果である。
以上で、フローチャートについての詳細説明を終了し、次に、前述の図４６のフローチャートの詳細説明で後述するとした「クエリに与えるパラメータ値を得て実行する手法」について説明する
この手法では、クエリＱ６、クエリＱ８、クエリＱ９、クエリＱ１０を使用するにあたり、それぞれのクエリのパラメータに与える値を得て、そのクエリを実行している。この手法を行うには、いま処理しているのは伝票データの何番目の本体項目であるかのデータ（このデータについてはステップＳ２の詳細説明の時に述べている）、いま処理しているＳ５のレコードセット、処理している伝票のデータ、クエリ名の４つのデータが必要になる。なお、処理している伝票のデータとは、ステップＳ５で処理対象データとして選ばれたパラメータＰＲ１かＰＲ４のことである。また、クエリ名は、図４６のフローチャートに従い処理が進んでいく過程で、どのクエリを使用するかは明らかになってきているので、クエリ名の特定方法については図４６のフローチャートのステップＳ７以降各部の詳細説明時に説明した。
この手法を用いるにはまず、使用したいクエリ（クエリＱ６、クエリＱ８、クエリＱ９、クエリＱ１０のいずれかである）を生成するときに使用したのと同じレコードをＳ５のレコードセットから抽出する（Ｓ５のレコードセットはクエリＱ３の結果であり、上記の各クエリを生成するときに使用したのも同じクエリＱ３の結果である。）。つまり、クエリＱ６を使用したいときには「集計計算の有無」フィールドがＴｒｕｅで「抽出条件」フィールドがＴｒｕｅのものを抽出し、クエリＱ８の場合は「集計計算の有無」フィールドがＴｒｕｅで「パラメータ名称」フィールドに値が記録されているレコードを抽出し、クエリＱ９の場合は「集計計算の有無」フィールドがＴｒｕｅで「抽出条件」フィールドがＴｒｕｅのものを抽出し、クエリＱ１０の場合は「集計計算の有無」フィールドがＴｒｕｅで「抽出条件」フィールドがＴｒｕｅのものを抽出する。それぞれのクエリの場合において抽出されたレコードは１つとは限らず、複数の場合もある。この抽出されたレコードをＳ５のレコードと呼ぶ。Ｓ５のレコードの全てについて順次「データタイプ」フィールドの値を調べ、それが１であれば、処理対象データの値をコードとして解釈し、対応するデータベースを検索し、パラメータに与える値を得る（この時の詳細については後述する。）。一方、「データタイプ」フィールドの値が２であれば、いま処理中の伝票データからパラメータに与える値を得る（この時の詳細についても後述する。）。
パラメータに与える値として得られたデータは、いま処理中のＳ５のレコードの「フィールドタイプ」フィールドの値に従って型を整える。つまり、「フィールドタイプ」フィールドの値が１であれば、数値とし（本発明では倍精度型である）、２であれば論理型とし、３であれば、これはコードを表すのであるから、長整数型とし、４であれば文字列とし、５であれば日付とし、６であれば時刻とし、７であれば文字列とする。この整型された値をクエリに与えるのであるが、どのパラメータにいま整型された値を与えるかは、「パラメータ名称」フィールドにその名前が記録されているパラメータであり、このパラメータは生成時にその型を決定するにあたって「ＳＱＬ定義フィールドタイプ」フィールドの値に従った。この「ＳＱＬ定義フィールドタイプ」フィールドと同一のレコードの「フィールドタイプ」フィールドの値は、定義により同じ意味を持つようになっているので、いま整型した値の型とクエリのパラメータの型は一致する。そして、各クエリの場合において示したＳ５のレコードのすべてについて上記の処理が終われば、クエリに必要なパラメータは過不足なく与えられたことになるので、そのクエリを実行することができる。具体的な実行方法は、使用するＤＢＭＳによって異なるのであるが、実行したいクエリ名と、そのクエリを実行するという旨をＤＢＭＳが定める手法に従ってＤＢＭＳに与えれば実行される。
次に前節において後述するとしたパラメータ値を得る具体的な手法について説明する。
まず、いま処理しているＳ５のレコードの「データタイプ」フィールドの値が２であった場合、つまり伝票データからパラメータに与える値を得るときの詳細について説明する。
この処理においては、まず、Ｓ５のレコードの「データの名称」フィールドの値を調べる。このフィールドには、「伝票基本」、「ヘッダー項目」、「ヘッダー未登録項目」、「本体項目」、「本体項目備考」、「関連伝票」、「属性」のいずれかの文字列が記録されている。この７つの文字列はそれぞれ図２０と図２１に示す５２から５８までのデータセクションを意味する。仮に、「データ名称」フィールドの値が「ヘッダー項目」であるとするならば、それは、パラメータに与える値は、いま処理している伝票データのヘッダー項目データセクション５３から得る、ということを意味している。以下に、上記７者の場合にそれぞれどのようにパラメータに与える値を得るかを説明する（以下この説明については、図２０、図２１を参照）。
「伝票基本」であった場合：
いま処理しているＳ５のレコードの「抽出データ」フィールドの値に従い、処理中の伝票の伝票基本データセクションの５２ａから５２ｅのいずれかの値を得る。
「ヘッダー項目」であった場合：
ヘッダー項目データセクション５３のデータのうち、「項目の実体データ」５３ｄの値を得るのであるが、ヘッダー項目データセクション５３の数は不定であるので、処理中の伝票のどのヘッダー項目データセクションから値を得るかは、「項目の順序」５３ｃの値と、いま処理中のＳ５のレコードの「項目の順番」フィールドの値が一致するヘッダー項目データセクションからとする。
「ヘッダー未登録項目」の場合：
ヘッダー未登録データセクション５４のデータのうち「未登録項目に記録する内容」５４ｃを得るのであるが、ヘッダー未登録データセクション５４の数は不定であるので、処理中の伝票のどのヘッダー未登録データセクション５４から値を得るかは、「項目の順序」５４ｂの値と、いま処理中のＳ５のレコードの「項目の順番」フィールドの値が一致するヘッダー未登録データセクションからとする。
「本体項目」の場合：
いま処理しているＳ５のレコードの「抽出データ」フィールドの値に従い、本体項目データセクション５５の「伝票番号」５５ａから「この項目の処理ＩＤ」５５ｍのいずれかの値を得る。このとき、本体項目データセクション５５の数は不定であるので、どの本体項目データセクションから値を得るかは、項目番号５５ｂの値と、この手法を開始する前に必要とされた４つのデータのうち、何番目の本体項目を処理しているかを表すデータの値が一致する本体項目データセクションからとする。
「本体項目の備考」の場合
この手法を開始する前に必要とされた４つのデータのうち、何番目の本体項目を処理しているかを表すデータが示す本体項目データセクションに含まれる本体項目備考データセクション５６から、いま処理しているＳ５のレコードの「抽出データ」フィールドの値に従い、「伝票番号」５６ａから「シリアル番号」５６ｈのいずれかの値を得る。このとき、本体項目備考データセクション５６の数は不定であるので、どの本体項目備考データセクション５６から値を得るかは、備考コード５６ｄの値と、処理中のＳ５のレコードの「項目の順番」フィールドの値が一致する本体項目備考データセクション５６からとする。
「関連伝票」の場合：
この手法を開始する前に必要とされた４つのデータのうち、何番目の本体項目を処理しているかを表すデータが示す本体項目データセクションに含まれる関連伝票データセクション５７から、いま処理しているＳ５のレコードの「抽出データ」フィールドの値に従い、「伝票番号」５７ａから「参照シリアル番号」５７ｈのいずれかの値を得る。このとき、関連伝票データセクション５７の数は不定であるので、どの関連伝票データセクション５７から値を得るかは、関連コード５７ｄの値と、処理中のＳ５のレコードの「項目の順番」フィールドの値が一致する関連伝票データセクション５７からとする。
「属性」の場合
この手法を開始する前に必要とされた４つのデータのうち、何番目の本体項目を処理しているかを表すデータが示す本体項目データセクションに含まれる属性データセクション５８から、いま処理しているＳ５のレコードの「抽出データ」フィールドの値に従い、「伝票番号」５８ａから「属性の値」５８ｇのいずれかの値を得る。このとき、属性データセクション５８の数は不定であるので、どの属性データセクション５８から値を得るかは、属性順序５８ｅの値と、処理中のＳ５のレコードの「項目の順番」フィールドの値が一致する属性データセクション５８からとする。
以上で、いま処理しているＳ５のレコードの「データタイプ」フィールドの値が２であった時の説明を終える。
次に、いま処理しているＳ５のレコードの「データタイプ」フィールドの値が１であった場合、つまり、伝票のデータをコードと解釈して他のデータベースからパラメータに与える値を得るときの詳細について説明する。
この処理においては、まず前述のＳ５のレコードの「データタイプ」フィールドの値が２であった場合の処理を行う。この処理で得られた値が目的とするテーブル（このテーブルの特定方法は後述する）のレコードを特定する為のコードであると解釈される。
次に、このコードを使い、いま処理しているＳ５のレコードの「検索対象ファイル名」フィールドと、「テーブル名」フィールドの値を使い、検索対象となるテーブルを特定し、必要に応じて「インデックス名」フィールドに示されたインデックスを使い検索する。検索の結果抽出されたレコードのフィールドのなかから、Ｓ５のレコードの「フィールド名」フィールドで指定されたフィールドの値を得る。この値をパラメータに対する値としてクエリに与える。
以上で、いま処理しているＳ５のレコードの「データタイプ」フィールドの値が１であった時の説明を終えるとともに、「クエリに与えるパラメータ値を得て実行する手法」についての説明を終える。
以上で、集計表作成ソフトウェア３６の説明を終える。なお、最後に、発明を実施するための最良の形態の記載全体を通してまだ説明していなかった、クライアントコンピュータ２に備える集計表表示用ソフトウェア２２（図１参照）について述べる。実際に本願発明による伝票管理システムを使用するときには、この集計表表示用ソフトウェア２２はなくてはならないものである。一方、本願発明の特徴は、伝票データを記録し管理するためのシステム及び方法に特徴があり、集計表のデータはここまでに説明してきた手法でそれぞれ指定された構造のデータベースに記録されているが、これらの集計表を表示するのは、「データベースに保存されたデータを表示する」という一般的な問題であり、また、具体的な手法はまったく任意であるので、本願発明を実施する時点で利用可能な任意の表示用ソフトウェアを用いればよいものである。従って、集計表表示用ソフトウェア２２の内容については特に説明を行わない。
本発明による伝票管理システムを実施するための構成全体を示すブロック図である。 伝票管理データベースに含まれるデータベースの構成を示す図である。 伝票管理データベースに含まれるデータベースの構成を示す図である。 本発明による伝票管理システムにより管理される伝票の一例として、受注伝票の例を示す図である。 本発明による伝票管理システムにより管理される伝票の一例として、出荷伝票の例を示す図である。 本発明による伝票管理システムにより管理される伝票の一例として、売上伝票の例を示す図である。 本実施の形態において用いる入力コントロール定義テーブルの内容説明図である。 本実施の形態において用いる伝票別入力コントロール定義テーブルの内容説明図である。 本実施の形態において用いる伝票ＩＤテーブルの内容説明図である。 本実施の形態において用いる計上ＩＤテーブルの内容説明図である。 本実施の形態において用いる処理ＩＤテーブルの内容説明図である。 本実施の形態において用いる伝票間参照関係テーブルの内容説明図である。 本実施の形態において用いる品目コードテーブルの内容説明図である。 本実施の形態において用いる品目属性定義テーブルの内容説明図である。 本実施の形態において用いる品目コード品目属性対応テーブルの内容説明図である。 本実施の形態において用いる単位テーブルの内容説明図である。 本実施の形態において用いる品目上位区分テーブルの内容説明図である。 本実施の形態において用いる下位区分テーブルの内容説明図である。 本実施の形態において用いる区分品目対応テーブルの内容説明書である。 本実施の形態における伝票データの構造を模式的に示した図である。 本実施の形態における伝票データの構造を模式的に示した図である。 本実施の形態における伝票データのＸＭＬ形式による構造の例を示した図である。 本実施の形態における伝票データのＸＭＬ形式による構造の例を示した図である。 本実施の形態において用いる伝票基本データテーブルの内容説明図である。 本実施の形態において用いるヘッダー項目データテーブルの内容説明図である。 本実施の形態において用いるヘッダー未登録項目データテーブルの内容説明図である。 本実施の形態において用いる本体項目データテーブルの内容説明図である。 本実施の形態において用いる本体項目備考データテーブルの内容説明図である。 本実施の形態において用いる関連伝票データテーブルの内容説明書である。 本実施の形態において用いる属性データテーブルの内容説明図である。 伝票入力用インターフェイス提供ソフトウェアが提供する機能の概要を示した図である。 （ａ）、（ｂ）は伝票入力用インターフェイス提供ソフトウェアがコンピュータのディスプレイ上に表示させるメインメニューの例を示した図である。 伝票入力用インターフェイス提供ソフトウェアがコンピュータのディスプレイ上に表示させる入力待ち画面の例を示した図である。 （ａ）、（ｂ）は伝票入力用インターフェイス提供ソフトウェアがコンピュータのディスプレイ上に表示させる処理内容選択画面の例を示した図である。 （ａ）、（ｂ）は伝票入力用インターフェイス提供ソフトウェアがコンピュータのディスプレイ上に表示させる処理内容選択画面の例を示した図である。 （ａ）、（ｂ）は伝票入力用インターフェイス提供ソフトウェアがコンピュータのディスプレイ上に表示させる本体項目入力画面の例を示した図である。 本実施の形態において用いる集計表名テーブルの内容説明図である。 本実施の形態において用いる集計要素テーブルの内容説明図である。 本実施の形態において用いる集計計算要素テーブルの内容説明図である。 本実施の形態において用いる検索対象定義テーブルの内容説明図である。 本実施の形態において用いる集計動作定義テーブルの内容説明図である。 図３８の集計要素テーブルの例で定義される集計表の例を示した図である。 本実施の形態において用いる集計表示要素テーブルの内容説明図である。 本実施の形態において用いる集計表定義データベースに含まれるクエリの内容説明図である。 本実施の形態において用いる集計表データベースに含まれるクエリの内容説明図である。 集計表作成ソフトウェアの全体の制御構造を示すフローチャートである。 図４６に示すフローチャートのステップＳ３で取得されるレコードセットの例を示した図である。 図４６に示すフローチャートのステップＳ３で取得されるレコードセットの例を示した図である。 図４６に示すフローチャートのステップＳ３で取得されるレコードセットの例を示した図である。 図４６に示すフローチャートの各ステップの内容を示すフローチャートである。 図４６に示すフローチャートの各ステップの内容を示すフローチャートである。
符号の説明
２ クライアントコンピュータ
３ データベースサーバ
４ 伝票管理データベース
５ 伝票データ
６ 表示データ
７ ネットワーク
２１ 伝票データ入力用インターフェイス提供ソフトウェア
２２ 集計表表示用ソフトウェア
２３ 基本設定管理ソフトウェア
３１ 新規計上用ソフトウェア
３２ 修正計上用ソフトウェア
３３ 伝票１枚検索ソフトウェア
３４ 伝票１項目検索ソフトウェア
３６ 集計表作成ソフトウェア
３７ 基本設定管理ソフトウェア
３８ 伝票印刷用ソフトウェア
３９ 請求書発行ソフトウェア

Claims (9)

  1. クライアント装置と、クライアント装置とネットワークで接続されたデータベースサーバ装置と、データベースサーバ装置と接続された伝票管理データベースと、で構成された伝票管理システムであって、
    クライアント装置は、必要に応じてデータベースサーバ装置を介して伝票管理データベースに格納された伝票データの提供を受けながら伝票データの入力・修正・計上・検索のためのインターフェイスを提供する機能と、入力された伝票データを所定の変換方式に従って変換してデータベースサーバ装置に送信する機能と、を有する、伝票入力用インターフェイス提供手段を備え、
    データベースサーバ装置は、クライアント装置から受信した新規計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの新規計上手段と、クライアント装置から受信した修正計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの修正計上手段と、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データを一件毎に検索しクライアント装置に送信する伝票一枚検索手段と、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データの項目を一項目毎に検索してクライアント装置に送信する伝票一項目検索手段と、を備え、
    伝票管理データベースは、個々の伝票に含まれるデータ中、計上されるデータを修飾するデータであるヘッダーの項目の種類と数を定義するデータを格納する伝票定義データベースと、伝票の種類と伝票間のデータの依存関係を定義するデータを格納する伝票関係定義データベースと、ヘッダーの項目で使用されるデータを格納するヘッダー用データ定義データベースと、個々の伝票に含まれるデータ中、計上の対象となる品目及びその属性を含む本体項目のデータを定義する本体項目用データ定義データベースと、クライアント装置から計上された伝票のデータを所定の方式に従って格納する伝票データベースと、を備えたことによって、
    クライアント装置からデータベースサーバ装置を介して計上され伝票管理データベースで管理する伝票の種類と伝票に含まれる項目と伝票間のデータの依存関係の設定とを、自由に設定可能にしたことを特徴とする、伝票管理システム。
  2. 前記伝票定義データベースは、伝票のヘッダー項目を入力するための機能を提供する入力コントロールの種類を識別するコントロールＩＤとそのデータの型や入力方式を定義する入力コントロール定義テーブルと、伝票の種類別にどの入力コントロールを使用してヘッダー項目を入力するかをコントロールＩＤと伝票ＩＤに関連づけて定義する伝票別入力コントロール定義テーブルと、を含み、
    前記伝票関係定義データベースは、伝票の種類を定義する伝票ＩＤテーブルと、伝票管理データベースに対する伝票データの計上の種類を定義する計上ＩＤテーブルと、伝票データの処理の内容を伝票の種類と計上の種類と参照伝票の種類により一意に示す処理ＩＤを計上ＩＤと伝票ＩＤと参照する伝票ＩＤに関連づけて定義する処理ＩＤテーブルと、各処理ＩＤの処理において伝票の各ヘッダー項目の値を入力するための入力コントロールの参照関係を参照伝票ＩＤと被参照伝票ＩＤとデータを得るための参照伝票の入力コントロールと被参照伝票の入力コントロールに関連づけて定義する伝票間参照関係テーブルと、を含み、
    前記ヘッダー用データ定義データベースは、ヘッダー項目に顧客データを入力するために参照する顧客コード・名称・住所を含む顧客テーブルの内容を定義する顧客テーブルと、ヘッダー項目に仕入先データを入力するために参照する仕入先コード・名称・住所を含む仕入先テーブルの内容を定義する仕入先テーブルと、ヘッダー項目に配送業者データを入力するために参照する配送業者コード・名称・住所を含む配送業者テーブルの内容を定義する配送業者テーブルと、ヘッダー項目に自社の担当者データを入力するために参照する社員コード・氏名・部署名を含む社員テーブルの内容を定義する社員テーブルと、ヘッダー項目に入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容が未確定であるときその旨記録する未登録項目テーブルと、ヘッダー項目に入力するデータが論理値でありその値が「Ｙｅｓ」又は「Ｎｏ」しかないときに選択肢の内容を定義するＹｅｓＮｏテーブルと、ヘッダー項目に入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容を定義する下位区分テーブルと、を含み
    前記本体項目用データ定義データベースは、計上の対象となる品目を識別する品目コードを定義する品目コードテーブルと、品目についての属性を入力するための属性コード・入力するデータのタイプ・単位を含む品目属性の内容を定義する品目属性定義テーブルと、どの品目にどの属性が対応するかを、品目コードと属性コードに関連づけて定義する品目コード品目属性対応テーブルと、本体項目に用いられる単位コードとその内容を定義する単位テーブルと、品目の上位区分の品目区分コードとその内容を定義する品目上位区分テーブルと、品目属性として入力するデータが論理値でありその値が「Ｙｅｓ」又は「Ｎｏ」しかないときに選択肢の内容を定義するＹｅｓＮｏテーブルと、品目について入力するデータが他のデータベースを参照して入力する場合にそのデータベースのテーブルの内容を定義する下位区分テーブルと、どの区分にどの品目が含まれるかを、品目区分コードと品目コードに関連づけて定義する区分品目対応テーブルと、を含む請求項２に記載の伝票管理システム。
  3. 前記クライアント装置の伝票入力用インターフェイス提供手段は、入力されたデータを所定の変換方式に従って変換することによって、データベースサーバ装置に対して処理の内容を指示するデータを伝票番号と処理コードと伝票ＩＤと処理ＩＤと項目番号に関連づけて記録する問合せ用データセクションと、計上する伝票を特定するための基本的なデータを伝票ＩＤと伝票番号とに関連づけて記録する伝票基本データセクションと、ヘッダー項目のデータを伝票番号とコントロールＩＤに関連づけて項目毎に記録するヘッダー項目データセクションと、ヘッダー用データがデータベース化されていない未登録のヘッダー項目のデータを伝票番号に関連づけて直接項目毎に記録するヘッダー未登録項目データセクションと、本体項目のデータを伝票番号に関連づけて項目毎に記録する本体項目データセクションと、１枚の伝票に含まれる本体項目を同時に修飾するヘッダーのデータを伝票番号と項目番号に関連づけて記録する本体項目備考データセクションと、本体項目の項目毎にデータを得た参照伝票と参照項目のデータを伝票番号と参照伝票ＩＤと参照伝票番号に関連づけて記録する関連伝票データセクションと、本体項目の項目毎に品目の属性データを、伝票番号に関連づけて記録する属性データセクションと、を含む各データセクションに振り分けて記録した伝票データとしてデータベースサーバ装置に送信し、
    前記クライアント装置から伝票データを受信した前記データベースサーバ装置は、伝票データの処理の内容を、問合せデータセクションに記録された処理ＩＤと処理コードの値から判断し、
    伝票のデータを計上する処理であれば、伝票データの新規計上手段または伝票データの修正計上手段により伝票基本データセクション・ヘッダー項目データセクション・ヘッダー未登録項目データセクション・本体項目データセクション・本体項目備考データセクション・関連伝票データセクション及び属性データセクションの各データセクションに記録されたデータを、伝票基本データセクションに記録されたデータを格納する伝票基本データテーブルと、ヘッダー項目データセクションに記録されたデータを格納するヘッダー項目データテーブルと、ヘッダー未登録データセクションに記録されたデータを格納するヘッダー未登録項目データテーブルと、本体項目データセクションに記録されたデータを格納する本体項目データテーブルと、本体項目備考データセクションに記録されたデータを格納する本体項目備考データテーブルと、関連伝票データセクションに記録されたデータを格納する関連伝票データテーブルと、属性データセクションに記録されたデータを格納する属性データブルと、で構成される伝票データベースの各テーブルに振り分けて格納し、
    伝票１枚または伝票１項目の検索を必要とする処理であれば、伝票一枚検索手段または伝票一項目検索手段により、伝票データベースにアクセスして要求されたデータをクライアント装置に送信する、請求項１に記載の伝票管理システム。
  4. 前記伝票管理データベースは、各集計表を識別する集計ＩＤとその名称を含む集計表の基本的なデータを定義する集計表名テーブルと、集計表に含める個々のフィールドを識別する集計フィールドＩＤとその内容を、集計表の基礎となる伝票ＩＤに関連づけて定義する集計要素テーブルと、集計計算を実行するときに各集計表の各フィールドに対してどのような計算を実行するかを識別する集計計算要素ＩＤとその内容を、処理ＩＤと集計ＩＤと集計フィールドＩＤに関連づけて定義する集計計算要素テーブルと、集計計算の対象となるデータの出所がデータベースである場合にそのデータベースを、集計計算要素ＩＤに関連づけて定義する検索対象定義テーブルと、各集計表に対する処理ＩＤの集計計算のデータ処理の順番・対象・計算の内容を、集計ＩＤと処理ＩＤに関連づけて定義する集計動作定義テーブルと、各集計表を表示させるときの各フィールドの表示の順番・表示の有無・レコードの並び換えを含む表示特性を、集計ＩＤと集計フィールドＩＤとに関連づけて定義する集計表示要素テーブルと、を含む集計表定義データベースを、さらに備え、
    集計を行う伝票の種類、集計表の種類、各集計表に含める項目、集計する伝票の項目と集計表の項目の対応関係、及び集計計算を実行するときにどの集計表に対して何を加算し減算するかを自由に設定できるようにした、請求項３に記載の伝票管理システム。
  5. 伝票管理データベースに備えられた集計表定義データベースの各テーブルに設定した値に基づいて、各集計ＩＤ毎の集計データを記録するためのデータを抽出して作成した各集計表テーブルを備えた集計表データベースをさらに有する、請求項４に記載の伝票管理システム。
  6. 前記集計表定義データベースは、
    前記集計動作定義テーブルから、「処理ＩＤ」フィールドの値が指定された値と合致するレコードを抽出して「集計ＩＤ」フィールドの値に従って昇順に並び換え、同一の「集計ＩＤ」フィールドの値を有するレコードがある場合はさらに規定されたデータ処理の順番に並び換えることによって一連のレコードを取得する第１のレコード抽出処理手段と、
    前記集計動作定義テーブルから、「処理ＩＤ」フィールドの値及び「集計ＩＤ」フィールドの値がそれぞれ指定された値と一致するレコードを抽出し、規定されたデータ処理の順番に並び換えることによって一連のレコードを取得する第２のレコード抽出処理手段と、
    前記集計計算要素テーブルと前記集計要素テーブルとをそれぞれの「集計フィールドＩＤ」フィールドの値を基準に内部結合し、当該内部結合の結果得られたテーブルの全てのレコードが含まれるように、当該内部結合の結果得られたテーブルと前記検索対象定義テーブルとをそれぞれの「集計計算要素ＩＤ」フィールドの値を基準として外部結合し、当該外部結合によって作成されたレコードによって構成されるテーブルから、前記集計要素テーブルに由来する「集計ＩＤ」フィールドの値が指定された値と一致し、さらに前記集計計算要素テーブルに由来する「処理ＩＤ」フィールドの値が指定された値と一致する一連のレコードを取得する第３のレコード抽出処理手段と、
    前記集計表示要素テーブルと前記集計計算要素テーブルとをそれぞれの「集計フィールドＩＤ」フィールドの値を基準に内部結合し、当該内部結合の結果得られるテーブルから、前記集計表示要素テーブルに由来する「集計ＩＤ」フィールドの値が指定された値に一致するレコードを抽出し、前記集計表示要素テーブルに規定された順番に従って並び換えることによって一連のレコードを取得する第４のレコード抽出処理手段と、
    をさらに有し、第１のレコード抽出処理手段によって伝票データに含まれる処理ＩＤ毎の集計動作を抽出し、第２のレコード抽出処理手段によって伝票データに含まれる処理ＩＤの集計動作中指定した集計ＩＤで特定される集計表に対する動作のみを抽出し、第３のレコード抽出処理手段によって指定した処理ＩＤを有する伝票計上処理においてその伝票データを集計ＩＤで特定される集計表に集計計算するときどのように計算するかを示すレコードセットを取得し、第４のレコード抽出処理手段によって指定した集計ＩＤで特定される集計表を表示するときにその集計表に含まれる各フィールドがどのような表示特性をもっているかを示すレコードセットを取得する、請求項５に記載の伝票管理システム。
  7. 前記集計表定義データベースにおいて、
    前記集計要素テーブルは、少なくとも、すべての集計表についてそれぞれの集計表の各フィールドの識別コードを記録する「集計フィールドＩＤ」フィールドと、各集計表を識別する集計ＩＤを記録する「集計ＩＤ」フィールドと、集計フィールドＩＤで識別される集計表の各フィールドの名称を記録する「フィールド名称」フィールドと、各フィールドのデータ型を記録する「フィールドタイプ」フィールドと、集計表に集計計算をするときに集計表の集計対象のレコードを選ぶ際の抽出条件としてその集計フィールドＩＤのフィールドを加えるか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「抽出条件」フィールドと、その集計フィールドＩＤのフィールドを抽出条件とするときのパラメータ名を記録する「パラメータ名称」フィールドと、集計計算のときその集計フィールドＩＤのフィールドに対して伝票データを上書きせずに加減算するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「集計対象」フィールドと、集計表からレコードを削除するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「レコード削除の真偽」フィールドと、集計表を表示するときにその集計フィールドＩＤのフィールドを表示すべきレコードとして抽出するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「表示用抽出条件」フィールドと、を有し、
    前記集計計算要素テーブルは、少なくとも、「処理ＩＤ」フィールドと、「集計ＩＤ」フィールドと、同一の行で定義されている「処理ＩＤ」フィールドの値で示す処理が同一の行で定義されている「集計ＩＤ」フィールドの値で示す集計表に対して伝票データ中のどのデータを集計するかを一意に識別するコードを記録する「集計計算要素ＩＤ」フィールドと、「集計フィールドＩＤ」フィールドと、その集計フィールドＩＤで特定されるフィールドに対して伝票のデータを集計するか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「集計計算の有無」フィールドと、を有し、
    前記集計表示要素テーブルは、少なくとも、「集計ＩＤ」フィールドと、「集計フィールドＩＤ」フィールドと、集計表に含まれる各レコードを並べるときにそのレコードが指し示すフィールドの値により並び換えるか否かをＴＲＵＥ又はＦＡＬＳＥを表す値で記録する「ＤｏＳｏｒｔ」フィールドと、並び換えを行うときに依存するフィールドが複数ある場合の優先順位を規定する「ＳｏｒｔＰｒｉｏｒｉｔｙ」フィールドと、並び換えが行われるときに依存するフィールドが複数ある場合の優先順位を昇順か降順かを表す値で記録する「ＡＳＣｏｒＤＥＳＣ」フィールドと、を有し、
    前記データベースサーバは、
    操作の対象とする集計表を表す集計ＩＤを前記第４のレコード抽出処理手段に与えて取得した一連のレコード（以下「第４の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルから集計表を表示するために必要なデータを抽出するためのデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第４の取得レコードの「フィールド名称」フィールドに記録されている値が示すすべてのフィールドのデータを当該集計表テーブルから抽出するにあたり、第４の取得レコードの「表示用抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とを一致させ、当該条件に合致するレコードを当該集計表テーブルから抽出して、第４の取得レコードの「ＤｏＳｏｒｔ」フィールドの値がＴＲＵＥのレコードの「ＳｏｒｔＰｒｉｏｒｉｔｙ」フィールドで示される並び換えの条件の優先順位と「ＡＳＣｏｒＤＥＳＣ」フィールドで示される昇順あるいは降順の区別に従って並び換えるＳＱＬ文を表す文字列を生成し、第１のデータ操作手段として前記集計表データベースに保存するための、第１のＳＱＬ文生成手段と、
    集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを前記第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルから集計計算の対象となるレコードがあるか否かを確認するためのデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とが一致する当該集計表テーブルのレコードの任意のフィールドを抽出するＳＱＬ文を表す文字列を生成し、第２のデータ操作手段として前記集計表データベースに保存するための、第２のＳＱＬ文生成手段と、
    集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルからレコードを削除するデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「レコード削除の真偽」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値のいずれかが０または０以下となる当該集計表テーブルのレコードを削除するＳＱＬ文を表す文字列を生成し、第３のデータ操作手段とし前記集計表データベースに保存するための、第３のＳＱＬ文生成手段と、
    集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルに新たにレコードを追加するデータ操作手段を前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「パラメータ名称」フィールドに値が記録されているレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を新たに記録すべき値として当該集計表テーブルにレコードを追加するＳＱＬ文を表す文字列を生成し、第４のデータ操作手段として前記集計表データベースに保存するための、第４のＳＱＬ文生成手段と、
    集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルのレコードに計上した伝票のデータを加算又は減算するデータ操作手段を前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値が一致する当該集計表テーブルのレコードに対して加算または減算を行うために、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「集計対象」フィールドの値がＴＲＵＥである条件を満たすレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を加算または減算しさらに前記の条件を満たさず第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「集計対象」フィールドの値がＦＡＬＳＥであり「抽出条件」フィールドがＴＲＵＥである条件をも満たさないレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドに対してそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値を新たな値として与えるＳＱＬ文を表す文字列を生成し、第５のデータ操作手段として前記集計表データベースに保存するための、第５のＳＱＬ文生成手段と、
    集計計算の対象とする集計表を表す集計ＩＤと集計表に対する集計計算の契機となった処理を表す処理ＩＤを第３のレコード抽出処理手段に与えて得られた一連のレコード（以下「第３の取得レコード」という）に基づき、当該集計ＩＤが表す集計表のデータを保持する集計表テーブルのレコードに計上した伝票のデータを上書きするデータ操作手段を生成して前記集計表データベースに保存するためのＳＱＬ文生成手段であって、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「抽出条件」フィールドの値がＴＲＵＥであるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべてのフィールドに記録された値とそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値とが一致するレコードに対して上書きを行うために、第３の取得レコードの中で「集計計算の有無」フィールドの値がＴＲＵＥであり「パラメータ名称」フィールドに値のあるレコードの「フィールド名称」フィールドに記録されている値によって示されるすべての当該集計表テーブルのフィールドの保持している値をそれぞれ「パラメータ名称」フィールドに記載されている値をその名称とするパラメータに与えられた値によって置き換えるＳＱＬ文を表す文字列を生成し第６のデータ操作手段として前記集計表データベースに保存するための、第６のＳＱＬ文生成手段と、をさらに備えた、請求項６に記載の伝票管理システム。
  8. 前記集計表データベースに、前記第１のＳＱＬ文生成手段によって生成された第１のデータ操作手段と、前記第２のＳＱＬ文生成手段によって生成された第２のデータ操作手段と、前記第３のＳＱＬ文生成手段によって生成された第３のデータ操作手段と、前記第４のＳＱＬ文生成手段によって生成された第４のデータ操作手段と、前記第５のＳＱＬ文生成手段によって生成された第５のデータ操作手段と、前記第６のＳＱＬ文生成手段によって生成された第６のデータ操作手段と、をさらに有した請求項７に記載の伝票管理システムにおいて、
    パラメータとして、伝票データと、当該伝票データが新規計上又は参照計上と修正計上とのいずれであるかを示す識別子と、集計計算の対象となる集計表を表す集計ＩＤの値と、当該伝票データが修正計上に係る場合に前記伝票管理データベースから抽出された修正前の伝票データと、を受け取るステップ１と、
    ステップ１で受け取った伝票データの本体項目について、ステップ３以降の処理が全ての本体項目について終了しているか否か判断し、終了していなければステップ３の処理に進ませ、終了していれば終了処理に進ませるステップ２と、
    ステップ２でステップ３以降が未処理であると判断した本体項目の処理ＩＤを、修正計上に係るものであれば伝票データの問合せデータセクションから取得し新規計上又は参照計上にかかるものであれば伝票データの本体項目データセクションから取得して、その処理ＩＤを前記集計表を表す集計ＩＤの値によって前記第１のレコード抽出手段又は前記第２のレコード抽出手段に与えて第１のレコードセットを取得するステップ３と、
    ステップ３で取得した第１のレコードセットのレコードの数を知り、レコードの数の回数だけ以降の処理を繰り返すためすべてのレコードが以降の処理を終了しているか否か判断し、ステップ５以降の処理が未処理であれば処理を行うステップ５に進ませ、ステップ５以降の処理が終了していれば、レコード削除の有無を判断するステップ１５に進ませるステップ４と、
    取得した第１のレコードセットに含まれる集計ＩＤから集計計算の対象となる集計表テーブルを特定し、取得した第１のレコードセットに含まれる集計ＩＤと処理ＩＤを前記第３のレコード抽出手段に与えて第２のレコードセットを取得し、取得した第２のレコードセットに含まれるレコードの「処理対象」フィールドの値に従って処理対象の伝票データが計上された伝票データであるのか修正前の伝票データであるのかを選択するステップ５と、
    ステップ５で特定された集計表テーブルの親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致するか否か判断するステップ６と、
    ステップ６で親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致すると判断した場合に、第２のデータ操作手段にパラメータを与えて集計計算対象の集計表テーブルにレコードがあるかないか判断するステップ７と、
    ステップ７で集計計算対象の集計表テーブルにレコードがあると判断した場合に、第１のレコードセットの「データ処理動作」フィールドの記録された値に従って、前記第５のデータ操作手段または前記第６のデータ操作手段にパラメータを与えて、既存のレコードの上書き・加算・減算のいずれかを実行するステップ８と、
    ステップ７で集計計算対象の集計表テーブルにレコードがないと判断した場合に、第１のレコードセットの「データ処理動作」フィールドに記録された値に従って、前記第４のデータ操作手段にパラメータを与えて、レコードの新規追加を実行するステップ９と、
    ステップ６で親の伝票ＩＤと集計計算の対象となる伝票データの伝票ＩＤとが一致しないと判断した場合に、現在処理中の本体項目のデータに関連伝票データが含まれているか否か判断し、含まれていなければステップ４に戻らせ、含まれていればステップ１１に進ませるステップ１０と、
    ステップ１０で現在処理中の本体項目のデータに関連伝票データが含まれていると判断した場合に、ステップ５で特定された集計表テーブルの親の伝票ＩＤと処理中の本体項目が参照している伝票の伝票ＩＤとが一致するか否かを判断し、一致しなければステップ４に戻らせ、一致していればステップ１２に進ませるステップ１１と、
    ステップ１０で、ステップ５で特定された集計表テーブルの親の伝票ＩＤと処理中の本体項目が参照している伝票の伝票ＩＤとが一致すると判断した場合に、第２のデータ操作手段にパラメータを与えて集計計算対象の集計表テーブルにレコードがあるかないか判断するステップ１２と、
    ステップ１２で集計計算対象の集計表テーブルにレコードがあると判断した場合に、第１のレコードセットの「データ処理動作」フィールドの記録された値に従って、前記第５のデータ操作手段または前記第６のデータ操作手段にパラメータを与えて、既存のレコードの上書き・加算・減算のいずれかを実行するステップ１３と、
    ステップ１２で集計計算対象の集計表テーブルにレコードがないと判断した場合に、第１のレコードセットの「データ処理動作」フィールドに記録された値に従って、前記第４のデータ操作手段にパラメータを与えて、レコードの新規追加を実行するステップ１４と、
    ステップ４ですべてのレコードが以降の処理を終了していると判断した場合に、第１のレコードセットに含まれるレコードの数からその回数だけ第３のデータ操作手段により、集計表テーブルのレコード中削除条件に合致したものを削除するステップ１５と、
    を有する、伝票管理システムにおける集計表の集計計算方法。
  9. クライアント装置と、クライアント装置とネットワークで接続されたデータベースサーバ装置と、データベースサーバ装置と接続された伝票管理データベースと、で構成された伝票管理システムにおいて、
    必要に応じてデータベースサーバ装置を介して伝票管理データベースに格納された伝票データの提供を受けながら伝票データの入力・修正・計上・検索のためのインターフェイスを提供するステップと、入力された伝票データを所定の変換方式に従って変換してデータベースサーバ装置に送信するステップとを、クライアント装置に実行させ、
    クライアント装置から受信した新規計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの新規計上ステップと、クライアント装置から受信した修正計上する伝票データを所定の格納方式に従って伝票管理データベースに格納する伝票データの修正計上ステップと、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データを一件毎に検索しクライアント装置に送信する伝票一枚検索ステップと、クライアント装置からの指示を受けて伝票管理データベースにアクセスして伝票データの項目を一項目毎に検索してクライアント装置に送信する伝票一項目検索ステップとを、データベースサーバ装置に実行させ、
    個々の伝票に含まれるデータ中、計上されるデータを修飾するデータであるヘッダーの項目の種類と数を定義するデータを格納する伝票定義データベースと、伝票の種類と伝票間のデータの依存関係を定義するデータを格納する伝票関係定義データベースと、ヘッダーの項目で使用されるデータを格納するヘッダー用データ定義データベースと、個々の伝票に含まれるデータ中、計上の対象となる品目及びその属性を含む本体項目のデータを定義する本体項目用データ定義データベースと、クライアント装置から計上された伝票のデータを所定の方式に従って格納する伝票データベースと、で伝票を管理するデータベースとして伝票管理データベースを機能させるステップを実行させる、伝票管理用ソフトウェア。
JP2004145647A 2004-05-14 2004-05-14 伝票管理システム及び伝票管理用ソフトウェア Pending JP2005327136A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004145647A JP2005327136A (ja) 2004-05-14 2004-05-14 伝票管理システム及び伝票管理用ソフトウェア

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004145647A JP2005327136A (ja) 2004-05-14 2004-05-14 伝票管理システム及び伝票管理用ソフトウェア

Publications (1)

Publication Number Publication Date
JP2005327136A true JP2005327136A (ja) 2005-11-24

Family

ID=35473446

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004145647A Pending JP2005327136A (ja) 2004-05-14 2004-05-14 伝票管理システム及び伝票管理用ソフトウェア

Country Status (1)

Country Link
JP (1) JP2005327136A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007304809A (ja) * 2006-05-10 2007-11-22 Fuji Xerox Co Ltd 表示装置、画像処理装置、表示方法、及びプログラム
JP2008129844A (ja) * 2006-11-21 2008-06-05 Nec Informatec Systems Ltd ストアドプロシージャジェネレート装置、方法、プログラム、及びシステム
JP2008165525A (ja) * 2006-12-28 2008-07-17 Sap Ag コスト管理システム
US8142866B2 (en) 2007-08-29 2012-03-27 Denso Corporation Display panel, method for producing the same and composition of ink used by the method for producing the same
JP2017102957A (ja) * 2017-02-01 2017-06-08 富士通株式会社 集計装置および集計プログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007304809A (ja) * 2006-05-10 2007-11-22 Fuji Xerox Co Ltd 表示装置、画像処理装置、表示方法、及びプログラム
JP2008129844A (ja) * 2006-11-21 2008-06-05 Nec Informatec Systems Ltd ストアドプロシージャジェネレート装置、方法、プログラム、及びシステム
JP2008165525A (ja) * 2006-12-28 2008-07-17 Sap Ag コスト管理システム
JP4695065B2 (ja) * 2006-12-28 2011-06-08 エスアーペー アーゲー コスト管理システム
US8142866B2 (en) 2007-08-29 2012-03-27 Denso Corporation Display panel, method for producing the same and composition of ink used by the method for producing the same
JP2017102957A (ja) * 2017-02-01 2017-06-08 富士通株式会社 集計装置および集計プログラム

Similar Documents

Publication Publication Date Title
US20210209157A1 (en) System and method for non-programmers to dynamically manage multiple sets of xml document data
US6742054B1 (en) Method of executing a data transformation specification
US5455945A (en) System and method for dynamically displaying entering, and updating data from a database
US7401094B1 (en) Automated generation of dynamic data entry user interface for relational database management systems
JP4594306B2 (ja) 自己記述型ビジネスオブジェクト
JP5324797B2 (ja) データ管理システム
US20050091276A1 (en) Dynamic meta data
JP2001306373A (ja) データベース設計システム、データベース設計方法、記録媒体、及び表示方法
KR20010072019A (ko) 데이터 웨어하우스에 대한 애그리깃 레벨 및 크로스프로덕트 레벨을 선택하는 방법 및 장치
MXPA01008947A (es) Especificacion para convertidor de codigo abap (programacion avanzada de aplicacion de negocios).
JP4945196B2 (ja) データ管理システム
EP1646949A2 (en) Service management of a service oriented business framework
WO2005015440A2 (en) Extending service-oriented business frameworks
EP1646955A2 (en) Meta model for an enterprise service architecture
US20030204503A1 (en) Connecting entities with general functionality in aspect patterns
EP1646958A2 (en) Side-effect modeling
US7890540B2 (en) Browsing meta data for an enterprise service framework
JP2005327136A (ja) 伝票管理システム及び伝票管理用ソフトウェア
EP1143357A2 (en) Method for defining iteration configuration in a data transformation specification
JP2001028005A (ja) データウェアハウスにおける検索・集計高速化を実現するデータ格納、更新、検索、集計方法
JP2004303117A (ja) 名寄せデータベース設計支援方法およびシステム
EP1143348A2 (en) Method for defining a data transformation specification
JP2000187665A (ja) データベースシステムにおける情報導出方法及び情報導出システム、並びに記憶媒体
Saaksvuori et al. Product lifecycle management systems
Farzbod An implementation of inventory system for Lafene Health Center based on dbase III plus