200926034 九、發明說明 【發明所屬之技術領域】 本發明係關於購買操作系統、購買操作處理方法及購 買操作處理程式。具體而言，本發明關於能夠由眾多具有 不同核準標準的公司或組織共同使用的環境（ASP等）中 所使用的技術’所述技術允許各別公司或組織使用共同的 程式資源以及設定及使用它自己獨有的核準路由。 【先前技術】 關於公司的購買操作系統，舉例而言，眾多購買公司 或組織通常使用相同的系統以降低操作成本以及實現合作 購買。執行此種操作的購買操作系統使用之設計（ASP等 )’以邏輯方式分割單一系統的資源，而使得眾多購買公 司或組織能夠使用單一系統。在此設計中，程式資源由多 家公司或組織共用。此種購買操作系統的核準功能通常是 僅根據對應於購買量等二或三階段的核準規則，核準規則 在購買操作系統中預先決定。在某購買公司或組織使用特 定用於公司或組織的核準規則而非用系統中預先決定的核 準規則之情形中，舉例而言，所述公司或組織以僅有關於 購買定單的資料被鏈結至系統的方式使用購買操作系統。 更具體而言，以此方式，在輸入關於購買訂單的資料之前 ’公司或組織將關於要購買的產品之資料輸入其本身個別 地操作的系統中，以及，操作個別操作系統以確認用於購 買的核準。關於此種方法的實施例，請參考非專利文獻之 -5- 200926034 下述網站： http://www.withkaunet.com/top/infol3.html， http://www.withkaunet.com/top/info3.html，及 http://www.webmethods.co.jp/pdf/Biz.pdf。 如上所述，在傳統的可由具有不同的核準標準的眾多 k 公司或組織共同使用的購買操作處理環境中（系統中的資 . 源以邏輯方式分割之環境，例如A S P )，各別公司或組織 Q 使用共同的程式資源。在各別公司或組織要在此環境下的 購買操作系統中實施其自己獨有的核準標準之情形中，包 含於購買操作系統中的一般功能及服務無法實用，因此， . 每當購買操作系統被調整至獨有的核準標準時，各別發展 成本會加諸於公司或組織。結果，各別公司或組織的成本 負擔等會增加。同時，即使使用上述非專利文獻中所述的 鏈結方法以避免此問題，但是，各別公司或組織必須承擔 系統發展成本及操作成本。 ❹ ' 【發明內容】 ^ 慮及上述問題而產生本發明。本發明的目的在於使每 一使用者能夠在每一使用者使用共用的程式資源的假定下 界定及使用其自己獨有的核準規則。 本發明的購買操作系統提供由例如公司及組織等多個 使用者共同使用，以及執行多個使用者之間產品、服務等 交易的中間處理之系統。所提供的系統包括：核準路由設 定接收單元，用於從多個使用者中每一使用者所使用的使 -6- 200926034 用者終端或輸入介面輸入接收用於多個使用者中的每一使 用者的核準路由資料，以及，將如此收到的核準路由資料 儲存於儲存單元中，核準路由資料是關於產品或服務交易 的多個使用者中的每一使用者所要求的內部核準之核準路 由的資料’以及’核準路由資料包含彼此相關連之作爲核 * 準標的的交易之屬性及核準所需的核準者的屬性；核準路 • 由控制單元’用於從使用者終端接收產品或服務的交易請 φ 求資料’然後，用於從儲存單元中均與發出交易請求資料 的使用者的使用者終端相關連的核準路由資料中選取交易 屬性符合交易請求資料的交易屬性之核準路由資料，以及 ’用於根據此處選取的該核準路由資料以執行用於使用者 的內部核準處理；及交易中間執行單元，在因內部核準處 理的結果而從要求的核準者取得核準的情形中，將作爲核 準標的之該交易中下單或收到的訂單的資料傳送給使用者 的交易對手的終端。 〇 根據本發明的購買操作系統，使每一公司或組織能夠 ' 在購買操作系統的每一使用者使用共用的程式資源的假定 - 下’在購買操作系統上實現其自己獨有的核準標準。由於 維持購買操作系統的每一使用者使用共同程式資源的假設 ’所以’解決了先前技術中造成的問題。這些問題包含購 買操作系統中的多功能的一般多樣性及服務減少以及每次 對每一核準標準採取回應措施之個別發展時發生成本負擔 。因此’在購買操作系統的每一使用者使用共用的程式資 源的假定下’每一使用者能夠定義及使用其自己獨有的核 -7 - 200926034 準規則。 此外，在上述購買操作系統中，核準路由設定接收單 元配置成將用於輸入核準路由資料的輸入接收螢幕資料傳 送給使用者終端或輸入介面，以及，從使用者終端或輸入 介面接收輸入接收營幕中輸入的核準路由資料。此外，輸 入接收螢幕資料配置成包含：用於接收包含於核準路由中 ^ 的每一核準者的核準授權等級的設定之介面；及用於接收 〇 包含於核準路由中的每一核準階段中所要求的核準者的核 準授權等級之設定的介面。 根據上述配置，關於核準路由資料，可以設定每一核 準階段中具有適當授權等級的核準者。使每一使用者能夠 設定其自己獨有的核準路由之本申請案的發明之效果可以 增強每一使用者設定其自己獨有的核準路由的彈性。 此外，在購買操作系統中，關於該多個使用者中的每 一該使用者的核準者候選人及關於該核準者候選人的核準 ® 授權等級的資料儲存於該儲存單元中，以及，在經由該輸 ' 入接收螢幕而從使用者終端或輸入介面收到每一核準階段 中要求的核準授權等級的設定時，核準路由設定接收單元 指定儲存單元中具有等於或大於此處收到的設定中標示的 要求的核準授權等級之核準授權等級的核準者候選人，然 後’產生核準者候選人清單，然後，將核準者候選人清單 的資料傳送給使用者終端或該輸入介面以及從核準者清單 接收標示選取的核準者之指令。 根據此配置，對於使用者設定核準者而言，用於決定 -8- 200926034 核準者的處理之效率會增進，同時，可以免除不具有要求 的核準等級的核準者被錯誤地設定於核準路由資料中之情 形。 此外’在購買操作系統中，核準路由設定接收單元配 置成將用於輸入該核準路由資料的輸入接收螢幕資料傳送 * 給使用者終端或該輸入介面，以及，從使用者終端或輸入 - 介面接收輸入於輸入接收螢幕中的核準路由資料。此外， φ 輸入接收螢幕資料配置成包含：用於接收交易中被訂購的 產品及售出產品的屬性設定之介面，交易是該核準路由中 的核準處理標的；用於接收用於會計程序等的付款源資訊 的介面；用於接收介易的交易額度範圍的設定之介面，交 易是核準路由的核準處理標的；及用於接收與藉由使用使 用者終端而發出產品或服務的交易請求的使用者相關的屬 性設定。 根據此配置，關於核準路由資料，可以將詳細的交易 © 內容設定爲要成爲用於自動地選取核準路由的標準之交易 ' 屬性。這增加每一使用者增進其設定自己的核準路由彈性 - 之效果。 此外，在上述購買操作系統中，核準路由控制單元從 使用者終端接收產品或服務的交易請求資料，以及，從如 此接收到的交易請求資料讀取交易中被訂購的產品及售出 的產品的屬性資料、交易的交易額度資料、該付款源資訊 及與發出交易請求指令的使用者相關的屬性資料。此外， 核準路由控制單元配置成從儲存單元中均與發出交易請求 -9- 200926034 資料的使用者終端的使用者相關連的核準路由資料中選取 設定於核準路由資料中及與從交易請求資料讀出的資料相 符之具有被訂購的產品及售出產品的屬性之核準路由資料 、交易額度範圍、付款源資訊、及使用者的屬性’然後， 根據此處選取的核準路由資料，執行用於使用者的內部核 * 準處理。 I 根據此配置，關於核準路由資料’可以將詳細的交易 Φ 內容設定爲要成爲用於自動地選取核準路由的標準之交易 屬性。這增加每一使用者增進其設定自己的核準路由彈性 之效果、或是增加允許根據交易的詳細內容來選取適當核 準路由的效果。 此外，在上述購買操作系統中，多個使用者共用的核 準路由資料儲存於儲存單元中，及當選取交易屬性符合交 易請求資料的交易屬性之核準路由資料時，在具有交易屬 性符合該交易請求資料之交易屬性的核準路由資料不存在 〇 於儲存單元中均與發出該交易請求資料的使用者終端的使 ' 用者相關連的核準路由資料中之情形中，核準路由控制單 - 元選取多個使用者共用的核準路由資料。 根據此配置，每一使用者可以設定自己獨有的核準路 由。同時，可以控制要登錄於儲存單元中的核準路由資料 的實體容量、及用於核準路由資料設定的不同主資料的實 體容量，也可以簡化儲存單元中的資料維護及管理。因此 ，可以降低系統的潛在成本。 此外，在上述購買操作系統中，將多個使用者共用的 -10- 200926034 核準路由資料設定用於每一或多個交易屬性。在上述購買 操作系統中，當選取交易屬性符合交易請求資料的交易屬 性之核準路由資料時，在交易屬性符合交易請求資料的交 易屬性之核準路由資料不存在於儲存單元中均與發出交易 請求資料的該使用者終端的使用者相關連的核準路由資料 • 中的情形中，核準路由控制單元從多個使用者共用的核準 I 路由資料中選取多個使用者共用的某核準路由資料，多個 〇 使用者共用的某核準路由資料包括包含於交易請求資料中 的交易的預定屬性資料。 根據此配置，可以控制要登錄於儲存單元中的核準路 由資料的實體容量、及用於核準路由資料設定的不同主資 料的實體容量，也可以簡化儲存單元中的資料維護及管理 。同時，可以自動地選取根據交易屬性的核準路由。因此 ，可以簡化資料維護及管理以及適當地選取核準路由。 此外，在購買操作系統中，儲存設定於核準路由資料 © 中的核準者所使用的核準者終端在網路上的位址，以及， 當根據選取的核準路由資料以執行內部核準處理時，核準 * 路由控制單元將準請求資料與交易請求資料一起傳送給包 含於核準路由資料中的核準者終端的位址，然後，從核準 者終端取得標示該核準者核準或不核準的輸入資料，然後 ，決定是否取得定界定於核準路由資料中所有核準者的核 準，以及，假使判定取得來自界定於核準路由資料中的所 有核準者的核定時，將決定的結果通知交易執行單元。 根據此配置，購買操作系統依據交易屬性而自動地選 -11 - 200926034 取核準路由’也根據自動選取的核準路由而自動地執行核 準者的核準資料取得以及執行取得核準資料後要執行的處 理。因此，使用者不再需要根據核準路由以分別地執行內 部核準處理。 此外，根據本發明之購買操作處理方法，由電腦執行 • ’電腦由例如公司及組織等多個使用者共同使用，以及執 » 行多個使用者之間產品、服務等交易的中間處理。所提供 〇 的方法包括下述步驟：從使用者所使用的使用者終端或輸 入介面輸入接收用於多個使用者中的每一使用者的核準路 由資料，以及，將如此收到的核準路由資料儲存於儲存單 元中，核準路由資料是關於產品或服務交易的多個使用者 中的每一使用者所要求的內部核準之核準路由的資料，以 及，核準路由資料包含彼此相關連之作爲核準標的的交易 之屬性及核準所需的核準者的屬性；從使用者終端接收產 品或服務的交易請求資料，然後，從儲存單元中均與發出 Ο 該交易請求資料的該使用者的使用者終端相關連的核準路 由資料中選取交易屬性符合交易請求資料的交易屬性之核 - 準路由資料，以及，根據此處選取的核準路由資料以執行 用於使用者的內部核準處理；及在因內部核準處理的結果 而從要求的核準者取得核準的情形中’將作爲核準標的之 交易中下單或收到的訂單的資料傳送給使用者的交易對手 的終端。 根據購買操作處理方法’在購買操作系統的每一使用 者使用共用的程式資源的假定下’使每一使用者能夠在購 -12- 200926034 Η操作系統上實現其自己獨有的核準標準。由於維持購買 操作系統的每一使用者使用共同程式資源的假設，所以， 解決了先前技術中造成的問題。這些問題包含購買操作系 統中的多功能的一般多樣性及服務減少以及每次對每一核 準標準採取回應措施之個別發展時發生成本負擔。因此， * 在使每一公司或組織能夠在購買操作系統的每一使用者使 1 用共用的程式資源的假定下，每一使用者能夠定義及使用 〇 其自己獨有的核準規則。 根據本發明的購買操作處理程式，使由例如公司及組 織等多個使用者合作使用、以及執行多個使用者之間產品 、服務等交易的中間處理之電腦，執行下述步驟：從使用 者所使用的使用者終端或輸入介面輸入接收用於多個使用 者中的每一使用者的核準路由資料，以及，將如此收到的 核準路由資料儲存於儲存單元中，核準路由資料是關於產 品或服務交易的多個使用者中的每一使用者所要求的內部 〇 核準之核準路由的資料，以及，核準路由資料包含彼此相 * 關連之作爲核準標的的交易之屬性及核準所需的核準者的 - 屬性；從使用者終端接收產品或服務的交易請求資料，然 後，從儲存單元中均與發出交易請求資料的該使用者的使 用者終端相關連的核準路由資料中選取交易屬性符合交易 請求資料的交易屬性之核準路由資料，以及，根據此處選 取的核準路由資料以執行用於使用者的內部核準處理；及 在因內部核準處理的結果而從要求的核準者取得核準的情 形中，將作爲核準標的之交易中下單或收到的訂單的資料 -13- 200926034 傳送給使用者的交易對手的終端。 根據本發明的購買操作系統，使每一公司或組織能夠 在購買操作系統的每一使用者使用共用的程式資源的假定 下’在購買操作系統上實現其自己獨有的核準標準。由於 維持購買操作系統的每一使用者使用共同程式資源的假設 * ’所以’解決了先前技術中造成的問題。這些問題包含購 * 買操作系統中的多功能的一般多樣性及服務減少以及每次 φ 對每一核準標準採取回應措施之個別發展時發生成本負擔 。因此’在購買操作系統的每一使用者使用共用的程式資 源的假定下’每一使用者能夠定義及使用其自己獨有的核 準規則。 此外，從「實施方式」一節及附圖，將更清楚本申請 案中揭示的問題及其解決方法。 根據本發明，在購買操作系統的每一使用者使用共用 的程式資源的假定下，每一使用者能夠定義及使用其自己 φ 獨有的核準規則。 【實施方式】 系統配置 於下’將使用附圖’詳細說明本發明的實施例。圖1 是根據本實施例之購買操作系統100的配置。根據本實施 例之購買操作系統100 (此後稱爲系統100)是電腦系統 ，由例如公司及組織等眾多使用者共用，以及，執行使用 者之間的產品、服務等中間處理。本系統i 〇 〇可以說是提 -14- 200926034 供眾多具有不同的核準標準的購買公司2或組織可以執行 合作購買操作的環境（系統中的資源以邏輯方式分割的環 境，例如A S P )之電腦。此外’眾多公司2及它們的交易 對手公司3可以經由例如網際網路等網路1 4〇而模擬使用 電腦。 * 因此，可以假定系統100爲伺服器設備’伺服器設備 * 經由網路140耦合至大量的使用者終端300 (較佳地’也 φ 爲核準者終端400 )，在處理使用者終端之間交易的產品 或服務期間，在網路上提供場所作爲電子市場，以及’執 行產品搜尋、己下的訂單或收到的訂單之資料處理、交易 歷史管理及核準處理。在使用者終端3 00之間，由購買公 司2所使用且均執行產品或服務的購買操作之使用者終端 稱爲購買公司終端350，而由交易對手公司3所使用且均 在收到來自購買公司2的訂單時遞交產品或服務的使用者 終端稱爲交易對手公司終端360。 〇 此外，系統100在儲存單元101中包含登入程式4、 * 請求源程式5及交易對手程式6。請求源程式5提供下述 - 功能：由購買公司2所使用的產品搜尋功能1 〇以搜尋要 下訂單的產品；訂單請求功能1 1，從購買公司2接收訂單 ，接著處理訂單；核準功能1 2，根據每一使用者的各別核 準路由以執行核準處理；及下單歷史管理功能13，管理使 用者下的訂單之歷史資料。此外，交易對手程式6提供訂 單接收功能14及出貨登錄功能15。訂單接收功能14從購 買公司2接收訂單，出貨登錄功能15登錄標示交易對手 -15- 200926034 公司3已根據訂單而對可應用的產品等執行出貨處理之資 料、等等。 應注意，關於與購買操作有關的使用者授權，假定爲 「客戶」或「核準者」。關於購買處理，屬於每一購買公 司2且具有「客戶」授權的使用者（此後稱爲「客戶使用 ， 者」）藉由使用登入程式4以登入系統100，接著，藉由 • 使用請求源程式5的產品搜尋功能1 〇及訂單請求功能1 1 φ ’產生核準請求資料。另一方面，具有「核準者」授權的 使用者（此後，稱爲「核準使用者」）藉由使用登入程式 4以登入系統1 00以及藉由使用請求源程式5的核準功能 1 2以執行核準處理。 此時’系統100將核準路由資料中設定的核準者所使 用的核準終端400網路上的位址儲存在儲存單元1〇1中。 然後，核準功能12(核準路由控制器in)將核準請求與 訂單請求（交易請求資料）—起傳送給核準者終端40〇的 G 位址’該位址係包含於核準路由資料中。舉例而言，核準 • 請求資料是設有接收核準或不核準的輸入之介面的螢幕資 - 料。然後，核準功能12取得標示來自核準者終端400的 核準者的核準或不核準之輸入資料，接著，決定核準或不 核準是否從核準路由資料中所界定的所有核準者取得的。 假使核準功能12判定核準是自核準路由資料中所界定的 所有核準者取得的，則核準功能〗2將判定結果通知訂單 請求功能11 (交易執行單元）。 由於可以對單一核準請求事件設定一或更多核準者， -16- 200926034 所以，在 準時，核 式訂單事 在交 用者藉由 ' 對應的一 . 易對手程 φ 行訂單接 歷史屬性 有用的資 購買公司 使用者共 此外 及DV伺 程式5及 ® 式。此外 ' 統100處 • 理的產品 料（核準 爲儲存單 功能時， 器9的資 上述 101中的 從核準路由資料中設定的所有核準者完成取得核 準請求事件對於對應的一交易對手公司3變成正 件。 易對手公司3中具有「交易對手代表」授權之使 使用登入程式4以登入系統1〇〇’接著’相對於 購買公司2所產生的正式定單事件’藉由使用交 式6的訂單接收功能14及出貨登錄功能15’執 收處理及出貨處理。例如關於每一使用者的購買 資訊、、產品資訊及其它資訊等隨著使用而成爲 訊會被儲存於以邏輯方式劃分給資料庫7中每一 2或交易對手公司3的空間中，資料庫7是所有 同的且包含於系統的儲存單元1 〇 1中。 ，根據本實施例的系統1〇〇包含WEB伺服器8 服器9。WEB伺服器8設有登入程式4、請求源 交易對手程式6以作爲儲存單元中的業務應用程 ，DV伺服器9包含使用者主屬性125、要由系 理的產品及服務的清單之資料、要由系統100處 及服務的訂單資料、下單歷史資料及核準路由資 路由申請主條件126及核準路由主控制127)作 元101中的資料庫7。當執行業務應用中的每一 網頁伺服器8經由網路140取出/寫入DB伺服 料庫7中的每一件資訊。 系統將儲存於例如非揮發性記憶體中的儲存單元 程式1 〇 2讀出至記憶體1 〇 3中，以提供執行購買 -17- 200926034 操作處理方法的功能。系統1 ο 〇接著促使作爲算術 CPU 104執行程式。此外，系統100包含例如通常 腦的鍵盤及不同型式的按鍵等輸入介面105、例如 顯示器等輸出介面106以及用於與使用者終端300 者終端400通訊的通訊單元1〇7。 • 接著，舉例而言，將說明根據程式102而由系 . 配置及保有的功能單元。如上所述，每一功能單元 0 體地設置於單一伺服器設備等上。但是，可以假定 元以分散方式配置於網路140上的多個電腦上以及 伺服器設備的發起下，以合作方式工件。 系統1〇〇包含核準路由設定接收單元110。核 設定接收單元110從使用者或輸入介面105所使用 者終端接收用於使用者之核準路由資料，核準路由 含彼此相關連的交易屬性及核準者屬性，交易屬性 標的。此處，核準路由資料是在產品或服務交易時 〇 用者所要求的內部核準之核準路由的資料。核準路 • 接收單元110將如此收到的核準路由資料儲存在儲 • 101中。可以假定此核準路由設定接收單元110由 求源程式5提供。 此外，系統1 〇 〇包含核準路由控制單元111。 由控制單元11 1從使用者終端300接收產品及服務 請求資料。核準路由控制單元111接著從與發出交 資料的使用者終端3 0 0中之一對應終端的使用者相 核準路由資料中選取屬性與交易請求資料相符的核 單元的 用於電 LED或 及核準 統 10 0 可以整 功能單 在預定 準路由 的使用 資料包 是核準 每一使 由設定 存單元 上述請 核準路 的交易 易請求 關連的 準路由 -18- 200926034 資料。核準路由控制單元111接著根據此處選取的 由資料，執行用於使用者的內部核準處理。可以假 源程式5所提供的核準路由控制單元111。 此外，系統100包含交易中間執行單元112， 部核準處理的結果而從所需的核準者取得核準之情 - 交易中間執行單元112將核準標的交易所下單或收 , 單之資料傳送給使用者的交易對手的終端。可以假 0 易中間執行單元112由請求源程式5及交易對手程 供。 應注意，核準路由設定接收單元110可以配置 核準路由資料的輸入接收螢幕資料給使用者端300 介面105，以及，也從使用者終端300或輸入介面 收輸入於輸入接收螢幕中的核準路由資料。輸入接 資料可以配置成包含用於接收包含於核準路由中的 準者的核準授權等級的設定之介面、以及用於接收 Ο 核準路由中的每一核準階段所需的核準者核準授權 • 定之介面。 • 此外’系統100可以配置成將關於每一使用者 者候選人資訊以及候選人的核準授權等級的資料儲 存單元101中。此外，核準路由設定接收單元n〇 下述方式配置。在經由輸入接收螢幕而從使用者端 輸入介面105收到每一核準階段中所需的核準授權 時’核準路由設定接收單元110指定具有等於或大 的設定中所需的核準授權等級之核準授權等級的核 核準路 定請求 在因內 形中， 到的訂 定此交 式6提 成傳送 或輸入 105接 收螢幕 每一核 包含於 等級設 的核準 存於儲 可以以 300或 的設定 於收到 準者候 -19- 200926034 選人，然後，產生核準候選人清單。之後’核準路由設定 接收單元110將核準候選人清單的資料傳送給使用者終端 300或輸入介面150’以及’接收標示核準候選人清單中 選取的核準者之指令。 此外，核準路由設定接收單元110可以配置成將核準 • 路由資料的輸入接收螢幕資料傳送給使用者終端300或輸 , 入介面105，以及，從使用者終端300或輸入介面105, φ 接收輸入接收螢幕中輸入的核準路由資料。輸入接收螢幕 資料包含：用於接收核準路由之核準處理標的之交易中訂 購的產品或售出的產品的屬性設定之介面；用於接收付款 源資訊的介面，付款源資訊是用於會計程序等的資訊；用 於接收核準路由之核準處理標的之交易的交易額度範圍的 設定之介面；及用於接收與使用者藉由使用者終端而發出 的產品或服務的交易請求指令有關的屬性資訊之介面。 此外’核準路由控制單元1 1 1可以配置成從使用者終 ® 端3 00接收產品或服務的交易請求資料，以及，從交易請 • 求資料讀出交易中被訂購的產品或售出的產品的屬性資料 • 、交易的交易額度資料及與發出交易請求指令的使用者相 關的屬性資料。然後，核準路由控制單元ln配置成從儲 存單元101中與發出交易請求資料的使用者終端3 00的使 用者相關連的每一核準路由資料中，選取具有被訂購的產 品或售出的產品的屬性、交易額度範圍、及使用者屬性之 核準路由資料’使用者屬性是設定於符合交易請求資料中 讀出的資料的核準路由資料中。然後，核準路由控制單元 -20- 200926034 111可以根據此處所選取的核準路由資料，執行用於使用 者的內部核準處理。此外，系統100將所有使用者共用的 核準路由資料儲存在儲存單元101中。然後，當選取具有 符合那些交易請求資料的交易屬性之核準路由資料時， 在具有符合那些交易請求資料的交易屬性的核準路由資料 不存在於儲存單元1 0 1中的核準路由資料之情形中（每一 . 核準路由資料與發出交易請求資料的使用者端3 00的使用 0 者相關連）’核準路由控制單元111可以從儲存單元101 中選取共用的核準路由資料。 此外’對每一或多個交易屬性，設定所有使用者共同 的核準路由資料。當選取具有符合那些交易請求資料的交 易屬性之核準路由資料時，在具有符合那些交易請求資料 的交易屬性之核準路由資料不存於儲存單元101中的核準 路由資料中的情形中（每一核準路由資料與發出交易請求 資料的使用者端300的使用者相關連），核準路由控制單 〇 元111從儲存單元101的共同核準路由資料中選取某共同 ' 核準路由資料，該某共同核準路由資料中設定有包含於交 • 易請求資料中的交易之預定屬性資料。 此外，系統100儲存要由設定於核準路由資料中的核 準者所使用的核準終端400的網路上的位址。核準路由控 制單元111可以以下述方式配置。當根據選取的核準路由 資料執行內部核準處理時，核準路由控制單元1 1 1將核準 請求資料與交易客戶資料一起傳送給包含於核準路由資料 中的核準終端400的位址，以及，從核準者終端400中取 -21 - 200926034 得核準者核準或不核準的輸入資料。然後，核 單元U1決定是否從核準路由資料中界定的所 得核準。假使判定從所有核準者取得核準，則 制單元111將決定結果通知交易執行單元。 應注意，系統100中每一功能單元110至 . 硬體或儲存於例如記憶體或HDD (硬碟機）等 . 單元中的程式來實施。在此情形中，當執行程 φ 100的CPU從儲存單元讀出程式以及執行程式 表格結構實施例 接著，將說明根據本實施例的購買操作系; 用的表格的結構。圖2顯示之圖形分別顯示A 屬性125) 、B(核準路由主申請條件126)、 路申主控制127) 的資料結構。 使用者主屬性1 25是記錄組，記錄組中的 〇 存與個別使用者相關的屬性，每一個別使用者 • —使用者終端3 00，發出產品或服務的交易請 ， 例而言，在每一記錄中，以使用者ID作爲鑰 公司碼、辦公室碼及一對應的個別使用者所屬 區碼、核準授權型式及核準授權等級等資料彼 應注意，此處「個別使用者」一詞意指真正地 終端3 00的個人，例如員工或工作人員，其屬 申請專利範圍的範圍中之「使用者」（公司或^ 此外，核準路由申請主條件126是記錄組 準路由控制 有核準者取 核準路由控 1 1 2可以以 適當的儲存 式時，系統 流100所使 (使用者主 及C (核準 每一記錄儲 藉由對應的 求指令。舉 匙，使例如 之公司的分 此相關連。 操作使用者 於本發明的 且織）。 ，每一記錄 -22- 200926034 包含系統1 00所使用以根據交易屬性而選取核準路由資料 之選取條件的說明。在毎一記錄中，使用核準路由定義 ID作爲鑰匙，以及，使例如公司碼、辦公室碼、分區碼 、基本價格範圍（交易額度範圍）、及授權（在多個核準 路由資料是可選取的情形下用於選取核準路由之授權等級 * )等被允許實施此核準路由的資料彼此相關連。 . 此外，核準路由申請主條件1 27是記錄組，每一記錄 φ 儲存用於每一使用者（公司或組織）之每一核準路由資料 的定義內容。舉例而言，在每一記錄中，使用核準路由定 義ID作爲鑰匙，使例如設定接受階段的數目（核準階段 的數目）、均爲關於核準者屬性資訊的核準者公司碼、核 準者辦公室碼、及核準者分區碼、核準者碼、核準者所使 用的核準者終端400的位址、所需的核準授權等級（能夠 給予用於每一核準階段數目之核準者授權等級）、及表示 對應的一核準階段是要求核準之要求旗標彼此相關連。 © 應注意，所有使用者共同的核準路由資料及申請條件 * 設定於核準路由申請主條件126及核準路由主控制127中 * 。在此情形中，如圖9所示，舉例而言，^ @」設定於例 如公司碼、辦公司碼、分區碼、核準授權型式及核準授權 等級等各別資料項中，作爲儲存於核準路由申請主條件 126中的申請條件之一（圖9中的「WF5」）。此「@」 是一記號，代表由「®」標示的條件由所有使用者的屬性 中對應的一屬性所取代並接著被申請。同樣地，「@」設 定在均爲核準者的屬性資訊之例如核準者公司碼、核準者 -23- 200926034 辦公司碼及核準者分區碼等每一資料項中，作爲儲存於核 準路由主控制127中儲存的申請路由資料之—（圖9中的 「WF5」）。對多個交易屬性中的每一屬性，設定所有使 用者共同的核準路由資料。舉例而言，某共同的核準路由 資料對應於公司碼K1至K3，另一共同核準路由資料對應 . 於從「100，000日圓」至「500,000曰圓」的交易額等等。 0 處理流程實施例1 於下’將根據圖式，說明根據本實施例之購買操作處 理方法的真實程序。應注意，對應於下述要說明的購買操 作處理方法之每一型式的操作是以由系統100讀入記憶體 中並執行的程式來實施。此程式由用於執行下述說明的不 同型式的操作之碼構成。 圖3顯示根據本實施例之購買操作處理的處理程序實 施例1。此處，將說明屬於某一合作的購買公司2之客戶 © 使用者購買產品之情形的處理流程。當嘗試登入系統1 00 ' 的客戶使用者經由網路140存取網頁伺服器8的登入程式 ’ 4時，登入程式4將能夠接收使用者ID及密碼輸入的螢 幕資料（此後稱爲登入螢幕）傳送給客戶使用者所使用的 購買公司終端3 50。 爲回應此操作，客戶使用者在顯示於購買公司終端 350上的登入螢幕上輸入使用者ID及密碼及按下的登入 按鍵。接著，輸入的資訊經由網路140，從購買公司終端 350傳送給網頁伺服器8的登入程式4。 -24- 200926034 網頁伺服器8的登入程式4經由網路140查詢DB伺 服器9的使用者主屬性125，然後，決定購買公司終端傳 送來的密碼是否正確，同時，取出公司識別區、公司碼、 辨公司碼（此後稱爲客戶使用者資訊）、核準等級及客戶 使用者授權等每一資料（S301 )。 * 接著，登入程式4決定步驟S301中取出的客戶使用 . 者授權的種類（步驟S3 02 )。假使授權爲「客戶」，則 @ 登入程式4將顯示能夠分別執行產品搜尋功能1 〇及訂單 請求功能11的螢幕顯示鍵（此後稱爲客戶選單螢幕）之 資料傳送給客戶使用者所使用的購買公司終端3 50 (S303 )。另一方面，假使客戶使用者的授權是非「客戶」授權 時，登入程式4將能夠顯示允許其它授權中的每一授權之 功能的按鍵傳送給合作的購買公司終端350。 當在購買公司終端3 50中客戶使用者按下客戶選單螢 幕上顯示的產品搜尋鍵時，執行請求經由網路140從購買 ❹ 公司 終端3 5 0傳送至網頁伺服器8的產品搜尋功能1 〇 ( ' S3 04 ) ° ' 在收到執行請求時，網頁伺服器8的產品搜尋功能1 〇 將能夠接收用於搜尋產品的條件輸入之螢幕（此後稱爲產 品搜尋螢幕）的資料傳送給客戶使用者的購買公司終端 3 5 0 ( S3 05 )-> 當客戶使用者在顯示於購買公司終端350上的產品搜 尋螢幕上輸入搜尋條件及按下搜尋鍵時，搜尋條件經由網 路140從購買公司終端35〇傳送至網頁伺服器8的產品搜 -25- 200926034 尋功能1 〇 ( s 3 0 6 )。 網頁伺服器8的產品搜尋功能1 〇根據從購買公司終 端350傳送來的搜尋條件，從DB伺服器9的產品資料中 取出符合搜尋條件的產品資料。然後，產品搜尋功能1 〇 將顯示取出結果的螢幕（此後稱爲搜尋結果螢幕）之資料 • 傳送給客戶使用者的購買公司終端3 50 ( S307 )。 . 當客戶使用者從顯示於購買公司終端350上的搜尋結 〇 果螢幕選取客戶使用者發出訂單請求的產品、按下訂單產 生鍵時，執行請求會經由網路140而從購買公司終端350 傳送至網頁伺服器8的訂單請求功能11 (S308)。 在從購買公司終端3 50收到執行請求時，網頁伺服器 8的訂單請求功能11將能夠接收與使用者選取的產品之送 貨資訊、付款源資訊及核準者資訊有關的輸入之訂單請求 產生螢幕（此後稱爲訂單請求產生螢幕）的資料經由網路 140而傳送給客戶使用者的購買公司終端35〇(S3〇9)。 ® 此後，此輸入資訊稱爲訂單請求資訊。當客戶使用者在輸 • 入訂單請求資訊並以下述說明的處理方法指定核準者之後 . 按下訂單請求鍵時（S310)，產品資訊、送貨資訊及付款 源資訊會經由網路140，從購買公司終端35〇傳送給網頁 伺服器8的訂單請求功能u。在從購買公司終端35〇收到 g 丁單請求資訊時，訂單請求功能n將資訊當作訂單請求 事項寫入DV伺服器的訂單資料及訂單歷史資料中（S311 )° 應注意，在步驟S 3 1 1之前，根據訂單請求功能丨i自 -26- 200926034 動選取的核準路由資料、包含客戶使用者所指定的核準者 之核準路徑資料，執行內部核準處理。以訂單請求功能1 1 將訂單請求資料與訂單請求資訊（交易請求資料）一起傳 送給包含於自動選取的核準路由資料中的核準者的核準者 終端400的位址之方式，執行此處理。然後，從核準者終 • 端400接收表示核準者核準或不核準的輸人資料。之後， . 決定是否從核準路由資料中界定的所有核準者取得核準。 φ 假使判定從核準路由資料中界定的所有核準者取得核準， 則執行步驟S 3 1 1。 處理流程實施例2 接著，將說明處理流程實施例之步驟S308至S311中 用於自動選取核準路由及設定核準者之處理。圖4顯示根 據本實施例之購買操作處理方法的處理程序實施例2。應 注意，請求源程式5的訂單請求功能11規劃有訂單請求 〇 螢幕顯示幕組5a、核準者設定螢幕顯示模組5b、核準者 ' 清單螢幕顯示模組5c及訂單請求產生模組5d。 • 在客戶使用者在處理程序實施例1的步驟308中按下 訂單請求產生鍵，接著，在步驟S 3 09中經由網路140而 由網頁伺服器8接收執行請求之後（S501)，訂單請求螢 幕顯示幕組5a將圖5中所示的訂單請求產生螢幕G601傳 送給客戶使用者的購買公司終端350(S502 )。 客戶使用者在訂單請求產生螢幕G601中輸入要購買 的每一產品的付款源資訊G6 02，以及，按下核準者設定 -27- 200926034 鍵G603。然後’將此執行請求經由網路140從購買公司 終端350傳送給網頁伺服器8的核準者設定螢幕顯示模組 5b ° 在收到執行請求之後，核準者設定螢幕顯示模組5b 使用步驟S301中取得的客戶使用者屬性、步驟S308中客 • 戶使用者所選取的產品資訊、及訂單請求產生螢幕G601 . 上指定的付款源資訊G602作爲申請條件，然後，經由網 φ 路140，從DV伺服器9的核準路由申請主條件126中取 出符合這些申請條件的核準路由定義ID。在不存在有符 合申請條件的此種核準路由定義ID的情形中，執行錯誤 處理。 另一方面，在存在有符合申請條件的此種核準路由定 義ID的情形中，核準者設定螢幕顯示模組5b藉由使用取 出的核準路由定義ID作爲鑰匙以從核準路由主控制1 27 取出所有可申請的核準路由資料（S 504 )。 Φ 核準者設定螢幕顯示模組5b從核準路由主控制127 • 中取出的每一核準路由資料中取出每一設定接受階段號數 • 的要求旗標、以及取出設定接受階段號數中最大的値。然 後，核準者設定螢幕顯示模組5b將核準者設定螢幕G70 1 經由網路140傳送給客戶使用者的購買公司終端350( S5 05 )，核準者設定螢幕G701顯示等於或大於設定接受 階段號數的最大値之核準者設定欄的數目、設定核準階段 的號數的每一欄位中標示「要求的」或「選項的」的資訊 、及核準者搜尋鍵G702 (請參考圖6)。 -28- 200926034 當客戶使用者按下顯示於購買公司終端350 準者設定螢幕G701上的每一核準階段欄之核準 G702時，此執行結果及對應的搜尋鍵的核準 G703的資料會經由網路140而從購買公司終端 給網頁伺服器8的核準者清單螢幕顯示模組5c ( • 在收到來自購買公司終端350的執行請求時 , 清單螢幕顯示模組5c藉由使用步驟S504中取出 φ 由定義ID及從客戶使用者的購買公司終端350 核準階段號數G703的資料作爲鑰匙，查詢DB 的核準路由主控制127中可申請的資料。此外， 單螢幕顯示模組5c藉由使用此處查詢的資料中 準者公司碼、核準者辦公室碼、核準者分區碼、 準等級及核準者碼作爲鑰匙，以從使用者主屬性 出可特別用於可申請的核準階段號數之核準者使 (S507)。此時，要被取出的核準者需爲具有等 〇 所需的核準等級之核準等級的使用者。 • 接著，訂單請求功能1 1將核準者清單螢幕 - 5C所取出的核準者使用者資訊傳送給客戶使用者 司終端350作爲圖7中所示的核準者清單螢幕 S508 ) »當客戶使用者從核準者清單螢幕G801 請求功能11傳送來的核準者清單中設定的核準 下選取鍵G802時，核準者（在圖式的實施例中 者2」）被設定在核準者設定螢幕G704的如圖 核準者設定螢幕的可申請階段號數（在圖6中；| 上用於核 者搜尋鍵 階段號數 3 50傳送 S5 06 ) ° ，核準者 的核準路 傳送來的 伺服器9 核準者清 設定的核 需要的核 125中取 用者資訊 於或大於 顯示模組 的購買公 ；G801 ( 選取訂單 者以及按 爲「使用 6所示的 -29- 200926034 重複步驟S506至步驟S509的處理直到客戶使用者設 定均需要指定核準者之所有核準階段號數的核準者。當客 戶使用者在完成對所有核準者的設定時，按下購買公司終 端350上顯示的核準者設定螢幕的申請鍵G705時，顯示 • 客戶使用者所設定的一序列核準者（換言之，他們可以被 . 稱爲核準路由）。 II 在對購買產品重複地執行步驟S503至步驟S509中所 要求的處理之後，客戶使用者按下訂單請求產生螢幕的訂 單請求產生鍵。此時，購買公司終端350檢查是否有遺失 的要求的核準者設定以及關於核準者及核準路由的組織資 訊是否與對應於每一產品的訂單請求一致。假使未發現此 遺失的設定，則訂單請求產生資料會經由網路140而從購 買公司終端350傳送至訂單請求產生模組5d。訂單請求產 生模組5d將從購買公司終端3 50收到的資料傳送給DB伺 〇 服器9作爲訂單請求事項及將此事項登記作爲訂單請求資 • 料及訂單歷史資料（S5 10 )。 核準路由自動選取控制實施例1 圖8顯示使用者主屬性、核準路由申請主條件126及 核準路由主控制127的設定實施例、以及核準路由的自動 選取控制的實施例。在本實施例中，三個不同的核準路由 定義 ID 被定義爲 WF1(D911) 、WF2(D912)及 WF3( D913)。此外，對於核準路由定義ID所述的資料，當屬 -30- 200926034 於公司碼「K1」、辦公室碼「001」及分區碼「Α」的客 戶使用者發出核準請求時，WF1 (D911)及WF2 (D912) 是要被取出的資料。此外，在購買產品的單價不小於 1〇,〇〇〇日圓時，應用核準者定義ID的資料WF2(D912) 。對於其它情形，應用核準者定義ID的資料WF1 ( D91 1 - )〇 • 此外’在屬於具有公司碼「K2」的公司的客戶使用者 φ 之情形中，應用核準者定義ID的資料WF3 ( D913 )。在 核準路由主控制127中，對每一核準路由定義ID WF1至 WF3 ( D9 1 1-D9 13 )的每一核準階段的號數，設定能夠給 予核準的核準者的申請條件。在這些設定實施例中，同樣 地，對用於核準者定義ID的資料WF1 ( D921 )，將核準 階段號數設定爲一階段，對用於核準者定義ID的資料 WF2 ( D922 至 D923 )及 WF3 ( D924 至 D925 )設定爲二 階段。 Φ 關於核準路由定義ID的第一階WF1(D911)的核準 • 者，需要具有公司碼「K1」、辦公室碼「001」及核準等 • 級不小於「1」的核準者。關於核準路由定義ID WF2 ( D912)，對第一階段可應用與核準路由定義IDWF1( D921 )相同的設定。除此之外，核準路由主控制127的核 準路由（D923 )中的第二階段需要具有核準等級2或更大 且屬於分區碼B之核準者。此外，對於核準路由定義ID WF3 ( D9 1 3 )，核準路由主控制127的核準路由（D924) 中的第一階段需要具有公司碼「K2」、辦公室碼「111」 -31 - 200926034 、分區碼「B」及核準等級等於或大於「1」的核準者。此 外’在核準路由（D925 )中，可以選加地設定與D924的 情形具有相同的公司碼及辦公室碼、且分區碼「C」及核 準等級等於或大於「2」的核準者。 舉例而言，考慮使用者1 ( D901 )發出價格100日圓 • 的產品之核準請求的情形（實施例1 )。當客戶使用者在 . 步驟S 503按下核準者設定鍵時，訂單請求功能n使用關 0 於客戶使用者的聯合資訊之公司碼「K1」、辦公室碼「 001」、分區碼「A」、以及產品的購買價格「100日圓」 作爲申請條件並因而從核準路由申請主條件126取出可申 請的核準路由定義ID。此時，由於用於「WF1」的單價之 條件是購買產品的額度小於1 0,000日圓，所以，在它們 的申請條件中均具有公司碼「K1」的申請路由ID「WF1」 (D911)及「WF1」 （D912)中，取出「WF1」 （D911) 作爲可申請的路由定義ID。 Φ 訂單請求功能11使用核準路由定義ID「WFlj作爲 • 鑰匙並因而從核準路由主控制127中取出可申請的資料（ . D921 )。由於取出的核準路由資料D921的設定接受階段 數目僅爲一（要求的），所以，在步驟S505中，訂單請 求功能11將僅顯示一核準指定欄位的核準者設定螢幕傳 送給客戶用者的購買公司終端350。 此外，當客戶使用者在步驟S 5 06中按下核準階段號 數「1」的核準者搜尋鍵時，在步驟S 5 0 7中，訂單請求功 能11取出使用者3(D903)及使用者4(D9 04 )的資料 -32- 200926034 ，使用者3(D903)及使用者4(D904)均具有核準者公 司碼「K1」、核準者辦公室碼「〇〇1」' 授權「核準者」 、及具有等於或大於「1」的所需核準者等級，這些都是 設定於藉由使用核準路由定義ID「WF1」及設定接收階段 「1」而取出的核準路由資料D921中。 . 在步驟S508中，訂單請求功能11將取出的使用者3 , (D903 )及使用者4 ( D904 )的資料作爲清單螢幕傳送給 φ 客戶使用者的購買公司終端350。此外，在步驟S5〇9中 ，客戶使用者從清單螢幕取出核準者以及設定核準者。 類似地，在使用者（D901)購買價格20,000日圓的 產品之情形中（實施例1 )，雖然「WF1」（D91 1 )及「 WF2」 （D912)均符合作爲步驟S504中取出的核準路由 定義ID之條件，但是，在此情形中，應用具有更高優先 權的「WF2」（D912 )。訂單請求功能1 1使用核準路由 定義ID「WF2」 （D912)作爲鑰匙並因而從核準路由主控 〇 制127中取出可申請的核準路由資料（D922 )及（D923 • )。由於用於取出的資料之設定核準階段的號數爲「1」 - 及「2」，所以，在步驟S505中，訂單請求功能11將顯 示核準階段指定攔的核準者指定螢幕傳送給客戶使用者的 購買公司終端3 5 0。 客戶使用者對第一及第二核準階段等每一階段重複步 驟S 506至S 509的處理，並因而指定核準者。此使，如同 實施例1的情形般，在步驟S507的處理中，在第一階段 中需要設定使用者3(D903 )或使用者4(D9〇4) ’以及 -33- 200926034 在第二階段中需要設定屬於公司碼「κι」、辦公室碼「 001」、及具有等於或大於「2」的核準等級之核準者。因 此，僅有使用者4 (D904)可以被設定爲核準者。 應注意，核準路由中所需的核準等級也可以被設定爲 用於客戶使用者。舉例而言，在具有核準等級1的客戶使 • 用者：使用者2 ( D902 )購買價格20,000日圓的產品之情 . 形中（實施例3)，在步驟S504中要取出的核準路由定 φ 義ID如同（實施例2)的情形般爲「WF2」（D9 12)。但 是，由於客戶使用者：使用者2( D902 )的核準等級爲1 ，所以，判定客戶使用者也具有第一階段（D922 )的核準 授權，第一階段（D922 )的核準授權具有所需的核準等級 「1」。因此，在步驟S505中，將未顯示第一核準階段的 核準者指定欄位但僅顯示第二核準階段的核準者指定欄位 之核準者指定螢幕，傳送給客戶使用者的購買公司終端 350。客戶使用者藉由同於實施例2中用於在第二核準者 〇 階段的核準指定欄位中指定核準者之處理，指定核準者。 • 此外，在屬於公司碼「K2」的使用者：「使用者5」 . (D905 )購買產品（實施例4 )的情形中，以訂單請求功 能11取出核準路由定義ID「WF3」 （D913)(由於辦公 司碼及分區碼未設定於申請條件中，所以，對所有屬於公 司碼「K2」的使用者取出核準路由定義ID「WF3」）。此 外，訂單請求功能1 1使用核準路由定義ID「WF3」作爲 鑰匙並因而從核準路由主控制127取出核準路由資料（ D924 )及（D925 )。由於定義用於第二階段的核準者之 -34- 200926034 核準路由資料（D92 5 )是選加設定，所以，在步驟S5 05 中，訂單請求功能11將在第一及第二階段的核準者指定 欄位中分別顯示「要求設定」及「選加設定」的核準者設 定螢幕傳送給客戶使用者的購買公司終端350。 當客戶使用者在步驟S506至S509中指定核準者時， • 要求指定第一核準階段的核準者（在步驟S5 07的處理中 - 要取出的核準者爲「使用者6」（D906 ))。但是，指定 φ 第二階段中的核準者是選加的，以致於適當地指定核準者 。當核準者要被設定於第二階段時，如同第一階段的情形 般，藉由執行步驟S506至S509的處理，以設定核準者（ 在步驟S507的處理中要取出的核準者爲「使用者7」（ D907 ))。 核準路由自動選取控制實施例2 接著，將使用圖9，說明眾多購買公司2使用共同核 〇 準路由（核準規則）的情形之定義核準路由的方法及自動 • 選取處理方法。在眾多購買公司2使用共同核準路由的情 • 形中，對於在核準路由申請主條件126及核準路由主控制 127中具有相同內容的核準路由資料之每一購買公司2而 言，在改進或消除主條件或主控制時時會增加問題。此外 ，爲了避免執行發生於要應用的核準路由定義在步驟 S5 〇4中並不存在的情形下的錯誤處理，較佳的是預先設 定定義，此定義可以由購買公司2廣泛地使用以及應用於 個別設定的核準路由資料與應用條件不相符之情形。 -35- 200926034 在上述情形中，如圖9所示，藉由將「@」設定在核 準路由申請主條件126及核準路由主控制127每一項中， 使得核準路由的每一申請條件是可以讀取及可由對應的客 戶使用者的屬性之一所取代（已於圖2中說明）。舉例而 言’在圖9中’核準路由定義id「wF4」 （D1011)是公 • 司碼「K3」的獨特定義，而「WF5」 （D1012)是所有購 - 買公司共同的核準路由的定義，包含設定於公司碼、辦公 φ 室碼及分區碼中的「@」。 在屬於公司碼「KF 3」的客戶使用者：「使用者8」 (D 1 0 0 1 )購買單價1 〇 〇日圓的產品之情形中（實施例5 )，在步驟S504中要由訂單請求功能11取出的核準路由 定義 ID 爲「WF5」 （D1012)加上「WF4」 （D1011)， 「WF4」（D1011 )係被個別地定義用於具有公司碼「K3 」的公司。此時，關於核準路由定義ID「WF5」 （D1012 )，訂單請求功能1 1分別以「K3」、「0 〇 1」及「A」等 Ο 關於「使用者8」（D1 001 )的屬性資訊取代設定作爲公 • 司碼、辦公司碼及分區碼的「@」。 - 在本實施例中，客戶使用者·· 「使用者8」（D1001 )是要購買單價100日圓的產品，以及當單價耒小於 1 0,000日圓時應用核準定義ID「WF4」 （D1011)。 訂單請求功能11使用核準路由定義ID「WF5」（ D1012)作爲鑰匙並因而從核準路由主控制127取出可應 用的核準由資料（D1023)。此外，由於核準路由資料（ D1023)包含核準者公司碼「@」、核準者辦公司碼「@」 -36- 200926034 及核準者分區碼「@」，所以，當在步驟S507中取出用 於核準階段號數「1」的核準者清單時，訂單請求功能11 讀取這些碼碼中的「@」記號並分別以客戶使用者的公司 碼「K3」、辦公司碼「001」及分區碼「A」取代之。此 外，從使用者主屬性125取出屬於相同組織之作爲客戶使 - 用者的核準者使用者「使用者9」（D1 002 )。 . 此外，使用者主屬性125的「公司識別碼」是用於將 @ 多個公司分組（聯合公司、等等）的定義。因此，雖然在 本實施例中省略下述的說明及實施例，但是，如同公司碼 等被設定於核準路由申請主條件126中的情形般，「公司 識別碼」可以作爲用於核準路由的申請之申請標準。 根據本實施例，即使在能夠由具有不同核準標準之眾 多公司或組織共同使用的環境中（以邏輯方式分割系統資 源之環境，例如ASP)，每一公司或組織仍然能夠使用其 自己獨特的核準規則（核準路由）。此外，在共同核準標 φ 準由眾多公司或組織採用的情形中，藉由使用共同核準規 • 則以控制例如主資料等不同資料的設定量，而簡化資料的 . 維護及管理。根據上述效果，可以降低核準處理程式等的 發展及操作處理的數目，同時，可以維持設於購買操作系 統中的功能的多樣性。此外，由於不需要傳統系統中所使 用的資料鏈結處理’所以，可以以適當成本實現購買操作 系統。 因此’在購買操作系統的每一使用者使用共同的程式 資源的假設下’每一使用者能夠定義及使用其自己獨特的 -37- 200926034 核準規則。 應注意’雖然上述以用於非直接材料或直接材料之網 路耦合購買操作系統爲例說明，但是，本發明也可以應用 至均具有關於系統的使用者的組織資訊及使用視內容而變 的核準工作流程的所有操作系統。舉例而言，本發明可以 - 應用至用於相同組織中、或多個組織中的管理核準事務、 . 內部報告流通操作、等等之操作系統。 ^ 如上所述，已以實施例爲基礎來提供本發明的實施例 。但是，本發明不限於此。在不悖離本發明的精神及範圍 之下，可以對實施例作不同的修改。 【圖式簡單說明】 圖1是根據本實施例之購買操作系統的整體配置圖； 圖2A至2C分別顯示根據本發明的實施例之使用者主 屬性、核準路由申請主條件及核準路由主控制的資料結構 φ 實施例； • 圖3是流程圖，顯示本實施例的購買操作處理方法的 - 處理程序1 ; 圖4是流程圖，顯示本實施例的購買操作處理方法的 處理程序2 ; 圖5顯示本實施例的訂單請求產生螢幕的實施例； 圖6是顯示本實施例的核準者設定螢幕的實施例； 圖7是核準者清單螢幕； 圖8顯示根據本實施例的核準路由的自動選取控制實 -38- 200926034 施例1 ; :及 圖 9顯示根據本實施例的核準路由的自動選取控制實 施例2 [ > 【主要元件符號說明】 . 2 ： 3 : 購買公司 交易對手公司 〇 4 : 5 : 登入程式 請求源程式 5 a :請單請求螢幕顯示模組 5b :核準者設定螢幕顯示模組 5 c :核準者清單螢幕顯示模組 5d :請單請求產生模組 6 : 交易對手程式 7 ： ⑩ 8 : 資料庫 網頁伺服器 ， 9 ： DB伺服器 . 10 :產品搜尋功能 11 =訂單請求功能 12 :核準功能 13 :訂單下單歷史管理功能 14 :訂單接收功能 15 :出貨登錄功能 100 :購買操作系統 -39- 200926034200926034 IX. Description of the Invention [Technical Field of the Invention] The present invention relates to a purchase operating system, a purchase operation processing method, and a purchase operation processing program. In particular, the present invention relates to technologies that can be used in environments (ASPs, etc.) that are commonly used by companies or organizations with different approval standards. The techniques allow individual companies or organizations to use common program resources and set and use. It has its own unique approved route. [Prior Art] Regarding the company's purchase of an operating system, for example, many purchasing companies or organizations usually use the same system to reduce operating costs and achieve cooperative purchases. The design (ASP, etc.) used to purchase an operating system that performs such operations logically separates the resources of a single system, enabling a plurality of purchasing companies or organizations to use a single system. In this design, program resources are shared by multiple companies or organizations. Such an approval function for purchasing an operating system is usually based only on two or three stages of approval rules corresponding to the purchase amount, and the approval rules are predetermined in the purchase operating system. In the case where a purchasing company or organization uses an approval rule specific to a company or organization rather than a predetermined approval rule in the system, for example, the company or organization is linked with information only about the purchase order. To purchase the operating system in a systematic way. More specifically, in this way, before entering the information about the purchase order, the company or organization inputs the information about the product to be purchased into the system itself operating individually, and operates the individual operating system to confirm the purchase. Approval. For an example of such a method, please refer to the non-patent literature -5-200926034 The following website: http://www. Withkaunet. Com/top/infol3. Html, http://www. Withkaunet. Com/top/info3. Html, and http://www. Webmethods. Co. Jp/pdf/Biz. Pdf. As mentioned above, in a traditional purchase operation processing environment that can be used by a large number of k companies or organizations with different approval standards (in the system). The source is logically partitioned, such as A S P ), and individual companies or organizations Q use common program resources. In the case where individual companies or organizations are required to implement their own unique approval criteria in the purchase operating system in this environment, the general functions and services included in the purchase of the operating system are not practical, therefore, . Whenever an operating system is purchased and adjusted to a unique approval standard, the individual development costs are added to the company or organization. As a result, the cost burden of individual companies or organizations will increase. Meanwhile, even if the link method described in the above non-patent literature is used to avoid this problem, individual companies or organizations must bear the system development cost and the operation cost. ❹ ' [Contents of the Invention] The present invention has been made in consideration of the above problems. It is an object of the present invention to enable each user to define and use their own unique approval rules on the assumption that each user uses a common program resource. The purchase operating system of the present invention provides a system for use by a plurality of users such as companies and organizations, and an intermediate process of executing transactions of products, services, and the like among a plurality of users. The system provided includes an approved routing setting receiving unit for receiving from each of the plurality of users a user-input or input interface input for each of the plurality of users for each of the plurality of users. The approved routing data of the user, and the approved routing data thus received are stored in the storage unit, and the approved routing data is the approval of the internal approval required by each of the plurality of users of the product or service transaction. The routed data 'and the approved route data contain the attributes of the transactions that are associated with each other as the core* standard and the attributes of the approver required for approval; the approved route is used by the control unit to receive products or services from the user terminal. The transaction φ asks for the data 'then, and is used to select the approved routing data of the transaction attribute whose transaction attribute meets the transaction request data from the approved routing data associated with the user terminal of the user who sent the transaction request data in the storage unit. And 'for the approved routing data selected here to perform internal approval processing for the user And the transaction intermediate execution unit, in the case where the approval is obtained from the required approver due to the result of the internal approval process, the information of the order placed or received in the transaction as the approved subject is transmitted to the user's counterparty. terminal. Purchasing an operating system in accordance with the present invention enables each company or organization to implement its own unique approval criteria on the purchase operating system under the assumption that each user of the operating system uses a shared program resource. The problem caused by the prior art is solved by the assumption that each user who purchases the operating system uses the common program resources. These issues include the general diversity of versatility in the purchase of operating systems and the reduction in service and the cost burden of individual developments each time a response is taken to each approved standard. Therefore, each user can define and use their own unique core -7 - 200926034 quasi-rules under the assumption that each user of the operating system uses a shared program resource. Further, in the above-mentioned purchase operating system, the approval route setting receiving unit is configured to transmit the input receiving screen data for inputting the approved routing data to the user terminal or the input interface, and receive the input receiving camp from the user terminal or the input interface. Approved routing data entered in the screen. In addition, the input receiving screen data is configured to include: an interface for receiving an approval authorization level of each approver included in the approved route; and for receiving each of the approval stages included in the approved route The interface for setting the approval authority level of the required approver. According to the above configuration, with respect to the approved routing data, an approver having an appropriate authorization level in each of the approval phases can be set. The effect of the invention of the present application that enables each user to set their own unique approved routes can enhance the flexibility of each user to set their own unique approved routes. Further, in purchasing an operating system, information about an approver candidate for each of the plurality of users and an approval® authorization level for the approver candidate is stored in the storage unit, and When the setting of the approval authority level required in each approval phase is received from the user terminal or the input interface via the input screen, the approval route setting receiving unit specifies that the storage unit has a setting equal to or greater than the one received here. The approver candidate of the approved authorization level of the required authorized level of approval, then 'generate the list of approver candidates, and then transmit the data of the approver candidate list to the user terminal or the input interface and from the approver The list receives instructions indicating the selected approver. According to this configuration, for the user-set approver, the efficiency of the process for determining the approver of the -8-200926034 is enhanced, and at the same time, the approver who is not required to have the required approval level is erroneously set in the approved routing data. The situation in the middle. In addition, in the purchase operating system, the approved routing setting receiving unit is configured to transmit an input receiving screen data for inputting the approved routing data to the user terminal or the input interface, and receive from the user terminal or the input interface. Enter the approved routing data entered on the input receiving screen. In addition, the φ input receiving screen data is configured to include: an interface for receiving attribute settings of the ordered product and the sold product in the transaction, the transaction is an approval processing target in the approved route; and is used for receiving an accounting program, etc. The interface of the payment source information; the interface for receiving the setting of the transaction amount range of the transaction, the transaction is the approval processing target of the approved route; and the use of the transaction request for receiving the product or service by using the user terminal Related attribute settings. According to this configuration, regarding the approved routing data, the detailed transaction © content can be set as the transaction 'to be used as a standard for automatically selecting the approved route'. This increases the effect of each user increasing their ability to set their own approved routes. Further, in the above-mentioned purchase operating system, the approval route control unit receives the transaction request data of the product or service from the user terminal, and reads the products ordered and the products sold in the transaction request data read transaction thus received. Attribute data, transaction amount data of the transaction, information of the payment source, and attribute data related to the user who issued the transaction request instruction. In addition, the approved routing control unit is configured to select from the approved routing data associated with the user of the user terminal that issued the transaction request -9-200926034 data in the storage unit, and select and set in the approved routing data and read from the transaction request data. The obtained data is consistent with the approved routing data of the products ordered and the attributes of the products sold, the transaction amount range, the payment source information, and the attributes of the user'. Then, according to the approved routing data selected here, the execution is used for use. Internal core* quasi-processing. I According to this configuration, the detailed transaction Φ content can be set as the transaction attribute to be used as a standard for automatically selecting an approved route. This increases the effect of each user increasing their ability to set their own approved routing resilience, or the effect of allowing the appropriate routing to be selected based on the details of the transaction. In addition, in the above-mentioned purchase operating system, the approved routing data shared by the plurality of users is stored in the storage unit, and when the transaction attribute matching the transaction attribute of the transaction attribute of the transaction request data is selected, the transaction attribute conforms to the transaction request. The approved routing data of the transaction attribute of the data does not exist. In the case where the storage unit is in the approved routing data associated with the user of the user terminal that issued the transaction request data, the approved routing control unit-yuan is selected. Approved routing data shared by users. According to this configuration, each user can set his own approved route. At the same time, it is possible to control the physical capacity of the approved routing data to be registered in the storage unit, and the physical capacity of different master data used to approve the routing data setting, and also simplify the data maintenance and management in the storage unit. Therefore, the potential cost of the system can be reduced. In addition, in the above-mentioned purchase operating system, the -10-200926034 approved routing data shared by a plurality of users is set for each of the transaction attributes. In the above-mentioned purchase operating system, when the selected routing attribute of the transaction attribute of the transaction request data is selected, the approved routing data of the transaction attribute whose transaction attribute meets the transaction request data does not exist in the storage unit and the transaction request data is issued. In the case of the approved routing data associated with the user of the user terminal, the approved routing control unit selects an approved routing data shared by multiple users from the approved I routing data shared by multiple users, and multiple The approved routing data shared by the user includes predetermined attribute data of the transaction included in the transaction request data. According to this configuration, it is possible to control the physical capacity of the approved routing material to be registered in the storage unit, and the physical capacity of the different main materials for approval of the routing data setting, and also simplify the data maintenance and management in the storage unit. At the same time, the approved route based on the transaction attribute can be automatically selected. Therefore, data maintenance and management can be simplified and approved routes can be appropriately selected. In addition, in the purchase operating system, the address of the approver terminal used by the approver set in the approved routing data © on the network is stored, and when the internal approval processing is performed based on the selected approved routing data, the approval* The routing control unit transmits the quasi-request data together with the transaction request data to the address of the approver terminal included in the approved routing data, and then obtains input data indicating the approval or disapproval of the approver from the approver terminal, and then determines Whether or not the approval of all approvers defined in the approved routing data is obtained, and if the determination is to obtain the timing from all the approvers defined in the approved routing data, the outcome of the decision is notified to the transaction executing unit. According to this configuration, the purchase operating system automatically selects -11 - 200926034 to take the approved route according to the transaction attribute. The approval data acquisition by the approver is automatically performed according to the automatically selected approved route, and the processing to be performed after the approval data is obtained is executed. Therefore, the user no longer needs to perform the internal approval process separately according to the approved route. Further, the purchase operation processing method according to the present invention is executed by a computer. The computer is used by a plurality of users such as a company and an organization, and performs intermediate processing of products, services, and the like among a plurality of users. The method of providing 〇 includes the steps of: receiving approved routing data for each of a plurality of users from a user terminal or input interface used by the user, and receiving the approved route thus received The data is stored in a storage unit, and the approved routing data is information about an internally approved approved route required by each of a plurality of users of the product or service transaction, and the approved routing data includes each other as an approval The attribute of the target transaction and the attribute of the approver required for approval; receiving the transaction request data of the product or service from the user terminal, and then, from the storage unit, the user terminal of the user who issued the transaction request data The relevant approved routing data selects the core-quasi-routing data of the transaction attribute of the transaction attribute in accordance with the transaction request data, and performs the internal approval processing for the user according to the approved routing data selected here; and The result of the treatment and the approval of the required approver will be used as approval Of the transactions or orders received orders for data transmission to the user terminal counterparties. According to the purchase operation processing method 'under the assumption that each user of the operating system uses the shared program resources', each user can implement its own unique approval standard on the purchase -12-200926034 Η operating system. The problem caused by the prior art is solved by the assumption that each user of the purchase operating system uses the common program resources. These issues include the general diversity of versatility in the purchase operating system and the reduction in service and the cost burden of each individual development of each response to each of the approved standards. Therefore, each user can define and use his own unique approval rules under the assumption that each company or organization can use a shared program resource for each user who purchases an operating system. According to the purchase operation processing program of the present invention, a computer which is used by a plurality of users such as a company and an organization, and an intermediate process for executing transactions of products, services, and the like among a plurality of users, performs the following steps: The user terminal or the input interface input used receives the approved routing data for each of the plurality of users, and stores the approved routing data thus received in the storage unit, and the approved routing data is related to the product. Or the information of the internal/approved approved route required by each of the plurality of users of the service transaction, and the approved routing information includes the attributes of the transaction as the approved subject and the approval required for approval - the attribute request; receiving the transaction request data of the product or service from the user terminal, and then selecting the transaction attribute from the approved routing information associated with the user terminal of the user who sent the transaction request data from the storage unit Approved routing data for the transaction attributes of the requested data, and, based on the core selected here Routing data to perform internal approval processing for the user; and in the case where the approval is obtained from the required approver due to the result of the internal approval processing, the information of the order placed or received in the transaction as the approved subject - 13- 200926034 The terminal of the counterparty transmitted to the user. The purchase of an operating system in accordance with the present invention enables each company or organization to implement its own unique approval criteria on the purchase operating system under the assumption that each user of the operating system uses the shared program resources. The problem caused by the prior art is solved by the assumption that each user who purchases the operating system uses the common program resources *'. These issues include the general diversity of versatility in the purchase of operating systems and the reduction in service and the cost burden of individual developments each time φ responds to each approved standard. Therefore, each user can define and use their own unique approval rules under the assumption that each user of the operating system uses a shared program resource. Further, the problems disclosed in the present application and their solutions will be more apparent from the "Embodiment" section and the accompanying drawings. According to the present invention, each user can define and use his or her own unique approval rule under the assumption that each user of the operating system uses a shared program resource. [Embodiment] System Configuration Hereinafter, an embodiment of the present invention will be described in detail using the drawings. FIG. 1 is a configuration of a purchase operating system 100 according to the present embodiment. The purchase operating system 100 (hereinafter referred to as the system 100) according to the present embodiment is a computer system shared by a plurality of users such as companies and organizations, and performs intermediate processing such as products and services between users. This system i can be said to be 14-14 200926034 for many purchase companies with different approval standards 2 or the organization can perform cooperative purchase operation environment (the environment in the system is logically divided environment, such as ASP) computer . In addition, many companies 2 and their counterparty companies 3 can simulate the use of computers via a network such as the Internet. * Thus, it can be assumed that system 100 is a server device 'server device* coupled via network 140 to a large number of user terminals 300 (preferably 'also φ for approver terminal 400) for transaction between processing user terminals During the product or service period, the venue is provided on the Internet as an electronic marketplace, as well as 'executing product searches, orders placed or orders received, transaction history management and approval processing. Between the user terminals 00, the user terminal used by the purchasing company 2 and performing the purchasing operation of the product or service is referred to as the purchasing company terminal 350, and is used by the counterparty company 3 and both are received from the purchase. The user terminal that submits the product or service when the company 2 orders is called the counterparty company terminal 360. In addition, the system 100 includes a login program 4, a request source program 5, and a counterparty program 6 in the storage unit 101. The request source program 5 provides the following - function: the product search function 1 used by the purchasing company 2 searches for the product to be placed; the order request function 1 1, receives the order from the purchasing company 2, and then processes the order; the approval function 1 2, according to each user's individual approved route to perform the approval process; and the order history management function 13, manage the historical data of the order under the user. Further, the counterparty program 6 provides a order receiving function 14 and a shipping registration function 15. The order receiving function 14 receives the order from the purchasing company 2, and the shipping registration function 15 logs in to indicate the counterparty -15- 200926034. The company 3 has executed the shipping processing information for the applicable products and the like according to the order, and the like. It should be noted that the user authorization associated with the purchase operation is assumed to be "customer" or "approver". Regarding the purchase process, a user belonging to each purchase company 2 and having a "customer" authorization (hereinafter referred to as "customer use") is logged into the system 100 by using the login program 4, and then, by using the request source program 5 product search function 1 订单 and order request function 1 1 φ 'Generate approval request data. On the other hand, a user authorized by the "Approver" (hereinafter referred to as "Approved User") is executed by using the login program 4 to log in to the system 100 and by using the approval function 1 2 of the request source program 5 Approved processing. At this time, the system 100 stores the address on the network of the approved terminal 400 used by the approver set in the approved routing data in the storage unit 101. Then, the approval function 12 (approval routing controller in) transmits the approval request and the order request (transaction request data) to the G address of the approver terminal 40'. The address is included in the approved routing data. For example, approval • Request data is screen information with an interface to receive approved or unapproved inputs. The approval function 12 then obtains input data indicating approval or non-approval from the approver of the approver terminal 400, and then determines whether approval or non-approval is obtained from all approvers defined in the approved routing data. If the approval function 12 determines that the approval is obtained by all the approvers defined in the approved routing data, the approval function 》2 notifies the order request function 11 (transaction execution unit) of the determination result. Since one or more approvers can be set for a single approval request event, -16- 200926034 Therefore, on time, the nuclear order is handled by the actor by 'corresponding one. Easy opponents φ line order pick history attribute Useful resources Purchase company User total and DV servo program 5 and ® style. In addition, when the product is approved as the storage order function, the approval request for all the approvers set in the approved routing data in the above 101 of the above-mentioned 101 is changed for the corresponding one of the counterparty companies 3 The E-Competitor Company 3 has the "Trading Opportunity Representative" authorization to use the login program 4 to log in to the system 1 'and then 'relative to the official order event generated by the purchase company 2' by using the order of the delivery 6 The receiving function 14 and the shipping registration function 15' receive processing and shipping processing. For example, each user's purchase information, product information, and other information are stored and logically distributed to the user. In the space of each of the database 7 or the counterparty company 3, the database 7 is all the same and is included in the storage unit 1 〇1 of the system. The system 1 according to the present embodiment includes the WEB server 8. Server 9. The WEB server 8 is provided with a login program 4, requesting a source counterparty program 6 as a business application in the storage unit, and the DV server 9 includes a user main attribute 125, The information in the list of products and services to be processed by the system, the order data from the system 100 and the service, the historical data of the order and the approved routing routing application main conditions 126 and the approved routing main control 127) Library 7. Each web server 8 in the execution business application fetches/writes each piece of information in the DB server library 7 via the network 140. The system reads the storage unit program 1 〇 2 stored in, for example, non-volatile memory into the memory 1 〇 3 to provide the function of executing the processing method of the purchase -17-200926034. System 1 ο 促使 then causes execution of the program as arithmetic CPU 104. In addition, system 100 includes an input interface 105 such as a keyboard of a normal brain and a different type of button, an output interface 106 such as a display, and a communication unit 1 7 for communicating with user terminal 300 of user terminal 300. • Next, for example, the description will be made according to the program 102. Configuration and retention of functional units. As described above, each functional unit 0 is physically disposed on a single server device or the like. However, it can be assumed that the elements are distributed in a distributed manner on a plurality of computers on the network 140 and under the initiation of the server device, in cooperation with the workpiece. The system 1A includes an approved route setting receiving unit 110. The core setting receiving unit 110 receives the approved routing data for the user from the user terminal of the user or the input interface 105, and the approval route includes the transaction attribute and the approver attribute associated with each other, and the transaction attribute. Here, the approved routing data is the information of the internally approved approved routing required by the user at the time of the product or service transaction. Approved way • The receiving unit 110 stores the approved routing data thus received in the storage 101. It can be assumed that this approved route setting receiving unit 110 is provided by the source program 5. Further, the system 1 〇 〇 includes an approved route control unit 111. The product and service request data is received from the user terminal 300 by the control unit 111. The approval routing control unit 111 then selects, for the electrical LED or the approval system, the core unit whose attribute matches the transaction request data from the approved routing data of the user corresponding to the terminal of the user terminal 300 that issued the data. 10 0 The usage data package that can be used to schedule the quasi-routing of the entire function list is to approve the quasi-route -18-200926034 data for each transaction request that is required to be approved by the setting storage unit. The approval route control unit 111 then executes the internal approval process for the user based on the material selected here. The approved route control unit 111 provided by the source program 5 can be used. In addition, the system 100 includes a transaction intermediate execution unit 112 that obtains approval from the required approver as a result of the approval process - the transaction intermediate execution unit 112 transmits the data of the approved exchanged exchange order or receipt to the user The terminal of the counterparty. The default intermediate execution unit 112 can be supplied by the request source program 5 and the counterparty. It should be noted that the approved routing setting receiving unit 110 may configure the input of the approved routing data to receive the screen material to the user terminal 300 interface 105, and also accept the approved routing data input into the input receiving screen from the user terminal 300 or the input interface. The input data can be configured to include an interface for setting an approval authority level for receiving the subscribers included in the approved route, and an approver approval authority required for receiving each approval phase in the approval route. . • Further, the system 100 can be configured to include information about each user candidate and the authorized authorization level of the candidate in the data storage unit 101. In addition, the approved route setting receiving unit n〇 is configured as follows. When the approval authorization required in each approval phase is received from the user input interface 105 via the input receiving screen, the approval routing setting receiving unit 110 specifies the approval authority having the approval authorization level required in the setting equal to or greater. The level of the nuclear approval road request in the internal shape, the arrival of the delivery of the 6 delivery or input 105 receiving screen each core included in the level of the approval deposit can be set to 300 or in the receipt Waiting for -19- 200926034 to select, and then, generate a list of approved candidates. The 'approved route setting receiving unit 110 then transmits the data of the approved candidate list to the user terminal 300 or the input interface 150' and 'receives the order of the approver selected in the list of approved candidates. In addition, the approved routing setting receiving unit 110 may be configured to transmit the input and receive screen data of the approved routing data to the user terminal 300 or the input interface 105, and receive input and receive from the user terminal 300 or the input interface 105, φ. Approved routing data entered on the screen. The input receiving screen data includes: an interface for setting the attribute of the product ordered or the product sold in the transaction for receiving the approval processing target of the approved route; an interface for receiving the payment source information, and the payment source information is used for accounting procedures, etc. Information; an interface for setting a range of transaction limits for receiving transactions for approval of the approved route; and attribute information for receiving a transaction request instruction for a product or service issued by the user via the user terminal interface. In addition, the 'approved routing control unit 1 1 1 may be configured to receive transaction request data for products or services from the user terminal end 00, and to read out products ordered or products sold in the transaction from the transaction request data. Attribute data • The transaction amount data of the transaction and the attribute data related to the user who issued the order for the transaction request. Then, the approval route control unit ln is configured to select, from each of the approved routing materials associated with the user of the user terminal 300 that issued the transaction request data, the product having the ordered product or the product sold. The attribute, the transaction amount range, and the approved routing data of the user attribute 'user attribute are set in the approved routing data of the data read in the transaction request data. The approved routing control unit -20-200926034 111 can then perform internal approval processing for the user based on the approved routing data selected herein. In addition, system 100 stores approved routing data shared by all users in storage unit 101. Then, when the approved routing data having the transaction attributes conforming to those transaction request materials is selected, in the case where the approved routing data having the transaction attributes conforming to those transaction request materials does not exist in the approved routing data in the storage unit 101 ( Every one . The approved routing data is associated with the user of the user terminal 300 that issued the transaction request data. The approved routing control unit 111 can select the shared approved routing data from the storage unit 101. In addition, for each or more transaction attributes, the approved routing data common to all users is set. When the approved routing data having the transaction attributes conforming to those transaction request materials is selected, in the case where the approved routing data having the transaction attributes conforming to those transaction request materials is not stored in the approved routing data in the storage unit 101 (each approval) The routing information is associated with the user of the user terminal 300 that issues the transaction request data. The approval routing control unit 111 selects a common 'approved routing data from the common approved routing data of the storage unit 101, and the common approved routing data. The predetermined attribute data of the transaction included in the transaction request data is set. In addition, system 100 stores the address on the network of approved terminal 400 to be used by the approver set in the approved routing profile. The approved route control unit 111 can be configured in the following manner. When the internal approval processing is performed based on the selected approved routing data, the approval routing control unit 1 1 1 transmits the approval request data together with the transaction customer data to the address of the approved terminal 400 included in the approved routing data, and, from the approver In the terminal 400, the input data approved or not approved by the approver is taken from -21 to 200926034. Core unit U1 then decides whether or not to obtain the approved approval from the approved routing data. If the decision is made to be approved from all the approvers, the processing unit 111 notifies the transaction execution unit of the result of the decision. It should be noted that each functional unit 110 to in system 100. Hardware or stored in, for example, memory or HDD (hard disk drive). The program in the unit is implemented. In this case, when the CPU executing the program φ 100 reads the program from the storage unit and executes the program table structure embodiment, the structure of the table for the purchase operation system according to the present embodiment will be explained. The graph shown in Figure 2 shows the data structure of A attribute 125), B (approved route main application condition 126), and Lushen main control 127). The user main attribute 1 25 is a record group, and the record group stores attributes related to individual users, and each individual user - user terminal 3 00, sends a product or service transaction, for example, in In each record, the user ID is used as the key company code, the office code and a corresponding individual user's area code, approval authorization type and approval authorization level. The information should be noted here. The word "individual user" is used here. Refers to the person who is truly terminal 00, such as an employee or a staff member, who is a "user" in the scope of the patent application scope (company or ^ In addition, the approved route request master condition 126 is the record group quasi-route control with the approver Approved routing control 1 1 2 can be used in the appropriate storage mode, system flow 100 (user master and C (approve each record storage by the corresponding request. The key to make the company, for example, related) Operating the user in the present invention. Each record -22-200926034 contains the selection criteria used by system 100 to select the approved routing data based on the transaction attributes. In the first record, the approved route definition ID is used as the key, and, for example, the company code, office code, partition code, basic price range (transaction limit range), and authorization (selectable routing data is selectable) In the case of selecting the authorization level of the approved route*), the materials allowed to implement this approved route are related to each other. In addition, the approved route request master condition 1 27 is a record group, and each record φ stores a definition content for each approved route material for each user (company or organization). For example, in each record, an approved route definition ID is used as a key, such as to set the number of acceptance phases (the number of approval phases), the approver company code for the approver attribute information, the approver office code, And the approver partition code, the approver code, the address of the approver terminal 400 used by the approver, the required approval authorization level (can give the approver authorization level for each approval stage number), and indicate the corresponding An approval phase is that the requirements flag for approval is related to each other. © It should be noted that all users' approved routing information and application conditions are set in the approved route request master condition 126 and the approved route master control 127 *. In this case, as shown in FIG. 9, for example, ^@" is set in each item such as a company code, a company code, a partition code, an approval authorization type, and an approval authorization level, and is stored in the approved route. One of the application conditions in the main condition 126 is applied ("WF5" in Fig. 9). This "@" is a mark indicating that the condition indicated by "®" is replaced by the corresponding attribute of all the attributes of the user and is then applied. Similarly, "@" is set in each data item such as the approver company code, the approver -23-200926034 company code, and the approver partition code, which are attribute information of the approver, as the main control stored in the approved route. The application routing information stored in 127 ("WF5" in Figure 9). For each of the multiple transaction attributes, set the approved routing data common to all users. For example, a common approved routing data corresponds to company codes K1 to K3, and another common approved routing data corresponds. The transaction amount from "100,000 yen" to "500,000 yen" and so on. 0 Process Flow Example 1 Hereinafter, the actual procedure of the purchase operation processing method according to the present embodiment will be explained based on the drawings. It should be noted that each type of operation corresponding to the purchase operation processing method to be described below is implemented by a program that is read into the memory by the system 100 and executed. This program consists of code for performing the different types of operations described below. Fig. 3 shows a processing procedure example 1 of the purchase operation processing according to the present embodiment. Here, the customer of the purchase company 2 belonging to a certain cooperation will be described. The process flow of the case where the user purchases the product. When the client user attempting to log in to the system 100's accesses the login program '4 of the web server 8 via the network 140', the login program 4 will be able to receive the screen data of the user ID and password input (hereinafter referred to as the login screen). The purchase company terminal 3 50 is transmitted to the customer user. In response to this operation, the customer user enters the user ID and password and the login button pressed on the login screen displayed on the purchasing company terminal 350. Then, the input information is transmitted from the purchase company terminal 350 to the login program 4 of the web server 8 via the network 140. -24- 200926034 The login program 4 of the web server 8 queries the user main attribute 125 of the DB server 9 via the network 140, and then determines whether the password transmitted by the company terminal is correct, and at the same time, the company identification area and the company code are taken out. Each data such as a company code (hereinafter referred to as customer user information), an approval level, and a customer user authorization (S301) is identified. * Next, the login program 4 determines the customer use taken in step S301. The type of authorization (step S3 02). If the authorization is "Customer", the @Login 4 will display the purchase of the data displayed by the screen display button (hereinafter referred to as the customer menu screen) capable of executing the product search function 1 and the order request function 11, respectively. Company terminal 3 50 (S303). On the other hand, if the authorization of the client user is not a "customer" authorization, the login program 4 will be able to display a button for allowing each authorized function of the other authorizations to be transmitted to the partner purchasing company terminal 350. When the customer user presses the product search key displayed on the customer menu screen in the purchase company terminal 350, the product search function for transmitting the request from the purchase company terminal 350 to the web server 8 via the network 140 is executed. ( ' S3 04 ) ° ' When the execution request is received, the product search function 1 of the web server 8 transmits the data of the screen for the condition input of the search product (hereinafter referred to as the product search screen) to the customer. The purchase company terminal 3 5 0 (S3 05 )-> When the customer user inputs the search condition on the product search screen displayed on the purchase company terminal 350 and presses the search key, the search condition is purchased from the network 140. The company terminal 35〇 transmits to the web server 8 product search-25-200926034 seek function 1 〇 (s 3 0 6 ). The product search function 1 of the web server 8 extracts the product data matching the search condition from the product data of the DB server 9 based on the search condition transmitted from the purchase company terminal 350. Then, the product search function 1 〇 will display the data of the screen for taking out the result (hereinafter referred to as the search result screen) • The purchase company terminal 3 50 (S307) transmitted to the customer user. . When the client user selects the product from which the customer user issues the order request from the search results screen displayed on the purchase company terminal 350, and presses the order generation button, the execution request is transmitted from the purchase company terminal 350 to the network through the network 140. The order request function 11 of the web server 8 (S308). Upon receiving an execution request from the purchasing company terminal 3 50, the order request function 11 of the web server 8 will be able to receive an order request for input related to the delivery information, payment source information, and approver information of the product selected by the user. The data of the screen (hereinafter referred to as an order request generation screen) is transmitted via the network 140 to the purchase company terminal 35 (S3〇9) of the customer. ® This input information is then called Order Request Information. After the customer user has entered the order request information and specified the approver by the processing described below. When the order request button is pressed (S310), the product information, the delivery information, and the payment source information are transmitted from the purchase company terminal 35 to the order request function u of the web server 8 via the network 140. When receiving the g-single request information from the purchasing company terminal 35, the order request function n writes the information as an order request to the order data of the DV server and the order history data (S311). Note that in step S Prior to 3 1 1 , the internal approval process was performed according to the approved routing data selected by the order request function -26i from -26-200926034, including the approved route data of the approver specified by the customer. This processing is executed in the manner that the order request function 1 1 transmits the order request material together with the order request information (transaction request data) to the address of the approver terminal 400 of the approver included in the automatically selected approved routing material. Receiver data indicating approval or disapproval by the approver is then received from the approver terminal 400. after that, . Decide whether to approve from all approvers defined in the approved routing information. If it is determined that all the approvers defined in the approved routing data have obtained the approval, step S 3 1 1 is performed. Process Flow Example 2 Next, the process for automatically selecting an approved route and setting an approver in steps S308 to S311 of the embodiment of the process flow will be explained. Fig. 4 shows a processing procedure example 2 of the purchase operation processing method according to the present embodiment. It should be noted that the order request function 11 of the request source program 5 is planned to have an order request 萤 screen display group 5a, an approver setting screen display module 5b, an approver 'list screen display module 5c, and an order request generating module 5d. • The customer request presses the order request generation key in step 308 of the processing program embodiment 1, and then, after receiving the execution request by the web server 8 via the network 140 in step S309, (S501), the order request The screen display group 5a transmits the order request generation screen G601 shown in FIG. 5 to the purchase company terminal 350 of the customer user (S502). The customer user inputs the payment source information G6 02 of each product to be purchased in the order request generation screen G601, and presses the approver setting -27-200926034 key G603. Then, 'the execution request is transmitted from the purchase company terminal 350 to the web server 8 via the network 140 to set the screen display module 5b. After receiving the execution request, the approver sets the screen display module 5b to use step S301. The obtained customer user attribute, the product information selected by the customer and the user in step S308, and the order request generate a screen G601. The specified payment source information G602 is used as the application condition, and then the approved route definition ID corresponding to the application conditions is extracted from the approved route request main condition 126 of the DV server 9 via the network path 140. In the case where there is no such approved route definition ID that meets the application conditions, error handling is performed. On the other hand, in the case where there is such an approved route definition ID conforming to the application condition, the approver setting screen display module 5b takes all of the approved route master control 1 27 by using the extracted approved route definition ID as a key. Approved routing information (S 504) that can be applied for. Φ The approver setting screen 5b takes out the required flag of each setting acceptance stage number from each approved routing data extracted from the approved routing main control 127, and extracts the largest number of setting acceptance stage numbers. . Then, the approver setting screen display module 5b transmits the approver setting screen G70 1 to the purchase company terminal 350 (S5 05) of the customer user via the network 140, and the approver setting screen G701 displays equal to or greater than the set acceptance stage number. The maximum number of approver setting fields, the information indicating "required" or "option" in each field of the number of the approval stage, and the approver search key G702 (refer to FIG. 6). -28- 200926034 When the customer user presses the approval G702 displayed in each approval stage column on the purchase company terminal 350 setting screen G701, the execution result and the corresponding search key approval G703 data will be transmitted via the network. 140, from the purchase company terminal to the approver list screen display module 5c of the web server 8 ( • upon receiving an execution request from the purchase company terminal 350, the list screen display module 5c takes out φ by using step S504 The ID and the data of the approval stage number G703 of the purchase company terminal 350 of the customer user are used as keys to query the data that can be requested in the approved route master control 127 of the DB. In addition, the single screen display module 5c is used by using the query here. The information of the prospective company code, the approver's office code, the approver's division code, the quasi-level and the approver's code as keys to the approver of the approval stage number that can be applied for from the user's main attribute ( S507). At this time, the approver to be taken out is required to be the user of the approval level of the approval level required by the equivalent. • Next, the order request function 1 1 will The subscriber list screen - 5C approves the approver user information transmitted to the customer user department terminal 350 as the approver list screen S508 shown in FIG. 7) » When the customer user requests the function 11 from the approver list screen G801 When the approval key G802 is set in the approved approver list, the approver (in the embodiment of the drawing) 2 is set in the approver setting screen G704 as the approver setting screen of the approver setting screen. (In Figure 6; | for the core search key phase number 3 50 transfer S5 06) °, the approver's approved route is sent by the server 9 approver clears the core required by the core 125 of the user The information is greater than or greater than the purchase price of the display module; G801 (Select the orderer and press the process of repeating steps S506 to S509 as shown in the use of -29-200926034 shown in Figure 6 until the customer user setting requires the approval of all the approvers. The approver of the stage number. When the customer user completes the setting of all the approvers, when the application button G705 of the approver setting screen displayed on the purchase company terminal 350 is pressed, Display • A sequence of approvers set by the customer (in other words, they can be. Called an approved route). II After repeatedly performing the processing required in steps S503 to S509 for the purchase of the product, the customer user presses the order request to generate an order request generation key for the screen. At this time, the purchasing company terminal 350 checks whether there is a lost requester's setting and whether the organization information regarding the approver and the approved route is consistent with the order request corresponding to each product. If the lost setting is not found, the order request generation data is transmitted from the purchase company terminal 350 to the order request generation module 5d via the network 140. The order request generation module 5d transmits the data received from the purchase company terminal 3 50 to the DB server 9 as an order request item and registers the item as an order request resource and order history data (S5 10). Approved Route Automatic Selection Control Embodiment 1 FIG. 8 shows an embodiment of a user main attribute, an approved route request main condition 126, and an approved route main control 127, and an automatic selection control of an approved route. In this embodiment, three different approved route definition IDs are defined as WF1 (D911), WF2 (D912), and WF3 (D913). In addition, for the information specified in the approved route definition ID, WF1 (D911) and the customer request for the company code "K1", the office code "001" and the partition code "Α" are issued by -30-200926034. WF2 (D912) is the material to be taken out. In addition, when the unit price of the purchased product is not less than 1〇, when the yen is rounded, the application approver defines the ID of the data WF2 (D912). For other cases, the application approver defines the ID of the data WF1 ( D91 1 - )〇 • In addition, in the case of the customer user φ belonging to the company with the company code "K2", the application approver defines the ID of the data WF3 (D913 ). In the approved route master control 127, the number of each approval stage of each of the approved route definition IDs WF1 to WF3 (D9 1 1-D9 13 ) is set, and the application condition that can be given to the approved approver is set. In these setting embodiments, similarly, for the data WF1 (D921) for the approver definition ID, the approval phase number is set to one stage, and the data WF2 (D922 to D923) for the approver definition ID and WF3 (D924 to D925) is set to two stages. Φ For approval of the first-order WF1 (D911) of the approved route definition ID, an approver with a company code of "K1", an office code of "001", and an approval level of not less than "1" is required. Regarding the approved route definition ID WF2 (D912), the same setting as the approved route definition IDWF1 (D921) can be applied to the first stage. In addition to this, the second phase in the approved route (D923) of the approved route master control 127 requires an approver with an approval level of 2 or greater and belonging to the partition code B. In addition, for the approved route definition ID WF3 (D9 1 3 ), the first stage in the approved route (D924) of the approved route master control 127 needs to have the company code "K2", the office code "111" -31 - 200926034, and the partition code. "B" and the approver whose approval level is equal to or greater than "1". In addition, in the approved route (D925), an approver having the same company code and office code as the case of D924, and the partition code "C" and the approval level equal to or greater than "2" can be selected. For example, consider the case where the user 1 (D901) issues an approval request for a product of a price of 100 yen (Embodiment 1). When the customer is at . Step S 503 When the approver setting button is pressed, the order request function n uses the company code "K1", the office code "001", the partition code "A", and the purchase price of the product of the joint information of the customer user. The 100 yen is taken as the application condition and thus the approved route definition ID is taken out from the approved route request master condition 126. At this time, since the condition for the unit price of "WF1" is that the amount of the purchased product is less than 10,000 yen, the application route ID "WF1" (D911) and "with the company code "K1" are included in their application conditions. In WF1" (D912), take "WF1" (D911) as the available route definition ID. Φ The order request function 11 uses the approved route definition ID "WFlj as the key and thus retrieves the available information from the approved route master control 127 ( . D921). Since the number of setting acceptance phases of the extracted approved routing data D921 is only one (required), in step S505, the order request function 11 transmits only the approver setting screen of the approved designated field to the client user. The company terminal 350 is purchased. Further, when the customer user presses the approver search key of the approval stage number "1" in step S506, the order request function 11 takes out the user 3 (D903) and the user in step S507. 4 (D9 04) data -32- 200926034, user 3 (D903) and user 4 (D904) have the approver company code "K1", the approver office code "〇〇1"' authorized "Approved" And having the required approver level equal to or greater than "1", which are set in the approved routing data D921 which is extracted by using the approved route definition ID "WF1" and setting the receiving phase "1". . In step S508, the order request function 11 transmits the extracted data of the user 3, (D903) and the user 4 (D904) as a list screen to the purchase company terminal 350 of the φ client user. Further, in step S5〇9, the customer user takes the approver from the list screen and sets the approver. Similarly, in the case where the user (D901) purchases a product having a price of 20,000 yen (Embodiment 1), although "WF1" (D91 1) and "WF2" (D912) both meet the approved route definition taken in step S504. The condition of the ID, however, in this case, the application has a higher priority "WF2" (D912). The order request function 1 1 uses the approved route definition ID "WF2" (D912) as a key and thus retrieves the available approved routing data (D922) and (D923 • ) from the approved routing master control 127. Since the number of the setting approval stage of the data for taking out is "1" - and "2", in step S505, the order request function 11 transmits the approver designated screen of the approval stage designation to the customer user. The purchase company terminal 3 5 0. The customer user repeats the processing of steps S 506 through S 509 for each of the first and second approval stages, and thus specifies the approver. Therefore, as in the case of Embodiment 1, in the process of step S507, it is necessary to set the user 3 (D903) or the user 4 (D9〇4) ' and -33-200926034 in the second stage in the second stage. It is necessary to set an approver belonging to the company code "κι", the office code "001", and the approval level equal to or greater than "2". Therefore, only the user 4 (D904) can be set as the approver. It should be noted that the approval level required in the approved route can also be set to be used for the customer user. For example, in a customer with an approval level of 1, the user: user 2 (D902) purchases a product with a price of 20,000 yen. In the case (Embodiment 3), the approval route to be fetched in step S504 is defined as "WF2" as in the case of (Embodiment 2) (D9 12). However, since the customer user: User 2 (D902) has an approval level of 1, it is determined that the customer user also has the approval authorization of the first stage (D922), and the approval authorization of the first stage (D922) has the required Approval level "1". Therefore, in step S505, the approver designation field in which the approver designation field of the first approval stage is not displayed but only the approver designation field of the second approval stage is displayed is transmitted to the purchase company terminal 350 of the customer user. The customer user specifies the approver by the same process as in Example 2 for specifying the approver in the approval designation field of the second approver 阶段 stage. • In addition, the user belonging to the company code "K2": "User 5". (D905) In the case of purchasing the product (Embodiment 4), the approval route definition ID "WF3" (D913) is taken out by the order request function 11 (since the company code and the partition code are not set in the application condition, The user of company code "K2" takes out the approved route definition ID "WF3"). In addition, the order request function 11 uses the approved route definition ID "WF3" as a key and thus retrieves the approved routing data (D924) and (D925) from the approved route master control 127. Since the approved routing data (D92 5 ) defined for the approver of the second stage is an optional setting, in step S5 05, the order request function 11 will be the approver in the first and second stages. The approver of the "required setting" and the "additional setting" in the designated field respectively sets the purchase company terminal 350 for the screen to be transmitted to the customer user. When the customer user specifies the approver in steps S506 to S509, • the approver of the first approval stage is required to be specified (in the processing of step S5 07 - the approver to be taken out is "user 6" (D906)). However, the approver in the second phase of the designation φ is optional so that the approver is properly designated. When the approver is to be set in the second stage, as in the case of the first stage, the process of steps S506 to S509 is performed to set the approver (the approver to be taken out in the process of step S507 is "user" 7" (D907)). Approved Route Automatic Selection Control Embodiment 2 Next, a method for defining a route for the approval of a plurality of purchase companies 2 using a common core route (approval rule) and an automatic selection processing method will be described using FIG. In the case where a plurality of purchasing companies 2 use a common approved route, for each purchase company 2 having approved routing information having the same content in the approved route request main condition 126 and the approved route master control 127, improvement or elimination is performed. The main condition or the main control time will increase the problem. Further, in order to avoid execution of error processing in the case where the approved route definition to be applied does not exist in step S5 〇 4, it is preferable to preset the definition, which can be widely used and applied by the purchasing company 2 The situation where the approved routing information is not consistent with the application conditions. -35- 200926034 In the above case, as shown in FIG. 9, by setting "@" in each of the approved route request main condition 126 and the approved route main control 127, each application condition of the approved route is made possible. The reading can be replaced by one of the attributes of the corresponding customer user (described in Figure 2). For example, 'in Figure 9' the approved route definition id "wF4" (D1011) is a unique definition of the public code "K3", and "WF5" (D1012) is the definition of the approved route common to all purchase-buy companies. Contains "@" set in company code, office φ room code and partition code. In the case of a customer belonging to the company code "KF 3": "User 8" (D 1 0 0 1 ) in the case of purchasing a product of unit price 1 yen (Example 5), the order is requested in step S504. The approved route definition ID extracted by function 11 is "WF5" (D1012) plus "WF4" (D1011), and "WF4" (D1011) is individually defined for the company with company code "K3". At this time, regarding the approved route definition ID "WF5" (D1012), the order request function 1 1 uses "K3", "0 〇1", "A", etc., respectively, about the attribute information of "user 8" (D1 001). Instead of setting "@" as the company code, company code and partition code. - In the present embodiment, the customer user · "user 8" (D1001) is a product to be purchased for a unit price of 100 yen, and the approval definition ID "WF4" (D1011) is applied when the unit price is less than 10,000 yen. The order request function 11 uses the approved route definition ID "WF5" (D1012) as a key and thus retrieves the applicable approval source data (D1023) from the approved route master control 127. In addition, since the approved routing data (D1023) includes the approver company code "@", the approver company code "@" -36- 200926034, and the approver partition code "@", when it is taken out for approval in step S507 In the list of approvers of the stage number "1", the order request function 11 reads the "@" mark in the code numbers and respectively uses the company code "K3" of the customer user, the company code "001" and the partition code " A" replaces it. Further, from the user main attribute 125, the approver user "user 9" (D1 002) belonging to the client user of the same organization is taken out. . Further, the "company identification code" of the user main attribute 125 is a definition for grouping @multiple companies (joint company, etc.). Therefore, although the following description and examples are omitted in the present embodiment, the "company identification code" can be used as an application for approval of the route, as in the case where the company code or the like is set in the approval route request main condition 126. Application criteria. According to the present embodiment, even in an environment that can be used by many companies or organizations having different approval standards (an environment that logically partitions system resources, such as ASP), each company or organization can still use its own unique approval. Rule (approved route). In addition, in cases where the joint approval criteria are used by a number of companies or organizations, the use of common approval rules to control the setting of different data, such as master data, simplifies the data. Maintenance and management. According to the above effects, the development of the approval processing program and the like and the number of operation processes can be reduced, and at the same time, the diversity of functions provided in the purchase operation system can be maintained. In addition, since the data link processing used in the conventional system is not required, the purchase operation system can be realized at an appropriate cost. Therefore, each user can define and use their own unique -37-200926034 approval rules under the assumption that each user of the operating system uses a common program resource. It should be noted that although the above description is taken as an example of a network coupled purchase operating system for indirect materials or direct materials, the present invention can also be applied to organizational information and use of visual content that are both related to users of the system. Approve all operating systems for the workflow. For example, the present invention can be applied to management approval transactions for use in the same organization, or in multiple organizations, . An internal operating system that reports circulation operations, etc. As described above, the embodiments of the present invention have been provided on the basis of the embodiments. However, the invention is not limited thereto. The embodiments may be modified differently without departing from the spirit and scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is an overall configuration diagram of a purchase operating system according to the present embodiment; FIGS. 2A to 2C respectively show a user main attribute, an approved route request main condition, and an approved route main control according to an embodiment of the present invention. The data structure φ embodiment; • FIG. 3 is a flowchart showing the processing operation method of the purchase operation processing method of the present embodiment; FIG. 4 is a flowchart showing the processing procedure 2 of the purchase operation processing method of the present embodiment; 5 shows an embodiment of the order request generation screen of the present embodiment; FIG. 6 is an embodiment showing the approver setting screen of the embodiment; FIG. 7 is an approver list screen; FIG. 8 shows an automatic approval route according to the present embodiment. Selection control real-38-200926034 Embodiment 1; and FIG. 9 shows an automatic selection control method 2 of the approved route according to the present embodiment [ > [Main component symbol description]. 2 : 3 : Purchase company counterparty company 〇 4 : 5 : Login program request source program 5 a : Request request screen display module 5b : Approver setting screen display module 5 c : Approver list screen display module 5d : Please request a module 6: Counterparty program 7 : 10 8 : Database server, 9 : DB server. 10 : Product search function 11 = Order request function 12 : Approval function 13 : Order order history management function 14 : Order receiving function 15 : Shipping login function 100 : Purchase operating system -39- 200926034
101 ： 103 ： 104 ： 105 ： 106 ： 107 ： 140 ： 3 60 ： 儲存單元 記憶體101 : 103 : 104 : 105 : 106 : 107 : 140 : 3 60 : Storage unit Memory
CPU 輸入介面 輸出介面 通訊單元 網際網路 購買公司終端 交易對手公司終端CPU input interface Output interface Communication unit Internet Buy company terminal Trader company terminal
-40-40