JPWO2014020711A1 - 取引管理システムおよび取引管理プログラム - Google Patents

Abstract

【課題】段階的な複数の取引者間での商品の取引の伝票管理を簡易にする。【解決手段】取引管理システムは、中間取引者ID及び商品IDに対応づけて、中間取引者が当該商品を発注する上流取引者IDを記憶する取引設定情報記憶部と、商品ID及び上流取引者IDに対応づけて当該上流取引者による商品の第1の販売価格を記憶すると共に、商品ID及び中間取引者IDに対応づけて当該中間取引者による商品の第2の販売価格を記憶する価格記憶部と、伝票発行処理部とを含む。伝票発行処理部は、下流取引者から商品の発注があると、発注数量および第2の販売価格に基づき、下流取引者から中間取引者への発注伝票を生成するとともに、発注数量及び第1の販売価格に基づき、中間取引者から上流取引者への発注伝票を生成する。発注，納品，物流データを一元管理して、発注伝票生成時のデータを用いて、効率的に納品伝票を作成する。売上元帳と仕入元帳についても同様である。

Description

本発明は、取引管理システムおよび取引管理プログラムに関する。

商品の流通には、たとえば商品のメーカ等の生産者から末端消費者までの間に、卸業者や小売業者等が介在し、複数の取引者が段階的に関与することが多い。複数の取引者が段階的に商品の流通に関与する場合、各取引者間の取引状態を容易に把握可能とすることや、商品の流通経路を簡易に把握できる仕組みが求められる。

また、近年、商品を購入したい発注者が、ネットワークを介して自分の端末装置から発注先のサーバ等にアクセスし、商品の発注を行う処理がさかんに行われている。このような処理は、発注先と発注者との２者間の処理だけでなく、たとえば実際に商品を提供する業者、それを仲介する業者、および商品を購入する顧客の三者間で行われることもある。

たとえば、特許文献１（特開２００７−１７２０８１号公報）には、仲介販売支援システムおよび仲介販売支援方法が記載されている。当該仲介販売支援技術では、販売仲介者用サーバシステムと商品提供者用サーバシステムとがネットワークを介して接続された構成となっている。顧客が顧客端末装置から販売仲介者用サーバシステムから提供される販売仲介者ホームページに含まれているリンクを選択すると、商品提供者用サーバシステムは、商品提供者ホームページを顧客端末装置の表示面に表示させる。また、商品提供者用サーバシステムは、顧客が商品提供者ホームページにおいて選択した商品の注文書生成データを要求すると、注文書生成データを顧客端末装置に送信する。販売仲介者用サーバシステムは、顧客が注文書生成データに基づき作成した注文書データを顧客端末装置から受信する。このように、販売仲介者ホームページに商品提供者ホームページのリンクを含めることにより、販売仲介者が販売に用いるホームページについて、その更新手間を削減しかつ最新情報を顧客に提供することができるとされている。また、販売仲介者用サーバシステムは、商品の発注者である顧客からの注文データに基づき、商品提供者への注文伝票データを生成する構成となっている。

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

しかし、特許文献１に記載された技術では、販売仲介者用サーバシステムは、顧客からの注文内容および発送先のデータを商品提供者のサーバシステムに仲介しているだけであり、販売仲介者と商品提供者との商品の取引に関する処理が自動的に行われる構成とはなっていない。そのため、注文処理は行うことができても、実際の取引の伝票管理は別途行う必要があり、依然として管理に手間がかかるという問題があった。

本発明の目的は、上述した課題である、段階的な複数の取引者間での商品の取引の伝票管理を簡易にすることができる取引管理システムおよび取引管理プログラムを提供することにある。

本発明によれば、
中間取引者の中間取引者ＩＤおよび商品ＩＤに対応づけて、当該中間取引者が当該商品ＩＤで特定される商品を購入する上流取引者ＩＤを記憶する取引設定情報記憶部と、
商品ＩＤおよび上流取引者ＩＤに対応づけて上流取引者ＩＤで特定される上流取引者による商品の販売価格である第１の販売価格を記憶するとともに、商品ＩＤおよび中間取引者ＩＤに対応づけて当該中間取引者による商品の販売価格である第２の販売価格を記憶する価格記憶部と、
中間取引者が商品を販売する下流取引者から、商品ＩＤ、当該下流取引者の下流取引者ＩＤ、および商品の発注数量の入力とともに、中間取引者への商品の発注を受け付ける発注管理部と、
発注管理部が受け付けた発注数量および第２の販売価格に基づき、下流取引者から中間取引者への発注伝票を発行するとともに、発注管理部が受け付けた発注数量および第１の販売価格に基づき、中間取引者から上流取引者への発注伝票を発行する伝票発行処理部と、
を含む取引管理システムが提供される。

このように、商品ＩＤで特定されるある商品について、ある中間取引者がその商品を購入する先の上流取引者およびその上流取引者が当該商品を販売する第１の販売価格を取引設定情報記憶部および価格記憶部に登録しておくことにより、取引管理システムは、下流取引者から発注があった場合に、中間取引者と上流取引者との間の商品の販売価格も把握することができる。そのため、下流取引者から中間取引者への発注伝票を発行するだけでなく、中間取引者から上流取引者への発注伝票も自動的に発行することができる。たとえば、下流取引者と中間取引者、中間取引者と上流取引者という３者以上の間で段階的な取引が行われる際に、取引される商品の発注数量が変化しない場合に、下流取引者から入力される商品の発注数量に基づき、上流取引者による第１の販売価格を用いて、上流取引者への発注伝票を容易に発行することができる。

ここで、上流取引者は、この取引管理システムのユーザであってもなくてもいずれでもよい。上流取引者がこのシステムのユーザである場合は、たとえば上流取引者がログインした状態で上流取引者のユーザ端末のディスプレイに発注伝票が表示される形態で提供することができる。また、上流取引者への商品の発注処理を電子的に自動で行うことができる。また、上流取引者がこのシステムのユーザでない場合も、発注伝票が自動的に発行されるので、それをファクシミリ送付したり、メール添付したりして発注処理を簡易に行うことができる。また、取引管理システムが複数のサーバで分散構成されており、上流取引者とその下流の取引者とが異なるサーバのユーザである場合は、サーバ間のデータ連携によって取引者間の発注処理を行うことができる。

また、本発明の取引管理システムにおいて、伝票発行処理部は、中間取引者から上流取引者への発注伝票を発行するために用いた発注数量および第１の販売価格に基づき、上流取引者から中間取引者への請求伝票または納品伝票を発行するとともに、下流取引者から中間取引者への発注伝票を発行するために用いた発注数量および第２の販売価格に基づき、中間取引者から下流取引者への請求伝票または納品伝票を発行することができる。

このような取引において、取引者間でやりとりされる商品の発注数量は互いに同じである。従って、下流側から上流側への発注伝票の発行に用いたデータを上流側から下流側への請求伝票または納品伝票に用いることにより、請求伝票または納品伝票の発行を容易に行うことができる。

また、本発明に係る取引管理システムの取引管理情報記憶部において、商品ＩＤによって、上流取引者と下流取引者が一致する取引データをリンクすることによって、商品物流の全体の把握が可能になる。

さらに、ある商品について、上流の各取引業者の在庫状況が見られるようにすることにより、発注の要否や発注時の納期の予測が可能になる。一方、ある商品について、下流の各取引業者の在庫状況が見られるようにすることにより、受注予測が可能になる。

また、商品納品時に下流取引者が商品の異常（数量不足や品質不良など）を発見したときに、その異常を登録することによって、中間取引者は、該中間取引者とその上流取引者との間の検収前に上流取引者に注意し、再送などを促すことができるので、商品の品質を担保を簡便なＤＢ構造によって実現することができる。

このように、本発明に係る取引管理システムは、商品受取者と商品発送者を末端として、その間に所定数の取引仲介業者を挿入した取引パターンを設けることにより、この取引パターンを単位として発注管理、納品管理、請求管理、商品の品質管理、商品の物流管理を効率的に行うことができる。すなわち、取引管理情報記憶部のこのパターン化された簡便なデータ構造によって、これらの管理を可能にしたのが、本発明の大きな特徴の一つと言える。

ここで、商品は、有体物のみならず、無体物である「役務」も含んでいる。また、「販売」は、商品の販売のみならず役務の「提供」も含む趣旨である。したがって、本発明に係る取引管理システムは、商品取引のみならず、役務の提供に対しても適用可能である。

また、本発明に係る取引管理システムの納期管理部は、上流取引者から送られてくる取引ＩＤと発送完了済み通知を受けて、該取引ＩＤの各取引者間における取引の検収基準が発送時検収か、納品時検収かを判定し、発送時検収の場合は、該取引者間の請求可能フラグをオンにする一方、納品時検収の場合は待ちリストに登録し、下流取引者の端末から商品受領日付送られてきた場合は、その日付を格納し、周期的に当該待ちリストに登録されている取引ＩＤについて、商品受領日付が書き込まれているか否かを判定し、商品受領日付が書き込まれている場合は、当該取引ＩＤの納品時検収の取引者間の取引の請求可能フラグをオンにする。また、伝票発行処理部は、請求形態に基づいて、都度請求の場合は直ちに、締め請求の場合は締め日に、請求可能フラグがオンになっている取引についてのみ伝票データを作成する。

本発明は、発注書と請求書などの所謂表裏の関係にある伝票を適切なタイミングで作成することができる。売上元帳，仕入元帳についても同様である。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、段階的な複数の取引者間での商品の取引の伝票管理を簡易にすることができる。

本発明の実施の形態における取引管理システムおよびユーザ端末の構成を示すブロック図である。 本発明の実施の形態における取引管理システムの構成を詳細に示す機能ブロック図である。 商品情報記憶部のデータ構成の一例を示す図である。 取引者情報記憶部のデータ構成の一例を示す図である。 取引設定情報記憶部のデータ構成の一例を示す図である。 価格記憶部のデータ構成の一例を示す図である。 取引管理情報記憶部のデータ構成の一例を示す図である。 発注管理部の処理手順の一例を示すフローチャートである。 発注管理部の処理手順の一例を示すフローチャートである。 図７に示した取引管理情報記憶部のデータ構成の一例を模式的に示す図である。 納品管理部の処理手順の一例を示すフローチャートである。 取引管理情報記憶部のデータ構成の一例を模式的に示す図である。 納品管理部の処理手順の一例を示すフローチャートである。 伝票発行処理部の処理手順の一例を示すフローチャートである。 伝票発行処理部により提供される伝票を模式的に示す図である。 伝票発行処理部により提供される伝票を模式的に示す図である。 物流状況管理部が下流側の取引者から出荷された商品の数量を提示する処理手順を示すフローチャートである。 取引管理情報記憶部のデータ構成の一例を示す図である。 取引管理情報記憶部のデータ構成の他の例を示す図である。 物流状況管理部が下流側の取引者から出荷された商品の数量を提示する処理手順を示すフローチャートである。 取引管理情報記憶部のデータ構成の他の例を示す図である。 在庫情報記憶部のデータ構成の一例を示す図である。 ユーザに提示される在庫情報の一例を示す図である。 本発明の第２の実施の形態による取引管理情報記憶部のデータ構成の一例を示す図である。 本発明の第２の実施の形態による納品管理部の発送時起動ルーチンの処理手順を示すフローチャートである。 本発明の第２の実施の形態による納品管理部の定周期起動ルーチンの処理手順を示すフローチャートである。 本発明の実施の形態による発注情報の流れと商品の流れの説明図である。

以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。

（第１の実施の形態）
図１は、本発明の第１の実施の形態における取引管理システム１０および取引管理システム１０と通信を行う各取引者の端末であるユーザ端末４０、ユーザ端末４２、ユーザ端末４４の構成を示すブロック図である。

取引管理システム１０は、ネットワーク５０を介してユーザ端末４０、ユーザ端末４２、およびユーザ端末４４等の端末と接続されている。ネットワーク５０は、たとえばインターネット等のパブリックネットワークやイントラネット等のローカルネットワーク等とすることができる。

取引管理システム１０は、たとえば取引管理サービス事業者により管理、運営されている。取引管理システム１０は、商品の流通の取引者間の商品の受発注処理の管理を行う。ユーザ端末４０、ユーザ端末４２、およびユーザ端末４４は、取引管理サービス事業者の提供するサービスを利用して取引を行う各取引者のたとえばパーソナルコンピュータ等の端末とすることができる。本実施の形態において、取引者は、取引業者とすることができる。

