TWI391870B

TWI391870B - 購買操作系統、購買操作處理方法及購買操作處理程式產品

Info

Publication number: TWI391870B
Application number: TW97130356A
Authority: TW
Inventors: Nobuto Koga; Takahiro Yoshida; Yasunobu Sugiura
Original assignee: Hitachi Ltd
Priority date: 2007-10-29
Filing date: 2008-08-08
Publication date: 2013-04-01
Also published as: CN101425165A; JP2009110197A; MY152598A; SG152120A1; TW200926034A; JP5160860B2

Description

購買操作系統、購買操作處理方法及購買操作處理程式產品

本發明係關於購買操作系統、購買操作處理方法及購買操作處理程式產品。具體而言，本發明關於能夠由眾多具有不同核準標準的公司或組織共同使用的環境(ASP等)中所使用的技術，所述技術允許各別公司或組織使用共同的程式資源以及設定及使用它自己獨有的核準路由。

關於公司的購買操作系統，舉例而言，眾多購買公司或組織通常使用相同的系統以降低操作成本以及實現合作購買。執行此種操作的購買操作系統使用之設計(ASP等)，以邏輯方式分割單一系統的資源，而使得眾多購買公司或組織能夠使用單一系統。在此設計中，程式資源由多家公司或組織共用。此種購買操作系統的核準功能通常是僅根據對應於購買量等二或三階段的核準規則，核準規則在購買操作系統中預先決定。在某購買公司或組織使用特定用於公司或組織的核準規則而非用系統中預先決定的核準規則之情形中，舉例而言，所述公司或組織以僅有關於購買定單的資料被鏈結至系統的方式使用購買操作系統。更具體而言，以此方式，在輸入關於購買訂單的資料之前，公司或組織將關於要購買的產品之資料輸入其本身個別地操作的系統中，以及，操作個別操作系統以確認用於購買的核準。關於此種方法的實施例，請參考非專利文獻之下述網站：http：//www.withkaunet.com/top/info13.html，http：//www.withkaunet.com/top/info3.html，及http：//www.webmethods.co.jp/pdf/Biz.pdf。

如上所述，在傳統的可由具有不同的核準標準的眾多公司或組織共同使用的購買操作處理環境中(系統中的資源以邏輯方式分割之環境，例如ASP)，各別公司或組織使用共同的程式資源。在各別公司或組織要在此環境下的購買操作系統中實施其自己獨有的核準標準之情形中，包含於購買操作系統中的一般功能及服務無法實用，因此，每當購買操作系統被調整至獨有的核準標準時，各別發展成本會加諸於公司或組織。結果，各別公司或組織的成本負擔等會增加。同時，即使使用上述非專利文獻中所述的鏈結方法以避免此問題，但是，各別公司或組織必須承擔系統發展成本及操作成本。

慮及上述問題而產生本發明。本發明的目的在於使每一使用者能夠在每一使用者使用共用的程式資源的假定下界定及使用其自己獨有的核準規則。

本發明的購買操作系統提供由例如公司及組織等多個使用者共同使用，以及執行多個使用者之間產品、服務等交易的中間處理之系統。所提供的系統包括：核準路由設定接收單元，用於從多個使用者中每一使用者所使用的使用者終端或輸入介面輸入接收用於多個使用者中的每一使用者的核準路由資料，以及，將如此收到的核準路由資料儲存於儲存單元中，核準路由資料是關於產品或服務交易的多個使用者中的每一使用者所要求的內部核準之核準路由的資料，以及，核準路由資料包含彼此相關連之作為核準標的的交易之屬性及核準所需的核準者的屬性；核準路由控制單元，用於從使用者終端接收產品或服務的交易請求資料，然後，用於從儲存單元中均與發出交易請求資料的使用者的使用者終端相關連的核準路由資料中選取交易屬性符合交易請求資料的交易屬性之核準路由資料，以及，用於根據此處選取的該核準路由資料以執行用於使用者的內部核準處理；及交易中間執行單元，在因內部核準處理的結果而從要求的核準者取得核準的情形中，將作為核準標的之該交易中下單或收到的訂單的資料傳送給使用者的交易對手的終端。

根據本發明的購買操作系統，使每一公司或組織能夠在購買操作系統的每一使用者使用共用的程式資源的假定下，在購買操作系統上實現其自己獨有的核準標準。由於維持購買操作系統的每一使用者使用共同程式資源的假設，所以，解決了先前技術中造成的問題。這些問題包含購買操作系統中的多功能的一般多樣性及服務減少以及每次對每一核準標準採取回應措施之個別發展時發生成本負擔。因此，在購買操作系統的每一使用者使用共用的程式資源的假定下，每一使用者能夠定義及使用其自己獨有的核準規則。

此外，在上述購買操作系統中，核準路由設定接收單元配置成將用於輸入核準路由資料的輸入接收螢幕資料傳送給使用者終端或輸入介面，以及，從使用者終端或輸入介面接收輸入接收螢幕中輸入的核準路由資料。此外，輸入接收螢幕資料配置成包含：用於接收包含於核準路由中的每一核準者的核準授權等級的設定之介面；及用於接收包含於核準路由中的每一核準階段中所要求的核準者的核準授權等級之設定的介面。

根據上述配置，關於核準路由資料，可以設定每一核準階段中具有適當授權等級的核準者。使每一使用者能夠設定其自己獨有的核準路由之本申請案的發明之效果可以增強每一使用者設定其自己獨有的核準路由的彈性。

此外，在購買操作系統中，關於該多個使用者中的每一該使用者的核準者候選人及關於該核準者候選人的核準授權等級的資料儲存於該儲存單元中，以及，在經由該輸入接收螢幕而從使用者終端或輸入介面收到每一核準階段中要求的核準授權等級的設定時，核準路由設定接收單元指定儲存單元中具有等於或大於此處收到的設定中標示的要求的核準授權等級之核準授權等級的核準者候選人，然後，產生核準者候選人清單，然後，將核準者候選人清單的資料傳送給使用者終端或該輸入介面以及從核準者清單接收標示選取的核準者之指令。

根據此配置，對於使用者設定核準者而言，用於決定核準者的處理之效率會增進，同時，可以免除不具有要求的核準等級的核準者被錯誤地設定於核準路由資料中之情形。

