JP2015130159A - 電子帳票サーバ、電子帳票サーバの動作方法、電子帳票サーバの動作プログラム、電子帳票サーバの動作プログラムを記録した記録媒体 - Google Patents

Abstract

【課題】電子請求書発行の事務処理負担を減少させる電子帳票サーバを提供する。【解決手段】帳票に含まれる取引データとレイアウト情報を含む電子帳票を発行者に関連付けて受信する電子帳票受信部０１０１と、帳票上でのデータの配置を示す情報を保持する帳票上データ属性情報保持部０１０２と、受信した電子帳票に含まれる取引データのレイアウト情報と帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて保持する属性付取引データ保持部０１０３と、共通様式の帳票フォーマットを保持する共通出力フォーマット保持部０１０４と、複数の発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のフォーマットを用いて出力する共通出力部０１０５と、を有する。【選択図】図１

Description

本発明は、電子帳票サーバやその動作方法に関する。

従来から、取引相手に対して発行する請求書等の帳票を紙出力ではなく電子化して発行する技術が知られている。この技術を用いることにより、日々の取引で大量に生じうる帳票を効率的に管理することができるし、送付にかかる時間面費用面でのコスト削減、ひいては紙資源の節約などの効果が期待されている。

ここでいう帳票の電子化とは一般に、計算機に入力された帳票発行に必要な種々の情報を紙に印字出力するのではなく、社会通念上帳票として利用可能な様式からなる電子データとしてネットワークを介して帳票発行先が把握可能な状態に出力することをさす。

なお、帳票発行業務のコスト削減の観点から電子帳票の生成や発行等の業務を受託するビジネスが知られている。特許文献１や特許文献２にはいずれも、帳票発行元からデータを受信して電子帳票を生成し、帳票発行先に対して送信する電子帳票発行受託業務に関する技術が記載されている。

特開２００４−７３８７号公報 特開２０１２−２２４１７号公報

しかしながら、従来からある電子帳票発行技術では、電子帳票発行受託者と帳票発行元のコスト削減が図られているとは言い難かった。特許文献１記載の技術においても特許文献２記載の技術においても帳票発行元はテキスト形式、ＣＳＶ形式、エクセル（登録商標）形式等所定の形式にデータを整えて電子帳票発行受託業者に送付しなければならないという煩雑な事務処理が生じたからである。

このように従来技術においては、電子帳票発行受託者は多数の依頼元（電子帳票発行元）のデータを扱わなければならないために電子帳票発行受託者での管理の便宜のために依頼元に対して電子帳票データの加工処理といった新たな事務処理の負担を課すことになっていた。そのため、事務処理の軽減を求めている依頼元（帳票発行元）に対して、コストを削減できる真に好適なシステムを提供できているとは言い難かった。

以上のような課題を解決するために、本発明は、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信部と、帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を保持する帳票上データ属性情報保持部と、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて保持する属性付取引データ保持部と、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部と、前記属性付取引データ保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する共通出力部と、を有する電子帳票サーバなどを提案する。

主に上記のような構成をとる本発明によって、帳票発行元自身が従来から発行していた帳票作成用のデータに特段手を加える必要なく、また帳票発行受託者が新たな負荷を負うこともなく効率的な電子帳票生成・発行処理を実現することができる。

実施形態１の電子帳票サーバの機能ブロックの一例を示す図 電子帳票を構成する帳票である請求書の一例を示す図 図２−ａで示した電子帳票のレイアウト情報を説明するための概念図 帳票上データ属性情報保持部における帳票上データ属性情報の保持の一例を示す図 属性付取引データ保持の一例を示す図 実施形態１の電子帳票サーバの機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図 実施形態１の電子帳票サーバの処理の一例を示す図 実施形態２の電子帳票サーバの機能ブロックの一例を示す図 実施形態２の電子帳票サーバの処理の一例を示す図 実施形態３の電子帳票サーバの機能ブロックの一例を示す図 実施形態３の電子帳票サーバの処理の一例を示す図 実施形態４の電子帳票サーバの機能ブロックの一例を示す図 実施形態４の電子帳票サーバの処理の一例を示す図 実施形態５の電子帳票サーバの機能ブロックの一例を示す図 実施形態５の電子帳票サーバの処理の一例を示す図 実施形態１の電子帳票サーバを用いて共通帳票を出力する一態様を説明するための概念図 実施形態１の電子帳票サーバを用いて共通帳票を出力する別の態様を説明するための概念図 実施形態１の電子帳票サーバを用いて共通帳票を出力する別の態様を説明するための概念図 実施形態１の電子帳票サーバを用いて取引データを出力する一態様を説明するための概念図 実施形態２の電子帳票サーバの機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図

以下、本発明の各実施形態について図面と共に説明する。実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態１は、主に請求項１、７、８、９などに対応する。実施形態２は、主に請求項２などに対応する。実施形態３は、主に請求項３、４などに対応する。実施形態４は、主に請求項５などに対応する。実施形態５は、主に請求項６などに対応する。なお、本発明はこれらの実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。

＜＜実施形態１＞＞

＜概要＞
本実施形態の電子帳票サーバは、取引データとレイアウト情報を含む電子帳票を発行者に関連付けて受信する一方、該当する発行者の該当する帳票上での配置とその位置に配置されるべき取引データの属性情報（帳票上データ属性情報）とを関連付けて予め保持しておく。そして受信した電子帳票に含まれる取引データのレイアウト情報とそのレイアウトにおける前記予め保持されている配置に関連付けられている帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データと帳票上データ属性情報とを関連付けて取得する。
そして、電子帳票サーバの共通様式のフォーマットを保持するとともに、前記帳票上データ属性情報と関連付けられた取引データを取引データのデータ属性に応じて共通のフォーマットを用いて出力することを特徴として備えている。

＜機能的構成＞
図１は、本実施形態の電子帳票サーバの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「電子帳票サーバ」０１００は、「電子帳票受信部」０１０１と、「帳票上データ属性情報保持部」０１０２と、「属性付取引データ保持部」０１０３と、「共通出力フォーマット保持部」０１０４と、「共通出力部」０１０５と、を有する。

なお、以下に記載する電子帳票サーバの機能ブロックは、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵやメインメモリ、ＧＰＵ、画像メモリ、グラフィックボード、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤやＤＶＤなどの記憶媒体とそれらの媒体の読取ドライブなど）、情報入力に利用される入力デバイス、タッチパネル、プリンタ、バーコードリーダなどのスキャナ装置その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラムなどが挙げられる。そして、メインメモリ上に展開したプログラムに従ったＣＰＵの演算処理によって、入力デバイスやその他インターフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムを組み合わせて一のプログラムとして実現されても良い。さらにこのプログラムを記録した記録媒体としてもよい。

なお、本発明の電子帳票サーバは、一または複数の装置との組み合わせによりシステムとしても実現可能である。そして、このような装置の一部をソフトウェアとして構成することも可能である。さらに、そのようなソフトウェアが記録された記憶媒体も当然に本発明の技術的な範囲に含まれる（本実施形態に限らず、本明細書の全体を通じて同様である。）。