本実施の形態において、取引管理システム１０は、たとえば商品のメーカ等の生産者、末端消費者、ならびにこれらの間に介在する卸業者や小売業者等の取引者間での取引に関する取引管理情報を統合的に保持する構成とすることができる。このような構成とすることにより、商品の売買を直接行う二者間のデータだけでなく、商品が流通される段階的な取引におけるデータに基づき、伝票発行処理や、帳簿生成処理、在庫管理処理、および商品の流通のトレーサビリティ管理等を容易に行うようにすることができる。また、このような構成とすることにより、下流側の取引で用いた取引管理情報の情報を上流側の取引管理情報に転用したり、上流側の取引で用いた取引管理情報の情報を下流側の取引管理情報に転用したりすることができる。また、各取引者が統合的なデータにアクセス可能となっているので、後述する伝票や帳簿等を各取引者に提供する際に、互いにデータを送受信等する必要もない。

図２は、本実施の形態における取引管理システム１０の構成を詳細に示す機能ブロック図である。
取引管理システム１０は、ネットワーク５０を介してデータの送受信を行うための送受信部２４、送受信部２４から受け取ったデータの処理を行う中央演算処理部２６、およびデータを記憶するためのデータ記憶部２８を含む。

中央演算処理部２６は、構成要素として、送受信処理部１１２、設定情報受付部１１４、発注管理部１１８、取引管理情報生成部１２０、伝票発行処理部１２２、納品管理部１２６、および物流状況管理部１２８を含む。データ記憶部２８は、構成要素として、商品情報記憶部１４０、取引者情報記憶部１４２、取引設定情報記憶部１４４、価格記憶部１４６、取引管理情報記憶部１４８、伝票情報記憶部１５０および在庫情報記憶部１５２を含む。

図２に示した取引管理システム１０の中央演算処理部２６およびデータ記憶部２８の各構成要素は、ハードウエア単位の構成ではなく、機能単位のブロックを示している。取引管理システム１０の中央演算処理部２６およびデータ記憶部２８の各構成要素は、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた本図の構成要素を実現するプログラム、そのプログラムを格納するハードディスクなどの記憶ユニット、ネットワーク接続用インタフェースを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。また、ここでは図示していないが、取引管理システム１０は、データの入出力を行うたとえばキーボードやマウス等の入力部およびたとえばディスプレイ等の表示部を含むことができる。さらに、中央演算処理部２６は、そのような入力部および表示部との間でデータの入出力を行う入出力処理機能を有する構成とすることができる。また、取引管理システム１０の構成は、物理的に一つの装置で構成されたものに限られず、分散配置された構成とすることもできる。

次に、中央演算処理部２６およびデータ記憶部２８の各構成要素を具体的に説明する。
送受信処理部１１２は、送受信部２４との間でデータの受け渡しを行う。

商品情報記憶部１４０は、取引管理システム１０のユーザが取引管理システム１０を利用して取引の管理を行う商品に関する情報を商品ＩＤに対応づけて記憶する。取引者情報記憶部１４２は、取引管理システム１０のユーザである取引者に関する情報を取引者ＩＤに対応づけて記憶する。

取引設定情報記憶部１４４は、取引者ＩＤに対応づけて各取引者が販売する商品の商品ＩＤを記憶する。また、取引設定情報記憶部１４４は、取引者ＩＤおよび商品ＩＤの組合せに対応づけて、当該取引者が当該商品ＩＤで特定される商品を購入する発注先の上流取引者の上流取引者ＩＤ、当該取引者に当該商品ＩＤで特定される商品を発注する発注者である下流取引者の下流取引者ＩＤ、当該下流取引者への販売可能数量、発注管理モード、商品流通モード等を取引設定情報として記憶することができる。

価格記憶部１４６は、各商品に対して各取引者が発注者である下流取引者に販売する販売価格を商品ＩＤ、取引者ＩＤ、および発注者である下流取引者の下流取引者ＩＤに対応付けて記憶する。

設定情報受付部１１４は、ユーザがユーザ端末４０〜ユーザ端末４２等のユーザ端末からネットワーク５０を介して入力する各種設定情報を受け付け、それぞれ商品情報記憶部１４０、取引者情報記憶部１４２、取引設定情報記憶部１４４、および価格記憶部１４６に記憶する。本実施の形態において、取引設定情報記憶部１４４および価格記憶部１４６に記憶するデータは、各取引者であるユーザが直接ユーザ端末４０〜ユーザ端末４２等のユーザ端末から入力したり、各取引者が設定した情報をオペレータ等がユーザ端末４０〜ユーザ端末４２等のユーザ端末や取引管理システム１０の入力部から入力したりすることができる。

図３は、商品情報記憶部１４０のデータ構成の一例を示す図である。商品情報記憶部１４０は、商品ＩＤに対応づけて、各商品の商品区分、商品名、生産者情報、商品紹介アドレス等の情報を記憶する。

図４は、取引者情報記憶部１４２のデータ構成の一例を示す図である。取引者情報記憶部１４２は、取引者ＩＤに対応づけて、各取引者の取引者名、住所、電話番号、電子メールアドレス、パスワード、取引者紹介アドレス等の情報を記憶する。ここで、取引者ＩＤは、各取引者が取引管理システム１０にログイン等する際にユーザを識別するユーザＩＤとすることができる。

図５は、取引設定情報記憶部１４４のデータ構成の一例を示す図である。
取引設定情報記憶部１４４は、対象の取引者（中間取引者に該当）の取引者ＩＤに対応づけて、当該取引者が販売する商品の商品ＩＤ、当該取引者が当該商品ＩＤで特定される商品を購入する発注先の上流取引者の上流取引者ＩＤ、当該取引者に当該商品ＩＤで特定される商品を発注する発注者である下流取引者の下流取引者ＩＤ、当該下流取引者への販売可能数量、その商品を上流取引者に発注するか否かの発注管理モード、上流側に自動的に発注してよいか否かの自動発注許可フラグ、その商品を上流取引者に発注したときの商品流通モード等の情報を記憶する。

ここで、発注管理モードとは、当該取引者が下流側の取引者から商品の発注を受けた際にさらに上流側の取引者への発注が必要か否かを示す。たとえば、中間取引者が在庫を保持しており、下流取引者から商品の発注があった場合に自己の保持する在庫を下流取引者に提供する場合は、その時点での上流取引者への発注は不要のため、「発注不要」とされる。たとえば、図５に示した例では、取引者ＩＤ「ａ」および取引者ＩＤ「ｃ」の取引者については、自己で商品ＩＤ「ｐ０００１」の商品の在庫を保持しているため、発注管理モードが「発注不要」となっている。一方、取引者ＩＤ「ｂ」の取引者については、発注管理モードが「発注要」となっている。これは、取引者ＩＤ「ｂ」の取引者に対して下流取引者ＩＤで特定される下流取引者から発注があった場合は、その上流側の上流取引者ＩＤで特定される上流取引者への発注が必要ということである。

また、発注管理モードを「発注要」と設定する場合には、上流取引者への発注を自動で行ってよいか、または当該取引者への確認が必要かということを区別可能に設定することができる。上流取引者への発注を自動で行ってよい場合は自動発注許可フラグ欄の自動発注許可フラグがオンとされる。ここでは、自動発注フラグをオンとした場合、「レ」と示している。図５に示した例では、取引者ＩＤ「ｂ」の取引者については、発注管理モードが「発注要」となっており、自動発注許可フラグ欄に「レ」と設定されている。これは、取引者ＩＤ「ａ」の取引者がその上流取引者ＩＤ「ｂ」の取引者に商品ＩＤ「ｐ０００１」の商品を発注した場合、取引者ＩＤ「ｂ」の取引者の発注先である上流取引者ＩＤ「ｃ」の取引者への発注を自動的に行ってよいということである。

なお、本明細書中で「上流」および「下流」とは、商品の流れに対応し、商品は上流取引者から下流取引者の方向に流通される。

また、商品流通モードとは、当該取引者から上流側の取引者に商品の発注を行った際の当該取引者への商品の流通形態を示す。たとえば、当該取引者が上流側の取引者から商品を受け取る場合は「商品受取」、当該取引者が下流側の取引者からの発注を上流側の取引者に仲介するのみで、当該取引者自体は商品を受け取らない場合は「直送」と設定することができる。たとえば、図５に示した例では、取引者ＩＤ「ａ」および取引者ＩＤ「ｃ」の取引者については、商品流通モードが「商品受取」となっている。これは、取引者ＩＤ「ａ」の取引者および取引者ＩＤ「ｃ」の取引者は、それらの上流側の取引者から実際に商品を受け取る必要があるということである。一方、取引者ＩＤ「ｂ」の取引者については、商品流通モードが「直送」となっている。これは、取引者ＩＤ「ｂ」の取引者は、取引の仲介をするだけで、その上流側の取引者から実際に商品を受け取る必要はないということである。つまり、上流取引者ＩＤ「ｃ」の取引者への発注が行われた後、上流取引者ＩＤ「ｃ」から発送される商品は、取引者ＩＤ「ｂ」の取引者へは発送されず、取引者ＩＤ「ａ」の取引者へ直送されるということである。

図６は、価格記憶部１４６のデータ構成の一例を示す図である。
価格記憶部１４６は、商品ＩＤに対応づけて、取引者ＩＤ、下流取引者ＩＤ、販売価格（単価（円））、請求形態、請求タイミング等の情報を記憶する。請求形態および請求タイミングは、発注者である上流側の取引者と発注先である取引者との間で決定しておき、たとえば発注先である取引者がユーザ端末４０〜ユーザ端末４２から設定情報受付部１１４を介して価格記憶部１４６に登録しておくことができる。

ここで、請求形態欄には、発注ごとに請求書を発行する都度請求か、たとえば月末や期末等に請求書をまとめて発行する締め請求かを設定しておくことができる。たとえば請求形態が都度請求の場合は、請求タイミング欄には、下流取引者から商品の発注があった際に請求書を発行する取り決めである「発注時」、発注先である上流側の取引者から商品の発送があった際に請求書を発行する取り決めである「商品発送時」、発注者である取引者に商品が納入された際に請求書を発行する取り決めである「商品納入時」等を設定することができる。また、たとえば請求形態が締め請求の場合は、請求タイミング欄には、期末にまとめて請求書を発行する取り決めである「期末」、月末にまとめて請求書を発行する取り決めである「月末」等を設定することができる。販売価格は、基本的に下流側ほど高く設定される。これにより、取引者が卸業者等の場合に、販売利益を得ることができる。

（発注処理）
次に、本実施の形態の取引管理システム１０における発注処理手順を説明する。
図２に戻り、発注管理部１１８は、取引者であるユーザから商品の発注指示を受け付けると、その発注指示に基づく発注処理を管理する。以下、最初に商品の発注指示を行う取引者を下流取引者、その下流取引者の発注先の取引者を中間取引者、さらにその中間取引者の発注先の取引者を上流取引者として説明する。発注管理部１１８は、ある下流取引者から商品の発注指示があった場合に、発注先である中間取引者がさらに上流側の上流取引者に商品を発注するか否かを判定する。発注管理部１１８は、上流側の上流取引者に商品を発注すると判定した場合、その上流側の上流取引者への発注処理も行う。

下流取引者は、商品を発注する際、ユーザ端末４０〜ユーザ端末４２等のユーザ端末からネットワーク５０を介してたとえば自己のユーザＩＤである下流取引者ＩＤおよびパスワードを入力して、取引管理システム１０にログインする。発注管理部１１８は、ログインした下流取引者が発注指示を行うと、下流取引者が入力する発注情報を受け付ける。本実施の形態において、発注管理部１１８は、発注者である下流取引者の下流取引者ＩＤ、発注する商品の商品ＩＤ、および発注する商品の発注数量の入力を受け付ける。発注管理部１１８は、下流取引者の下流取引者ＩＤおよび商品ＩＤをキーとして、取引設定情報記憶部１４４および価格記憶部１４６から、その商品を当該下流取引者に販売する発注先の中間取引者の中間取引者ＩＤおよび販売価格も発注情報として取得する。

