首页 / 专利库 / 商业 / 电子商务 / 出力制御プログラム、出力制御方法および出力制御装置

制御プログラム、出力制御方法および出力制御装置

阅读:870发布:2023-05-26

专利汇可以提供制御プログラム、出力制御方法および出力制御装置专利检索,专利查询,专利分析的服务。并且【課題】電子商取引を実現するシステムを使用するときの利便性を向上させることを目的とする。 【解決手段】出 力 制御装置は、複数の取引先との商取引に利用されるアプリケーションにおける、前記複数の取引先それぞれに対応する定義情報を取得し、取得した複数の前記定義情報の比較結果に応じて、特定の出力画面における出力項目が一致する取引先に関する出力情報を集約して出力する制御を行う制御部、を備えることを特徴とする。 【選択図】図2,下面是制御プログラム、出力制御方法および出力制御装置专利的具体信息内容。

コンピュータに、 複数の取引先との商取引に利用されるアプリケーションにおける、前記複数の取引先それぞれに対応する定義情報を取得する処理、 取得した複数の前記定義情報の比較結果に応じて、特定の出画面における出力項目が一致する取引先に関する出力情報を集約して出力する処理、 を実行させることを特徴とする出力制御プログラム。前記コンピュータに、 前記出力情報を集約して出力する処理において、前記特定の出力画面における出力項目が一致し、且つ該出力項目の順序が一致する取引先に関する出力情報を集約して出力する処理、 を実行させることを特徴とする請求項1記載の出力制御プログラム。前記コンピュータに、 前記複数の取引先に共通する第1機能を制御する第1制御情報と、前記複数の取引先のそれぞれの固有の第2機能を制御する第2制御情報と、を異なる記憶領域に記憶する記憶部のうち前記第2制御情報を参照して、前記取引先ごとに異なる制御を行わせる処理、 を実行させることを特徴とする請求項1または2記載の出力制御プログラム。前記コンピュータに、 前記第1制御情報に前記第2制御情報が設定されているとき、前記第1制御情報が前記第2制御情報を前記記憶部から読み出して、前記取引先ごとに異なる制御を行わせる処理、 を実行させることを特徴とする請求項3記載の出力制御プログラム。コンピュータが、 複数の取引先との商取引に利用されるアプリケーションにおける、前記複数の取引先それぞれに対応する定義情報を取得する処理、 取得した複数の前記定義情報の比較結果に応じて、特定の出力画面における出力項目が一致する取引先に関する出力情報を集約して出力する処理、 を実行することを特徴とする出力制御方法。複数の取引先との商取引に利用されるアプリケーションにおける、前記複数の取引先それぞれに対応する定義情報を取得し、取得した複数の前記定義情報の比較結果に応じて、特定の出力画面における出力項目が一致する取引先に関する出力情報を集約して出力する制御を行う制御部、 を備えることを特徴とする出力制御装置。

说明书全文

本発明は、制御プログラム、出力制御方法および出力制御装置に関する。

電子商取引を実現するシステムとして、Web-electronic Data Interchange(WebEDI)を利用したシステムが用いられている。関連する技術として、EDIを利用したデータ管理システムに関する技術が提案されている(例えば、特許文献1参照)。

特許文献1の技術では、管理対象のレコードのデータ項目名と、データ項目名を一意に示す列IDとを予め特定して静的に格納する列管理テーブルと、レコードを一意に示す行IDを格納する行管理テーブルとを備えている。また、特許文献1の技術は、列管理テーブルと行管理テーブルとを結合することにより動的に作成される値管理テーブルを備える。

特開2007−213551号公報

サプライヤが操作する端末には、WebEDIが提供する画面が表示される。サプライヤは、この画面に基づいて、端末を操作して、バイヤとの間で取引を行う。WebEDIが提供する画面は、バイヤによって異なる。

サプライヤが複数のバイヤと取引を行う場合、サプライヤは端末を操作して、バイヤごとに画面を切り替える。従って、サプライヤは、この切り替え操作を行う必要があるため、サプライヤがWebEDIを利用するときの利便性が低下する。

また、複数のバイヤの取引に関する情報を1つの画面に一括的に表示する場合、バイヤによって、取引で使用する情報の項目が異なると、画面に多くの項目が表示される。このため、画面の視認性や操作性が低下し、サプライヤがWebEDIを利用するときの利便性が低下する。

1つの側面として、本発明は、電子商取引を実現するシステムを使用するときの利便性を向上させることを目的とする。

1つの態様では、出力制御プログラムは、コンピュータに、複数の取引先との商取引に利用されるアプリケーションにおける、前記複数の取引先それぞれに対応する定義情報を取得する処理、取得した複数の前記定義情報の比較結果に応じて、特定の出力画面における出力項目が一致する取引先に関する出力情報を集約して出力する処理、を実行させることを特徴とする。

1つの側面によれば、電子商取引を実現するシステムを使用するときの利便性を向上させることができる。

システムの一例を示す図である。

EDIサーバの一例を示す機能ブロック図である。

サプライヤ端末の一例を示す機能ブロック図である。

各種テーブルの一例を示す図(その1)である。

各種テーブルの一例を示す図(その2)である。

取引情報の集約の一例を説明する図である。