「電子帳票受信部」０１０１は、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信するように構成されている。具体的には、請求書をはじめ給与明細書や納品書、その他その名称を問わず社会通念上行われる取引において発行されうるあらゆる文書である帳票を電子帳票として受信することが可能であり、「電子帳票を帳票発行者に関連付けて受信する」とは例えば、帳票発行者ごとに帳票発行者ＩＤを付与し、電子帳票を当該帳票発行者ＩＤと紐づけて受信する。当該構成をとることにより、異なるレイアウトの電子帳票を帳票発行者ごとに管理把握することが可能になる。

ちなみに、ここでいう取引データとは、帳票の発行者（発行元）や発行先、請求金額、取引内容など帳票に表されるべき取引の性質や内容を表す文字・数字・記号等のテキストからなる一または複数のデータである。電子帳票は例えばＰＤＦファイル（登録商標）、ワードファイル（登録商標）、エクセルファイル（登録商標）などのファイルである。これらのファイルは電子帳票を印刷したり、パソコンの画面に表示させたりするために文字、記号などの情報、またそれらの文字等を表示するフォントの種類の情報、文字の大きさの情報、文字、記号等の配置の情報をファイルに格納している。

なお、帳票発行者は発行している帳票のレイアウトごとに把握識別されることが望ましい。すなわち、一の帳票発行者が複数の異なるレイアウトからなる帳票を発行するような場合には、帳票発行者は当該異なるレイアウトごとに別個に識別されうる。より具体的にいえば、一の帳票発行者が発行する帳票のレイアウトごとに異なる複数の帳票発行者ＩＤを有することがある。このような構成をとることにより、異なるレイアウトの帳票を発行している帳票発行者と関連付けられる各種データ（たとえば、後述する帳票上データ属性情報や属性付取引データ）を効率的に保持ないし管理することが可能になる。

ここでレイアウト情報について説明する。電子帳票は通常、例えばワードやエクセル（登録商標）、ｐｄｆ形式など特定の形式にて生成される。これらの形式にて生成された電子帳票は、ネットワークを介して電子帳票受信部にて受信される。なおこのとき、電子帳票サーバにて取引データの内容を把握するために特定の性質ないし内容の取引データが帳票上どの位置に配置されるべきかを示す情報が必要となる。そしてこの取引データの配置位置を特定するための情報がレイアウト情報である。このように、レイアウト情報を用いることが前提とされている以上、本実施形態の電子帳票サーバの利用者は、少なくとも電子帳票とする取引データのレイアウトは変更せず、使用し続けることが要求される。

一般に、電子帳票がワード形式やエクセル（登録商標）形式にて構成されている場合はもちろん、ｐｄｆ形式においても、取引データを構成する個々のテキストごとの配置位置の情報を具えている。この場合電子帳票受信部では、当該配置位置の情報をレイアウト情報として受信する。これに対し、テキストを画像として構成する場合のように電子帳票が取引データを構成するテキストの配置情報がなく生成されている場合には、光学文字認識（ＯＣＲ、Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅｃｏｇｎｉｔｉｏｎ）等の処理によって画像で受信した電子帳票に座標を割り当ててレイアウト情報（配置）として利用する。

なお、レイアウト情報は後に説明する帳票上データ属性情報保持部にて保持されている帳票上データ属性情報、これは帳票上のレイアウト（取引データの配置）と、そこに配置されるべき取引データの属性（帳票上取引データ属性情報）を用いて、受信した電子帳票上に記録されているテキスト、数字、記号などの情報とその情報の属性（帳票上取引データ属性情報）とを関連付けるために用いられる。これについては後述する。

なおここで、図２―ａを用いて電子帳票について説明する。同図は帳票である請求書の一例であり、「株式会社カワニシ」が「山北商事株式会社」に対して１１万４０００円を請求する旨が記載されている。同請求書には取引データとして請求書発行者（株式会社カワニシ）や発行先（山北商事株式会社）、請求金額（￥１１７，６００）のほか、タイトル（請求書）、発行日（２０１４年６月２８日）、請求番号（０６５４３２１ＰＡＴ）、顧客ＩＤ（０１０２２３）、品名（情報提供サービス）、数量（３）、単価（￥４０，０００）、小計（￥１２０，０００）、税額（￥９，６００）、合計金額（￥１２９，６００）、源泉徴収額（￥１２，０００）、振込金額（￥１１７，６００）、振込先口座等の情報がそれぞれ所定の位置に記載されている。

続けて図２−ｂを示す。同図は図２−ａで示した電子帳票のレイアウト情報を説明するための概念図である。具体的にいうと、帳票の横軸方向左側から右側にかけて所定範囲ごとに「Ａ，Ｂ，Ｃ，Ｄ・・・」といった符号が割り当てられ、縦軸方向上側から下側にかけて所定範囲ごとに「１，２，３，４・・・」といった符号が割り当てられている。これらの符号を用いることにより、帳票上もっとも左上に位置する範囲ないし領域は「（Ａ，１）」として特定することが可能である。なお、上記のように特定された領域の情報は、前記位置ＩＤとして採用することが可能である。

なお、一つの領域には原則として一つの文字や記号が配置されるが、一つの文字や記号が複数の領域にまたがって配置されるような場合には、当該複数の領域をまとめて特定してレイアウト情報とする。一例をあげると、同図最上部に示された「請求書」とのテキストを構成する各文字は、いずれも複数の領域にまたがって配置されており、この場合「請」という文字についてのレイアウト情報は「（Ｑ，Ｒ，４，５）」といったように特定される。すなわち、同図の帳票に含まれる取引データである文字「請」に対応するレイアウト情報は（Ｑ，Ｒ，４，５）である。

「帳票上データ属性情報保持部」０１０２は、帳票発行者毎に帳票上配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を保持するように構成される。データ属性は同一の帳票発行者の同一の種類の帳票では同一の位置で常に同一のデータ属性となる。配置されるべき位置の情報をどのように保持するかは適宜設定可能であるが、ここでは前記レイアウト情報と同様に帳票の縦軸方向と横軸方向にそれぞれ所定単位ごとに設けられる符号を用いて帳票上での配置位置を特定することが考えられる。

ここで図３を示す。同図は帳票上データ属性情報保持部における帳票上データ属性情報保持の一例を示す図である。同図に示されているように、帳票発行先（請求先）や顧客ＩＤ、発行日などのデータ属性の情報の帳票上での配置位置がそれぞれレイアウト情報を用いて特定され、帳票発行者を識別するための帳票発行者ＩＤごとに保持されている。例えば、帳票発行者ＩＤが「Ａ０１０２３」である帳票発行者（図２−ａの例に倣い株式会社カワニシとする、以下同じ）の発行する帳票の場合、請求先は「（Ｃ−Ｍ，１０，１１）」の領域、すなわち、横軸Ｃ列からＭ列にかけて縦軸１０段目および１１段目にて特定される領域に配置される。これに対し帳票発行者ＩＤが「Ａ０１０２４」である帳票発行者の発行する帳票において請求先はそれよりもやや右下側である「（Ｆ−Ｍ，１３，１４）」の領域に配置される、といった具合である。ちなみに、同図中「（ｎ／ａ）」と記載されているのは、当該データ属性を備える情報が帳票上記載されないことを意味している。なお、ここではわかりやすくするために図に表して示したが、受信した電子帳票のデータ中には例えば（山：Ｃ、１０、１１）、（北：Ｄ、１０、１１）、（商：Ｅ、１０、１１）、（事：Ｆ、１０、１１）、（株：Ｇ、１０、１１）、（式：Ｈ、１０、１１）・・・のように記録されている。