なお、発注管理部１１８は、下流取引者がログインした状態で商品の発注指示を行った場合、たとえばそのユーザ端末に発注のための情報を入力する入力画面（不図示）を提供してもよい。また、発注管理部１１８は、下流取引者から、商品名または商品ＩＤの入力を受け付けることにより、その商品名または商品ＩＤをキーとして、商品情報記憶部１４０、取引設定情報記憶部１４４および価格記憶部１４６等から該当する商品の情報を読み出してユーザの入力画面に提示してもよい。また、発注管理部１１８は、下流取引者の下流取引者ＩＤをキーとして、取引設定情報記憶部１４４および価格記憶部１４６にアクセスして、たとえばその下流取引者が下流取引者として設定されている複数の商品の各商品ＩＤを取得し、入力画面にリストとして表示して、下流取引者に商品を選択させるようにしてもよい。この場合、商品ＩＤをキーとして商品情報記憶部１４０から商品の情報を読み出して商品情報も入力画面に表示するようにしてもよい。このとき発注管理部１１８は、下流取引者ＩＤおよび商品ＩＤをキーとして、取引設定情報記憶部１４４から上流取引者が当該下流取引者に割り当てているその商品の販売可能数量等を読み出し、それを入力画面に表示するようにしてもよい。

発注管理部１１８は、下流取引者から発注指示を受け付けると、取引ＩＤを発行する。発注管理部１１８は、取引ＩＤを発行すると、取引管理情報生成部１２０にその旨を通知する。取引管理情報生成部１２０は、発注管理部１１８が発行した取引ＩＤに対応付けて、発注管理部１１８がユーザから受け付けた発注情報ならびに取引設定情報記憶部１４４および価格記憶部１４６から取得した発注情報を含む取引管理情報を生成する。取引管理情報生成部１２０は、生成した取引管理情報を取引管理情報記憶部１４８に記憶する。

なお、本明細書において、「取引者から受け付ける」とは、取引管理システム１０の各機能が、取引者が用いるユーザ端末４０〜ユーザ端末４２等のユーザ端末から各ユーザの取引者ＩＤにより取引者が特定された状態で指示や情報を受け付けることをいう。

図７は、取引管理情報記憶部１４８のデータ構成の一例を示す図である。
取引管理情報記憶部１４８は、取引ＩＤ欄、枝番欄、発注取引者ＩＤ欄、商品ＩＤ欄、発注数量欄、単価欄、発注先取引者ＩＤ欄、発送先取引者ＩＤ欄等を含む。さらに、取引管理情報記憶部１４８は、発注可能フラグ欄、請求形態欄、請求タイミング欄、請求可能フラグ欄、発送済フラグ欄、納入済フラグ欄等を含む。これらのフラグ欄は、後述する伝票発行処理部１２２が伝票を発行するタイミングを制御するため等に用いられる。取引管理情報生成部１２０は、発注者である下流取引者の下流取引者ＩＤを「発注取引者ＩＤ」として、発注先の中間取引者の中間取引者ＩＤを「発注先取引者ＩＤ」として記憶する。

また、本実施の形態において、発注管理部１１８は、取引設定情報記憶部１４４の商品流通モード欄にアクセスして、その下流取引者が対象取引者である取引設定情報について「商品受取」と設定されている場合、その下流取引者の下流取引者ＩＤを発送先取引者ＩＤとして取得する。一方、発注管理部１１８は、取引設定情報記憶部１４４の商品流通モード欄にアクセスして、その下流取引者が対象取引者である取引設定情報についてたとえば「直送」等、「商品受取」と設定されていない場合、その下流取引者の下流側の取引者が対象取引者である取引設定情報の商品流通モード欄を参照し、「商品受取」となっているか否かを判定する。ここで、商品流通モード欄を参照し、「商品受取」となっていれば、そのときの対象取引者の取引者ＩＤを発送先取引者ＩＤとして取得する。一方、ここで、「直送」等、「商品受取」と設定されていない場合、さらにその下流側の取引者の下流側の取引者が対象取引者である取引設定情報の商品流通モード欄を参照し、「商品受取」となっているか否かを判定する。発注管理部１１８は、この処理を繰り返し、対象取引者の商品流通モード欄の設定が「商品受取」となっている取引者の取引者ＩＤを発送先取引者ＩＤとして取得する処理を行う。

たとえば、図５に示した例では、対象取引者が取引者ＩＤ「ａ」の取引者の取引設定情報の商品流通モード欄の設定は「商品受取」となっている。そのため、発注管理部１１８は、取引者ＩＤ「ａ」の取引者と取引者ＩＤ「ｂ」の取引者との間の取引について、取引者ＩＤ「ａ」を発送先取引者ＩＤとして取得する。一方、対象取引者が取引者ＩＤ「ｂ」の取引者の取引設定情報の商品流通モード欄の設定は「直送」となっている。この場合、発注管理部１１８は、この取引者ＩＤ「ｂ」の取引者のさらに下流側の取引者ＩＤ「ａ」の取引者の取引設定情報の商品流通モード欄を参照し、「商品受取」となっているか否かを判定する。ここで、取引者ＩＤ「ａ」の取引者の取引設定情報の商品流通モード欄の設定は「商品受取」となっている。そのため、発注管理部１１８は、取引者ＩＤ「ｂ」の取引者と取引者ＩＤ「ｃ」の取引者との間の取引についても、取引者ＩＤ「ａ」を発送先取引者ＩＤとして取得する。

図８は、発注管理部１１８が下流取引者から商品の発注指示を受け付けた際の処理手順の一例を示すフローチャートである。

発注管理部１１８は、発注指示を受け付けると（ステップＳ１００のＹＥＳ）、取引ＩＤを発行する（ステップＳ１０２）。ここで、取引ＩＤは、他の取引の取引ＩＤと重複しない各取引を識別可能なものとすることができる。発注管理部１１８は、発行した取引ＩＤおよび取得した発注情報を取引管理情報生成部１２０に通知して取引管理情報生成部１２０に取引管理情報生成指示を行う（ステップＳ１０４）。この指示に基づき、取引管理情報生成部１２０は、取引管理情報を生成して取引管理情報記憶部１４８に記憶する。取引管理情報は、取引ＩＤ、発注取引者ＩＤ、商品ＩＤ、発注数量、販売価格（単価）、発注先取引者ＩＤ等を含む。また、本実施の形態において、図７を参照して説明したように、取引管理情報には、発注可能フラグ欄、請求形態欄、請求タイミング欄、請求可能フラグ欄、発送済フラグ欄、納入済フラグ欄も設けられた構成とすることができる。

このとき、下流取引者自身が発注指示を行っているので、発注管理部１１８は、取引管理情報の発注可能フラグ欄の発注可能フラグをオンとする（ステップＳ１０６）。

続いて、発注管理部１１８は、下流取引者ＩＤおよび商品ＩＤをキーとして取引設定情報記憶部１４４にアクセスして、これらのキーで特定される中間取引者である取引者の取引者ＩＤの発注管理モード欄の設定を確認し、上流側への発注処理を行うか否かを判定する（ステップＳ１０８）。発注管理部１１８は、発注管理モード欄に「発注要」と設定されている場合、上流側への発注処理が必要と判定する（ステップＳ１０８のＹＥＳ）。

発注管理部１１８は、上流側への発注処理が必要と判定した場合（ステップＳ１０８のＹＥＳ）、新たな取引ＩＤを発行する（ステップＳ１１０）。ここで、このように下流側での発注処理を契機として上流側への発注処理が必要と判定された場合、発注管理部１１８は、上流側の発注処理に対して、下流側の発注処理に対して発行した取引ＩＤに含まれる識別情報と同じ識別情報を含む取引ＩＤ、たとえば同じ識別情報にさらに枝番が付されたものを発行することができる。本実施の形態において、発注管理部１１８は、ステップＳ１０２で発行した取引ＩＤにも枝番を追加するとともに、新たな取引の取引ＩＤにもステップＳ１０２で発行した取引ＩＤに別の枝番を付したものを発行する。発注管理部１１８は、発行した取引ＩＤおよび取得した発注情報を取引管理情報生成部１２０に通知して取引管理情報生成部１２０に新たな取引管理情報生成指示を行う（ステップＳ１１２）。このとき、取引管理情報生成部１２０は、商品ＩＤおよび発注数量を下流側の取引管理情報から引き継いで用いることができる。

この後、発注管理部１１８は、上流側への自動発注処理を行えるか否かを判定する。まず、発注管理部１１８は、下流取引者ＩＤおよび商品ＩＤをキーとして取引設定情報記憶部１４４にアクセスして、これらのキーで特定される中間取引者である取引者の取引者ＩＤの上流取引者ＩＤ欄の設定を確認し、上流取引者ＩＤが設定されているか否かを判定する（ステップＳ１１４）。上流取引者ＩＤが設定されている場合（ステップＳ１１４のＹＥＳ）、発注管理部１１８は、価格記憶部１４６にアクセスして、下流取引者ＩＤとして中間取引者である取引者の取引者ＩＤ、取引者ＩＤとしてその上流取引者ＩＤ、および商品ＩＤが設定されている情報の販売価格（単価）が設定されているか否かを判定する（ステップＳ１１６）。

販売価格（単価）が設定されている場合（ステップＳ１１６のＹＥＳ）、発注管理部１１８は、下流取引者ＩＤおよび商品ＩＤをキーとして取引設定情報記憶部１４４にアクセスして、これらのキーで特定される中間取引者である取引者の取引者ＩＤの自動発注許可フラグ欄の設定を確認し、自動発注許可フラグがオンとなっているか否かを判定する（ステップＳ１１８）。自動発注許可フラグがオンとなっている場合（ステップＳ１１８のＹＥＳ）、ユーザに確認することなく自動発注処理を行ってよいということなので、ステップＳ１０６に進み、発注管理部１１８は、この取引管理情報の発注可能フラグをオンとする。なお、発注管理部１１８は、ステップＳ１１４でＹＥＳの場合に上流取引者ＩＤを取得するとともに、ステップＳ１１６でＹＥＳの場合に販売価格（単価）を取得し、それらを発注情報として取引管理情報生成部１２０に順次通知することができる。取引管理情報生成部１２０は、発注管理部１１８から通知された発注情報を取引管理情報に追加して取引管理情報記憶部１４８に記憶することができる。

ステップＳ１０６の後、上流側への発注処理が必要でないと判定するまで（ステップＳ１０８のＮＯ）、同様の処理を繰り返し、発注管理部１１８は、上流側において発注管理モードで発注要と設定されている取引者間の取引者について同様の発注処理を行う。

一方、ステップＳ１１４で上流取引者ＩＤが設定されていない場合（ステップＳ１１４のＮＯ）、ステップＳ１１６で販売価格（単価）が設定されていない場合（ステップＳ１１６のＮＯ）、またはステップＳ１１８で自動発注許可フラグがオンとなっていない場合（ステップＳ１１８のＮＯ）、発注管理部１１８は、自動発注処理を行うことができないため、発注先の取引者（ここでは中間取引者）への問合せ処理を行う（ステップＳ１２０）。この場合も、ステップＳ１１０において、取引ＩＤが発行されているため、発注管理部１１８は、中間取引者へ問合せをする際に取引ＩＤも提供することができる。これにより、後に中間取引者から発注情報の入力がある際に、取引管理情報の生成を容易にすることができる。

以上のように、各商品を販売する発注先の取引者がさらにその商品を発注する先の上流側の取引者の情報および当該上流側の取引者による販売価格を取引設定情報記憶部１４４および価格記憶部１４６に記憶させておくことにより、上流側への発注の取引管理情報が自動的に生成される構成とすることができる。また、自動発注可否フラグを設定しておくことにより、自動発注処理も行うことができる。

図９は、図８のステップＳ１２０の取引者への問合せを行った後に、発注管理部１１８がユーザである中間取引者から、発注情報の入力を受け付ける場合の処理手順の一例を示すフローチャートである。

ここで、中間取引者であるユーザが取引管理システム１０にログインした状態で、取引ＩＤの入力とともに、発注情報の入力指示があると（ステップＳ１２１のＹＥＳ）、発注管理部１１８は、ユーザから上流取引者ＩＤの入力、販売価格（単価）の入力等を発注情報として受け付ける（ステップＳ１２２のＹＥＳ、ステップＳ１２３のＹＥＳ）。発注管理部１１８は受け付けた発注情報を取引管理情報生成部１２０に通知し、取引管理情報生成部１２０に取引管理情報生成指示を行う（ステップＳ１２４）。また、ユーザから発注の可否を受け付け、上流側への発注許可が得られれば（ステップＳ１２５のＹＥＳ）、その取引管理情報の発注可能フラグをオンとする（ステップＳ１２６）。

