專利名稱：產(chǎn)生跟單信用證并符合貨運單據(jù)的制作方法
技術(shù)領域：
本發(fā)明涉及支持進出口交易的系統(tǒng)與方法。更具體地，涉及生成與跟單信用證文件(documentary credit instrument)一致的銀行所需單據(jù)以及合作的(collaborative)跟單信用證文件的申請或修改的方法與系統(tǒng)。
背景技術(shù)：
跟單信用證文件，包含信用證，長期被用來確保對賣方或供應方付款，尤其是當買方距離遠(國際交易)或與賣方?jīng)]有持續(xù)關(guān)系時。一般地，買方向買方與其具有銀行關(guān)系的開證銀行請求開立跟單信用證文件，有時利用如圖4A-D所示的申請書。經(jīng)常在買方請求開證之前，買方與賣方議付跟單信用證文件的條款。開證行將有效信用證文件發(fā)送給通知行。依賴于并且根據(jù)跟單信用證，買方發(fā)貨(ship goods)。如果需要修改，買方與賣方還議付對跟單信用證文件的修改條款。
人們早就認識到跟單信用證的開立與兌現(xiàn)(redemption)過程充滿了出錯的機會與結(jié)果產(chǎn)生的契約落空(frustration)。例如，在美國專利號6151588中Tozzoli等人在第3欄談及開證行如何要求信用證中要求的所有單據(jù)應該準確地對應于信用證的條款，并且即使是由于打印錯誤或者輕微的拼寫錯誤，也拒不付款給賣方，從而使要求付款的賣方契約落空。Tradecard公司為上述專利的受讓人，其通過創(chuàng)建另類資金機制，來應對這一以及其他長期面臨的跟單信用證問題，這一機制描述見于上述專利及可從其網(wǎng)站www.Tradecard.com得到的其”Financial Supply Chain AutomationTheMissing Link in Supply Chain Management White Paper”(2002年4月29日創(chuàng)建的PDF文件)。Tradecard繞過了這些跟單信用證問題，而沒有解決它們。
因此，需要發(fā)明減少申請、開立和兌現(xiàn)跟單信用證文件中的錯誤的方法與系統(tǒng)。這樣的方法與系統(tǒng)可以利用從跟單信用證模板映射的數(shù)據(jù)生成兌現(xiàn)跟單信用證銀行所需的單據(jù)。這樣的方法與系統(tǒng)可以鼓勵買方與賣方合作準備跟單信用證申請，以及以電子方式提供開證和兌現(xiàn)跟單信用證文件的申請。這樣的方法與系統(tǒng)可以鼓勵買方與賣方合作準備修改跟單信用證文件的請求。

發(fā)明內(nèi)容
本發(fā)明涉及支持進出口交易的系統(tǒng)與方法。更具體地，其包括生成與跟單信用證文件一致的銀行所需單據(jù)以及合作的跟單信用證文件的申請書和修改書的方法與系統(tǒng)。本發(fā)明的具體方面在權(quán)利要求、說明書、以及附圖中描述。


