JP2006500690A

JP2006500690A - ビジネスデータの自動記憶方法およびビジネスデータの自動記憶システム

Info

Publication number: JP2006500690A
Application number: JP2004540596A
Authority: JP
Inventors: フォンツィンマーマンペーター; ヴァルマイアーライナー; デュヴェルオラフ; ヘンリッヒディルク; ショルマーティン; シュヌックフォルカー; ノヴォトニーディートマー; リップフォルカー
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2002-09-27
Filing date: 2003-09-08
Publication date: 2006-01-05
Anticipated expiration: 2023-09-08
Also published as: US20060155550A1; WO2004032006A2; CA2500393C; AU2003273837A1; AU2003273837B2; CA2500393A1; EP1403794A1; EP1546963A1; JP4722485B2

Abstract

本発明は、コンピュータシステムを用いてビジネスイベントに関するデータを１つまたは複数のビジネスアプリケーションからのアクセスのために記憶し、ビジネスイベントに１つずつＩＤコードを割り当て、コンピュータシステム内で１つまたは複数のビジネスイベントクラスを種々のデータ構造によって表す、ビジネスイベント記録時の伝票の自動ファイリング方法に関する。ここで本発明の方法は、第１のステップでビジネスイベントに関するデータから、１つまたは複数のビジネスイベントクラスおよび１つまたは複数のビジネスアプリケーションごとに専用の構造を有する少なくとも１つの入力データセットを形成し、第２のステップで少なくとも１つの入力データセットを１つまたは複数のビジネスアプリケーションからコンフィグレーションできる構成の出力データセットへ変換し、第３のステップで出力データセットを対応するＩＤコードとともに記憶する。こうしてＩＤコードを参照することにより少なくとも２つのビジネスアプリケーションによって出力データセットを完全にまたは部分的に読み出すことができる。

Description

本発明は、コンピュータシステムを用いてビジネスイベントに関するデータを１つまたは複数のビジネスアプリケーションからのアクセスのために記憶し、ビジネスイベントに１つずつＩＤコードを割り当て、コンピュータシステム内で１つまたは複数のビジネスイベントクラスを種々のデータ構造によってシミュレートする、ビジネスイベントの伝票の自動ファイリング方法に関する。

前述の方法は例えば会計事務の分野で知られる。この種の方法はコンピュータシステム、特に有利にはデータバンクシステムを用いて自動で行われる。

会計事務の主たる役割は、企業による財の創造の戦略的な全てのプロセスのチェーンとその会計事務プロセスとを記録することである。種々の情報が単一の言語、例えば勘定の概念によって書き留められ評価される。このとき１つのビジネスイベントは財産が上昇（入金）または低下（出金）する１つの商取引過程を意味する。こうしたビジネスイベントにはさらに所定のクラスが割り当てられ、１つのクラス内では個々のビジネスイベントに対応するデータがほぼ均一な構造を有する。典型的なクラスとして例えば個人会計、物資の取引、生産額などが挙げられる。

会計事務の規則性を保証するために、記録は完全かつ正確に行われなければならない。伝票はこの規則性の証明に用いられる。その際にビジネスイベントの全ての記録は所定の商取引評価メソッドに則って伝票により文書化され、そのそれぞれに１つずつＩＤコードが割り当てられる。種々の商取引評価メソッドの例として、独国の商法またはＩＡＳに準拠したビジネスイベントの評価や、法規またはコンツェルン内部のプロトコルに準拠したコンツェルン会社間の評価、種々の通貨における評価などが挙げられる。

２つめの例を詳細に説明する。同じコンツェルン内部に２つの会社Ａ，Ｂが存在しているとする。Ａ社はＢ社に製造コストＺの製品Ｘを価格Ｙで販売した。法則にしたがってこのイベントは次のように記帳される。すなわち、Ｂ社の製品Ｘの残高勘定がＹだけ増加し、損益計算において同様に借方Ｙが生じる。コンツェルン内部の法則によればＢ社の製品Ｘの残高勘定はＺだけ増加し、損益計算の借方はＹであり貸方はＹ−Ｚとなる。

所定のビジネスイベントが複数の異なる商取引評価メソッドにしたがって評価される場合には、相応に複数の異なる伝票（証明書）が形成される。この方式により複数の伝票にわたって所定の属性に関して収集された統合会計データがプロセスデータに対して監査されることが保証される。

種々の目的を満足するために、商取引評価メソッドを用いる会計事務の分野では、以下ビジネスアプリケーションと称する商取引評価プロセス、例えば成果または費用の計算、貸借対照、損益計算などを行い、これらをそれぞれ台帳や原簿へ記帳する。それぞれの計算および帳簿は時間や項目の詳細度に関して異なる要求を有する。しかしそれぞれの会計すなわち各ビジネスアプリケーションの帳簿合わせは簿記およびその結果の使用にとって重要な意義を有しており、ソフトウェアによる正規の簿記の基本則に相応する。

会計事務へのさらなる要求は、監査および記録、つまり商品およびサービスの入荷および出荷をシミュレートする簿記過程がロジスティクスプロセスの実行をできるだけ阻害しないようにすることである。

以下にＥＲＰ（Enterprise Resource Planning）ソフトウェアと称するビジネスプロセスを支援するソフトウェアはこうした会計事務への典型的な要求を満足する。これは１つの企業のロジスティクスプロセスと会計事務とを同じＥＲＰシステムで実行することにより行われる。会計事務はロジスティクスプロセスに密接に関連しており、直接にトランザクションとして記録される。このことは伝票に含まれるべきデータが完全にならないと記憶されないことを意味する。ロジスティクスプロセスはＥＲＰソフトウェアにおいてシミュレートされるので、一般に会計事務の概念、例えば勘定に関連している。その際に会計事務の種々の会計は記録のための固有の伝票に記載される。