図１０は、下流取引者（ＩＤ「ａ」）と中間取引者（ＩＤ「ｂ」）とに関する第１の取引管理情報１４８ａと中間取引者（ＩＤ「ｂ」）と上流取引者（ＩＤ「ｃ」）とに関する第２の取引管理情報１４８ｂとを模式的に示す図である。ここでは、図５を参照して説明したように、取引者ＩＤ「ａ」の取引者から取引者ＩＤ「ｂ」の取引者に商品の発注があり、取引者ＩＤ「ｂ」の取引者は仲介を行うのみで、取引者ＩＤ「ｂ」の取引者から取引者ＩＤ「ｃ」の取引者への商品の発注が引き続き自動的に行われ、商品は取引者ＩＤ「ｃ」の取引者から取引者ＩＤ「ａ」の取引者へ直送される場合を示す。

ここで、取引者ＩＤ「ａ」と取引者ＩＤ「ｂ」との間の第１の取引管理情報１４８ａの発注取引者ＩＤ欄、商品ＩＤ欄、発注数量欄、および単価欄の情報は、発注管理部１１８が受け付けた発注情報から取得することができる。ここでは配送先取引者ＩＤは「ａ」となる。また、本実施の形態において、取引者ＩＤ「ｂ」と取引者ＩＤ「ｃ」との間の第２の取引管理情報１４８ｂの商品ＩＤ欄、発注数量欄には、それぞれ第１の取引管理情報１４８ａと同様の情報が入力される。また、第２の取引管理情報１４８ｂの発注取引者ＩＤ欄には、第１の取引管理情報１４８ａの発注先取引者ＩＤ欄の情報が入力される。

また、この例において、図５を参照して説明したように、取引者ＩＤ「ｂ」の取引者の商品流通モードは「直送」となっている。そのため、発注管理部１１８は、その発注者の下流側の取引管理情報で設定されている配送先取引者ＩＤ、すなわち「ａ」を配送先取引者ＩＤとして設定する。

（発送・納入処理）
次に、本実施の形態の取引管理システム１０における発送・納入処理手順を説明する。
図２に戻り、納品管理部１２６は、発注先の取引者が発注された商品を発送したときに、当該取引者から発送済情報の入力を受け付ける。具体的には、納品管理部１２６は、発送済情報として、当該取引者から、取引ＩＤおよび当該取引者の取引者ＩＤ等を受け付ける。納品管理部１２６は、取引ＩＤおよび取引者ＩＤに基づき、取引管理情報記憶部１４８の該当する取引管理情報の発送済フラグ欄の発送済フラグをオンとする。

また、納品管理部１２６は、取引ＩＤおよび取引者ＩＤとに基づき、該当する取引管理情報を参照し、その取引管理情報の発送先取引者ＩＤと同じ発送先取引者ＩＤが発送先として指定された取引管理情報がさらに下流側に存在するか否かを判定する。下流側に同じ発送先取引者ＩＤが発送先として指定された取引管理情報がある場合、納品管理部１２６は、その取引管理情報の発送済フラグもオンとする。

図１１は、納品管理部１２６が、取引管理情報記憶部１４８の発送済フラグをオンとする処理手順の一例を示すフローチャートである。
たとえば商品を発送する上流取引者は、ユーザ端末４０等のユーザ端末から、ネットワーク５０を介して取引管理システム１０に情報を入力することができる。納品管理部１２６は、上流取引者の取引者ＩＤおよび取引ＩＤとともに、発送済であることを示す発送済情報の入力を受け付ける（ステップＳ１３０のＹＥＳ）。納品管理部１２６は、取引管理情報記憶部１４８にアクセスして、取引ＩＤと取引者ＩＤとに基づき、その上流取引者の取引者ＩＤが発注先となっている取引管理情報の発送済フラグをオンとする（ステップＳ１３２）。

つづいて、納品管理部１２６は、同様に取引管理情報記憶部１４８にアクセスして、その上流取引者の取引者ＩＤが発注先となっている取引管理情報の発送先取引者ＩＤが発注取引者ＩＤと同じか否かを判定する（ステップＳ１３４）。ここで、発送先取引者ＩＤと発注取引者ＩＤとが同じでない場合（ステップＳ１３４のＮＯ）、下流側の取引管理情報に移動して、その取引管理情報の発送済フラグをオンとして（ステップＳ１３２）、同様の処理を繰り返す。一方、ステップＳ１３４で、発送先取引者ＩＤと発注取引者ＩＤとが同じ場合（ステップＳ１３４のＹＥＳ）、処理を終了する。

たとえば、図１０を参照して説明した例では、取引者ＩＤ「ｂ」と取引者ＩＤ「ｃ」との間の第２の取引管理情報１４８ｂでは、発注取引者ＩＤは「ｂ」なのに対して発送先取引者ＩＤは「ａ」となっており、これらは異なっている。そのため、納品管理部１２６は、第２の取引管理情報１４８ｂの発送済フラグをオンとした後、下流側の第１の取引管理情報１４８ａの発送済フラグもオンとする。ここで、取引者ＩＤ「ａ」と取引者ＩＤ「ｂ」との間の第１の取引管理情報１４８ａでは、発注取引者ＩＤは「ａ」なのに対して発送先取引者ＩＤも「ａ」となっており、これらは同じである。そのため、ここで発送済フラグをオンとする処理を終了する。このような処理により、商品が中間取引者に発送されず、上流取引者から下流取引者へ直送されるような場合、上流取引者である取引者ＩＤ「ｃ」の取引者が発送済情報を入力するだけで、中間取引者である取引者ＩＤ「ｂ」の取引者が発送済情報等を入力することなく、第１の取引管理情報１４８ａの発送済フラグもオンとする処理を行うことができる。

この状態を図１２に示す。本実施の形態において、納品管理部１２６は、フラグをオンとするための発送済フラグとして、商品が発送された先の取引者の取引者ＩＤを用いることができる。ここでは、取引者ＩＤ「ｃ」の取引者から下流側の取引者ＩＤ「ａ」の取引者に商品が発送されるため、発送済フラグとして取引者ＩＤ「ａ」を取引管理情報記憶部１４８に記憶する。

また、納品管理部１２６は、発注者である取引者に商品が納入されたときに、当該取引者から納入済情報の入力を受け付ける。具体的には、納品管理部１２６は、納入済情報として、当該取引者から、納入済の指示とともに取引ＩＤ、当該取引者の取引者ＩＤおよびその商品を発送した取引者の取引者ＩＤ等を受け付ける。納品管理部１２６は、取引ＩＤおよび取引者ＩＤに基づき、取引管理情報記憶部１４８の該当する取引管理情報の納入済フラグ欄の納入済フラグをオンとする。

また、納品管理部１２６は、取引ＩＤおよび取引者ＩＤとに基づき、該当する取引管理情報を参照し、その取引管理情報の発送先取引者ＩＤと同じ発送先取引者ＩＤが発送先として指定された取引管理情報がさらに上流側に存在するか否かを判定する。上流側に同じ発送先取引者ＩＤが発送先として指定された取引管理情報がある場合、納品管理部１２６は、その取引管理情報の納入済フラグもオンとする。

図１３は、納品管理部１２６が、取引管理情報記憶部１４８の納入済フラグをオンとする処理手順の一例を示すフローチャートである。
たとえば商品が納入される下流取引者は、ユーザ端末４０等のユーザ端末から、ネットワーク５０を介して取引管理システム１０に情報を入力することができる。納品管理部１２６は、下流取引者の取引者ＩＤおよび取引ＩＤとともに、納入済であることを示す納入済情報の入力を受け付ける（ステップＳ１４０のＹＥＳ）。ここで、納入済情報は、その商品を発送した取引者の取引者ＩＤも含むものとすることができる。納品管理部１２６は、取引管理情報記憶部１４８にアクセスして、取引ＩＤと取引者ＩＤとに基づき、その下流取引者ＩＤが発注者となっている取引管理情報の納入済フラグをオンとする（ステップＳ１４２）。

つづいて、納品管理部１２６は、同様に取引管理情報記憶部１４８にアクセスして、その下流取引者の取引者ＩＤが発注者となっている取引管理情報の発注先取引者ＩＤがその商品を発送した取引者の取引者ＩＤと同じか否かを判定する（ステップＳ１４４）。ここで、発注先取引者ＩＤと発送した取引者の取引者ＩＤとが同じでない場合（ステップＳ１４４のＮＯ）、上流側の取引管理情報に移動して、その取引管理情報の納入済フラグをオンとして（ステップＳ１３２）、同様の処理を繰り返す。一方、ステップＳ１４４で、発注先取引者ＩＤと発送した取引者の取引者ＩＤとが同じ場合（ステップＳ１４４のＹＥＳ）、処理を終了する。

たとえば、図１０を参照して説明した例では、商品が上流取引者である取引者ＩＤ「ｃ」の取引者から発送された場合、取引者ＩＤ「ａ」と取引者ＩＤ「ｂ」との間の第１の取引管理情報１４８ａでは、発注先取引者ＩＤは「ｂ」なのに対して商品を発送した取引者の取引者ＩＤは「ｃ」で、これらは異なっている。そのため、納品管理部１２６は、第１の取引管理情報１４８ａの納入済フラグをオンとした後、上流側の第２の取引管理情報１４８ｂの納入済フラグもオンとする。ここで、取引者ＩＤ「ｂ」と取引者ＩＤ「ｃ」との間の第２の取引管理情報１４８ｂでは、発注先取引者ＩＤは「ｃ」なのに対して商品を発送した取引者の取引者ＩＤも「ｃ」で、これらは同じである。そのため、ここで納入済フラグをオンとする処理を終了する。このような処理により、商品が中間取引者に発送されず、上流取引者から下流取引者へ直送されるような場合、下流取引者である取引者ＩＤ「ａ」の取引者が納入済情報を入力するだけで、中間取引者である取引者ＩＤ「ｂ」の取引者が納入済情報等を入力することなく、第２の取引管理情報１４８ｂの納入済フラグもオンとする処理を行うことができる。

（伝票発行処理）
次に、本実施の形態の取引管理システム１０における伝票発行処理手順を説明する。
伝票発行処理部１２２は、商品の発注者から発注先への発注書（発注伝票）や、商品の発注先から発注者への請求書（請求伝票）や納品書（納品伝票）を発行する。また、伝票発行処理部１２２は、各取引者間での取引に基づき、商品を発注する側の下流取引者の仕入元帳、商品の発注を受け付ける側の売上元帳をそれぞれ発行することができる。伝票情報記憶部１５０は、発注書、納品書・請求書、仕入元帳、および売上元帳を発行するためのフォーマット等の伝票を発行するために必要なデータを記憶することができる。

伝票発行処理部１２２は、伝票発行処理部１２２は、発注管理部１１８が受け付けた発注の発注数量および発注先による販売価格に基づき、発注者から発注先への発注書を発行する。本実施の形態において、価格記憶部１４６は、商品ＩＤおよび上流取引者ＩＤに対応づけて上流取引者ＩＤで特定される上流取引者による商品の販売価格である第１の販売価格を記憶するとともに、商品ＩＤおよび中間取引者ＩＤに対応づけて当該中間取引者による商品の販売価格である第２の販売価格を記憶している。伝票発行処理部１２２は、発注管理部１１８が受け付けた発注数量および第２の販売価格に基づき、下流取引者から中間取引者への発注伝票を発行するとともに、発注管理部１１８が受け付けた発注数量および第１の販売価格に基づき、中間取引者から上流取引者への発注伝票を発行する。伝票発行処理部１２２は、発注管理部１１８が上流側への発注が必要と判定した場合に、発注管理部１１８が受け付けた発注数量および上流側の取引者による第１の販売価格に基づき、上流側の次の発注先への発注書も発行する。

伝票発行処理部１２２は、発注書を発行するために用いた販売数量および販売価格に基づき、下流側への請求書または納品書を発行する。本実施の形態において、同じ取引者間での発注書と請求書または納品書とは、同じデータを用いて発行される。つまり、本実施の形態において、伝票発行処理部１２２は、販売数量および販売価格を含むデータを用いて、発注書用のフォーマットに基づき上流側の取引者に提供するための発注書を発行するとともに、請求書または納品書用のフォーマットに基づき下流側の取引者に提供するための請求書または納品書を発行する。これにより、たとえば発注者がある発注先に発注を行った際に、発注として入力されたデータに基づき発注書が発行された場合は、同じデータを用いてその発注先から発注者への請求書または納品書を発行することができる。