此外，在購買操作系統中，核準路由設定接收單元配置成將用於輸入該核準路由資料的輸入接收螢幕資料傳送給使用者終端或該輸入介面，以及，從使用者終端或輸入介面接收輸入於輸入接收螢幕中的核準路由資料。此外，輸入接收螢幕資料配置成包含：用於接收交易中被訂購的產品及售出產品的屬性設定之介面，交易是該核準路由中的核準處理標的；用於接收用於會計程序等的付款源資訊的介面；用於接收介易的交易額度範圍的設定之介面，交易是核準路由的核準處理標的；及用於接收與藉由使用使用者終端而發出產品或服務的交易請求的使用者相關的屬性設定。

根據此配置，關於核準路由資料，可以將詳細的交易內容設定為要成為用於自動地選取核準路由的標準之交易屬性。這增加每一使用者增進其設定自己的核準路由彈性之效果。

此外，在上述購買操作系統中，核準路由控制單元從使用者終端接收產品或服務的交易請求資料，以及，從如此接收到的交易請求資料讀取交易中被訂購的產品及售出的產品的屬性資料、交易的交易額度資料、該付款源資訊及與發出交易請求指令的使用者相關的屬性資料。此外，核準路由控制單元配置成從儲存單元中均與發出交易請求資料的使用者終端的使用者相關連的核準路由資料中選取設定於核準路由資料中及與從交易請求資料讀出的資料相符之具有被訂購的產品及售出產品的屬性之核準路由資料、交易額度範圍、付款源資訊、及使用者的屬性，然後，根據此處選取的核準路由資料，執行用於使用者的內部核準處理。

根據此配置，關於核準路由資料，可以將詳細的交易內容設定為要成為用於自動地選取核準路由的標準之交易屬性。這增加每一使用者增進其設定自己的核準路由彈性之效果、或是增加允許根據交易的詳細內容來選取適當核準路由的效果。

此外，在上述購買操作系統中，多個使用者共用的核準路由資料儲存於儲存單元中，及當選取交易屬性符合交易請求資料的交易屬性之核準路由資料時，在具有交易屬性符合該交易請求資料之交易屬性的核準路由資料不存在於儲存單元中均與發出該交易請求資料的使用者終端的使用者相關連的核準路由資料中之情形中，核準路由控制單元選取多個使用者共用的核準路由資料。

根據此配置，每一使用者可以設定自己獨有的核準路由。同時，可以控制要登錄於儲存單元中的核準路由資料的實體容量、及用於核準路由資料設定的不同主資料的實體容量，也可以簡化儲存單元中的資料維護及管理。因此，可以降低系統的潛在成本。

此外，在上述購買操作系統中，將多個使用者共用的核準路由資料設定用於每一或多個交易屬性。在上述購買操作系統中，當選取交易屬性符合交易請求資料的交易屬性之核準路由資料時，在交易屬性符合交易請求資料的交易屬性之核準路由資料不存在於儲存單元中均與發出交易請求資料的該使用者終端的使用者相關連的核準路由資料中的情形中，核準路由控制單元從多個使用者共用的核準路由資料中選取多個使用者共用的某核準路由資料，多個使用者共用的某核準路由資料包括包含於交易請求資料中的交易的預定屬性資料。

根據此配置，可以控制要登錄於儲存單元中的核準路由資料的實體容量、及用於核準路由資料設定的不同主資料的實體容量，也可以簡化儲存單元中的資料維護及管理。同時，可以自動地選取根據交易屬性的核準路由。因此，可以簡化資料維護及管理以及適當地選取核準路由。

此外，在購買操作系統中，儲存設定於核準路由資料中的核準者所使用的核準者終端在網路上的位址，以及，當根據選取的核準路由資料以執行內部核準處理時，核準路由控制單元將準請求資料與交易請求資料一起傳送給包含於核準路由資料中的核準者終端的位址，然後，從核準者終端取得標示該核準者核準或不核準的輸入資料，然後，決定是否取得定界定於核準路由資料中所有核準者的核準，以及，假使判定取得來自界定於核準路由資料中的所有核準者的核定時，將決定的結果通知交易執行單元。

根據此配置，購買操作系統依據交易屬性而自動地選取核準路由，也根據自動選取的核準路由而自動地執行核準者的核準資料取得以及執行取得核準資料後要執行的處理。因此，使用者不再需要根據核準路由以分別地執行內部核準處理。

此外，根據本發明之購買操作處理方法，由電腦執行，電腦由例如公司及組織等多個使用者共同使用，以及執行多個使用者之間產品、服務等交易的中間處理。所提供的方法包括下述步驟：從使用者所使用的使用者終端或輸入介面輸入接收用於多個使用者中的每一使用者的核準路由資料，以及，將如此收到的核準路由資料儲存於儲存單元中，核準路由資料是關於產品或服務交易的多個使用者中的每一使用者所要求的內部核準之核準路由的資料，以及，核準路由資料包含彼此相關連之作為核準標的的交易之屬性及核準所需的核準者的屬性；從使用者終端接收產品或服務的交易請求資料，然後，從儲存單元中均與發出該交易請求資料的該使用者的使用者終端相關連的核準路由資料中選取交易屬性符合交易請求資料的交易屬性之核準路由資料，以及，根據此處選取的核準路由資料以執行用於使用者的內部核準處理；及在因內部核準處理的結果而從要求的核準者取得核準的情形中，將作為核準標的之交易中下單或收到的訂單的資料傳送給使用者的交易對手的終端。

根據購買操作處理方法，在購買操作系統的每一使用者使用共用的程式資源的假定下，使每一使用者能夠在購買操作系統上實現其自己獨有的核準標準。由於維持購買操作系統的每一使用者使用共同程式資源的假設，所以，解決了先前技術中造成的問題。這些問題包含購買操作系統中的多功能的一般多樣性及服務減少以及每次對每一核準標準採取回應措施之個別發展時發生成本負擔。因此，在使每一公司或組織能夠在購買操作系統的每一使用者使用共用的程式資源的假定下，每一使用者能夠定義及使用其自己獨有的核準規則。