固有機能の呼び出しの一例を説明する図である。

取引先選択画面の一例を示す画面例(その1)である。

取引一覧画面の一例を示す画面例(その1)である。

取引先選択画面の一例を示す画面例(その2)である。

取引一覧画面の一例を示す画面例(その2)である。

取引一覧画面の他の例を示す画面例である。

印刷された注文書の一例を示す図(その1)である。

印刷された注文書の一例を示す図(その2)である。

データ蓄積処理の一例を示すフローチャートである。

情報出力処理の一例を示すフローチャートである。

判定処理の一例を示すフローチャートである。

機能実行処理の一例を示すフローチャートである。

EDIサーバのハードウェア構成の一例を示す図である。

サプライヤ端末のハードウェア構成の一例を示す図である。

以下、図面を参照して、実施形態について説明する。実施形態では、電子商取引を実現するシステムとして、WebEDIシステムを適用した例について説明する。ただし、電子商取引を実現するシステムは、WebEDIには限定されない。

実施形態では、WebEDIを利用した電子商取引(以下、単に取引と称することもある)は、購買業務であるものとする。ただし、取引は購買業務には限定されない。取引は、バイヤとサプライヤとの間で行われる。

サプライヤは、取引の対象を供給する供給元である。バイヤは、取引の対象を購買する購買側である。バイヤは、サプライヤから見ると、サプライヤの取引先になる。以下、バイヤを供給元、サプライヤを取引先と称することがある。

図1は、WebEDIを適用したシステム1の一例を示している。システム1において、バイヤ端末2A〜2C(以下、総称して、バイヤ端末2と称することもある)とEDIサーバ3とは第1ネットワーク5により接続されている。第1ネットワーク5は、例えば、インターネット網であってもよい。

EDIサーバ3とサプライヤ端末4A〜4C(以下、総称して、サプライヤ端末4と称することもある)とは第2ネットワーク6により接続されている。第2ネットワーク6は、例えばインターネット網であってもよい。第1ネットワーク5と第2ネットワーク6とは同じネットワークであってもよい。

バイヤ端末2は、バイヤが取引を行うときに使用する端末である。バイヤ端末2の数は、3つには限定されない。実施形態では、バイヤ端末2と1つの企業とが対応しているものとして説明するが、1つの企業が複数のバイヤ端末2と対応してもよい。

EDIサーバ3は、WebEDIを実現するコンピュータである。EDIサーバ3は、WebEDIの機能を実現するアプリケーションを実行する。このアプリケーションが実行されることにより、バイヤ端末2とサプライヤ端末4との間で、WebEDIを利用した電子商取引が行われる。

サプライヤ端末4は、サプライヤが取引を行うときに使用する端末である。サプライヤ端末4の数は、3つには限定されない。実施形態では、サプライヤ端末4と1つの企業とが対応しているものとして説明するが、1つの企業が複数のサプライヤ端末4と対応してもよい。

次に、図2を参照して、EDIサーバ3の一例について説明する。EDIサーバ3は、第1制御部11と第1通信部12とアプリケーション記憶部13と機能記憶部14とデータベース15とを備えるコンピュータである。EDIサーバ3は、出力制御装置の一例である。

第1制御部11は、EDIサーバ3の各種処理を行う。第1通信部12は、第1ネットワーク5および第2ネットワーク6と通信を行う。アプリケーション記憶部13は、EDIサーバ3の機能を実現するアプリケーションを記憶する。

第1制御部11は、アプリケーション記憶部13に記憶されているアプリケーションを実行する。実施形態の処理を実現する出力制御プログラムは、アプリケーションに含まれる。

機能記憶部14は、アプリケーションが規定する各種の機能を記憶する。機能記憶部14は、各バイヤに共通した共通機能21とバイヤごとの固有の固有機能22A〜22Cとを記憶する。以下、固有機能22A〜22Cを総称して、固有機能22と称することがある。

共通機能21としては、例えば、画面の呼び出しや帳票作成等の機能がある。これらの機能は、各バイヤ端末2で共通である。共通機能21は第1機能の一例である。共通機能21は、所定の情報で実現される。例えば、共通機能21は、ソースコードで表される。共通機能21は、第1制御情報の一例である。

固有機能22は、バイヤごとに規定される所定の情報である。固有機能22は、第2機能の一例である。例えば、固有機能22は、ソースコードで表される。固有機能22は、第2制御情報の一例である。

例えば、取引が注文である場合、バイヤによって、注文の変更方法が異なる場合がある。また、取引が出荷である場合、バイヤによって、出荷方法が異なる場合がある。また、帳票作成を行うとき、帳票の形式がバイヤによって異なる場合がある。

第1制御部11がアプリケーションに規定される共通機能21を実行しているときに、共通機能21が固有機能22を呼び出したとする。第1制御部11は、呼び出された固有機能22を実行する。

例えば、第1制御部11が共通機能21として帳票作成の機能を実行しているときに、共通機能21は固有機能22を呼び出す。第1制御部11は、取引の処理を行っているバイヤの情報を認識しているため、バイヤに対応した帳票形式の固有機能22を呼び出す。これにより、取引の処理を行っているバイヤに応じた帳票形式の帳票が作成される。

