專利名稱：包括生成、處理和跟蹤在內(nèi)的貿(mào)易運作及貿(mào)易單證的集成系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明總體涉及貿(mào)易運作的管理系統(tǒng)和方法，具體來說，涉及一種生成、處理并跟蹤單證的系統(tǒng)和方法以及與進(jìn)口/出口貿(mào)易運作相關(guān)聯(lián)的處理流程。
背景技術(shù)：
目前采購商和銷售商之間貿(mào)易運作的單證處理流程，手工方式強度大且容易出錯。通常貿(mào)易運作開始于要從一銷售商采購商品而索要該商品報價的采購商。采購商和銷售商商議導(dǎo)致該報價的貿(mào)易條款以及雙方達(dá)成一致作為協(xié)議基礎(chǔ)的其它條款和條件。采購商接著向銷售商發(fā)出反映達(dá)成一致的報價、條款以及條件的采購訂單(PO)。該PO規(guī)定該交易的必要組成部分，例如商品種類、數(shù)量和價格以及例如交貨時間和地點這類其它細(xì)節(jié)。雖然并不總是需要，但貿(mào)易處理流程中下一步驟是由銀行頒發(fā)信用證(L/C)。所生成的L/C依據(jù)并通常結(jié)合全部達(dá)成一致的條款和條件以及全部的PO信息。若銷售商符合L/C的全部條款和條件，L/C本質(zhì)上是該L/C頒發(fā)銀行(頒證銀行)的付款保證。具體來說，由于銀行交易的是單證而非商品，銷售商必須出示嚴(yán)格符合L/C的整套單證以便頒證銀行授予該L/C。該L/C是由頒證銀行根據(jù)該采購商的信用價值頒發(fā)的。
PO和/或L/C傳送至接著便到位以制造(或供應(yīng))并裝運采購商所需商品的銷售商。就內(nèi)部來說，一旦收到PO和/或L/C，銷售商便創(chuàng)建一銷售單，制作該銷售單證。銷售單反映PO和/或L/C的要求。若銷售商是一制造商，該銷售單便用于生成一實際商品據(jù)此制造的制造說明單。若銷售商是一分銷商，該銷售單便用于生成一用來提取要裝運商品的倉儲提取單。作為替代，銷售商可用采購商的PO和/或L/C，生成其自己的發(fā)出給商品實際制造商的采購訂單PO。一旦制造過程接近全面完成，銷售商便聯(lián)系裝運商/貨運運輸商來管理商品的裝運。銷售商向裝運商發(fā)裝運指令，裝運商據(jù)此生成裝貨單以及報關(guān)單(根據(jù)需要)。
當(dāng)銷售商(通過制造、從倉儲當(dāng)中提取或從制造商那里獲得)有商品可供作裝運時，銷售商生成PO和/或L/C所需的全部單證。上述單證通常包括商品發(fā)票、提取單、檢驗和/或原產(chǎn)地證明。另外，此時銷售商還提供單證用于該商品運輸，獲取裝運保險，并向原產(chǎn)地和目的地政府機(jī)構(gòu)提交所需貿(mào)易單證。一旦裝運好商品，便出示PO和/或L/C所需的全部貿(mào)易單證以便與頒證銀行(或代表頒證銀行進(jìn)行代理的另一商議銀行)商議。
由上面說明很容易知道，就貿(mào)易運作制作單證所需的處理流程，涉及多方根據(jù)輸入到銀行系統(tǒng)內(nèi)的采購商的相同冗余采購信息生成多種單證，銷售商以及其它貿(mào)易合作方因而很容易出錯和總體低效率。單證中上述差錯會造成包括商品裝運延誤在內(nèi)的整個處理流程的延誤。任何這類差錯將造成采購商收到商品的延誤以及銷售商收到付款的延誤。顯然，全部交易方都會從一種減少單證中差錯數(shù)目的系統(tǒng)和方法當(dāng)中受益。
因為這種單證處理流程并不屬于出口商或進(jìn)口商的核心業(yè)務(wù)(即采購或銷售商品)，所以許多出口商和進(jìn)口商正將該單證制作及跟蹤運作外包給第三方。此外，信用證征收處理流程中存在某種程度的風(fēng)險披露，因而許多客戶希望銀行在他們的信用證基金征收中協(xié)助他們。
發(fā)明概述鑒于現(xiàn)有技術(shù)系統(tǒng)及方法的上述限制，本發(fā)明目的在于，向采購商、銷售商、貿(mào)易伙伴、及其全球分支機(jī)構(gòu)、代理商以及供應(yīng)鏈服務(wù)提供商(例如裝運商)提供一通過互聯(lián)網(wǎng)、第三方網(wǎng)絡(luò)(增值網(wǎng)絡(luò)VAN)、租用線路或撥號連接以電子方式交換獲得與貿(mào)易相關(guān)聯(lián)的全部信息的自動設(shè)施。
還有一目的在于，根據(jù)貿(mào)易協(xié)議或合同(例如信用證或采購訂單)自動生成該貿(mào)易所需的單證。
本發(fā)明還有一目的在于，輔助出口商(銷售商)監(jiān)控其合約，輔助管理其商品制造，管理其風(fēng)險披露以及向出口商提供綜合的理財服務(wù)。
本發(fā)明另外一目的在于，輔助進(jìn)口商(采購商)監(jiān)控其合約(例如依據(jù)信用證的未到期債務(wù))，提供信息來輔助管理其存貨，管理其連帶責(zé)任以及向進(jìn)口商提供綜合的理財服務(wù)。
一較佳實施例中，本發(fā)明系統(tǒng)和方法由銀行運作執(zhí)行，但實際上部分系統(tǒng)和方法可由任意一方運作執(zhí)行。雖然目前對本發(fā)明的說明是就銀行而言的，但不應(yīng)解釋為限于銀行環(huán)境。
本發(fā)明包括4個主要部件TradeEDI(貿(mào)易電子數(shù)據(jù)交換)，Trade Manager(貿(mào)易管理器)，TradeDOC(貿(mào)易單證)以及Financial System(金融系統(tǒng))。TradeEDI對客戶提供一種系統(tǒng)的電子界面和網(wǎng)關(guān)(例如保密的互聯(lián)網(wǎng)連接)。TradeManager則提供一種用于啟動并跟蹤貿(mào)易交易狀態(tài)的客戶界面。TradeDOC主要是代表出口商(銷售商/制造商)以及供應(yīng)鏈服務(wù)提供商用于所需大量具體單證的生成，以支持貿(mào)易交易并對形成該貿(mào)易交易基礎(chǔ)的銷售商的商品制造/提取/采辦以及裝運進(jìn)行跟蹤和輔助管理。
貿(mào)易運作通常由作為銀行客戶的采購方開始。采購商利用TradeEDI或TradeManager發(fā)送一采購訂單(PO)和/或信用證(L/C)申請。PO和/或L/C借助于電子手段或通過紙件(其接著由銀行鍵入或掃描)發(fā)送。PO和/或L/C表示采購商和銷售商就監(jiān)管貿(mào)易交易所達(dá)成一致的條款和條件(例如商品種類和數(shù)量，單價，交貨日期和交貨地)。若有要求，本發(fā)明系統(tǒng)可根據(jù)所提供的PO自動生成一L/C。這種自動生成的L/C在銀行內(nèi)經(jīng)過正常的準(zhǔn)予處理。
一旦PO和/或L/C相對于客戶檔案經(jīng)過驗證，便映射至Financial System內(nèi)的數(shù)據(jù)庫，它接著送至Trade Manager所保存的數(shù)據(jù)庫。該數(shù)據(jù)庫可以是關(guān)系型、面向?qū)ο笮突騼烧叩慕M合。從整個貿(mào)易處理中前面這點起，該貿(mào)易交易各方全部能夠登錄到Trade Manager上，并迅速地確定任意特定貿(mào)易運作的狀態(tài)。本發(fā)明較佳實施例中，用戶采用一標(biāo)準(zhǔn)的瀏覽器以及互聯(lián)網(wǎng)與Trade Manager通信。用諸如加密、認(rèn)證及非否認(rèn)(non-repudiation)這種標(biāo)準(zhǔn)安全技術(shù)來提供保密通信，并確保互聯(lián)網(wǎng)以及其他電子通信媒體上各方的真正身份。運用互聯(lián)網(wǎng)是本發(fā)明令人難以置信的優(yōu)點，因為大多數(shù)貿(mào)易運作涉及的是分布于世界各地的各方。舉例來說，采購商可能在德克薩斯，而銷售商則可能在新加坡，買方銀行可能在紐約，而賣方銀行則可能在倫敦。利用本發(fā)明，任何當(dāng)事方可經(jīng)互聯(lián)網(wǎng)訪問Trade Manager150，即時地找到貿(mào)易運作的狀態(tài)。另外，TradeEDI可隨Financial System或TradeDOC對貿(mào)易交易的處理，經(jīng)互聯(lián)網(wǎng)或其他通信媒體通過電子消息向采購商、銷售商或其各自貿(mào)易伙伴交換信息(例如以推出方式發(fā)送信息)。
本發(fā)明其他有意義部分是TradeDOC。如上所述，傳統(tǒng)的現(xiàn)有技術(shù)方法中，與貿(mào)易交易有關(guān)的全部單證是以人工方式根據(jù)紙件檔案生成的。這種人工方式很明顯勞動強度高而且容易出錯。俗話說得好，要命的是細(xì)節(jié)。但很不幸，貿(mào)易運作方面的細(xì)節(jié)出錯可能在延誤或損益方面，不過更為重要的是采購商和銷售商之間所看重的關(guān)系方面，均造成極高的代價。即便銷售商具有明顯優(yōu)質(zhì)的產(chǎn)品，但假如銷售商未能管理單證的經(jīng)營細(xì)節(jié)而無法按時交貨，采購商就不愿與該銷售商交易。本發(fā)明通過在銷售商處理過程各個步驟自動生成并驗證全部單證來解決現(xiàn)有技術(shù)全部這些問題。
TradeDOC是一(公開帳戶(Open Account)事務(wù)中)可按照L/C或PO的條款和條件生成貿(mào)易單證的設(shè)施。采購商是銀行客戶而銷售商可以是或可以不是該銀行客戶的場合，TradeDOC有利于全球性供應(yīng)鏈客商的貿(mào)易單證處理。而當(dāng)銷售商是銀行客戶而采購商可以是或可以不是該銀行客戶時，TradeDOC還為銷售商生成貿(mào)易交易中相應(yīng)的貿(mào)易單證。TradeDOC保存一可與Trade Manager所保存的數(shù)據(jù)庫相比較的數(shù)據(jù)庫，因而能夠用L/C和/或PO所包含的細(xì)節(jié)為銷售商生成銷售單。作為替代，若銷售商自己生成銷售單，TradeDOC便將銷售單與L/C或PO相比較來驗證其正確性。按同樣方式，TradeDOC可生成或驗證制造說明單、發(fā)票、裝運指令、保險指令、底單、受益證明和裝貨單以及實際上銷售商所需的任何其他貿(mào)易單證以滿足L/C或PO。隨著對相同的共同數(shù)據(jù)庫中L/C和/或PO的初始采購信息均執(zhí)行TradeDOC所進(jìn)行的生成驗證運作，使得單證中出錯的可能全部被消除。一旦制造完成了、商品準(zhǔn)備裝運，TradeDOC便生成完成該交易所需的全部最終出口單證。TradeDOC可在靠近采購商或采購商銀行的地方遠(yuǎn)程打印所完成的單證以有利于征收處理。一替代實施例中，全部貿(mào)易單證以電子方式發(fā)送給接收的伙伴。本實施例在電子商務(wù)(例如電子市場)中變得越來越流行。
各個TradeDOC、TradeEDI及Trade Manager是允許銀行客戶讓他們的伙伴查看貿(mào)易單證的集成系統(tǒng)。Trade Manager提供通過互聯(lián)網(wǎng)在瀏覽器上查看TradeDOC所生成的貿(mào)易單證。根據(jù)客戶檔案向某些貿(mào)易伙伴提供打印單證的認(rèn)證。TradeEDI可根據(jù)客戶檔案中反映的客戶協(xié)議相對于貿(mào)易伙伴接收或發(fā)送電子單證。
本發(fā)明還提供對于采購商和銷售商兩者的對帳功能。當(dāng)貿(mào)易單證提供用于協(xié)商時，系統(tǒng)便通知采購商帳戶應(yīng)付款系統(tǒng)付款，并使銷售商發(fā)票與采購商發(fā)出的L/C或PO相關(guān)。同樣，當(dāng)從他們采購商接收到付款時，本發(fā)明能夠執(zhí)行一對帳處理，由此該付款相對于銷售商帳戶應(yīng)收帳款項(例如開發(fā)票項)對帳。按此方式，本發(fā)明能夠在貿(mào)易運作各個方面進(jìn)行輔助，從始發(fā)直至征收解決現(xiàn)有技術(shù)全部上述問題。
附圖簡要說明為了說明本發(fā)明，附圖中示出了目前的較佳形式。但應(yīng)理解，本發(fā)明不限于附圖給出的準(zhǔn)確形式。