ただしこうした手段にはデータ技術上の一連の欠点が存在する。
ａ）全てのロジスティクスプロセスが唯一のＥＲＰシステム内部で進行するという条件は一般には満足されない。多くの企業が歴史的に異なって成長してきた地域性を有するシステムを用いており、その内部で多くの専用プロセスが展開されているからである。会計事務の概念を認識していないこうした外的なプロセスを記録するには、ローカルなＥＲＰシステムでは不充分である。したがってしばしば多数の管理プログラムが必要となる。
ｂ）ローカルなＥＲＰシステムのデータ構造は固定であることにより、企業はその商取引概念をローカルなＥＲＰシステムの定義および技術的特性へ適合化させることを強いられる。このことは特に前項ａ）で示したシステムの地域性のもとで大きな問題となる。
ｃ）各ビジネスアプリケーションにおいて種々の会計につき個々に伝票を発行することになるので、きわめて大きなデータ容量と時間コストとがかかる。会計を個別に行っているため、各会計間の帳簿合わせに対しても大きな問題が生じる。
ｄ）会計事務から直接にトランザクションを記述することは使用されるコンピュータシステム、ひいては展開すべきデータ技術的なロジスティクスプロセスに大きな負荷をかける。特に記録の際にシステム停止などのエラーが会計事務に生じると、プロセス実行が阻害される。

これらの従来技術から出発して、本発明は、冒頭に言及した形式の方法を改善し、前述の欠点を少なくとも部分的に排除することを課題とする。

この課題は、冒頭に言及した形式の本発明の方法において、第１のステップでビジネスイベントに関するデータから、１つまたは複数のビジネスイベントクラスおよび１つまたは複数のビジネスアプリケーションごとに専用の構造を有する少なくとも１つの入力データセットを形成し、第２のステップで少なくとも１つの入力データセットを１つまたは複数のビジネスアプリケーションからコンフィグレーションできる構成の出力データセットへ変換し、第３のステップで出力データセットを対応するＩＤコードとともに記憶し、ＩＤコードを参照することにより少なくとも２つのビジネスアプリケーションによって出力データセットを完全にまたは部分的に読み出すことにより解決される。

したがって本発明の対象となるのは、コンピュータシステムを用いてビジネスイベントに関するデータを１つまたは複数のビジネスアプリケーションからのアクセスのために記憶し、ビジネスイベントに１つずつＩＤコードを割り当て、コンピュータシステム内で１つまたは複数のビジネスイベントクラスを種々のデータ構造によってシミュレートする、ビジネスイベントの伝票の自動ファイリング方法において、第１のステップでビジネスイベントに関するデータから、１つまたは複数のビジネスイベントクラスおよび１つまたは複数のビジネスアプリケーションごとに専用の構造を有する少なくとも１つの入力データセットを形成し、第２のステップで少なくとも１つの入力データセットを１つまたは複数のビジネスアプリケーションからコンフィグレーションできる構成の出力データセットへ変換し、第３のステップで出力データセットを対応するＩＤコードとともに記憶し、ＩＤコードを参照することにより少なくとも２つのビジネスアプリケーションによって出力データセットを完全にまたは部分的に読み出すことを特徴とする方法である。

さらに本発明は上述の方法を実行する請求項１１記載のコンピュータシステム、請求項１２記載のコンピュータプログラム、請求項１４記載のコンピュータプログラム製品、および上述の方法から得られる請求項１６記載の電子データ構造（電子伝票）をも対象としている。

本発明は、本発明の方法を実行するプログラムをコンピュータへロードするデータ担体のコンピュータプログラムであってもよい。プログラムはソースコード、オブジェクトコードまたは混合コードの形式を有しており、完全にまたは部分的に圧縮されている。データ担体は、プログラムを含むのに適したユニットまたは装置、例えばＣＤ−ＲＯＭ、半導体ＲＯＭまたはＤＶＤ−ＲＯＭなどのＲＯＭ、フロッピーディスクまたはハードディスクなどの磁気記憶媒体であってもよいし、電気線路または光ケーブルを伝送される電気信号または光信号などのキャリアや、無線などの電磁波、またはその他の適切な媒体であってもよい。プログラムが信号に含まれてケーブルまたは媒体またはその他の手段を介して伝送される場合には、このケーブルまたは媒体またはその他の手段がデータ担体となる。これに代えてプログラムを集積回路へ組み込み、本発明の方法を実行させてもよい。

本発明の方法およびシステムの有利な実施形態は従属請求項に記載されている。カテゴリごとに従属請求項に記載されているそれぞれの特徴や、独立請求項に記載されている本発明の主たる特徴は、個別でも、または任意に組み合わせても、本発明の前述の課題を解決する手段となる。

以下では、本発明の方法およびこれを実行するプログラムコードを“アカウンティングエンジン”、出力データセットを“伝票”とも称する。