従って、第1制御部11が固有機能22を実行することで、バイヤごとに異なる制御を行うことができる。

実施形態では、共通機能21のソースコードとバイヤごとの各固有機能22のソースコードとは、それぞれ分離されているものとする。つまり、実施形態では、共通機能21のソースコードと各固有機能22のそれぞれのソースコードとは、機能記憶部14の異なる記憶領域に記憶される。

このため、共通機能21と各固有機能22とは別個のソースコードとして開発されるため、開発の保守性が向上する。

次に、データベース15について説明する。データベース15は、各種のテーブルを記憶する。データベース15は、購買データテーブル31とフォーマットテーブル32と取引実績テーブル33と定義情報テーブル34と定義情報識別テーブル35とを記憶する。

購買データテーブル31は、EDIサーバ3がバイヤ端末2から受信する各購買データを記憶する。購買データは、バイヤ端末2がEDIサーバ3に送信する取引に関するデータである。

フォーマットテーブル32は、バイヤごとに固有機能22を特定する情報を記憶する。実施形態では、フォーマットテーブル32は、バイヤと取引種別とにより特定される固有機能22の名称を記憶する。

取引実績テーブル33は、サプライヤごとに取引実績のあるバイヤの情報を記憶する。EDIサーバ3は、サプライヤとバイヤとの間で行われる取引を認識している。例えば、サプライヤとバイヤとの間に新たな取引が発生したことをEDIサーバ3が認識した場合、第1制御部11は、取引実績テーブル33の内容を更新する。

定義情報テーブル34は、バイヤごとの定義情報を記憶する。定義情報は、取引に使用される項目を定義した情報である。定義情報は、データレイアウトとも称される。購買データは、定義情報に基づいている。

定義情報識別テーブル35は、バイヤと定義情報とIDとの対応関係を記憶する。IDはIdentificationの略称である。定義情報識別テーブル35の対応関係は、予めデータベース15に記憶されている。

<サプライヤ端末の一例> 次に、図3を参照して、サプライヤ端末4の一例について説明する。サプライヤ端末4は、第2制御部41と第2通信部42と画面制御部43と画面部44と操作認識部45と印刷制御部46とを備えている。

第2制御部41は、サプライヤ端末4の全体の制御を行う。第2通信部42は、第2ネットワーク6を介して、EDIサーバ3と通信を行う。画面制御部43は、画面部44に表示される画面の制御を行う。

操作認識部45は、操作デバイス220と接続される。操作デバイス220は、例えばマウスやキーボード等である。操作認識部45は、操作デバイス220による操作を受け付ける。実施形態では、操作デバイス220は、マウスであるものとする。

印刷制御部46は、印刷デバイス221と接続される。印刷デバイス221は、例えばプリンタである。例えば、操作認識部45が帳票を印刷する操作を受け付けたとき、印刷制御部46は、プリンタを制御して、帳票を印刷させる。

<各種テーブルの一例> 次に、図4および図5を参照して、各種テーブルの一例について説明する。図4は、購買データテーブル31とフォーマットテーブル32と取引実績テーブル33との一例を示している。

バイヤは、バイヤ端末2を操作して、WebEDIを利用して取引を行うための情報を入力する。バイヤ端末2は、入力された情報を受け付ける。バイヤ端末2は、上述した定義情報を記憶しており、定義情報に順じた購買データを生成する。バイヤ端末2は、第1ネットワーク5を介して、EDIサーバ3に購買データを出力する。

EDIサーバ3の第1通信部12は、購買データを入力する。第1制御部11は、データベース15の購買データテーブル31に購買データを記憶する。第1制御部11は、各バイヤ端末2から購買データを入力するごとに、入力した購買データを順次、購買データテーブル31に記憶する。

図4は、購買データテーブル31が、バイヤ端末2A、2Bおよび2Cから入力した購買データを記憶している例を示している。例えば、バイヤ端末2Aおよびバイヤ端末2Bが出力した購買データは、発信者、受信者、注文番号、注文数量および単価の項目を含んでいる。なお、この購買データは、他の項目を含んでいる。

バイヤ端末2Cの購買データは、From、To、発注番号、納期および購買担当の項目を有している。なお、この購買データは、他の項目を含んでいる。バイヤ端末2Cの購買データのうち、Fromは発信者に対応し、Toは受信者に対応し、注文番号は発注番号に対応するものとする。

従って、バイヤ端末2Aの購買データとバイヤ端末2Bの購買データとは全ての項目が一致する。一方、バイヤ端末2Aおよび2Bの購買データとバイヤ端末2Cの購買データとは納期および購買担当の項目が異なる。

購買データは、バイヤごとの定義情報に基づいている。従って、バイヤ端末2Aが記憶する定義情報とバイヤ端末2Bの定義情報とは全ての項目が一致する。一方、バイヤ端末2Cが記憶する定義情報は、バイヤ端末2Aおよび2Bが記憶する定義情報とは項目が異なる。

次に、フォーマットテーブル32について説明する。フォーマットテーブル32は、バイヤと取引種別と固有ロジッククラス名との項目を有している。バイヤの項目は、バイヤの名称を示している。