帳票上データ属性情報は基本的には各帳票発行者により送信される。すなわち、電子帳票サーバは、帳票発行者の管理する端末から、当該帳票発行者の発行する帳票における帳票上データ属性情報の入力を受付け、当該受付けた帳票上データ属性情報を帳票発行者ＩＤと関連づけて保持する。

「属性付取引データ保持部」０１０３は、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて保持するように構成される。レイアウト情報と帳票上データ属性情報とを用いて取引データとデータ属性とを関連付ける処理の一例としては、帳票上データ属性情報により特定のデータ属性と対応した範囲ないし領域に含まれる範囲ないし領域をレイアウト情報として備えているテキストについて、当該データ属性と関連付けるべき取引データを構成するテキストであると判断し関連付けることが考えられる。このように、テキストの配置位置の情報を用いる当該構成をとれば、テキストの表示形式にとらわれることなく、またテキストの内容を判断する処理を要することなく簡易に取引データとデータ属性との関連付けを行うことができる。

なお、取引データとデータ属性との関連付けは、電子帳票受信部にて電子帳票を受信した後速やかに行われることが望ましいが、例えば電子帳票の請求先からの出力要求があった場合に行ってもよい。当該構成をとることにより、取引データの修正や電子帳票自体の差替えなどデータ属性と関連付けられるべき取引データの内容に変更が生じた場合であっても、変更の都度前記関連付けの変更処理を行う煩雑さを回避することができる。例えば消費税が値上げされることが予めわかっていたが、その値上げ前に受信した請求書である電子帳票を請求先が出力要求することなく消費税の値上げがされた場合には消費税等の修正を既に受信している電子帳票に対して帳票発行者がすることが可能であれば便利である。また既に受信している電子帳票をキャンセルして新たな請求書である電子帳票に代えることができれば便利である。

ここで図４を用いて属性付取引データ保持部におけるデータ保持の具体的な一例を説明する。同図では、帳票発行者ＩＤが「Ａ０１０２３」である帳票発行者、すなわち株式会社カワニシが作成した帳票である複数の請求書に含まれる取引データと、同社と関連付けられているデータ属性とが関連付けられ保持されている様子が示されている。同図のうち（ａ）は図２−ｂで示した図と同じ図であり、（ｂ）は図３で示した株式会社カワニシと関連付けられた帳票のレイアウト（配置）に対応した帳票上データ属性情報の図である。そして（ｃ）は、（ａ）の電子帳票を受信し、そのレイアウト情報に基づいて予め保持していた（ｂ）の帳票上データ属性情報に基づいて取引データとデータ属性との関連付けを行った様子を示している。
同図に示されているように、例えば、同図（ａ）中横軸方向Ｃ列からＭ列にかけての領域０４１１かつ縦軸方向１０段目および１１段目の領域０４１２、つまり（Ｃ−Ｍ，１０，１１）の領域をレイアウト情報として有するテキスト「山北商事株式会社」についてみると、同（ｂ）の領域０４２０にて示されているように、当該領域には「請求先」の情報が配置されているとの帳票上データ属性情報が保持されていることから、同（ｃ）中の領域０４３０において、取引データ「山北商事株式会社」とデータ属性「請求先」とを関連付けて保持する様子が示されている。

このように、帳票発行者と関連付けられた帳票上データ属性情報が予め保持されていることで、帳票発行者から電子帳票を受信する際に個々の取引データの意味内容を判断する処理を要さずにとデータ属性との関連付けを行うことが可能になる。

「共通出力フォーマット保持部」０１０４は、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持することを特徴とする。共通出力フォーマットは全ての利用者に対して唯一のフォーマットでもよいし、複数のフォーマットが選択的に共通に利用される形態であってもよい。また共通フォーマットは帳票の部分であってももちろんよい。帳票の部分が共通フォーマットであり、他の部分は非共通フォーマットでもよい。

例えば「送り状」「発注書」「受注書」「見積書」「請求書」「納品書」「戻入書」「届出書」「領収書」「クレーム書」「欠品届書」「数量不足通知書」「不良品通知書」など複数種類のフォーマットが準備されており、それぞれは必要に応じて選択されて共通に利用される形態であってもよい。またこれらの共通出力フォーマットは、本電子帳票サーバを利用する全ての帳票発行者がオリジナルで利用している帳票、すなわち、電子帳票受信部にて受信する全ての帳票に含まれるデータ属性を共通出力フォーマットで記述可能でなければならない。例えば電子帳票受信部で受信する電子帳票には「原産地」というデータ属性があるにも関わらず共通出力フォーマットにかかるデータ属性を記述する欄が備えられていないということは許容されない。一般的に共通出力フォーマットに少なくとも含まれなければならないデータ属性は「帳票発行者名」「帳票発行者特定情報」「帳票受信者名」「帳票受信者特定情報」「帳票の種類」「発行年月日」「帳票内容処理期限」「取扱対象特定情報」「数量」「単価」「合計金額」「税額」「値引き額」「振込先」「帳票識別情報」「連絡先情報」「担当者名」「案件識別情報」「手数料」「印紙額」などであり、さらに「原材料情報」「原産地」「荷積み地」「経由地」「荷降ろし地」「輸送方法」「決済方法」「保険種類」「取扱注意情報」「その他類型化できない情報」などである。

「共通出力部」０１０５は、属性付取引データ保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力するように構成される。当該構成をとることにより、異なるレイアウトの取引データからなる複数の電子帳票の発送先となっている利用者に対しても、これらの複数の電子帳票をすべて同じ共通出力フォーマットを用いて同一のレイアウトにて出力し、その管理の手間を大幅に抑制することが可能になる。

ここで図１５−ａないしｃを用いて共通出力部の機能について説明する。同各図はいずれも、本実施形態の電子帳票サーバを用いて共通帳票を出力する一態様を説明するための概念図である。各図左側にはそれぞれ、山北商事株式会社に向けて異なる発行者の発行した電子帳票の取引データが示されており、各図右側には、当該取引データを共通出力フォーマットを用いて出力する様子が示されている。

なお、共通出力部における取引データの出力態様の一例としては、紙出力するか、電子出力するかが考えられ、より具体的には、プリントアウトやＦＡＸ送信の形式にて出力したり、ｐｄｆファイルなど所定のファイル形式を生成する方法によったり、電子メールその他の通信手段を用いる形式であったりすることが考えられる。これらの方法を組み合わせて出力する態様（例えば、取引データをｐｄｆ化して電子メール添付にて送信する態様）も当然に共通出力部における取引データ出力の一態様に含まれる。ｐｄｆファイル化などの出力態様をも許容する構成を採用することにより、利用者の取引データ改変等の懸念を低減させることができる。