本発明の方法は会計事務用のＥＲＰソフトウェアのワークツールとして個人または私立団体または法人（以下まとめて“会社”と略する）での電子的な伝票のファイリングに使用することができる。これはコンピュータシステムにより行われる。コンピュータシステムとは、本発明では、単一のコンピュータ（ＰＣ、ラップトップコンピュータ）であってもよいし、複数のコンピュータから成るネットワークであってもよい。ネットワークはインターネットを利用しているものも含む。有利にはアカウンティングエンジンは会社内のコンピュータネットワークで使用される。こうした会社内のコンピュータシステムで個々のビジネスイベントに関するデータが例えばＥＲＰソフトウェアによって記憶される。アカウンティングエンジンはコンピュータシステム内で実行されるプログラムコードとして機能し、個々のビジネスイベントに関するデータ（基礎データ）から入力データセットを形成し、これをコンピュータ上で動作する会計事務の複数のアプリケーションプログラム（ビジネスアプリケーション）によって読み出し可能な出力データセット（伝票）へ変換し、基礎データとは別に記憶する。

伝票は１つまたは複数のビジネスアプリケーションによりコンフィグレーションされる。このためにビジネスアプリケーションにはユーザとのインタラクションのための問い合わせルーチンが設けられている。伝票のコンフィグレーションは、ユーザに対してモニタに選択可能なデータ、フィールドまたは関数のリストを表示し、そのなかからキーボード、マウスまたは音声入力などのインタラクションを介して１つまたは複数を選択させることにより実現される。これらは伝票として記憶されたり、入力データセットを伝票の形式へ変換する際に適用されたりする。有利には伝票は少なくとも２つのビジネスアプリケーションからアクセスできるように構成されている。

本発明のこうした全プロセスにより、伝票の冗長ファイリングを省略できるので、メモリスペースを大幅に節約することができる。基礎データは既にコンピュータシステム内に記憶されているかユーザからインタフェースを介して入力されており、さらなる処理が行われたりデータ伝送部を介して伝送されたりする。

変換過程では、入力データはコンピュータシステム内に記憶されている別のデータにより、種々のビジネスアプリケーションの要求に応じて完全にまたは部分的に変更または補完される。このときビジネスアプリケーションはビジネスイベントを評価する商取引の手法を設定することができる。ビジネスアプリケーションごとに異なる評価を選択してよい。このことにより同一のビジネスイベントを複数の異なる手法で評価できる。１つの評価に対しては１つの伝票しか形成されないが、１つの伝票に複数のビジネスアプリケーションがアクセスして読み出すことができる。本発明の伝票は１つのビジネスアプリケーションしか当該の伝票にアクセスしない場合には必要とされるよりも多くのデータを含みうるが、もちろんつねにさまざまな手法での評価を設定しなくても良く、複数のビジネスアプリケーションに対して１つの伝票が形成される場合には、全体としては生じるデータは少なくなる。このことは“少なくとも２つのビジネスアプリケーションからアクセスできる”ことの利点に相応する。

第１の有利な実施形態では、本発明の方法の第１のステップは第１のプログラムモジュールを用いて実行され、第２のステップは第２のプログラムモジュールを用いて実行される。ここで専用の構造を有する入力データセットは第１のプログラムモジュールからインタフェースを介して第２のプログラムモジュールへ供給される。また、複数のビジネスアプリケーションが第３のプログラムモジュールまたはさらに別のプログラムモジュールとして構成されてもよい。これは第２のプログラムモジュールと共働し、本発明の方法の第２のステップでの１つまたは複数の第３のプログラムモジュールによる変換過程をインタフェースを介して調整できるように構成されている。

特に有利には、第２のプログラムモジュールは、少なくとも２つのビジネスアプリケーションによって選択可能な伝票のデータを、データ要求により、インタフェースを介してさらなる処理および／または表示のために１つまたは複数の第３のプログラムモジュールおよび／または別のプログラムモジュールへ供給するように構成されている。選択可能なデータは第３のプログラムモジュールまたは別のプログラムモジュールによって選択される。本発明の第２のステップで得られた伝票は有利にはトランザクションとして記憶される。有利には複数のビジネスアプリケーションに対する伝票は１つまたは複数のテーブルを備えた専用のデータバンク構造を有する。特に有利には、会計事務の種々の仕訳に対する伝票はそれぞれ異なるデータ領域を有する。

仕訳とは記帳項目のセットをテーブルにまとめたものであり、例えば債権、債務、費用、収益、商品入荷、商品出荷などの領域から成る。例えば伝票は費用および収益についての第１のデータ領域、物資の現在高についての第２のデータ領域、債権および債務についての第３のデータ領域を有する。第１の領域には顧客、製品、費用状況など、第２の領域には製品、集積方式、集積場所など、第３の領域には顧客などのデータが含まれる。これらのデータは説明のための例示にすぎず、必要に応じて任意に変更または補完できる。伝票にはさらに複数の仕訳に共通するデータを備えた領域（“ヘッド領域”）が設けられており、ここにはＩＤコード、法人名（団体名）、記帳日、処理日、担当者名などが記載される。異なるデータ領域に当該の仕訳に関連する同じビジネスイベント情報を記憶することもできる。伝票を物理的なメモリに格納する際には、有利には１つまたは複数のテーブル構造を有するデータバンク構造が採用される。

第２の有利な実施形態では、伝票に含まれているデータに少なくとも関数が適用される。この関数は例えば伝票の決済または伝票に含まれている顧客グループの検査に用いられる。有利には関数はプログラムモジュール内に選択可能に格納されている。特に有利には少なくとも１つの関数を別のプログラムモジュールを介してコンフィグレーション可能である。関数の選択は、ユーザに対してモニタに選択可能な関数のリストを表示し、そのなかからキーボード、マウスまたは音声入力などのインタラクションを介して１つまたは複数を選択させることにより実現される。また標準的に全ての伝票に適用可能な関数を設けてもよい。少なくとも１つの関数のコンフィグレーションは前述の場合と同様にパラメータを選択することにより実現される。例えば１つの伝票に複数の法人の記帳が行われる場合には、選択テーブルごとに決済を検査する関数をコンフィグレーションし、選択された法人の口座の決済を１つずつ検査すると有利である。