同様に、本実施の形態において、同じ取引者間での仕入元帳と売上元帳とは、同じデータを用いて発行される。本実施の形態において、伝票発行処理部１２２は、発注伝票を発行するために用いた情報を蓄積して形成された仕入元帳または売上元帳を生成することができる。具体的には、伝票発行処理部１２２は、所定期間における各取引者間での取引管理情報を蓄積して記憶しておくことができる。伝票発行処理部１２２は、このような取引管理情報の蓄積データを用いて、仕入元帳用のフォーマットに基づき、この取引者間での取引に基づく商品を発注する側の下流取引者に提供するための仕入元帳を発行することができる。また、このような仕入元帳を発行した場合、伝票発行処理部１２２は、同じ蓄積データを用いて、売上元帳用のフォーマットに基づき、この取引者間での取引に基づく商品の発注を受け付ける側上流取引者に提供するための売上元帳を同時に発行することができる。

ここで、伝票を発行するとは、その伝票を、該当する取引者が閲覧可能となるようにすることである。伝票発行処理部１２２は、発注管理部１１８や納品管理部１２６によりいずれかの取引者の取引管理情報記憶部１４８の発注可能フラグ、発送済フラグ、または納入済フラグがオンとされるのに基づき、発注書、請求書、納品書等の伝票を該当する取引者が閲覧可能となるような処理を行う。

図１４は、伝票発行処理部１２２の処理手順の一例を示すフローチャートである。
発注管理部１１８は、取引管理情報記憶部１４８の取引管理情報の発注可能フラグをオンとした場合、取引ＩＤ（枝番がある場合は枝番含む）の通知とともに、伝票発行処理部１２２にその旨を通知する。また、納品管理部１２６は、取引管理情報記憶部１４８の取引管理情報の発送済フラグまたは納入済フラグをオンとした場合、取引ＩＤ（枝番がある場合は枝番含む）の通知とともに、伝票発行処理部１２２にその旨を通知する。

発注管理部１１８または納品管理部１２６から、発注可能フラグ、発送済フラグまたは納入済フラグをオンとしたとの通知があると（ステップＳ１５０のＹＥＳ）、伝票発行処理部１２２は、オンとされたフラグの種類に応じて処理を行う。

伝票発行処理部１２２は、そのフラグが発注可能フラグか否かを判定し（ステップＳ１５２）、発注可能フラグの場合（ステップＳ１５２のＹＥＳ）、その取引ＩＤで特定される取引管理情報に基づき発行された発注書を、発注先取引者ＩＤで特定される取引者が閲覧可能となるように処理する（ステップＳ１５４）。閲覧可能とした場合、伝票発行処理部１２２は、たとえば該当する取引者が自己のＩＤを入力してログインした場合に、その取引者のログイン画面にその伝票が表示されるように制御することができる。

本実施の形態において、図８のステップＳ１１８およびステップＳ１０６で説明したように、上流取引者への発注を自動で行う設定となっている場合は、取引管理情報が生成される際にその発注可能フラグもオンとなる。そのため、伝票発行処理部１２２は、発注管理部１１８が下流取引者からの発注を受け付けてすぐに中間取引者および上流取引者にそれぞれ下流取引者および中間取引者からの発注書が閲覧可能となるようにすることができる。これにより、中間取引者である取引者ＩＤ「ｂ」の取引者が処理を行うことなく、上流側の取引者ＩＤ「ｃ」が発注書を閲覧できるようにすることができる。

ステップＳ１５４の後、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報の請求タイミングを参照し、商品発注時が請求タイミングとして設定されているか否かを判定する（ステップＳ１７４）。ここで、商品発注時が請求タイミングとして設定されている場合（ステップＳ１７４のＹＥＳ）、伝票発行処理部１２２は、その取引管理情報の請求可能フラグをオンとする（ステップＳ１７６）。次いで、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報に基づき生成された請求書を発注取引者ＩＤで特定される取引者が閲覧可能となるように処理する（ステップＳ１７８）。

ステップＳ１５２でフラグが発注可能フラグでない場合（ステップＳ１５２のＮＯ）、伝票発行処理部１２２は、そのフラグが納入済フラグか否かを判定する（ステップＳ１５８）。納入済フラグの場合（ステップＳ１５８のＹＥＳ）、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報の請求タイミングを参照し、商品納入時が請求タイミングとして設定されているか否かを判定する（ステップＳ１６０）。ここで、商品納入時が請求タイミングとして設定されている場合（ステップＳ１６０のＹＥＳ）、伝票発行処理部１２２は、その取引管理情報の請求可能フラグをオンとする（ステップＳ１６４）。次いで、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報に基づき生成した納品書および請求書を発注取引者ＩＤで特定される取引者が閲覧可能となるように処理する（ステップＳ１６４）。このとき、伝票発行処理部１２２は、納品書と請求書とを兼用で生成することができる。

一方、ステップＳ１６０で、商品納入時が請求タイミングとして設定されていない場合（ステップＳ１６０のＮＯ）、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報に基づき生成した納品書を発注取引者ＩＤで特定される取引者が閲覧可能となるように処理する（ステップＳ１６８）。

次いで、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報の発注タイミングに基づき、請求タイミングとして、たとえば期末や月末等の締め請求が設定されているか否かを判定する（ステップＳ１７０）。締め請求が設定されている場合（ステップＳ１７０のＹＥＳ）、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報を請求書の蓄積情報としてたとえば伝票情報記憶部１５０に蓄積する処理を行う（ステップＳ１７２）。伝票発行処理部１２２は、伝票情報記憶部１５０に蓄積された請求書の蓄積情報を、たとえば期末等にユーザから指示を受け付けることにより、または期末等のタイミングを監視しておく等により、設定されたタイミングで該当する取引者に閲覧可能に提供することができる。

また、オンとされたフラグがステップＳ１５２で発注可能フラグでもなく（ステップＳ１５２のＮＯ）、ステップＳ１５８で納入済フラグでもない場合（ステップＳ１５８のＮＯ）、そのフラグは発送済フラグということになる。この場合もステップＳ１７４に進み、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報の請求タイミングを参照し、商品発送時が請求タイミングとして設定されているか否かを判定する（ステップＳ１７４）。ここで、商品発送時が請求タイミングとして設定されている場合（ステップＳ１７４のＹＥＳ）、伝票発行処理部１２２は、その取引管理情報の請求可能フラグをオンとする（ステップＳ１７６）。次いで、伝票発行処理部１２２は、その取引ＩＤで特定される取引管理情報に基づき生成された請求書を発注取引者ＩＤで特定される取引者が閲覧可能となるように処理する（ステップＳ１７８）。

以上のように、本実施の形態における伝票発行処理部１２２によれば、発注可能フラグ、発送済フラグ、または納入済フラグのいずれかがオンとされると、取引設定情報記憶部１４４に設定された請求形態、請求タイミングに応じて発注書、請求書、納品書等を該当する取引者が閲覧可能となる。上述したように、納品管理部１２６は、たとえば、商品が中間取引者に発送されず、上流取引者から下流取引者へ直送されるような場合、上流取引者が発送済情報を入力するだけで、中間取引者が発送済情報等を入力することなく、中間取引者と下流取引者との取引の取引管理情報の発送済フラグもオンとする処理を行う。また、このような場合、納品管理部１２６は、下流取引者が納入済情報を入力するだけで、中間取引者が納入済情報等を入力することなく、中間取引者と上流取引者との取引の取引管理情報の納入済フラグもオンとする処理を行うことができる。そのため、このような場合に、発送済フラグや納入済フラグがオンとされるのに引き続いて、伝票発行処理部１２２が適切なタイミングで自動的に発注書、請求書、納品書を発行することができる。

次に、伝票発行処理部１２２が生成する発注書および納品書の模式例を示す。図１５および図１６は、発注書および納品書を模式的に示す図である。
図１５（ａ）は、取引者ＩＤ「ａ」の「Ａ社」から取引者ＩＤ「ｂ」の「Ｂ社」に提供される発注書を示す図である。図１５（ｂ）は、取引者ＩＤ「ｂ」の「Ｂ社」から取引者ＩＤ「ａ」の「Ａ社」に提供される納品書を示す図である。ここで、破線で示した箇所以外は、発注書と納品書に含まれる情報は同じである。

同様に、図１６（ａ）は、取引者ＩＤ「ｂ」の「Ｂ社」から取引者ＩＤ「ｃ」の「Ｃ社」に提供される発注書を示す図である。図１６（ｂ）は、取引者ＩＤ「ｃ」の「Ｃ社」から取引者ＩＤ「ｂ」の「Ｂ社」に提供される納品書を示す図である。ここでも、破線で示した箇所以外は、発注書と納品書に含まれる情報は同じである。

以上のように、ある商品について、あるユーザがその商品を購入する先の上流取引者およびその上流取引者がその商品を販売する販売価格をシステムに登録しておくことにより、いずれかの取引者（下流取引者）から発注があった場合に、発注された商品の発注数量が変化しない場合は、その取引者から発注先の取引者（中間取引者）への発注書を生成するだけでなく、発注先の取引者からさらにその上流の取引者（上流取引者）への発注書も自動的に生成することができる。また、各取引者間の上流側の取引者に提供した発注書に用いたデータを各取引者間の下流側の取引者に提供する請求書または納品書のデータとして用いることができるので、請求書または納品書も簡易に提供することができる。

次に、物流状態管理部１２８の処理を説明する。
図２に戻り、物流状態管理部１２８は、取引管理情報記憶部１４８の取引管理情報にアクセスして、ある下流側の取引者に上流側の取引者からの商品が納入された後、その商品がその下流側の取引者からさらに下流側に発送されたか否か等の情報を管理して所定の取引者に提供する。これにより、上流側の取引者は、下流側の取引者の商品の出荷状態を把握することができ、次回に下流側の取引者から商品の発注がある発注予測をたてることができる。

たとえば、物流状況管理部１２８は、図１２を参照して説明した例で商品を発送した取引者ＩＤ「ｃ」の取引者に、商品を発送した先の取引者ＩＤ「ａ」の取引者にさらに下流側の取引者から商品の発注があったか否か、および発注があった場合の数量を提示することができる。

図１７は、物流状況管理部１２８が下流側の取引者から出荷された商品の数量を提示する処理手順を示すフローチャートである。
ユーザがログインして、上流側の取引で発送先取引者ＩＤ欄に記入された取引者ＩＤを入力すると（ステップＳ１９０）、物流状況管理部１２８は、その発送先取引者ＩＤを発注先取引者ＩＤとして含む取引管理情報があるか否かを判定する（ステップＳ１９２）。その発送先取引者ＩＤを発注先取引者ＩＤとして含む取引管理情報がある場合（ステップＳ１９２のＹＥＳ）、物流状況管理部１２８は、その取引管理情報において、商品が発送済か否かを判定する（ステップＳ１９４）。商品が発送済の場合（ステップＳ１９４のＹＥＳ）、物流状況管理部１２８は、その発注数量を取得する（ステップＳ１９６）。ステップＳ１９２に戻り、同様の処理を繰り返す。この後、物流状況管理部１２８は、取得した発注数量を取引者に提示する（ステップＳ１９８）。

以上のように、上流側の取引者において、自己の商品の発注者である取引者からさらに下流の取引者に発送された商品の数量を把握することにより、たとえばその下流側の取引者の在庫数量が減っている場合等に、下流側の取引者からの発注がある可能性が高い等の予測を立てることができる。これにより、上流側の取引者はさらに上流側への発注等を適切なタイミングで行うこと等ができる。

なお、以上では、ステップＳ１９４で商品が発送済か否かを判定したが、発注受付済か否かを判定するようにすることもできる。なお、物流状況管理部１２８は、取引者にこのような発送数量を提示する場合は、ユーザの取引者ＩＤに基づきユーザ認証を行い、そのユーザが発注先として指定された取引の発注者に関する情報のみを提示可能とするようにすることができる。

また、図１２に示したように、本実施の形態において、取引管理情報記憶部１４８は、商品の発注に基づき、各取引毎に、当該商品の商品ＩＤと、商品の発注者の取引者ＩＤと、当該商品を当該発注者に販売する発注先の取引者ＩＤと、当該発注先が当該商品を発送する先の発送先の取引者ＩＤと、発注数量と、当該発送先への商品の発送状態とを記憶している。商品の発送状態は、発注可能フラグ欄、発送済フラグ欄、納入済フラグ欄のフラグから把握することができる。