根據本發明的購買操作處理程式產品，使由例如公司及組織等多個使用者合作使用、以及執行多個使用者之間產品、服務等交易的中間處理之電腦，執行下述步驟：從使用者所使用的使用者終端或輸入介面輸入接收用於多個使用者中的每一使用者的核準路由資料，以及，將如此收到的核準路由資料儲存於儲存單元中，核準路由資料是關於產品或服務交易的多個使用者中的每一使用者所要求的內部核準之核準路由的資料，以及，核準路由資料包含彼此相關連之作為核準標的的交易之屬性及核準所需的核準者的屬性；從使用者終端接收產品或服務的交易請求資料，然後，從儲存單元中均與發出交易請求資料的該使用者的使用者終端相關連的核準路由資料中選取交易屬性符合交易請求資料的交易屬性之核準路由資料，以及，根據此處選取的核準路由資料以執行用於使用者的內部核準處理；及在因內部核準處理的結果而從要求的核準者取得核準的情形中，將作為核準標的之交易中下單或收到的訂單的資料傳送給使用者的交易對手的終端。

此外，從「實施方式」一節及附圖，將更清楚本申請案中揭示的問題及其解決方法。

根據本發明，在購買操作系統的每一使用者使用共用的程式資源的假定下，每一使用者能夠定義及使用其自己獨有的核準規則。

系統配置

於下，將使用附圖，詳細說明本發明的實施例。圖1是根據本實施例之購買操作系統100的配置。根據本實施例之購買操作系統100(此後稱為系統100)是電腦系統，由例如公司及組織等眾多使用者共用，以及，執行使用者之間的產品、服務等中間處理。本系統100可以說是提供眾多具有不同的核準標準的購買公司2或組織可以執行合作購買操作的環境(系統中的資源以邏輯方式分割的環境，例如ASP)之電腦。此外，眾多公司2及它們的交易對手公司3可以經由例如網際網路等網路140而模擬使用電腦。

因此，可以假定系統100為伺服器設備，伺服器設備經由網路140耦合至大量的使用者終端300(較佳地，也為核準者終端400)，在處理使用者終端之間交易的產品或服務期間，在網路上提供場所作為電子市場，以及，執行產品搜尋、己下的訂單或收到的訂單之資料處理、交易歷史管理及核準處理。在使用者終端300之間，由購買公司2所使用且均執行產品或服務的購買操作之使用者終端稱為購買公司終端350，而由交易對手公司3所使用且均在收到來自購買公司2的訂單時遞交產品或服務的使用者終端稱為交易對手公司終端360。

此外，系統100在儲存單元101中包含登入程式4、請求源程式5及交易對手程式6。請求源程式5提供下述功能：由購買公司2所使用的產品搜尋功能10以搜尋要下訂單的產品；訂單請求功能11，從購買公司2接收訂單，接著處理訂單；核準功能12，根據每一使用者的各別核準路由以執行核準處理；及下單歷史管理功能13，管理使用者下的訂單之歷史資料。此外，交易對手程式6提供訂單接收功能14及出貨登錄功能15。訂單接收功能14從購買公司2接收訂單，出貨登錄功能15登錄標示交易對手公司3已根據訂單而對可應用的產品等執行出貨處理之資料、等等。

應注意，關於與購買操作有關的使用者授權，假定為「客戶」或「核準者」。關於購買處理，屬於每一購買公司2且具有「客戶」授權的使用者(此後稱為「客戶使用者」)藉由使用登入程式4以登入系統100，接著，藉由使用請求源程式5的產品搜尋功能10及訂單請求功能11，產生核準請求資料。另一方面，具有「核準者」授權的使用者(此後，稱為「核準使用者」)藉由使用登入程式4以登入系統100以及藉由使用請求源程式5的核準功能12以執行核準處理。

此時，系統100將核準路由資料中設定的核準者所使用的核準終端400網路上的位址儲存在儲存單元101中。然後，核準功能12(核準路由控制器111)將核準請求與訂單請求(交易請求資料)一起傳送給核準者終端400的位址，該位址係包含於核準路由資料中。舉例而言，核準請求資料是設有接收核準或不核準的輸入之介面的螢幕資料。然後，核準功能12取得標示來自核準者終端400的核準者的核準或不核準之輸入資料，接著，決定核準或不核準是否從核準路由資料中所界定的所有核準者取得的。假使核準功能12判定核準是自核準路由資料中所界定的所有核準者取得的，則核準功能12將判定結果通知訂單請求功能11(交易執行單元)。

由於可以對單一核準請求事件設定一或更多核準者，所以，在從核準路由資料中設定的所有核準者完成取得核準時，核準請求事件對於對應的一交易對手公司3變成正式訂單事件。

在交易對手公司3中具有「交易對手代表」授權之使用者藉由使用登入程式4以登入系統100，接著，相對於對應的一購買公司2所產生的正式定單事件，藉由使用交易對手程式6的訂單接收功能14及出貨登錄功能15，執行訂單接收處理及出貨處理。例如關於每一使用者的購買歷史屬性資訊、、產品資訊及其它資訊等隨著使用而成為有用的資訊會被儲存於以邏輯方式劃分給資料庫7中每一購買公司2或交易對手公司3的空間中，資料庫7是所有使用者共同的且包含於系統的儲存單元101中。

此外，根據本實施例的系統100包含WEB伺服器8及DV伺服器9。WEB伺服器8設有登入程式4、請求源程式5及交易對手程式6以作為儲存單元中的業務應用程式。此外，DV伺服器9包含使用者主屬性125、要由系統100處理的產品及服務的清單之資料、要由系統100處理的產品及服務的訂單資料、下單歷史資料及核準路由資料(核準路由申請主條件126及核準路由主控制127)作為儲存單元101中的資料庫7。當執行業務應用中的每一功能時，網頁伺服器8經由網路140取出/寫入DB伺服器9的資料庫7中的每一件資訊。

上述系統將儲存於例如非揮發性記憶體中的儲存單元101中的程式102讀出至記憶體103中，以提供執行購買操作處理方法的功能。系統100接著促使作為算術單元的CPU 104執行程式。此外，系統100包含例如通常用於電腦的鍵盤及不同型式的按鍵等輸入介面105、例如LED或顯示器等輸出介面106以及用於與使用者終端300及核準者終端400通訊的通訊單元107。