本発明を図１，図２に則して以下に詳細に説明する。ただし実施例は本発明を限定するものではない。

図１には本発明の方法を実行するコンピュータシステムの概略図が示されている。図２には本発明の方法を実行するコンピュータプログラムのブロック図が示されている。図３には伝票がデータソースによって作成され、ビジネスアプリケーションからアクセスされる様子が概略的に示されている。図４には商品購入の実施例における入力データセットの内容および伝票の構造の概略図が示されている。図５には商品販売の実施例における入力データセットの内容および伝票の構造の概略図が示されている。

図１にはコンピュータ１０３を含むコンピュータシステム１０１が示されている。コンピュータはＣＰＵ１０５および作業メモリ１０２を有しており、このメモリにはＣＰＵ１０５によって実行されるＥＲＰソフトウェア１１１がロードされている。ＥＲＰソフトウェア１１１はそれぞれ１つまたは複数のプログラムモジュールとして構成されたビジネスイベントモジュール１１０とアカウンティングエンジン１０６とビジネスアプリケーションモジュール１０９とを有している。コンピュータシステム１０１は入力手段１１３、出力手段１１２、コンピュータ１０３をネットワークの形態の別のコンピュータ１１４へ接続するネットワークコネクション１０４を有している。ここでネットワークコンピュータ１１４もビジネスイベントに関するデータを入出力する入出力ユニット、またはアカウンティングエンジンをコンフィグレーションし、入力マスクを表示し、結果を出力し、アカウンティングエンジンを実行する手段を有している。またビジネスイベントに関するデータおよびビジネスアプリケーションを含みＥＲＰソフトウェア１１１からアクセス可能なデータバンク１０７と、伝票を記憶する伝票メモリ１０８とが設けられている。伝票メモリ１０８はデータバンク１０７の一部であってもよい。プログラムモジュール１０６，１０９，１１０はデータバンク１０７へアクセス可能であり、プログラムモジュール１０６，１０９は付加的に伝票メモリ１０８へもアクセス可能である。

この種のコンピュータシステムにより本発明の方法が次のように実行される。プログラムモジュール１１０は所定のビジネスイベントに関するデータをＩＤコードとともにアカウンティングエンジン１０６へ供給する。このときデータはデータバンク１０７内に存在していたものであってもよいし、コンピュータ１０３，１１４の入力手段を介して入力されたものや作業メモリ１０２に記憶されていたものであってもよい。アカウンティングエンジン１０６は、データバンク１０７からのデータを追加したり、および／または供給されたデータを商取引の伝票の要求を満足する書式へ変換したりして、これらを種々のビジネスアプリケーション１０９が読み出せるようにする。続いてこの伝票が伝票メモリ１０８へ記憶される。変換を実行するためにデータバンク１０７は商取引に関する全ての情報を含む。伝票に記憶される変換の形式およびデータの形式はプログラムモジュール１０９を介してそのつど専用に調整することができる。

図２にはアカウンティングエンジンの実施例が詳細に示されている。この図では長方形の囲みがプログラムコードを表しており、丸みを帯びた囲みがデータ構造を表している。図２のアカウンティングエンジンは第１のプログラムモジュール２１０および第２のプログラムモジュール２２０を有している。第１のプログラムモジュール２１０はビジネスイベントのクラスごとに構成されたビジネスイベントプログラムモジュール２５０からインタフェース２７１を介してビジネスイベントに関するデータを受け取る。ここでのデータは例えば購入製品の形式、個数、タイプである。また製造の実施例で商品または原材料の個数を所定の作業場所の在庫から引き去ることや、社員への給与の支払いであってもよい。これらのデータは記憶媒体を介してロードされるか、または入力手段（キーボード、モニタ）を介してオンラインで入力される。データの供給は例えば該当するデータのアドレスを引き渡すことよって行われる。付加的にＩＤコード２５１も供給される。

第１のプログラムモジュール２１０はビジネスイベントに関するデータから入力データセット２１２を形成する１つまたは複数の形成モジュール２１１を有している。入力データセットはＥＲＰソフトウェア内でシミュレートされたビジネスイベントのクラスごとに専用の構造を有している。形成モジュール２１１も同様にビジネスイベント２４０のクラスごとに構成されている。ビジネスイベントモジュール２５０と形成モジュール２１１との対応関係は例えばテーブルによって定められる。入力データセット２１２はその構造内にヘッド領域を有しており、ここにはＩＤコード２５１、口座名、部署名、ユーザ名、タイムスタンプ、記帳日、法人名などの一般的なデータと、ビジネスイベントのクラスに該当するデータとが含まれている。構造の残りの部分には具体的なそのつどのビジネスイベントに関するデータが含まれる。一般的なデータの一部はデータバンクのデータバンクアプリケーション２６０からインタフェース２７２を介して読み出されたものであってもよい。形成モジュール２１１のコンフィグレーション、ビジネスイベント２５０への割り当ておよび入力データセット２１２の構造の設定は、有利には、それぞれの会社のＥＤＶシステムにアカウンティングエンジンをインストールする際に行われる。