圖1示出本發(fā)明系統(tǒng)主要部件；圖2示出本發(fā)明系統(tǒng)各部分執(zhí)行功能的概要圖。
圖3A和圖3B示出本發(fā)明TradeDOC部件所執(zhí)行的處理。
圖4示出本發(fā)明執(zhí)行的付款和對帳功能。
較佳實施例的詳細(xì)說明圖1示出本發(fā)明系統(tǒng)及方法中主要部件和數(shù)據(jù)流。單元100是包括貿(mào)易單證準(zhǔn)備及生成設(shè)施的TradeDOC單元。單元150是在整個貿(mào)易循環(huán)過程提供跟蹤和通信服務(wù)的Trade Manager單元。單元125是通過互聯(lián)網(wǎng)或其他電子通信媒體對客戶及其貿(mào)易伙伴之間信息保密交換提供電子網(wǎng)關(guān)和界面的TradeEDI。單元175表示諸如銀行這種金融機(jī)構(gòu)的Financial System。Financial System 175則提供諸如信用證(L/C)或公開帳戶事務(wù)的準(zhǔn)予及生成這種傳統(tǒng)金融處理服務(wù)以及依據(jù)L/C或公開帳戶的基金付款和收款。單元120和130分別表示貿(mào)易交易中的銷售商120和采購商130。
一較佳實施例中，各個TradeDOC 100、Trade Manager 150及Financial System175由金融機(jī)構(gòu)(例如銀行)主辦和運作，并包括軟件和硬件的組合。由于伸縮性和各種處理模塊(例如衛(wèi)星及集線式處理或分布式處理)，F(xiàn)inancial System 175可采用客戶機(jī)服務(wù)器或主機(jī)處理來實施?？蛻魴C(jī)服務(wù)器技術(shù)可采用諸如SUN Javasoft或Netscape Web Server，Java服務(wù)器程序(servlets)，HTML/XML和用于演示的Java以及CORBA技術(shù)以允許位于各現(xiàn)場的處理應(yīng)用服務(wù)器彼此間通信。這種網(wǎng)絡(luò)中心(netcentric)技術(shù)允許遠(yuǎn)程分支以有限的電信帶寬訪問并啟動交易信息。另外，集線器現(xiàn)場處理時可用UNIX或PC/NT服務(wù)器采用C++編程語言和關(guān)系型數(shù)據(jù)庫(例如Sysbase、Oracle或其他類似的關(guān)系型數(shù)據(jù)庫技術(shù))在集線器現(xiàn)場的客戶機(jī)工作站上進(jìn)行交易處理和Visual Basic以及Visual C++處理。作為替代，F(xiàn)inancial System175可采用諸如IBM系統(tǒng)390這種傳統(tǒng)主機(jī)計算機(jī)系統(tǒng)來實施。各個實施例中，作為部分Financial System 175運作的軟件包括定制軟件，專用于實現(xiàn)在此說明的功能。在銀行環(huán)境中，金融系統(tǒng)175可包括諸如紐約和倫敦那樣的一個位于中心位置的設(shè)施或多個在地理區(qū)域內(nèi)分布的設(shè)施。
TradeDOC 100、TradeEDI 125及Trade Manager 150可由在一個或多個主機(jī)系統(tǒng)或一個或多個服務(wù)器系統(tǒng)上執(zhí)行的軟件所構(gòu)成。主機(jī)系統(tǒng)是上面就FinancialSystem 175說明的主機(jī)系統(tǒng)。本發(fā)明一實施例中，TradeDOC 100、TradeEDI 125及Trade Manager 150運作于與Financial System 175相同的主機(jī)系統(tǒng)。本發(fā)明一較佳實施例中，TradeDOC 100、TradeEDI 125及Trade Manager 150采用上面對于Financial System 175所說明的相同的網(wǎng)絡(luò)中心技術(shù)，諸如SUN Javasoft或Netscape Web Server，Java服務(wù)器程序(servlets)，HTML/XML和用于演示的Java以及CORBA技術(shù)，以便遠(yuǎn)程站點應(yīng)用服務(wù)器彼此間通信。應(yīng)用服務(wù)器采用可以商業(yè)銷售方式提供的帶CORBA的網(wǎng)絡(luò)中心技術(shù)(例如Weblogics和Websphere)。TradeEDI采用可以商業(yè)銷售方式提供的EDI翻譯器(例如Harbinger的OpenEDI、Gentran等)。用Trade XML消息以有利于Financial System 175與Trade Manager 150、TradeDOC100及TradeEDI 125之間的消息通信。各個實施例中，Trade Manager 150、TradeEDI及TradeDOC 100包括在此說明的用上述可以商業(yè)銷售方式提供的軟件編程的定制軟件。
一實施例中，F(xiàn)inancial System 175、Trade Manager 150及TradeDOC 100如圖1所示借助于公司內(nèi)部網(wǎng)(intranet)彼此間通信。Financial System 175、TradeManager 150及TradeDOC 100間的通信涉及敏感的金融信息，所以公司內(nèi)部網(wǎng)連接中的通信渠道必須提供一相應(yīng)的安全級。如圖1中進(jìn)一步所示，銷售商120和采購商130兩者各自經(jīng)TradeEDI 125與Trade Manager 150和TradeDOC 100通信。一較佳實施例中，銷售商120或采購商130與Trade Manager 150及TradeDOC 100之間的通信媒體是公用互聯(lián)網(wǎng)。該實施例中，銷售商120和采購商130各自能夠用諸如NetscapeTMNavigatorTM或MicrosoftTMExplorerTM這種標(biāo)準(zhǔn)互聯(lián)網(wǎng)瀏覽器與本發(fā)明系統(tǒng)通信，TradeEDI 125則提供保密金融通信所需的相應(yīng)加密、認(rèn)證及非否認(rèn)手段。作為替代，銷售商120和采購商130可用租用線路、第三方網(wǎng)絡(luò)或撥號線路，再加上用TradeEDI 125作為保密通信的界面與Trade Manager 150或TradeDOC 100連接。
銷售商120和采購商130所用的工作站最好是任何互聯(lián)網(wǎng)就緒設(shè)備(例如具有互聯(lián)網(wǎng)能力的個人計算機(jī)(PC)、蜂窩區(qū)電話或諸如3Com Palm V或VII這種互聯(lián)網(wǎng)就緒個人數(shù)字助理(PDA)(手持設(shè)備))。作為替代，銷售商120和采購商130的工作站可以是由銷售商120和采購商130或為銷售商120和采購商130運作的服務(wù)器系統(tǒng)或主機(jī)系統(tǒng)其中一部分。將會認(rèn)識到，采購商和銷售商以及其他供應(yīng)鏈當(dāng)事方的工作站將對與所出現(xiàn)的諸如虛擬市場(例如Intelysis、MySAP、SAPHIRE及TradeMatrix)這種e-commerce(電子商務(wù))技術(shù)相關(guān)聯(lián)的進(jìn)程貢獻(xiàn)另外的功能。如下面將進(jìn)一步說明的那樣，銷售商120和采購商130工作站較好是與銷售商120和采購商130的一個或多個各總體底帳、行政管理、會計及制造系統(tǒng)通信。
銷售商120及采購商130一側(cè)和Trade Manager 150及TradeDOC 100另一側(cè)之間的通信包括金融以及其他財產(chǎn)信息，所以TradeEDI 125用相應(yīng)的安全機(jī)制來保護(hù)這些通信。直接撥號及私人網(wǎng)絡(luò)實施例中，靠這種連接的私人屬性增強安全。但公用互聯(lián)網(wǎng)實施例中則必須采取特別的安全預(yù)防措施。這些安全措施包括例如認(rèn)證、加密以及非否認(rèn)手段。認(rèn)證中，用Certifying Authority(證明機(jī)構(gòu))軟件來認(rèn)證電子信息通信是在沒有干預(yù)的情況下由真正的當(dāng)事方發(fā)送或從真正的當(dāng)事方接收的，并進(jìn)一步確保通信無法被否認(rèn)。此外，對全部通信加密以防止未得到授權(quán)者獲取通信中所包含的數(shù)據(jù)。一實施例中，利用公共密鑰技術(shù)用于加密、認(rèn)證及非否認(rèn)手段。如本領(lǐng)域技術(shù)人員所理解的那樣，認(rèn)證、加密及非否認(rèn)系統(tǒng)按照相應(yīng)的ANSI和ISO標(biāo)準(zhǔn)及準(zhǔn)則運作。
圖2更為詳細(xì)地示出本發(fā)明部件及處理。對于該處理必需有三個階段始發(fā)、跟蹤及付款。圖2示出采購商為運作該系統(tǒng)的金融機(jī)構(gòu)的客戶時的始發(fā)階段。第一階段中，采購商130的L/C申請和/或PO由Financial System 175接收并處理。第二階段中，商品經(jīng)過制造、提取或采辦以及裝運，該處理過程所需的全部單證如圖3A和圖3B進(jìn)一步所說明的由TradeDOC 100生成。最后階段則根據(jù)L/C或公開帳戶進(jìn)行付款和征收。全部階段中每一行為由交易中所涉及各方均可訪問的Trade Manager 150跟蹤(如下面所提及的那樣，Trade Manager 150的某些信息僅可由基于當(dāng)事方之間協(xié)議的某些當(dāng)事方獲得)。
如圖2所示，該處理過程由其本身將PO或者將PO或L/C申請發(fā)送給銀行的采購商130始發(fā)。一較佳實施例中，經(jīng)互聯(lián)網(wǎng)或其他電子通信手段以電子形式從采購商130接收單證。作為替代，可以紙件形式接收單證，并由銀行職員以人工方式鍵入或掃描進(jìn)來。圖2所示的本發(fā)明一實施例中，從采購商130接收到的PO由FinancialSystem 175存儲(存棧)于數(shù)據(jù)倉棧215中以便接下來按客戶商業(yè)規(guī)則歸入一個或多個L/C。這對于不想開發(fā)或購買一L/C系統(tǒng)來跟蹤監(jiān)視其L/C和相關(guān)聯(lián)PO的采購商130來說，是一項吸引人的業(yè)務(wù)。如上所述，某些貿(mào)易交易不需要L/C，在這些交易中采購商130僅發(fā)送PO，由它始發(fā)Financial System 175中一公開帳戶事務(wù)。
當(dāng)從采購商130接收到電子文檔時，TradeEDI 125(圖2中未圖示)便翻譯進(jìn)來的數(shù)據(jù)，并利用數(shù)據(jù)庫205中包含的客戶檔案將數(shù)據(jù)映射至Financial System 175。對L/C事務(wù)和公開帳戶事務(wù)兩者執(zhí)行翻譯和映射。若采購商130請求了銀行根據(jù)該PO創(chuàng)建一L/C，便由自動L/C模塊225自動生成該L/C。自動L/C用采購商130的PO信息和數(shù)據(jù)庫205中包含的對采購商130預(yù)先建立的客戶檔案。采購商130的檔案包含采購商130所用的標(biāo)準(zhǔn)L/C模板，其中包括用于該貿(mào)易交易中所涉及的特定銷售商100的標(biāo)準(zhǔn)L/C文本和條款及條件。自動L/C225生成的L/C根據(jù)PO信息以及采購商檔案定制。舉例來說，若PO顯示一特定銷售商120，采購商130和銷售商120便可具有反映在采購商檔案中的一套達(dá)成一致的條款和條件。對于不同的銷售商120，條款和條件可以不同，這些差異反映在對涉及該銷售商120的交易所用的不同的標(biāo)準(zhǔn)模板。各個模板存儲于數(shù)據(jù)庫205中的采購商檔案。此外，不同條款和條件依據(jù)PO中所包含的商品、數(shù)量、交貨日期……生成。
Financial System 175用客戶檔案數(shù)據(jù)庫205中采購商130檔案中所包含的受益方(例如銷售商)和其他當(dāng)事方的預(yù)先創(chuàng)建的條款和條件來提供數(shù)據(jù)的確認(rèn)。來自客戶檔案205的數(shù)據(jù)和Financial System 175所需的數(shù)據(jù)與從采購商130進(jìn)來的數(shù)據(jù)相比較以確保完整和符合所要求的UCP碼。若沒有矛盾，F(xiàn)inancial System 175就針對采購商130自動執(zhí)行信用檢查，并在Auto Release(自動發(fā)布)處理230(也稱為直通車處理)中創(chuàng)建L/C。該處理過程不需要人工處理。若發(fā)現(xiàn)采購商130的數(shù)據(jù)和客戶持續(xù)有效的檔案205之間有矛盾，F(xiàn)inancial System 175便將該事務(wù)送至Repair(修正單元)210以便與采購商130一起進(jìn)行人工查看和可能的修正或澄清。Financial System 175使這種矛盾突出顯示以方便查看過程。
一旦消除了這種矛盾，或沒有矛盾的話，Auto Release230便更新TradeManager 150中各個數(shù)據(jù)庫，若銷售商120是一客戶或銀行貿(mào)易伙伴的一客戶，即采購商130的全球供應(yīng)鏈網(wǎng)絡(luò)其中一部分，信息將送至TradeDOC 100來反映所頒發(fā)的L/C狀態(tài)。Trade Manager 150通知銷售商120(或其顧問銀行或其他代理機(jī)構(gòu))頒發(fā)L/C，銷售商120因此可著手其制造/提取、采辦及裝運運作。
如上所述，所謂Open Account事務(wù)這類某些事務(wù)不需要L/C和PO，單獨形成該事務(wù)的初始單證。這種情形下，PO首先被驗證有效(對于上面所述的一致完整的信息而言)，接著由Financial System 175映射至其本身的內(nèi)部數(shù)據(jù)庫用于FinancialSystem 175跟蹤用途。一旦完成這種驗證和映射，PO信息便發(fā)送至Trade Manager150和TradeDOC 100以便被那些模塊的數(shù)據(jù)庫所包含。Trade Manager 150接著通知銷售商120(或其代理機(jī)構(gòu))L/C的頒發(fā)和收到，銷售商120因此可著手其制造/提取、采辦及裝運運作。
本發(fā)明一替代實施例中，采購商130可用一不同的銀行來頒發(fā)L/C。該實施例中，采購商130可與其全部銀行服務(wù)提供商訂立協(xié)議以便用TradeEDI 125、TradeManager 150和TradeDOC 100服務(wù)于其所有貿(mào)易運作。本實施例中本發(fā)明系統(tǒng)的運作方是作為一外包承包商運作的，并不象頒證銀行或顧問銀行那樣具有責(zé)任。該實施例中，采購商130還會用TradeEDI 125、Trade Manager 150和TradeDOC 100與其賣主訂立同樣協(xié)議。這允許采購商在一個地方擁有全部采購及付款信息，以便可以更高效率管理其全球供應(yīng)鏈。采購商130通過Trade Manager 150或TradeEDI 125創(chuàng)建一電子L/C申請，并且選擇其指定的頒證銀行。L/C申請和PO信息用采購商客戶檔案驗證有效并映射至Financial System 175中。該完成的L/C事務(wù)送至Trade Manager150以允許頒證銀行查看并準(zhǔn)予該事務(wù)。L/C數(shù)據(jù)以及條款和條件可由頒證銀行下載利用與其內(nèi)部金融系統(tǒng)的界面。準(zhǔn)予處理過程可以是單級或多級準(zhǔn)予。核準(zhǔn)人的數(shù)目也可取決于L/C的美元數(shù)量。一旦該指定的頒證銀行準(zhǔn)予Trade Manager 150上的事務(wù)，便由指定銀行發(fā)布L/C并將L/C頒發(fā)給顧問銀行或銷售商100。若涉及有顧問銀行，L/C將由Financial System 175通過SWIFT、Telex或郵件送至指定的顧問銀行。所頒發(fā)的L/C信息可從Trade Manager 150下載，或由TradeEDI 125送至指定的頒證銀行以更新它們的內(nèi)部金融系統(tǒng)。使得L/C信息僅對于L/C頒證銀行和采購商130可資利用。若頒證銀行和采購商130與銷售商100和其他相關(guān)貿(mào)易伙伴有協(xié)議，TradeManager 150上的L/C信息也可由這些當(dāng)事方訪問。L/C及PO信息發(fā)送至TradeDOC 100用于準(zhǔn)備貿(mào)易單證，也可輔助銷售商100管理其L/C。
不論所運作的單證是PO還是PO和/或L/C，這些單證的全部信息被包括在TradeManager 150的數(shù)據(jù)庫中。Trade Manager 150中最為有意義的部分是允許數(shù)據(jù)輸入、修改、查詢和查看的數(shù)據(jù)庫(關(guān)系型、面向?qū)ο笮突騼烧叩慕M合)、商業(yè)規(guī)則以及客戶檔案。較佳實施例中，基于L/C的每一記錄包含關(guān)于以下字段的數(shù)據(jù)L/C號、PO號、受益方名稱(例如銷售商120)、受益方地址、受益方國家、裝運方名稱(可選)、裝運方地址(可選)、商品描述(可選)、項目號或樣式號(可選)、顏色(可選)、尺寸(可選)、裝運期限(可選)、裝貨港(可選)、裝貨港國家(可選)、目的地港(可選)、目的地港國家(可選)、最早裝運日期(可選)、最遲裝運日期、運輸方式(可選)、數(shù)量、數(shù)量計量單位、幣種、單價、單價計量單位(若不同于數(shù)量計量單位則可選)、總數(shù)量、采購商130的SKU號(可選)、銷售商120的SKU號(可選)、制造商的SKU號(可選)、部門號(可選)、匯票期限種類(可選)、匯票期限日(可選)、匯票期限碼(可選)以及狀態(tài)。上述清單并未窮盡，與上述數(shù)據(jù)字段任意種類數(shù)相比，本發(fā)明的特定實施方案可或多或少地采用。此外，較佳數(shù)據(jù)庫的主要索引是L/C，但其他實施方案所具有的記錄可基于PO。
雖然上述討論針對的是來自采購商130的單個PO，實際上若干個PO(每一PO含多項)可被單個L/C所涵蓋，或被視為Open Account貿(mào)易交易中的一部分。TradeManager 150向客戶檔案提供其相關(guān)聯(lián)賣主檔案和客戶商業(yè)規(guī)則以便在L/C和L/C所涵蓋的PO之間相關(guān)。銀行通常想以L/C為著眼點跟蹤貿(mào)易運作狀態(tài)(因為L/C是有作用的金融單證)，但采購商130和銷售商120更為關(guān)注PO狀態(tài)及其費用款項，因為這些款項代表商品。為了適應(yīng)各方的需要，Trade Manager 150提供對數(shù)據(jù)庫的不同視圖。一較佳實施例中，由受益方(銷售商120)按L/C或PO提供種種視圖。另外，采購商還可以就商品目錄在L/C上加上比PO中所含的更具有說明性的信息來保護(hù)自己(例如纖維含量、項目種類(即玩具類)等)。
響應(yīng)用戶(例如采購商130)的查詢，Trade Manager 150數(shù)據(jù)庫記錄以表格形式向用戶顯示。舉例來說，若采購商130對Trade Manager 150數(shù)據(jù)庫查詢涉及受益方公司XYZ(即銷售商120)的全部交易。Trade Manager 150所生成的報表就每一項與公司XYZ的交易列出PO號、L/C號、商品數(shù)量、單價、總計PO數(shù)量以及當(dāng)前狀態(tài)?？衫斫釺rade Manager 150所能顯示的信息可以為個別用戶定制。舉例來說，一特定采購商130可能對所提議的交貨日期的關(guān)注甚于對單價的關(guān)注?？珊苋菀椎貙⑦@些交貨日期結(jié)合進(jìn)給該采購商130的報告當(dāng)中。如上所述，較佳實施例中，同樣的報表視圖可用于按L/C和/或PO分類。
在集成TradeDOC 100和Trade Manager 150方面，采購商120的信息可為采購商130所利用。若采購商130和銷售商120同意，諸如制造商狀態(tài)信息、裝運狀態(tài)信息等這類信息可為采購商130用來監(jiān)視跟蹤。這將允許采購商130對商品的庫存及分銷進(jìn)行管理或在情況變化時可能重新組織裝運。
Trade Manager 150其中一主要任務(wù)是在相應(yīng)L/C存續(xù)期間跟蹤PO的歷史。若PO或L/C因修正或付款而被更新，所記錄的數(shù)值并非被覆蓋，而是Trade Manager 150創(chuàng)建修正或付款記錄，該記錄接著鏈接回到數(shù)據(jù)庫的PO和/或L/C記錄。用戶查看Trade Manager 150數(shù)據(jù)庫的數(shù)據(jù)時，得到一對所選定記錄變焦仔細(xì)查看的選擇權(quán)。用戶變焦仔細(xì)查看時，Trade Manager 150便顯示記錄細(xì)節(jié)以及歷史(即全部的修正和付款)。一較佳實施例中，歷史部分顯示的是數(shù)量和總量兩者的動態(tài)平衡。
Trade Manager 150允許得到相應(yīng)授權(quán)的用戶輸出文檔。所支持的標(biāo)準(zhǔn)格式諸如是ASCII、ExcelTM和LotusTM文檔?？衫蒙厦嫠龅娜魏问侄沃T如通過互聯(lián)網(wǎng)或其他私人電子數(shù)據(jù)交換(EDI)來發(fā)生輸出。用戶可從全部可資利用的數(shù)據(jù)單元當(dāng)中選擇并規(guī)定其要輸出的各個數(shù)據(jù)單元。另外，用戶還可規(guī)定另外的選擇標(biāo)準(zhǔn)，諸如數(shù)據(jù)范圍、平衡數(shù)量或受益方。與L/C或PO事務(wù)相關(guān)聯(lián)的貿(mào)易單證、打印文檔及電子消息可用來由銷售商120、采購商130及其他貿(mào)易伙伴查看。此外，Trade Manager 150還支持將信息按進(jìn)度下載給用戶。該特征對于其所維持的互聯(lián)網(wǎng)系統(tǒng)需要用TradeManager 150可提供的信息進(jìn)行更新的采購商130和銷售商120來說是很吸引人的。Trade Manager 150還為其用戶提供檔案服務(wù)。通常用戶要到記錄中所體現(xiàn)的貿(mào)易交易已經(jīng)完成(例如到期、取消或完全收回)才希望某些記錄存檔。
如上面簡要說明的那樣，Trade Manager 150提供若干安全機(jī)制來確保系統(tǒng)與其用戶之間的保密通信。這些安全機(jī)制包括加密、認(rèn)證以及非否認(rèn)。此外，還向每一用戶提供一包括用戶授權(quán)訪問的數(shù)據(jù)在內(nèi)的檔案。很自然，Trade Manager 150阻止特定客戶查看另一客戶的貿(mào)易交易。Trade Manager 150還提供一客戶可在其中指定其的哪些雇員可查看特定數(shù)據(jù)的訪問安全級。舉例來說，出口商(銷售商120)可指定其制造雇員可以查看PO數(shù)據(jù)而非與貿(mào)易交易相關(guān)聯(lián)的L/C金融數(shù)據(jù)。較佳實施例中，全部用戶(而非銀行職員)對于Trade Manager 150中所存儲數(shù)據(jù)只有讀出權(quán)限。這種安全特征確保沒有人能夠有意、更可能是無意地改動數(shù)據(jù)庫中所包含的數(shù)據(jù)。若用戶發(fā)現(xiàn)數(shù)據(jù)庫中出錯或其他矛盾，便通知銀行操作員，其具有能力修改該數(shù)據(jù)以便改正該錯誤。
如上所述，本發(fā)明較佳實施例中，用戶用標(biāo)準(zhǔn)瀏覽器和互聯(lián)網(wǎng)訪問TradeManager 150。本發(fā)明有意義方面以及優(yōu)點其中之一是分布在地理范圍的交易各方通過利用互聯(lián)網(wǎng)可分別登錄到Trade Manager 150，并即時確定特定交易狀態(tài)。這相對于確定交易狀態(tài)通常包含跨若干時區(qū)的若干通電話或傳真是一革命性量變。
隨著Trade Manager 150數(shù)據(jù)庫人口的增長，TradeDOC 100的類似數(shù)據(jù)庫其人口也隨交易數(shù)據(jù)增長。較佳實施例中，F(xiàn)inancial System 175、Trade Manager 150及TradeDOC 100各自保存它們自己的獨立數(shù)據(jù)庫。采取這種實施方案，其中一個技術(shù)原因是，某一系統(tǒng)對數(shù)據(jù)庫的加載不影響其他系統(tǒng)使用該數(shù)據(jù)庫，因而性能可隨獨立數(shù)據(jù)庫增強。保存獨立數(shù)據(jù)庫的一個要求是各個數(shù)據(jù)庫中的數(shù)據(jù)必須同步。保存獨立數(shù)據(jù)庫的另一原因是，F(xiàn)inancial System 175、Trade Manager 150及TradeDOC100各自可分開獨立運作。舉例來說，某些銷售商100可能想僅用TradeDOC 100來管理它們自己的內(nèi)部處理流程而不需要Financial System 175或Trade Manager 150所提供的任何功能。本實施例中，可建立僅集成TradeDOC 100及其獨立數(shù)據(jù)庫的設(shè)施用于這種銷售商100。一替代實施例中，可對Financial System 175、TradeManager 150及TradeDOC 100提供單個共用數(shù)據(jù)庫。該實施例中，不需要數(shù)據(jù)同步，但如上所述可能有性能影響。不過在小規(guī)模站點，全部這些數(shù)據(jù)庫可組合為單個數(shù)據(jù)庫。
如上面簡要說明的，TradeDOC 100是從通知銷售商120有關(guān)L/C和/或PO時起到征收所交貨商品款項時這段時間貿(mào)易處理流程的管理工具。如上所述，某些銷售商120可能與銀行達(dá)成協(xié)議，在銀行并不具有成為頒證銀行或顧問銀行能力的情況下用TradeDOC 100來生成貿(mào)易單證。這是很可能的，因為TradeDOC 100通常由銀行的單證制作組運作，該組與管理Financial System 175的L/C部門是分開的。此外，采購商130還可在其與銷售商120的協(xié)議中委托銷售商120用TradeDOC 100管理其單證處理流程。對于那些作為直接來自采購商130或采購商130的頒證銀行或銷售商120的顧問銀行的L/C或PO的受理方的銷售商120來說，TradeDOC 100可具有與Trade Manager150相同的信息。該實施例中，用直接從銷售商120或從顧問銀行或頒證銀行所提供的L/C和/或PO信息更新TradeDOC 100和Trade Manager 150兩者。這包括任何修正和付款信息。
圖2所示較佳實施例中，TradeDOC 100由金融機(jī)構(gòu)代表其客戶即銷售商120運作，但若交易中的銷售商120愿意，就可將對TradeDOC 100系統(tǒng)的訪問授權(quán)給其他許可的用戶(例如采購商130)。某些銷售商120會不想讓采購商監(jiān)視銷售商處理流程中的內(nèi)部狀態(tài)，而某些采購商則會堅持這種監(jiān)視能力。下面是結(jié)合圖3對TradeDOC100運作的全面說明，但如圖2通常所示，TradeDOC 100生成貿(mào)易交易所需的全部單證，并與諸如運輸商、經(jīng)紀(jì)人、海關(guān)等政府機(jī)構(gòu)、裝運商250、保險提供商260以及供應(yīng)鏈各方這種第三方互動，以便確保此處理流程順暢，不因不正確或不充分單證而擔(dān)擱。
圖3A和圖3B示出對銷售商120完成貿(mào)易運作所需單證的生成處理流程進(jìn)行輔助管理的TradeDOC 100運作。如上述附圖中進(jìn)一步所示，TradeDOC 100還通過確保商品按照L/C和/或PO制造在其內(nèi)部制造流程輔助銷售商120。說明TradeDOC 100處理流程之前，先對TradeDOC 100所用數(shù)據(jù)庫進(jìn)行簡要說明。TradeDOC 100中的數(shù)據(jù)庫與Trade Manager 150中所保存的數(shù)據(jù)庫相同。TradeDOC 100中每一記錄較好是包含下列字段頒證銀行L/C號、顧問銀行L/C號、頒證銀行名稱及地址、顧問銀行名稱及地址、受益方名稱及地址、L/C貨幣幣種、L/C數(shù)量、L/C頒證日期、L/C屆滿日期、L/C匯票期限、最近裝運日期、商品庫存、轉(zhuǎn)運允許指示符、分運允許指示符、特別指令、賠償指令以及修改次數(shù)。由此可見，TradeDOC 100的某些字段與TradeManager 150數(shù)據(jù)庫中的相同(例如L/C號)，而其他(例如轉(zhuǎn)運允許指示符)只是TradeDOC 100生成單證所要求的，因而未被Trade Manager 150跟蹤。
TradeDOC 100接收上面就貿(mào)易交易說明的字段數(shù)據(jù)，從而在TradeDOC 100數(shù)據(jù)庫中創(chuàng)建一L/C記錄。如下面就圖3A和圖3B將要說明的，TradeDOC 100可根據(jù)L/C條款創(chuàng)建一所需單證清單。TradeDOC 100將L/C條款和條件分析拆解為各屬性以及處理規(guī)則，以便使對于單證要求的判定處理更為自動。除了每一交易的L/C記錄，TradeDOC 100可(基于客戶的標(biāo)準(zhǔn)指令)根據(jù)L/C或PO中包含的“商品庫存”數(shù)據(jù)創(chuàng)建一個或多個“銷售單”記錄(注意一個L/C或PO可有超過一個的“銷售單”與其相關(guān)聯(lián))。如下面更為全面的說明，TradeDOC 100允許基于其自己的銷售單而非采購商130所發(fā)出的PO或L/C對交易保持跟蹤。若數(shù)據(jù)源自采購商130、或采購商頒證銀行或顧問銀行，以待定狀態(tài)建立一銷售單記錄，因為TradeDOC 100需要受益方(銷售商120)提供銷售單記錄細(xì)節(jié)(例如“銷售單號”這種記錄細(xì)節(jié))。若數(shù)據(jù)直接源自銷售商120，便輸入數(shù)據(jù)，并將銷售單記錄狀態(tài)設(shè)定為“銷售單經(jīng)過確認(rèn)”。
反映商業(yè)貿(mào)易性質(zhì)時，偶爾會發(fā)生對L/C或PO的修改，因而TradeDOC 100能夠處理這種修改。對L/C或PO的修改以電子或硬拷貝形式來自采購商130或顧問銀行。最好，如對初始通知的L/C或PO所說明的，對L/C或PO的修改包含全部字段數(shù)據(jù)。經(jīng)過修改的L/C或PO中，數(shù)據(jù)反映的是經(jīng)過修改的條款。一旦收到該修改的L/C或PO，TradeDOC 100根據(jù)下列核對標(biāo)準(zhǔn)頒證銀行L/C號、顧問銀行L/C號以及L/C狀態(tài)并非“撤消”，從TradeDOC 100數(shù)據(jù)庫當(dāng)中檢索初始的L/C或PO記錄。若未發(fā)現(xiàn)所核對的記錄，或發(fā)現(xiàn)記錄但對經(jīng)過核對的L/C檢測的是錯誤記錄，交易便帶有一例外報告標(biāo)志，L/C的修改處理流程便被終止。若L/C的狀態(tài)是“已經(jīng)屆滿”或“預(yù)定結(jié)束”而且所提議的經(jīng)修改L/C中的“屆滿日期”比處理日期還早的話，交易便帶有一例外報告標(biāo)志，并使修改流程終止有待TradeDOC 100操作員的人工修改。
對一經(jīng)修改L/C或PO處理過程中，TradeDOC 100提供下列驗證不應(yīng)存在一新增加的銷售單；必須存在一被刪除或被修改的銷售單；以及每一經(jīng)修改銷售單相對于其全部相關(guān)“發(fā)票”(若存在)加以驗證來檢查余下抵消值。若上述驗證失敗，TradeDOC 100可顯示一警告消息并進(jìn)行處理流程，或顯示一出錯消息，并終止處理流程有待于人工修改。與初始的L/C同樣，若所提供的數(shù)據(jù)不完整，必須以人工方式修改。
一旦經(jīng)修改的L/C得到驗證，便基于該修改更新L/C記錄。此外，還根據(jù)需要基于所修改的L/C條款更新此清單或所需單證(根據(jù)L/C和/或PO生成)。這可能意味向該清單加新單證，從清單當(dāng)中刪除老單證和/或修改該清單上任何現(xiàn)存單證所需份數(shù)。最后，若修改了L/C的商品庫存便更新銷售單記錄。這可能意味增加新銷售單、刪除老銷售單和/或修改任何現(xiàn)存銷售單的各個要素。若經(jīng)修改L/C的數(shù)據(jù)來自銷售商120以外的其他任何人，必須由銷售商120確認(rèn)任何新的或經(jīng)修改的銷售單。與修改同樣，TradeDOC 100能夠處理所刪除的L/C。必須注意，TradeDOC 100僅修改依據(jù)L/C和PO生成的貿(mào)易單證或經(jīng)修改的L/C和/或經(jīng)修改的PO，但不修改PO或L/C本身。
回到圖3A和圖3B，上述圖示出TradeDOC 100所執(zhí)行的處理流程以及TradeDOC100與其他系統(tǒng)互動這兩者。上述圖中示出的該流程的起點是，L/C和/或PO的條款達(dá)成一致并歸入TradeDOC 100及Trade Manager 150數(shù)據(jù)庫，目前銷售商120的義務(wù)是根據(jù)各方之間達(dá)成的協(xié)議制造和交貨。以電子方式通過Trade Manager 150或TradeEDI 125通知銷售商100 L/C或PO。
如上面對TradeDOC 100數(shù)據(jù)庫所述，銷售商120據(jù)此制造其商品的有效運作單證是一稱為銷售單的內(nèi)部單證。盡管未在圖中專門示出，TradeDOC 100能夠根據(jù)L/C和/或PO生成銷售商120的銷售單。作為替代，銷售商120可自己生成銷售單。如圖3所示，TradeDOC 100與Trade Manager 150通信以便如在Trade Manager 150中所報導(dǎo)的那樣保持當(dāng)前的交易狀態(tài)。如下面所述隨著處理過程中達(dá)到里程碑，TradeDOC100提供給Trade Manager 150一更新狀態(tài)。如上所述，若銷售商120和采購商130同意，該狀態(tài)便可供銷售商120和采購商130利用。
一旦銷售商120本身或TradeDOC 100生成了銷售單，TradeDOC 100便在步驟300將銷售單細(xì)節(jié)與L/C和/或PO細(xì)節(jié)相比較。該比較是要驗證銷售商120的銷售單與L/C和/或PO的全部要求相符合。舉例來說，L/C會需要制造交貨1,000單位，而銷售商120可能錯誤地生成規(guī)定10,000單元的銷售單。步驟300的檢查將確保在銷售商120在任何未來可能極高代價的行為之前揪住并改正這種錯誤。
步驟305示出TradeDOC 100所提供的可選功能。實際上，銷售商120可處于提供融資即“供方信用”給采購商的地位。若為這種情形，銷售商對該特定采購商130在預(yù)置的信用限度下檢查信用可資利用度。金融機(jī)構(gòu)對采購商130信用可資利用度執(zhí)行實際的監(jiān)視，TradeDOC通過提供交易條款來輔助金融機(jī)構(gòu)作出此判斷。步驟305中，銷售單用于判斷融資是否可提供。盡管未在圖3A中示出，通過銀行運作的TradeDOC100或通過第三方融資源120對融資作出判斷。所形成的融資判斷回報給銷售商120。
同時將銷售單提供給TradeDOC 100，銷售商120將相同銷售單提供給其制造部門122。制造分支122根據(jù)銷售單生成一其制造雇員將據(jù)此制造實際商品的制造說明單。銷售單本身并不能由制造雇員在其日常運作及規(guī)劃功能中利用。盡管圖3A規(guī)定制造部門122生成一制造說明單，但若已經(jīng)制造了商品并且進(jìn)入庫存(例如銷售商是分銷商而非制造商)，制造商部門122便可提供一表明將從庫存當(dāng)中提取的商品項目的庫存提取單以便滿足銷售單。
制造說明書送至TradeDOC 100將銷售單與制造說明單相比較。步驟310中這種比較檢測采購商130所要求商品的制造說明書(體現(xiàn)在PO或L/C中)和制造部門122計劃使得滿足采購商130的要求成為可能的商品說明書之間的任何差異。接著，將步驟300的比較用來找出銷售商120所用單證中的某些差錯。這種差錯可能造成錯誤類型或數(shù)目的商品，進(jìn)而造成銷售商120的利潤損失。舉例來說，若采購商130訂購了10,000藍(lán)色單元，而制造商122錯誤地制造10,000紅色單元，銷售商120首先必須返工制造最初要求的藍(lán)色單元，很可能造成裝運延誤，而且銷售商120還存在10,000紅色單元的積壓。
若TradeDOC 100檢測出制造說明單和銷售單之間矛盾，便通知銷售商的生產(chǎn)控制126。最好在進(jìn)行任何所需制造或取貨之前有核對步驟310。由于TradeDOC 100在步驟310執(zhí)行的比較實際上是一瞬間的，所以銷售商120只要確保在制造開始之前某一時刻生成制造說明單并發(fā)送至TradeDOC 100。步驟320中，銷售商的生產(chǎn)控制126對制造說明單進(jìn)行改正，并將經(jīng)改正的制造單送回至TradeDOC 100，對說明單進(jìn)行相對于銷售單的確認(rèn)比較。若刪除了相同或另外的差錯，便可在TradeDOC 100和銷售商120的生產(chǎn)控制126系統(tǒng)或職員之間進(jìn)行交互處理過程。一旦未檢測出矛盾，制造部門122用經(jīng)過驗證的制造說明單著手并逐漸完成商品制造。
完成步驟310的比較后，在步驟315中TradeDOC 100用經(jīng)過核對的銷售單來創(chuàng)建裝運指令(例如裝貨底單或空運單)。商品裝運的管理流程與商品制造流程并行。裝貨底單或空運單或其他裝運指令根據(jù)TradeDOC 100數(shù)據(jù)庫生成，該數(shù)據(jù)庫包括但不局限于下列關(guān)于裝運的數(shù)據(jù)申請人/采購商130的名稱、貨幣幣種、數(shù)量、匯票期限信息、實際裝運日期、商品庫存、商品描述及數(shù)量、采購訂單/合同號、名稱、第三方單證地址及電話號碼(若有的話，例如檢查證明，若可能，為合同方)、以及(若有的話)特定指令。本發(fā)明之前，銷售商120不得不以人工方式生成裝運指令，這又造成人為的或制度性差錯可能。
一旦步驟315中的自動處理流程生成了裝運指令單證，TradeDOC 100便如圖3B所示將裝運指令(例如提取單)發(fā)送給貨物運輸商(裝運商)250。而且，較佳實施例中，將互聯(lián)網(wǎng)用作裝運指令從TradeDOC 100發(fā)送至貨物運輸商250的通信媒介。響應(yīng)TradeDOC 100的裝運指令，裝運商250返回一裝貨底單(B/L)。B/L是運輸商品時裝運商250所用的商業(yè)單證。本發(fā)明一替代實施例中，TradeDOC 100可生成該B/L底單，它接著發(fā)送至裝運商250以請求準(zhǔn)許。盡管圖3B中未專門說明，但TradeDOC 100在步驟350中檢查裝運商250的B/L底單，來驗證其符合TradeDOC 100先前生成的裝運指令細(xì)節(jié)。
步驟350中，TradeDOC 100用步驟310(參照圖3A)的經(jīng)核對銷售單并根據(jù)銷售商120會計部門124(參照圖3A)的應(yīng)收帳款更新或發(fā)票底單自動生成發(fā)票。如圖3A所示，銷售商120的會計部門124僅在銷售商的制造部門122通知了會計部門124已經(jīng)完成商品制造以后才生成應(yīng)收帳款更新或發(fā)票底單。應(yīng)收帳款更新或發(fā)票底單反映的是制造部門122實際制造出的商品。TradeDOC 100驗證銷售商120的會計系統(tǒng)124的應(yīng)收帳款更新或發(fā)票底單是遵循步驟310所生成的經(jīng)核對銷售單。而且，TradeDOC100的驗證確保應(yīng)收帳款更新或發(fā)票底單當(dāng)中沒有人為的或制度性的差錯。若從會計系統(tǒng)124的單證當(dāng)中檢測出某些差錯，便以人工方式改正這些差錯。一旦TradeDOC100驗證會計部門124的數(shù)據(jù)正確，TradeDOC 100便生成構(gòu)成完成貿(mào)易交易所需單證其中一部分并用于創(chuàng)建其余單證這種實際發(fā)票。
TradeDOC 100在步驟355所用的步驟350中生成的發(fā)票自動生成一裝運保險指令。該裝運保險指令需要包含有關(guān)要求投保商品的相關(guān)信息。保險指令(最好經(jīng)互聯(lián)網(wǎng))送至保險提供商390。保險提供商390進(jìn)而生成所要裝運商品的裝運保險條款的證明單證并發(fā)送回TradeDOC 100。
步驟360中，完成貿(mào)易交易所需的全部最終出口單證由TradeDOC 100用TradeDOC100數(shù)據(jù)庫中的現(xiàn)存數(shù)據(jù)、步驟350的發(fā)票、貨運商250的最終B/L以及保險提供商390的保險單證自動生成。所生成的最終正式單證包括但不局限于例如發(fā)票、提取單、B/L、保險證明以及分析證明。某些情形，客戶會用獨立的證明經(jīng)紀(jì)人/代理人來證明所要裝運的商品，例如SGS。TradeDOC 100向他們提供發(fā)票/提取單當(dāng)中的商品清單，并在完成檢查后檢查機(jī)構(gòu)將提供經(jīng)證明的消息。這可利用電子消息或紙質(zhì)證明/戳印來進(jìn)行。
步驟375中，步驟360中生成的單證包括裝貨單和空運單在內(nèi)，可由TradeDOC100生成一應(yīng)收帳款保險申請。該申請送至一保險提供商390，它可以與提供裝運保險的保險提供商相同或不同。步驟365中，TradeDOC 100能夠?qū)⒆罱K單證送至需要提前知道這些單證的銷售商120的經(jīng)紀(jì)人和代理人。一個例子是一負(fù)責(zé)確保商品對海關(guān)暢通的當(dāng)?shù)卮砣?。步驟370中，TradeDOC 100生成對于銷售商120就生成全部正式文件所進(jìn)行服務(wù)的服務(wù)收費。一較佳實施例中，這些服務(wù)收費以電子形式在其中一個其工作站上出示給銷售商100。這種服務(wù)收費的出示包括一“付款”按鈕，銷售商120可點擊該按鈕，銷售商120的帳戶(例如一按需通知儲蓄帳戶)便自動按服務(wù)收費數(shù)量付帳。
某些地區(qū)如香港，當(dāng)?shù)卣笕魏芜M(jìn)出口都要向當(dāng)?shù)刭Q(mào)易部提交一申明。TradeDOC 100可利用TradeDOC 100數(shù)據(jù)庫中全部現(xiàn)成信息生成可提交給香港貿(mào)易部(最好經(jīng)電子通信手段)這樣一種出口申明。另外，出口到美國(U.S.)的紡織品需要一出口配額申請。一旦知道界面，TradeDOC 100便能利用與當(dāng)?shù)卣到y(tǒng)之間的電子界面，以便提交當(dāng)?shù)卣璧某隹趩巫C。紡織品進(jìn)口至U.S.需要U.S.的簽證。TradeDOC 100可自動生成所需單證，并利用與美國海關(guān)系統(tǒng)或與美國海關(guān)系統(tǒng)有界面的當(dāng)?shù)卣到y(tǒng)的界面。舉例來說，香港政府貿(mào)易部與美國海關(guān)系統(tǒng)具有聯(lián)系以有利于獲得所需的U.S.簽證。某些商品的出口，例如澳大利亞的奶制品需要澳大利亞政府機(jī)構(gòu)對該產(chǎn)品出具證明。TradeDOC 100能夠利用與合適的政府機(jī)構(gòu)的界面獲得該電子證明。日用品出口商通常需要提供分析證明以確定產(chǎn)品即鋁的質(zhì)量/純度。而且TradeDOC 100可利用與出口商或第三方證明人的界面來獲得分析證明。
本處理流程的最終步驟是全部最終出口單證送至頒證銀行來啟動征收處理流程。征收處理流程中，最終單證必須出具給一開放帳戶交易下的采購商130或出具給L/C交易下的采購商130的銀行(頒證銀行)。本發(fā)明的一個顯著優(yōu)點是，因為全部最終單證都是電子形式的，單證可(用上面所述的公司內(nèi)部網(wǎng))在最靠近采購商130或采購商130的銀行的銀行地點打印。該遠(yuǎn)程打印能力很明顯地減少出具征收文件所需時間，并且總體上消除單證丟失或其他失誤的任何可能。這另外還縮短征收所花時間。若海關(guān)和銀行成為網(wǎng)絡(luò)的一部分，該單證可在Web站點郵寄供L/C或訂購協(xié)議上規(guī)定的合適的各方檢索。
圖4示出開放帳戶或L/C交易的征收處理流程。本發(fā)明輔助采購商130管理其應(yīng)付款帳戶，并輔助銷售商管理其收款帳戶。系統(tǒng)會代表采購商130將發(fā)票與PO核對，并提供一電子文檔等格式來更新采購商130的內(nèi)部帳戶及記錄保持系統(tǒng)。系統(tǒng)會代表銷售商120將進(jìn)項的采購商130付款與未結(jié)算發(fā)票核對，并提供一電子文檔等形式來更新銷售商120的內(nèi)部會計及記錄保持系統(tǒng)。
如圖4所示，TradeDOC 100以電子方式將全部最終貿(mào)易單證發(fā)送給FinancialSystem 175用于公開帳戶或L/C上的付款處理。Financial System 175再一次在步驟420驗證檢查貿(mào)易單證以確保單證與L/C或PO之間沒有矛盾。若運作FinancialSystem 175的銀行并非是頒證銀行，便將貿(mào)易單證以電子方式或打印形式送至頒證銀行(未圖示)，該頒證銀行進(jìn)而通知采購商130付款到期。若運作FinancialSystem 175的銀行是頒證銀行或為采購商130保存公開帳戶，F(xiàn)inancial System 175便通知銀行的付款系統(tǒng)450收到最終貿(mào)易單證。付款系統(tǒng)450進(jìn)而將L/C付款的債務(wù)建議送至Trade Manager 150，它將付款建議送至采購商130。如圖4中替代示出的，銷售商120可自己告知采購商130在一公開帳戶上付款的請求。
與告知付款相并行，若采購商130請求，F(xiàn)inancial System 175便能夠代表采購商130執(zhí)行一對帳功能。Financial System 175模塊所執(zhí)行的對帳功能將貿(mào)易單證下的付款與(公開帳戶交易下的)未結(jié)算L/C或PO核對。因為L/C可能包含多項PO，PO和L/C兩者可能指多項發(fā)票，所以這并非是微不足道的任務(wù)。對帳處理流程所生成的文檔送至采購商130的會計系統(tǒng)以便完成/更新其帳戶應(yīng)付款記錄。
若銀行是頒證銀行或持有公開帳戶，采購商130便向Trade Manager 150提供一付款授權(quán)。響應(yīng)該付款授權(quán)，付款系統(tǒng)450便從采購商130的帳戶(例如DDA)扣款，并將付款送至銷售商120或其銀行400。再如上面所述，對于向銷售商120收取的服務(wù)收費，當(dāng)Trade Manager 150告知采購商130付款時，Trade Manager 150可集成一“付款”按鈕便于得到向銷售商120付款的授權(quán)。
若銷售商120是銀行客戶，一旦由頒證銀行或還款銀行付款，便將付款經(jīng)Financial System 175授信給銷售商120的帳戶。付款系統(tǒng)450將付款細(xì)節(jié)連同已經(jīng)扣除的收費一起發(fā)送至TradeDOC 100。TradeDOC 100執(zhí)行用銷售商120的發(fā)票細(xì)節(jié)或費用款項細(xì)節(jié)來對付款進(jìn)行對帳的功能。TradeDOC 100所執(zhí)行的銷售商120的對帳功能與Financial System 175相反，因為該銷售商120的對帳是基于費用款項進(jìn)行的。銷售商120發(fā)票的費用款項細(xì)節(jié)最好是保存在TradeDOC 100數(shù)據(jù)庫中，而非Financial System 175數(shù)據(jù)庫中。作為替代，若全部具體對帳信息包含在FinancialSystem 175數(shù)據(jù)庫中Financial System 175便可執(zhí)行銷售商120的對帳。由于利用上面就采購商130所述的流程，TradeDOC 100便將應(yīng)收帳款以及費用的經(jīng)對帳信息發(fā)送至銷售商120的會計系統(tǒng)用于更新其應(yīng)收帳款記錄。如上所述，因為銷售商120的核心業(yè)務(wù)是制造和銷售商品，因而本發(fā)明提供的對帳功能是很理想的。
本發(fā)明的一個顯著優(yōu)點是，其可被打包并加上標(biāo)記(即白色標(biāo)記)，使得系統(tǒng)用戶不知道誰在實際運作該系統(tǒng)。舉例來說，該系統(tǒng)可實際由A銀行運作，但可將用戶界面屏幕設(shè)計使得用戶認(rèn)為此系統(tǒng)正由B銀行運作。按此方式，B銀行能夠以與公司形象一致的用戶界面對其客戶提供服務(wù)，而A銀行則享有從B銀行收到的運作該系統(tǒng)的收益。此外，本發(fā)明的各個方案可單獨許可和運作。舉例來說，某些銷售商120可能只想要TradeDOC 100提供的單證功能，而不需要Financial System 175、TradeManager 150或TradeEDI功能。
雖然是相對于其特定實施例對本發(fā)明加以說明的，但許多其他變形和用途對本領(lǐng)域技術(shù)人員來說將是很明顯的。因而希望，本發(fā)明并非由在此的具體說明限定，而只能由所揭示內(nèi)容的實質(zhì)和范圍來限定。
權(quán)利要求
1.一種與采購商和銷售商之間貿(mào)易運作相關(guān)聯(lián)單證的處理方法，其特征在于，包括下列步驟接收一包含關(guān)于該貿(mào)易運作需求信息的初始單證；至少將某些需求信息映射至數(shù)據(jù)庫；以及用數(shù)據(jù)庫中包含的需求信息自動生成貿(mào)易單證。
2.如權(quán)利要求1所述的方法，其特征在于，初始單證是采購商的采購訂單。
3.如權(quán)利要求1所述的方法，其特征在于，接收初始單證的步驟還包括以電子方式接收初始單證的步驟。
4.如權(quán)利要求1所述的方法，其特征在于，初始單證是采購商的信用證申請。
5.如權(quán)利要求4所述的方法，其特征在于，還包括下列步驟保存一包含采購商所用的標(biāo)準(zhǔn)條款和條件的客戶檔案；以及用客戶檔案中包含的標(biāo)準(zhǔn)條款和條件自動生成信用證。
6.如權(quán)利要求5所述的方法，其特征在于，還包括當(dāng)數(shù)據(jù)庫中包含的需求信息和客戶檔案中包含的標(biāo)準(zhǔn)條款和條件相矛盾時以人工方式修正信用證的步驟。
7.如權(quán)利要求5所述的方法，其特征在于，還包括下列步驟頒發(fā)信用證；以及告知銷售商該信用證的頒發(fā)。
8.如權(quán)利要求1所述的方法，其特征在于，還包括保存數(shù)據(jù)庫上貿(mào)易運作狀態(tài)的步驟。
9.如權(quán)利要求1所述的方法，其特征在于，還包括提供采購商和銷售商對數(shù)據(jù)庫的訪問以便查看貿(mào)易運作狀態(tài)的步驟。
10.如權(quán)利要求9所述的方法，其特征在于，提供采購商和銷售商對數(shù)據(jù)庫訪問的步驟還包括在互聯(lián)網(wǎng)上提供訪問。
11.如權(quán)利要求9所述的方法，其特征在于，提供采購商和銷售商對數(shù)據(jù)庫訪問的步驟還包括在私人網(wǎng)絡(luò)上提供訪問。
12.如權(quán)利要求9所述的方法，其特征在于，提供采購商和銷售商對數(shù)據(jù)庫訪問的步驟還包括在撥號線路上提供訪問。
13.如權(quán)利要求9所述的方法，其特征在于，提供采購商和銷售商對數(shù)據(jù)庫訪問的步驟還包括提供保密訪問。
14.如權(quán)利要求9所述的方法，其特征在于，靠加密、認(rèn)證以及非否認(rèn)手段提供保密訪問。
15.如權(quán)利要求9所述的方法，其特征在于，還包括對采購商和銷售商指定的另外當(dāng)事方提供對數(shù)據(jù)庫訪問的步驟。
16.如權(quán)利要求1所述的方法，其特征在于，初始單證是一信用證申請，該方法還包括下列步驟接收采購商的多項采購訂單；存儲多項采購訂單；以及用所存儲的多項采購訂單自動生成信用證。
17.如權(quán)利要求1所述的方法，其特征在于，還包括響應(yīng)初始單證生成一銷售單的步驟。
18.如權(quán)利要求17所述的方法，其特征在于，生成銷售單的步驟還包括用數(shù)據(jù)庫中包含的需求信息自動生成銷售單的步驟。
19.如權(quán)利要求18所述的方法，其特征在于，銷售商希望就貿(mào)易運作將信用賦予采購商，該方法還包括用自動生成的銷售單來確定該信用可資利用度的步驟。
20.如權(quán)利要求17所述的方法，其特征在于，還包括下列步驟將該銷售單與數(shù)據(jù)庫中包含的需求信息相比較以確定任何矛盾；以及存在某些矛盾時改正銷售單，由此生成一經(jīng)過核對的銷售單。
21.如權(quán)利要求20所述的方法，其特征在于，還包括下列步驟用銷售單生成一制造說明單；將該制造說明單與經(jīng)過核對的銷售單相比較以確定任何矛盾；以及存在某些矛盾時改正制造說明單，由此生成一經(jīng)過核對的制造說明單。
22.如權(quán)利要求20所述的方法，其特征在于，還包括下列步驟用經(jīng)過核對的銷售單自動生成裝運指令；以及將該裝運指令發(fā)送給一裝運商。
23.如權(quán)利要求22所述的方法，其特征在于，裝運指令為一裝貨底單。
24.如權(quán)利要求22所述的方法，其特征在于，將裝運指令發(fā)送給裝運商的步驟還包括以電子方式發(fā)送裝運指令的步驟。
25.如權(quán)利要求20所述的方法，其特征在于，還包括生成一發(fā)票的步驟。
26.如權(quán)利要求25所述的方法，其特征在于，生成發(fā)票的步驟還包括用經(jīng)過核對的銷售單自動生成發(fā)票的步驟。
27.如權(quán)利要求25所述的方法，其特征在于，還包括下列步驟將發(fā)票與經(jīng)過核對的銷售單相比較以確定任何矛盾；以及存在某些矛盾時改正發(fā)票，由此生成一經(jīng)過核對的發(fā)票。
28.如權(quán)利要求27所述的方法，其特征在于，還包括下列步驟接收一裝運商的裝運指令；將裝運指令與經(jīng)過核對的發(fā)票相比較以確定任何矛盾；以及通知裝運商這些矛盾，由此該裝運商可改正這些矛盾而提供經(jīng)過核對的裝運指令。
29.如權(quán)利要求27所述的方法，其特征在于，還包括下列步驟用經(jīng)過核對的發(fā)票自動生成裝運保險指令；以及將裝運保險指令發(fā)送給一承保商。
30.如權(quán)利要求29所述的方法，其特征在于，還包括下列步驟從承保商接收一保險證明；以及用保險證明、經(jīng)過核對的發(fā)票和經(jīng)過核對的裝運指令自動生成貿(mào)易單證。
30.如權(quán)利要求28所述的方法，其特征在于，還包括用經(jīng)過核對的發(fā)票和經(jīng)過核對的裝運指令自動生成貿(mào)易單證的步驟。
31.如權(quán)利要求30所述的方法，其特征在于，還包括以電子方式通知采購商和銷售商所規(guī)定的當(dāng)事方關(guān)于生成貿(mào)易單證的步驟。
32.如權(quán)利要求30所述的方法，其特征在于，貿(mào)易單證包括經(jīng)過核對的發(fā)票、經(jīng)過核對的裝運指令、保險證明、提取單以及檢驗證明。
33.如權(quán)利要求30所述的方法，其特征在于，還包括向采購商給出貿(mào)易單證用于協(xié)商的步驟。
34.如權(quán)利要求33所述的方法，其特征在于，還包括代表采購商執(zhí)行對帳功能的步驟。
35.如權(quán)利要求34所述的方法，其特征在于，代表采購商執(zhí)行對帳功能的步驟還包括相對于需求信息對貿(mào)易單證規(guī)定的到期付款進(jìn)行對帳的步驟。
36.如權(quán)利要求33所述的方法，其特征在于，還包括下列步驟接收反映采購商給銷售商付款的付款信息；以及響應(yīng)該付款信息代表銷售商執(zhí)行對帳功能。
37.如權(quán)利要求36所述的方法，其特征在于，代表銷售商執(zhí)行對帳功能的步驟還包括相對于經(jīng)過核對的發(fā)票對付款信息進(jìn)行對帳的步驟。
38.如權(quán)利要求30所述的方法，其特征在于，還包括向代表采購商的銀行給出貿(mào)易單證用于協(xié)商的步驟。
39.如權(quán)利要求38所述的方法，其特征在于，還包括在銀行附近的位置打印單證的步驟。
40.如權(quán)利要求39所述的方法，其特征在于，貿(mào)易單證以電子方式提供給銀行。
41.一種與采購商和銷售商之間貿(mào)易運作相關(guān)聯(lián)單證的處理系統(tǒng)，其特征在于，該系統(tǒng)包括一界面模塊，接收一包含關(guān)于該貿(mào)易運作需求信息的初始單證；一與該界面模塊相連的數(shù)據(jù)庫，該界面模塊至少將某些需求信息映射至數(shù)據(jù)庫；以及一與數(shù)據(jù)庫相連的單證生成模塊，該單證生成模塊用數(shù)據(jù)庫中包含的需求信息自動生成貿(mào)易單證。
42.如權(quán)利要求41所述的系統(tǒng)，其特征在于，初始單證是采購商的采購訂單。
43.如權(quán)利要求41所述的系統(tǒng)，其特征在于，界面模塊是以電子方式接收初始單證的電子界面模塊。
44.如權(quán)利要求41所述的系統(tǒng)，其特征在于，初始單證是采購商的信用證申請。
45.如權(quán)利要求44所述的系統(tǒng)，其特征在于，還包括一客戶檔案數(shù)據(jù)庫，該客戶檔案數(shù)據(jù)庫包含采購商所用的標(biāo)準(zhǔn)條款和條件；以及一與客戶檔案數(shù)據(jù)庫相連的信用證生成模塊，該信用證生成模塊用客戶檔案中包含的標(biāo)準(zhǔn)條款和條件自動生成信用證。
46.如權(quán)利要求45所述的系統(tǒng)，其特征在于，還包括一與信用證生成模塊、數(shù)據(jù)庫和客戶檔案數(shù)據(jù)庫相連的修正模塊，該修正模塊當(dāng)數(shù)據(jù)庫中包含的需求信息和客戶檔案中包含的標(biāo)準(zhǔn)條款和條件相矛盾時便修正信用證。
47.如權(quán)利要求41所述的系統(tǒng)，其特征在于，還包括一與數(shù)據(jù)庫相連的跟蹤模塊，并且在數(shù)據(jù)庫中保存一貿(mào)易運作狀態(tài)，跟蹤模塊提供采購商和銷售商對數(shù)據(jù)庫的訪問以便查看貿(mào)易運作狀態(tài)。
48.如權(quán)利要求47所述的系統(tǒng)，其特征在于，跟蹤模塊與互聯(lián)網(wǎng)相連，并且在互聯(lián)網(wǎng)上提供對數(shù)據(jù)庫的訪問。
49.如權(quán)利要求47所述的系統(tǒng)，其特征在于，跟蹤模塊與私人網(wǎng)絡(luò)相連，并且在私人網(wǎng)絡(luò)上提供對數(shù)據(jù)庫的訪問。
50.如權(quán)利要求47所述的系統(tǒng)，其特征在于，跟蹤模塊與撥號線路相連，并且在撥號線路上提供對數(shù)據(jù)庫的訪問。
51.如權(quán)利要求47所述的系統(tǒng)，其特征在于，跟蹤模塊與界面模塊相連，界面模塊提供對數(shù)據(jù)庫的保密訪問。
52.如權(quán)利要求51所述的系統(tǒng)，其特征在于，靠加密、認(rèn)證以及非否認(rèn)手段提供保密訪問。
53.如權(quán)利要求41所述的系統(tǒng)，其特征在于，初始單證是一信用證申請，該系統(tǒng)還包括一與界面模塊和信用證生成模塊相連的采購訂單存儲設(shè)施，采購訂單存儲設(shè)施經(jīng)界面接口模塊從采購商接收到多項采購訂單，并且信用證生成模塊用采購訂單存儲設(shè)施所存儲的多項采購訂單自動生成信用證。
54.如權(quán)利要求41所述的系統(tǒng)，其特征在于，單證生成模塊響應(yīng)初始單證生成一銷售單。
55.如權(quán)利要求54所述的系統(tǒng)，其特征在于，單證生成模塊用數(shù)據(jù)庫中包含的需求信息生成銷售單。
56.如權(quán)利要求55所述的系統(tǒng)，其特征在于，還包括一與單證生成模塊相連的信用證驗證模塊，若銷售商希望就貿(mào)易運作將信用賦予采購商，信用證驗證模塊便用銷售單來確定采購商信用可資利用度。
57.如權(quán)利要求54所述的系統(tǒng)，其特征在于，還包括一與單證生成模塊和數(shù)據(jù)庫相連的比較改正模塊，該比較模塊將該銷售單與數(shù)據(jù)庫中包含的需求信息相比較以確定任何矛盾，當(dāng)存在某些矛盾時該比較改正模塊改正銷售單，由此生成一經(jīng)過核對的銷售單。
58.如權(quán)利要求57所述的系統(tǒng)，其特征在于，單證生成模塊還采用銷售單生成制造說明單，比較改正模塊將該制造說明單與經(jīng)過核對的銷售單相比較以確定任何矛盾，當(dāng)存在某些矛盾時該比較改正模塊進(jìn)一步改正制造說明單，由此生成一經(jīng)過核對的制造說明單。
59.如權(quán)利要求57所述的系統(tǒng)，其特征在于，單證生成模塊與界面模塊相連，該單證生成模塊還用經(jīng)過核對的銷售單生成裝運指令，界面模塊將該裝運指令發(fā)送給一裝運商。
60.如權(quán)利要求57所述的系統(tǒng)，其特征在于，單證生成模塊還生成一發(fā)票。
61.如權(quán)利要求60所述的系統(tǒng)，其特征在于，比較改正模塊將發(fā)票與經(jīng)過核對的銷售單相比較以確定任何矛盾，并且當(dāng)存在某些矛盾時改正發(fā)票，由此生成一經(jīng)過核對的發(fā)票。
62.如權(quán)利要求61所述的系統(tǒng)，其特征在于，單證生成模塊用經(jīng)過核對的發(fā)票生成所需的貿(mào)易單證。
全文摘要
本發(fā)明的第一和第二部件，組合在一起提供一用于始發(fā)一貿(mào)易交易的客戶界面，并用于對交易狀態(tài)的保密查看。第三部件則輔助對支持貿(mào)易交易所需的大量具體單證進(jìn)行自動生成和驗證。第三部件另外還對構(gòu)成貿(mào)易交易基礎(chǔ)的銷售商的商品制造及裝運進(jìn)行跟蹤及輔助管理。第四部件根據(jù)采購訂單自動生成信用證，并對依據(jù)信用證或公開帳戶進(jìn)行的付款執(zhí)行一對帳功能。
文檔編號G06Q40/00GK1439142SQ99816335
公開日2003年8月27日 申請日期1999年12月23日 優(yōu)先權(quán)日1998年12月23日
發(fā)明者T·哈爾屏, Z·曹, S·方, J·雷爾, K·K·揚, M·P·泰穆, P·科, T·陳, A·桑, N·托里斯, Y·B·亞普, K·里昂, S·所羅門, S·昌 申請人:大通銀行