取引種別は、取引の種別を示している。取引種別としては、例えば、注文や出荷、納期回答等がある。固有ロジッククラス名は、固有機能22の名称を示している。従って、フォーマットテーブル32のバイヤと取引種別とにより、固有機能22が特定される。

なお、フォーマットテーブル32は、取引種別の項目を有していなくてもよい。この場合、バイヤにより固有機能22が特定される。フォーマットテーブル32の固有ロジッククラス名は、固有機能22を特定できれば、他の情報であってもよい。例えば、固有ロジッククラス名は、固有機能22を識別する識別子であってもよい。

次に、取引実績テーブル33について説明する。取引実績テーブル33は、サプライヤごとに、取引実績のあるバイヤの情報を記憶する。EDIサーバ3がサプライヤとバイヤとの間に新たな取引が発生したことを認識したときに、第1制御部11は、新たな取引の対応関係を取引実績テーブル33に記憶する。

次に、図5を参照して、定義情報テーブル24について説明する。定義情報テーブル24は、バイヤごとに定義情報の項目を記憶している。定義情報テーブル24には、予めバイヤごとの定義情報が記憶されている。

例えば、定義情報が標準化されている場合、複数のバイヤは標準化された定義情報を使用する。この場合、定義情報テーブル24に記憶されるバイヤごとの定義情報のうち、全ての項目が一致する複数の定義情報が定義情報テーブル24に記憶されている場合がある。

実施形態では、バイヤAおよびバイヤBは、標準化された定義情報を使用するものとする。このため、バイヤAの定義情報とバイヤBの定義情報とは項目が全て一致する。一方、バイヤCは、独自の定義情報を使用するものとする。この場合、バイヤCの定義情報は、バイヤAおよびバイヤBの定義情報と項目が一致しない。

次に、定義情報識別テーブルについて説明する。定義情報識別テーブルは、バイヤと定義情報名称とIDとの項目を有している。IDは、バイヤおよび定義情報名称を特定する。図5の例において、定義情報名称は「標準注文」を含んでいる。これは、取引種別が「注文」の標準化された定義情報を示している。

また、「標準出荷」は、取引種別が「出荷」の標準化された定義情報を示している。従って、取引種別によって、標準化された定義情報が異なる場合がある。このため、バイヤAおよびバイヤBは、標準化された「注文」の定義情報と「出荷」の定義情報とで異なるIDが割り当てられている。

<取引情報の集約の一例> 次に、図6を参照して、取引情報の集約の一例について説明する。取引情報は、購買データに基づいて、EDIサーバ3がサプライヤ端末4に出力する取引に関する情報である。この取引情報は、出力情報の一例である。

EDIサーバ3の第1制御部11は、購買データに基づいて、バイヤおよびサプライヤを特定し、サプライヤ端末4に出力する取引情報を生成する。サプライヤ端末4は、取引情報を入力することで、表示部44に取引情報を表示する。これにより、サプライヤは、バイヤからの取引を認識する。

図6(A)は、取引情報の集約の第1例を示している。第1制御部11は、定義情報テーブルを参照して、全ての項目が一致する定義情報を使用するバイヤを特定する。例えば、バイヤAとバイヤBとは項目が全て一致している定義情報を使用している。従って、第1制御部11は、バイヤAとバイヤBとの取引情報を集約する。一方、バイヤCは、定義情報に納期および購買担当の項目を含んでいる。

これら2つの項目は、バイヤAおよびバイヤBの定義情報にはない項目である。従って、第1制御部11は、バイヤCの取引情報は集約しない。なお、バイヤCの定義情報の項目と全て一致する他のバイヤの定義情報があれば、第1制御部11は、バイヤCの取引情報と上記の他のバイヤの取引情報とを集約する。

図6(B)は、取引情報の集約の第2例を示している。第2例では、バイヤAおよびバイヤBの定義情報は、バイヤDの定義情報と全ての項目が一致する。ただし、バイヤAおよびバイヤBとバイヤDとでは定義情報の項目の順序が異なる。以下、項目の順序を単に順序と称することもある。

図6(B)の例では、「単価」および「注文数量」の順序が、バイヤAおよびバイヤBの定義情報とバイヤDの定義情報とで異なる。実施形態では、定義情報の全ての項目が一致したとしても、順序が異なる場合、第1制御部11は、取引情報を集約しない。

これは、定義情報の順序が異なると、バイヤとサプライヤとの間で取引が行われるときに、第1制御部11が取引情報の順序を入れ替える処理を行うためである。例えば、定義情報の項目の数が多くなると、順序の入れ替えの処理に多くの時間が費やされる。

このため、実施形態では、第1制御部11は、定義情報の順序が異なるバイヤの取引情報を集約しない。これにより、順序の入れ替えのための処理を省略できる。ただし、第1制御部11は、順序が異なる定義情報について、バイヤ情報の集約を行ってもよい。この場合、第1制御部11は、上記の順序の入れ替え処理を行う。

<固有機能の呼び出しの一例> 次に、図7を参照して、固有機能22の呼び出しの一例について説明する。図7の例において、基本機能は、第1制御部11が実行するアプリケーションの基本的な機能である。この基本機能は、例えばソースコードで記述されている。