このようにして形成された入力データセット２１２は第１のプログラムモジュール２１０からインタフェース２１３を介して第２のプログラムモジュール２２０へ供給される。第２のプログラムモジュールは変換モジュール２２１を有しており、ここで伝票プロセッサ２２２が入力データセット２１２を少なくとも２つのビジネスアプリケーションによってアクセス可能な固有の構造を有する出力データセット（伝票）２２６へ変換する。この変換モジュールにより入力データセット２１２に含まれていたビジネスイベントに関するデータが会計事務に相応するデータへ変換される。この変換はデータを追加したり、および／または入力データセットのデータを変換したりすることによって行われる。データの追加は伝票プロセッサがインタフェース２７３を介してデータバンクアプリケーション２６０へアクセスすることにより行われる。このように追加されるデータの例として顧客グループまたは価格が挙げられる。データの変換は例えばデータバンクアプリケーション２６０から得られた引き渡しの個数および単価から売上高を計算して行われる。これらはさらなるステップでの種々のビジネスアプリケーションからのアクセスに備えて伝票２２６に記憶される。

種々のビジネスアプリケーションとは、例えば成果会計、費用会計、貸借対照、損得計算などの会計事務のアプリケーションまたはその管理のアプリケーションである。少なくとも２つのビジネスアプリケーションからアクセス可能にするという要求を満足するために、伝票２２６はヘッド領域２２６ａと内部でさらに階層化されたデータ領域２２６ｂ、２２６ｃとを有している。後者は１つまたは複数のビジネスアプリケーションの読み出しアクセスのために設けられている。ヘッド領域は入力データセット２１２の一般的なデータと伝票プロセッサ２２２がデータバンクアプリケーション２６０から追加したデータとを含んでいる。各データ領域２２６ｂ、２２６ｃは会計事務の個々の仕訳に対するデータを含んでいる。例えば仕訳のデータ領域２２６ｂには費用および収益のデータが存在している。どの領域のどのデータをどのビジネスアプリケーションが読み出すかはそれぞれのビジネスアプリケーションによってコンフィグレーション可能である。このことについて以下に詳細に説明する。

ビジネスアプリケーションは図２の実施例では第３のプログラムモジュール２４０の形態で構成されている。第３のプログラムモジュール２４０はコンフィグレーションモジュール２４２を有しており、これはインタフェース２７４を介して変換モジュールのコンフィグレーションサービス２２３と共働する。これによりコンフィグレーションモジュール２４２は、どのデータが所定のビジネスアプリケーションのアクセスのために該当する伝票２２６のデータ領域２２６ａまたは２２６ｂへ書き込まれ、第３のプログラムモジュール２４０によって読み出されるかを求めることができる。変換に必要なデータはデータバンク内にテーブルの形式で格納される。テーブルの相応のフィールド名はインタフェース２７６を介してデータバンクアプリケーション２６０により選択される。選択されたフィールド名はインタフェース２７４を介してコンフィグレーションサービス２２３へ供給される。このようにして選択されたフィールドの内容すなわちデータは、変換モジュール２２１によってインタフェース２７３を介してデータバンクアプリケーション２６０から読み出され、伝票プロセッサ２２２により伝票へ挿入されるか変換される。さらにコンフィグレーションモジュール２４２はどのような入力データセットの評価を行うか、また得られた結果のうちどの値を伝票として記憶するかを定めることができる。例えば所定の記帳形式ごとに通貨を選択することができる。

入力データセット２１２が伝票２２６へ変換されると、サーバモジュール２３０により１つまたは複数の関数２３１がこの伝票２２６へ適用される。例えばこの関数２３１で、借方および貸方の差し引きが０となるか否か、示されている制御セットが正しいか否か、勘定データに該当する必須のフィールドが全て埋められたか否か、顧客グループが正しく定められているか、その他のエラーや正規の記帳の基本セットに一致しないデータがないか、などが検査される。関数２３１はサービスモジュール２３０に格納されており、インタフェース２７７，２２７を介してコンフィグレーションモジュール２４２により読み出され、該当する伝票へ適用され、相応のビジネスアプリケーションにより選択される。

構造データ、すなわちＩＤコード２５１および第３のプログラムモジュール２４０によりコンフィグレーションされた設定を備えた伝票２２６は、パーシステンシメモリモジュール２２５によって記憶される。物理メモリへの格納は１つまたは複数のテーブルを有するデータバンク構造の形式で行われる。伝票プロセッサ２２２はインタフェース２２８を介して構造データへアクセスすることができ、これを使用して入力データセット２１２を所定のクラスのビジネスイベントの伝票２２６へ変換する。インタフェース２７１，２１３はビジネスイベントのクラスごとに専用に構成されている。

データを読み出すために、１つまたは複数の第３のプログラムモジュール２４０は読み出しモジュール２４１を有しており、これはインタフェース２７５を介して読み出しサービスモジュール２２４と共働する。このとき読み出しサービスモジュール２２４は読み出しモジュール２４１へコンフィグレーションモジュール２４２によって選択されたデータを供給する。コンフィグレーションモジュール２４２は、上述の場合と同様に、どのデータまたはどのフィールドをデータバンクアプリケーション２６０が伝票へ追加したり伝票から読み出したりするかを設定することができる。

本発明をさらに図３に則して説明する。図３は伝票３０４のデータ構造の概略図であり、ここにはビジネスイベントＩ〜ＩＩＩ（３０１，３０２，３０３）のデータを伝票３０４の所定のデータ領域３０６，３０７，３０８へ変換する手段が示されている。またビジネスアプリケーションＩ〜ＩＩＩ（３０９，３１０，３１１）が伝票３０４のデータ領域３０６，３０７，３０８へアクセスする様子も示されている。ただし図示の手段は唯一のものではなく、例示に過ぎないことを理解されたい。