図１５−ａには、オオモリ株式会社から平成２７年度の年会費に相当する金額の請求を受けていることを示す内容の電子帳票の一例が示されている。すなわち、請求書の中央やや上部分に請求先（山北商事株式会社）が記載され、中央には請求額が内税方式にて記載されており、そのすぐ下には摘要（年会費として）が記載されている。そのやや下には支払期日に関する特記事項が記載され、その左下には振込先口座が、右下には当該電子帳票の発行主体を特定する為の情報（発行元名称、所在地、電話番号、ＦＡＸ番号）がそれぞれ記載されている。なお、発行主体を特定する為の情報とあわせて、発行元の担当者とその連絡先に関する記載もある。
図１５−ｂには、関谷加工から複数種類の部品・製品の代金の請求を受けていることを示す内容の電子帳票の一例が示されている。すなわち、請求書の左上部分にタイトルを配置し、その右横に請求先名（山北商事株式会社）が記載されている。タイトルのすぐ下には請求書の発行ＩＤが記載され、請求先名のすぐ下には請求者特定のためのＩＤが記載されている。中央には請求者が販売した製品の内訳と販売個数、各製品の単価、売価が記載されるとともに、売価の下に小計額が記載されている。なお、この取引においては値引きが生じており、小計額の下に値引き額の記載があり、消費税、合計額、源泉徴収額、支払額の記載が下に続く。そのやや下には支払期日に関する特記事項が記載され、最下部中央には当該電子帳票の発行主体を特定する為の情報（発行元名称、所在地、電話番号、ＦＡＸ番号）がそれぞれ記載されている。
そして図１５−ｃには、株式会社カワニシからサービス利用代金の請求を受けていることを示す内容の電子帳票の一例が示されている。すなわち、請求書の左上最上部に当該帳票の発行ＩＤが記載され、その下中央部にタイトル（請求書）が記載されている。真下には請求日の記載があり、その左下にはその右横に請求先名（山北商事株式会社）が所在地とともに記載されている。請求先名のすぐ斜め右下には当該電子帳票の発行主体を特定する為の情報（発行元名称、所在地、電話番号、ＦＡＸ番号）が記載され、その下中央部には請求期間と請求金額小計額が左右に分かれて記載されている。そのさらに下をみると上記小計額の内訳が記載されており、更に下に源泉徴収額を勘案した振込金額が記載されている。そして最下部中央に振込先口座が記載されている。

同各図において採用されている共通出力フォーマットは、いずれも図２−ａで示した請求書のフォーマットと同じものであり、特に図１５−ｃの（イ）で示されている取引データは、既に説明に用いた図２−ａ記載の取引データの内容と同一である。このような処理を行う本実施形態の電子帳票サーバを用いることにより、利用者に対して帳票発行者ごとに異なるフォーマットにて電子帳票が作成されていても、利用者はそれらの電子帳票を全て同一のフォーマットにて確認することができ、便宜な帳票管理を行うことが可能になる。

なお、共通出力に先立ち、用いるべき共通出力フォーマットがデータ属性に応じたレイアウトに対応するかどうかを判断し対応する共通出力フォーマットを選択するための機能を備えることも考えられる。例えば、データ属性に「請求先」との情報が含まれると判断される場合には、複数の共通出力フォーマットのなかから請求書に対応するフォーマットを共通出力フォーマットとして選択し帳票を出力する、といった具合である。他にも例えば、「入金日」とのデータ属性が含まれると判断される場合には、領収書に対応するフォーマットを共通出力フォーマットとして選択したり、「売上」とのデータ属性が含まれると判断される場合には、売上伝票に対応するフォーマットを選択したりすることなどが考えられる。当該構成をとることにより、用途の異なる複数の共通出力フォーマットを簡易に当該用途ごとに提供することが可能になる。

なおここでいう出力先としては、電子帳票の発行先が管理する端末装置であることが考えられる。つまり帳票が請求書であれば請求先、領収書であれば支払元の管理する端末装置ということになる。発行先は自身の管理する端末装置にて当該取引データを受信してディスプレイに表示するなどにより、自身に対する帳票の送付の事実やその内容を、自身にとり好適なタイミングで把握することができる。のみならず、一又は複数の取引データが表示されていれば、当該表示のなかから一の取引データを選択し、例えば電子決済を始め決済のための処理を行うように構成されていてもよい。ここでディスプレイに対し取引データを出力する一例として図１６を示す。同図に示されているのは、図１５−ａないしｃを用いて説明した取引が一覧形式にて把握可能に構成された表示画面である。このように、共通出力部においては共通のレイアウトに従って出力がなされていればよく、必ずしも帳票の形式にて出力されなくてもよい。利用者は当該表示を見ながら、任意の取引（例えば帳票ＩＤが０６５４３２１ＰＡＴの取引）を選択し、当該取引における決済処理を行う、といったことが可能である。当該構成を採用することによって、取引データの管理のみならず、決済までをも円滑に行い、利用者における取引（特に決済）の利便性・迅速性をより確保することが可能になる。
なおこのとき、前記共通帳票を出力した旨の情報を、予め登録されている当該出力先に対し、電子メールやＦＡＸ、音声自動通話等の方法により通知する構成をとることも考えられる。当該構成をとれば、通知を確認した出力先による共通帳票の受信漏れや確認ミスの危険を低減させることが可能になる。

＜具体的な構成＞
図５は、本実施形態の電子帳票サーバの機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図である。これらの図を利用して、それぞれのハードウェア構成部の働きについて説明する。電子帳票サーバは、各種演算処理を実行するための「ＣＰＵ」０５０１と、「記憶装置（記憶媒体）」０５０２と、「メインメモリ」０５０３と、「出力インターフェース」０５０４と、「入力インターフェース」０５０５と、「インターネット通信インターフェース」０５０６と、を備え、入出力インターフェースを介して、例えば「キーボード」０５０７や「ディスプレイ」０５０８と、また、インターネット通信インターフェースを介して帳票発行元の管理する端末である「発行元端末」０５８０や帳票発行先の管理する端末である「発行先端末」０５９０などの外部周辺装置と情報の送受信を行う。なお、記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０５０９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

（電子帳票受信部の具体的な処理）
ＣＰＵは、記憶装置から「電子帳票受信プログラム」０５１０をメインメモリに読み出して実行し、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信し、メインメモリの所定のアドレスに格納する。

（帳票上データ属性情報取得部の具体的な処理）
ＣＰＵは、記憶装置から「帳票上データ属性情報取得プログラム」０５２０をメインメモリに読み出して実行し、帳票時に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である「帳票上データ属性情報」０５５０を取得し、帳票発行者毎に付与された所定のアドレスに格納する。

（属性付取引データ取得部の具体的な処理）
ＣＰＵは、記憶装置から「属性付取引データ取得プログラム」０５３０をメインメモリに読み出して実行し、電子帳票受信プログラムの実行により得られた電子帳票に含まれる取引データの帳票上での「レイアウト情報」０５６０と、帳票上データ属性情報取得プログラムの実行により当該電子帳票発行者と関連付けられた「帳票上データ属性情報」０５５０とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付ける処理を行い、当該処理結果をメインメモリの所定のアドレスに格納する。