そのため、本実施の形態における取引管理システム１０において、取引管理情報記憶部１４８の取引管理情報を参照することにより、たとえば発送済フラグ（または発注可能フラグ）と発送数量とに基づき、どれだけの数量の商品がその取引者から下流の取引者に発送されたのかを把握することができる。物流状況管理部１２８は、取引者ＩＤおよび商品ＩＤの指定とともに、当該取引者ＩＤで指定される検索対象の取引者における商品の在庫数量の問合せに対し、取引管理情報記憶部１４８にアクセスして、当該検索対象の取引者が発注者および発送先として登録されている取引管理情報における発注数量から当該検索対象の取引者が発注先として登録されている取引管理情報における発注数量を減じる処理を行うことにより、当該検索対象の取引者における商品の在庫数量を算出して提示する。

図１８は、図１２に示した第１の取引管理情報１４８ａおよび第２の取引管理情報１４８ｂにおいて、下流取引者である取引ＩＤ「ａ」の取引者が、さらに下流側から商品の発注を受け、新たな取引を行う場合の取引管理情報記憶部１４８のデータ構成の例を示す図である。

ここで、取引者ＩＤは「ａ」の取引者がたとえば取引者ＩＤ「ｆ」の取引者から、商品ＩＤ「ｐ０００１」のこの商品について、発注数量「２０」の発注を受けたとする。この場合、取引管理情報生成部１２０は新たな取引ＩＤを付した第３の取引管理情報１４８ｃを生成し、新たな取引ＩＤ「ｔ０２０１」を付して取引管理情報記憶部１４８に記憶する。

このような第３の取引管理情報１４８ｃが生成されている場合、物流状況管理部１２８は、取引者ＩＤ「ａ」および商品ＩＤ「ｐ０００１」の指定の指定とともに、当該取引者ＩＤで指定される検索対象の取引者における商品の在庫数量の問合せに対し、取引管理情報記憶部１４８にアクセスして、当該検索対象の取引者が発注者および発送先として登録されている第１の取引管理情報１４８ａにおける発注数量「１００」から当該検索対象の取引者が発注先として登録されている第３の取引管理情報１４８ｃにおける発注数量「２０」を減じる処理を行うことにより、当該検索対象の取引者ＩＤ「ａ」の取引者における商品の在庫数量が「８０」であることを算出して、取引管理システム１０のユーザに提示することができる。

図１９は、図１８に示した取引管理情報記憶部１４８の構成の他の例を示す図である。
ここでは、取引管理情報生成部１２０は、取引の対象となる上流側の取引の取引ＩＤ「ｔ０１０１」も、元の取引ＩＤとして、各取引管理情報に対応づけて取引管理情報記憶部１４８に記憶することができる。このような構成とすることにより、物流状況管理部１２８は、上流側の取引の取引ＩＤに基づき、下流側の取引における商品の発送状態等を把握するような管理を行うことができる。物流状況管理部１２８は、商品を発送した先の取引者ＩＤ「ａ」の取引者にさらに下流側の取引者から商品の発注があったか否か、および発注があった場合の数量を提示することができる。

図２０は、物流状況管理部１２８が下流側の取引者から出荷された商品の数量を提示する処理手順を示すフローチャートである。
ユーザがログインして、上流側の取引での取引ＩＤを入力すると（ステップＳ２００）、物流状況管理部１２８は、その取引ＩＤを元の取引ＩＤとして含む取引管理情報があるか否かを判定する（ステップＳ２０２）。その取引ＩＤを元の取引ＩＤとして含む取引管理情報がある場合（ステップＳ２０２のＹＥＳ）、物流状況管理部１２８は、その取引管理情報において、商品が発送済か否かを判定する（ステップＳ２０４）。商品が発送済の場合（ステップＳ２０４のＹＥＳ）、物流状況管理部１２８は、その発注数量を取得する（ステップＳ２０６）。ステップＳ２０２に戻り、同様の処理を繰り返す。この後、物流状況管理部１２８は、取得した発注数量を取引者に提示する（ステップＳ２０８）。

図２１は、図１８や図１９に示した取引管理情報記憶部１４８の構成の他の例を示す図である。
ここでは、取引管理情報生成部１２０は、商品が取引者間で流通される度に、各商品ＩＤに対応づけて、商品ＩＤ付加情報として、その商品が流通された取引者の取引者ＩＤを取引管理情報記憶部１４８に記憶する構成とすることができる。

第１の取引管理情報１４８ａおよび第２の取引管理情報１４８ｂでは、商品ＩＤ付加情報として、「ｅ−ｄ−ｃ」が記憶されている。これは、取引者ＩＤ「ｃ」の取引者が保持している商品ＩＤ「ｐ０００１」の商品は、取引者ＩＤ「ｅ」の取引者、取引者ＩＤ「ｄ」の取引者、取引者ＩＤ「ｃ」の取引者の順に流通されたものであるということである。ここで、この商品が、取引者ＩＤ「ｃ」の取引者から取引者ＩＤ「ａ」の取引者へ発送された後、取引管理情報には、取引者ＩＤ「ａ」が付され、第３の取引管理情報１４８ｃの商品ＩＤ付加情報欄に示したように、商品ＩＤ付加情報として「ｅ−ｄ−ｃ−ａ」が記憶される構成とすることができる。このような構成とすることにより、各取引管理情報を確認することにより、どの取引者の間で流通されたかを簡易に把握することができる。また、ここでは商品を流通した取引者の取引者ＩＤのみを付す例を示したが、商品ＩＤ付加情報として、商品を製造する際に用いた原材料の取引者の取引者ＩＤも含む構成とすることもできる。その際、現在の商品ではなく原材料を取り扱った取引者の取引者ＩＤは、区別可能な符号等とともに付す構成とすることもできる。また、取引者が末端消費者である場合は、そのことも把握可能なマーク等を付す構成とすることができる。これにより、自分の商品はどういう人が購入しているか等の分析が可能になる。

さらに、取引管理情報記憶部１４８において、各取引管理情報のたとえば発送先取引者ＩＤ欄の情報は、関連する他の取引管理情報の発注先取引者ＩＤ欄の情報が記憶された取引管理情報記憶部１４８のアドレス情報を含む構成とすることもできる。このような構成とすることにより、上流側の取引者の情報と、下流側の取引者の情報とをリンク付けることができるので、在庫数量を提示する際の検索処理時間を短縮することができる。

また、物流状況管理部１２８は、いずれかの取引者からの商品の発注に基づき、上流側の取引者から下流側の取引者に商品が流通された場合に、商品を受け取った取引者の取引者ＩＤを商品ＩＤ付加情報の末尾に追加して、当該取引者が受け取った商品の数量を在庫数量として商品ＩＤおよび商品ＩＤ付加情報に対応付けて在庫情報記憶部１５２に記憶する。また、このとき、物流状況管理部１２８は、商品ＩＤと商品を発送した取引者の取引者ＩＤが末尾に追加されている商品ＩＤ付加情報とに対応付けられている在庫数量から発送された商品の数量を減じて在庫数量を更新する処理も行う。

この例を図２２に示す。図２２は、在庫情報記憶部１５２のデータ構成の一例を示す図である。
ここでは、物流状況管理部１２８は、いずれかの取引者に商品が納入され、納入済フラグがオンとされたタイミングでその取引者の取引者ＩＤを商品ＩＤ付加情報に追加して、納入された商品の在庫数量を更新する処理を行うようにすることができる。まず、図２２（ａ）に示した例では、商品ＩＤ「ｐ０００１」の商品につき、商品ＩＤ付加情報「ｅ−ｄ」の在庫数量が１０００、商品ＩＤ付加情報「ｅ−ｄ−ｃ」の在庫数量が５００となっている。ここで、取引者ＩＤ「ａ」の取引者から、取引者ＩＤ「ｃ」の取引者に発注数量「１００」の発注があったとする。この後、取引者ＩＤ「ｃ」の取引者から取引者ＩＤ「ａ」の取引者に商品が発送され、取引者ＩＤ「ａ」の取引者から、納入済の指示があり、納入済フラグがオンとされるとする。この場合、物流状況管理部１２８は、商品ＩＤ付加情報「ｅ−ｄ−ｃ」に「ａ」を付加した新たな商品ＩＤ付加情報「ｅ−ｄ−ｃ−ａ」に対応付けて在庫数量「１００」を記憶するとともに、商品ＩＤ付加情報「ｅ−ｄ−ｃ」の在庫数量を、更新前の在庫情報「５００」から「１００」を引いた「４００」に更新する。これにより在庫情報記憶部１５２を参照することにより、商品ＩＤ付加情報の末尾に付された取引者ＩＤの取引者のところに現在ある商品の在庫数量を容易に把握することができる。

図２２（ｃ）は、さらに、取引者ＩＤ「ｆ」の取引者から、取引者ＩＤ「ａ」の取引者に発注数量「２０」の発注があったとする。この後、取引者ＩＤ「ａ」の取引者から取引者ＩＤ「ｆ」の取引者に商品が発送され、取引者ＩＤ「ｆ」の取引者から、納入済の指示があり、納入済フラグがオンとされるとする。この場合、物流状況管理部１２８は、商品ＩＤ付加情報「ｅ−ｄ−ｃ−ａ」に「ｆ」を付加した新たな商品ＩＤ付加情報「ｅ−ｄ−ｃ−ａ−ｆ」に対応付けて在庫数量「２０」を記憶するとともに、商品ＩＤ付加情報「ｅ−ｄ−ｃ−ａ」の在庫数量を、更新前の在庫情報「１００」から「２０」を引いた「８０」に更新する。

さらに、物流状況管理部１２８は、自己の取引者ＩＤで認証された取引者から、当該取引者が下流側に発送した取引の物流状態の問合せを受け付け、その取引者に関連する商品の物流状態を提供する処理を行うことができる。たとえば、取引者ＩＤ「ｅ」の取引者から、当該取引者が下流側に発送した取引の物流状態の問合せを受け付けると、物流状況管理部１２８は、在庫情報記憶部１５２にアクセスして、取引者ＩＤ「ｅ」が商品ＩＤ付加情報に含まれる情報を抽出する。物流状況管理部１２８は、抽出した情報を当該取引者のユーザ端末に提供することができる。このとき、物流状況管理部１２８は、商品ＩＤ付加情報をそのままユーザに提供するのではなく、対象の取引者の取引者ＩＤと隣接する取引者ＩＤ以外の取引者ＩＤは、特定不明なマーク（たとえば「％」）に変換して当該取引者に提供するようにすることができる。これにより、取引者を特定せずに、流通経路における在庫状況を把握することができる。取引者が特定されないので、上流取引者や下流取引者は自らの在庫データを開示しやすくなり、全体の需要予測や納期予測等の精度を向上させることができる。

図２３を参照して説明する。ここでは、取引者ＩＤ「ｅ」の取引者の取引者ＩＤと、この取引者が直接商品の取引を行った取引者ＩＤ「ｄ」の取引者の取引者ＩＤ以外は、取引者ＩＤそのものではなく、「％」というマークが表示されている。このような構成により、取引者ＩＤ「ｅ」の取引者に、その取引者が直接取引を行っていない取引者の識別情報である取引者ＩＤ自体は提供されないが、その取引者が直接やりとりをしていないたとえば下流側の各段階の取引者のところにどの程度の商品の在庫があるか等を提示することができる。これにより、取引者の情報が他の取引者に知れ渡るのを防ぎつつ、各取引者が自己が取り扱う商品がどの程度流通されているかを把握することにより、受注予測や発注予定を立てる際の参考とすることができるようになる。また、ここでは示していないが、たとえば末端消費者は、末端消費者であることが識別可能な符号とともに表示するようにすることもできる。
ただし、ここで「％」というマークで示した個々の取引者自体の同意が得られた場合は、それらの取引者の取引者ＩＤを取引者ＩＤ「ｅ」の取引者に提示するようにしてもよい。

以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。

なお、以上の実施の形態においては、伝票発行処理部１２２が取引管理情報に基づき発注書を発行した後に、請求書または納品書を発行する例を示したが、伝票発行処理部１２２は、取引管理情報に基づき、請求書または納品書を単独で発行することもできる。つまり、本実施の形態において、価格記憶部１４６に各取引者間における販売価格を記憶させておくことにより、上流側から下流側への請求書が発行された場合に、納品書生成の手順と同様にして、販売価格の情報に基づき、さらに下流側への請求書も自動的に発行することができる。