接著，舉例而言，將說明根據程式102而由系統100配置及保有的功能單元。如上所述，每一功能單元可以整體地設置於單一伺服器設備等上。但是，可以假定功能單元以分散方式配置於網路140上的多個電腦上以及在預定伺服器設備的發起下，以合作方式工件。

系統100包含核準路由設定接收單元110。核準路由設定接收單元110從使用者或輸入介面105所使用的使用者終端接收用於使用者之核準路由資料，核準路由資料包含彼此相關連的交易屬性及核準者屬性，交易屬性是核準標的。此處，核準路由資料是在產品或服務交易時每一使用者所要求的內部核準之核準路由的資料。核準路由設定接收單元110將如此收到的核準路由資料儲存在儲存單元101中。可以假定此核準路由設定接收單元110由上述請求源程式5提供。

此外，系統100包含核準路由控制單元111。核準路由控制單元111從使用者終端300接收產品及服務的交易請求資料。核準路由控制單元111接著從與發出交易請求資料的使用者終端300中之一對應終端的使用者相關連的核準路由資料中選取屬性與交易請求資料相符的核準路由資料。核準路由控制單元111接著根據此處選取的核準路由資料，執行用於使用者的內部核準處理。可以假定請求源程式5所提供的核準路由控制單元111。

此外，系統100包含交易中間執行單元112，在因內部核準處理的結果而從所需的核準者取得核準之情形中，交易中間執行單元112將核準標的交易所下單或收到的訂單之資料傳送給使用者的交易對手的終端。可以假定此交易中間執行單元112由請求源程式5及交易對手程式6提供。

應注意，核準路由設定接收單元110可以配置成傳送核準路由資料的輸入接收螢幕資料給使用者端300或輸入介面105，以及，也從使用者終端300或輸入介面105接收輸入於輸入接收螢幕中的核準路由資料。輸入接收螢幕資料可以配置成包含用於接收包含於核準路由中的每一核準者的核準授權等級的設定之介面、以及用於接收包含於核準路由中的每一核準階段所需的核準者核準授權等級設定之介面。

此外，系統100可以配置成將關於每一使用者的核準者候選人資訊以及候選人的核準授權等級的資料儲存於儲存單元101中。此外，核準路由設定接收單元110可以以下述方式配置。在經由輸入接收螢幕而從使用者端300或輸入介面105收到每一核準階段中所需的核準授權的設定時，核準路由設定接收單元110指定具有等於或大於收到的設定中所需的核準授權等級之核準授權等級的核準者候選人，然後，產生核準候選人清單。之後，核準路由設定接收單元110將核準候選人清單的資料傳送給使用者終端300或輸入介面150，以及，接收標示核準候選人清單中選取的核準者之指令。

此外，核準路由設定接收單元110可以配置成將核準路由資料的輸入接收螢幕資料傳送給使用者終端300或輸入介面105，以及，從使用者終端300或輸入介面105，接收輸入接收螢幕中輸入的核準路由資料。輸入接收螢幕資料包含：用於接收核準路由之核準處理標的之交易中訂購的產品或售出的產品的屬性設定之介面；用於接收付款源資訊的介面，付款源資訊是用於會計程序等的資訊；用於接收核準路由之核準處理標的之交易的交易額度範圍的設定之介面；及用於接收與使用者藉由使用者終端而發出的產品或服務的交易請求指令有關的屬性資訊之介面。

此外，核準路由控制單元111可以配置成從使用者終端300接收產品或服務的交易請求資料，以及，從交易請求資料讀出交易中被訂購的產品或售出的產品的屬性資料、交易的交易額度資料及與發出交易請求指令的使用者相關的屬性資料。然後，核準路由控制單元111配置成從儲存單元101中與發出交易請求資料的使用者終端300的使用者相關連的每一核準路由資料中，選取具有被訂購的產品或售出的產品的屬性、交易額度範圍、及使用者屬性之核準路由資料，使用者屬性是設定於符合交易請求資料中讀出的資料的核準路由資料中。然後，核準路由控制單元 111可以根據此處所選取的核準路由資料，執行用於使用者的內部核準處理。此外，系統100將所有使用者共用的核準路由資料儲存在儲存單元101中。然後，當選取具有符合那些交易請求資料的交易屬性之核準路由資料時，在具有符合那些交易請求資料的交易屬性的核準路由資料不存在於儲存單元101中的核準路由資料之情形中(每一核準路由資料與發出交易請求資料的使用者端300的使用者相關連)，核準路由控制單元111可以從儲存單元101中選取共用的核準路由資料。

此外，對每一或多個交易屬性，設定所有使用者共同的核準路由資料。當選取具有符合那些交易請求資料的交易屬性之核準路由資料時，在具有符合那些交易請求資料的交易屬性之核準路由資料不存於儲存單元101中的核準路由資料中的情形中(每一核準路由資料與發出交易請求資料的使用者端300的使用者相關連)，核準路由控制單元111從儲存單元101的共同核準路由資料中選取某共同核準路由資料，該某共同核準路由資料中設定有包含於交易請求資料中的交易之預定屬性資料。

此外，系統100儲存要由設定於核準路由資料中的核準者所使用的核準終端400的網路上的位址。核準路由控制單元111可以以下述方式配置。當根據選取的核準路由資料執行內部核準處理時，核準路由控制單元111將核準請求資料與交易客戶資料一起傳送給包含於核準路由資料中的核準終端400的位址，以及，從核準者終端400中取得核準者核準或不核準的輸入資料。然後，核準路由控制單元111決定是否從核準路由資料中界定的所有核準者取得核準。假使判定從所有核準者取得核準，則核準路由控制單元111將決定結果通知交易執行單元。

應注意，系統100中每一功能單元110至112可以以硬體或儲存於例如記憶體或HDD(硬碟機)等適當的儲存單元中的程式來實施。在此情形中，當執行程式時，系統100的CPU從儲存單元讀出程式以及執行程式。

表格結構實施例

接著，將說明根據本實施例的購買操作系統100所使用的表格的結構。圖2顯示之圖形分別顯示A(使用者主屬性125)、B(核準路由主申請條件126)、及C(核準路申主控制127)的資料結構。