電子伝票３０４はヘッド領域３０５とデータ領域３１３とを有している。ヘッド領域３０５はＩＤコード３１２とビジネスイベント３０１，３０２，３０３に関するその他の一般データとを含む。ここでビジネスイベント３０１，３０２，３０３のそれぞれに対して１つずつ固有の伝票が作成されることを言及しておく。ただし図ではわかりやすくするために３つの伝票は伝票３０４としてまとめられている。データ領域３１３は種々の仕訳に対するデータを含む下位の領域３０６，３０７，３０８を有している。第１の領域３０６は費用および収益のデータ、第２の領域３０７は在庫のデータ、第３の領域３０８は債権および債務のデータを含む。ビジネスイベントＩのように、１つのビジネスイベントがヘッド領域の一般データと各領域３０６，３０７，３０８の仕訳のデータとの組み合わせの全てを有することもある。

このことを以下に図４，図５を参照して説明するが、これはいかなる意味での限定も意図していない。図１〜図３とは異なり、図４，図５にはプログラムモジュールが示されていないので、データ構造が長方形の囲みで示されている。

まず日本に親会社があり、米国に子会社Ａ、欧州に子会社Ｂを有するコンツェルンがあるとしよう。最初のビジネスイベントとして、Ｂ社がＡ社から単価１１０ユーロの製品Ｙを３個買い付けたとする。Ａ社での製造コストは１個当たり１００ユーロ、したがって利潤は１０％である。このイベントをＢ社の会計事務から考察すると、２つの異なる観点、すなわちＢ社の観点（ビジネスアプリケーションＩ）とコンツェルンの観点（ビジネスアプリケーションＩＩ）とから評価されることになる。商取引として見るとＢ社では商品の現在高が増大し、その価格ぶんの大きさの負債が生じる。

図２のプログラムモジュール２５０を介してこのビジネスイベントに属するデータが図２の第１のモジュール２１０へ供給される。すなわちＩＤコード（１０１）・注文日（２００２．２．５）・ビジネスイベント（商品購入）・品目（製品Ｙ）・個数（３）・購入金額（３３０）などである。プログラムモジュール２１０はこれらのデータからビジネスイベントのクラス専用の２つの入力データセットを形成する。つまりビジネスアプリケーションＩ用の第１の入力データセット４１０とビジネスアプリケーションＩＩ用の第２の入力データセット４２０との２つである。これらは同じ構造を有し、それぞれヘッド領域４１１，４２１と仕訳のデータ領域、すなわち残高４１２，４２２および負債４１３，４２３とから成る。各領域は１行のテーブルとして構成されている。ヘッド領域は例えばＩＤコード、記帳日、ビジネスイベントなどのフィールドを有しており、ここに供給された相応のデータが入力される。この場合にはモジュール２１０によって供給された第１のＩＤコードから、２つの入力データセットが一義的に表されるように、相応のビジネスアプリケーションのインデクス“Ｉ”，“ＩＩ”を加えた第２のＩＤコードおよび第３のＩＤコードが形成される。さらにモジュール２１０によってユーザＩＤのフィールドが追加され、ここに該当する担当者のマークが入力される。このデータはデータバンクアプリケーション２６０から取り出される。残高のデータ領域４１２はコンツェルン会社、品目、個数、価格［ユーロ］のフィールドを有しており、コンツェルン会社のフィールドはデータバンクからのデータで埋められ、その他のフィールドは供給されたデータで埋められる。価格［ユーロ］のフィールドの内容は購入金額に相応する。これについては借方で正の数、貸方で負の数になっていることに注意されたい。負債のデータ領域４１３はコンツェルン会社、納入者、価格［ユーロ］のフィールドを有しており、最初の２つのフィールドは図２のデータバンクアプリケーション２６０からの値を有する。

ビジネスアプリケーションＩＩの入力データセット４２０はビジネスアプリケーションＩの入力データセット４１０と構造は変わらないが、価格［ユーロ］のフィールドの内容のみが異なっている。これはコンツェルンとしての評価であって販売とは関係なく、ビジネスアプリケーションＩＩ用の入力データセットを形成する形成モジュール２１０がコンフィグレーションされ、データバンクアプリケーション２６０によってコンツェルン全体にわたってアクセス可能なデータバンクから製造コストの値が読み出され、残高のデータ領域４２２の価格［ユーロ］のフィールドおよび負債のデータ領域４２３の価格［ユーロ］のフィールドへ入力されたことによる。

ここで図２の変換モジュール２２１が第１の入力データセット４１０から第１の伝票４３０を形成し、第２の入力データセット４２０から第２の伝票４４０を形成する。２つの伝票のデータ構造は異なっており、入力データセットの構造に対して１つまたは複数のフィールドが補完されたり除去されたりしている。ヘッド領域４３１，４４１および残高のデータ領域４３２，４４２および負債のデータ領域４３３，４４３が設けられている。

ヘッド領域４３１，４４１は同じ構造を有してはいるが、個々のフィールドの内容が異なっている。ここには入力データセットのヘッド領域のフィールドに加えて営業年度のフィールドと四半期のフィールドとが存在している。欧州のＢ社から見ると、営業年度はカレンダー年と同じである。変換モジュール２２１は社名および記帳日の知識から営業年度として２００２年、四半期として第１四半期を導出し、これらの値を相応のフィールドへ記憶する。