図7の例の基本機能は、業務ロジックの処理の流れを示す業務ロジック関数を含む。例えば、業務ロジックは、取引で実行される処理の流れを示す。業務ロジック関数は、上述した共通機能21のソースコードであるものとする。また、業務ロジック関数は、固有ロジックを呼び出す命令を含むものとする。

固有ロジックは、上述した固有機能22のソースコードであるものとする。第1制御部11が固有ロジックの呼び出しを実行すると、フォーマットテーブル32を参照して、呼び出しの対象の固有ロジックを特定する。

例えば、第1制御部11がバイヤAの注文取引に関する購買データの処理を行っているものとする。第1制御部11は、購買データに基づいて、バイヤと取引種別とを認識する。これにより、第1制御部11は、固有ロジッククラス名「Class.A.logic」を認識し、バイヤA固有機能22Aを呼び出す。

上述したように、固有機能22はソースコードである。従って、第1制御部11は、機能記憶部14のバイヤA固有機能22のソースコードを呼び出して、該ソースコードの処理を実行する。

<各種画面例の一例> 次に、各種画面例について説明する。以下において説明する画面例は、サプライヤ端末4Aに表示される画面の例である。サプライヤAは、サプライヤ端末4Aを操作して、該サプライヤ端末4AがEDIサーバ3にアクセスする。これにより、EDIサーバ3を利用した取引が行われる。サプライヤ4Bおよび4Cの場合も同様である。

サプライヤ端末4Aは、サプライヤAの操作を受け付けて、受け付けた操作に関する情報をEDIサーバ3に送信する。EDIサーバ3は、入力した情報に基づいて、所定の処理を行い、所定の情報をサプライヤ端末4Aに出力する。そして、サプライヤ端末4Aは画面部44に所定の情報を表示する。

WebEDIでは、サプライヤ端末4Aの画面部44にはブラウザが表示され、このブラウザの中にEDIサーバ3が提供する各種情報が表示される。なお、サプライヤ端末4Aの画面部44には、ブラウザ以外の方法で、EDIサーバ3が提供する各種情報が表示されてもよい。

実施形態では、サプライヤがサプライヤ端末4Aを操作して、EDIサーバ3のサービスを利用するとき、EDIサーバ3は、IDやパスワード等をサプライヤ端末4Aに要求する。

サプライヤ端末4Aは、入力されたIDやパスワード等をEDIサーバ3に出力する。 EDIサーバ3がIDやパスワード等の認証を行い、認証が成功したときに、サプライヤ端末4Aは、EDIサーバ3にログインする。

EDIサーバ3の第1制御部11は、ログインしたサプライヤ端末4Aに対応するサプライヤAと取引実績があるバイヤの情報を取引実績テーブル33から取得する。上述したように、取引実績テーブル33のサプライヤAに対応するバイヤは、バイヤA〜バイヤCである。

第1制御部11は、バイヤA〜Cに関する情報をサプライヤ端末4Aに出力する制御を行う。例えば、第1制御部11は、バイヤA〜Cのそれぞれの取引種別に関する情報をサプライヤ端末4Aに出力する制御を行う。第1通信部12は、該情報をサプライヤ端末4Aに出力する。サプライヤ端末4Aは、該情報を入力する。

図8に示す画面は、サプライヤが取引を行うバイヤを選択する画面(以下、取引先選択画面と称することもある)の一例である。取引選択画面は、EDIサーバ3がサプライヤ端末4に提供する画面である。サプライヤ端末4Aの画面部44には取引先選択画面が表示される。取引先選択画面において、バイヤごとに表示領域が分けられている。

ただし、画面制御部43は、取引情報が集約されているバイヤについては、取引先選択画面の同じ表示領域に表示する制御を行う。上述したように、EDIサーバ3は、バイヤAの取引情報とバイヤBの取引情報とを集約してサプライヤ端末4Aに出力している。

このため、図8の例に示すように、画面制御部43は、取引先選択画面において、バイヤAとバイヤBとを同じ表示領域に集約して表示している。これにより、サプライヤは、取引先選択画面に基づいて、バイヤAの取引情報とバイヤBの取引情報とが集約していることを認識することができる。

取引先選択画面の各表示領域の取引種別は選択可能になっている。例えば、サプライヤ端末4Aの操作認識部45はマウスの操作を認識する。図8の例では、マウスのマウスポインタPがバイヤAの「注文」を選択している状態を示している。

第2制御部41は、バイヤAの「注文」を選択した操作を受け付ける。第2通信部42は、バイヤAからサプライヤAに対する注文の取引情報を取得する要求をEDIサーバ3に対して出力する。

EDIサーバ3の第1制御部11は、入力した要求に基づいて、サプライヤAおよびバイヤAを特定する。第1制御部11は、定義情報テーブル34を参照して、バイヤAと項目および順序が全て一致する定義情報を使用するサプライヤがあるか否かを判定する。

上述したように、バイヤAとバイヤBとの定義情報の項目および順序は全て一致する。第1制御部11は、バイヤAの取引情報とバイヤBの取引情報とを集約する。第1制御部11は、集約したバイヤAの取引情報およびバイヤBの取引情報をサプライヤ端末4Aに出力する制御を行う。

第1通信部12は、第2ネットワーク6を介して、集約したバイヤAおよびバイヤBの取引情報をサプライヤ端末4Aに出力する。サプライヤ端末4Aの第2通信部42は、取引情報を入力する。