使用者主屬性125是記錄組，記錄組中的每一記錄儲存與個別使用者相關的屬性，每一個別使用者藉由對應的一使用者終端300，發出產品或服務的交易請求指令。舉例而言，在每一記錄中，以使用者ID作為鑰匙，使例如公司碼、辦公室碼及一對應的個別使用者所屬之公司的分區碼、核準授權型式及核準授權等級等資料彼此相關連。應注意，此處「個別使用者」一詞意指真正地操作使用者終端300的個人，例如員工或工作人員，其屬於本發明的申請專利範圍的範圍中之「使用者」(公司或組織)。

此外，核準路由申請主條件126是記錄組，每一記錄包含系統100所使用以根據交易屬性而選取核準路由資料之選取條件的說明。在每一記錄中，使用核準路由定義ID作為鑰匙，以及，使例如公司碼、辦公室碼、分區碼、基本價格範圍(交易額度範圍)、及授權(在多個核準路由資料是可選取的情形下用於選取核準路由之授權等級)等被允許實施此核準路由的資料彼此相關連。

此外，核準路由申請主條件127是記錄組，每一記錄儲存用於每一使用者(公司或組織)之每一核準路由資料的定義內容。舉例而言，在每一記錄中，使用核準路由定義ID作為鑰匙，使例如設定接受階段的數目(核準階段的數目)、均為關於核準者屬性資訊的核準者公司碼、核準者辦公室碼、及核準者分區碼、核準者碼、核準者所使用的核準者終端400的位址、所需的核準授權等級(能夠給予用於每一核準階段數目之核準者授權等級)、及表示對應的一核準階段是要求核準之要求旗標彼此相關連。

應注意，所有使用者共同的核準路由資料及申請條件設定於核準路由申請主條件126及核準路由主控制127中。在此情形中，如圖9所示，舉例而言，「@」設定於例如公司碼、辦公司碼、分區碼、核準授權型式及核準授權等級等各別資料項中，作為儲存於核準路由申請主條件126中的申請條件之一(圖9中的「WF5」)。此「@」是一記號，代表由「@」標示的條件由所有使用者的屬性中對應的一屬性所取代並接著被申請。同樣地，「@」設定在均為核準者的屬性資訊之例如核準者公司碼、核準者辦公司碼及核準者分區碼等每一資料項中，作為儲存於核準路由主控制127中儲存的申請路由資料之一(圖9中的「WF5」)。對多個交易屬性中的每一屬性，設定所有使用者共同的核準路由資料。舉例而言，某共同的核準路由資料對應於公司碼K1至K3，另一共同核準路由資料對應於從「100,000日圓」至「500,000日圓」的交易額等等。

處理流程實施例1

於下，將根據圖式，說明根據本實施例之購買操作處理方法的真實程序。應注意，對應於下述要說明的購買操作處理方法之每一型式的操作是以由系統100讀入記憶體中並執行的程式來實施。此程式由用於執行下述說明的不同型式的操作之碼構成。

圖3顯示根據本實施例之購買操作處理的處理程序實施例1。此處，將說明屬於某一合作的購買公司2之客戶使用者購買產品之情形的處理流程。當嘗試登入系統100的客戶使用者經由網路140存取網頁伺服器8的登入程式4時，登入程式4將能夠接收使用者ID及密碼輸入的螢幕資料(此後稱為登入螢幕)傳送給客戶使用者所使用的購買公司終端350。

為回應此操作，客戶使用者在顯示於購買公司終端350上的登入螢幕上輸入使用者ID及密碼及按下的登入按鍵。接著，輸入的資訊經由網路140，從購買公司終端350傳送給網頁伺服器8的登入程式4。

網頁伺服器8的登入程式4經由網路140查詢DB伺服器9的使用者主屬性125，然後，決定購買公司終端傳送來的密碼是否正確，同時，取出公司識別區、公司碼、辨公司碼(此後稱為客戶使用者資訊)、核準等級及客戶使用者授權等每一資料(S301)。

接著，登入程式4決定步驟S301中取出的客戶使用者授權的種類(步驟S302)。假使授權為「客戶」，則登入程式4將顯示能夠分別執行產品搜尋功能10及訂單請求功能11的螢幕顯示鍵(此後稱為客戶選單螢幕)之資料傳送給客戶使用者所使用的購買公司終端350(S303)。另一方面，假使客戶使用者的授權是非「客戶」授權時，登入程式4將能夠顯示允許其它授權中的每一授權之功能的按鍵傳送給合作的購買公司終端350。

當在購買公司終端350中客戶使用者按下客戶選單螢幕上顯示的產品搜尋鍵時，執行請求經由網路140從購買公司終端350傳送至網頁伺服器8的產品搜尋功能10(S304)。

在收到執行請求時，網頁伺服器8的產品搜尋功能10將能夠接收用於搜尋產品的條件輸入之螢幕(此後稱為產品搜尋螢幕)的資料傳送給客戶使用者的購買公司終端350(S305)。

當客戶使用者在顯示於購買公司終端350上的產品搜尋螢幕上輸入搜尋條件及按下搜尋鍵時，搜尋條件經由網路140從購買公司終端350傳送至網頁伺服器8的產品搜尋功能10(S306)。

網頁伺服器8的產品搜尋功能10根據從購買公司終端350傳送來的搜尋條件，從DB伺服器9的產品資料中取出符合搜尋條件的產品資料。然後，產品搜尋功能10將顯示取出結果的螢幕(此後稱為搜尋結果螢幕)之資料傳送給客戶使用者的購買公司終端350(S307)。

當客戶使用者從顯示於購買公司終端350上的搜尋結果螢幕選取客戶使用者發出訂單請求的產品、按下訂單產生鍵時，執行請求會經由網路140而從購買公司終端350傳送至網頁伺服器8的訂單請求功能11(S308)。

在從購買公司終端350收到執行請求時，網頁伺服器8的訂單請求功能11將能夠接收與使用者選取的產品之送貨資訊、付款源資訊及核準者資訊有關的輸入之訂單請求產生螢幕(此後稱為訂單請求產生螢幕)的資料經由網路140而傳送給客戶使用者的購買公司終端350(S309)。此後，此輸入資訊稱為訂單請求資訊。當客戶使用者在輸入訂單請求資訊並以下述說明的處理方法指定核準者之後按下訂單請求鍵時(S310)，產品資訊、送貨資訊及付款源資訊會經由網路140，從購買公司終端350傳送給網頁伺服器8的訂單請求功能11。在從購買公司終端350收到訂單請求資訊時，訂單請求功能11將資訊當作訂單請求事項寫入DV伺服器的訂單資料及訂單歷史資料中(S311)。