圖1為實現(xiàn)本發(fā)明的環(huán)境的高級方框圖；圖2為實現(xiàn)本發(fā)明的環(huán)境的子系統(tǒng)體系結(jié)構(gòu)的高級方框圖；圖3顯示跟單信用證過程中的參加者；圖4A-C為示例跟單信用證申請書，由人工準備，沒有應用本發(fā)明；圖5A-D顯示已輸入跟單信用證信息的匯總，包含實現(xiàn)本發(fā)明的系統(tǒng)環(huán)境；圖6至9顯示輸入跟單信用證信息的部分界面；圖10顯示設置用戶界面；圖10A-C為用戶界面的第一實施方式；圖10D-G為第二實施方式；圖11顯示輸入發(fā)票的用戶界面的兩種實施方式；圖12顯示輸入裝箱單的用戶界面的兩種實施方式；圖13顯示輸入有關(guān)于海運提單或空運單的信息的用戶界面的兩種實施方式；圖14為本發(fā)明一種實施方式的同步規(guī)則集合的一部分；圖15為系統(tǒng)利用該系統(tǒng)收集的數(shù)據(jù)而生成的信件的示例格式。
具體實施例方式
以下參考附圖進行詳細描述。描述優(yōu)選實施方式用來說明本發(fā)明，而非限制其權(quán)利要求所限定的范圍。本領域技術(shù)人員應該理解對以下描述的等價變化。
在通過引用融入的相關(guān)申請中描述了很好地融入了跟單信用證過程的環(huán)境。所融入的申請描述了對進出口商有用的以從訂單直至結(jié)算階段跟蹤貨物的方法與設備。跟單信用證可以歸類作為結(jié)算的一部分，但是其在開始貨物的任何轉(zhuǎn)移之前安排。如下所述，在貨物轉(zhuǎn)移期間利用準確匹配議付(negotiated)跟單信用證的語言生成單據(jù)是有用的。
圖1-2顯示Tradebeam的環(huán)境，其中融入了跟單信用證過程。圖1為Tradebeam產(chǎn)品的訂單、物流后勤(logistics)、以及結(jié)算方面的高層方框圖。訂單模塊101支持信用與風險管理、合同協(xié)商與履行、對進/出口規(guī)章的遵守、以及對銷售與購買訂單的處理。物流后勤模塊102支持許多活動。所支持的活動包含存貨控制與配送、追蹤與跟蹤貨運、以及保險規(guī)格(insurancespecification)、采購與書面證明(procurement and certification)。與本發(fā)明方面有關(guān)的所支持的方面包含貨運單據(jù)創(chuàng)建與跟蹤、檢查、裝箱單生成、裝運指令與商業(yè)單據(jù)。其他物流后勤活動包含準備與生成報關(guān)單、以及預定與計劃運輸。結(jié)算模塊103支持理賠(OS & Dclaims)、付款處理、運費支付、以及發(fā)票處理。另外，其支持作為當前主題的跟單信用證或信用證。
圖2顯示將Tradebeam環(huán)境組織為子系統(tǒng)。這些子系統(tǒng)包括過程管理子系統(tǒng)201、單據(jù)管理子系統(tǒng)202、事件管理子系統(tǒng)203、業(yè)務智能子系統(tǒng)204、集成子系統(tǒng)205、安全子系統(tǒng)206、貿(mào)易設置子系統(tǒng)207、全球化/本地化子系統(tǒng)208、以及個性化子系統(tǒng)209。這些子系統(tǒng)與底層組件可以用來支持跟單信用證活動。
可以依賴于特定的跟單信用證國際標準。用于進/出口的跟單信用證文件應該符合(conform)經(jīng)常更改的跟單信用證統(tǒng)一慣例(1993修訂本，國際商會500號出版物，巴黎，法國)。國際商會(ICC)發(fā)布國際認可的管理跟單信用證的規(guī)則、定義、以及實踐，稱為“跟單信用證統(tǒng)一慣例”(UCP)。UCP在世界上所有訂閱UCP的銀行之間促進信用證與其他跟單信用證文件的標準化。這些規(guī)則被不時地更新；最后一次更新在1994年1月1日生效，稱為UCP500。人們還希望將DC/LC系統(tǒng)映射到由銀行機構(gòu)SWIFT標準使用的標準字段(field)。對于映射可適用的Swift標準可以包含MT700與MT707。在這些輸入畫面上顯示的字段可以容易地映射到這些標準。
跟單信用證為用來覆蓋幾種相關(guān)類型的金融文件的名詞。ICC與銀行組織的SWIFT標準一貫地使用跟單信用證(documentary credit)這一名詞，而不是信用證(letter of credit)。美國的許多銀行與行業(yè)一般用信用證。使用國際上接受的名詞，跟單信用證為一種金融文件，一般由銀行開立，其中憑出具符合信用證(credit document)中所規(guī)定的條款和條件的單據(jù)，開證行負責進行付款。有兩種類型的跟單信用證，即商業(yè)信用證(commercialletters of credit)(即進口或出口LC)與備用信用證(standby letters ofcredit)。跟單信用證包含銀行代表買方(進口商)在預定時間段內(nèi)在出具所規(guī)定的單據(jù)的前提下立即(即期(sight))或在隨后的日期(后期(Forward))支付商品或服務的賣方(出口商)指定的金額的許諾。即期跟單信用證為一種要求即期匯票(draft)的跟單信用證類型，意指出口商有權(quán)即期，即在向銀行出具匯票時得到付款。遠期(term)跟單信用證允許在30、60、90天的期限上或者在某指定未來日期進行付款。即期或遠期跟單信用證都需要在設定時間限制內(nèi)出具符合信用證條款的單據(jù)，以兌現(xiàn)該信用證。所謂的職業(yè)國際銀行(Professional International Banks)處理某些不經(jīng)常使用的跟單信用證類型，例如可轉(zhuǎn)讓信用證(transferable letters of credit)、循環(huán)信用證(revolving letters of credit)、背對背信用證(back-to-back letters ofcredit)、紅條款信用證(red clause letters of credit)。
跟單信用證(DC)允許買方與賣方訂約(contract)受托(trusted)中間方(銀行)，在賣方已經(jīng)發(fā)貨(ship the goods)、并且能夠提供符合議定的信用證(agreed-upon letter)的條款的單據(jù)證據(jù)的情況下，該中間方將保證對賣方的完全付款。該文件雖然在本質(zhì)上較簡單，但是可以具有許多變化。通過當滿足DC條件時保證賣方以及通過合理地保證買方收到所訂購的貨物，DC在買方與賣方之間分散風險。DC是用于付款的常用文件，尤其當訂約方相互不熟悉時。雖然該文件對雙方都提供了良好地保證，其也可能會讓人困惑，并且有限制性。其也可能較昂貴，從幾百美圓至總值的百分之五。
DC一般是不可撤消的，這意味著一旦確定(establish)了DC，則在沒有買方、賣方、開證行、通知行的同意下，不能改變DC。因此，賣方，尤其是當經(jīng)驗不足時，應該向有經(jīng)驗的銀行、受托經(jīng)紀人、及其運輸行(freightforwarder)出具DC協(xié)議，從而這些方面能夠幫助確定該DC是否合法，以及是否能夠合理地滿足所有條款。受托銀行，而非開證行或買方的銀行可以在一定費用下?lián)螕?jù)的真實性。在非開證行國家的國家中開立的對受益人有利的信用證必須通過受益人國內(nèi)的通知行通知。通知行的主要任務在于驗證信用證的真實性，并且將其詳情轉(zhuǎn)發(fā)給受益人。
DC在設計上可以非常靈活，以滿足特定目的。例如，背對背信用證允許賣方使用從其買方收到的LC作為銀行抵押(collateral)以開立其自己的LC，從而賣方能夠購買滿足其買方訂單所需的輸入或者供應。由于對他方的依賴性、以及完成原始交易的額外步驟，所以增加了風險，因此某些銀行可能不愿意開立背對背信用證。由于信用證為金融合同，所以其可能有很大變化。某些LC變化包含循環(huán)、自由議付(Freely Negotiable)、紅條款、可轉(zhuǎn)讓、可撤消或者限制議付(Restricted)。也許至少從賣方的觀點來說最安全、人們最希望的信用證為備用信用證。備用信用證與商業(yè)信用證不同，因為其更像銀行或者履約保證書。其不是主要的付款方法，而是一種通常對于較長期項目的自動防故障(fail-safe)方法或者保證。只有當買方未進行所安排的付款或者以其他方式未滿足預定條款和條件時該LC才承諾付款。否則，買方在收到貨物時，或者根據(jù)與賣方安排的信用證條款付款。如果買方不履行責任，那么賣方必須通過提供備用信用證條款可能要求的單據(jù)與證明憑備用信用證支取付款。與其他信用證相比，典型的備用信用證對于賣方或者受益人滿足條款來說較簡單。因此，使用備用信用證有利于賣方。因為備用信用證可能長年有效(持久條款(Evergreen Clause))，所以其消除了對于重復客戶每項交易的單獨信用證的復雜性。因此，可以有多于一項的交易與單個信用證相關(guān)聯(lián)。
使用信用證或跟單信用證具有某些缺點。如果在跟單信用證的時間、單據(jù)或者其他要求中存在即使是最細微的差別，則買方可以拒絕所托運的貨物(shipment)。被拒絕的托運貨物意味著賣方必須迅速找到新買主，一般是以較低價格，或者付款將托運貨物返回或者處理。除昂貴之外，跟單信用證需要時間開出，并且一般會從其開立日直至最終兌現(xiàn)或者付款、違約拒絕、過期或者取消(一般取消要求雙方同意)占壓買方的流動資本(wording capital)或者信用額度(credit line)。
DC的條款非常具體和有拘束力。許多貿(mào)易商，即使是經(jīng)驗豐富者，也會由于其無法理解或者遵守條款而遇到很大困難。某些統(tǒng)計數(shù)字顯示近乎50％的跟單信用證付款提交(submission)會由于沒有遵守條款而被拒絕。例如如果條款要求送達四個特定單據(jù)而其中一件不完整或者僅僅是送達晚了，則都會拒付，而不管每個其他條款都滿足并且收到狀態(tài)良好的托運貨物。銀行的工作是確保安全的付款交易，將堅持嚴格如所寫的那樣滿足條款。有時買方同意在不滿足條款時付款。但是修改或更改DC的條款可能費錢、費時，有時甚至不可能。
DC的基本機制涉及至少四方a)買方或申請人；b)開證行或申請人銀行；c)受益人銀行或通知行；d)賣方或受益人。圖3顯示買方301、賣方302、買方銀行311、以及賣方銀行312。該圖可以用來說明DC的傳統(tǒng)手工處理。傳統(tǒng)地，買方或申請人301向其銀行申請開立DC。如果申請人與該開證行沒有信用約定，則該申請人必須以現(xiàn)金或某些其他可轉(zhuǎn)讓(negotiable)證券保證DC。開證行或申請人銀行311開立有利于受益人的DC，并且將單據(jù)傳送給代理(correspondent)銀行。申請人銀行以后還驗證所有條款、條件、以及單據(jù)符合DC，并且通過賣方銀行向賣方付款。代理行312驗證DC真實性并且通告(或通知)受益人302。通知行312作為申請人銀行311與受益人302之間的受托橋梁。其也可以將受益人履約單據(jù)證據(jù)轉(zhuǎn)回給開證行。然而，通知行沒有DC付款的責任，除非通知行添加了其自己的保兌(confirmation)。受益人可以要求申請人及其銀行請求通知行保兌DC。這意味著保兌行也承諾確保當受益人符合DC的條款與條件時向受益人付款。保兌行為此服務收取一筆不小的費用。當受益人或其銀行不熟悉開證行及其可信度時，或者開證行(即使是聲譽良好的銀行)處于高風險國家時，這是非常有用的。如果受益人不熟悉通知行/保兌行，受益人還可能通過受托銀行出具其符合信用證的單據(jù)。然而，這可能增加附加費用。受益人或者賣方302必須確保根據(jù)規(guī)定準備了所訂購的貨物，并且按時裝運。賣方還必須收集并且向銀行出具DC所要求的全套準確的單據(jù)。
通過查看跟單信用證的申請表，可以進一步理解跟單信用證過程與符合所需的信息。圖4為用于手工申請的一般表單。在圖4A所示的頁面上，指示申請人通過在字段401中填入申請日期來完成該表單。在框402，指示所完成的信用證傳送給受益人的方法?？梢允褂脧瓦x框或指明另一種方法傳送。可以在字段404可選地指定通知行的名稱。一般地，受益人選擇的通知行按照名稱與地址填入。如果沒有指定通知行，則開證行可以選擇其所熟悉的銀行。如果通知行不是開證行的代理行，則與通知行在同一國家內(nèi)的代理行可以作為中間方。在405填入申請人完整的公司名稱與地址。在406填入該信用證的數(shù)字金額與金額增減幅度(tolerance percentage)。如金額使用About與Approximately(大約)等詞語，則適用10％的增減幅度，或者開證行可以提供預定的百分比。在407還填入信用證的大寫金額。在408填入受益人或賣方的完整公司名稱與地址。在409指定該信用證的到期日。在410指定受益人將所需貨物裝運的最遲日期。在允許多個裝運日期的情況下，根據(jù)特定的裝運計劃，可以使用貨物描述字段417或特殊指示字段427。在411指示付款條款或匯票付款到期日。即期匯票在出示與信用證符合的單據(jù)時付款。付款可以延遲特定的天數(shù)，例如距離提單出單日期(bill of lading date)60天或者見票后90天。也可以指定固定到期日(maturity date)或其他付款條款。兌現(xiàn)信用證時的可支付金額可以是發(fā)票金額的100％，或者另一指定金額412。負責銀行收費的一方(申請人或受益人)在413指定。一般地，貿(mào)易伙伴支付其各自銀行的費用。如上所示，在特定時間可支付的匯票可按折扣早一些兌現(xiàn)。在414中指示支付折扣費用的一方。一般地，受益人發(fā)生折扣費用，以換取早些接收付款。貨物開始運輸以及最終運抵的裝貨與卸貨港在415、416中填入。在417中記錄對要裝運的貨物的實際描述。該實際描述必須出現(xiàn)在商業(yè)發(fā)票上，并且應該簡短。這是小偏差就可能延遲跟單信用證兌現(xiàn)的地方之一。在418指示貨運條款。標準貨運條款可通過復選框選擇或可以指定其它貨運條款。標準條款包含“F.O.B”，表示船上交貨；“C & F”或“CFR”，表示成本加運費；“CIF”，表示成本、保險費加運費；以及“FAS”，表示船邊交貨。該系統(tǒng)支持國際商會(ICC)認可的13種條款(INCO條款)，或者至少有適用的和經(jīng)常使用的條款。1990標準條款列表包含EXW——工廠交貨(Ex Work)(......指名地點)；FCA——貨交承運人(Free Carrier)(......指名地點)；FAS——船邊交貨(Free Alongside Ship)(......指名裝運港)；FOB——船上交貨(Free On Board)(......指名裝運港)；CFR——成本加運費(Cost andFreight)(......指名目的港)；CIF——成本、保險費加運費(Cost InsuranceAnd Freight)(......指名目的港)；CPT——運費付至(Carrier Paid To)(......指名目的港)；CIP——運費、保險費付至(Carriage And Insurance PaidTo)(......指名目的港)；DAF——邊境交貨(Delivered At Frontier)(......指名地點)；DES——目的港船上交貨(Delivered Ex Ship)(......指名目的港)；DEQ——目的港碼頭交貨(Delivered Ex Quay Duty Paid)(......指名目的港)；DDU——未完稅交貨(Delivered Duty Unpaid)(......指名目的港)；以及DDP——完稅后交貨(Delivered Duty Paid)(......指名目的港)。也可以使用其他標準條款，或者可以指定為其他條款。申請人在419選擇信用證為可轉(zhuǎn)讓(transferable)或不可轉(zhuǎn)讓(nontransferable)的，在420選擇允許還是不允許分批裝運(partial shipments)，在421選擇允許還是不允許轉(zhuǎn)運(transshipments)。
在圖4B所示頁面上，申請人指定賣方要兌現(xiàn)該跟單信用證所需的單據(jù)。該表單要求從全套潔凈已裝船(clean on board)內(nèi)模式(inter modal)運輸提單單據(jù)、全套潔凈已裝船海運提單單據(jù)、空運單(air waybill)、以及其他所指定的運輸單據(jù)中選擇至少一種運輸單據(jù)422。可以選擇一或多種運費單據(jù)423，其可以被標記為送到即付(collect)、預付、開立給或背書給開證行的指定人(the order of the issuing bank)。在424指定通知方，包含公司名稱、以及地址，經(jīng)常還有聯(lián)系人名稱與電話號碼。在425選擇保險條件，例如由申請人投保，從而不需要保險單據(jù)；由賣方投保的特定保險；或者在申請書中描述的其他保險。可能要求將其他商業(yè)單據(jù)傳送給銀行426，例如商業(yè)發(fā)票、裝箱單、產(chǎn)地證明的一個或多個副本或者正本。在427指定特殊指示和/或條件，如UCP所限定的。在428給出必須向議付行(negotiating bank)交單的、相關(guān)于裝運的時間。如果該時間未指定，則開證行可以使用缺省值，例如21天。交單時間一般對應于最遲裝運日期410與跟單信用證到期日409之間的天數(shù)?？梢蕴峁┢渌畔⒐﹥?nèi)部使用，其可能不包含在跟單信用證的條款中。例如，可以在429指定運輸行或者海關(guān)經(jīng)紀人的名稱與地址。作為銀行服務，可以將有關(guān)跟單信用證的全套單據(jù)發(fā)送給經(jīng)紀人/運輸行進行清關(guān)。申請人公司的聯(lián)系信息也可以在430中提供，包括能夠回答有關(guān)開立跟單信用證或者當跟單信用證被兌現(xiàn)時對不符(discrepancies)的棄權(quán)聲明書的問題的人員的名稱與電話號碼。在圖4C所示頁面上，可以確定(identify)一個或多個共同申請人431、432?？梢悦Q、地址、以及一個或多個簽名來確定共同申請人。開證行可以提供額外信息塊433，僅限銀行使用。
通過回去參照圖3，能夠理解在實現(xiàn)本發(fā)明各方面的跟單信用證交易中的各方之間的通信模式以及所需的通信。再一次地，所述各方一般包含貨物的買方或者跟單信用證的申請人、賣方或者受益人、開證行或者買方銀行、以及通知行或者賣方銀行。以下步驟的許多可能的組合可以實現(xiàn)本發(fā)明的各個方面在步驟321，賣方302創(chuàng)建信用證指示(letter of credit instruction，LCI)，并且以電子形式將其發(fā)送給買方301。賣方可以使用諸如圖6-9所示的用戶界面來創(chuàng)建該LCI。信用證指示為賣方請求買方輸入到信用證申請書中的條款與條件，其成為信用證文件。信用證指示指明為支持買方的計劃購買而在信用證中所需的金額。在信用證指示中請求的金額為估價單(proforma invoice)中估計的金額，包含賣方希望取得的超出貨物成本的成本。信用證指示可以提供信用證的詳細條款與條件。這些條款與條件當然要經(jīng)過買賣雙方之間的談判與協(xié)議。
在步驟322，買方創(chuàng)建信用證申請書(letter of credit application，LCApp)，并且以電子形式將其發(fā)送給賣方以對條款與條件進行更改/改變(如果有的話)。由買方準備商業(yè)信用證申請書，并且提供給其銀行，以進行申請以及隨后開立信用證。諸如通過引用并入的專利申請中所述的合作系統(tǒng)可以被方便地用來傳遞消息、顯示、編輯、以及生成交互的審計軌跡(audittrail)。買賣雙方合作并且確定信用證條款與條件。當買賣雙方努力對條款達成一致時，LCI和/或LCApp的草本可以在買賣雙方之間交換多次。LCI、LCApp或者實際開立的LC的條款最好與由總體進-出口跟蹤系統(tǒng)所跟蹤的一個或多個交易的其他細節(jié)相關(guān)聯(lián)，如所并入的專利申請中所述。
在步驟323，買方以至少與向賣方302兌現(xiàn)有關(guān)的條款的最終版將信用證申請書發(fā)送給開證行311。對于開證行的傳送最好為電子形式。在步驟324，開證行處理并接受信用證申請。開證行確認該申請并且將該確認存儲在該系統(tǒng)中。在銀行生成PDF文件的情況下，上傳該PDF文件。在來自銀行的傳真的情況下，通過使用諸如Easy Link Fax集成環(huán)境等軟件模塊，將該傳真掃描為PDF格式或者以電子形式捕獲并且轉(zhuǎn)換為PDF。有許多PDF格式的替代格式，包含任意圖形文件格式，例如TIF或JPEG格式，以及任意網(wǎng)絡兼容格式，例如WordPerfect的Trellix格式，或者其他文件包裹格式。優(yōu)選地，開證行既生成跟單信用證文件的傳真件(facsimile)又生成機器可讀版本，例如XML、EDI、cvs或其他互換格式文件，其可以被上傳到該系統(tǒng)中。生成跟單信用證的機器可讀版本可以減少在記錄跟單信用證條款時的印刷錯誤的機會，以在以后生成一致的所謂同步化單據(jù)(synchronized document)。如果開證行沒有生成機器可讀版本，則由某人手動地將銀行消息的詳情輸入到系統(tǒng)中。與通過實現(xiàn)本發(fā)明的系統(tǒng)進行的通信無關(guān)地，在步驟325，開證行通知通知行其已經(jīng)開立了信用證。用于此類通知的一種銀行系統(tǒng)已知為SWIFT。在步驟326，通知行將LC發(fā)送給賣方。賣方所接收的經(jīng)過驗證的信用證可以用來通過以下方式更新該系統(tǒng)在來自通知行的PDF的情況下，為所上傳的PDF；在來自通知行的傳真的情況下，為傳真消息的經(jīng)轉(zhuǎn)換版本；以及在由通知行傳送的電子文件的情況下，為所上傳的XML、EDI、cvs或其他互換格式文件。
經(jīng)常需要對信用證進行修改，如步驟427-440所述。在步驟427，當需要信用證修改(letter of credit amendment，LCAmd)時，賣方將問題或議題通知買方(或者相反)，并且買賣雙方再次合作并且確定對條款的改變。可能有消息以及對草本文本的更新的交換一或多次，直至買賣雙方就改變后的條款達成一致。在步驟428，最好以電子形式，買方向開證行提交信用證修改書，并且將最終版本提供給賣方。在步驟429，開證行例如通過PDF或傳真確認而批準信用證修改，該確認被上傳到該系統(tǒng)中，如上所述。優(yōu)選地，開證行還生成電子形式的機器可讀的確認，例如XML、EDI、或cvs文件，其可以被直接用來反映信用證的更新后的條款。如果未生成機器可讀的確認，則以手工方式根據(jù)銀行消息輸入修改后的條款。在步驟340，開證行將修改后的信用證傳送給通知行。這一步驟一般通過使用安全銀行通道，例如SWIFT來進行。在步驟341，賣方用發(fā)票、提單或者空運單、裝箱單、以及其他進行結(jié)算需要提交給銀行的單據(jù)匹配或符合(match or reconcile)信用證(包含修改)。優(yōu)選地，使用本系統(tǒng)來利用用于生成信用證指示或申請書的相同數(shù)據(jù)，生成至少一個或多個優(yōu)選為多個的銀行所需單據(jù)，其被符合為適當反映所開立與修改的信用證條款。賣方向銀行提交信用證正本以及所有要求的單據(jù)以進行結(jié)算。
通過提供單據(jù)管理、對有關(guān)各方的提醒以及其中的通信、活動跟蹤與可視性、將貿(mào)易單據(jù)鏈接到信用證條款、以及靈活的設立與協(xié)調(diào)的各種組合，如所并入的專利申請中所述的系統(tǒng)支持跟單信用證的使用。文檔處理的可視性可以抵消在信用證兌現(xiàn)過程中將實際付款延遲至貨物裝運之后數(shù)月的因素。會造成延遲的因素包括完成交易所需的多個單據(jù)、完成處理所涉及的多方，以及發(fā)出付款所需的對于單據(jù)的嚴格符合。這些因素由于銀行在該過程中持有資金這一對銀行有利條件而得到加重，因為銀行會收到不少管理與信用費用。利用用來協(xié)調(diào)文檔的改進的設施，就可以減少人們對跟單信用證條款的抱怨，以及利用用來管理完成該文檔的可視性的改進的設施，就可以縮短資金循環(huán)的長度。
跟單信用證管理的一個方面為普通用戶管理。輸入并且在該系統(tǒng)中可用的跟單信用證交易中的關(guān)鍵參與者(actor)可能不止上述四者，包含買方或者申請人、開證行或者申請人銀行、受益人銀行或者通知行、賣方或者受益人、以及一個或多個運輸行。優(yōu)選地，可以將參與者輸入系統(tǒng)，并且在各交易中重新使用。
參照圖3描述的電子過程可以由工作流結(jié)構(gòu)、提醒、以及通知支持。這些參與者之間的一種交互情景為如下1.進口商設立(set up)信用證(或者2.由進口商或者出口商從銀行上傳)。3.進口商或者出口商將該信用證與貿(mào)易或交易相關(guān)聯(lián)。4.由運輸行輸入運輸單據(jù)信息(B/L、AWB等等)。5.由出口商創(chuàng)建發(fā)票與裝箱單。6.出口商通過遵循正確的信用證業(yè)務規(guī)則核準所有單據(jù)符合信用證條款。7.出口商匯總銀行兌現(xiàn)信用證所需的單據(jù)，并且將這些單據(jù)發(fā)送給銀行以進行結(jié)算。在系統(tǒng)中對各個參與者的設置支持它們根據(jù)這一情景或者其他情景發(fā)揮作用。
可以以下一般方式設立跟單信用證或者信用證可以與其相關(guān)聯(lián)的一綜貿(mào)易發(fā)起(initiate)貿(mào)易。將參與者與該貿(mào)易相關(guān)聯(lián)。跟單信用證或者信用證可以與該貿(mào)易相關(guān)聯(lián)。因為一件信用證可以支持許多綜貿(mào)易，所以允許用戶根據(jù)在該系統(tǒng)中可用的信用證，在現(xiàn)有信用證中選擇用于該貿(mào)易，或者生成新的信用證。雖然使用跟單信用證或者信用證對于給定貿(mào)易是可選的，但是當選擇了使用它時，其會影響下游的業(yè)務規(guī)則，因為跟單信用證的條款管理用來生成特定的銀行所需的以及與貨運有關(guān)的單據(jù)的信息?？梢栽O立通知規(guī)則，如在并入的申請中進一步描述的。
所述工作流結(jié)構(gòu)、提醒、以及通知可以如下賣方準備LCI，并將其發(fā)送給買方。系統(tǒng)通知買方LCI的到達，并且提醒其在進行該交易中的角色。買方準備LCApp，并將其發(fā)送給賣方。買賣雙方就LCApp(或者LCI)進行合作，并且達成商定草本。代表買方的用戶可以將商定LCApp發(fā)送給經(jīng)理批準。買方經(jīng)理可以將LCApp發(fā)送給開證行?？梢耘渲冒l(fā)送單據(jù)功能，以在買賣雙方之間發(fā)送單據(jù)，并且該功能還可以配置來在買賣雙方及其各自銀行之間發(fā)送單據(jù)。通知買賣雙方LCApp已經(jīng)完成被發(fā)送給了開證行。該通知可以鏈接到所述發(fā)送單據(jù)功能。對于人工傳送，該發(fā)送單據(jù)功能可以將單據(jù)發(fā)送給打印機；對于系統(tǒng)之間傳送，該發(fā)送單據(jù)功能可以將單據(jù)發(fā)送電子郵件、電子單據(jù)互換或者其他電子傳送系統(tǒng)；對于系統(tǒng)至諸如傳真或電子單據(jù)的PDF附件等個人傳送，該發(fā)送單據(jù)功能可以將單據(jù)發(fā)送給傳真生成與傳送系統(tǒng)；或者該發(fā)送單據(jù)功能可以將單據(jù)發(fā)送至組合目的地。
對于信用證修改，買方可以準備所提議的修改，并且將其發(fā)送給賣方(或者相反)。買賣雙方就信用證修改進行合作，并且達成商定草本。代表買方的用戶可以將商定的修改發(fā)送給經(jīng)理批準。買方經(jīng)理可以將該修改發(fā)送給開證行。
在圖5中顯示概括了為LCI、LCApp、LC、或者LC修改而收集的信息的用戶界面。在頂部框中，導航條501提供對界面頁面的直接訪問，這些界面頁面為可使用該LC系統(tǒng)的部分環(huán)境。導航條鏈接包含“主頁”(home)、顯示匯總貨運狀態(tài)的“控制板”(dashboard)、存儲LC的“單據(jù)庫”(documentvault)、“報告”(report)、“管理”(Administration)、“幫助”(help)、以及“登出”(logout)。上下文框502標識用戶、用戶的公司聯(lián)系、以及該用戶目前在其中工作的特定業(yè)務(Portfolio)。貨運描述信息503(如果適用的話)包含裝運號(Shipment number)、預期出發(fā)日、預期到達日、起運地、目的地、提單或空運單號、以及船名/航次(Vessel/Voyage)或者航班/日期(Flight/Date)。提醒顯示504報告對于用戶的未處理提醒的數(shù)目，這些提醒可能由其他人采取的行動導致、用戶采取的行動失敗、經(jīng)過里程碑或者提醒日期、或者其他事件或條件。該提醒顯示提醒用戶要解決的優(yōu)先問題，而不要求用戶直接訪問要解決的問題列表。該框與左側(cè)列表框可以用于進出口系統(tǒng)的多種用戶界面，以呈現(xiàn)一致的用戶界面。
在左側(cè)框中的列表相應于在圖1的討論中所指的TradeBeam產(chǎn)品的訂單、物流后勤、以及結(jié)算方面。訂單功能列表101，即在該實施例中的511，支持諸如人工訂單輸入、人工銷售訂單輸入、以及檢查是否符合進出口規(guī)章等功能。裝運或者物流后勤功能列表102，即512，支持諸如預定與調(diào)度運輸、準備出口貨運指示、出關(guān)處理、準備進口貨運指示、入關(guān)處理、以及交貨證明等功能。與本發(fā)明各方面有關(guān)的所支持的單據(jù)包含貨運單據(jù)創(chuàng)建與跟蹤、檢查、裝箱單生成、貨運指令、以及商業(yè)單據(jù)。結(jié)算功能列表103，即513，支持諸如發(fā)票處理與信用證處理等功能。再次地，該左側(cè)列表框與最上面的框可以用于多種用戶界面。
次上框用于單據(jù)生成，在該例子中用于跟單信用證或信用證?？刂奇溄?12允許用戶預覽正在生成的單據(jù)傳真件或者發(fā)送單據(jù)。提交與取消控制522允許用戶確定是否保留或保存對當前界面進行的編輯。向頁面日志添加注釋面板523允許用戶標注當用戶工作于貨運部分時所編輯的審計軌跡。分配動作面板與當前動作標識符524標識在當前信用證過程中當前負責采取下一步驟的參與者，并且允許用戶重新分配該當前動作或者分配所需的下一動作。批準狀態(tài)面板與當前狀態(tài)標識符525標識當前過程的當前狀態(tài)，并且允許用戶根據(jù)用戶的批準權(quán)限更新該狀態(tài)。選項卡(tabs)526允許直接訪問與信用證處理有關(guān)的用戶界面，包含“匯總”、“詳情”、“各方”、“條款”、“修改”、以及“頁面日志”。頁面日志顯示上述對于信用證處理的審計軌跡。以下進一步描述其余選項卡。
信用證界面的主要部分跨越圖5A-E。準備過程中的最近的信用證單據(jù)表示為531。這可以是指示、申請、或者修改，或者其可以是信用證本身。指示/申請/修改號碼與日期顯示為532。信用證與信用證通知號碼與日期，與包含信用證類型、到期日、金額、幣種的匯總信息一道，列為533。對于申請，標識申請人與開證行，與請求開立與到期日期、到期地點、以及是否需要請求確認一道，為534。在圖5B顯示的界面部分，提供了有關(guān)于信用證約定各方的進一步信息，包含申請人541、受益人542、開證行543、以及通知行544。在實踐中，這四方是不同的主體；沒有兩方會是“Global ConsigneeInc.”在圖5C所示的界面部分，545-551匯總了銀行543、544以及信用證條款的完成后信息。一組條款545為數(shù)字和大寫金額、百分比信用證增減幅度、以及最大信用額。第二組條款546包含交貨條款(例如INCO條款)、交貨條款地(delivery terms places)、可否議付等等(Availabe with and by)、交單期限、是否允許分批裝運、是否允許轉(zhuǎn)運、哪方支付銀行費用、哪方支付運費、哪方支付保險費、以及哪方支付其他費用。就費用由申請人支付而言，這些費用可以不顯示為信用證條款，因為其不會為受益人強加需要滿足的條件。標識信用證的付款到期日(tenor)547與付款人(drawee)548?？梢灾付ɑ旌细犊罨蜓悠诟犊畹奶厥鈼l款549。一組裝運細節(jié)550包含起運地、經(jīng)過地以及目的地、最遲裝運日期與裝運期限。指定貨物和/或服務描述511，其會進入其他銀行所需的單據(jù)。在圖5D所示的界面部分，指定銀行所需單據(jù)560。在該例子中，需要兩份正本商業(yè)發(fā)票以及一份副本。需要一份正本裝箱單與兩份副本，以及提單、匯票(bill of exchange)以及其他單據(jù)的額外拷貝。對于一般的不一定為信用證條款的信息，指定收貨人(consignee)與被通知方570、572。可以輸入并記錄對于信用證的附加條件580、特殊指示581、以及銀行備注582。一組匯總修改信息590包含信用額(credit amount)的增或減、以及產(chǎn)生的新的信用額、加上新到期日。在實踐中，修改可能產(chǎn)生信用額的增或減。新的信用額590將與金額的增或減590一道伴隨信用證金額533。在圖5E所示的界面部分，顯示信用證的修改文本或者修改描述。
圖6-9提供了相應于圖5A-E中匯總的數(shù)據(jù)的數(shù)據(jù)輸入字段。在這些圖中，遵循方便與邏輯的原則將數(shù)據(jù)分組。在圖6中，提供對于模板的支持627、628，該支持在圖5中不明顯?？梢赃x擇現(xiàn)有模板627或者創(chuàng)建新模板628。當已經(jīng)完成并提交數(shù)據(jù)輸入時522，可以創(chuàng)建新模板。在圖6中，用戶選擇是否創(chuàng)建指示、申請、或者更改。還可以允許用戶選擇從銀行開立的跟單信用證或信用證人工輸入，這在圖中沒有顯示。與該用戶界面相關(guān)聯(lián)可以有進行以下工作的效用上傳PDF文件、下載傳真或電子版本數(shù)據(jù)、打印、預覽、傳真、或者允許由非準備該單據(jù)的某人批準該單據(jù)?？梢灾С钟糜谫I方與賣方的不同視圖，這允許一方控制在該方具有獨占控制權(quán)的字段中輸入數(shù)據(jù)，例如其對收貨人或者運輸行的選擇。對于買方或者賣方，可以支持以下工作流其中不同于輸入這些數(shù)據(jù)的人批準信用證或者其他單據(jù)。例如，經(jīng)理可以具有批準權(quán)限，而文員只具有創(chuàng)建/修改權(quán)限。圖6中的大部分字段也在圖5中出現(xiàn)，并且被相應地標號。在圖7-9中，對所有出現(xiàn)的字段與圖5一致地標號。為了減少視覺上混亂，圖6-9中省略了最頂部的框與左側(cè)列表框。為了呈現(xiàn)一致的視覺外觀，圖6-9中的界面可以如圖5那樣劃框。預期在該申請中顯示的所有界面都將被國際化，包含對于講英語、西班牙語、以及日語的人的支持。在與銀行機構(gòu)的合作中，該系統(tǒng)可以用來符合由IndentrusLLC(一全球電子商務信托組織)或者其后繼者或類似組織設立的標準。也可以支持對Thomson Direcotries，包含ThomWeb，以及The Thomson Corporation的其他服務的訪問。
本發(fā)明的一方面包含根據(jù)在DC/LC指示、申請、(多個)修改、或者文件中使用的數(shù)據(jù)自動填充(populate)銀行所需的、與裝運有關(guān)的單據(jù)的字段?？赡苁芤嬗谂cDC/LC同步化的單據(jù)包含提單、規(guī)章符合單據(jù)、出口裝運指示、發(fā)票、以及裝箱單。為了說明某些此類單據(jù)，圖示了用于設立貨運、完成銀行所需的、與裝運有關(guān)的單據(jù)的用戶界面的一個實施例。圖10A-C顯示貨運“timtest003”的設立。該顯示的主要組成部分為導航條1010、貨運描述信息1020、按照裝運階段的匯總狀態(tài)信息1030、審計軌跡日志1040、訪問模板1045與提醒1046、對于各種參與者的設立(包含出口商1050、進口商1055、出口運輸行1060、進口運輸行1065、以及海關(guān)經(jīng)紀人1070)、以及對于裝運單據(jù)的標識的需求準備1075。貨運描述信息1020包括裝運號、預期出發(fā)日、預期到達日、船名/船次(如果適用的話)、提單或空運單號、起運地、目的地、以及航班/日期(如果適用的話)。以上描述了裝運階段類目與狀態(tài)圖標。通過點擊相應的圖標，察看者可以從該屏幕導航至用于不同階段的屏幕。裝運日志1040顯示審計軌跡的至少一部分。審計軌跡記錄重大事件(significantevent)的日期、時間、以及參與者。重大事件可以包含單據(jù)的創(chuàng)建、編輯、以及批準，或者跟蹤裝運狀態(tài)的數(shù)據(jù)或者由參與者進行的明示狀態(tài)變化，如下詳細所述。在設立顯示屏幕上，可以過濾審計軌跡事件，并且只顯示那些有關(guān)于設立的，諸如“設立完成”的事件。例如，比較在圖16A的貿(mào)易索引裝運日志1640上或者在圖17A的預訂信息頁面日志1740上顯示的事件。
返回到設立顯示屏幕上，塊1045、1046允許選擇模板以及提醒配置?？梢越⒛０鍋硐蜓b運參加者分配身份或訪問權(quán)限。模板為節(jié)省對于與預先建立的路徑相關(guān)聯(lián)的訪問權(quán)限的決策的簡便方式。通過配置提醒框，可以配置、察看、或者修改提醒1046。提醒是與某事件相關(guān)聯(lián)(key to)的備忘錄(tickler)。其可以與該事件的預期日期相關(guān)聯(lián)、與該事件之前的防范(prudent)時間相關(guān)聯(lián)、或者與該事件之后的某時間相關(guān)聯(lián)。該事件可以對應于該備忘錄的名稱，或者其可以是不同的相關(guān)事件。例如，可能在海運集裝箱(oceangoing container)最終到達日期(drop-off date)之前一周要求裝運單據(jù)。如果在該一周里程碑前沒有完成裝運單據(jù)，則在各種概括視圖或者詳情顯示屏幕上出現(xiàn)提醒。
這些圖10A-C還顯示對各種潛在參與者的設立。對于特定裝運，不需要設立所有參與者。例如，當按慣例進口運輸行作為海關(guān)經(jīng)紀人時，可能不需要在該詳細顯示屏幕中包含所有參與者。對于出口商1050的設立包含選擇出口商。在以管理員的身份設立出口商之后，出口商可以從選擇列表中選擇。在該例子中，向出口商分配了創(chuàng)建、更改、以及批準在與出口有關(guān)的階段進行的動作的權(quán)限，并且經(jīng)過進口商1055的批準，具有修改在與進口有關(guān)的階段中的動作的權(quán)限。類似地，設立進口商1055包含選擇進口商，以及分配對于每個裝運階段類目的權(quán)限。該進口商對于進口裝運指示以及交貨證明/進口狀態(tài)信息具有創(chuàng)建、更改、以及批準權(quán)限。設立出口運輸行1060、進口運輸行1065、以及海關(guān)經(jīng)紀人1070一般遵循對進口商或出口商的設立，但是有一項重要的例外。例如，當出口商設立貨運時，出口商將設立出口商與進口商兩者，但是可以將進口運輸行1065或者海關(guān)經(jīng)紀人1070的設立交給進口商1055決定。進口商經(jīng)出口商同意可能具有創(chuàng)建這一部分設立、或者輸入數(shù)據(jù)的權(quán)限。更一般地講，出口商或進口商可能將對于其相應方的代理的設立交給其相應方?jīng)Q定。該詳細顯示屏幕中另一部分支持設立裝運單據(jù)1075。貨運單據(jù)可以用作各種功能，例如滿足海關(guān)要求、政府要求、銀行要求，滿足健康、安全、或者環(huán)境規(guī)章，或者滿足合同條款。具備這些以及其他功能的貨運單據(jù)可能包含發(fā)票、裝箱單，以及另一套，包含9802工作單(Worksheet)、空運單、拼箱聲明(Assembler’s declaration)、經(jīng)紀發(fā)票、加拿大特殊海關(guān)發(fā)票(Canadian Special Customs Invoice)、分析證(Certificate ofAnalysis)、檢驗證(Certificate of Inspection)、保險證(Certificate ofInsurance)、產(chǎn)地證(Certificate of Origin)、重量證(Certificate ofWeight)、CF 3461、CF 7501合格證(Compliance Certification)、危險物品聲明(Declaration of Dangerous Goods)、交貨單(Delivery Order)、國內(nèi)裝運發(fā)票(Domestic Trucking Invoice)、運輸行發(fā)票(ForwarderInvoice)、熏蒸消毒證(Fumigation Certificate)、MSDS、加工廠證(MillCertificate)、NAFTA證、海運提單(Ocean Bill of Lading)、物理檢驗證(Physical Inspection Certificate)、提單證明(Proof Bill of Lading)、交貨證明(Proof of Delivery)、以及紡織品聲明(Textile Declaration)?？赡苓€需要上傳和配發(fā)其他的海關(guān)單據(jù)。當設立中需要單據(jù)時，概括狀態(tài)顯示屏幕以及其他詳情顯示屏幕中的同步字段會跟蹤至所需單據(jù)完成的進展。匯總單據(jù)管理狀態(tài)1043反映所有所需貨運單據(jù)是否都完成了。該詳情顯示屏幕還允許將設置保存為模板1081、更改(確認)1082對輸入顯示屏幕的字段中的數(shù)據(jù)或者取消1083輸入到字段中的更新。
圖10D-G顯示重新組織了在圖10A-C中出現(xiàn)的特征的結(jié)算設立的第二個實施例。在該實施例中，可以將結(jié)算模塊作為獨立的產(chǎn)品發(fā)送，例如沒有訂單模塊。圖10D為初始設立屏幕，可以從該屏幕添加參加者，并且可以將特定單據(jù)包含在貿(mào)易中。圖10E顯示結(jié)算設立的單據(jù)選項卡。在該屏幕中，可以指定對單據(jù)的要求以及上傳附件。圖10F顯示結(jié)算設立的所設的提醒選項卡。在系統(tǒng)表中聲明了多個提醒條件，并且可以在該設立屏幕中使用。針對與特定單據(jù)相關(guān)的觸發(fā)條件，可以選擇提醒，并且指定時機。為了設立提醒，可以使用模板?？梢詫⑻嵝训奶囟ㄅ渲帽４鏋槟０?。圖10G顯示設立參加者以及參加者權(quán)限。從圖10D的添加參加者按鈕達到該屏幕。
圖11A-B允許輸入發(fā)票。該顯示屏幕的主要組成部分包含如圖10A中所出現(xiàn)的導航條1110、貨運描述信息1120、匯總狀態(tài)信息1130、以及審計軌跡日志1140。主要組成部分還包含典型發(fā)票信息1151-55、集裝箱及裝箱信息1156、付款條款信息1157-59、以及有關(guān)于該貨運階段中進一步處理的信息1160。典型發(fā)票信息包含買方與賣方參考號1151。該典型信息還包含1152發(fā)票號碼與日期、提單或空運單號碼與日期、以及裝運日期、付款到期日、以及交貨日期。可以輸入顧客、買受方(sold to(賣給))、付款人、裝運目的方(ship to(發(fā)貨給))的名稱與地址1153。付款與裝運信息1154包含付款方法與匯寄目的方(remit to(匯寄給))、裝貨與卸貨地點、(如果適合的話)船名與船次、以及(如果適合的話)航班與日期?？梢圆炜串a(chǎn)品信息1155，并且在某些實施例中可編輯該信息。裝備(equipment)信息顯示為1156。與付款相關(guān)的信息可以包含付款條款1157、交貨條款1158、以及信用證號與備注1159?？梢暂斎腩櫩蛻{條(customer notes)與特殊指示。與該裝運階段中進一步處理相關(guān)的信息包含對于負責朝向該階段完成的下一動作的裝運參加人的指示1160。在該例子中，箭頭指向出口商。如果當前任務是該參與者的責任，則會在取消按鈕旁邊出現(xiàn)通知按鈕。選擇該通知按鈕將通過電子郵件或傳真通知提醒下一個負責的裝運參加者，并且“控制板”圖標從棕色“處理中”箭頭變?yōu)榫G色“待作”框。選擇該通知按鈕將提醒下一個負責的裝運參加者，并且將在頁面日志中創(chuàng)建輸入項。如果察看者具有批準該發(fā)票的權(quán)限，則在取消按鈕旁邊出現(xiàn)完成按鈕。在某些實施例中，可能在選擇了完成按鈕之后出現(xiàn)更改按鈕，以允許具有權(quán)限的參與者解除對該發(fā)票的完成動作。
圖11C-K顯示發(fā)票輸入用戶界面的替換實施例。圖11C-E顯示該替換實施例的發(fā)票GUI的匯總選項卡。圖11F-G顯示該發(fā)票GUI的詳情選項卡。圖11H-I顯示該發(fā)票GUI的產(chǎn)品選項卡。圖11J-K顯示該發(fā)票GUI的頁面日志選項卡。
圖12A允許輸入裝箱單。該顯示屏幕的主要組成部分包含如圖10A中所出現(xiàn)的導航條1210、貨運描述信息1220、匯總狀態(tài)信息1230、以及審計軌跡日志1240。主要組成部分還包含與其他屏幕同步的信息1251-54、裝箱單信息1255、裝備信息1256、以及有關(guān)于該貨運階段中進一步處理的信息1960。與其他屏幕同步的信息包含賣方參考號、發(fā)票與提單或空運單號1251、顧客1252、提單或空運單、發(fā)票以及裝運日期1253、以及運輸與信用證信息1254。在該例子中，裝箱單信息1255包含行號(line item sequence no)、產(chǎn)品ID與產(chǎn)品描述、集裝箱(container)與集裝箱封印標識(container sealidentification)、批次(lot no.)、取貨地(pickup location)、包ID(packageID)、數(shù)量(quantity)、包裝(packaging)、單位重量(unit weight)、凈重(netweight)、毛重(gross weight)、以及區(qū)別標記與號碼(distinguishing marksand numbers)。裝備信息顯示為1256。還有一系列開放字段，用戶可以在其中為每個產(chǎn)品信息行輸入可選或附加信息。雖然在該屏幕照片上未顯示、但是當信息為可更改形式時存在的有三個功能按鈕添加行、下載模板、上傳模板?！疤砑有小痹试S用戶在裝箱單中創(chuàng)建另一行。“下載模板”允許用戶將模板以Excel或其他形式下載到其本地系統(tǒng)，其允許用戶手工輸入或“剪切和粘貼”裝箱單信息到標準格式，該標準格式可以被轉(zhuǎn)換為可以上傳到該系統(tǒng)中的數(shù)據(jù)格式?！吧蟼髂０濉痹试S用戶將模板上傳到裝箱單中，由此創(chuàng)建新行。有關(guān)于該貨運階段中進一步處理的信息包含對于負責朝向該階段完成的下一動作的裝運參加人的指示1260。在該例子中，箭頭指向出口商。在該圖中沒有取消按鈕，該取消按鈕在參與者在該顯示屏幕中輸入任何信息之前存在。如果已經(jīng)在該圖中輸入了信息，則將在取消按鈕旁邊出現(xiàn)通知按鈕。選擇該通知按鈕將提醒下一個負責的裝運參加者。如果察看者具有批準該裝箱單的權(quán)限，則在取消按鈕旁邊出現(xiàn)完成按鈕。在某些實施例中，可能在選擇了完成按鈕之后出現(xiàn)更改按鈕，以允許具有權(quán)限的參與者解除對該發(fā)票的完成動作。
圖12B-I顯示裝箱單用戶界面的替換實施例。圖12B-I顯示該替換實施例的裝箱單GUI的匯總選項卡。圖12B-C顯示匯總選項卡。圖12D-E顯示該裝箱單GUI的詳情選項卡。圖12F-G顯示產(chǎn)品選項卡。圖12H-I顯示該裝箱單GUI的頁面日志選項卡。
圖13A-B允許輸入有關(guān)于提單或空運單的信息。該顯示屏幕的主要組成部分包含導航條1310、貨運描述信息1320、匯總狀態(tài)信息1330、以及審計軌跡日志1340。主要組成部分還包含狀態(tài)信息1351、承運人(carrier)名稱與提單或空運單號碼1352、委托人(shipper)名稱、預定號碼與出口參考號1353、收貨人(consignee)與貨運代理(forwarding agent)名稱與地址1354、起運地點或國家1355、通知方與指示1356、來自第三方出口系統(tǒng)的AES XTNNo.1357、裝貨碼頭與移動類型(loading pier terminal and type ofmove)1358、運費條款1359、其他裝運信息1361-1362、以及有關(guān)于該貨運階段中進一步處理的信息1360。在該例子中，狀態(tài)信息指示是否要已經(jīng)收到并且上傳了提單或空運單的證據(jù)(proof)與最終版本。在上傳之后，就可下載提單的證據(jù)或最終版本。例如，該提單不能由出口商準備或者至少不能由其批準，因為該提單承認運輸公司已經(jīng)收到了貨物，并且作為此運輸目的的標題。附加裝運信息可以包含前程運輸(pre-carriage)、接貨地點或港口、裝貨卸貨以及船名/船次或航班/號碼信息1360、交貨地點1361、以及裝備信息1362。有關(guān)于該貨運階段中進一步處理的信息包含對于負責朝向該階段完成的下一動作的裝運參加人的指示1370。在該例子中，箭頭指向出口商。如果在該圖中輸入了信息，則會在取消按鈕旁邊出現(xiàn)通知按鈕。選擇該通知按鈕將提醒下一個負責的裝運參加者。如果察看者具有批準該發(fā)票的權(quán)限，則在取消按鈕旁邊出現(xiàn)完成按鈕。在某些實施例中，可能在選擇了完成按鈕之后出現(xiàn)更改按鈕，以允許具有權(quán)限的參與者解除對該發(fā)票的完成動作。
圖13C-L顯示提單用戶界面的替換實施例。圖13C-E顯示匯總選項卡。圖13F-H顯示該提單GUI的詳情選項卡。圖13I-J顯示產(chǎn)品選項卡。圖13K-L顯示該提單GUI的頁面日志選項卡。
DC/LC系統(tǒng)最好支持報告。標準報告可以包含LC狀態(tài)報告。此類報告可能包含所有或部分的LC號碼、LC日期、賣方名稱、買方名稱、LC到期日、發(fā)票號、海運提單號、提單號、以及系統(tǒng)管理員選擇的其他字段。也可以支持臨時(ad-hoc)報告。應該允許對標準報告進行基于參數(shù)的搜索，其包含與上述所列字段不同的字段作為參數(shù)。作為參數(shù)的起止日期將允許過濾信息。報告的基本功能可以包括按照不同列排序、打印、通過選擇特定交易/超鏈接(例如發(fā)票號等等)而深入到(drilling down)實際的單據(jù)/交易、以及根據(jù)訪問控制權(quán)限允許從該屏幕訪問以編輯相應單據(jù)。
對于DC系統(tǒng)的管理方面的支持應該符合該DC系統(tǒng)所運行的環(huán)境。可以預測將提供支持來設立域(domain)、公司、貿(mào)易、經(jīng)理、以及用戶的角色。還應該將用戶與角色相關(guān)聯(lián)。用戶對于DC/LC系統(tǒng)可能具有的權(quán)限(permissions)包括創(chuàng)建LCI、更改LCI、察看LCI、以及刪除LCI；創(chuàng)建LCApp、更改LCApp、察看LCApp、以及刪除LCApp；確認LC；上傳和管理單據(jù)以及發(fā)送所管理的單據(jù)；創(chuàng)建LCAmend、更改LCAmend、察看LCAmend、以及刪除LCAmend；察看報告，創(chuàng)建Party Master(一方主管)、更改PartyMaster、以及察看Party Master。
可以如下定義DC/LC準備的階段以及準備階段中的狀態(tài)第一階段——指示；第二階段——申請；第三階段——修改。考慮到LC的性質(zhì)，用戶不應該能夠返回到前一階段。如果早些的階段未完成，則應該在后繼階段開始之前完成或取消它。安全設置應該定義用戶對于每個階段以及階段內(nèi)的狀態(tài)的權(quán)限和特權(quán)。用戶應該能夠向指定的人員、管理者或者下一動作期間的貿(mào)易伙伴聯(lián)系人發(fā)送通知，尤其是針對LC的所需單據(jù)。應該允許用戶應用或保存模板。上述每個階段中的狀態(tài)為指示——進行中或完成；申請——進行中、完成、或已確認；以及修改——進行中或完成。
該系統(tǒng)可以根據(jù)用戶角色區(qū)分用戶，例如創(chuàng)建草本DC/LC申請的不同人員以及批準申請以發(fā)送給銀行的人員。對于各種單據(jù)來說，不同的工作流、提醒、以及通知可能是適當?shù)?。對于LC指示，代表賣方的某人準備它并且將其發(fā)送給買方?？梢灾С止芾碣u方活動的第二人進行中間批準。由系統(tǒng)就LCI提醒買方。對于LC申請，代表買方的某人準備它并且將其發(fā)送給賣方。在賣方評論或編輯申請、并且將其與修改一道發(fā)送給買方的意義上，賣方在發(fā)送給銀行的申請的準備過程中進行合作。當買賣雙方尋求對于條款的一致時，可能反復申請的準備。代表買方的某人將商定的申請發(fā)送給表示買方的管理人員進行批準。該買方管理人員將已完成的經(jīng)批準的申請發(fā)送給買方的開證行。可以提醒買賣雙方已經(jīng)將LCApp傳送給了銀行，并且其已經(jīng)被開證行批準。更一般地說，對于買賣雙方的、關(guān)于申請動作的通知將是基于事件的。對于LC修改，買方(或者賣方)準備草本修改。買賣雙方就修改條款進行合作。將商定的修改發(fā)送給買方管理經(jīng)理進行批準并且傳送給開證行?？梢曰谑录?qū)動就LCAmend處理提醒買賣雙方。上述圖10F顯示了提醒的設立。
涉及有關(guān)于銀行的信息的任何系統(tǒng)也應該關(guān)心安全性?？梢栽谝韵氯我患墑e或者適當?shù)钠渌墑e上建立安全性。初始級別(initiation level)的安全性可以規(guī)定誰有權(quán)限設立LC，并且該初始級別的安全性應該在用戶/公司級別上控制。關(guān)聯(lián)級別(association level)的安全性可以指示誰可以察看LC信息，并且將其與特定貿(mào)易相關(guān)聯(lián)。下游貿(mào)易級別(downstream trade level)的安全性可以在用戶/貿(mào)易級別上控制，而且當發(fā)生貿(mào)易設立時將授予該訪問權(quán)限。
可以使用常規(guī)集成技術(shù)或者任意新發(fā)明的技術(shù)將DC/LC系統(tǒng)或者包含DC/LC系統(tǒng)的進-出口系統(tǒng)與ERP或者EAI銷售商的遺留應用程序集成。集成可能包括允許以XML、EDI、.txt、ASCII、以制表符分割、csv或者類似格式上傳與下載。
同步規(guī)則定義來自信用證的數(shù)據(jù)如何被傳播給其他單據(jù)，包含銀行所需單據(jù)以及與貨運有關(guān)的單據(jù)。更一般地講，同步規(guī)則定義如何將數(shù)據(jù)從一個單據(jù)傳播到其它單據(jù)。圖14為本發(fā)明一個實施例的一組同步規(guī)則的一部分。這些規(guī)則的子集也實現(xiàn)本發(fā)明，并且可能是有用的。圖14中的某些規(guī)則有關(guān)于DC/LC系統(tǒng)運行其中的環(huán)境，并且應用本發(fā)明不限于DC或LC。通過將其與域Id(未顯示)相關(guān)聯(lián)，可以將在圖14中所示的規(guī)則應用到任何領域，或者應用到選定領域。來源與目的單據(jù)類型為字段出現(xiàn)其中的單據(jù)類型。這些單據(jù)類型可以包含上面或者所引入的申請中所述的單據(jù)類型。字段名稱為字段的名稱，例如圖5匯總或者圖6-9的輸入表單中的字段。來源與目的單據(jù)狀態(tài)指示應用該規(guī)則的單據(jù)準備的條件。在一個實施例中，這些狀態(tài)被編碼為新1；處理中2；中斷(On-Hold)3；完成4；已取消5；被鎖定6；等待批準7；已批準8；已確認9；不存在0；以及任意1。有時可以通過應用到多個狀態(tài)或者通過一般化將觸發(fā)規(guī)則搜索或者應用規(guī)則的狀態(tài)變遷來簡化這些規(guī)則?！案路秶绷兄甘緦τ谧侄芜M行的更新的范圍。在該例子中，范圍為1、2、或3，對應于一綜貿(mào)易、一個服務模塊、或者跨貿(mào)易與跨模塊。根據(jù)為本發(fā)明選擇的確切的軟件實施例，可以將不同的范圍應用于更新。在DC或LC為一種付款形式的環(huán)境中，可能有其中沒有相關(guān)聯(lián)的DC或LC的交易。相應地，在規(guī)則之間具有冗余，從而如果沒有LC與交易相關(guān)聯(lián)，則可以指定替換規(guī)則。前提條件“LOCTradeExists”對應于在LC與交易相關(guān)聯(lián)的情況下推翻(override)其他規(guī)則的規(guī)則。
為了觀察同步規(guī)則的具體實例，考慮第一個信用證到提單規(guī)則。當完成信用證并且提單正在朝向完成的處理中時，應用該規(guī)則。Beneficiary-address1(受益人地址)字段從信用證拷貝到提單的shipper-address1(委托人地址)字段。該映射確保將最新的信用證信息用于準備委托人可能確認或者采納的估價提單。類似地，當收到或批準信用證、并且提單正在處理中時，第二個規(guī)則映射相同的文件。目的單據(jù)字段的灰色陰影指示系統(tǒng)防范正在準備提單的用戶推翻信用證的措詞。可以將這種防范實現(xiàn)為禁止改變字段、基于人物角色的禁止、或者需要明示推翻、并且將該推翻記錄在審計軌跡中的警告。該規(guī)則的更新范圍為跨貿(mào)易。
同步的一種動因在于信用證一般要求完成許多單據(jù)，以證明買賣雙方已經(jīng)有效完成交易達到各方(自身、顧客、承運人等等)滿意的程度。需要完成與附加這些單據(jù)才能讓度資金(release fund)。支持以下單據(jù)是有用的，這些單據(jù)有時用作交易已經(jīng)完成的證明檢驗證、保險證、海運提單(Ocean Billof Lading)、空運單、發(fā)票、提單(Bill of Lading)、匯票副本、以及產(chǎn)地證。LC將指定需要這些單據(jù)的哪些作為單據(jù)證明。當創(chuàng)建LC時，應該指定必須完成的所需單據(jù)。作為這些單據(jù)被“鏈接”到LC的結(jié)果，將應用有關(guān)于下游單據(jù)創(chuàng)建以及業(yè)務規(guī)則的業(yè)務邏輯。
在不支持所有單據(jù)或者不支持LC所需的定制單據(jù)(custom documents)的情況的，支持幾種單據(jù)是有用的。例如，支持發(fā)票、提單/空運單、以及海運提單是有用的。雖然這些單據(jù)的這些字段應該與LC同步，但是由于在貿(mào)易過程中發(fā)生的業(yè)務處理錯誤也可能有差異。一個例子為發(fā)票，其指示不同于LC的買方名稱的不同拼寫。允許有意地推翻這些差異是有用的，因為這些差異可能代表了在現(xiàn)實世界或者其他記錄系統(tǒng)中實際發(fā)生的事情。尤其是如果LC數(shù)據(jù)是從另一第三方來源上傳的，而不是作為LC申請基礎輸入的，則應該注意對于特定LC，是否應該推翻用于買方名稱等等的系統(tǒng)值。
某些字段應該跨越這些單據(jù)共享。對于發(fā)票準備，進-出口情況分析指示應該根據(jù)LC同步買賣雙方姓名及地址，而不管LC正確與否，除非LC被明示地推翻，或者LC數(shù)據(jù)可疑。應該同步銷售條款，包含銷售條款地(FOBCharlseton)。貨物描述應該準確匹配LC，但是可以包含添加的細節(jié)?？梢栽诎l(fā)票上可選地列出LC號碼與開立日期。對于提單的準備，應該根據(jù)LC同步買賣雙方姓名及地址。起運地、目的地名稱與地址(如果有的話)應該匹配其他單據(jù)與LC。件數(shù)、重量、尺寸、立方(cube)應該匹配其他單據(jù)與LC。在提單中，貨物描述只需要一般地匹配LC，并且可以包含添加的細節(jié)?？商鎿Q地，其可以匹配LC或者在具有附加細節(jié)字段的情況下匹配LC?？梢栽谔釂紊峡蛇x地列出LC號碼與開立日期。對于BL/AWB的準備，委托人應該默認為賣方(受益人)，并且具有改變以匹配LC中字段的選項?？梢粤谐鍪肇浫伺c通知方，并且其應該與提供給銀行的任何信息(這樣的信息可以是可選的，并且不是LC部分(即使被包含在申請表單上))一致。BL/AWB上的件數(shù)、重量、以及立方應該匹配提單與LC。貨物描述應該一般地匹配LC，并且可以包含航運公司/空運公司所需的添加細節(jié)?？商鎿Q地，其可以匹配LC或者在具有附加細節(jié)字段的情況下匹配LC。可以在BL/AWB上可選地列出LC號碼與開立日期。在BL/AWB上的運費，包含費用是預付、收到即付、還是到目的地付款，不應該與LC及發(fā)票不一致。收貨地、裝貨港、卸貨港、轉(zhuǎn)運目的地(transship to)、以及起運國家與地點不應該與LC不一致。其他承運人注釋應該如LC所指示的那樣出現(xiàn)。
在偶然情況下，LC可能使用不同的單據(jù)首部或標題，例如提單。所生成的單據(jù)的單據(jù)標題應該匹配LC，包含上述稱為商業(yè)發(fā)票、提單、重量單、檢驗證等等的單據(jù)。正本單據(jù)應該在標題附近標注“正本”或者等同表達字樣，因為正本與副本經(jīng)常是來自同一打印機的相繼打印的復制件，而不是來自多部分形式的碳寫本(carbons from multi-part form)。所有生成的單據(jù)都應該具明日期，并且在其上出現(xiàn)的日期不應該其它單據(jù)或信用證不一致。
圖15顯示可以用來聲明以及生成系統(tǒng)能夠生成的單據(jù)的合并(merge)格式。從系統(tǒng)數(shù)據(jù)合并到該單據(jù)中的字段由尖括號<...>以及尖括號之間的字段名稱指示。該信件的文本依賴于在系統(tǒng)操作員與收信人之間建立的關(guān)系。類似的合并格式可能對于匯票、起運地海運與空運證明、檢驗證、海運與空運保險通知、輸入系統(tǒng)的承載注釋的信件、空運單、發(fā)票、多次裝貨的單證(billof ladings)、裝貨的多張單證(bills of lading)、受益人證、重量單、以及類似單據(jù)有用。使用聲明式或者合并格式允許非程序員的人員向系統(tǒng)添加單據(jù)類型，而不要求對單據(jù)的硬編碼。
當將數(shù)據(jù)輸入系統(tǒng)時應用的有效性驗證規(guī)則可能是有用的。
根據(jù)上述內(nèi)容，本領域技術(shù)人員顯然可以理解根據(jù)本發(fā)明的各個方面以及組成部分可以構(gòu)造各種系統(tǒng)與方法。本發(fā)明的一個實施例包含一種生成跟單信用證以及相關(guān)單據(jù)的方法?？蛇x地，可以將該方法實現(xiàn)為系統(tǒng)或者執(zhí)行該方法步驟的系統(tǒng)。該系統(tǒng)或者設備可以包含組合該方法的各個步驟、方面、選項以及替換實施例的幾個實施例。該方法也可以實現(xiàn)為磁介質(zhì)，該介質(zhì)印有執(zhí)行該方法的步驟的程序。該程序可以包含組合該方法的各個步驟、方面、選項以及替換實施例的幾個實施例。該生成跟單信用證以及有關(guān)單據(jù)的計算機輔助方法可以包含提供至少一個用于跟單信用證開立的模板以及一個或多個用于與跟單信用證有關(guān)的單據(jù)的模板。跟單信用證開立單據(jù)可以是跟單信用證指示、跟單信用證申請、或者跟單信用證文件中的一個、兩個、或者所有的任意組合。與跟單信用證有關(guān)的單據(jù)為銀行按照相應跟單信用證文件付款所需的多個單據(jù)中的單據(jù)。該方法還包含從跟單信用證開立模板映射字段到與跟單信用證有關(guān)的單據(jù)模板，以及接受對于跟單信用證開立模板中至少某些字段的數(shù)據(jù)。根據(jù)本發(fā)明的一個實施例，該方法還包含利用該映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段。
在本發(fā)明的另一實施例中，前一實施例側(cè)重于準備草本跟單信用證指示或者跟單信用證申請。該草本中的至少某些條款被從第一方傳遞到第二方，其中第一方與第二方代表貿(mào)易伙伴。該系統(tǒng)傳遞第二方所作的對于草本的批準或編輯。在開立相應的跟單信用證文件之前，并且最好在向開證行提交跟單信用證申請之前，該系統(tǒng)記錄第一與第二方有關(guān)草本條款的協(xié)議。
可以獨立實現(xiàn)或者附加于上述實施例的步驟實現(xiàn)的另一實施例包含提供對于跟單信用證條款修改的至少一個模板。該信用證修改模板被映射到與跟單信用證有關(guān)的模板以及跟單信用證開立模板。接受對于跟單信用證開立模板中至少某些字段的數(shù)據(jù)。利用該映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段?？梢耘c該實施例組合的另一方面涉及關(guān)于修改條款的合作。該合作方面包含將草本跟單信用證修改的至少某些條款從第一方與第二方中的一方傳遞到另一方。該系統(tǒng)接受來自另一方的對于草本修改的批準或編輯。在開立相應的經(jīng)修改的跟單信用證文件之前，并且最好在提交修改請求之前，該系統(tǒng)記錄第一與第二方有關(guān)草本修改的協(xié)議。
與上述任何實施例相結(jié)合地，本發(fā)明的另一方面包含電子提交對于跟單信用證文件或者跟單信用證文件修改的申請。該電子提交方面包含生成機器可讀的跟單信用證申請或者修改申請，并且利用映射填充該申請中的字段。該方法還包含以電子方式將該申請?zhí)峤唤o開證行。這一方面還可以包括接收對于跟單信用證文件開立的確認，以及更新為跟單信用證開立模板提供的數(shù)據(jù)以符合所開立或者經(jīng)修改的跟單信用證文件。
再次地，根據(jù)本發(fā)明的各個方面以及組成部分可以構(gòu)造各種系統(tǒng)與方法。本發(fā)明的一個實施例包含用來生成跟單信用證以及相關(guān)單據(jù)的計算機輔助系統(tǒng)。該系統(tǒng)的元件包含至少一個用于跟單信用證開立的模板以及一個或多個用于與跟單信用證有關(guān)的單據(jù)的模板。
跟單信用證開立單據(jù)可以為跟單信用證指示、跟單信用證申請、或者跟單信用證文件中一個、兩個、或者所有的任意組合。跟單信用證有關(guān)單據(jù)為銀行按照相應跟單信用證文件付款所需的多個單據(jù)中的單據(jù)。該系統(tǒng)還包含將來自跟單信用證開立模板的字段與跟單信用證有關(guān)單據(jù)模板相關(guān)的映射。該系統(tǒng)包含處理對于跟單信用證開立模板中至少某些字段的輸入數(shù)據(jù)、并且利用所述映射填充所述多個跟單信用證有關(guān)單據(jù)中字段的邏輯。
在該系統(tǒng)的另一實施例中，前一實施例側(cè)重于將草本跟單信用證指示或者跟單信用證申請的至少某些條款從第一方傳遞到第二方，其中第一方與第二方代表貿(mào)易伙伴。處理輸入數(shù)據(jù)的邏輯適用于由第二方批準或編輯該草本，并且在開立相應的跟單信用證文件之前，并且最好在提交跟單信用證文件申請之前，該邏輯記錄第一與第二方有關(guān)草本條款的協(xié)議。
可以獨立實現(xiàn)或者附加于上述系統(tǒng)實現(xiàn)的另一實施例包含用于跟單信用證文件條款修改的至少一個模板以及從來自跟單信用證修改模板的字段到跟單信用證有關(guān)單據(jù)模板的另外的映射。該實施例還包括另外的邏輯，用來接受至跟單信用證修改模板中至少某些字段的輸入，以及利用該另外的映射填充跟單信用證有關(guān)單據(jù)中的字段。該實施例的另一方面支持關(guān)于修改條款的合作。在該合作方面，所述用來處理輸入數(shù)據(jù)的另外的邏輯適用于將草本跟單信用證修改的至少某些條款從第一方與第二方中的一方傳遞到另一方。該系統(tǒng)處理由另一方對于草本修改的批準或編輯，并且在開立相應的經(jīng)修改的跟單信用證文件之前，并且最好在提交所提議的修改之前，該系統(tǒng)記錄第一與第二方有關(guān)草本修改條款的協(xié)議。
與上述任一系統(tǒng)實施例相結(jié)合地，本發(fā)明的另一方面包含電子提交跟單信用證申請或者修改申請的邏輯。該實施例還包含利用映射填充跟單信用證申請中的字段并且生成機器可讀的跟單信用證申請的邏輯。然后，該系統(tǒng)以電子方式將該申請?zhí)峤唤o開證行。這一方面還可以包括以下邏輯接收對于原始或者經(jīng)修改的跟單信用證文件的開立的確認，以及更新為跟單信用證開立模板提供的數(shù)據(jù)以符合所開立或者經(jīng)修改的跟單信用證文件。
雖然通過參照上述優(yōu)選實施例與詳細示例公開了本發(fā)明，但是應該理解這些示例出于說明目的，而不是限制意義的。在所述實施例中隱含了計算機輔助處理。相應地，本發(fā)明可以實現(xiàn)為計算機輔助處理的方法、包含進行有關(guān)于DC或LC的多個單據(jù)中字段的同步的邏輯的系統(tǒng)、印有進行有關(guān)于DC或LC的多個單據(jù)中字段的同步的邏輯的介質(zhì)、印有進行有關(guān)于DC或LC的多個單據(jù)中字段的同步的邏輯的數(shù)據(jù)流、或者進行有關(guān)于DC或LC的多個單據(jù)中字段的同步的計算機可訪問服務。本領域技術(shù)人員可以容易地想到各種修改與組合情況，但是這些修改與組合都在權(quán)利要求所限定的本發(fā)明的精神與范圍內(nèi)。
權(quán)利要求
1.一種生成跟單信用證以及相關(guān)單據(jù)的計算機輔助方法，包含提供至少一個用于跟單信用證開立的模板，包含跟單信用證指示、跟單信用證申請、或者跟單信用證文件中的至少一個；提供一個或多個用于與跟單信用證有關(guān)的單據(jù)的模板，其中與跟單信用證有關(guān)的單據(jù)為銀行按照相應跟單信用證文件付款所需的多個單據(jù)中的單據(jù)；從跟單信用證開立模板映射字段到與跟單信用證有關(guān)的單據(jù)模板；接受對于跟單信用證開立模板中至少某些字段的數(shù)據(jù)；以及利用所述映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段。
2.如權(quán)利要求1所述的方法，其中用于跟單信用證開立的模板相應于賣方的跟單信用證指示。
3.如權(quán)利要求1所述的方法，其中用于跟單信用證開立的模板相應于買方的跟單信用證申請。
4.如權(quán)利要求1所述的方法，其中用于跟單信用證開立的模板相應于銀行開立的跟單信用證文件。
5.如權(quán)利要求1所述的方法，其中所述提供數(shù)據(jù)還包含將草本跟單信用證指示或者跟單信用證申請中的至少某些條款從第一方傳遞到第二方，其中第一方與第二方代表貿(mào)易伙伴；由第二方批準或編輯該草本；以及在開立相應的跟單信用證文件之前，記錄第一與第二方有關(guān)草本條款的協(xié)議。
6.如權(quán)利要求1所述的方法，還包含提供用于跟單信用證文件的條款修改的至少一個模板；從跟單信用證修改模板映射字段到與跟單信用證有關(guān)的單據(jù)模板；接受對于跟單信用證修改模板中至少某些字段的數(shù)據(jù)；以及利用所述映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段。
7.如權(quán)利要求6所述的方法，其中所述提供對于跟單信用證修改模板的數(shù)據(jù)還包含將草本跟單信用證修改的至少某些條款從第一方與第二方中的一方傳遞到另一方；由另一方批準或編輯草本修改；以及在開立相應的經(jīng)修改的跟單信用證文件之前，記錄第一與第二方有關(guān)草本修改條款的協(xié)議。
8.如權(quán)利要求1所述的方法，其中所述提供數(shù)據(jù)步驟針對開證前單據(jù)，還包含生成機器可讀的跟單信用證申請，利用映射填充該申請中的字段；以及以電子方式將跟單信用證申請?zhí)峤唤o開證行。
9.如權(quán)利要求8所述的方法，還包含接收對于跟單信用證文件開立的確認；以及更新為跟單信用證開立模板提供的數(shù)據(jù)以符合所開立的跟單信用證文件。
10.一種生成跟單信用證以及相關(guān)單據(jù)的計算機輔助系統(tǒng)，包含至少一個用于跟單信用證開立的模板，包含跟單信用證指示、跟單信用證申請、或者跟單信用證文件中的至少一個；一個或多個用于與跟單信用證有關(guān)的單據(jù)的模板，其中與跟單信用證有關(guān)的單據(jù)為銀行按照相應跟單信用證文件付款所需的多個單據(jù)中的單據(jù)；將來自跟單信用證開立模板的字段和與跟單信用證有關(guān)的單據(jù)模板相關(guān)的映射；處理對于跟單信用證開立模板中至少某些字段的輸入數(shù)據(jù)的邏輯；以及利用所述映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段的邏輯。
11.如權(quán)利要求10所述的計算機輔助系統(tǒng)，其中用于跟單信用證開立的模板相應于賣方的跟單信用證指示。
12.如權(quán)利要求10所述的計算機輔助系統(tǒng)，其中用于跟單信用證開立的模板相應于買方的跟單信用證申請。
13.如權(quán)利要求10所述的計算機輔助系統(tǒng)，其中用于跟單信用證開立的模板相應于銀行開立的跟單信用證文件。
14.如權(quán)利要求10所述的計算機輔助系統(tǒng)，其中所述處理輸入數(shù)據(jù)的邏輯適用于將草本跟單信用證指示或者跟單信用證申請中的至少某些條款從第一方傳遞到第二方，其中第一方與第二方代表貿(mào)易伙伴；由第二方批準或編輯該草本；以及在開立相應的跟單信用證文件之前，記錄第一與第二方有關(guān)草本條款的協(xié)議。
15.如權(quán)利要求10所述的計算機輔助系統(tǒng)，還包含至少一個用于跟單信用證文件條款修改的模板；從跟單信用證修改模板映射字段到與跟單信用證有關(guān)的單據(jù)的模板的另一映射；接受對于跟單信用證修改模板中至少某些字段的輸入的另一邏輯；以及利用所述另一映射填充所述多個與跟單信用證有關(guān)的單據(jù)中的字段的另一邏輯。
16.如權(quán)利要求15所述的計算機輔助系統(tǒng)，其中所述處理輸入數(shù)據(jù)的另一邏輯適用于將草本跟單信用證修改的至少某些條款從第一方與第二方中的一方傳遞到另一方；由另一方批準或編輯草本修改；以及在開立相應的經(jīng)修改的跟單信用證文件之前，記錄第一與第二方有關(guān)草本修改條款的協(xié)議。
17.如權(quán)利要求10所述的計算機輔助系統(tǒng)，其中所述處理輸入數(shù)據(jù)的邏輯針對開證前單據(jù)，還包含利用映射填充跟單信用證申請中的字段、以及生成機器可讀的跟單信用證申請的另一邏輯；以及以電子方式將跟單信用證申請?zhí)峤唤o開證行的邏輯。
18.如權(quán)利要求17所述的計算機輔助系統(tǒng)，還包含接收對于跟單信用證文件開立的確認的邏輯；以及更新為跟單信用證開立模板提供的數(shù)據(jù)以符合所開立的跟單信用證文件的邏輯。
全文摘要
提供了一種支持進出口交易的系統(tǒng)與方法。在買方(301)、賣方(302)、開證行(311)和通知行(312)之間建立通信。在步驟(321)，賣方(302)創(chuàng)建信用證指示并將其以電子形式發(fā)送到買方(301)。在步驟(322)，買方創(chuàng)建信用證申請并將其發(fā)送到賣方(302)。各種通信在這些交易方之間發(fā)生并且最終，在步驟(326)，通知行將信用證發(fā)送給賣方(302)。
文檔編號G06Q10/00GK1739115SQ200380108206
公開日2006年2月22日 申請日期2003年10月29日 優(yōu)先權(quán)日2002年11月4日
發(fā)明者馬諾杰·納拉延, 史蒂夫·M·維亞倫戈, 艾倫·R·博恩朔伊爾 申請人:貿(mào)易杠桿股份有限公司