図9は、サプライヤ端末4Aの第2通信部42が入力した出力情報に基づく画面(以下、取引一覧画面と称する)の一例である。上述したように、サプライヤ端末4Aは、「注文」を選択する操作を受け付けている。よって、図9の画面例は、注文に関する一覧画面になる。取引一覧画面は、特定の出力画面の一例である。

図9の取引一覧画面の例は、番号と情報種と発注者名と注文番号と注文数量と単価との項目を含んでいる。取引一覧画面は、入力した取引情報を示している。取引情報は複数の取引に関する情報を含んでいる。第2制御部41は、各取引に番号を付している。

情報種は企業が送信するデータの種類を示している。情報種に基づいて、操作認識部45は操作を変更する事ができる。例えば、図9の例では、情報種として確定と変更と取消を含んでいる。ただし、情報種は、上記の3つには限定されない。

例えば、第1制御部11が1番の取引で確定を選択する操作を受け付けた場合、1番の取引は確定する。また、第1制御部11が4番の取引で変更を選択する操作を受け付けた場合、4番の取引の内容は変更される。また、第1制御部11が5番の取引で取消を選択する操作を受け付けた場合、5番の取引の内容は取り消される。

取引一覧画面は、各取引に対応したチェックボックスCKを含む。第1制御部11は、チェックボックスCKをチェックする操作を受け付ける。図9の例の場合、1番、4番および5番の取引のチェックボックスCKがチェックされている。

取引一覧画面は、確認ボタン44Aおよび帳票作成ボタン44Bを含む。第1制御部11が確認ボタン44Aを押下する操作を受け付けたとき、画面制御部43は、チェックボックスCKがチェックされている取引の内容を確認する画面を画面部44に表示する。

第1制御部11は、帳票作成ボタン44Bを押下する操作を受け付けたとき、チェックボックスCKがチェックされている取引の帳票を作成する。画面制御部43は、作成した帳票のイメージを画面部44に表示してもよい。また、第1制御部11が印刷する操作を受け付けたとき、印刷制御部46は、作成された帳票が印刷されるように印刷デバイス221を制御してもよい。

サプライヤ端末4Aの第2通信部42は、バイヤAの取引情報とバイヤBの取引情報とを集約した取引情報を入力している。よって、図9の画面例に示すように、取引一覧画面は、バイヤAからの取引情報とバイヤBからの取引情報との両者の情報を含む。図9では、発注に関する取引情報が画面部44に表示されている例を示している。

従って、1つの取引一覧画面で、サプライヤAは、バイヤAからの発注に関する情報とバイヤBからの発注に関する情報とを纏めて閲覧できる。これは、EDIサーバ3が、定義情報の項目および順序が全て一致しているバイヤの取引情報を集約して出力しているためである。

例えば、EDIサーバ3の第1制御部11がバイヤの取引情報を集約しない場合、第1通信部12は、各バイヤの取引情報を個別的にサプライヤ端末4に出力する。従って、サプライヤ端末4の画面部44には、バイヤごとの取引一覧画面が表示される。

例えば、取引先選択画面から取引一覧画面を表示するときに、EDIサーバ3は、ログイン操作を要求する場合がある。この場合、ログイン操作を行うために、サプライヤは、サプライヤ端末4に対して、IDやパスワード等を入力する。

そして、サプライヤ端末4は、入力を受け付けたIDやパスワード等をEDIサーバ3に出力し、EDIサーバ3で認証を行う。EDIサーバ3は、認証に成功したときに、取引一覧画面を表示するための取引情報をサプライヤ端末4に出力する。

例えば、サプライヤ端末4Aの画面部44にバイヤAの取引一覧画面が表示されているときに、バイヤBの取引一覧画面を画面部44に表示する場合、取引一覧画面の切り替え操作がサプライヤAに要求される。

このため、サプライヤAは、バイヤAの取引一覧画面からログアウト操作を行い、取引先選択画面から再びログイン操作を行う。従って、異なるバイヤの取引一覧画面を表示するためには、バイヤ端末4Aに対して、ログイン操作およびログアウト操作が要求される。これらの操作は、取引一覧画面の切り替え操作が行われるごとに要求される。

このため、EDIサーバ3が提供するサービスをサプライヤが利用するときの利便性が低下する。ログイン操作およびログアウト操作が要求されない場合であっても、取引一覧画面がバイヤごとの個別の画面であると、サプライヤ端末4は、画面の切り替え操作をサプライヤに要求する。

従って、EDIサーバ3が提供するサービスをサプライヤが利用するときの利便性が低下する。これに対して、実施形態では、EDIサーバ3は、定義情報の項目および順序が全て同じバイヤの取引情報を集約しているため、サプライヤ端末4の画面部44には、集約されたバイヤの取引情報が一括して表示される。

これにより、取引一覧画面に表示されている複数のバイヤについて、取引一覧画面を切り替える操作が不要になる。このため、EDIサーバ3が提供するサービスをサプライヤが利用するときの利便性が向上する。

次に、図10を参照して、取引先選択画面において、バイヤCの「注文」が選択された場合について説明する。第2制御部41は、この選択操作を受け付けて、第2通信部42は、バイヤCがサプライヤAに注文した取引内容を取得する要求をEDIサーバ3に対して出力する。