（共通出力部の具体的な処理）
ＣＰＵは、記憶装置から属性付取引データ取得プログラムの実行により得られた情報を読み出すとともに「共通出力プログラム」０５４０をメインメモリに読み出して実行し、複数の帳票発行者が発行する異なる種類の電子帳票上の「取引データ」０５７０をデータ属性に応じて共通出力フォーマットを用いて出力する処理を行う。

＜処理の流れ＞
図６は、本実施形態の電子帳票サーバにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０６０１では、帳票発行者毎に帳票上に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する（帳票上データ属性情報記録ステップ）。ステップＳ０６０２では、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する（電子帳票受信ステップ）。その後ステップＳ０６０３では、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録し（属性付取引データ記録ステップ）、ステップＳ０６０４では、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じた共通のレイアウトに出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する（共通出力ステップ）。
また、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信ステップと、帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する帳票上データ属性情報記録ステップと、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する属性付取引データ記録ステップと、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている共通出力フォーマットを用いて、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて出力する共通出力ステップと、を計算機に実行可能とした電子帳票サーバの動作プログラムでもよく、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信ステップと、帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する帳票上データ属性情報記録ステップと、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する属性付取引データ記録ステップと、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている共通出力フォーマットを用いて、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて出力する共通出力ステップと、を計算機に読取実行可能とした電子帳票サーバの動作プログラムを記録した記録媒体でもよい。

＜効果＞
以上の構成を有する本発明によって、帳票発行元自身が従来から発行していた帳票の形式に手を加える必要なく、効率的な電子帳票生成・発行処理を実現することができる。

＜＜実施形態２＞＞

＜概要＞
本実施形態の電子帳票サーバは、基本的に実施形態１の電子帳票サーバと同様であるが、受信した電子帳票である受信電子帳票を保持し、その保持されている受信電子帳票を出力する点をさらなる特徴とする。

＜機能的構成＞
図７は、本実施形態の電子帳票サーバの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「電子帳票サーバ」０７００は、「電子帳票受信部」０７０１と、「帳票上データ属性情報保持部」０７０２と、「属性付取引データ保持部」０７０３と、「共通出力フォーマット保持部」０７０４と、「共通出力部」０７０５と、「受信電子帳票保持部」０７０６および「受信電子帳票出力部」０７０７を有する。本実施形態の電子帳票サーバの基本的な構成は、実施形態１の電子帳票サーバと共通するため、以下では相違点である「受信電子帳票保持部」および「受信電子帳票出力部」の機能について説明する。

「受信電子帳票保持部」０７０６は、電子帳票受信部にて受信した電子帳票である受信電子帳票を保持するように構成されている。例えば、帳票発行者ごと、あるいは発行日時ごとであったり帳票発行先ごとであったりと、所定のグループごとに受信電子帳票を保持する構成が考えられる。当該構成をとることにより、受信後直ちに属性付取引データ保持部による処理を実行するのでなく、例えば特定の顧客に対して発行されるべき複数の取引データについて、まとめて属性付取引データ保持部による処理を実行し、まとめて共通出力部から出力するように構成することが可能になる。

「受信電子帳票出力部」０７０７は、保持されている受信電子帳票を出力するように構成されている。ここでいう出力先としては、実施形態１で説明した帳票発行先の端末装置である場合よりも、帳票発行元の端末装置やそれ以外の第三者の管理する端末装置などであることが考えられる。当該構成をとることにより、個別の利用者のニーズに応じ、共通出力フォーマットによらず発行者ごとのフォーマットにて帳票を出力することが可能になる。

＜具体的な構成＞
図１７は、本実施形態の電子帳票サーバの機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図である。これらの図を利用して、それぞれのハードウェア構成部の働きについて説明する。電子帳票サーバは、各種演算処理を実行するための「ＣＰＵ」１７０１と、「記憶装置（記憶媒体）」１７０２と、「メインメモリ」１７０３と、「出力インターフェース」１７０４と、「入力インターフェース」１７０５と、「インターネット通信インターフェース」１７０６と、を備え、入出力インターフェースを介して、例えば「キーボード」１７０７や「ディスプレイ」１７０８と、また、インターネット通信インターフェースを介して帳票発行元の管理する端末である「発行元端末」１７８０や帳票発行先の管理する端末である「発行先端末」１７９０などの外部周辺装置と情報の送受信を行う。なお、記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」１７０９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
なお、本実施形態の電子帳票サーバのハードウェア構成は、基本的に既に図５を用いて説明した実施形態１の電子帳票サーバのハードウェア構成と同様である。そこで以下では、実施形態１で説明しなかった「受信電子帳票保持部」「受信電子帳票出力部」の具体的な処理について、図１７を用いて説明する。

（受信電子帳票保持部の具体的な処理）
ＣＰＵは、記憶装置から「受信電子帳票記録プログラム」１７５０をメインメモリに読み出して実行し、メインメモリの所定のアドレスに格納されている受信電子帳票を読み出し、出力する処理を行う。

（受信電子帳票出力部の具体的な処理）
ＣＰＵは、記憶装置から「受信電子帳票出力プログラム」１７６０をメインメモリに読み出して実行し、メインメモリの所定のアドレスに格納されている受信電子帳票を読み出し、出力する処理を行う。

＜処理の流れ＞
図８は、本実施形態の電子帳票サーバにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０８０１では、帳票発行者毎に帳票上に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する（帳票上データ属性情報記録ステップ）。ステップＳ０８０２では、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する（電子帳票受信ステップ）。その後ステップＳ０８０３では、電子帳票受信ステップにて受信した電子帳票である受信電子帳票を記録し（受信電子帳票保持ステップ）、ステップＳ０８０４ではさらに電子帳票を受信するかどうかを判断する。ここでの判断が受信するとの内容であれば、ステップＳ０８０２以降の処理を繰り返し、受信しないとの内容であればステップＳ０８０５の処理に移行する。その後ステップＳ０８０５では、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する（属性付取引データ記録ステップ）。そしてステップＳ０８０６では、電子帳票受信ステップにて受信した電子帳票である受信電子帳票を出力する（受信電子帳票出力ステップ）。さらにステップＳ０８０７では、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じた共通のレイアウトに出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する（共通出力ステップ）。

なおここで受信電子帳票出力ステップは、必ずしも属性付取引データ記録ステップの後で処理される必要はなく、電子帳票受信ステップの後であればどの段階にて処理されてもよい（以下で述べる他の実施形態においても同様である）。

＜効果＞
本実施形態の電子帳票サーバを利用することにより、複数の電子帳票の一括発行や共通出力フォーマットを用いない帳票発行を望む発行者のニーズに対し柔軟に対応することが可能になる。

＜＜実施形態３＞＞

＜概要＞
本実施形態の電子帳票サーバは、基本的に実施形態２の電子帳票サーバと同様であるが、受信電子帳票を認証を受けるために出力し、認証済みの受信電子帳票である認証済受信電子帳票を保持する点をさらなる特徴とする。

＜機能的構成＞
図９は、本実施形態の電子帳票サーバの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「電子帳票サーバ」０９００は、「電子帳票受信部」０９０１と、「帳票上データ属性情報保持部」０９０２と、「属性付取引データ保持部」０９０３と、「共通出力フォーマット保持部」０９０４と、「共通出力部」０９０５と、「受信電子帳票保持部」０９０６および「受信電子帳票出力部」０９０７を有し、受信電子帳票出力部は「認証出力手段」０９１０を、受信電子帳票保持部は「認証済受信電子帳票保持手段」０９２０をそれぞれ有する。本実実施形態の電子帳票サーバの基本的な構成は、実施形態２の電子帳票サーバと共通するため、以下では相違点である「認証出力手段」および「認証済受信電子帳票保持手段」の機能について説明する。