應注意，在步驟S311之前，根據訂單請求功能11自動選取的核準路由資料、包含客戶使用者所指定的核準者之核準路徑資料，執行內部核準處理。以訂單請求功能11將訂單請求資料與訂單請求資訊(交易請求資料)一起傳送給包含於自動選取的核準路由資料中的核準者的核準者終端400的位址之方式，執行此處理。然後，從核準者終端400接收表示核準者核準或不核準的輸人資料。之後，決定是否從核準路由資料中界定的所有核準者取得核準。假使判定從核準路由資料中界定的所有核準者取得核準，則執行步驟S311。

處理流程實施例2

接著，將說明處理流程實施例之步驟S308至S311中用於自動選取核準路由及設定核準者之處理。圖4顯示根據本實施例之購買操作處理方法的處理程序實施例2。應注意，請求源程式5的訂單請求功能11規劃有訂單請求螢幕顯示幕組5a、核準者設定螢幕顯示模組5b、核準者清單螢幕顯示模組5c及訂單請求產生模組5d。

在客戶使用者在處理程序實施例1的步驟308中按下訂單請求產生鍵，接著，在步驟S309中經由網路140而由網頁伺服器8接收執行請求之後(S501)，訂單請求螢幕顯示幕組5a將圖5中所示的訂單請求產生螢幕G601傳送給客戶使用者的購買公司終端350(S502)。

客戶使用者在訂單請求產生螢幕G601中輸入要購買的每一產品的付款源資訊G602，以及，按下核準者設定鍵G603。然後，將此執行請求經由網路140從購買公司終端350傳送給網頁伺服器8的核準者設定螢幕顯示模組5b。

在收到執行請求之後，核準者設定螢幕顯示模組5b使用步驟S301中取得的客戶使用者屬性、步驟S308中客戶使用者所選取的產品資訊、及訂單請求產生螢幕G601上指定的付款源資訊G602作為申請條件，然後，經由網路140，從DV伺服器9的核準路由申請主條件126中取出符合這些申請條件的核準路由定義ID。在不存在有符合申請條件的此種核準路由定義ID的情形中，執行錯誤處理。

另一方面，在存在有符合申請條件的此種核準路由定義ID的情形中，核準者設定螢幕顯示模組5b藉由使用取出的核準路由定義ID作為鑰匙以從核準路由主控制127取出所有可申請的核準路由資料(S504)。

核準者設定螢幕顯示模組5b從核準路由主控制127中取出的每一核準路由資料中取出每一設定接受階段號數的要求旗標、以及取出設定接受階段號數中最大的值。然後，核準者設定螢幕顯示模組5b將核準者設定螢幕G701經由網路140傳送給客戶使用者的購買公司終端350(S505)，核準者設定螢幕G701顯示等於或大於設定接受階段號數的最大值之核準者設定欄的數目、設定核準階段的號數的每一欄位中標示「要求的」或「選項的」的資訊、及核準者搜尋鍵G702(請參考圖6)。

當客戶使用者按下顯示於購買公司終端350上用於核準者設定螢幕G701上的每一核準階段欄之核準者搜尋鍵G702時，此執行結果及對應的搜尋鍵的核準階段號數G703的資料會經由網路140而從購買公司終端350傳送給網頁伺服器8的核準者清單螢幕顯示模組5c(S506)。

在收到來自購買公司終端350的執行請求時，核準者清單螢幕顯示模組5c藉由使用步驟S504中取出的核準路由定義ID及從客戶使用者的購買公司終端350傳送來的核準階段號數G703的資料作為鑰匙，查詢DB伺服器9的核準路由主控制127中可申請的資料。此外，核準者清單螢幕顯示模組5c藉由使用此處查詢的資料中設定的核準者公司碼、核準者辦公室碼、核準者分區碼、需要的核準等級及核準者碼作為鑰匙，以從使用者主屬性125中取出可特別用於可申請的核準階段號數之核準者使用者資訊(S507)。此時，要被取出的核準者需為具有等於或大於所需的核準等級之核準等級的使用者。

接著，訂單請求功能11將核準者清單螢幕顯示模組5c所取出的核準者使用者資訊傳送給客戶使用者的購買公司終端350作為圖7中所示的核準者清單螢幕G801(S508)。當客戶使用者從核準者清單螢幕G801選取訂單請求功能11傳送來的核準者清單中設定的核準者以及按下選取鍵G802時，核準者(在圖式的實施例中為「使用者2」)被設定在核準者設定螢幕G704的如圖6所示的核準者設定螢幕的可申請階段號數(在圖6中為「1」) 。

重複步驟S506至步驟S509的處理直到客戶使用者設定均需要指定核準者之所有核準階段號數的核準者。當客戶使用者在完成對所有核準者的設定時，按下購買公司終端350上顯示的核準者設定螢幕的申請鍵G705時，顯示客戶使用者所設定的一序列核準者(換言之，他們可以被稱為核準路由)。

在對購買產品重複地執行步驟S503至步驟S509中所要求的處理之後，客戶使用者按下訂單請求產生螢幕的訂單請求產生鍵。此時，購買公司終端350檢查是否有遺失的要求的核準者設定以及關於核準者及核準路由的組織資訊是否與對應於每一產品的訂單請求一致。假使未發現此遺失的設定，則訂單請求產生資料會經由網路140而從購買公司終端350傳送至訂單請求產生模組5d。訂單請求產生模組5d將從購買公司終端350收到的資料傳送給DB伺服器9作為訂單請求事項及將此事項登記作為訂單請求資料及訂單歷史資料(S510)。

核準路由自動選取控制實施例1

圖8顯示使用者主屬性、核準路由申請主條件126及核準路由主控制127的設定實施例、以及核準路由的自動選取控制的實施例。在本實施例中，三個不同的核準路由定義ID被定義為WF1(D911)、WF2(D912)及WF3(D913)。此外，對於核準路由定義ID所述的資料，當屬於公司碼「K1」、辦公室碼「001」及分區碼「A」的客戶使用者發出核準請求時，WF1(D911)及WF2(D912)是要被取出的資料。此外，在購買產品的單價不小於10,000日圓時，應用核準者定義ID的資料WF2(D912)。對於其它情形，應用核準者定義ID的資料WF1(D911)。

