承認履歴管理をする複数システムの承認履歴統合管理実現装置、その方法、及びそのプログラム
【課題】企業内の各基幹システムやワークフローシステムから発生した取引伝票の情報を、独自方式で実装する複数システムにおいて原始発生から会計計上にいたる伝票の承認履歴（例えば承認日時・承認者・承認者所属等）情報を統合ＤＢ（Database）にて一括管理する。
【解決手段】承認履歴情報の収集装置を汎用的な入力部品とすることとし、データフォーマットやコード体系など各コンピュータシステムによる差異を吸収した情報に変換した上で共通の保管装置に格納する。また、各コンピュータシステム共通の保管装置に格納された承認履歴情報を参照装置で活用する。これにより、各コンピュータシステムの情報を統合管理する。
【解決手段】承認履歴情報の収集装置を汎用的な入力部品とすることとし、データフォーマットやコード体系など各コンピュータシステムによる差異を吸収した情報に変換した上で共通の保管装置に格納する。また、各コンピュータシステム共通の保管装置に格納された承認履歴情報を参照装置で活用する。これにより、各コンピュータシステムの情報を統合管理する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は取引伝票の情報を管理するコンピュータ装置、その方法及びそのプログラムに関し、より詳細には前記取引伝票の情報の承認に関する履歴情報の一括管理を行うコンピュータ装置、その方法及びそのプログラムに関する。
【背景技術】
【０００２】
近年、企業が開示する企業内の各基幹システムやワークフローシステムから発生した取引伝票についての情報、なかでも取引伝票についての原始発生から会計計上にいたる伝票の承認履歴に対しては、以前にもましてその正確性及び真実性があることが求められている。
【０００３】
また、会計情報を迅速に閲覧及び検索し、探索することや、的確に把握する必要があるとの側面もある。このような、正確性及び真実性に対しての要求や、的確かつ迅速に把握すべきとの要求は、公認会計士が行う会計監査の場面、監査役等及び内部監査人が行う業務監査の場面、また日常的・定期的な経費の計上などの場面といった、多岐にわたるいずれの場合であっても存在している。
【０００４】
一方、各企業の業務の取引内容及びそれに伴う会計情報の内容は、その業態や、またその部署によっても大きく異なる。
【０００５】
更に、業務の取引内容に伴う会計情報は多種多様なコンピュータシステムによって管理されていることが多く、また前記コンピュータシステムも部門や部署ごとの会計情報の違いといった観点から必ずしも入力内容のフォーマットが統一されているわけではなかった。
【０００６】
加えて、前記会計情報に基づいた会計の計上を行う場合に、会計計上に至るまでの過程もまた多種多様化しているという問題もあった。
【０００７】
上記の様な背景から、会計情報の真実性や、会計状況の妥当性を検査するために、会計伝票の承認履歴を閲覧しようとした際には、個別の承認履歴を管理している各コンピュータシステム内の探索が非常に困難かつ煩雑になっているという問題が生じていた。
【０００８】
前記問題点解決のための従来技術として、取引伝票を含む各種伝票情報を電子化する技術が存在する（例えば特許文献１参照）。
【０００９】
特許文献１で開示されている伝票情報電子化技術を用いることにより、オフィス内でのペーパーレス化が進むといった利点や、上司の承認に関する手続の簡易化が図れるという利点があった。
【００１０】
加えて、電子化をすることにより伝票情報をデータベースとして管理することが可能となるといったメリットもあった。
【００１１】
また、ＥＤＩ（電子データ交換の標準規則）に従ってＥＤＩ伝票データが記述されているＥＤＩ標準ファイルをマッピング定義ファイル内のＲＤＢ（Relational Database）変換規則により標準形式にすることにより、ＲＤＢを構築するという技術も用いられている（例えば特許文献２参照）。
【００１２】
特許文献２に開示されている技術を用いることにより、ＥＤＩ伝票データを関係データベース（ＲＤＢ）として保持すること及び管理することができるといったメリットがあった。
【特許文献１】特開昭６１−２０４７６６号公報
【特許文献２】特開平０９−３１９８１１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
前記の各種伝票情報を電子化する技術を実施するためには、オペレーターが端末操作を行い伝票情報を端末に入力する必要がある。この際に入力する項目（例えば取引伝票の番号や、取引を行ったシステムの種別、承認日時、承認者、承認者所属等）をあらかじめ厳格に定めておかなくてはならなかった。
【００１４】
また、あらかじめ定めた入力に関する項目を、統一した形に沿ってオペレーターが漏れなく入力しなくては、入力伝票情報をデータベースとして活用することができなくなるという問題があった。
【００１５】
また、特許文献２に開示されている前記ＥＤＩ変換を行う技術を用いても、親会社と子会社のそれぞれが、異なる業界についての会社であるような企業では、全てのグループ会社で取引伝票のＥＤＩ化を図り、取引伝票の情報を統一した形で管理することは困難であった。
【００１６】
データ形式やコンピュータシステム、ネットワークの接続形態は業界ごとに違うためである。よって、前記ＥＤＩ変換を行う技術を利用するためには各会社が業界ごとに最適であるフォーマットが異なるという前提を考慮せずに、一つのフォーマットに従い伝票を起票する必要があるという問題があった。
【００１７】
なお、以下では前記で例示した伝票に入力するべき項目として予め定めておく項目を指して、「フォーマット」という文言をもちいる。
【００１８】
更に、従来技術では、承認履歴情報の、「収集」、「保管」、「参照」を行う各装置は、データフォーマットやコード体系などが異なった各コンピュータシステムでの個別の構築方式に合わせて、それぞれ独自に実装する必要があるという問題点もあった。
【００１９】
加えて承認履歴情報の活用も各コンピュータシステムそれぞれが別個で行っているという点も問題である。
【００２０】
そこで、本発明は、企業内の各基幹システムやワークフローシステムから発生した取引伝票について、原始発生から会計計上にいたる伝票の承認履歴（例えば承認日時、承認者、承認者所属等）情報を統合ＤＢ（Database）にて一括管理することが可能な、承認履歴管理を独自方式で実装する複数システムにおいて承認履歴管理の統合を実現する装置、その方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明によれば、承認履歴管理をする複数システムの承認履歴統合管理実現装置であって、前記複数システムより承認情報を取得する手段と、前記複数システムのそれぞれに対応する変換定義を保持する手段と、前記取得した承認情報を前記保持する変換定義情報に基づき変換する手段と、前記変換した情報を承認履歴情報として格納し保持する手段とを備えることを特徴とする承認履歴管理をする複数システムの承認履歴統合管理実現装置、その方法、そのプログラムが提供される。
【００２２】
上記の管理実現装置、その方法、そのプログラムにおいて前記格納し保持した承認履歴情報を項目ごとに管理する手段と、閲覧を要求された項目について前記承認履歴情報を検索する手段と、前記検索により取得した情報を提示する手段とを更に備えることを特徴とするようにしてもよい。
【発明の効果】
【００２３】
本発明によれば、企業内の各基幹システムやワークフローシステムから発生した取引伝票について、原始発生から会計計上にいたる伝票の承認履歴情報を統合ＤＢにて一括管理し、簡便な閲覧探索を可能とすることで、企業会計の内部統制を強化される。よって、承認履歴管理を独自方式で実装する複数システムにおいて、承認履歴管理の統合を実現することが可能となる。
【発明を実施するための最良の形態】
【００２４】
次に、本発明の最良の形態について図面を用いて説明する。
【００２５】
［実施形態］
（実施形態の構成）
本発明の実施形態の構成について図１を用いて説明する。
【００２６】
本発明の実施形態は、汎用入力プログラム１０１と、変換定義データベース１０２と、承認履歴データベース１０３と、検索・閲覧プログラム１０４と、表示装置１０５とを備える。
【００２７】
なお、前記実施形態の説明においては、承認情報を取得する相手方である入力装置を備えるコンピュータシステムを、第一のコンピュータシステム２０１と、第二のコンピュータシステム３０１として説明する。
【００２８】
ここで、汎用入力プログラム１０１は、入力された変換前の承認情報を、変換定義要求として変換定義データベース１０２に出力し、変換定義データベース１０２にデータベースに保持されている情報を参照することにより、前記変換定義要求の結果としてデータフォーマットやコード体系の変換を行い変換後の承認情報を承認履歴データベース１０３に出力する機能を備えている。
【００２９】
変換定義データベース１０２は、複数のコンピュータシステムのそれぞれに対応する変換に必要な情報を定義した、変換定義情報を定義し、保持している部分である。
【００３０】
該変換定義データベース１０２は、汎用入力プログラム１０１の変換定義要求を受け、変換定義要求結果として自らに格納・保持されている変換に必要な情報を出力する機能を備えている。
【００３１】
承認履歴データベース１０３は、共通フォーマットに統一された承認情報を格納する部分である。
【００３２】
検索・閲覧プログラム１０４は、共通フォーマットに統一された変換後の承認情報を承認履歴データベース１０３の中より検索する機能及び発見した承認情報を、表示装置１０５に受け渡す機能を有する。
【００３３】
表示装置１０５は、承認履歴の検索結果を表示する部分である。検索・閲覧プログラム１０４より前記共通フォーマットに統一された変換後の承認情報を受け取り、外部へ前記変換後の承認情報を出力する機能を有する。
【００３４】
前記、各コンピュータシステムは、入力装置２５１又は入力装置３５１を備え、伝票による取引を行い管理するためのコンピュータシステムである。
【００３５】
各コンピュータシステムは入力装置２５１又は入力装置３５１から承認情報と取引伝票の識別情報を受け取り、該情報を汎用入力プログラム１０１へ引き渡す機能を有している。
【００３６】
（実施形態の動作の説明）
本実施形態の動作について、以下図面を用いて説明する。
【００３７】
始めに承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースを構築する動作について以下説明する。なお下記のデータベース構築のための各手順については、図５でフローチャートとして示している。
【００３８】
まず、業務取引を管理する各コンピュータシステム（ここでは、第一のコンピュータシステム２０１を例に以下説明する）の入力装置に承認のために情報が入力される。
【００３９】
前記取引の入力装置に承認のために情報が入力される際に、同時に承認内容の情報と取引伝票の識別情報が汎用入力プログラム１０１へファイルとして送信される（Ｓ１０１）。
【００４０】
なお、前記取引伝票の識別情報としては、取引伝票の通し番号や、承認申請の日時、が例として挙げられる。ここで、前記各項目はあくまで例示であり、これら全ての入力を必ずしも必要とするものではない。また前記例示した項目以外の項目を入力必要項目とするようにしてもよい。
【００４１】
次に、汎用入力プログラム１０１は前記承認内容の情報と取引伝票の識別情報をファイル転送により受け取る。また、この際に前記受け取った情報を個々のものとして識別するために、新たな伝票番号を識別符号として作成する。
【００４２】
そして、前記受け取った情報に前記識別符号を付加する（以下、当該付加した識別符号を原始伝票番号という）（Ｓ２０１）。
【００４３】
ここで、前記受け取った情報は各コンピュータシステムからそれぞれのデータフォーマットやコード体系で送られてきたものである。各コンピュータシステムの相違から、データフォーマットやコード体系は統一されておらず、発信元のコンピュータシステムごとに異なったフォーマットやコード体系となっている。
【００４４】
すなわち、第一のコンピュータシステム２０１から送られてきた情報は該第一のコンピュータシステム２０１が採用しているフォーマットやコード体系のままであり、他方、第二のコンピュータシステム３０１から送られてきた情報は該第二のコンピュータシステム３０１が採用しているフォーマットやコード体系のままである。
【００４５】
そのため、このままでは共通のデータベースで一元管理することができない。そこで汎用入力プログラム１０１はフォーマットやコード体系を統一する必要がある。
【００４６】
この点、汎用入力プログラム１０１は、まず変換定義データベース１０２に保持されているフォーマットやコード体系の変換定義の中から、前記の今回受け取った承認内容の情報及び取引伝票の識別情報に対応する定義を、検索する（Ｓ３０１）。
【００４７】
なお、ここで変換定義データベース１０２に前記今回受け取った承認内容の情報及び取引伝票の識別情報に対応する定義がなかった場合が考えられる。
【００４８】
その場合は、前記今回の情報の送信元であるコンピュータシステムに対応する定義を、汎用入力プログラム１０１が前記の情報の送信元であるコンピュータシステムに要求し、それにより取得した定義を汎用入力プログラム１０１が新たに変換定義データベース１０２に入力する。
【００４９】
これにより以降は、前記定義づけされていなかったコンピュータシステムからの前記情報転送にも対応することが可能となる（Ｓ３５１）。
【００５０】
次に、汎用入力プログラム１０１は前記検索を行い発見した今回の承認内容の情報と取引伝票の識別情報に合致する変換定義に基づいて前記情報を、統一された共通のフォーマットやコード体系に変換する（Ｓ４０１）。
【００５１】
ここで、変換定義データベース１０２の格納例を図２、図３へ示す。
【００５２】
図２では、システム種別ごとに採用されている文字コードの種別があらかじめ格納されており、定義づけされている状態を示している。
【００５３】
図２の例では販売管理システムが採用している文字コードはＳｈｉｆｔ−ＪＩＳコードであること及び購買管理システムが採用しているのは、ＥＵＣであることが示されている。よって汎用入力プログラム１０１は、前記定義されている前提にしたがって前記統一されたコード体系に変換することができる。
【００５４】
また、図３では図２と同様にシステム種別ごとに区分されている。ここで、例えば販売管理システムに所属している承認をした者がユーザＡであるとの情報が第一のコンピュータシステム２０１より汎用入力プログラム１０１に送られてきた場合を考える。
【００５５】
ここで、販売管理システムでは、当該部署の業務内容に適しているとして、承認を出す各社員は社員名が特定されないように、ユーザＡ、ユーザＢ、といった名称で管理されているとする。もっとも、前記共通のフォーマットでは、社員名で統一すべき旨が定められているとする。
【００５６】
この場合、汎用入力プログラム１０１は変換定義データベース１０２を検索し、図３の２列目を検出する。ここには、販売管理システムに所属している承認をした者ユーザＡとは、「日電太郎」を指す旨が定義されている。
【００５７】
よって、汎用入力プログラム１０１は前記定義に基づき「ユーザＡ」を共通フォーマットである社員名「日電太郎」へと変換することが可能となる。
【００５８】
次に、図６を参照すると汎用入力プログラム１０１は前記統一されたフォーマットやコード体系に変換された情報の取引伝票の識別符号（前記原始伝票番号）を確認し、その番号順に承認履歴データベース１０３へ格納する（Ｓ５０１）。
【００５９】
なお、承認履歴データベース１０３の格納例を図４で示す。前記図では前記原始伝票番号順に、前記変換された情報が格納されている状態を示している。
【００６０】
その後も、各コンピュータシステムから承認情報が転送されるたびに上記（Ｓ１０１）、（Ｓ２０１）、（Ｓ３０１）、（Ｓ３５１）、（Ｓ４０１）及び（Ｓ５０１）を繰り返す。
【００６１】
前記反復により、各コンピュータシステムから転送された承認情報に基づく前記承認内容の情報と取引伝票の識別情報は、フォーマットやコード体系が統一された状態で順次蓄積されていく。
【００６２】
更に、前記蓄積された情報は、前記原始伝票番号で管理される。これにより、承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースが構築されることとなる。
【００６３】
次に、会計監査や、業務監査、または定期的・日常的な経費の計上などの場面において前記データベースを利用する手順について説明する。なお下記のデータベース利用手順については、図６でフローチャートとして示している。
【００６４】
まず、検索・閲覧プログラム１０４が承認履歴データベース１０３を参照し、承認履歴データベース１０３から承認履歴情報を検索する（Ｓ６０１）。ここで、前記検索は、前記の原始伝票番号に基づいて行うことも可能である。
【００６５】
また、前記原始伝票番号に基づいて行う方法以外にも、他の項目を検索項目として検索することも可能である。
【００６６】
例えば、前記の各項目取引を、承認を行ったシステムの種別、承認日時、承認者、承認者所属を検索項目とし、検索するようにしてもよい。
【００６７】
この検索項目の変更をおこなうことより、ある特定の承認者の承認した伝票情報のみを抽出したり、ある期間に承認された取引伝票のみを抽出したりといった観点から承認履歴情報を統合参照することも可能となる。
【００６８】
更に、伝票の承認の際に会計伝票番号を割り振っているのであれば、前記会計伝票番号に基づいて検索するようにしてもよい。
【００６９】
以上より検索・閲覧プログラム１０４は、前記検索により得られた承認履歴情報を表示装置１０５に表示する（Ｓ７０１）。
【００７０】
なお、検索結果が充分では無い場合は、検索・閲覧プログラム１０４が前記に例示したような、他の項目を検索項目として改めて設定し、再度検索すればよい（Ｓ８０１）。これにより、承認履歴情報を、検索要求が充足するまで簡便に統合参照することができる。
【００７１】
（実施形態の効果の説明）
本発明より得られる効果は以下のものである。
【００７２】
まず、接続されているすべてのコンピュータシステムとやりとりを行うことで、発生した承認履歴情報を統合して管理することができるという効果が得られる。承認履歴情報を共通のデータベースで一元保持するためである。
【００７３】
これにより、統一すべき共通フォーマットを変更する場合も、各コンピュータシステムの設定を変えることなく変更することが可能となる。例えば、あるシステムにおける「ユーザＡ」が、今後、別の者に変更される場合であっても、共通の変換定義データベースの定義を変更するだけで足りることとなる。
【００７４】
また、事後的に以前の定義情報が誤っていたことが発覚し、承認履歴情報を訂正しなくてはならないような場合であっても承認履歴データベースに保持されている情報のみを訂正すればよいという効果が得られる。
【００７５】
更に、承認履歴情報を統合参照することができるという効果も得られる。承認履歴情報を共通の統合したデータベースから参照するためである。これにより各コンピュータシステムが相互に直接ネットワークとして接続されていない場合であっても、そのような直接ネットワークとして接続されていないコンピュータシステムの承認履歴情報も含めて、全ての承認履歴情報を統合参照することができるという効果が得られる。
【００７６】
次に、各コンピュータシステムの差異の吸収が可能となるという効果が得られる。ここで、前記差異とは各コンピュータシステムでのフォーマットやコード体系の違いのことである。前述のように共通の変換定義に基づいて共通のフォーマットやコード体系に変換を行うからである。
【００７７】
加えて各コンピュータシステムがシステムごとに個別にデータ変換プログラムや、変換定義を保持するデータベース、承認履歴を保持するデータベースといった機能や装置を実装する必要がないという効果もある。
【００７８】
前述のようにデータ変換プログラムや、変換定義を保持するデータベース、承認履歴を保持するデータベースといった機能や装置を各コンピュータシステムで共有することができるためである。
【００７９】
これにより、各コンピュータシステムは、自己のコンピュータシステムにおいて起動する入力装置のみを用意すればよいこととなる。
【産業上の利用可能性】
【００８０】
本発明にかかる履歴情報の一括管理を行うコンピュータ装置、そのプログラム及びその方法は、承認伝票のデータフォーマットやコード体系などが各コンピュータシステムにより差異がある場合であっても、標準化されたフォーマットやコード体系に変換し各コンピュータシステムの情報を統合管理することができるものとして有用である。
【図面の簡単な説明】
【００８１】
【図１】本発明の基本的構成を表すブロック図である。
【図２】変換定義データベースにおける、承認履歴情報の文字コードに関する格納例を示す図である。
【図３】変換定義データベースにおける、承認履歴情報の項目変換に関する格納例を示す図である。
【図４】承認履歴データベースにおける、承認履歴情報の格納例を示す図である。
【図５】承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースの構築するための動作について示したフローチャートである。
【図６】データベースを利用し承認履歴を照会する手順について示したフローチャートである。
【符号の説明】
【００８２】
１０１ 汎用入力プログラム
１０２ 変換定義データベース
１０３ 承認履歴データベース
１０４ 検索・閲覧プログラム
１０５ 表示装置
２０１ 第一のコンピュータシステム
３０１ 第二のコンピュータシステム
【技術分野】
【０００１】
本発明は取引伝票の情報を管理するコンピュータ装置、その方法及びそのプログラムに関し、より詳細には前記取引伝票の情報の承認に関する履歴情報の一括管理を行うコンピュータ装置、その方法及びそのプログラムに関する。
【背景技術】
【０００２】
近年、企業が開示する企業内の各基幹システムやワークフローシステムから発生した取引伝票についての情報、なかでも取引伝票についての原始発生から会計計上にいたる伝票の承認履歴に対しては、以前にもましてその正確性及び真実性があることが求められている。
【０００３】
また、会計情報を迅速に閲覧及び検索し、探索することや、的確に把握する必要があるとの側面もある。このような、正確性及び真実性に対しての要求や、的確かつ迅速に把握すべきとの要求は、公認会計士が行う会計監査の場面、監査役等及び内部監査人が行う業務監査の場面、また日常的・定期的な経費の計上などの場面といった、多岐にわたるいずれの場合であっても存在している。
【０００４】
一方、各企業の業務の取引内容及びそれに伴う会計情報の内容は、その業態や、またその部署によっても大きく異なる。
【０００５】
更に、業務の取引内容に伴う会計情報は多種多様なコンピュータシステムによって管理されていることが多く、また前記コンピュータシステムも部門や部署ごとの会計情報の違いといった観点から必ずしも入力内容のフォーマットが統一されているわけではなかった。
【０００６】
加えて、前記会計情報に基づいた会計の計上を行う場合に、会計計上に至るまでの過程もまた多種多様化しているという問題もあった。
【０００７】
上記の様な背景から、会計情報の真実性や、会計状況の妥当性を検査するために、会計伝票の承認履歴を閲覧しようとした際には、個別の承認履歴を管理している各コンピュータシステム内の探索が非常に困難かつ煩雑になっているという問題が生じていた。
【０００８】
前記問題点解決のための従来技術として、取引伝票を含む各種伝票情報を電子化する技術が存在する（例えば特許文献１参照）。
【０００９】
特許文献１で開示されている伝票情報電子化技術を用いることにより、オフィス内でのペーパーレス化が進むといった利点や、上司の承認に関する手続の簡易化が図れるという利点があった。
【００１０】
加えて、電子化をすることにより伝票情報をデータベースとして管理することが可能となるといったメリットもあった。
【００１１】
また、ＥＤＩ（電子データ交換の標準規則）に従ってＥＤＩ伝票データが記述されているＥＤＩ標準ファイルをマッピング定義ファイル内のＲＤＢ（Relational Database）変換規則により標準形式にすることにより、ＲＤＢを構築するという技術も用いられている（例えば特許文献２参照）。
【００１２】
特許文献２に開示されている技術を用いることにより、ＥＤＩ伝票データを関係データベース（ＲＤＢ）として保持すること及び管理することができるといったメリットがあった。
【特許文献１】特開昭６１−２０４７６６号公報
【特許文献２】特開平０９−３１９８１１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
前記の各種伝票情報を電子化する技術を実施するためには、オペレーターが端末操作を行い伝票情報を端末に入力する必要がある。この際に入力する項目（例えば取引伝票の番号や、取引を行ったシステムの種別、承認日時、承認者、承認者所属等）をあらかじめ厳格に定めておかなくてはならなかった。
【００１４】
また、あらかじめ定めた入力に関する項目を、統一した形に沿ってオペレーターが漏れなく入力しなくては、入力伝票情報をデータベースとして活用することができなくなるという問題があった。
【００１５】
また、特許文献２に開示されている前記ＥＤＩ変換を行う技術を用いても、親会社と子会社のそれぞれが、異なる業界についての会社であるような企業では、全てのグループ会社で取引伝票のＥＤＩ化を図り、取引伝票の情報を統一した形で管理することは困難であった。
【００１６】
データ形式やコンピュータシステム、ネットワークの接続形態は業界ごとに違うためである。よって、前記ＥＤＩ変換を行う技術を利用するためには各会社が業界ごとに最適であるフォーマットが異なるという前提を考慮せずに、一つのフォーマットに従い伝票を起票する必要があるという問題があった。
【００１７】
なお、以下では前記で例示した伝票に入力するべき項目として予め定めておく項目を指して、「フォーマット」という文言をもちいる。
【００１８】
更に、従来技術では、承認履歴情報の、「収集」、「保管」、「参照」を行う各装置は、データフォーマットやコード体系などが異なった各コンピュータシステムでの個別の構築方式に合わせて、それぞれ独自に実装する必要があるという問題点もあった。
【００１９】
加えて承認履歴情報の活用も各コンピュータシステムそれぞれが別個で行っているという点も問題である。
【００２０】
そこで、本発明は、企業内の各基幹システムやワークフローシステムから発生した取引伝票について、原始発生から会計計上にいたる伝票の承認履歴（例えば承認日時、承認者、承認者所属等）情報を統合ＤＢ（Database）にて一括管理することが可能な、承認履歴管理を独自方式で実装する複数システムにおいて承認履歴管理の統合を実現する装置、その方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明によれば、承認履歴管理をする複数システムの承認履歴統合管理実現装置であって、前記複数システムより承認情報を取得する手段と、前記複数システムのそれぞれに対応する変換定義を保持する手段と、前記取得した承認情報を前記保持する変換定義情報に基づき変換する手段と、前記変換した情報を承認履歴情報として格納し保持する手段とを備えることを特徴とする承認履歴管理をする複数システムの承認履歴統合管理実現装置、その方法、そのプログラムが提供される。
【００２２】
上記の管理実現装置、その方法、そのプログラムにおいて前記格納し保持した承認履歴情報を項目ごとに管理する手段と、閲覧を要求された項目について前記承認履歴情報を検索する手段と、前記検索により取得した情報を提示する手段とを更に備えることを特徴とするようにしてもよい。
【発明の効果】
【００２３】
本発明によれば、企業内の各基幹システムやワークフローシステムから発生した取引伝票について、原始発生から会計計上にいたる伝票の承認履歴情報を統合ＤＢにて一括管理し、簡便な閲覧探索を可能とすることで、企業会計の内部統制を強化される。よって、承認履歴管理を独自方式で実装する複数システムにおいて、承認履歴管理の統合を実現することが可能となる。
【発明を実施するための最良の形態】
【００２４】
次に、本発明の最良の形態について図面を用いて説明する。
【００２５】
［実施形態］
（実施形態の構成）
本発明の実施形態の構成について図１を用いて説明する。
【００２６】
本発明の実施形態は、汎用入力プログラム１０１と、変換定義データベース１０２と、承認履歴データベース１０３と、検索・閲覧プログラム１０４と、表示装置１０５とを備える。
【００２７】
なお、前記実施形態の説明においては、承認情報を取得する相手方である入力装置を備えるコンピュータシステムを、第一のコンピュータシステム２０１と、第二のコンピュータシステム３０１として説明する。
【００２８】
ここで、汎用入力プログラム１０１は、入力された変換前の承認情報を、変換定義要求として変換定義データベース１０２に出力し、変換定義データベース１０２にデータベースに保持されている情報を参照することにより、前記変換定義要求の結果としてデータフォーマットやコード体系の変換を行い変換後の承認情報を承認履歴データベース１０３に出力する機能を備えている。
【００２９】
変換定義データベース１０２は、複数のコンピュータシステムのそれぞれに対応する変換に必要な情報を定義した、変換定義情報を定義し、保持している部分である。
【００３０】
該変換定義データベース１０２は、汎用入力プログラム１０１の変換定義要求を受け、変換定義要求結果として自らに格納・保持されている変換に必要な情報を出力する機能を備えている。
【００３１】
承認履歴データベース１０３は、共通フォーマットに統一された承認情報を格納する部分である。
【００３２】
検索・閲覧プログラム１０４は、共通フォーマットに統一された変換後の承認情報を承認履歴データベース１０３の中より検索する機能及び発見した承認情報を、表示装置１０５に受け渡す機能を有する。
【００３３】
表示装置１０５は、承認履歴の検索結果を表示する部分である。検索・閲覧プログラム１０４より前記共通フォーマットに統一された変換後の承認情報を受け取り、外部へ前記変換後の承認情報を出力する機能を有する。
【００３４】
前記、各コンピュータシステムは、入力装置２５１又は入力装置３５１を備え、伝票による取引を行い管理するためのコンピュータシステムである。
【００３５】
各コンピュータシステムは入力装置２５１又は入力装置３５１から承認情報と取引伝票の識別情報を受け取り、該情報を汎用入力プログラム１０１へ引き渡す機能を有している。
【００３６】
（実施形態の動作の説明）
本実施形態の動作について、以下図面を用いて説明する。
【００３７】
始めに承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースを構築する動作について以下説明する。なお下記のデータベース構築のための各手順については、図５でフローチャートとして示している。
【００３８】
まず、業務取引を管理する各コンピュータシステム（ここでは、第一のコンピュータシステム２０１を例に以下説明する）の入力装置に承認のために情報が入力される。
【００３９】
前記取引の入力装置に承認のために情報が入力される際に、同時に承認内容の情報と取引伝票の識別情報が汎用入力プログラム１０１へファイルとして送信される（Ｓ１０１）。
【００４０】
なお、前記取引伝票の識別情報としては、取引伝票の通し番号や、承認申請の日時、が例として挙げられる。ここで、前記各項目はあくまで例示であり、これら全ての入力を必ずしも必要とするものではない。また前記例示した項目以外の項目を入力必要項目とするようにしてもよい。
【００４１】
次に、汎用入力プログラム１０１は前記承認内容の情報と取引伝票の識別情報をファイル転送により受け取る。また、この際に前記受け取った情報を個々のものとして識別するために、新たな伝票番号を識別符号として作成する。
【００４２】
そして、前記受け取った情報に前記識別符号を付加する（以下、当該付加した識別符号を原始伝票番号という）（Ｓ２０１）。
【００４３】
ここで、前記受け取った情報は各コンピュータシステムからそれぞれのデータフォーマットやコード体系で送られてきたものである。各コンピュータシステムの相違から、データフォーマットやコード体系は統一されておらず、発信元のコンピュータシステムごとに異なったフォーマットやコード体系となっている。
【００４４】
すなわち、第一のコンピュータシステム２０１から送られてきた情報は該第一のコンピュータシステム２０１が採用しているフォーマットやコード体系のままであり、他方、第二のコンピュータシステム３０１から送られてきた情報は該第二のコンピュータシステム３０１が採用しているフォーマットやコード体系のままである。
【００４５】
そのため、このままでは共通のデータベースで一元管理することができない。そこで汎用入力プログラム１０１はフォーマットやコード体系を統一する必要がある。
【００４６】
この点、汎用入力プログラム１０１は、まず変換定義データベース１０２に保持されているフォーマットやコード体系の変換定義の中から、前記の今回受け取った承認内容の情報及び取引伝票の識別情報に対応する定義を、検索する（Ｓ３０１）。
【００４７】
なお、ここで変換定義データベース１０２に前記今回受け取った承認内容の情報及び取引伝票の識別情報に対応する定義がなかった場合が考えられる。
【００４８】
その場合は、前記今回の情報の送信元であるコンピュータシステムに対応する定義を、汎用入力プログラム１０１が前記の情報の送信元であるコンピュータシステムに要求し、それにより取得した定義を汎用入力プログラム１０１が新たに変換定義データベース１０２に入力する。
【００４９】
これにより以降は、前記定義づけされていなかったコンピュータシステムからの前記情報転送にも対応することが可能となる（Ｓ３５１）。
【００５０】
次に、汎用入力プログラム１０１は前記検索を行い発見した今回の承認内容の情報と取引伝票の識別情報に合致する変換定義に基づいて前記情報を、統一された共通のフォーマットやコード体系に変換する（Ｓ４０１）。
【００５１】
ここで、変換定義データベース１０２の格納例を図２、図３へ示す。
【００５２】
図２では、システム種別ごとに採用されている文字コードの種別があらかじめ格納されており、定義づけされている状態を示している。
【００５３】
図２の例では販売管理システムが採用している文字コードはＳｈｉｆｔ−ＪＩＳコードであること及び購買管理システムが採用しているのは、ＥＵＣであることが示されている。よって汎用入力プログラム１０１は、前記定義されている前提にしたがって前記統一されたコード体系に変換することができる。
【００５４】
また、図３では図２と同様にシステム種別ごとに区分されている。ここで、例えば販売管理システムに所属している承認をした者がユーザＡであるとの情報が第一のコンピュータシステム２０１より汎用入力プログラム１０１に送られてきた場合を考える。
【００５５】
ここで、販売管理システムでは、当該部署の業務内容に適しているとして、承認を出す各社員は社員名が特定されないように、ユーザＡ、ユーザＢ、といった名称で管理されているとする。もっとも、前記共通のフォーマットでは、社員名で統一すべき旨が定められているとする。
【００５６】
この場合、汎用入力プログラム１０１は変換定義データベース１０２を検索し、図３の２列目を検出する。ここには、販売管理システムに所属している承認をした者ユーザＡとは、「日電太郎」を指す旨が定義されている。
【００５７】
よって、汎用入力プログラム１０１は前記定義に基づき「ユーザＡ」を共通フォーマットである社員名「日電太郎」へと変換することが可能となる。
【００５８】
次に、図６を参照すると汎用入力プログラム１０１は前記統一されたフォーマットやコード体系に変換された情報の取引伝票の識別符号（前記原始伝票番号）を確認し、その番号順に承認履歴データベース１０３へ格納する（Ｓ５０１）。
【００５９】
なお、承認履歴データベース１０３の格納例を図４で示す。前記図では前記原始伝票番号順に、前記変換された情報が格納されている状態を示している。
【００６０】
その後も、各コンピュータシステムから承認情報が転送されるたびに上記（Ｓ１０１）、（Ｓ２０１）、（Ｓ３０１）、（Ｓ３５１）、（Ｓ４０１）及び（Ｓ５０１）を繰り返す。
【００６１】
前記反復により、各コンピュータシステムから転送された承認情報に基づく前記承認内容の情報と取引伝票の識別情報は、フォーマットやコード体系が統一された状態で順次蓄積されていく。
【００６２】
更に、前記蓄積された情報は、前記原始伝票番号で管理される。これにより、承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースが構築されることとなる。
【００６３】
次に、会計監査や、業務監査、または定期的・日常的な経費の計上などの場面において前記データベースを利用する手順について説明する。なお下記のデータベース利用手順については、図６でフローチャートとして示している。
【００６４】
まず、検索・閲覧プログラム１０４が承認履歴データベース１０３を参照し、承認履歴データベース１０３から承認履歴情報を検索する（Ｓ６０１）。ここで、前記検索は、前記の原始伝票番号に基づいて行うことも可能である。
【００６５】
また、前記原始伝票番号に基づいて行う方法以外にも、他の項目を検索項目として検索することも可能である。
【００６６】
例えば、前記の各項目取引を、承認を行ったシステムの種別、承認日時、承認者、承認者所属を検索項目とし、検索するようにしてもよい。
【００６７】
この検索項目の変更をおこなうことより、ある特定の承認者の承認した伝票情報のみを抽出したり、ある期間に承認された取引伝票のみを抽出したりといった観点から承認履歴情報を統合参照することも可能となる。
【００６８】
更に、伝票の承認の際に会計伝票番号を割り振っているのであれば、前記会計伝票番号に基づいて検索するようにしてもよい。
【００６９】
以上より検索・閲覧プログラム１０４は、前記検索により得られた承認履歴情報を表示装置１０５に表示する（Ｓ７０１）。
【００７０】
なお、検索結果が充分では無い場合は、検索・閲覧プログラム１０４が前記に例示したような、他の項目を検索項目として改めて設定し、再度検索すればよい（Ｓ８０１）。これにより、承認履歴情報を、検索要求が充足するまで簡便に統合参照することができる。
【００７１】
（実施形態の効果の説明）
本発明より得られる効果は以下のものである。
【００７２】
まず、接続されているすべてのコンピュータシステムとやりとりを行うことで、発生した承認履歴情報を統合して管理することができるという効果が得られる。承認履歴情報を共通のデータベースで一元保持するためである。
【００７３】
これにより、統一すべき共通フォーマットを変更する場合も、各コンピュータシステムの設定を変えることなく変更することが可能となる。例えば、あるシステムにおける「ユーザＡ」が、今後、別の者に変更される場合であっても、共通の変換定義データベースの定義を変更するだけで足りることとなる。
【００７４】
また、事後的に以前の定義情報が誤っていたことが発覚し、承認履歴情報を訂正しなくてはならないような場合であっても承認履歴データベースに保持されている情報のみを訂正すればよいという効果が得られる。
【００７５】
更に、承認履歴情報を統合参照することができるという効果も得られる。承認履歴情報を共通の統合したデータベースから参照するためである。これにより各コンピュータシステムが相互に直接ネットワークとして接続されていない場合であっても、そのような直接ネットワークとして接続されていないコンピュータシステムの承認履歴情報も含めて、全ての承認履歴情報を統合参照することができるという効果が得られる。
【００７６】
次に、各コンピュータシステムの差異の吸収が可能となるという効果が得られる。ここで、前記差異とは各コンピュータシステムでのフォーマットやコード体系の違いのことである。前述のように共通の変換定義に基づいて共通のフォーマットやコード体系に変換を行うからである。
【００７７】
加えて各コンピュータシステムがシステムごとに個別にデータ変換プログラムや、変換定義を保持するデータベース、承認履歴を保持するデータベースといった機能や装置を実装する必要がないという効果もある。
【００７８】
前述のようにデータ変換プログラムや、変換定義を保持するデータベース、承認履歴を保持するデータベースといった機能や装置を各コンピュータシステムで共有することができるためである。
【００７９】
これにより、各コンピュータシステムは、自己のコンピュータシステムにおいて起動する入力装置のみを用意すればよいこととなる。
【産業上の利用可能性】
【００８０】
本発明にかかる履歴情報の一括管理を行うコンピュータ装置、そのプログラム及びその方法は、承認伝票のデータフォーマットやコード体系などが各コンピュータシステムにより差異がある場合であっても、標準化されたフォーマットやコード体系に変換し各コンピュータシステムの情報を統合管理することができるものとして有用である。
【図面の簡単な説明】
【００８１】
【図１】本発明の基本的構成を表すブロック図である。
【図２】変換定義データベースにおける、承認履歴情報の文字コードに関する格納例を示す図である。
【図３】変換定義データベースにおける、承認履歴情報の項目変換に関する格納例を示す図である。
【図４】承認履歴データベースにおける、承認履歴情報の格納例を示す図である。
【図５】承認履歴情報を一元保持するための、各コンピュータシステム共通のデータベースの構築するための動作について示したフローチャートである。
【図６】データベースを利用し承認履歴を照会する手順について示したフローチャートである。
【符号の説明】
【００８２】
１０１ 汎用入力プログラム
１０２ 変換定義データベース
１０３ 承認履歴データベース
１０４ 検索・閲覧プログラム
１０５ 表示装置
２０１ 第一のコンピュータシステム
３０１ 第二のコンピュータシステム
【特許請求の範囲】
【請求項１】
承認履歴管理をする複数システムの承認履歴統合管理実現装置であって、
前記複数システムより承認情報を取得する手段と、
前記複数システムのそれぞれに対応する変換定義を保持する手段と、
前記取得した承認情報を前記保持する変換定義情報に基づき変換する手段と、
前記変換した情報を承認履歴情報として格納し保持する手段と、
を備えることを特徴とする管理実現装置。
【請求項２】
請求項１に記載の管理実現装置であって、
前記格納し保持した承認履歴情報を項目ごとに管理する手段と、
閲覧を要求された項目について前記承認履歴情報を検索する手段と、
前記検索により取得した情報を提示する手段と、
を更に備えることを特徴とする管理実現装置。
【請求項３】
請求項２に記載の管理実現装置であって、
前記複数システムより取得した承認情報に識別符号を付加する手段を更に備え、
前記承認履歴情報を管理する手段及び前記検索する手段は前記識別符号を用いて行うことを特徴とする管理実現装置。
【請求項４】
請求項１乃至３の何れか１項に記載の管理実現装置であって、
前記保持している変換定義情報は、事後的に変更可能なことを特徴とする管理実現装置。
【請求項５】
請求項１乃至４の何れか１項に記載の管理実現装置であって、
前記承認履歴情報を複数のコンピュータシステムに共有されて利用されることを特徴とする管理実現装置。
【請求項６】
承認履歴管理をする複数システムの承認履歴統合管理実現方法であって、
前記複数システムより承認情報を取得するステップと、
前記複数システムのそれぞれに対応する変換定義を保持するステップと、
前記取得した承認情報を前記保持する変換定義情報に基づき変換するステップと、
前記変換した情報を承認履歴情報として格納し保持するステップと、
を備えることを特徴とする管理実現方法。
【請求項７】
請求項６に記載の管理実現方法であって、
前記格納し保持した承認履歴情報を項目ごとに管理するステップと、
閲覧を要求された項目について前記承認履歴情報を検索するステップと、
前記検索により取得した情報を提示するステップと、
を更に備えることを特徴とする管理実現方法。
【請求項８】
請求項７に記載の管理実現方法であって、
前記複数システムより取得した承認情報に識別符号を付加するステップを更に備え、
前記承認履歴情報を管理するステップ及び前記検索するステップは前記識別符号を用いて行うことを特徴とする管理実現方法。
【請求項９】
請求項６乃至８の何れか１項に記載の管理実現方法であって、
前記保持している変換定義情報は、事後的に変更可能なことを特徴とする管理実現方法。
【請求項１０】
請求項６乃至９の何れか１項に記載の管理実現方法であって、
前記承認履歴情報を複数のコンピュータシステムに共有されて利用されることを特徴とする管理実現方法。
【請求項１１】
コンピュータに請求項６から１０の何れか１項に記載の管理実現方法を実行させることを特徴とするプログラム。
【請求項１】
承認履歴管理をする複数システムの承認履歴統合管理実現装置であって、
前記複数システムより承認情報を取得する手段と、
前記複数システムのそれぞれに対応する変換定義を保持する手段と、
前記取得した承認情報を前記保持する変換定義情報に基づき変換する手段と、
前記変換した情報を承認履歴情報として格納し保持する手段と、
を備えることを特徴とする管理実現装置。
【請求項２】
請求項１に記載の管理実現装置であって、
前記格納し保持した承認履歴情報を項目ごとに管理する手段と、
閲覧を要求された項目について前記承認履歴情報を検索する手段と、
前記検索により取得した情報を提示する手段と、
を更に備えることを特徴とする管理実現装置。
【請求項３】
請求項２に記載の管理実現装置であって、
前記複数システムより取得した承認情報に識別符号を付加する手段を更に備え、
前記承認履歴情報を管理する手段及び前記検索する手段は前記識別符号を用いて行うことを特徴とする管理実現装置。
【請求項４】
請求項１乃至３の何れか１項に記載の管理実現装置であって、
前記保持している変換定義情報は、事後的に変更可能なことを特徴とする管理実現装置。
【請求項５】
請求項１乃至４の何れか１項に記載の管理実現装置であって、
前記承認履歴情報を複数のコンピュータシステムに共有されて利用されることを特徴とする管理実現装置。
【請求項６】
承認履歴管理をする複数システムの承認履歴統合管理実現方法であって、
前記複数システムより承認情報を取得するステップと、
前記複数システムのそれぞれに対応する変換定義を保持するステップと、
前記取得した承認情報を前記保持する変換定義情報に基づき変換するステップと、
前記変換した情報を承認履歴情報として格納し保持するステップと、
を備えることを特徴とする管理実現方法。
【請求項７】
請求項６に記載の管理実現方法であって、
前記格納し保持した承認履歴情報を項目ごとに管理するステップと、
閲覧を要求された項目について前記承認履歴情報を検索するステップと、
前記検索により取得した情報を提示するステップと、
を更に備えることを特徴とする管理実現方法。
【請求項８】
請求項７に記載の管理実現方法であって、
前記複数システムより取得した承認情報に識別符号を付加するステップを更に備え、
前記承認履歴情報を管理するステップ及び前記検索するステップは前記識別符号を用いて行うことを特徴とする管理実現方法。
【請求項９】
請求項６乃至８の何れか１項に記載の管理実現方法であって、
前記保持している変換定義情報は、事後的に変更可能なことを特徴とする管理実現方法。
【請求項１０】
請求項６乃至９の何れか１項に記載の管理実現方法であって、
前記承認履歴情報を複数のコンピュータシステムに共有されて利用されることを特徴とする管理実現方法。
【請求項１１】
コンピュータに請求項６から１０の何れか１項に記載の管理実現方法を実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−１９１８６３（Ｐ２００８−１９１８６３Ａ）
【公開日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願番号】特願２００７−２４５２６（Ｐ２００７−２４５２６）
【出願日】平成１９年２月２日（２００７．２．２）
【出願人】（０００２１３３０１）中部日本電気ソフトウェア株式会社 (56)
【公開日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願日】平成１９年２月２日（２００７．２．２）
【出願人】（０００２１３３０１）中部日本電気ソフトウェア株式会社 (56)
[ Back to top ]