「認証出力手段」０９１０は、受信電子帳票出力部において、受信電子帳票を認証を受けるために出力するように構成されている。ここでいう「認証を受けるために出力する」出力先は、電子帳票に対する認証を行う外部機関が管理する装置ないしシステムであってもよいし、本実施形態の電子帳票サーバと同一管理者により管理される装置ないしシステムであってもよい。認証の具体的な内容としては、受信電子帳票出力部にて出力される受信電子帳票の作成者が真正であること、電子帳票の内容が真正であること、電子帳票の発行日が真正であること、などのいずれか一以上を示し、電子証明書を発行したり、電子署名を付したりすることで認証処理が行われる。電子証明書の発行は電子帳票の識別情報に関連付けて発行される。電子署名は電子帳票に対して付される。このような認証結果は認証機関から本件電子帳票サーバに対して返信されることで認証済電子帳票保持手段にて保持すべき電子帳票を識別し、また保持すべき電子帳票を取得する。

ちなみに、認証出力手段により出力された受信電子帳票が認証不可と判断される場合には、その旨の情報の発信を受け付ける認証不可情報受付部をさらに設けてもよい。当該構成を設けることで、電子帳票サーバにてその後の処理を行わないようにすることも可能である。

「認証済受信電子帳票保持手段」０９２０は、受信電子帳票保持部において、認証済みの受信電子帳票である認証済受信電子帳票を保持するように構成されている。具体的には、認証出力手段にて出力された受信電子帳票に対する認証が行われた受信電子帳票を受信し保持する。当該構成をとれば、受信電子帳票が真正であることを、帳票発行者ではない電子帳票サーバ管理者において確認証明することが可能になる。

ここで、保持している認証済受信電子帳票を特に帳票発行者に対して送信する認証済受信電子帳票送信手段（図示せず）をさらに設けてもよい。当該構成をとれば、帳票発行元の作成した帳票と電子帳票とがいずれも改ざんされていない真正の電子文書であることを容易に確認証明することができる。

＜具体的な構成＞
本実施形態の電子帳票サーバのハードウェア構成は、基本的に図１７を用いて既に説明した実施形態２の電子帳票サーバのハードウェア構成と同様である。そこで以下では、実施形態２で説明しなかった「認証出力手段」の具体的な処理について述べる。

（認証出力手段の具体的な処理）
ＣＰＵは、受信電子帳票出力プログラムの実行に際して記憶装置から「認証出力サブプログラム」をメインメモリに読み出して実行し、受信電子帳票を認証を受けるために出力する処理を行う。

＜処理の流れ＞
図１０は、本実施形態の電子帳票サーバにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１００１では、帳票上データ属性情報が記録済みであるか否かを判断する。ここで記録が済んでいないと判断される場合には、ステップＳ１００２にて帳票発行者毎に帳票上に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する（帳票上データ属性情報記録ステップ）。済んでいると判断される場合には、ステップＳ１００３にて帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する（電子帳票受信ステップ）。ステップＳ１００４ではさらに電子帳票を受信するかどうかを判断し、ここでの判断が受信するとの内容であれば、ステップＳ１００３以降の処理を繰り返し、受信しないとの内容であればステップＳ１００５の処理に移行する。ステップＳ１００５では電子帳票受信ステップにて受信した受信電子帳票が認証済受信電子帳票か否かを判断し、認証済受信電子帳票であればステップＳ１００６でこれを保持し、そうでない場合にはステップＳ１００７にて電子帳票受信ステップにて受信した電子帳票である受信電子帳票を記録する（受信電子帳票保持ステップ）。なおその後、ステップＳ１００８として受信電子帳票保持ステップにて記録された受信電子帳票を認証を受けるために出力するかどうかを判断し、認証を受けないと判断する場合にはステップＳ１０１１の処理に移行し、認証を受けると判断する場合にはステップＳ１００９として電子帳票受信ステップにて受信した電子帳票である受信電子帳票を認証を受けるために出力する（認証出力ステップ）。認証出力ステップが完了した後にはステップＳ１０１０にて当該認証を受けるための出力の結果を取得し、その後はステップＳ１００５以降の処理を繰り返す。なおここで、認証を受けた電子帳票を帳票発行者に対して送信する処理（認証済受信電子帳票送信ステップ）をおこなってもよい。
ステップＳ１０１１では、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する（属性付取引データ記録ステップ）。その後ステップＳ１０１２では受信電子帳票を出力するかどうかの判断を行い、出力するとの結果であればステップＳ１０１３にて電子帳票受信ステップにて受信した電子帳票である受信電子帳票を出力し（受信電子帳票出力ステップ）、出力しないとの結果であればステップＳ１０１４の処理に移行する。
ステップＳ１０１４では、電子帳票上の取引データを共通出力フォーマットを用いて出力するか否かの判断を行い、出力しないとの判断結果である場合には同様の処理を繰り返すが、出力するとの判断結果である場合には、ステップＳ１０１５として複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じた共通のレイアウトに出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する（共通出力ステップ）。

＜効果＞
本実施形態の電子帳票サーバを利用することにより、電子帳票を受信した事実を電子証明書の形式にて証明し、電子帳票の改ざんや改ざんされた電子帳票の悪用などの事態を事前に防ぐことが可能になる。

＜＜実施形態４＞＞

＜概要＞
本実施形態の電子帳票サーバは、基本的に実施形態２または３の電子帳票サーバと同様であるが、帳票の発行先である帳票発行先に対して電子出力をするか、紙出力をするかを定める情報である発行様式情報と関連付けた受信電子帳票である発行様式付受信電子帳票を保持し、発行様式付受信電子帳票を発行様式に応じて送信することを特徴として備えている。

＜機能的構成＞
図１１は、本実施形態の電子帳票サーバの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「電子帳票サーバ」１１００は、「電子帳票受信部」１１０１と、「帳票上データ属性情報保持部」１１０２と、「属性付取引データ保持部」１１０３と、「共通出力フォーマット保持部」１１０４と、「共通出力部」１１０５と、「受信電子帳票保持部」１１０６および「受信電子帳票出力部」１１０７を有し、受信電子帳票保持部は「発行様式付受信電子帳票保持手段」１１１０を、受信電子帳票出力部は「発行様式依存受信電子帳票送信手段」１１２０を、それぞれ有する。本実施形態の電子帳票サーバの基本的な構成は、実施形態２または３のいずれか一に記載の電子帳票サーバと共通するため、以下では相違点である「発行様式付受信電子帳票保持手段」および「発行様式依存受信電子帳票送信手段」の機能について説明する。

「発行様式付受信電子帳票保持手段」１１１０は、受信電子帳票保持部において、帳票の発行先である帳票発行先に対して電子出力をするか、紙出力をするかを定める情報である発行様式情報と関連付けた受信電子帳票である発行様式付受信電子帳票を保持するように構成されている。