此外，在屬於具有公司碼「K2」的公司的客戶使用者之情形中，應用核準者定義ID的資料WF3(D913)。在核準路由主控制127中，對每一核準路由定義ID WF1至WF3(D911－D913)的每一核準階段的號數，設定能夠給予核準的核準者的申請條件。在這些設定實施例中，同樣地，對用於核準者定義ID的資料WF1(D921)，將核準階段號數設定為一階段，對用於核準者定義ID的資料WF2(D922至D923)及WF3(D924至D925)設定為二階段。

關於核準路由定義ID的第一階WF1(D911)的核準者，需要具有公司碼「K1」、辦公室碼「001」及核準等級不小於「1」的核準者。關於核準路由定義ID WF2(D912)，對第一階段可應用與核準路由定義ID WF1(D921)相同的設定。除此之外，核準路由主控制127的核準路由(D923)中的第二階段需要具有核準等級2或更大且屬於分區碼B之核準者。此外，對於核準路由定義IDWF3(D913)，核準路由主控制127的核準路由(D924)中的第一階段需要具有公司碼「K2」、辦公室碼「111」、分區碼「B」及核準等級等於或大於「1」的核準者。此外，在核準路由(D925)中，可以選加地設定與D924的情形具有相同的公司碼及辦公室碼、且分區碼「C」及核準等級等於或大於「2」的核準者。

舉例而言，考慮使用者1(D901)發出價格100日圓的產品之核準請求的情形(實施例1)。當客戶使用者在步驟S503按下核準者設定鍵時，訂單請求功能11使用關於客戶使用者的聯合資訊之公司碼「K1」、辦公室碼「001」、分區碼「A」、以及產品的購買價格「100日圓」作為申請條件並因而從核準路由申請主條件126取出可申請的核準路由定義ID。此時，由於用於「WF1」的單價之條件是購買產品的額度小於10,000日圓，所以，在它們的申請條件中均具有公司碼「K1」的申請路由ID「WF1」(D911)及「WF1」(D912)中，取出「WF1」(D911)作為可申請的路由定義ID。

訂單請求功能11使用核準路由定義ID「WF1」作為鑰匙並因而從核準路由主控制127中取出可申請的資料(D921)。由於取出的核準路由資料D921的設定接受階段數目僅為一(要求的)，所以，在步驟S505中，訂單請求功能11將僅顯示一核準指定欄位的核準者設定螢幕傳送給客戶用者的購買公司終端350。

此外，當客戶使用者在步驟S506中按下核準階段號數「1」的核準者搜尋鍵時，在步驟S507中，訂單請求功能11取出使用者3(D903)及使用者4(D904)的資料，使用者3(D903)及使用者4(D904)均具有核準者公司碼「K1」、核準者辦公室碼「001」、授權「核準者」、及具有等於或大於「1」的所需核準者等級，這些都是設定於藉由使用核準路由定義ID「WF1」及設定接收階段「1」而取出的核準路由資料D921中。

在步驟S508中，訂單請求功能11將取出的使用者3(D903)及使用者4(D904)的資料作為清單螢幕傳送給客戶使用者的購買公司終端350。此外，在步驟S509中，客戶使用者從清單螢幕取出核準者以及設定核準者。

類似地，在使用者(D901)購買價格20,000日圓的產品之情形中(實施例1)，雖然「WF1」(D911)及「WF2」(D912)均符合作為步驟S504中取出的核準路由定義ID之條件，但是，在此情形中，應用具有更高優先權的「WF2」(D912)。訂單請求功能11使用核準路由定義ID「WF2」(D912)作為鑰匙並因而從核準路由主控制127中取出可申請的核準路由資料(D922)及(D923)。由於用於取出的資料之設定核準階段的號數為「1」及「2」，所以，在步驟S505中，訂單請求功能11將顯示核準階段指定欄的核準者指定螢幕傳送給客戶使用者的購買公司終端350。

客戶使用者對第一及第二核準階段等每一階段重複步驟S506至S509的處理，並因而指定核準者。此使，如同實施例1的情形般，在步驟S507的處理中，在第一階段中需要設定使用者3(D903)或使用者4(D904)，以及在第二階段中需要設定屬於公司碼「K1」、辦公室碼「001」、及具有等於或大於「2」的核準等級之核準者。因此，僅有使用者4(D904)可以被設定為核準者。

應注意，核準路由中所需的核準等級也可以被設定為用於客戶使用者。舉例而言，在具有核準等級1的客戶使用者：使用者2(D902)購買價格20,000日圓的產品之情形中(實施例3)，在步驟S504中要取出的核準路由定義ID如同(實施例2)的情形般為「WF2」(D912)。但是，由於客戶使用者：使用者2(D902)的核準等級為1，所以，判定客戶使用者也具有第一階段(D922)的核準授權，第一階段(D922)的核準授權具有所需的核準等級「1」。因此，在步驟S505中，將未顯示第一核準階段的核準者指定欄位但僅顯示第二核準階段的核準者指定欄位之核準者指定螢幕，傳送給客戶使用者的購買公司終端350。客戶使用者藉由同於實施例2中用於在第二核準者階段的核準指定欄位中指定核準者之處理，指定核準者。

此外，在屬於公司碼「K2」的使用者：「使用者5」(D905)購買產品(實施例4)的情形中，以訂單請求功能11取出核準路由定義ID「WF3」(D913)(由於辦公司碼及分區碼未設定於申請條件中，所以，對所有屬於公司碼「K2」的使用者取出核準路由定義ID「WF3」)。此外，訂單請求功能11使用核準路由定義ID「WF3」作為鑰匙並因而從核準路由主控制127取出核準路由資料(D924)及(D925)。由於定義用於第二階段的核準者之核準路由資料(D925)是選加設定，所以，在步驟S505中，訂單請求功能11將在第一及第二階段的核準者指定欄位中分別顯示「要求設定」及「選加設定」的核準者設定螢幕傳送給客戶使用者的購買公司終端350。