定義情報テーブル34には、バイヤCの定義情報と項目および順序が全て一致する他のバイヤの定義情報は記憶されていない。従って、EDIサーバ3の第1制御部11は、バイヤCの取引情報を他のバイヤの取引情報と集約せず、バイヤCの取引情報を個別的にサプライヤ端末4Aに出力する。

図11は、バイヤCの取引一覧画面の一例を示している。EDIサーバ3の第1制御部11は、バイヤCの取引情報を他のバイヤの取引情報と集約していない。このため、取引一覧画面の発注者名は全てバイヤCになっている。従って、図11の画面例は、バイヤCに特化した取引情報を表示した画面になる。

ここで、EDIサーバ3の第1制御部11は、定義情報の項目が同じであるか否かにかかわらず、複数のバイヤの情報を集約してサプライヤ端末4に出力することも考えられる。図12は、その一例を示している。

図12の取引一覧画面は、バイヤA、バイヤBおよびバイヤCの全てを一括して表示している。この場合、取引一覧画面に表示される項目数が多くなる。例えば、バイヤCの定義情報は、注文数量および単価の項目を含んでいない。

従って、取引一覧画面において、バイヤCの注文数量および単価の欄には情報が表示されない。同様に、バイヤAおよびバイヤBの定義情報は、納期および購買担当の項目を含んでいない。従って、画面部44に表示される取引一覧画面において、バイヤAおよびバイヤBの納期および購買担当の欄には情報が表示されない。

定義情報の項目数が多くなると、バイヤごとの定義情報で一致しない項目数が多くなる。このため、定義情報が同じであるか否かにかかわらず、複数のバイヤの情報が画面部44の取引一覧画面に一括して表示されると、表示される項目数が多くなる。

そして、画面部44に表示される取引一覧画面の多くの欄に情報が表示されなくなり、サプライヤ端末4を操作するサプライヤの視認性が低下する。また、取引一覧画面の項目数が多くなると、例えば画面をスクロールする操作等がサプライヤに要求される。このため、サプライヤの操作性も低下する。

従って、EDIサーバ3が提供するサービスをサプライヤが利用するときの利便性が低下する。実施形態では、EDIサーバ3の第1制御部11は、項目および順序が異なる定義情報のバイヤの取引情報は集約せず、個別的にバイヤの取引情報をサプライヤ端末4に出力している。

これにより、取引一覧画面の項目数が最低限に抑制される。従って、サプライヤの視認性や操作性が低下することが抑制されるため、EDIサーバ3が提供するサービスをサプライヤが利用するときの利便性が向上する。

<印刷物の一例> 図13は、印刷制御部46の制御により、印刷デバイス221が印刷した注文書の一例を示している。注文書は、帳票の一例である。サプライヤ端末4が、選択された取引について注文書を印刷する操作を受け付けた場合、印刷制御部46は、印刷デバイス221を制御して、注文書を印刷する。また、図14に示すように、バイヤの固有ロジックによって、バイヤ毎に定義情報の異なる帳票を印刷制御部46は出力してもよい。

<各種処理の一例> 次に、図15を参照して、データ蓄積処理について説明する。各バイヤ端末2は、バイヤの操作を受け付けて、購買データを生成し、第1ネットワーク5を介して、購買データを出力する。

EDIサーバ3の第1通信部12は、バイヤ端末2が出力した購買データを入力する(ステップS1)。第1制御部11は、入力した購買データを購買データテーブル31に記憶する(ステップS2)。

次に、図16を参照して、情報出力処理について説明する。上述したように、サプライヤ端末4は、サプライヤの操作を受け付けて、EDIサーバ3に対してログインする。第1制御部11は、ログインしたサプライヤ端末4に基づいて、サプライヤを認識する(ステップS11)。

第1制御部11は、取引実績テーブル33を参照して、認識したサプライヤと取引実績のあるバイヤを認識する(ステップS12)。第1制御部11は、定義情報テーブル34を参照して、認識したバイヤの定義情報を取得する(ステップS13)。

第1制御部11は、取得したバイヤの定義情報の中で、同じ定義情報を使用するバイヤがあるか否かを判定する(ステップS16)。第1制御部11は、取得したバイヤの定義情報の中で、項目および順序が全て一致する定義情報があるか否かに基づいて、ステップS16の判定を行ってもよい。

また、第1制御部11は、定義情報識別テーブル35を参照して、認識したバイヤの定義情報の中で同じIDのバイヤがあるか否かに基づいて、ステップS16の判定を行ってもよい。

第1制御部11は、同じ定義情報を使用するバイヤがあると判定した場合(ステップS14でYES)、同じ定義情報を使用するバイヤの購買データを購買データテーブル31から取得する。そして、第1制御部11は、取得した購買データに基づいて、取引情報を生成し、生成した取引情報を集約する(ステップS15)。第1通信部12は、集約したバイヤの情報をサプライヤ端末4に出力する(ステップS16)。