ここで発行様式情報について説明する。取引において発行される種々の帳票については法令上一定期間保管義務が課せられているものが少なくない。そして当該帳票を電子化した場合、当該電子化された帳票（電子帳票）の保管をもって上記保管義務を果たしているといえるためには、税務署等に対する事前の申請及び承認等の手続きが必要となる場合がある。端的にいえば、発行元がいくら電子帳票を発行しても、発行先において上記承認を得ていない場合には、その発行先からは電子帳票ではなく紙の帳票の発行が要求されうる。そしてこのような個々の発行元の事情に場合に対応するため、電子帳票の発行を可とするのか、不可として紙出力が必要なのかを定める情報が発行様式情報である。

なお、あらかじめ発行様式情報を入力するための発行様式情報入力部や、直接又は間接的に他の装置から取得した発行様式情報を保持する発行様式保持部などを設けてもよい。なお、各発行先に対して紙出力を希望するか電子出力を希望するかのリクエスト情報を送信し、当該リクエスト情報への応答に応じて発行様式情報の内容を定めてもよい（実施形態５で詳しく述べる）。当該構成をとることにより、発行先のニーズに応じた柔軟な帳票出力が可能になる。

「発行様式依存受信電子帳票出力手段」１１２０は、受信電子帳票出力部において、発行様式付受信電子帳票を発行様式に応じて出力するように構成されている。「発行様式付受信電子帳票を発行様式に応じて出力する」とは、例えば、紙出力するとの内容の発行様式である発行様式付受信電子帳票については、プリンタ出力を行うといった処理を行うことが考えられる。

＜具体的な構成＞
本実施形態の電子帳票サーバのハードウェア構成は、基本的に図１７を用いて既に説明した実施形態２の電子帳票サーバのハードウェア構成と同様である。そこで以下では、実施形態２で説明しなかった「発行様式依存受信電子帳票送信手段」の具体的な処理について述べる。

（発行様式付受信電子帳票保持手段の具体的な処理）
ＣＰＵは、記憶装置から「発行様式付受信電子帳票保持プログラム」をメインメモリに読み出して実行し、受信電子帳票を発行様式情報と関連付け所定のアドレスに格納する処理を行う。

（発行様式依存受信電子帳票送信手段の具体的な処理）
ＣＰＵは、受信電子帳票出力プログラムの実行に際し記憶装置から「発行様式依存受信電子帳票送信サブプログラム」をメインメモリに読み出して実行し、メインメモリの所定のアドレスに格納されている発行様式付受信電子帳票を読み出し所定の発行様式に応じて送信する処理を行う。

＜処理の流れ＞
図１２は、本実施形態の電子帳票サーバにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１２０１では、帳票上データ属性情報が記録済みであるか否かを判断する。ここで記録が済んでいないと判断される場合には、ステップＳ１２０２にて帳票発行者毎に帳票上に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する（帳票上データ属性情報記録ステップ）。済んでいると判断される場合には、ステップＳ１２０３にて帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する（電子帳票受信ステップ）。
ステップＳ１２０４では電子帳票受信ステップにて受信した受信電子帳票が発行様式付受信電子帳票か否かを判断し、発行様式付受信電子帳票であればステップＳ１２０５でこれを保持し、そうでない場合にはステップＳ１２０６で当該受信電子帳票に発行様式を付するか否かを判断する。付加するとの判断結果である場合にはステップＳ１２０７にて発行様式を付加したのち、ステップＳ１２０５として、電子帳票受信ステップにて受信した発行様式付の電子帳票である発行様式付受信電子帳票を記録し、（発行様式付受信電子帳票保持ステップ）ステップＳ１２０９の処理に移行する。付加しないとの判断結果である場合にはステップＳ１２０８として電子帳票受信ステップにて受信した電子帳票である受信電子帳票を記録し（受信電子帳票保持ステップ）ステップＳ１２０９の処理に移行する。
ステップＳ１２０９ではさらに電子帳票を受信するかどうかを判断し、ここでの判断が受信するとの内容であれば、ステップＳ１２０３以降の処理を繰り返し、受信しないとの内容であればステップＳ１２１０の処理として、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する（属性付取引データ記録ステップ）。
その後ステップＳ１２１１では受信電子帳票を出力するかどうかの判断を行い、出力するとの結果であれば、次にステップＳ１２１２として出力対象が発行様式付受信電子帳票か否かを判断する。そこでの判断結果に応じて、ステップＳ１２１３として発行様式付受信電子帳票を出力するか、ステップＳ１２１４として受信電子帳票を出力するかのいずれかの処理をおこなう。なお、ステップＳ１２１２にて受信電子帳票を出力しない、との判断結果が出た場合には、更にステップＳ１２１７にて取引データを出力するか否かを判断する処理を行い、出力するとの判断結果であればステップＳ１２１５の処理に移行し、出力しないとの判断結果であればステップＳ１２０３以降の処理を行う。
その後ステップＳ１２１５では、電子帳票上の取引データを共通出力フォーマットを用いて出力するか否かの判断を行い、出力しないとの判断結果である場合には同様の処理を繰り返すが、出力するとの判断結果である場合には、ステップＳ１２１６として複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じた共通のレイアウトに出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する（共通出力ステップ）。

＜効果＞
本実施形態の電子帳票サーバを利用することにより、電子出力のパターンによる発行先と、紙出力にて帳票発行をおこなう発行先との双方に対する事務処理をスムーズに行うことが可能になる。

＜＜実施形態５＞＞

＜概要＞
本実施形態の電子帳票サーバは、基本的に実施形態２ないし４の電子帳票サーバと同様であるが、電子帳票サーバを利用するために必要な情報である利用必要情報を保持し、受信電子帳票を出力する際に利用必要情報を受信電子帳票と同一の電子文書形式にて送信することを特徴として備えている。

＜機能的構成＞
図１３は、本実施形態の電子帳票サーバの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「電子帳票サーバ」１３００は、「電子帳票受信部」１３０１と、「帳票上データ属性情報保持部」１３０２と、「属性付取引データ保持部」１３０３と、「共通出力フォーマット保持部」１３０４と、「共通出力部」１３０５と、「受信電子帳票保持部」１３０６と、「受信電子帳票出力部」１３０７と、「利用必要情報保持部」１３０８と、を有し、受信電子帳票出力部は「利用必要情報付受信電子帳票送信手段」１３１０を有する。本実施形態の電子帳票サーバの基本的な構成は、実施形態２から４のいずれか一に記載の電子帳票サーバと共通するため、以下では相違点である「利用必要情報保持部」および「利用必要情報付受信電子帳票送信手段」の機能について説明する。

「利用必要情報保持部」１３０８は、電子帳票サーバを利用するために必要な情報である利用必要情報を保持するように構成される。利用必要情報は本実施形態の電子帳票サーバを利用して帳票を発行するために必要な情報であり、本実施形態の電子帳票サーバを利用して帳票を発行したことのない利用者に対しその利用を促すための情報である。必要に応じて都度ユニークな内容の利用必要情報を生成し保持する構成であってもよいし、あらかじめ生成された利用必要情報を保持しておく構成でもよい。