また、以上の実施の形態においては、下流取引者、中間取引者、および上流取引者のいずれもが取引管理システム１０に取引者としてユーザ登録された取引者である場合を例として示した。しかし、本実施の形態における取引管理システム１０は、上流取引者がこの取引管理システムのユーザでない場合に適用することもできる。上流取引者がこのシステムのユーザである場合は、たとえば発注伝票を上流取引者がログインした状態で上流取引者のユーザ端末のディスプレイに表示される形態で提供することができる。また、上流取引者への商品の発注処理を電子的に自動で行うことができる。一方、上流取引者がこのシステムのユーザでない場合も、発注伝票が自動的に生成されるので、それをファクシミリ送付したり、メール添付したりして発注処理を簡易に行うことができる。

また、取引設定情報記憶部１４４は、対象の取引者（中間取引者に該当）の取引者ＩＤおよび商品ＩＤに対応付けて、当該取引者が保持する在庫数量を保持する構成とすることもできる。この場合、発注管理部１１８は、下流側からの商品の発注があった場合に、その発注数量に基づき、取引設定情報記憶部１４４の在庫数量から発注数量を減じる処理や、販売可能数量を変更する処理も行うことができる。

なお、以上の実施の形態においては、たとえば図５に示したように、取引設定情報記憶部１４４には、各取引者ＩＤに対応付けて、上流取引者ＩＤおよび下流取引者ＩＤを記憶する構成を示した。しかし、すべての商品について各取引者ＩＤに、発注先である上流取引者ＩＤおよび／または下流取引者ＩＤを登録しておく必要はない。上流取引者や下流取引者を特定したくない商品については、特定しないことを示すたとえば「ａｌｌ」等のコードを登録しておくこともできる。

（第２の実施の形態）
次に本発明の第２の実施の形態について説明する。本実施の形態は、第１の実施の形態に対して、検収を上げる基準（検収基準）として発送時か納品時かを管理できるように取引管理情報記憶部１４８の構成を図２４に示すように変更し、納品管理部１２６はこの検収基準をもとに請求可能フラグをセットして、伝票発行処理部１２２がこの請求可能フラグに基づいて請求書等の出力処理を行うようにしたものである。

以下、第１の実施の形態との違いを中心に説明する。なお、発注管理部など本実施の形態に記載していない事項は、第１の実施の形態と同様である。

（取引管理情報記憶部１４８のデータ構成）
第１の実施の形態と同様、本実施の形態においても、取引管理システム１０は、商品受取者（受取予定者を含む。）と商品発送者（発送予定者を含む。）を末端として、その間に所定数の取引仲介業者を挿入したパターン（取引パターン）を設け、この取引パターンを単位として、取引管理情報記憶部１４８を構成することにより、請求納品の管理と商品の物流管理を行う。

図２４に、本実施の形態による取引管理情報記憶部１４８のデータ構成例を示す。この例において取引パターン１は、商品受取者である下流取引者と商品発送者である上流取引者の２者間の取引を行うときのパターンであり、取引パターン２は、発注の仲介を行う一の中間取引者が介在したパターンである。仲介取引者の数によりパターンを設けるようにする。

図２１と図２４との主な違いは、図２１の請求タイミング，発送済フラグ，納入済フラグに替えて、それぞれ検収基準，発送日時，納入日時とし、運送日数欄を新たに設けたことである。

なお、運送日数は、上流取引者から下流取引者へ商品を運送するときに掛かる日数であり、予め一定の初期値がセットされている。

次に、この取引管理情報記憶部１４８のデータを用いた納品管理部１２６の処理について図面を参照しながら説明する。なお、取引管理情報記憶部１４８は、上流取引者のユーザ端末から送られてくる取引ＩＤ，発送日時を含む発送完了通知によって起動する発送時起動ルーチンと、定周期で起動する定周期起動ルーチンで構成されている。

（納品管理部１２６の処理手順）
図２５は、納品管理部１２６の発送時起動ルーチンの処理手順を示すフローチャートである。納品管理部の発送時起動ルーチンは、上述したように上流取引者の発送完了通知を受信することによって起動する。

このルーチンは、起動されると、まず、発送が完了した旨の通知である発送通知を取引ＩＤと共に下流の取引者へメール送信する（Ｓ３００）。なお、下流の取引者とは、当該取引ＩＤにおける上流取引者から見た下流の取引者の全てを含む趣旨であるが（上流の取引者も同様）、ステップＳ３００の場合は、中間取引者が存在する場合はその取引者と下流取引者（末端の取引者）の両方に通知しても良いし、下流取引者のみに通知をするようにしても良い。

そして、納品管理部１２６は、発送日時を取引管理情報記憶部１４８の発送日時欄に書き込む（Ｓ３０１）。そして、納品管理部１２６は、当該取引ＩＤの取引パターンを判定し（Ｓ３０２）、パターン２すなわち仲介取引者が存在する場合は、中間取引者の検収基準（すなわち上流取引者と中間取引者との間の取引の検収基準）を読み込み（Ｓ３０３）、読み込んだ検収基準が商品発送時の場合は（Ｓ３０４で「ＹＥＳ」）、請求可能フラグをセットし、読み込んだ検収基準が商品到着時（納品時）の場合は（Ｓ３０４で「ＮＯ」）、請求可能待ちリスト（以下、単に「待ちリスト」という。）に取引ＩＤを登録する（Ｓ３０６）。

次に下流取引業者の検収基準（すなわち、下流取引業者とその直近上位の取引業者との間の取引の検収基準）を読み込み（Ｓ３０７）、上記のステップＳ３０４〜Ｓ３０６と同様の処理を実行する（Ｓ３０８〜Ｓ３１０）。

一方、ステップＳ３０２の判定処理でパターン１の場合は、直ちにステップＳ３０７へ移行し、以降の処理を実行する。なお、取引パターン数が３以上の場合は、中間取引者の数に応じて、ステップＳ３０３〜Ｓ３０６の処理を追加するようにすれば良い。
以上が納品管理部１２６の発送時起動ルーチンの処理手順である。

商品受取予定者である下流取引者は、商品を受け取るとユーザ端末を介して受取情報を入力する。このとき、受け取った商品に問題がなければ、取引ＩＤと共に正常受取である旨を取引管理システム１０へ送る。一方、受け取った商品に異常があれば、異常状態に対応したエラーコードを取引管理システム１０へ送る。取引管理システム１０は、受信した情報を、取引管理情報記憶部１４８の当該取引ＩＤの納入日時欄に格納する。商品の異常としては、たとえば、数量不足や商品の品質不良などがある。

次に納品管理部１２６の定周期起動ルーチンの処理手順について、図２６に基づいて説明する。納品管理部の定周期起動ルーチンは、周期的に起動されると、待ちリストに登録されている最初の取引ＩＤを抽出する（Ｓ４００）。次に、取引管理情報記憶部１４８の下流取引者欄の納入日時欄のデータを読み込み（Ｓ４０１）、納入日時欄に日時データが保存されている場合は（Ｓ４０３で「ＹＥＳ」）、その取引ＩＤにおいて検収基準が商品到着時になっている列の請求可能フラグをセットして（Ｓ４０４）、待ちリストから当該取引ＩＤを削除する（Ｓ４０５）。一方、ステップＳ４０３において、エラーコードがセットされている場合は（Ｓ４０６で「ＹＥＳ」）、発送先である上流取引者へ通知する（Ｓ４０７）。ステップＳ４０６においてＮＯの場合、すなわち納入日時欄に日時もエラーコードもセットされていない場合は、現在日時と上流取引者の発送日時との差を計算し（Ｓ４０９）、その差が運送日数＋α（予め定められたマージン）よりも大きい場合は（Ｓ４１０で「ＹＥＳ」）、ステップＳ４０４へ移行する。以上の処理を待ちリストの全取引ＩＤについて実行する（Ｓ４１１，Ｓ４１２）。なお、ステップＳ４０５の直後に当該商品ＩＤにおける商品ＩＤ付加情報に当該下流取引者のＩＤを付加するステップを入れても良い。また、納入日時から発送日時を差し引いて運送日数を計算し、その値を同じ取引者間の運送日数として使用するようにしても良い。

図２７は、発注情報の流れと商品の流れの説明図である。たとえば取引ＩＤｔ０１０１において、取引者ａ，ｂ，ｃの順に発注情報が流れ、取引者ｃ（上流取引者）が商品の発送完了を、たとえば端末上に表示された発送ボタンを押すことによってシステム１０へ通知する。また、商品は、取引者ｃから取引者ａへ送られる。商品の物流情報は、商品ＩＤ付加情報として取引管理情報記憶部１４８に保存される。たとえば、図２４の例では、取引者ｃから送られた商品は、取引者ｅ−ｄ−ｃの順に取引された商品であることを意味する。取引者ａは、取引者ｃから送られてきた商品について検収可能フラグがセットされたときに、取引管理システム１０によってその商品ＩＤ付加情報に取引者ａ（商品受取者）の識別情報が付加され、商品ＩＤ付加情報は、ｅ−ｄ−ｃ−ａとなる。この付加のしかたは、物流のトレーサビリティ情報となる。一方、同様のケースで、取引者ｃから送られてきた商品について検収可能フラグがセットされたときに、上流取引者ｃから見て当該取引ＩＤの下流の取引者（中間取引者を含む。）の識別情報を全て付加することも可能である。この場合の商品ＩＤ付加情報は、ｅ−ｄ−ｃ−ｂ−ａとなる。これは納品のトレーサビリティ情報となる。納品の流れは、原則的に発注（発注を受ける側からすれば受注）の流れの逆なので、発注のトレーサビリティ情報と捉えることも可能である。この物流のトレーサビリティと納品（発注）のトレーサビリティを両方記憶しておけば、物流で問題になったときに、どのような取引が行われたかを解明することができ取引の安心安全を実効あるものにすることができる。

このように、取引管理システム１０は、取引者ｃから送られてくる商品発送完了通知と、取引者ａ（下流取引者）の入力データによって、検収の可否の判定や、商品の品質の管理および、物流管理を集中的、効率的に実行する。

たとえば、図１５，図１６に示した発注書、納品書の出力は、取引管理情報記憶部１４８に保存されている共通データから出力することができるが、その出力タイミングが問題となる。本実施の形態による納品管理部１２６の処理によって、検収基準に合わせて請求可能フラグをセットし、伝票発行処理部１２２によって請求形態に合わせて、適切に発行処理を行うことができる。なお、共通データの利用、すなわち取引におけるいわゆる表裏の関係は、発注書と納品書に限らず、たとえば、売上元帳と仕入元帳などにも適用することができる。但し、本発明の実施の形態の特徴は、上述したように適切なタイミングで、下流取引者の入力の負担を省き、これらの伝票や会計データを作成することができることである。

さらに、商品ＩＤが一致し、かつ上流取引者と下流取引者が一致するデータをリンクさせ、第１の実施の形態で説明した各取引者の在庫量を他の取引者へ開示することによって、需要予測などを効率的に行うことができる。また、商品ＩＤ付加情報によって、検収と物流の処理を連動させて、効率的かつ正確に物流管理を行うことができる。

たとえば、ある商品について、上流の各取引業者の在庫状況が見られることにより、発注の要否や発注時の納期の予測が可能になる。一方、ある商品について、下流の各取引業者の在庫状況が見られることにより、受注予測が可能になる。なお、このとき、在庫状況（在庫量、在庫数の増減傾向等）が見られる／見られないの設定、業者の特定の可／不可の設定、どの程度まで上流あるいは下流の業者の在庫状況を見られるようにするかは設定可能にしておくと良い。さらには、在庫量の見せ方（たとえば、多い，少ないなどの所謂感覚的，アナログ的な見せ方や、増減傾向を比率で見せるなど）を設定できるようにしても良い。

以上、本実施の形態によれば、検収基準によって、請求可能フラグの設定タイミングを変更可能にしたので、第１の実施の形態の効果に加えて、適切なタイミングで効率的に検収や伝票の発行を可能にすると共に、商品の品質管理や物流管理を効率的に行うことが可能になる。