當客戶使用者在步驟S506至S509中指定核準者時，要求指定第一核準階段的核準者(在步驟S507的處理中要取出的核準者為「使用者6」(D906))。但是，指定第二階段中的核準者是選加的，以致於適當地指定核準者。當核準者要被設定於第二階段時，如同第一階段的情形般，藉由執行步驟S506至S509的處理，以設定核準者(在步驟S507的處理中要取出的核準者為「使用者7」(D907))。

核準路由自動選取控制實施例2

接著，將使用圖9，說明眾多購買公司2使用共同核準路由(核準規則)的情形之定義核準路由的方法及自動選取處理方法。在眾多購買公司2使用共同核準路由的情形中，對於在核準路由申請主條件126及核準路由主控制127中具有相同內容的核準路由資料之每一購買公司2而言，在改進或消除主條件或主控制時時會增加問題。此外，為了避免執行發生於要應用的核準路由定義在步驟S504中並不存在的情形下的錯誤處理，較佳的是預先設定定義，此定義可以由購買公司2廣泛地使用以及應用於個別設定的核準路由資料與應用條件不相符之情形。

在上述情形中，如圖9所示，藉由將「@」設定在核準路由申請主條件126及核準路由主控制127每一項中，使得核準路由的每一申請條件是可以讀取及可由對應的客戶使用者的屬性之一所取代(已於圖2中說明)。舉例而言，在圖9中，核準路由定義ID「WF4」(D1011)是公司碼「K3」的獨特定義，而「WF5」(D1012)是所有購買公司共同的核準路由的定義，包含設定於公司碼、辦公室碼及分區碼中的「@」。

在屬於公司碼「KF3」的客戶使用者：「使用者8」(D1001)購買單價100日圓的產品之情形中(實施例5)，在步驟S504中要由訂單請求功能11取出的核準路由定義ID為「WF5」(D1012)加上「WF4」(D1011)，「WF4」(D1011)係被個別地定義用於具有公司碼「K3」的公司。此時，關於核準路由定義ID「WF5」(D1012)，訂單請求功能11分別以「K3」、「001」及「A」等關於「使用者8」(D1001)的屬性資訊取代設定作為公司碼、辦公司碼及分區碼的「@」。

在本實施例中，客戶使用者：「使用者8」(D1001)是要購買單價100日圓的產品，以及當單價未小於10,000日圓時應用核準定義ID「WF4」(D1011)。

訂單請求功能11使用核準路由定義ID「WFS」(D1012)作為鑰匙並因而從核準路由主控制127取出可應用的核準由資料(D1023)。此外，由於核準路由資料(D1023)包含核準者公司碼「@」、核準者辦公司碼「@」及核準者分區碼「@」，所以，當在步驟S507中取出用於核準階段號數「1」的核準者清單時，訂單請求功能11讀取這些碼碼中的「@」記號並分別以客戶使用者的公司碼「K3」、辦公司碼「001」及分區碼「A」取代之。此外，從使用者主屬性125取出屬於相同組織之作為客戶使用者的核準者使用者「使用者9」(D1002)。

此外，使用者主屬性125的「公司識別碼」是用於將多個公司分組(聯合公司、等等)的定義。因此，雖然在本實施例中省略下述的說明及實施例，但是，如同公司碼等被設定於核準路由申請主條件126中的情形般，「公司識別碼」可以作為用於核準路由的申請之申請標準。

根據本實施例，即使在能夠由具有不同核準標準之眾多公司或組織共同使用的環境中(以邏輯方式分割系統資源之環境，例如ASP)，每一公司或組織仍然能夠使用其自己獨特的核準規則(核準路由)。此外，在共同核準標準由眾多公司或組織採用的情形中，藉由使用共同核準規則以控制例如主資料等不同資料的設定量，而簡化資料的維護及管理。根據上述效果，可以降低核準處理程式等的發展及操作處理的數目，同時，可以維持設於購買操作系統中的功能的多樣性。此外，由於不需要傳統系統中所使用的資料鏈結處理，所以，可以以適當成本實現購買操作系統。

因此，在購買操作系統的每一使用者使用共同的程式資源的假設下，每一使用者能夠定義及使用其自己獨特的核準規則。

應注意，雖然上述以用於非直接材料或直接材料之網路耦合購買操作系統為例說明，但是，本發明也可以應用至均具有關於系統的使用者的組織資訊及使用視內容而變的核準工作流程的所有操作系統。舉例而言，本發明可以應用至用於相同組織中、或多個組織中的管理核準事務、內部報告流通操作、等等之操作系統。

如上所述，已以實施例為基礎來提供本發明的實施例。但是，本發明不限於此。在不悖離本發明的精神及範圍之下，可以對實施例作不同的修改。

2‧‧‧購買公司

3‧‧‧交易對手公司

4‧‧‧登入程式

5‧‧‧請求源程式

5a‧‧‧請單請求螢幕顯示模組

5b‧‧‧核準者設定螢幕顯示模組

5c‧‧‧核準者清單螢幕顯示模組

5d‧‧‧請單請求產生模組

6‧‧‧交易對手程式

7‧‧‧資料庫

8‧‧‧網頁伺服器

9‧‧‧DB伺服器

10‧‧‧產品搜尋功能

11‧‧‧訂單請求功能

12‧‧‧核準功能

13‧‧‧訂單下單歷史管理功能

14‧‧‧訂單接收功能

15‧‧‧出貨登錄功能

100‧‧‧購買操作系統

101‧‧‧儲存單元

103‧‧‧記憶體

104‧‧‧CPU

105‧‧‧輸入介面

106‧‧‧輸出介面

107‧‧‧通訊單元

140‧‧‧網際網路

350‧‧‧購買公司終端

360‧‧‧交易對手公司終端

圖1是根據本實施例之購買操作系統的整體配置圖；圖2顯示根據本發明的實施例之使用者主屬性、核準路由申請主條件及核準路由主控制的資料結構實施例；圖3是流程圖，顯示本實施例的購買操作處理方法的處理程序1；圖4是流程圖，顯示本實施例的購買操作處理方法的處理程序2；圖5顯示本實施例的訂單請求產生螢幕的實施例；圖6是顯示本實施例的核準者設定螢幕的實施例；圖7是核準者清單螢幕；圖8顯示根據本實施例的核準路由的自動選取控制實施例1；及圖9顯示根據本實施例的核準路由的自動選取控制實施例2。