具体的には、帳票を電子帳票にて受信することを承諾する旨の情報を登録するためにアクセスすることが必要なＷｅｂサイトのＵＲＬや当該ＷｅｂサイトにログインするためのＩＤやパスワードなどを利用必要情報として保持することが考えられる。帳票一般ではなく特定の帳票のみ（例えば、請求書や領収書のみを対象として、契約書は除外する等）について電子帳票サーバを利用する旨の情報を利用必要情報として保持していてもよい。当該構成をとることによって、発行先の柔軟な意思に応じた電子帳票サーバの利用が可能になる。さらに言えば、現状では紙にて帳票管理を行っている発行先に対して電子帳票による管理を促し、発行元のみならず発行先にとって紙による帳票管理の煩雑さを解消させることも可能になる。

「利用必要情報付受信電子帳票出力手段」１３１０は、受信電子帳票出力部において受信電子帳票を出力する際に利用必要情報を受信電子帳票と同一の電子文書形式にて出力するように構成されている。「利用必要情報を受信電子帳票と同一の電子文書形式にて送信する」とは、例えば、受信電子帳票がｐｄｆフォーマットであれば、利用必要情報もｐｄｆフォーマットにて送信されることを意味している。ｐｄｆにはハイパーリンクなどの技術的手段が用いられ、これを受信した利用者が円滑に本実施形態の電子帳票サーバを利用することが可能になる。当該構成をとることにより、当該利用必要情報の受信者に対し、一の出力形態にて利用必要情報と受信電子帳票とを出力することが可能になる。

＜具体的な構成＞
本実施形態の電子帳票サーバのハードウェア構成は、基本的に図１７を用いて既に説明した実施形態２の電子帳票サーバのハードウェア構成と同様である。そこで以下では、実施形態２で説明しなかった「利用必要情報付受信電子帳票送信手段」の具体的な処理について述べる。

（利用必要情報保持手段の具体的な処理）
ＣＰＵは、記憶装置から「利用必要情報保持プログラム」をメインメモリに読み出して実行し、利用必要情報を所定のアドレスに格納する処理を行う。

（利用必要情報付受信電子帳票送信手段の具体的な処理）
ＣＰＵは、受信電子帳票出力プログラムの実行に際し記憶装置から「利用必要情報付受信電子帳票送信サブプログラム」をメインメモリに読み出して実行し、メインメモリの所定のアドレスに格納されている利用必要情報を読み出すとともに受信電子帳票と同一の電子文書形式にて送信する処理を行う。

＜処理の流れ＞
図１４は、本実施形態の電子帳票サーバにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１４０１では、帳票発行者毎に帳票上に配置されるデータの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する（帳票上データ属性情報記録ステップ）。ステップＳ１４０２では、電子帳票サーバを利用するために必要な情報である利用必要情報を記録する（利用必要情報保持ステップ）。
ステップＳ１４０３では、帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する（電子帳票受信ステップ）。その後ステップＳ１４０４では、受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する（属性付取引データ記録ステップ）。そしてステップＳ１４０５で利用必要情報を取得したのち、ステップＳ１４０６にて受信電子帳票と利用必要情報とを同一の電子文書形式にて出力する（利用必要情報付受信電子帳票送信ステップ）。そしてさらにステップＳ１４０７では、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じた共通のレイアウトに出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する（共通出力ステップ）。

＜効果＞
本実施形態の電子帳票サーバを利用することにより、紙出力にて帳票発行を行っている発行先に対して、電子帳票の利用を促すことができる。

０１００…電子帳票サーバ、０１０１…電子帳票受信部、０１０２…帳票上データ属性情報保持部、０１０３…属性付取引データ保持部、０１０４…共通出力フォーマット保持部、０１０５…共通出力部

Claims (9)

1. 帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信部と、
   帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を保持する帳票上データ属性情報保持部と、
   受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて保持する属性付取引データ保持部と、
   複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部と、
   前記属性付取引データ保持部に保持されている複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて前記共通出力フォーマットを用いて出力する共通出力部と、
   を有する電子帳票サーバ。
2. 電子帳票受信部にて受信した電子帳票である受信電子帳票を保持する受信電子帳票保持部と、
   保持されている受信電子帳票を出力する受信電子帳票出力部と、を有する請求項１に記載の電子帳票サーバ。
3. 受信電子帳票出力部は、受信電子帳票の認証を受けるために出力する認証出力手段を有し、
   受信電子帳票保持部は、認証済みの受信電子帳票である認証済受信電子帳票を保持する認証済受信電子帳票保持手段を有する請求項２に記載の電子帳票サーバ。
4. 受信電子帳票出力部は、認証済受信電子帳票を帳票発行者に対して送信する認証済受信電子帳票送信手段を有する請求項３に記載の電子帳票サーバ。
5. 受信電子帳票保持部は、帳票の発行先である帳票発行先に対して電子出力をするか、紙出力をするかを定める情報である発行様式情報と関連付けた受信電子帳票である発行様式付受信電子帳票を保持する発行様式付受信電子帳票保持手段を有し、
   受信電子帳票出力部は、発行様式付受信電子帳票を発行様式に応じて出力する発行様式依存受信電子帳票出力手段を有する請求項２から４のいずれか一に記載の電子帳票サーバ。
6. 電子帳票サーバを利用するために必要な情報である利用必要情報を保持する利用必要情報保持部を有し、
   受信電子帳票出力部は、受信電子帳票を出力する際に利用必要情報を受信電子帳票と同一の電子文書形式にて出力する利用必要情報付受信電子帳票出力手段を有する請求項２から５のいずれか一に記載の電子帳票サーバ。
7. 帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信ステップと、
   帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する帳票上データ属性情報記録ステップと、
   受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する属性付取引データ記録ステップと、
   複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている共通出力フォーマットを用いて、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて出力する共通出力ステップと、
   を有する電子帳票サーバの動作方法。
8. 帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信ステップと、
   帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する帳票上データ属性情報記録ステップと、
   受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する属性付取引データ記録ステップと、
   複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている共通出力フォーマットを用いて、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて出力する共通出力ステップと、
   を計算機に実行可能とした電子帳票サーバの動作プログラム。
9. 帳票に含まれる取引データと、その取引データの帳票上でのレイアウト情報を含む電子文書である電子帳票を帳票発行者に関連付けて受信する電子帳票受信ステップと、
   帳票発行者毎に帳票上に配置される取引データの帳票上での配置に応じて定められるデータ属性の情報である帳票上データ属性情報を帳票上データ属性情報保持部に記録する帳票上データ属性情報記録ステップと、
   受信した電子帳票に含まれる取引データの帳票上でのレイアウト情報と、保持されているその帳票発行者の帳票上データ属性情報とを用いて、受信した電子帳票に含まれる取引データとデータ属性とを関連付けて属性付取引データ保持部に記録する属性付取引データ記録ステップと、
   複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて共通のレイアウトに従って出力するための共通出力フォーマットを保持する共通出力フォーマット保持部に保持されている共通出力フォーマットを用いて、複数の帳票発行者が発行する異なる種類の電子帳票上の取引データをデータ属性に応じて出力する共通出力ステップと、
   を計算機に読取実行可能とした電子帳票サーバの動作プログラムを記録した記録媒体。

Images