(57)【要約】【課題】データの処理履歴をすべて保持し、この処理履歴と処理ルールとを照合することにより処理の可否を判断することが可能なデータ処理システムを提供する。【課題を解決するための手段】処理対象データを取得する手段と、処理対象データと関連付けられている処理仕様を取得する手段と、処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を保持する手段と、処理対象データに関連付けられて取得された処理仕様に基づいた処理を実行するか判断するためのルールを保持する手段と、ルールと履歴情報とに基づいて処理対象データに関連付けられた処理仕様に基づく処理を実行可能か判断する手段と、処理実行可能との判断結果の場合にその処理対象データに対して関連付けられている処理仕様の処理を実行する手段と、実行結果を出力する手段とを有するデータ処理システムなどを提供する。【選択図】図１
2007323406.tif 000002
【特許請求の範囲】
【請求項１】
処理対象データを取得する処理対象データ取得部と、
取得した処理対象データと関連付けられている処理仕様を取得する処理仕様取得部と、
処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を保持する履歴情報保持部と、
取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを保持するルール保持部と、
ルール保持部に保持されているルールと、履歴情報保持部に保持されている履歴情報とに基づいて取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する判断部と、
判断結果が処理実行可能との判断結果である場合にはその処理対象データに対して、関連付けられている処理仕様の処理を実行する処理実行部と、
処理実行部での実行結果を出力する出力部と、
を有するデータ処理システム。
【請求項２】
判断部での判断結果が処理実行不可との判断結果である場合には警告情報を出力する警告情報出力部をさらに有する請求項１に記載のデータ処理システム。
【請求項３】
処理対象データ取得部と、処理仕様取得部とは、取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更を受け付ける変更受付け手段を有する請求項１又は２に記載のデータ処理システム。
【請求項４】
出力部での出力フォーマットを管理する出力フォーマット管理部を有し、
出力部での出力は管理されているフォーマットに従ってなされる請求項１から３のいずれか一に記載のデータ処理システム。
【請求項５】
処理対象データを取得する処理対象データ取得ステップと、
前記処理対象データステップにて取得した処理対象データと関連付けられている処理仕様を取得する処理仕様取得ステップと、
取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを記憶装置から読み出すルール読出しステップと、
処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を記憶装置から読み出す履歴情報読出しステップと、
前記ルール読出しステップにて読み出したルールと、前記履歴情報読出しステップにて読み出した履歴情報とに基づいて、前記取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する判断ステップと、
前記判断ステップにおける判断結果が処理実行可能との判断結果である場合にはその処理対象データに対して、関連付けられている処理仕様の処理を実行する処理実行ステップと、
前記処理実行ステップでの実行結果を出力する出力ステップと、
を有するデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理対象データをこれに関連付けられた処理仕様とともに取得し、処理仕様に基づくデータ処理が実行可能か判断して処理を実行するデータ処理システム及びデータ処理方法に関する。
【背景技術】
【０００２】
文書管理、販売管理等のためのデータ処理においては、データの管理や報告を適正に行うために処理の手順や処理結果の報告のフォーマットが定められている場合がある。このため、データ処理を行う際に、一度処理済みのデータを不正に改竄したり、所定の処理手順に反する手順で処理したりすることを防止する必要があり、このための装置として、改竄防止システムや文書管理装置などが知られている（例えば特許文献１参照）。
【特許文献１】特開２００３‐１３１５６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、近年の金融商品取引法及び会社法（いわゆるＪ‐ＳＯＸ法）制定の動向と絡んで、企業会計における財務報告や監査を適正に行うことが厳格に求められるようになっている。即ち、企業内で承認されたすべての取引を正確に処理・記録することを確保するための統制（いわゆる内部統制）が必須となり、具体的には、（１）承認された取引などルールに基づいて処理可能と判断された取引だけを事実に基づいて正確に過不足なく入力するとともに、処理済みの取引データを履歴として保持する仕組み、（２）確定した処理済みの取引データを勝手に変更することができず、変更したときは必ずその変更履歴を保持する仕組み、及び（３）構築した仕組みを勝手に変更することができず、変更したときは必ずその変更履歴を保持する仕組みが必要とされる。そこで、かかる仕組みの構築が、各企業にとって喫緊の課題となっている。また、これに関連して内部統制が適正に行われているか判断するため企業外部の公認会計士等が財務報告に基づいて監査を行う体制の強化も謳われている。
【０００４】
このようなＪ‐ＳＯＸ法に基づく内部統制を適切に行うためには、第一に、取引データの変更履歴を含むすべての取引にかかる処理履歴を漏れなく保持しておく必要がある。また第二に、ある取引にかかる処理が適正なものであるかを取引ルールと上記の処理履歴とに照らして判断する必要がある。また第三に、公認会計士による監査のために上記の処理履歴等を所定のフォーマットで出力できるようにする必要もある。
【０００５】
上記所要を満たすためには、データの処理履歴をすべて保持し、この処理履歴と処理ルールとを照合することにより処理の可否を判断する仕組みの構築が不可欠である。また、外部への報告用のフォーマットが異なっている場合に所定のフォーマットに変更するなどしてデータを出力できる仕組みの構築も必要である。さらに、かかる仕組みを全体システムとして改めて構築するには多額の費用がかかることも考えられることから、既存のコンピュータシステムに外付け可能な、即ちそれぞれのシステムにおける処理形式に合わせて最適化することができるような形でデータや処理手順の取得を行うことが可能なシステムとして構築できるものであることが望ましい。しかし、従来このようなニーズをすべて満たすシステムは存在していなかった。
【０００６】
そこで、本発明が解決すべき課題は、上記のようなＪ‐ＳＯＸ法に基づく内部統制への対応を含め、データの処理履歴をすべて保持し、この処理履歴と処理ルールとを照合することにより処理の可否を判断することが可能なデータ処理システムを提供することにある。また、外部への報告用のフォーマットが異なっている場合に所定のフォーマットに変更してデータを出力できるデータ処理システムを提供することにある。さらに、既存のコンピュータシステムにおける処理形式に合わせて最適化することができるような形でデータや処理手順の取得を行うことが可能なデータ処理システムを提供することにある。
【課題を解決するための手段】
【０００７】
以上の課題を解決するため、本発明のうち、請求項１に記載の発明は、処理対象データを取得する処理対象データ取得部と、取得した処理対象データと関連付けられている処理仕様を取得する処理仕様取得部と、処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を保持する履歴情報保持部と、取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを保持するルール保持部と、ルール保持部に保持されているルールと、履歴情報保持部に保持されている履歴情報とに基づいて取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する判断部と、判断結果が処理実行可能との判断結果である場合にはその処理対象データに対して、関連付けられている処理仕様の処理を実行する処理実行部と、処理実行部での実行結果を出力する出力部とを有するデータ処理システムを提供する。また、請求項２に記載の発明は、判断部での判断結果が処理実行不可との判断結果である場合には警告情報を出力する警告情報出力部をさらに有する請求項１に記載のデータ処理システムを提供する。また、請求項３に記載の発明は、処理対象データ取得部と、処理仕様取得部とは、取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更を受け付ける変更受付け手段を有する請求項１又は２に記載のデータ処理システムを提供する。また、請求項４に記載の発明は、出力部での出力フォーマットを管理する出力フォーマット管理部を有し、出力部での出力は管理されているフォーマットに従ってなされる請求項１から３のいずれか一に記載のデータ処理システムを提供する。また、請求項５に記載の発明は、処理対象データを取得する処理対象データ取得ステップと、前記処理対象データステップにて取得した処理対象データと関連付けられている処理仕様を取得する処理仕様取得ステップと、取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを記憶装置から読み出すルール読出しステップと、処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を記憶装置から読み出す履歴情報読出しステップと、前記ルール読出しステップにて読み出したルールと、前記履歴情報読出しステップにて読み出した履歴情報とに基づいて、前記取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する判断ステップと、前記判断ステップにおける判断結果が処理実行可能との判断結果である場合にはその処理対象データに対して、関連付けられている処理仕様の処理を実行する処理実行ステップと、前記処理実行ステップでの実行結果を出力する出力ステップとを有するデータ処理方法を提供する。
【発明の効果】
【０００８】
本発明により、データの処理履歴をすべて保持し、この処理履歴と処理ルールとを照合することにより処理の可否を判断することが可能なデータ処理システムを提供することが可能となる。また、外部への報告用のフォーマットが異なっている場合に所定のフォーマットに変更してデータを出力できるデータ処理システムを提供することが可能となる。さらに、既存のコンピュータシステムにおけるデータや処理手順の処理形式に合わせて最適化するための変更が可能なデータ処理システムを提供することが可能となる。
【発明を実施するための最良の形態】
【０００９】
以下に、本発明の実施例を説明する。実施例と請求項の相互の関係は以下のとおりである。実施例１は主に請求項１、請求項５などに関し、実施例２は主に請求項２などに関し、実施例３は主に請求項３などに関し、実施例４は主に請求項４などに関する。なお、本発明はこれら実施例に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。
【実施例１】
【００１０】
<概要>
本実施例のデータ処理システムは、処理対象データの履歴情報を保持する手段と、処理仕様に基づく処理を実行するか否か判断するためのルールを保持する手段と、このルールと履歴情報とに基づいて処理仕様に基づいた処理を実行可能か判断する手段を有する点に特徴を有する。
【００１１】
<構成>
図１は、本実施例のデータ処理システムの機能ブロックの一例を示す図である。本件発明の構成要素である各部は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアの両者、のいずれかによって構成される。たとえば、これらを実現する一例として、コンピュータを利用する場合には、ＣＰＵ、メモリ、バス、インターフェイス、周辺機器などから構成されるハードウェアと、これらのハードウェア上にて実行可能なソフトウェアを挙げることができる。具体的には、メモリ上に展開されたプログラムを順次実行することで、メモリ上のデータや、インターフェイスを介して入力されるデータの加工、蓄積、出力などにより各部の機能が実現される。
【００１２】
本実施例の「データ処理システム」０１００は、「処理対象データ取得部」０１０１と、「処理仕様取得部」０１０２と、「履歴情報保持部」０１０３と、「ルール保持部」０１０４と、「判断部」０１０５と、「処理実行部」０１０６と、「出力部」０１０７とからなる。
【００１３】
「処理対象データ取得部」は、処理対象データを取得するように構成されている。ここでの「処理」は、対象データに対して新たなデータを追加したり、変更したりといったことを加えて新たなデータとすることをいう。例えば、取得する処理対象データが販売対象商品の見積書に関するデータ（見積もり相手方氏名、商品名、商品番号、商品単価など）である場合に、当該商品の受注があったときに当該データを取得してこれに受注データ（例えば発注者氏名、商品名、商品番号、発注日、発注数量など）を追加して新たなデータとすることが該当する。処理対象データの属性は問わないので、例えば上の例で挙げた販売管理データのほか、財務・会計管理データ、生産管理データ、資産管理データ、一般文書管理データなどであってもよい。処理対象データの取得元も問わない。例えば、本システムが外付けされたコンピュータ装置などが生成するデータを当該外部装置から取得するものであってもよいし、本システムに備えられたキーボード、マウス等のインターフェイスを介してユーザが行ったデータ入力を受け付けて取得するものであってもよい。
【００１４】
「処理仕様取得部」は、取得した処理対象データと関連付けられている処理仕様を取得するように構成されている。「処理仕様」とは、処理対象データのデータ形式・処理手順・処理要領などをいい、当該処理要領等に基づく処理要求を含む。例えば、上の例に即せば、受注データの処理は、所定のデータ形式により作成された見積書のうち発注のあった商品名・商品番号に対応する所定欄に発注数量を記入する形で行うといった処理要領など（処理要求及び処理手順を記述したプログラムを含む）が処理仕様にあたる。この取得元についても処理対象データの取得の場合と同様である。
【００１５】
「履歴情報保持部」は、処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を保持するように構成されている。例えば、上記の例では、見積書の作成処理を本システムが既に行っており、その処理情報を保持していることなどが考えられる。この既に行った処理は、典型的には、本発明のシステムの構成に従って処理実行部が実行する処理である。
【００１６】
「ルール保持部」は、取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを保持するように構成されている。ルールの具体例としては、受注入力の処理は見積書の出力がなされていなければ行ってはならないといったことが挙げられる。あるいは、５万円以上の受注入力を行うには承認があったことを示す与信情報が付加されていなければならないといったことでもよい。
【００１７】
「判断部」は、ルール保持部に保持されているルールと、履歴情報保持部に保持されている履歴情報とに基づいて取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断するように構成されている。例えば、受注入力の場合であれば、見積書の出力がなされていることというルールに照らし、履歴情報中において見積書の出力がなされているとの履歴が存在する場合に、処理が実行可能であると判断される。なお、第一回目の処理のときには未だ処理の履歴は存在しない。そこでこの場合は、ルールは「履歴が存在しないこと」となり、履歴情報保持部には「履歴が存在しない」という履歴情報が保持されているとみなして判断を行う。従って、この場合、ルール及び履歴情報に照らした判断結果は、常に「処理可能」という判断結果となる。
【００１８】
「処理実行部」は、判断結果が処理実行可能との判断結果である場合にはその処理対象データに対して、関連付けられている処理仕様により処理を実行するように構成されている。例えば、上記の例の判断がなされた場合に、見積書のうち発注のあった商品名・商品番号に対応する所定欄に発注数量を記入するという処理仕様に基づく処理が実行される。
【００１９】
「出力部」は、処理実行部での実行結果を出力するように構成されている。出力の方法は何でもよく、例えば、メールによるメッセージ通知などが考えられる。
【００２０】
次に、本実施例のデータ処理システムの構成を、具体例を用いてより詳細に説明する。ここでは、処理対象データが企業における販売管理に関するデータである場合の例で説明する。また、本例では、データ処理システムが外部のコンピュータ装置に外付けされ、当該外部装置が生成する処理対象データを当該外部装置から取得して処理する場合の例で説明する。図２は、かかる具体的構成の一例を説明するための概念図である。まず、外部装置０２１０においては、見積書入力データ、見積書承認依頼データ等の処理対象データが順次生成され、保持される。また、これらはそれぞれ処理仕様と関連付けられて保持される。即ち、本図においては省略して記載されているが、「見積書入力」０２１１は、処理対象データである見積書入力データとこれに関連付けられた処理仕様との両方を含めたものを意味する。他のデータについても同様である。そして、これらの処理対象データ及び処理仕様は、データ処理システム０２００が取得して、ルール保持部０２０４が保持するルール及び履歴情報保持部０２０３が保持する履歴情報に照らして処理実行可能か否か判断する。
【００２１】
例えば、見積書入力についていえば、同図に示すように、まず（１）データ処理システムが「見積書入力」０２１１（ここでは、見積書入力データとこれに関連付けられた処理仕様を示す）を外部装置から取得する。（２）データ処理システムは、取得したデータをルール及び履歴情報に基づいて処理実行可能か判断する。ただし、この場合は第一回目の処理であるので、ルールは「履歴が存在しないこと」であり、これと履歴情報保持部に保持されている「履歴が存在しない」という履歴情報とに基づいて判断を行う。この判断の結果処理実行可能と判断されると、データ処理システムは処理仕様に示された処理形式等に従って見積書を入力する処理を実行する。なお、本図においては一括して記載されているが、本図にいう「見積書入力」０２０６は、既に述べた処理対象データ等と、かかる処理済みのデータとの両方の意味を含むものである。（３）見積書の入力処理が実行されると、「見積書入力が処理済みである」旨のデータが履歴情報保持部を構成する記憶装置に履歴情報として保持される。この履歴情報は、次の「見積書承認依頼」の処理を実行してよいか否かの判断の際に判断の基礎として使用されることになる。（４）また、処理済みデータは、外部装置に送付される。これは見積書入力の処理が完了したことを外部装置に知らせることで、外部装置における以後のフローが円滑に行えるようにするためである。
【００２２】
次に、「見積書承認依頼」についても、同様に、まず（５）データ処理システムが「見積書承認依頼」０２１２（ここでも見積書承認依頼データとこれに関連付けられた処理仕様を含む）を外部装置から取得する。そして、（６）データ処理システムは、取得したデータをルール及び履歴情報に基づいて処理実行可能か判断する。ここでは、ルールは「見積書入力が処理済みであること」であり、このルールと上述（３）の処理によって保持された「見積書入力が処理済みである」との履歴情報とに基づいて処理実行可能か判断する。この判断の結果、処理実行可能と判断されると、データ処理システムが処理を実行する。（７）処理済みデータは履歴情報保持部に送付されて履歴情報として保持されるとともに、（８）外部装置に送付される。以下、図示を省略したが、「見積書承認」以下のフローについても、外部装置で生成、保持された処理対象データ及び処理仕様が順次データ処理システムによって取得されて同様に判断、処理される。
【００２３】
次に、本例のシステムの具体的構成の一例をさらに詳細に説明するため、図２のフローのうち「受注入力」から「請求」までのフローを処理する例を用いて、図３以下に基づいて説明する。まず図３（ａ）は、図２のうち「受注入力」０２１３から「請求」０２１４までのフローを抽出して再掲したものである。ただしここでは、説明の便宜上前後の部分のない完結的なフローとして説明する。つまり、実際には図２で示すように、「受注入力」に先立って「見積書入力」から「見積書出力」までのフローが存在するので、例えば「受注入力」の処理を実行しようとする場合、このためのルールとして「見積書出力が処理済みであること」が存在し、履歴情報に基づいて「見積書出力が処理済みであること」が確認されて初めて「受注入力」の処理が実行可能となる。しかし、本図では「受注入力」に先立つ部分のない完結的なフローと仮定したため、受注入力に先立って処理がなされていなければならない他のプロセスはないということである。一方、「引当」又は「発注」以下については、それに先立つプロセスが処理済みであることがルールとなり、かかる履歴情報が保持されていることが確認されて初めて処理実行可能と判断されることになる。
【００２４】
図３（ｂ）は、ルール保持部が保持するルールの一例であって、かかる「受注入力」から「請求」までの処理を実行する場合に可否判断の基礎とされるルールを定めたテーブルを示す。このルールは処理仕様に対応して定められる。このテーブルでは、「プロセスコード」欄０３０１に記載されたプロセスコードと、これに対応する「処理前ステータス」欄０３０２に記載されたステータスとが対応付けられている。このプロセスコードは、プロセスを特定するために付与された符号である。例えば「受注入力」はプロセスコード「ｏｒｄｅｒ」によって特定され、「引当」はプロセスコード「ｒｅｓｅｒｖｅ」によって特定される。そして、このテーブルによって、あるプロセスコードで特定されるプロセスの処理を実行するためには、当該フローの現在の状態が、そのプロセスコードに対応するステータスになっていることが必要であるとのルールが定められていることになる。例えばプロセスコード「ｒｅｓｅｒｖｅ」で特定される「引当」が処理実行可能であるためには、現在のステータスが「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ（受注入力処理済み）」であることが必要であることがルールとして定められている（なお、「受注入力」は既述のようにこれに先立って処理済みでなければならないプロセスがないので、処理前ステータスは「ｎｕｌｌ（不存在）」となっている）。なお、最右欄の「処理後ステータス」欄０３０３は、当該処理がなされた場合に実現するステータスを処理前ステータスと同じ符号で示したものである。この欄の記載は、ルールの内容を示すものではないが、あるプロセスの処理が実行された場合に実現する処理後ステータスが次のプロセスにおいて処理前ステータスとしてルールをなすことになるので、同じ符号を用いることにより処理を簡便に行うことができる点でかかる欄を設けることが望ましいことから、本例でも記載されているものである。
【００２５】
一方、履歴情報保持部は、履歴情報としてこれまでに処理されたすべての取引に関するデータを保持する。このデータには、一連の取引を識別するため取引ごとに取引ＩＤが付与される。また、取引ごとに処理の実行がなされたことが取引ステータスの欄に入力され、処理が進むごとにこのステータス欄が更新されていく。従って受注入力を行おうとする段階ではこれに先立つ処理済みプロセスがないので、履歴情報は「ｎｕｌｌ（不存在）」というものであったのが、当該受注入力が処理されると、履歴情報が「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ（受注入力処理済み）」に更新される。なお、更新は元の履歴情報に上書するのではなく、元の履歴を残したまま、新たな履歴を追加する形で行われる。また、履歴情報は、取引ＩＤで識別される取引ごとに保持される。また、処理実行は処理仕様に従ってなされるので、履歴情報にはどのような処理仕様で処理されたかの履歴も保持される。図４は、履歴情報保持部が保持する履歴情報のテーブルの一例を示す。本例では、「取引ＩＤ」欄０４０１に「Ｔ００００１」、「Ｔ００００２」、「Ｔ００００３」の各ＩＤで識別される３つの取引が記載され、「ステータス」欄０４０２のそれぞれに対応する欄に現在のステータスが履歴情報として記載されている。例えば、「Ｔ００００１」の取引は、現在のステータスが「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ（受注入力処理済み）」であることが示されている。本図では、作図の便宜上過去の履歴が省略され、最後の履歴だけが表示されているが、履歴情報としては過去の履歴がすべて保存されている。また、本図に示すように処理がなされる際に従った処理仕様が「処理形式」欄０４０３に保持されるようにしてもよい。本例では「処理形式ａ」に従って処理されたことが示されている。この場合は、本実施例のデータ処理システムは複数の処理形式を有しており、その中から処理対象データの処理形式に適合する処理形式を選択し、これに基づいてルールとの照合等を行うことになる。なお、ここでの「処理形式」は、データに含まれる項目やレイアウトなどのほか、その処理仕様をも含み得る概念である。
【００２６】
次に、以上のようなテーブルに保持されたルールと履歴情報とに基づいて処理の可否の判断を行う具体例について説明する。まず図５に示すように、受注にかかる処理対象データ０５０１をデータ処理システムが、これに関連付けられた処理仕様０５０２とともに外部装置から取得した場合に、データ処理システムが当該受注入力にかかる処理を実行可能かどうか判断する例について説明する。この場合、データ処理システムは、処理対象データの処理形式が、例えば自ら保持する処理形式データに照らし「処理形式ａ」であるとの情報を得る。そこで、この処理形式ａについてのルールを検索して得られた図３（ｂ）に示したのと同様のルール０５０３に照らし、本例はプロセスコードが「ｏｒｄｅｒ」であるので、処理前ステータスは「ｎｕｌｌ」であるとの情報を取得する。次に、データ処理システムは、取引ＩＤに基づいて履歴情報を検索するが、本例では、取得した処理対象データは最初のものであり、未だ取引ＩＤは付与されていないため、履歴情報は存在しない。そこで、データ処理システムはこの処理対象データに取引ＩＤ「Ｔ００００１」を付与するとともに、取引ＩＤ「Ｔ００００１」のステータスが「ｎｕｌｌ」であるとの履歴情報０５０４が存在するとみなす。なお、取引ＩＤは、処理対象データ中の例えば顧客名及び受注日と関連付けたデータ０５０５として保持される。このルール及び履歴情報に基づく判断の結果、取引ＩＤ「００００１」のステータス「ｎｕｌｌ」はルールに合致しているので、処理実行可能と判断されることになる。そこで、データ処理システムは、この処理を実行した上で、当該処理対象データが当該処理仕様（処理形式ａ）にて処理済みとなったことを示すログ０５０６を生成する。このログに基づいて、当該取引ＩＤで識別される取引の履歴情報が「ｎｕｌｌ」から「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」に更新される（事実上は、取引ＩＤ「Ｔ００００１」を付与した上で「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」というステータスを記入した履歴情報０５０７が新たに生成、保持される。その際、処理仕様が「処理形式ａ」であることも履歴情報中に含めて保持される）。また、このログは外部装置にも送付される。そこで、外部装置がこのログにより、当該取引の取引ＩＤが「Ｔ００００１」を知ることができ、次回の処理要求からはこの取引ＩＤを用いることが可能となる。また、当該取引について受注入力の処理が実行されたことを知ることができる。
【００２７】
次に、図６に示すように、取引ＩＤ「Ｔ００００１」について上の処理がなされたステータスのときに、データ処理システムが、図５と同様の処理対象データ０６０１をこれに関連付けられた「Ｔ００００１を引当」という処理仕様０６０２とともに外部装置から取得したとする。この場合、図３（ｂ）に示したのと同様のルール０６０３に照らすと、本例はプロセスコードが「ｒｅｓｅｒｖｅ」であるので、処理前ステータスは「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」となる。また、データ処理システムは、図４に示すような履歴情報のテーブル内を検索して、取引ＩＤ「Ｔ００００１」にかかる履歴情報０６０４を読み出す。本例では、「Ｔ００００１」にかかる履歴情報の現在のステータスは「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」である。この結果、取引ＩＤ「００００１」のステータスはルールに合致しているので、処理実行可能と判断されることになる。そこで、データ処理システムは、この処理を実行した上で、当該処理対象データが処理済みとなったことを示すログ０６０６を生成する。このログに基づいて、当該取引ＩＤで識別される取引の履歴情報が「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」から「ｒｅｓｅｒｖｅｄ」０６０７に更新される。また、このログは外部装置にも送付される。なお、上では外部装置から取引ＩＤを付加して送付された処理対照データを取得する場合の例で説明した。これは例えば、受注入力の処理がなされたときに外部装置に送付されるログに含まれる取引ＩＤに基づいて外部装置が以後当該取引について処理対象データを送付する際に当該ＩＤを付加する場合である。他方、外部装置から送付される処理対照データには取引ＩＤは付加されず、これを取得したデータ処理システムが当該データに含まれる顧客名、受注日などによって上記のデータ０６０５に基づいて取引ＩＤを判断するようにしてもよい。
【００２８】
次に、図７に示すように、上記の取引ＩＤで識別される取引とは別の取引について、受注にかかる処理対象データ０７０１をデータ処理システムが、これに関連付けられた処理仕様０７０２とともに外部装置から取得したとすると、この場合には、上の処理対象データ０５０１の場合と同様の判断、処理がなされる。なお、ここで取得した処理対象データは当該取引としては最初のものであり、未だ取引ＩＤは付与されていないので、データ処理システムはこの処理対象データに取引ＩＤ「Ｔ００００２」を付与する。上述のように、履歴情報は、取引ＩＤで識別される取引ごとに保持されるので、本例でも、既に保持されている「Ｔ００００１」のステータスに「Ｔ００００２」のステータスを追加した履歴情報０７０７として保持される。
【００２９】
さらに、図８に示すように、取引ＩＤ「Ｔ００００２」の取引について上の処理がなされたステータスのときに、データ処理システムが、図７と同様の処理対象データ０８０１をこれに関連付けられた「Ｔ００００２を請求」という処理仕様０８０２とともに外部装置から取得したとする。この場合、図３（ｂ）に示したのと同様のルール０８０３に照らすと、本例はプロセスコードが「ｃｈａｒｇｅ」であるので、処理前ステータスは「ｓｈｉｐｐｅｄ」となる。しかし、履歴情報０８０４に照らすと、当該取引（取引ＩＤ「Ｔ００００２」）については、未だ前記処理による「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」というステータスにとどまっているので、条件を満たさない。そこで、データ処理システムは処理実行不可と判断して、処理実行は行わない。
【００３０】
以上の図５から図８までを用いて説明した例は、定められた手順に従った処理を適正に行う例であった。具体的には、処理しようとするプロセスのプロセスコードの処理前ステータスに照らし、履歴情報が合致する場合にのみ処理を実行するものであった。次に、これとは異なり、既に処理済みのデータの改竄を防止する例について説明する。図９に示すように、取引ＩＤ「Ｔ００００１」の取引について図６に示した処理がなされたステータスのときに、データ処理システムが、図５と同様の処理対象データであるが商品単価及び金額をそれぞれ「２００（円）」、「４００，０００（円）」と変更したデータ０９０１をこれに関連付けられた「Ｔ００００１を出荷」という処理仕様０９０２とともに外部装置から取得したとする。この場合、図３（ｂ）に示したルール０９０３に照らすと、本例はプロセスコードが「ｓｈｉｐ」であるので、処理前ステータスは「ｒｅｓｅｒｖｅｄ  ｏｒ  ｒｅｃｅｉｐｔｅｄ」となる。そこで、取引ＩＤ「Ｔ００００１」にかかる履歴情報の現在のステータスは「ｒｅｓｅｒｖｅｄ」であることから、この点についてはルール及び履歴情報に基づく判断結果は処理実行可能ということになる。この結果、取引ＩＤ「００００１」のステータス自体はこのルールには合致している。しかし、履歴情報０９０４は、図６などでは実は省略して書かれていたが、詳細には本図に示すような事項が含まれる履歴として保持されている（図５から図８までの例では、これらの履歴情報に照らして改竄はないと判断されたものとする）。そして、履歴情報に基づく判断に際しては、これら単価、数量、金額が一致するか否かも照合した上で処理実行の可否を判断する。本例では、取得した処理対象データ中の単価、金額と履歴情報中の単価、金額が一致しないので、処理実行不可と判断される。このようにして不正な改竄が行われた場合の処理を実行しないことができる。
【００３１】
次に、本実施例のデータ処理システムのハードウェア構成について説明する。図１０は本実施例のデータ処理システムのハードウェア構成の一例を示す概略図である。本図に示すように、本例のデータ処理システムの処理対象データ取得部、処理仕様取得部及び出力部は、「記憶装置（記録媒体）」１００１と、「メインメモリ」１００２と、「ＣＰＵ」１００３と、「インターフェイス」１００４などから構成される。履歴情報保持部、ルール保持部、判断部及び処理実行部は、「記憶装置（記録媒体）」と、「メインメモリ」と、「ＣＰＵ」などから構成される。これらは「システムバス」１００５などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。記憶装置はＣＰＵによって実行される各種プログラムなどを記憶している。またメインメモリは、プログラムがＣＰＵによって実行される際の作業領域であるワーク領域を提供する。また、このメインメモリや記憶装置にはそれぞれ複数のメモリアドレスが割り当てられており、ＣＰＵで実行されるプログラムは、そのメモリアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
【００３２】
記憶装置には予め取得プログラム、判断プログラム、処理実行プログラム及び出力プログラムが記憶されている。これらのプログラムはデータ処理システムの電源スイッチ投入等により自動的にメインメモリに展開されて常駐する。まず、ＣＰＵは、メインメモリに展開された取得プログラムを実行し、処理対象データ及びこのデータに関連付けられている処理仕様をインターフェイスを介して取得し、メインメモリに一時格納する。取得元は、例えば本システムが外付けされたコンピュータ装置である。あるいは、図示を省略したが本システムに備えられたキーボード、マウス等のインターフェイスを介してユーザが行ったデータ入力を受け付けて取得してもよい。
【００３３】
次に、ＣＰＵは判断プログラムを実行して、処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する。この場合、ＣＰＵは、記憶装置に記憶されているルールをメインメモリに読み出すとともに、記憶装置に記憶されている履歴情報もメインメモリに読み出す。そして、メインメモリに一時格納されている処理対象データ及びこれに関連付けられている処理仕様を読み出して、上記のルールと履歴情報に照らして処理を実行可能か判断する。ＣＰＵが処理実行可能と判断した場合、ＣＰＵは処理実行プログラムを実行してその処理対象データに対して、関連付けられている処理仕様の処理を実行する。具体的には、ＣＰＵがメインメモリに格納されている処理対象データを処理仕様に従って処理済となったことを示すログを生成して、メインメモリに格納するとともに、当該ログに基づき、履歴情報のステータスを処理前のステータスから処理後のステータスに更新する。例えば、図６で説明した例に即せば、０６０６で示したようなログを作成し、履歴情報のステータスを「ｏｒｄｅｒ  ｅｎｔｅｒｅｄ」から「ｒｅｓｅｒｖｅｄ」に更新する。更新前後の履歴情報は記憶装置に記憶される。さらに、ＣＰＵは出力プログラムを実行して、実行結果である上記ログをインターフェイスを介して外部装置に送付される。送付方法としては、例えば、ＣＰＵが上記ログを書き込んだメールを生成して、ネットワークを介して接続された外部装置の予め登録されたアドレスに基づいて当該メールを送信することなどが用いられる。他方、ＣＰＵが上記判断の結果処理実行不能と判断した場合は、処理を実行しない。
【００３４】
<処理の流れ>
図１１は、本実施例のデータ処理システムにおける処理の流れの一例を示す図である。本例の処理の流れは、以下のステップからなる。まず、処理対象データ取得ステップＳ１１０１において、データ処理システムは処理対象データを取得する。次に、処理仕様取得ステップＳ１１０２において、データ処理システムは、前記処理対象データ取得ステップにて取得した処理対象データと関連付けられている処理仕様を取得する。次に、ルール読出しステップＳ１１０３において、データ処理システムは、取得した処理対象データに対して関連付けられて取得された前記処理仕様に基づいた処理を実行するか実行しないか判断するためのルールを記憶装置から読み出す。次に、履歴情報読出しステップＳ１１０４において、データ処理システムは処理対象データに対して実行済みの処理仕様を関連付けた履歴情報を記憶装置から読み出す。なお、ルール読出しステップにおける処理と履歴情報読出しステップにおける処理は逆の順序でなされてもよい。次に、判断ステップＳ１１０５において、データ処理システムは、前記ルール読出しステップにて読み出したルールと、前記履歴情報読出しステップにて読み出した履歴情報とに基づいて、前記取得した処理対象データに対して関連付けられている処理仕様に基づいた処理を実行可能か判断する。そして、その判断結果が処理実行可能との判断結果である場合には、処理実行ステップＳ１１０６において、データ処理システムは、その処理対象データに対して関連付けられている処理仕様の処理を実行する。さらに、出力ステップＳ０５０７において、データ処理システムは前記処理実行ステップでの実行結果を出力する。
【００３５】
<効果>
本実施例のデータ処理システムにより、データの処理履歴をすべて保持し、この処理履歴と処理ルールとを照合することにより処理の可否を判断することができるので、データの改竄や処理手順に反するデータ処理を防止することが可能となる。
【実施例２】
【００３６】
<概要>
本実施例のデータ処理システムは、基本的に実施例１のシステムと共通するが、判断部での判断結果が処理実行不可との判断結果である場合に警告情報を出力する手段をさらに有する点に特徴を有する。
【００３７】
<構成>
図１２は、本実施例のデータ処理システムの機能ブロックの一例を示す図である。本例のシステムは基本的に実施例１のシステムと共通する。ただし、本実施例の「データ処理システム」１２００は「警告情報出力部」１２０８をさらに有する。「警告情報出力部」は、判断部での判断結果が処理実行不可との判断結果である場合には警告情報を出力するように構成されている。警告情報を出す目的は、処理対象データに対する処理が処理実行不可と判断されたことを積極的に外部装置等の処理要求元に通知することで、処理要求元が次のアクション、特に処理実行不可と判断された原因を是正したアクションを迅速的確にとることを可能にすることにある。つまり、実施例１においては、処理実行不可と判断された場合には、単に処理済みであることを示すログを処理要求元に送付しないことで間接的に処理が実行されなかったことを示すとの構成も含まれるが、かかる構成に比べ、本実施例のように構成すれば、処理要求元は、より早い機会に確実に実行されなかったことを知ることができるので、その後の迅速な措置を促すことができる。このため、警告には、処理実行不可と判断された原因を含めることが望ましい。警告を出す方法としては、例えば、警告メッセージを含むメールを生成して、ネットワークを介して接続されている外部装置の予め登録されたアドレスに基づいて当該メールを送信することなどが用いられる。警告メッセージの内容は、例えば「処理は以下のエラーのため実行されませんでした。エラーの内容：現在のステータス「ｒｅｓｅｒｖｅｄ」においては請求を実行することはできません。」といったものである。
【００３８】
図１３は、本実施例のデータ処理システムのハードウェア構成の一例を示す概略図である。本図に示すように、本例のシステムの警告情報出力部は、「記憶装置（記録媒体）」１３０１と、「メインメモリ」１３０２と、「ＣＰＵ」１３０３と、「インターフェイス」１３０４などから構成される。これらも「システムバス」１３０５などのデータ通信経路によって相互に接続されている。実施例１で説明した構成に従い、ＣＰＵがルールと履歴情報に照らして処理実行不可と判断した場合、ＣＰＵは警告情報出力プログラムを実行して、まず警告情報を生成する。この生成は、例えば警告情報出力プログラムに含まれる予め登録された定型文によってメールのメッセージを作成せよとの命令に従って行われる。この定型文が「処理は以下のエラーのため実行されませんでした。エラーの内容：○○」というメッセージの場合、ＣＰＵは当該メッセージを生成するため、ルール及び履歴情報を読み出してエラーの内容をメッセージに書き込む。生成されたメールメッセージは一旦メインメモリに格納された後、ＣＰＵがインターフェイスを介して外部装置などの処理要求元に送信する。その余の構成は、実施例１と同じであるから、説明を省略する。
【００３９】
<処理の流れ>
図１４は、本実施例のデータ処理システムにおける処理の流れの一例を示す図である。本実施例の処理の流れは、基本的に実施例１の処理の流れと共通する。ただし、本例では、ルールと履歴情報とに基づいて処理仕様に基づく処理を実行可能か判断する判断ステップＳ１４０５における判断結果が処理実行不可との判断結果である場合、警告情報出力ステップＳ１４０８において、データ処理システムは警告情報を出力する。その余の処理の流れは実施例１と同じであるから、説明を省略する。
【００４０】
<効果>
本実施例のデータ処理システムにより、処理対象データに対する処理が処理実行不可と判断されたときに警告情報を出すことで、この判断を積極的に外部装置等の処理要求元に通知し、処理要求元の次のアクションを促すことができる。
【実施例３】
【００４１】
<概要>
本実施例のデータ処理システムは、基本的に実施例１又は２のシステムと共通するが、処理対象データ取得部と、処理仕様取得部とは、取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更を受け付ける手段を有する点に特徴がある。
【００４２】
<構成>
図１５は、本実施例のデータ処理システムの機能ブロックの一例を示す図である。本例のシステムは基本的に実施例１又は２のシステムと共通する。ただし、本実施例の「データ処理システム」１５００の「処理対象データ取得部」１５０１と「処理仕様取得部」１５０２は「変更受付け手段」１５０９を有する。「変更受付け手段」は、取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更を受け付けるように構成されている。なお、本図では作図の便宜上変更受付け手段が処理対象データ取得部と処理仕様取得部の双方に記載されているが、当該手段は両部が共有する一の手段である。処理形式には、データに含まれる項目やレイアウトなどのほか、その処理仕様をも含み得る。取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更を受け付けるように構成する目的は、特に本データ処理システムが外部装置に外付けされる場合、外部装置から取得する処理対象データの処理形式には様々なものがあり得ることから、ハードウェア、オペレーティングシステム、プログラミング言語が換装される等の事情により処理形式の変換が必要になった場合に、それがどのような処理形式であってもこれに合わせて最適化するための変更を行うことで、当該データに対する判断、処理を可能にすることにある。
【００４３】
変更受付け手段が取得すべきデータ及び仕様の処理形式に合わせた最適化のための変更受付けとは、例えば、データ処理システムが処理データ及び仕様を取得した場合に、そのデータ形式が同一の取引について既に処理されたデータ形式、具体的には履歴情報中の処理形式欄に保持されている処理形式と異なっている場合に、この今回取得した処理形式に合わせて最適化するため、当該データ等の変更を受け付けるという意味である。
【００４４】
図１６は、本実施例のデータ処理システムのハードウェア構成の一例を示す概略図である。本図に示すように、本例のシステムの変更受付け手段を含む処理対象データ取得部と処理仕様取得部は、「記憶装置（記録媒体）」１６０１と、「メインメモリ」１６０２と、「ＣＰＵ」１６０３と、「インターフェイス」１６０４などから構成される。これらも「システムバス」１６０５などのデータ通信経路によって相互に接続されている。取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更の受付けは、以下のようなハードウェア構成により実現される。即ち、ＣＰＵは、実施例１で述べたように、メインメモリに展開された取得プログラムを実行し、処理対象データ及びこのデータに関連付けられている処理仕様をインターフェイスを介して取得するが、その際、ＣＰＵはデータ又は処理仕様に含まれる処理形式にかかる情報（ここでは「処理形式情報」という。）を抽出してメインメモリに一次格納する。次に、ＣＰＵは自ら保持する複数の処理形式を検索して上記処理形式情報と比較照合することにより、例えば当該処理形式が「処理形式ｂ」であるとの情報を得る。一方、ＣＰＵは実施例１と同様の処理に従ってメインメモリに読み出した履歴情報を検索し、履歴情報中の「処理形式」欄の記載から、これまでの処理は「処理形式ａ」に従って処理されてきたとの情報を取得する。そこで、これらの比較照合の結果、今回の処理においては処理形式をｂに合わせてデータを最適化するため、履歴情報中で保持されている処理形式のａからｂへの変更を受け付ける。具体的には、ＣＰＵが、履歴情報中の処理形式欄記載の処理形式を「処理形式ｂ」に変更し、変更後の履歴情報をメインメモリに一時格納する。そして、この変更後の履歴情報とルールとに基づいて処理実行可否の判断を行って、処理実行可能との判断が得られた場合、処理を実行するとともに、この処理済みであることを示すログを生成して、このログに基づいて履歴情報のステータスを変更する。その際、履歴情報の処理形式欄は上述の処理により既に処理形式ｂに変更済みであるので、今後は再度処理形式の変更を行わない限り、この変更後の処理形式ｂによって履歴情報が保持、変更されていくことになる。その余の構成は、実施例１と同じであるから、説明を省略する。
【００４５】
<処理の流れ>
図１７は、本実施例のデータ処理システムにおける処理の流れのうち、取得すべきデータ及び仕様の処理形式に合わせて最適化するための変更の受付にかかる処理の流れの一例を示す図である。本実施例の処理の流れは、以下のステップからなる。まず、データ処理システムは、取得した処理対象データ及び処理仕様の処理形式を抽出する（ステップＳ１７０１）。次に、データ処理システムは、自ら保持する複数の処理形式を検索して処理形式と比較照合する（ステップＳ１７０２）。次に、データ処理システムは、履歴情報を検索し、履歴情報中の「処理形式」欄の記載から、これまでの処理にかかる処理形式情報を取得 する（ステップＳ１７０３）。次に、データ処理システムは、最適化のために履歴情報中で保持されている処理形式の変更が必要か否か判断し（ステップＳ１７０４）、必要との判断結果が得られた場合、データ処理システムは履歴情報中の処理形式を変更する（ステップＳ１７０５）。以上の結果、データ処理システムは変更後の履歴情報とルールとに基づいて処理実行可否の判断を行って、処理実行可能との判断が得られた場合、変更後の処理形式を用いて処理を実行することとなる。その余の処理の流れは実施例１と同じであるから、説明を省略する。
【００４６】
<効果>
本実施例のデータ処理システムにより、特に本システムが外付けの場合に、外部装置から取得する処理対象データの処理形式に合わせて最適な処理形式に変更することが可能となり、処理形式ごとに装置全体を構築する場合に比べて構築に要するコストを削減することが可能となる。
【実施例４】
【００４７】
<概要>
本実施例のデータ処理システムは、基本的に実施例１から３のいずれか一のシステムと共通するが、出力部での出力フォーマットを管理する手段を有する点、及び出力部での出力が管理されているフォーマットに従ってなされる点に特徴がある。
【００４８】
<構成>
図１８は、本実施例のデータ処理システムの機能ブロックの一例について説明する図である。本例のシステムは基本的に実施例１から３のいずれか一のシステムと共通する。ただし、本実施例の「データ処理システム」１８００は、「出力フォーマット管理部」１８１０を有する。「出力フォーマット管理部」は、出力部での出力フォーマットを管理するように構成されている。また、「出力部」での出力は管理されているフォーマットに従ってなされるように構成されている。
【００４９】
かかる構成は、外部への報告用のフォーマットが異なっている場合に所定のフォーマットに変更してデータを出力できるようにすることを目的とする。例えば、企業に対する会計監査を適正に行うために外部の公認会計士等による監査を行う場合には、外部への報告書のフォーマットを会計士等に理解可能なフォーマットとする必要があり、仮にそのフォーマットが実施例３までで述べてきたような企業の販売管理用のフォーマットと異なっていれば、販売管理用のフォーマットに追加、変更あるいは削除を加えた、報告に適したフォーマットに修正する必要がある。そこで、かかる追加、変更、削除等を加えたフォーマットで出力できる手段を備えたシステムとすることにより、かかる目的の実現を図ったものが本実施例のシステムである。
【００５０】
フォーマットの管理のための具体的構成は、実施例３と同様の公知技術が用いられる。図１９は、参考までに、実施例１などで用いた販売管理の例うち受注入力にかかる監査用の報告書のフォーマットの一例を示す。これを図５で示した販売管理のための処理対象データ０５０１などの例と比較すると、本例のフォーマットでは、監査用独自の項目として、「リスク」１９０１、「コントロール」１９０２、「検証結果」１９０３といった項目が追加されている。そこで、データ処理システムは、かかるフォーマットで出力するために、これらの項目を追加し、あるいはこれに加え販売管理用のフォーマットから不要な項目を削除する等のフォーマット管理を行う。かかる管理における項目の取捨選択は、例えば予め保持する報告書のフォーマットに追加すべき項目のリストなどに基づいて行われる。なお、「検証結果」は、本システムが該当欄のリスクに対処するために定められたコントロールに関し、どのような処理を実行したかを記入するための欄である。例えば「注文金額５００ドル以上は承認必要」というコントロール欄１９０４に対応する検証結果欄１９０５には、例えば「注文金額が５００ドル以上の注文が承認なしに出荷されていないことをチェックした」との結果が記入される。このための前提として、例えば本実施例のシステムのルール保持部が保持するルール中にかかるルールが規定され、また、当該ルール及び履歴情報に基づいてかかるルールに合致しているとの判断の下に処理が実行されたとの履歴情報に基づいて、本システムが自動的にかかる検証結果を生成して記入するように構成されていることが望ましい。
【００５１】
出力部が行う出力は、どのような方法によってもよい。例えば、メールを生成して、ネットワークを介して接続された外部装置の予め登録されたアドレスに基づいて当該メールを送信することなどが考えられる。あるいはハードコピーを送付するためにプリントアウトするという方法でもよい。
【００５２】
図２０は、本実施例のデータ処理システムのハードウェア構成の一例を示す概略図である。本図に示すように、本例のシステムの出力フォーマット管理部は、「記憶装置（記録媒体）」２００１と、「メインメモリ」２００２と、「ＣＰＵ」２００３などから構成される。これらも「システムバス」２００５などのデータ通信経路によって相互に接続されている。出力フォーマットの管理は、以下のようなハードウェア構成により実現される。即ち、ＣＰＵは、実施例１で述べた構成に従い処理実行プログラムを実行して処理後のステータスに更新されて格納された履歴情報を読み出す。一方、記憶装置には出力管理プログラムが保持されており、ＣＰＵはメインメモリに展開された当該プログラムを実行して、例えば記憶装置に保持する報告書用のフォーマットに追加すべき項目リストをメインメモリに読み出すとともに、履歴情報も読み出して、そのフォーマット欄中に保持されているフォーマットをこの報告書用のフォーマットに変更してメインメモリの別の領域に一旦格納する。次に、ＣＰＵが出力プログラムを実行してこの報告書用のフォーマットに変更された履歴情報を読み出し、所要の事項を記入して報告書とした上で、インターフェイスを介して外部装置などに送付する。所要の事項の記入は、例えば履歴情報に基づいてユーザ等がキーボード等を用いて行った入力を受け付けることで実行される。その余の構成は実施例１と同じであるから、説明を省略する。
【００５３】
<処理の流れ>
図２１は、本実施例のデータ処理システムにおける処理の流れのうち、出力フォーマット管理及び出力にかかる処理の流れの一例を示す図である。本実施例の処理の流れは、以下のステップからなる。まず、データ処理システムは、予め保持された報告書用のフォーマットに追加すべき項目リストを読み出す（ステップＳ２１０１）。次に、データ処理システムは、履歴情報を読み出す（ステップＳ２１０２）。次に、データ処理システムは、前記ステップＳ２１０２にて読み出した履歴情報中に保持されているデータ項目等と前記ステップＳ２１０１にて読み出した項目リストとに基づいて報告書用のフォーマットに変更する（ステップＳ２１０３）。さらに、データ処理システムは、この報告書用のフォーマットにて作成された報告書を出力する（例えば外部装置などに送付する）（ステップＳ２１０４）。その余の処理の流れは実施例１と同じであるから、説明を省略する。
【００５４】
<効果>
本実施例のデータ処理システムにより、外部への報告用のフォーマットが異なっている場合でも所定のフォーマットに変更してデータを出力することが可能となる。
【図面の簡単な説明】
【００５５】
【図１】実施例１のデータ処理システムの機能ブロックの一例を示す図
【図２】実施例１のデータ処理システムの具体的構成の一例を説明するための概念図
【図３】実施例１のデータ処理システムの具体的構成の一例を説明するための概念図
【図４】実施例１のデータ処理システムにおける履歴情報のテーブルの一例を示す図
【図５】実施例１のデータ処理システムにおける処理の可否の判断の具体例を説明するための図
【図６】実施例１のデータ処理システムにおける処理の可否の判断の具体例を説明するための図
【図７】実施例１のデータ処理システムにおける処理の可否の判断の具体例を説明するための図
【図８】実施例１のデータ処理システムにおける処理の可否の判断の具体例を説明するための図
【図９】実施例１のデータ処理システムにおける処理の可否の判断の具体例を説明するための図
【図１０】実施例１のデータ処理システムのハードウェア構成の一例を示す概略図
【図１１】実施例１のデータ処理システムにおける処理の流れの一例を示す図
【図１２】実施例２のデータ処理システムの機能ブロックの一例を示す図
【図１３】実施例２のデータ処理システムのハードウェア構成の一例を示す概略図
【図１４】実施例２のデータ処理システムにおける処理の流れの一例を示す図
【図１５】実施例３のデータ処理システムの機能ブロックの一例を示す図
【図１６】実施例３のデータ処理システムのハードウェア構成の一例を示す概略図
【図１７】実施例３のデータ処理システムにおける処理の流れの一例を示す図
【図１８】実施例４のデータ処理システムの機能ブロックの一例を示す図
【図１９】実施例４のデータ処理システムにおける報告書のフォーマットの一例を示す図
【図２０】実施例４のデータ処理システムのハードウェア構成の一例を示す概略図
【図２１】実施例４のデータ処理システムにおける処理の流れの一例を示す図
【符号の説明】
【００５６】
０１００      データ処理システム
０１０１      処理対象データ取得部
０１０２      処理仕様取得部
０１０３      履歴情報保持部
０１０４      ルール保持部
０１０５      判断部
０１０６      処理実行部
０１０７      出力部
【図１】
2007323406.tif 000003
【図２】
2007323406.tif 000004
【図３】
2007323406.tif 000005
【図４】
2007323406.tif 000006
【図５】
2007323406.tif 000007
【図６】
2007323406.tif 000008
【図７】
2007323406.tif 000009
【図８】
2007323406.tif 000010
【図９】
2007323406.tif 000011
【図１０】
2007323406.tif 000012
【図１１】
2007323406.tif 000013
【図１２】
2007323406.tif 000014
【図１３】
2007323406.tif 000015
【図１４】
2007323406.tif 000016
【図１５】
2007323406.tif 000017
【図１６】
2007323406.tif 000018
【図１７】
2007323406.tif 000019
【図１８】
2007323406.tif 000020
【図１９】
2007323406.tif 000021
【図２０】
2007323406.tif 000022
【図２１】
2007323406.tif 000023