残高のデータ領域４３２，４４２は異なる構造を有している。データ領域４３２はデータ領域４１２に相応するフィールドのほか、口座、価格［米ドル］および集積場所のフィールドを有する。口座および集積場所は変換モジュール２２１によってデータバンクアプリケーション２６０から求められ、価格［米ドル］はデータバンクアプリケーション２６０の換算関数を用いて価格［ユーロ］から求められる。価格［米ドル］は販売者が例えば米国に在籍している場合に利用される。データ領域４４２もほぼ同じ構造を有するが、集積場所のフィールドに代えて価格［円］のフィールドを有する。これはコンツェルンの親会社が日本にあり、コンツェルン会社の観点からは集積場所の情報は重要ではないが、日本の規則に則って貸借対照を行わなければならないからである。

負債のデータ領域４３３，４４３も異なる構造を有する。データ領域４３３はデータ領域４１３に相応するフィールドのほか、口座および価格［米ドル］のフィールドを有する。これらの内容は前述のデータ領域と同様に求められる。同じことが残高のデータ領域４４３にも当てはまり、ここでも価格［円］のフィールドが用いられている。

第２のビジネスイベントの例として、Ｂ社が前述の商品を欧州の第３者のＸＹＺ社へ販売し、商品の引き渡しが行われる図５のケースを考えよう。インボイスは処理されない。このイベントを商取引から見ると、Ｂ社では商品の現在高が低下し、その価格ぶんの大きさの生産額が生じることになる。

図２のプログラムモジュール２５０を介してこのビジネスイベントに属するデータが図２の第１のモジュール２１０へ供給される。すなわちＩＤコード（２１３）・注文日（２００２．４．１０．）・ビジネスイベント（商品出荷）・品目（製品Ｙ）・個数（３）である。前述の実施例と同様に、ビジネスアプリケーションＩ用の第１の入力データセット５１０とビジネスアプリケーションＩＩ用の第２の入力データセット５２０とが形成され、ここから２つの伝票５３０，５４０が形成される。必要な残りのデータは図２のデータバンクアプリケーション２６０から得られる。ヘッド領域５１１，５２１，５３１，５４１は前述の実施例のヘッド領域に相応し、その内容のみが適合化されている。同じことが残高のデータ領域５１２，５２２，５３２，５４２にも相当する。今回はビジネスイベントのクラスごとの負債のデータ領域は必要とされておらず、その代わり費用および収益のデータ領域５１３，５２３，５３３，５４３が設けられている。これらは入力データセット５１０，５２０に対してコンツェルン会社、顧客（第３者会社）、価格［ユーロ］のフィールドから成る。伝票５３０には価格［米ドル］および地域のフィールドが追加され、伝票５４０にはさらに価格［円］が追加される。その内容およびデータは前述した実施例と同様である。注意すべきは口座のフィールドの内容が１つのビジネスアプリケーション内では同一となっているが、ビジネスアプリケーションＩとＩＩとのあいだで異なっている点である。ただしこれはいつもそうなるというわけではない。

４つの伝票が記憶され、それぞれ複数のビジネスアプリケーション２４０、例えば残高管理アプリケーション、保険料計算アプリケーションおよび一般的な貸借対照アプリケーションによって読み出し可能となる。本発明によれば、どのビジネスアプリケーションがどのフィールドを読み出すかを設定することができる。残高管理アプリケーションはヘッド領域および残高のデータ領域の全てのフィールドまたは個々のフィールドへアクセスできる。こうしたコンフィグレーションは有利にはソフトウェアで行われる。

アカウンティングエンジンはＥＲＰソフトウェア内では伝票による個別証明の形式のビジネスイベントを集積して記録する中心的なコンポーネントである。これらの個別証明を１つまたは複数のビジネスアプリケーションは統合的かつ固有に見通すことができる。各伝票は所定の商取引評価においては冗長性なしに格納されるので、メモリスペースは伝票およびビジネスアプリケーションの数に応じて大幅に節約される。しかもその際に個々の伝票に必要なメモリスペースは増大する。またビジネスアプリケーションのプログラムモジュール間での帳簿合わせのコストも低減される。伝票およびプロセスフローの構造はもちろんユーザがコンフィグレーションすることができる。

アカウンティングエンジンを会計事務に使用することにより、企業では付加的な商取引上の利益が生じる。これはアカウンティングエンジンを戦略的なビジネスイベントと内部での会計事務のビジネスアプリケーションとの全てをつなぐ唯一のインタフェースとして使用可能であり、得られた伝票を文書化して中央に格納できるからである。記憶されているＩＤコードを用いればビジネスイベントの一義的な監査や取り消しも可能である。複数のビジネスイベントがアカウンティングエンジンの伝票メモリを利用する場合、種々のビジネスイベントから一貫した共通の伝票を作成することもできる。これにより関係するビジネスアプリケーションをインヒーラントに一致させることができる。

アカウンティングエンジンによりＥＲＰソフトウェアシステムで戦略的なビジネスイベントと会計事務のアプリケーションとを分離することもできる。このような分離により、有利には、データ技術によって会計事務をロジスティクスシステムへ非同期的に結合することができる。

公知の任意の技術を駆使して、または既存のソフトウェアと結びつけて、種々のプログラムまたはプログラムモジュールを設計することができる。例えば本発明のプログラムまたはプログラムモジュールはＪａｖａ^（Ｒ），Ｃ＋＋，ＨＴＭＬ，ＸＭＬ，ＳＡＰＲ／３，ＡＢＡＰまたはＪａｖａＡｐｐｌｅｔが組み込まれたＨＴＭＬで設計することできる。１つまたは複数のこのようなモジュールは例えばデータ入力のために既存のＥメールまたはブラウザソフトウェアに組み込むこともできる。