たとえば、取引パターン２において、インターネットショッピングなどのポータルサイトを運営する業者を中間取引者とし、そのサイトを利用して商品を購入する者を下流取引者、そのサイトに対して商品情報を掲載する商品販売業者を上流取引者とし、下流取引者と中間取引者との間は、検収基準を発送時とし、中間取引者と上流取引者を納品時基準にすることによって、エスクローとしての機能を容易に実現することができる。

また、商品納品時に下流取引者が商品の異常（数量不足や品質不良など）を発見したときに、その異常を登録することによって、中間取引者は、中間取引者と上流取引者との間の検収前に上流取引者に注意し、再送などを促すことができるので、簡便なＤＢ構造によって商品の品質を担保することができる。

また、商品ＩＤと、商品のロット番号（あるいは取引ＩＤ）と、商品ＩＤ付加情報とを連続的に繋げたバーコードやＱＲコード（登録商標、以下同様）等の識別コードを物流としてのトレーサビリティ情報として商品に添付し、あるいは当該トレーサビリティ情報をＩＣチップに格納して商品に添付して取引を行うようにしても良い。そして、上流取引者は、商品発送時にこのＱＲコード（物流としてのトレーサビリティ情報）をＱＲコードリーダー等の読み取り手段で読み取って、取引管理システム１０へ送信する。取引管理情報記憶部１４８では、取引ＩＤ、あるいは、商品ＩＤとロット番号（図示せず）と商品ＩＤ付加情報とで取引を特定できるようにしておき、納品管理部１２６は、上流取引者から送られてきた物流としてのトレーサビリティ情報から取引を特定して、図２５、図２６に記載した処理手順で請求可能フラグのセット等の処理を行い、伝票発行処理部１２２によって請求書等の発行処理を行う。これにより、商品発送後は、各取引者は、商品に付された物流のトレーサビリティ情報を単に読み取ることによって、請求書等の取引に必要な書類の発行を行うことができ大幅な省力化を図ることができる。また、商品に添付された物流のトレーサビリティ情報を逐次更新していくことにより、その商品のみによってどのように物流が行われたかを把握することが可能になる。

なお、本発明の取引管理システムは、分散型システムとして実現することができる。
たとえば、上流の取引が異なるサーバで実行されている場合は、取引管理情報記憶部１４８の各データを当該サーバのデータフォーマットにデータ変換をして、データ連携を行うことによって、分散処理を実現することができる。

取引パターン１，２は、取引の実情に応じて適宜組み合わせて用いることができることは既に述べたが、各パターンのデータ構造を適宜変更して使用することもできる。たとえば、図２４の取引パターン２の例では、上流取引者（ｃ）は、中間取引者（ｂ）を介して受けた注文に対して、上流取引者（ｃ）が当該注文に係る商品を下流取引者（ａ）へ直送することとしたが、直送か否かを表すフラグ設定するカラムを設けて、上流取引者（ｃ）は、当該フラグがセットされていれば下流取引者（ａ）に直送し、当該フラグがセットされていない場合は、中間取引者（ｂ）へ送付する。このフラグを中間取引者（ｂ）がセット可能にすることによって、より効率の良い取引管理を実現することができる。

尤も、上記のように、取引パターン２において、直送しないような場合は、下流取引者（ａ）と中間取引者（ｂ）との間で取引パターン１のデータ構造を用い、さらに、中間取引者（ｂ）と上流取引者（ｃ）との間で取引パターン１のデータ構造を用いて、それぞれ取引を完結させるようにすることもできる。このとき、取引ＩＤは共通とし、枝番で下流−中間の取引か、中間−上流の取引かを区別するようにしても良い。このようにパターン１のデータ構造に枝番の欄を設けることによっても、中間取引者が複数の注文品を一括して発送するというような取引の管理を効率よく行うことができる。

上記の各実施の形態は、主に商品の取引を例に説明したが、役務の提供についても適用可能なことは明らかである。例えば図１８，図１９，図２１，図２４においては、次の各用語は括弧書きの用語の意味も含んでいる。商品（役務）、商品ＩＤ（役務ＩＤ）、発注数量（工数）、発送（納品）、納入日時（検収日時）、運送日数(検収日数、または受入試験日数)、商品発送時（納品時）、商品到着時（検収時）等である。

たとえば、下流取引者（ａ）から上流取引者（ｂ）に対して、プログラムの開発（役務）を委託するような場合は、取引パターン１を用いて、発注数量（工数）と単価（工数単価）によって定まる費用が記載された発注書（契約書も含まれる）が発行され、設定された検収基準によって、納品時あるいは検収時に上流取引者（ｂ）から下流取引者（ａ）に対して請求書が発行される。このとき、工数と単価を別々に設定しても良いし、開発費用全体として、いずれかのカラム（たとえば「発注数量」欄）に設定し、他のカラム（たとえば「単価」欄）は、固定値（たとえば「１」）に設定しておくようにしても良い。また、ネット業者等が委託サービスを仲介するような場合は、取引パターン２を用いて、効率良く取引を管理することができる。

１０ 取引管理システム
２４ 送受信部
２６ 中央演算処理部
２８ データ記憶部
４０、４２、４４ ユーザ端末
５０ ネットワーク
１１２ 送受信処理部
１１４ 設定情報受付部
１１８ 発注管理部
１２０ 取引管理情報生成部
１２２ 伝票発行処理部
１２６ 納品管理部
１２８ 物流状況管理部
１４０ 商品情報記憶部
１４２ 取引者情報記憶部
１４４ 取引設定情報記憶部
１４６ 価格記憶部
１４８ 取引管理情報記憶部
１５０ 伝票情報記憶部
１５２ 在庫情報記憶部

Claims (8)

1. 中間取引者の中間取引者ＩＤおよび商品ＩＤに対応づけて、当該中間取引者が当該商品ＩＤで特定される商品を購入する上流取引者ＩＤを記憶する取引設定情報記憶部と、
   前記商品ＩＤおよび前記上流取引者ＩＤに対応づけて前記上流取引者ＩＤで特定される上流取引者による前記商品の販売価格である第１の販売価格を記憶するとともに、前記商品ＩＤおよび前記中間取引者ＩＤに対応づけて当該中間取引者による前記商品の販売価格である第２の販売価格を記憶する価格記憶部と、
   前記中間取引者が前記商品を販売する下流取引者から、前記商品ＩＤ、当該下流取引者の下流取引者ＩＤ、および前記商品の発注数量の入力とともに、前記中間取引者への前記商品の発注を受け付ける発注管理部と、
   前記発注管理部が受け付けた前記発注数量および前記第２の販売価格に基づき、前記下流取引者から前記中間取引者への発注伝票を発行するとともに、前記発注管理部が受け付けた前記発注数量および前記第１の販売価格に基づき、前記中間取引者から前記上流取引者への発注伝票を発行する伝票発行処理部と、
   を含む取引管理システム。
2. 請求項１に記載の取引管理システムにおいて、
   前記伝票発行処理部は、前記中間取引者から前記上流取引者への前記発注伝票を発行するために用いた前記発注数量および前記第１の販売価格に基づき、前記上流取引者から前記中間取引者への請求伝票または納品伝票を発行するとともに、前記下流取引者から前記中間取引者への前記発注伝票を発行するために用いた前記発注数量および前記第２の販売価格に基づき、前記中間取引者から前記下流取引者への請求伝票または納品伝票を発行する取引管理システム。
3. 請求項１または２に記載の取引管理システムにおいて、
   前記取引設定情報記憶部は、前記中間取引者ＩＤ、前記商品ＩＤおよび前記上流取引者ＩＤに対応づけて、前記中間取引者ＩＤで特定される中間取引者への商品の発注があった場合に当該中間取引者から前記上流取引者ＩＤで特定される上流取引者へのさらなる発注の要否および自動発注の可否の設定を記憶し、
   前記発注管理部は、前記下流取引者から前記中間取引者への商品の発注を受け付けた場合に、前記下流取引者から前記中間取引者への発注処理を可能とする発注可能フラグをオンとするとともに、前記取引設定情報記憶部にアクセスして前記上流取引者へのさらなる発注の要否および自動発注の可否の設定に基づき、さらなる発注が必要で自動発注が可能と設定されている場合に、前記中間取引者から前記上流取引者への発注処理を可能とする発注可能フラグをオンとする処理を行い、
   前記伝票発行処理部は、前記発注管理部により前記下流取引者から前記中間取引者への発注処理を可能とする発注可能フラグがオンとされた場合に、前記下流取引者から前記中間取引者への発注伝票を発行するとともに、前記発注管理部により前記中間取引者から前記上流取引者への発注処理を可能とする発注可能フラグをオンとされた場合に、前記中間取引者から前記上流取引者への発注伝票を発行する取引管理システム。
4. 請求項１から３いずれかに記載の取引管理システムにおいて、
   発注のあった商品について、当該商品の商品ＩＤと、商品の発注者の取引者ＩＤと、当該商品を当該発注者に販売する発注先の取引者ＩＤと、当該発注先が当該商品を発送する先の発送先の取引者ＩＤと、発注数量と、当該発送先への商品の発送状態とを示す取引管理情報を、複数の取引毎に記憶する前記取引管理情報記憶部と、
   取引者ＩＤおよび商品ＩＤの指定の指定とともに、当該取引者ＩＤで指定される検索対象の取引者における前記商品の在庫数量の問合せに対し、前記取引管理情報記憶部にアクセスして、当該検索対象の取引者が発注者および発送先として登録されている取引管理情報における前記発注数量から当該検索対象の取引者が発注先として登録されている取引管理情報における前記発注数量を減じる処理を行うことにより、当該検索対象の取引者における前記商品の在庫数量を算出して提示する物流状況管理部をさらに含む取引管理システム。
5. 請求項１から４いずれかに記載の取引管理システムにおいて、
   上流取引者の端末から送られてくる取引ＩＤと発送完了済み通知を受けて、該取引ＩＤの各取引者間における取引の検収基準が発送時検収か、納品時検収かを判定し、発送時検収の場合は、当該取引者間の請求可能フラグをオンにする一方、納品時検収の場合は待ちリストに登録し、その後下流取引者の端末から商品受領日付送られてきた場合は、その日付を格納し、周期的に当該待ちリストに登録されている取引ＩＤについて、商品受取日付が格納されているか否かを判定し、商品受領日付が書き込まれている場合は、当該取引ＩＤの納品時検収の取引者間における取引の請求可能フラグをオンにする納期管理部を備え、
   前記伝票発行処理部は、請求形態に基づいて、都度請求の場合は直ちに、締め請求の場合は締め日に、請求可能フラグがオンになっている取引についてのみ伝票データを作成することを特徴とする取引管理システム。
6. 請求項４または５に記載の取引管理システムにおいて、
   前記取引管理情報記憶部は、いずれかの前記上流取引者から、前記中間取引者または前記下流取引者に商品が発送された場合に、発送されたことを示す情報として、当該商品が発送された先の前記中間取引者または前記下流取引者の取引者ＩＤを前記取引管理情報として記憶する取引管理システム。
7. 請求項１から６いずれかに記載の取引管理システムにおいて、
   前記伝票発行処理部は、前記発注伝票を発行するために用いた情報を蓄積して形成された仕入元帳または売上元帳を生成する取引管理システム。
8. コンピュータを、
   中間取引者の中間取引者ＩＤおよび商品ＩＤに対応づけて、当該中間取引者が当該商品ＩＤで特定される商品を購入する上流取引者ＩＤを記憶する取引設定情報記憶手段、
   前記商品ＩＤおよび前記上流取引者ＩＤに対応づけて前記上流取引者ＩＤで特定される上流取引者による前記商品の販売価格である第１の販売価格を記憶するとともに、前記商品ＩＤおよび前記中間取引者ＩＤに対応づけて当該中間取引者による前記商品の販売価格である第２の販売価格を記憶する価格記憶手段、
   前記中間取引者が前記商品を販売する下流取引者から、前記商品ＩＤ、当該下流取引者の下流取引者ＩＤ、および前記商品の発注数量の入力とともに、前記商品の発注を受け付ける発注受付手段、
   前記発注管理部が受け付けた前記発注数量および前記第２の販売価格に基づき、前記下流取引者から前記中間取引者への発注伝票を発行するとともに、前記発注管理部が受け付けた前記発注数量および前記第１の販売価格に基づき、前記中間取引者から前記上流取引者への発注伝票を発行する伝票発行手段、
   として機能させる取引管理プログラム。

Images