第1制御部11は、同じ定義情報を使用するバイヤがないと判定した場合(ステップS14でNO)、バイヤの情報を集約しない。第1制御部11は、バイヤの購買データを購買データテーブル31から取得し、取得した購買データに基づいてバイヤの取引情報を個別的に生成する(ステップS17)。第1通信部12は、個別的に取得したバイヤの取引情報をサプライヤ端末4に出力する(ステップS18)。

サプライヤ端末4の第2通信部42は、バイヤの取引情報を入力する。画面制御部43は、入力したバイヤの取引情報に基づいて、画面部44に取引一覧画面を表示する制御を行う。

図17は、ステップS16の判定処理の一例を示している。この判定処理を定義情報判定処理と称する。第1制御部11は、取得したバイヤの定義情報の中で、全ての項目が一致する定義情報を使用するバイヤがあるか否かを判定する(ステップS16−1)。

第1制御部11は、全ての項目が一致する定義情報を使用するバイヤがあると判定した場合(ステップS16−1でYES)、全ての項目の順序が一致しているか否かを判定する(ステップS16−2)。

第1制御部11は、全ての項目の順序が一致していると判定したとき(ステップS16−2でYES)、同じ定義情報を使用するバイヤがあると判定する(ステップS16−3)。

一方、第1制御部11は、全ての項目が一致する定義情報を使用するバイヤがないと判定した場合(ステップS16−1でNO)、同じ定義情報を使用するバイヤがないと判定する(ステップS16−4)。また、第1制御部11は、全ての項目の順序が一致しないと判定した場合(ステップS16−2でNO)、処理はステップS16−4に進む。

次に、図18を参照して、機能実行処理について説明する。第1制御部11は、アプリケーションを実行する。第1制御部11が業務ロジック関数を実行するとき、機能記憶部14に記憶されている共通機能を実行する(ステップS31)。

第1制御部11は、業務ロジック関数にバイヤ固有の機能が設定されている場合(ステップS32でYES)、フォーマットテーブル32を参照する(ステップS33)。第1制御部11は、フォーマットテーブル32のうち、バイヤの情報と取引種別の情報とに基づいて、固有ロジッククラス名を特定する。

第1制御部11は、特定した固有ロジッククラス名に基づいて、機能記憶部14に記憶されている各固有機能22のうち何れかの固有機能22を呼び出す(ステップS34)。そして、第1制御部11は、呼び出した固有機能22のソースコードを実行する(ステップS35)。

従って、第1制御部11は、バイヤに応じた固有の機能を実行する。例えば、注文や出荷の変更といった業務ロジックがバイヤによって異なる場合、第1制御部11は、固有機能22のソースコードを実行する。これにより、EDIサーバ3は、バイヤによって異なる制御を行うことができる。

次に、図19の例を参照して、EDIサーバ3のハードウェア構成の一例を説明する。図19の例に示すように、バス100に対して、プロセッサ111とRAM112とROM113と補助記憶装置114と媒体接続部115と通信インタフェース116とが接続されている。

プロセッサ111は任意の処理回路である。プロセッサ111はRAM112に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態の処理を行うプログラムを適用してもよい。ROM113はRAM112に展開されるプログラムを記憶する不揮発性の記憶装置である。

補助記憶装置114は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置114に適用してもよい。媒体接続部115は、可搬型記録媒体118と接続可能に設けられている。

可搬型記録媒体118としては、可搬型のメモリや光学式ディスク(例えば、Compact Disk(CD)やDigital Versatile Disk(DVD)等)を適用してもよい。この可搬型記録媒体118に実施形態の処理を行うプログラムが記録されていてもよい。

EDIサーバ3の第1制御部11は、プロセッサ111により実現されてもよい。第1通信部12は、通信インタフェース116により実現されてもよい。アプリケーション記憶部13、機能記憶部14およびデータベース15は、RAM112や補助記憶装置114により実現されてもよい。

RAM112、ROM113、補助記憶装置114および可搬型記録媒体118は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

<サプライヤ端末のハードウェア構成の一例> 次に、図20の例を参照して、サプライヤ端末4のハードウェア構成の一例を説明する。図20の例に示すように、バス200に対して、プロセッサ211とRAM212とROM213と補助記憶装置214と媒体接続部215と通信インタフェース216と入出力インタフェース217とが接続されている。

入出力インタフェース217以外の各部は、上述したEDIサーバのハードウェア構成と同様である。入出力インタフェース217は、ディスプレイ219と操作デバイス220と印刷デバイス221と接続されている。

第2制御部41、画面制御部43、操作認識部45および印刷制御部46は、プロセッサ211により実現されてもよい。第2通信部42は、通信インタフェース216により実現されてもよい。画面部44は、ディスプレイ219により実現されてもよい。操作デバイス220および印刷デバイス221は、上述した操作デバイス220および印刷デバイス221である。

RAM212、ROM213、補助記憶装置214および可搬型記録媒体118は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

<その他> 本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

1 システム 2 バイヤ端末 3 EDIサーバ 4 サプライヤ端末 11 第1制御部 12 第1通信部 13 アプリケーション記憶部 14 データベース 15 機能記憶部 21 共通機能 22 固有機能 31 購買データベース 32 フォーマットテーブル 33 取引実績テーブル 34 定義情報テーブル 35 定義情報識別テーブル 111 プロセッサ 112 RAM 113 ROM

高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