さらにこのアカウンティングエンジンによれば、商取引において評価されないビジネスイベント、例えば価格データのない商品の引き取りなどをプロセスごとの概念で管理することもできる。生じたビジネスイベントの評価は会計事務の規則に則って行われる。異なる評価から作成された各伝票は論理的に分離された状態で保管される。有利には評価ごとに固有の伝票が作成される。

本願発明にともなって提出される特許請求の範囲は充分な権利保護を得るために不利益がないように形式化した提案である。本願出願人はこれまでに明細書および／または図面のみで開示された特徴の請求を留保する。なお特許請求の範囲にかっこ書きで示された事項は本発明の特徴を限定するものではない。

従属請求項に用いられている引用関係において独立請求項の要件のさらなる展開が示唆される。ただしそれらは引用関係にある従属請求項の特徴の組み合わせに対する独立の客観的保護の請求の放棄を意味するものではない。

また個々の特徴を接続する用語として“または”と記載しているが、これはある箇所では数学的な“または”でもあるし、別の箇所ではそれぞれ他の可能性を排除する“または”でもあることを理解されたい。

さらに、所定の刊行物に関連しないものの、本願出願人および発明者にとって既知の全ての構成は、それが公けに知られていない場合には、本願出願人および発明者がその権利を留保することを指摘しておく。

コンピュータシステムの概略図である。コンピュータプログラムのブロック図である。伝票がデータソースによって作成され、ビジネスアプリケーションからアクセスされる様子を示した図である。商品購入の実施例における入力データセットおよび伝票の概略図である。商品販売の実施例における入力データセットおよび伝票の概略図である。

Claims

コンピュータシステムを用いてビジネスイベントに関するデータを１つまたは複数のビジネスアプリケーションからのアクセスのために記憶し、ビジネスイベントに１つずつＩＤコードを割り当て、コンピュータシステム内で１つまたは複数のビジネスイベントクラスを種々のデータ構造によってシミュレートする
ビジネスイベントの伝票の自動ファイリング方法において、
第１のステップでビジネスイベントに関するデータから、１つまたは複数のビジネスイベントクラスおよび１つまたは複数のビジネスアプリケーションごとに専用の構造を有する少なくとも１つの入力データセットを形成し、
第２のステップで少なくとも１つの入力データセットを１つまたは複数のビジネスアプリケーションからコンフィグレーションできる構成の出力データセットへ変換し、
第３のステップで出力データセットを対応するＩＤコードとともに記憶し、ＩＤコードを参照することにより少なくとも２つのビジネスアプリケーションによって出力データセットを完全にまたは部分的に読み出す
ことを特徴とするビジネスイベントの伝票の自動ファイリング方法。
第１のステップを第１のプログラムモジュールを用いて実行し、第２のステップを第２のプログラムモジュールを用いて実行し、専用の構造を有する入力データセットを第１のプログラムモジュールからインタフェースを介して第２のプログラムモジュールへ供給する、請求項１記載の方法。
複数のビジネスアプリケーションを第３のプログラムモジュールまたは別のプログラムモジュールとする、請求項１または２記載の方法。
第２のステップでの１つまたは複数の第３のプログラムモジュールによる変換過程をインタフェースを介して調整できるように第２のプログラムモジュールを構成する、請求項３記載の方法。
少なくとも２つのビジネスアプリケーションによって選択可能なデータを出力データセットからデータ要求により読み出し、インタフェースを介してさらなる処理および／または表示のために１つまたは複数の第３のプログラムモジュールおよび／または別のプログラムモジュールへ供給できるように第２のプログラムモジュールを構成する、請求項３または４記載の方法。
選択可能なデータを第３のプログラムモジュールによって選択する、請求項５記載の方法。
出力データセットをトランザクションとして記憶する、請求項１から６までのいずれか１項記載の方法。
複数のビジネスアプリケーションに対する出力データセットは１つまたは複数のテーブルを備えた専用のデータバンク構造を有する、請求項１から７までのいずれか１項記載の方法。
会計事務の種々の仕訳に対する出力データセットはそれぞれ異なるデータ領域を有する、請求項１から８までのいずれか１項記載の方法。
出力データセットを少なくとも２つのビジネスアプリケーションからアクセスできるように構成する、請求項１から９までのいずれか１項記載の方法。
請求項１から１０までのいずれか１項記載のビジネスイベントの伝票の自動ファイリング方法を実行するコンピュータシステムにおいて、
ビジネスイベントに関するデータを記憶する手段と、
プログラムを記憶する手段と、
プログラムを実行する手段と、
請求項１から１０までのいずれか１項記載のビジネスイベントの伝票の自動ファイリング方法を実行するプログラムコード手段とを有する
ことを特徴とするコンピュータシステム。
請求項１から１０までのいずれか１項記載のビジネスイベントの伝票の自動ファイリング方法の全てのステップを任意に組み合わせたプログラムとしてコンピュータ上で実行される
ことを特徴とするプログラムコード手段を備えたコンピュータプログラム。
電気信号のキャリア内に含まれている、請求項１２記載のコンピュータプログラム。
コンピュータで読み出し可能なデータ担体に記憶されており、
請求項１から１０までのビジネスイベントの伝票の自動ファイリング方法の全てのステップを任意に組み合わせてコンピュータ上で実行するのに適している
ことを特徴とするプログラムコード手段を備えたコンピュータプログラム製品。
請求項１２記載のコンピュータプログラムが記憶されていることを特徴とする揮発性メモリまたは不揮発性メモリを備えたコンピュータ。
請求項１から１０までのいずれか１項記載のビジネスイベントの伝票の自動ファイリング方法によって得られることを特徴とする電子データ構造。