专利名称：产生跟单信用证并符合货运单据的制作方法
技术领域：
本发明涉及支持进出口交易的系统与方法。更具体地，涉及生成与跟单信用证文件(documentary credit instrument)一致的银行所需单据以及合作的(collaborative)跟单信用证文件的申请或修改的方法与系统。
背景技术：
跟单信用证文件，包含信用证，长期被用来确保对卖方或供应方付款，尤其是当买方距离远(国际交易)或与卖方没有持续关系时。一般地，买方向买方与其具有银行关系的开证银行请求开立跟单信用证文件，有时利用如图4A-D所示的申请书。经常在买方请求开证之前，买方与卖方议付跟单信用证文件的条款。开证行将有效信用证文件发送给通知行。依赖于并且根据跟单信用证，买方发货(ship goods)。如果需要修改，买方与卖方还议付对跟单信用证文件的修改条款。
人们早就认识到跟单信用证的开立与兑现(redemption)过程充满了出错的机会与结果产生的契约落空(frustration)。例如，在美国专利号6151588中Tozzoli等人在第3栏谈及开证行如何要求信用证中要求的所有单据应该准确地对应于信用证的条款，并且即使是由于打印错误或者轻微的拼写错误，也拒不付款给卖方，从而使要求付款的卖方契约落空。Tradecard公司为上述专利的受让人，其通过创建另类资金机制，来应对这一以及其他长期面临的跟单信用证问题，这一机制描述见于上述专利及可从其网站www.Tradecard.com得到的其”Financial Supply Chain AutomationTheMissing Link in Supply Chain Management White Paper”(2002年4月29日创建的PDF文件)。Tradecard绕过了这些跟单信用证问题，而没有解决它们。
因此，需要发明减少申请、开立和兑现跟单信用证文件中的错误的方法与系统。这样的方法与系统可以利用从跟单信用证模板映射的数据生成兑现跟单信用证银行所需的单据。这样的方法与系统可以鼓励买方与卖方合作准备跟单信用证申请，以及以电子方式提供开证和兑现跟单信用证文件的申请。这样的方法与系统可以鼓励买方与卖方合作准备修改跟单信用证文件的请求。
发明内容
本发明涉及支持进出口交易的系统与方法。更具体地，其包括生成与跟单信用证文件一致的银行所需单据以及合作的跟单信用证文件的申请书和修改书的方法与系统。本发明的具体方面在权利要求、说明书、以及附图中描述。
图1为实现本发明的环境的高级方框图；图2为实现本发明的环境的子系统体系结构的高级方框图；图3显示跟单信用证过程中的参加者；图4A-C为示例跟单信用证申请书，由人工准备，没有应用本发明；图5A-D显示已输入跟单信用证信息的汇总，包含实现本发明的系统环境；图6至9显示输入跟单信用证信息的部分界面；图10显示设置用户界面；图10A-C为用户界面的第一实施方式；图10D-G为第二实施方式；图11显示输入发票的用户界面的两种实施方式；图12显示输入装箱单的用户界面的两种实施方式；图13显示输入有关于海运提单或空运单的信息的用户界面的两种实施方式；图14为本发明一种实施方式的同步规则集合的一部分；图15为系统利用该系统收集的数据而生成的信件的示例格式。
具体实施例方式
以下参考附图进行详细描述。描述优选实施方式用来说明本发明，而非限制其权利要求所限定的范围。本领域技术人员应该理解对以下描述的等价变化。
在通过引用融入的相关申请中描述了很好地融入了跟单信用证过程的环境。所融入的申请描述了对进出口商有用的以从订单直至结算阶段跟踪货物的方法与设备。跟单信用证可以归类作为结算的一部分，但是其在开始货物的任何转移之前安排。如下所述，在货物转移期间利用准确匹配议付(negotiated)跟单信用证的语言生成单据是有用的。
图1-2显示Tradebeam的环境，其中融入了跟单信用证过程。图1为Tradebeam产品的订单、物流后勤(logistics)、以及结算方面的高层方框图。订单模块101支持信用与风险管理、合同协商与履行、对进/出口规章的遵守、以及对销售与购买订单的处理。物流后勤模块102支持许多活动。所支持的活动包含存货控制与配送、追踪与跟踪货运、以及保险规格(insurancespecification)、采购与书面证明(procurement and certification)。与本发明方面有关的所支持的方面包含货运单据创建与跟踪、检查、装箱单生成、装运指令与商业单据。其他物流后勤活动包含准备与生成报关单、以及预定与计划运输。结算模块103支持理赔(OS & Dclaims)、付款处理、运费支付、以及发票处理。另外，其支持作为当前主题的跟单信用证或信用证。
图2显示将Tradebeam环境组织为子系统。这些子系统包括过程管理子系统201、单据管理子系统202、事件管理子系统203、业务智能子系统204、集成子系统205、安全子系统206、贸易设置子系统207、全球化/本地化子系统208、以及个性化子系统209。这些子系统与底层组件可以用来支持跟单信用证活动。
可以依赖于特定的跟单信用证国际标准。用于进/出口的跟单信用证文件应该符合(conform)经常更改的跟单信用证统一惯例(1993修订本，国际商会500号出版物，巴黎，法国)。国际商会(ICC)发布国际认可的管理跟单信用证的规则、定义、以及实践，称为“跟单信用证统一惯例”(UCP)。UCP在世界上所有订阅UCP的银行之间促进信用证与其他跟单信用证文件的标准化。这些规则被不时地更新；最后一次更新在1994年1月1日生效，称为UCP500。人们还希望将DC/LC系统映射到由银行机构SWIFT标准使用的标准字段(field)。对于映射可适用的Swift标准可以包含MT700与MT707。在这些输入画面上显示的字段可以容易地映射到这些标准。
跟单信用证为用来覆盖几种相关类型的金融文件的名词。ICC与银行组织的SWIFT标准一贯地使用跟单信用证(documentary credit)这一名词，而不是信用证(letter of credit)。美国的许多银行与行业一般用信用证。使用国际上接受的名词，跟单信用证为一种金融文件，一般由银行开立，其中凭出具符合信用证(credit document)中所规定的条款和条件的单据，开证行负责进行付款。有两种类型的跟单信用证，即商业信用证(commercialletters of credit)(即进口或出口LC)与备用信用证(standby letters ofcredit)。跟单信用证包含银行代表买方(进口商)在预定时间段内在出具所规定的单据的前提下立即(即期(sight))或在随后的日期(后期(Forward))支付商品或服务的卖方(出口商)指定的金额的许诺。即期跟单信用证为一种要求即期汇票(draft)的跟单信用证类型，意指出口商有权即期，即在向银行出具汇票时得到付款。远期(term)跟单信用证允许在30、60、90天的期限上或者在某指定未来日期进行付款。即期或远期跟单信用证都需要在设定时间限制内出具符合信用证条款的单据，以兑现该信用证。所谓的职业国际银行(Professional International Banks)处理某些不经常使用的跟单信用证类型，例如可转让信用证(transferable letters of credit)、循环信用证(revolving letters of credit)、背对背信用证(back-to-back letters ofcredit)、红条款信用证(red clause letters of credit)。
跟单信用证(DC)允许买方与卖方订约(contract)受托(trusted)中间方(银行)，在卖方已经发货(ship the goods)、并且能够提供符合议定的信用证(agreed-upon letter)的条款的单据证据的情况下，该中间方将保证对卖方的完全付款。该文件虽然在本质上较简单，但是可以具有许多变化。通过当满足DC条件时保证卖方以及通过合理地保证买方收到所订购的货物，DC在买方与卖方之间分散风险。DC是用于付款的常用文件，尤其当订约方相互不熟悉时。虽然该文件对双方都提供了良好地保证，其也可能会让人困惑，并且有限制性。其也可能较昂贵，从几百美圆至总值的百分之五。
DC一般是不可撤消的，这意味着一旦确定(establish)了DC，则在没有买方、卖方、开证行、通知行的同意下，不能改变DC。因此，卖方，尤其是当经验不足时，应该向有经验的银行、受托经纪人、及其运输行(freightforwarder)出具DC协议，从而这些方面能够帮助确定该DC是否合法，以及是否能够合理地满足所有条款。受托银行，而非开证行或买方的银行可以在一定费用下担保单据的真实性。在非开证行国家的国家中开立的对受益人有利的信用证必须通过受益人国内的通知行通知。通知行的主要任务在于验证信用证的真实性，并且将其详情转发给受益人。
DC在设计上可以非常灵活，以满足特定目的。例如，背对背信用证允许卖方使用从其买方收到的LC作为银行抵押(collateral)以开立其自己的LC，从而卖方能够购买满足其买方订单所需的输入或者供应。由于对他方的依赖性、以及完成原始交易的额外步骤，所以增加了风险，因此某些银行可能不愿意开立背对背信用证。由于信用证为金融合同，所以其可能有很大变化。某些LC变化包含循环、自由议付(Freely Negotiable)、红条款、可转让、可撤消或者限制议付(Restricted)。也许至少从卖方的观点来说最安全、人们最希望的信用证为备用信用证。备用信用证与商业信用证不同，因为其更像银行或者履约保证书。其不是主要的付款方法，而是一种通常对于较长期项目的自动防故障(fail-safe)方法或者保证。只有当买方未进行所安排的付款或者以其他方式未满足预定条款和条件时该LC才承诺付款。否则，买方在收到货物时，或者根据与卖方安排的信用证条款付款。如果买方不履行责任，那么卖方必须通过提供备用信用证条款可能要求的单据与证明凭备用信用证支取付款。与其他信用证相比，典型的备用信用证对于卖方或者受益人满足条款来说较简单。因此，使用备用信用证有利于卖方。因为备用信用证可能长年有效(持久条款(Evergreen Clause))，所以其消除了对于重复客户每项交易的单独信用证的复杂性。因此，可以有多于一项的交易与单个信用证相关联。
使用信用证或跟单信用证具有某些缺点。如果在跟单信用证的时间、单据或者其他要求中存在即使是最细微的差别，则买方可以拒绝所托运的货物(shipment)。被拒绝的托运货物意味着卖方必须迅速找到新买主，一般是以较低价格，或者付款将托运货物返回或者处理。除昂贵之外，跟单信用证需要时间开出，并且一般会从其开立日直至最终兑现或者付款、违约拒绝、过期或者取消(一般取消要求双方同意)占压买方的流动资本(wording capital)或者信用额度(credit line)。
DC的条款非常具体和有拘束力。许多贸易商，即使是经验丰富者，也会由于其无法理解或者遵守条款而遇到很大困难。某些统计数字显示近乎50％的跟单信用证付款提交(submission)会由于没有遵守条款而被拒绝。例如如果条款要求送达四个特定单据而其中一件不完整或者仅仅是送达晚了，则都会拒付，而不管每个其他条款都满足并且收到状态良好的托运货物。银行的工作是确保安全的付款交易，将坚持严格如所写的那样满足条款。有时买方同意在不满足条款时付款。但是修改或更改DC的条款可能费钱、费时，有时甚至不可能。
DC的基本机制涉及至少四方a)买方或申请人；b)开证行或申请人银行；c)受益人银行或通知行；d)卖方或受益人。图3显示买方301、卖方302、买方银行311、以及卖方银行312。该图可以用来说明DC的传统手工处理。传统地，买方或申请人301向其银行申请开立DC。如果申请人与该开证行没有信用约定，则该申请人必须以现金或某些其他可转让(negotiable)证券保证DC。开证行或申请人银行311开立有利于受益人的DC，并且将单据传送给代理(correspondent)银行。申请人银行以后还验证所有条款、条件、以及单据符合DC，并且通过卖方银行向卖方付款。代理行312验证DC真实性并且通告(或通知)受益人302。通知行312作为申请人银行311与受益人302之间的受托桥梁。其也可以将受益人履约单据证据转回给开证行。然而，通知行没有DC付款的责任，除非通知行添加了其自己的保兑(confirmation)。受益人可以要求申请人及其银行请求通知行保兑DC。这意味着保兑行也承诺确保当受益人符合DC的条款与条件时向受益人付款。保兑行为此服务收取一笔不小的费用。当受益人或其银行不熟悉开证行及其可信度时，或者开证行(即使是声誉良好的银行)处于高风险国家时，这是非常有用的。如果受益人不熟悉通知行/保兑行，受益人还可能通过受托银行出具其符合信用证的单据。然而，这可能增加附加费用。受益人或者卖方302必须确保根据规定准备了所订购的货物，并且按时装运。卖方还必须收集并且向银行出具DC所要求的全套准确的单据。
通过查看跟单信用证的申请表，可以进一步理解跟单信用证过程与符合所需的信息。图4为用于手工申请的一般表单。在图4A所示的页面上，指示申请人通过在字段401中填入申请日期来完成该表单。在框402，指示所完成的信用证传送给受益人的方法。可以使用复选框或指明另一种方法传送。可以在字段404可选地指定通知行的名称。一般地，受益人选择的通知行按照名称与地址填入。如果没有指定通知行，则开证行可以选择其所熟悉的银行。如果通知行不是开证行的代理行，则与通知行在同一国家内的代理行可以作为中间方。在405填入申请人完整的公司名称与地址。在406填入该信用证的数字金额与金额增减幅度(tolerance percentage)。如金额使用About与Approximately(大约)等词语，则适用10％的增减幅度，或者开证行可以提供预定的百分比。在407还填入信用证的大写金额。在408填入受益人或卖方的完整公司名称与地址。在409指定该信用证的到期日。在410指定受益人将所需货物装运的最迟日期。在允许多个装运日期的情况下，根据特定的装运计划，可以使用货物描述字段417或特殊指示字段427。在411指示付款条款或汇票付款到期日。即期汇票在出示与信用证符合的单据时付款。付款可以延迟特定的天数，例如距离提单出单日期(bill of lading date)60天或者见票后90天。也可以指定固定到期日(maturity date)或其他付款条款。兑现信用证时的可支付金额可以是发票金额的100％，或者另一指定金额412。负责银行收费的一方(申请人或受益人)在413指定。一般地，贸易伙伴支付其各自银行的费用。如上所示，在特定时间可支付的汇票可按折扣早一些兑现。在414中指示支付折扣费用的一方。一般地，受益人发生折扣费用，以换取早些接收付款。货物开始运输以及最终运抵的装货与卸货港在415、416中填入。在417中记录对要装运的货物的实际描述。该实际描述必须出现在商业发票上，并且应该简短。这是小偏差就可能延迟跟单信用证兑现的地方之一。在418指示货运条款。标准货运条款可通过复选框选择或可以指定其它货运条款。标准条款包含“F.O.B”，表示船上交货；“C & F”或“CFR”，表示成本加运费；“CIF”，表示成本、保险费加运费；以及“FAS”，表示船边交货。该系统支持国际商会(ICC)认可的13种条款(INCO条款)，或者至少有适用的和经常使用的条款。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选择信用证为可转让(transferable)或不可转让(nontransferable)的，在420选择允许还是不允许分批装运(partial shipments)，在421选择允许还是不允许转运(transshipments)。
在图4B所示页面上，申请人指定卖方要兑现该跟单信用证所需的单据。该表单要求从全套洁净已装船(clean on board)内模式(inter modal)运输提单单据、全套洁净已装船海运提单单据、空运单(air waybill)、以及其他所指定的运输单据中选择至少一种运输单据422。可以选择一或多种运费单据423，其可以被标记为送到即付(collect)、预付、开立给或背书给开证行的指定人(the order of the issuing bank)。在424指定通知方，包含公司名称、以及地址，经常还有联系人名称与电话号码。在425选择保险条件，例如由申请人投保，从而不需要保险单据；由卖方投保的特定保险；或者在申请书中描述的其他保险。可能要求将其他商业单据传送给银行426，例如商业发票、装箱单、产地证明的一个或多个副本或者正本。在427指定特殊指示和/或条件，如UCP所限定的。在428给出必须向议付行(negotiating bank)交单的、相关于装运的时间。如果该时间未指定，则开证行可以使用缺省值，例如21天。交单时间一般对应于最迟装运日期410与跟单信用证到期日409之间的天数。可以提供其他信息供内部使用，其可能不包含在跟单信用证的条款中。例如，可以在429指定运输行或者海关经纪人的名称与地址。作为银行服务，可以将有关跟单信用证的全套单据发送给经纪人/运输行进行清关。申请人公司的联系信息也可以在430中提供，包括能够回答有关开立跟单信用证或者当跟单信用证被兑现时对不符(discrepancies)的弃权声明书的问题的人员的名称与电话号码。在图4C所示页面上，可以确定(identify)一个或多个共同申请人431、432。可以名称、地址、以及一个或多个签名来确定共同申请人。开证行可以提供额外信息块433，仅限银行使用。
通过回去参照图3，能够理解在实现本发明各方面的跟单信用证交易中的各方之间的通信模式以及所需的通信。再一次地，所述各方一般包含货物的买方或者跟单信用证的申请人、卖方或者受益人、开证行或者买方银行、以及通知行或者卖方银行。以下步骤的许多可能的组合可以实现本发明的各个方面在步骤321，卖方302创建信用证指示(letter of credit instruction，LCI)，并且以电子形式将其发送给买方301。卖方可以使用诸如图6-9所示的用户界面来创建该LCI。信用证指示为卖方请求买方输入到信用证申请书中的条款与条件，其成为信用证文件。信用证指示指明为支持买方的计划购买而在信用证中所需的金额。在信用证指示中请求的金额为估价单(proforma invoice)中估计的金额，包含卖方希望取得的超出货物成本的成本。信用证指示可以提供信用证的详细条款与条件。这些条款与条件当然要经过买卖双方之间的谈判与协议。
在步骤322，买方创建信用证申请书(letter of credit application，LCApp)，并且以电子形式将其发送给卖方以对条款与条件进行更改/改变(如果有的话)。由买方准备商业信用证申请书，并且提供给其银行，以进行申请以及随后开立信用证。诸如通过引用并入的专利申请中所述的合作系统可以被方便地用来传递消息、显示、编辑、以及生成交互的审计轨迹(audittrail)。买卖双方合作并且确定信用证条款与条件。当买卖双方努力对条款达成一致时，LCI和/或LCApp的草本可以在买卖双方之间交换多次。LCI、LCApp或者实际开立的LC的条款最好与由总体进-出口跟踪系统所跟踪的一个或多个交易的其他细节相关联，如所并入的专利申请中所述。
在步骤323，买方以至少与向卖方302兑现有关的条款的最终版将信用证申请书发送给开证行311。对于开证行的传送最好为电子形式。在步骤324，开证行处理并接受信用证申请。开证行确认该申请并且将该确认存储在该系统中。在银行生成PDF文件的情况下，上传该PDF文件。在来自银行的传真的情况下，通过使用诸如Easy Link Fax集成环境等软件模块，将该传真扫描为PDF格式或者以电子形式捕获并且转换为PDF。有许多PDF格式的替代格式，包含任意图形文件格式，例如TIF或JPEG格式，以及任意网络兼容格式，例如WordPerfect的Trellix格式，或者其他文件包裹格式。优选地，开证行既生成跟单信用证文件的传真件(facsimile)又生成机器可读版本，例如XML、EDI、cvs或其他互换格式文件，其可以被上传到该系统中。生成跟单信用证的机器可读版本可以减少在记录跟单信用证条款时的印刷错误的机会，以在以后生成一致的所谓同步化单据(synchronized document)。如果开证行没有生成机器可读版本，则由某人手动地将银行消息的详情输入到系统中。与通过实现本发明的系统进行的通信无关地，在步骤325，开证行通知通知行其已经开立了信用证。用于此类通知的一种银行系统已知为SWIFT。在步骤326，通知行将LC发送给卖方。卖方所接收的经过验证的信用证可以用来通过以下方式更新该系统在来自通知行的PDF的情况下，为所上传的PDF；在来自通知行的传真的情况下，为传真消息的经转换版本；以及在由通知行传送的电子文件的情况下，为所上传的XML、EDI、cvs或其他互换格式文件。
经常需要对信用证进行修改，如步骤427-440所述。在步骤427，当需要信用证修改(letter of credit amendment，LCAmd)时，卖方将问题或议题通知买方(或者相反)，并且买卖双方再次合作并且确定对条款的改变。可能有消息以及对草本文本的更新的交换一或多次，直至买卖双方就改变后的条款达成一致。在步骤428，最好以电子形式，买方向开证行提交信用证修改书，并且将最终版本提供给卖方。在步骤429，开证行例如通过PDF或传真确认而批准信用证修改，该确认被上传到该系统中，如上所述。优选地，开证行还生成电子形式的机器可读的确认，例如XML、EDI、或cvs文件，其可以被直接用来反映信用证的更新后的条款。如果未生成机器可读的确认，则以手工方式根据银行消息输入修改后的条款。在步骤340，开证行将修改后的信用证传送给通知行。这一步骤一般通过使用安全银行通道，例如SWIFT来进行。在步骤341，卖方用发票、提单或者空运单、装箱单、以及其他进行结算需要提交给银行的单据匹配或符合(match or reconcile)信用证(包含修改)。优选地，使用本系统来利用用于生成信用证指示或申请书的相同数据，生成至少一个或多个优选为多个的银行所需单据，其被符合为适当反映所开立与修改的信用证条款。卖方向银行提交信用证正本以及所有要求的单据以进行结算。
通过提供单据管理、对有关各方的提醒以及其中的通信、活动跟踪与可视性、将贸易单据链接到信用证条款、以及灵活的设立与协调的各种组合，如所并入的专利申请中所述的系统支持跟单信用证的使用。文档处理的可视性可以抵消在信用证兑现过程中将实际付款延迟至货物装运之后数月的因素。会造成延迟的因素包括完成交易所需的多个单据、完成处理所涉及的多方，以及发出付款所需的对于单据的严格符合。这些因素由于银行在该过程中持有资金这一对银行有利条件而得到加重，因为银行会收到不少管理与信用费用。利用用来协调文档的改进的设施，就可以减少人们对跟单信用证条款的抱怨，以及利用用来管理完成该文档的可视性的改进的设施，就可以缩短资金循环的长度。
跟单信用证管理的一个方面为普通用户管理。输入并且在该系统中可用的跟单信用证交易中的关键参与者(actor)可能不止上述四者，包含买方或者申请人、开证行或者申请人银行、受益人银行或者通知行、卖方或者受益人、以及一个或多个运输行。优选地，可以将参与者输入系统，并且在各交易中重新使用。
参照图3描述的电子过程可以由工作流结构、提醒、以及通知支持。这些参与者之间的一种交互情景为如下1.进口商设立(set up)信用证(或者2.由进口商或者出口商从银行上传)。3.进口商或者出口商将该信用证与贸易或交易相关联。4.由运输行输入运输单据信息(B/L、AWB等等)。5.由出口商创建发票与装箱单。6.出口商通过遵循正确的信用证业务规则核准所有单据符合信用证条款。7.出口商汇总银行兑现信用证所需的单据，并且将这些单据发送给银行以进行结算。在系统中对各个参与者的设置支持它们根据这一情景或者其他情景发挥作用。
可以以下一般方式设立跟单信用证或者信用证可以与其相关联的一综贸易发起(initiate)贸易。将参与者与该贸易相关联。跟单信用证或者信用证可以与该贸易相关联。因为一件信用证可以支持许多综贸易，所以允许用户根据在该系统中可用的信用证，在现有信用证中选择用于该贸易，或者生成新的信用证。虽然使用跟单信用证或者信用证对于给定贸易是可选的，但是当选择了使用它时，其会影响下游的业务规则，因为跟单信用证的条款管理用来生成特定的银行所需的以及与货运有关的单据的信息。可以设立通知规则，如在并入的申请中进一步描述的。
所述工作流结构、提醒、以及通知可以如下卖方准备LCI，并将其发送给买方。系统通知买方LCI的到达，并且提醒其在进行该交易中的角色。买方准备LCApp，并将其发送给卖方。买卖双方就LCApp(或者LCI)进行合作，并且达成商定草本。代表买方的用户可以将商定LCApp发送给经理批准。买方经理可以将LCApp发送给开证行。可以配置发送单据功能，以在买卖双方之间发送单据，并且该功能还可以配置来在买卖双方及其各自银行之间发送单据。通知买卖双方LCApp已经完成被发送给了开证行。该通知可以链接到所述发送单据功能。对于人工传送，该发送单据功能可以将单据发送给打印机；对于系统之间传送，该发送单据功能可以将单据发送电子邮件、电子单据互换或者其他电子传送系统；对于系统至诸如传真或电子单据的PDF附件等个人传送，该发送单据功能可以将单据发送给传真生成与传送系统；或者该发送单据功能可以将单据发送至组合目的地。
对于信用证修改，买方可以准备所提议的修改，并且将其发送给卖方(或者相反)。买卖双方就信用证修改进行合作，并且达成商定草本。代表买方的用户可以将商定的修改发送给经理批准。买方经理可以将该修改发送给开证行。
在图5中显示概括了为LCI、LCApp、LC、或者LC修改而收集的信息的用户界面。在顶部框中，导航条501提供对界面页面的直接访问，这些界面页面为可使用该LC系统的部分环境。导航条链接包含“主页”(home)、显示汇总货运状态的“控制板”(dashboard)、存储LC的“单据库”(documentvault)、“报告”(report)、“管理”(Administration)、“帮助”(help)、以及“登出”(logout)。上下文框502标识用户、用户的公司联系、以及该用户目前在其中工作的特定业务(Portfolio)。货运描述信息503(如果适用的话)包含装运号(Shipment number)、预期出发日、预期到达日、起运地、目的地、提单或空运单号、以及船名/航次(Vessel/Voyage)或者航班/日期(Flight/Date)。提醒显示504报告对于用户的未处理提醒的数目，这些提醒可能由其他人采取的行动导致、用户采取的行动失败、经过里程碑或者提醒日期、或者其他事件或条件。该提醒显示提醒用户要解决的优先问题，而不要求用户直接访问要解决的问题列表。该框与左侧列表框可以用于进出口系统的多种用户界面，以呈现一致的用户界面。
在左侧框中的列表相应于在图1的讨论中所指的TradeBeam产品的订单、物流后勤、以及结算方面。订单功能列表101，即在该实施例中的511，支持诸如人工订单输入、人工销售订单输入、以及检查是否符合进出口规章等功能。装运或者物流后勤功能列表102，即512，支持诸如预定与调度运输、准备出口货运指示、出关处理、准备进口货运指示、入关处理、以及交货证明等功能。与本发明各方面有关的所支持的单据包含货运单据创建与跟踪、检查、装箱单生成、货运指令、以及商业单据。结算功能列表103，即513，支持诸如发票处理与信用证处理等功能。再次地，该左侧列表框与最上面的框可以用于多种用户界面。
次上框用于单据生成，在该例子中用于跟单信用证或信用证。控制链接512允许用户预览正在生成的单据传真件或者发送单据。提交与取消控制522允许用户确定是否保留或保存对当前界面进行的编辑。向页面日志添加注释面板523允许用户标注当用户工作于货运部分时所编辑的审计轨迹。分配动作面板与当前动作标识符524标识在当前信用证过程中当前负责采取下一步骤的参与者，并且允许用户重新分配该当前动作或者分配所需的下一动作。批准状态面板与当前状态标识符525标识当前过程的当前状态，并且允许用户根据用户的批准权限更新该状态。选项卡(tabs)526允许直接访问与信用证处理有关的用户界面，包含“汇总”、“详情”、“各方”、“条款”、“修改”、以及“页面日志”。页面日志显示上述对于信用证处理的审计轨迹。以下进一步描述其余选项卡。
信用证界面的主要部分跨越图5A-E。准备过程中的最近的信用证单据表示为531。这可以是指示、申请、或者修改，或者其可以是信用证本身。指示/申请/修改号码与日期显示为532。信用证与信用证通知号码与日期，与包含信用证类型、到期日、金额、币种的汇总信息一道，列为533。对于申请，标识申请人与开证行，与请求开立与到期日期、到期地点、以及是否需要请求确认一道，为534。在图5B显示的界面部分，提供了有关于信用证约定各方的进一步信息，包含申请人541、受益人542、开证行543、以及通知行544。在实践中，这四方是不同的主体；没有两方会是“Global ConsigneeInc.”在图5C所示的界面部分，545-551汇总了银行543、544以及信用证条款的完成后信息。一组条款545为数字和大写金额、百分比信用证增减幅度、以及最大信用额。第二组条款546包含交货条款(例如INCO条款)、交货条款地(delivery terms places)、可否议付等等(Availabe with and by)、交单期限、是否允许分批装运、是否允许转运、哪方支付银行费用、哪方支付运费、哪方支付保险费、以及哪方支付其他费用。就费用由申请人支付而言，这些费用可以不显示为信用证条款，因为其不会为受益人强加需要满足的条件。标识信用证的付款到期日(tenor)547与付款人(drawee)548。可以指定混合付款或延期付款的特殊条款549。一组装运细节550包含起运地、经过地以及目的地、最迟装运日期与装运期限。指定货物和/或服务描述511，其会进入其他银行所需的单据。在图5D所示的界面部分，指定银行所需单据560。在该例子中，需要两份正本商业发票以及一份副本。需要一份正本装箱单与两份副本，以及提单、汇票(bill of exchange)以及其他单据的额外拷贝。对于一般的不一定为信用证条款的信息，指定收货人(consignee)与被通知方570、572。可以输入并记录对于信用证的附加条件580、特殊指示581、以及银行备注582。一组汇总修改信息590包含信用额(credit amount)的增或减、以及产生的新的信用额、加上新到期日。在实践中，修改可能产生信用额的增或减。新的信用额590将与金额的增或减590一道伴随信用证金额533。在图5E所示的界面部分，显示信用证的修改文本或者修改描述。
图6-9提供了相应于图5A-E中汇总的数据的数据输入字段。在这些图中，遵循方便与逻辑的原则将数据分组。在图6中，提供对于模板的支持627、628，该支持在图5中不明显。可以选择现有模板627或者创建新模板628。当已经完成并提交数据输入时522，可以创建新模板。在图6中，用户选择是否创建指示、申请、或者更改。还可以允许用户选择从银行开立的跟单信用证或信用证人工输入，这在图中没有显示。与该用户界面相关联可以有进行以下工作的效用上传PDF文件、下载传真或电子版本数据、打印、预览、传真、或者允许由非准备该单据的某人批准该单据。可以支持用于买方与卖方的不同视图，这允许一方控制在该方具有独占控制权的字段中输入数据，例如其对收货人或者运输行的选择。对于买方或者卖方，可以支持以下工作流其中不同于输入这些数据的人批准信用证或者其他单据。例如，经理可以具有批准权限，而文员只具有创建/修改权限。图6中的大部分字段也在图5中出现，并且被相应地标号。在图7-9中，对所有出现的字段与图5一致地标号。为了减少视觉上混乱，图6-9中省略了最顶部的框与左侧列表框。为了呈现一致的视觉外观，图6-9中的界面可以如图5那样划框。预期在该申请中显示的所有界面都将被国际化，包含对于讲英语、西班牙语、以及日语的人的支持。在与银行机构的合作中，该系统可以用来符合由IndentrusLLC(一全球电子商务信托组织)或者其后继者或类似组织设立的标准。也可以支持对Thomson Direcotries，包含ThomWeb，以及The Thomson Corporation的其他服务的访问。
本发明的一方面包含根据在DC/LC指示、申请、(多个)修改、或者文件中使用的数据自动填充(populate)银行所需的、与装运有关的单据的字段。可能受益于与DC/LC同步化的单据包含提单、规章符合单据、出口装运指示、发票、以及装箱单。为了说明某些此类单据，图示了用于设立货运、完成银行所需的、与装运有关的单据的用户界面的一个实施例。图10A-C显示货运“timtest003”的设立。该显示的主要组成部分为导航条1010、货运描述信息1020、按照装运阶段的汇总状态信息1030、审计轨迹日志1040、访问模板1045与提醒1046、对于各种参与者的设立(包含出口商1050、进口商1055、出口运输行1060、进口运输行1065、以及海关经纪人1070)、以及对于装运单据的标识的需求准备1075。货运描述信息1020包括装运号、预期出发日、预期到达日、船名/船次(如果适用的话)、提单或空运单号、起运地、目的地、以及航班/日期(如果适用的话)。以上描述了装运阶段类目与状态图标。通过点击相应的图标，察看者可以从该屏幕导航至用于不同阶段的屏幕。装运日志1040显示审计轨迹的至少一部分。审计轨迹记录重大事件(significantevent)的日期、时间、以及参与者。重大事件可以包含单据的创建、编辑、以及批准，或者跟踪装运状态的数据或者由参与者进行的明示状态变化，如下详细所述。在设立显示屏幕上，可以过滤审计轨迹事件，并且只显示那些有关于设立的，诸如“设立完成”的事件。例如，比较在图16A的贸易索引装运日志1640上或者在图17A的预订信息页面日志1740上显示的事件。
返回到设立显示屏幕上，块1045、1046允许选择模板以及提醒配置。可以建立模板来向装运参加者分配身份或访问权限。模板为节省对于与预先建立的路径相关联的访问权限的决策的简便方式。通过配置提醒框，可以配置、察看、或者修改提醒1046。提醒是与某事件相关联(key to)的备忘录(tickler)。其可以与该事件的预期日期相关联、与该事件之前的防范(prudent)时间相关联、或者与该事件之后的某时间相关联。该事件可以对应于该备忘录的名称，或者其可以是不同的相关事件。例如，可能在海运集装箱(oceangoing container)最终到达日期(drop-off date)之前一周要求装运单据。如果在该一周里程碑前没有完成装运单据，则在各种概括视图或者详情显示屏幕上出现提醒。
这些图10A-C还显示对各种潜在参与者的设立。对于特定装运，不需要设立所有参与者。例如，当按惯例进口运输行作为海关经纪人时，可能不需要在该详细显示屏幕中包含所有参与者。对于出口商1050的设立包含选择出口商。在以管理员的身份设立出口商之后，出口商可以从选择列表中选择。在该例子中，向出口商分配了创建、更改、以及批准在与出口有关的阶段进行的动作的权限，并且经过进口商1055的批准，具有修改在与进口有关的阶段中的动作的权限。类似地，设立进口商1055包含选择进口商，以及分配对于每个装运阶段类目的权限。该进口商对于进口装运指示以及交货证明/进口状态信息具有创建、更改、以及批准权限。设立出口运输行1060、进口运输行1065、以及海关经纪人1070一般遵循对进口商或出口商的设立，但是有一项重要的例外。例如，当出口商设立货运时，出口商将设立出口商与进口商两者，但是可以将进口运输行1065或者海关经纪人1070的设立交给进口商1055决定。进口商经出口商同意可能具有创建这一部分设立、或者输入数据的权限。更一般地讲，出口商或进口商可能将对于其相应方的代理的设立交给其相应方决定。该详细显示屏幕中另一部分支持设立装运单据1075。货运单据可以用作各种功能，例如满足海关要求、政府要求、银行要求，满足健康、安全、或者环境规章，或者满足合同条款。具备这些以及其他功能的货运单据可能包含发票、装箱单，以及另一套，包含9802工作单(Worksheet)、空运单、拼箱声明(Assembler’s declaration)、经纪发票、加拿大特殊海关发票(Canadian Special Customs Invoice)、分析证(Certificate ofAnalysis)、检验证(Certificate of Inspection)、保险证(Certificate ofInsurance)、产地证(Certificate of Origin)、重量证(Certificate ofWeight)、CF 3461、CF 7501合格证(Compliance Certification)、危险物品声明(Declaration of Dangerous Goods)、交货单(Delivery Order)、国内装运发票(Domestic Trucking Invoice)、运输行发票(ForwarderInvoice)、熏蒸消毒证(Fumigation Certificate)、MSDS、加工厂证(MillCertificate)、NAFTA证、海运提单(Ocean Bill of Lading)、物理检验证(Physical Inspection Certificate)、提单证明(Proof Bill of Lading)、交货证明(Proof of Delivery)、以及纺织品声明(Textile Declaration)。可能还需要上传和配发其他的海关单据。当设立中需要单据时，概括状态显示屏幕以及其他详情显示屏幕中的同步字段会跟踪至所需单据完成的进展。汇总单据管理状态1043反映所有所需货运单据是否都完成了。该详情显示屏幕还允许将设置保存为模板1081、更改(确认)1082对输入显示屏幕的字段中的数据或者取消1083输入到字段中的更新。
图10D-G显示重新组织了在图10A-C中出现的特征的结算设立的第二个实施例。在该实施例中，可以将结算模块作为独立的产品发送，例如没有订单模块。图10D为初始设立屏幕，可以从该屏幕添加参加者，并且可以将特定单据包含在贸易中。图10E显示结算设立的单据选项卡。在该屏幕中，可以指定对单据的要求以及上传附件。图10F显示结算设立的所设的提醒选项卡。在系统表中声明了多个提醒条件，并且可以在该设立屏幕中使用。针对与特定单据相关的触发条件，可以选择提醒，并且指定时机。为了设立提醒，可以使用模板。可以将提醒的特定配置保存为模板。图10G显示设立参加者以及参加者权限。从图10D的添加参加者按钮达到该屏幕。
图11A-B允许输入发票。该显示屏幕的主要组成部分包含如图10A中所出现的导航条1110、货运描述信息1120、汇总状态信息1130、以及审计轨迹日志1140。主要组成部分还包含典型发票信息1151-55、集装箱及装箱信息1156、付款条款信息1157-59、以及有关于该货运阶段中进一步处理的信息1160。典型发票信息包含买方与卖方参考号1151。该典型信息还包含1152发票号码与日期、提单或空运单号码与日期、以及装运日期、付款到期日、以及交货日期。可以输入顾客、买受方(sold to(卖给))、付款人、装运目的方(ship to(发货给))的名称与地址1153。付款与装运信息1154包含付款方法与汇寄目的方(remit to(汇寄给))、装货与卸货地点、(如果适合的话)船名与船次、以及(如果适合的话)航班与日期。可以察看产品信息1155，并且在某些实施例中可编辑该信息。装备(equipment)信息显示为1156。与付款相关的信息可以包含付款条款1157、交货条款1158、以及信用证号与备注1159。可以输入顾客凭条(customer notes)与特殊指示。与该装运阶段中进一步处理相关的信息包含对于负责朝向该阶段完成的下一动作的装运参加人的指示1160。在该例子中，箭头指向出口商。如果当前任务是该参与者的责任，则会在取消按钮旁边出现通知按钮。选择该通知按钮将通过电子邮件或传真通知提醒下一个负责的装运参加者，并且“控制板”图标从棕色“处理中”箭头变为绿色“待作”框。选择该通知按钮将提醒下一个负责的装运参加者，并且将在页面日志中创建输入项。如果察看者具有批准该发票的权限，则在取消按钮旁边出现完成按钮。在某些实施例中，可能在选择了完成按钮之后出现更改按钮，以允许具有权限的参与者解除对该发票的完成动作。
图11C-K显示发票输入用户界面的替换实施例。图11C-E显示该替换实施例的发票GUI的汇总选项卡。图11F-G显示该发票GUI的详情选项卡。图11H-I显示该发票GUI的产品选项卡。图11J-K显示该发票GUI的页面日志选项卡。
图12A允许输入装箱单。该显示屏幕的主要组成部分包含如图10A中所出现的导航条1210、货运描述信息1220、汇总状态信息1230、以及审计轨迹日志1240。主要组成部分还包含与其他屏幕同步的信息1251-54、装箱单信息1255、装备信息1256、以及有关于该货运阶段中进一步处理的信息1960。与其他屏幕同步的信息包含卖方参考号、发票与提单或空运单号1251、顾客1252、提单或空运单、发票以及装运日期1253、以及运输与信用证信息1254。在该例子中，装箱单信息1255包含行号(line item sequence no)、产品ID与产品描述、集装箱(container)与集装箱封印标识(container sealidentification)、批次(lot no.)、取货地(pickup location)、包ID(packageID)、数量(quantity)、包装(packaging)、单位重量(unit weight)、净重(netweight)、毛重(gross weight)、以及区别标记与号码(distinguishing marksand numbers)。装备信息显示为1256。还有一系列开放字段，用户可以在其中为每个产品信息行输入可选或附加信息。虽然在该屏幕照片上未显示、但是当信息为可更改形式时存在的有三个功能按钮添加行、下载模板、上传模板。“添加行”允许用户在装箱单中创建另一行。“下载模板”允许用户将模板以Excel或其他形式下载到其本地系统，其允许用户手工输入或“剪切和粘贴”装箱单信息到标准格式，该标准格式可以被转换为可以上传到该系统中的数据格式。“上传模板”允许用户将模板上传到装箱单中，由此创建新行。有关于该货运阶段中进一步处理的信息包含对于负责朝向该阶段完成的下一动作的装运参加人的指示1260。在该例子中，箭头指向出口商。在该图中没有取消按钮，该取消按钮在参与者在该显示屏幕中输入任何信息之前存在。如果已经在该图中输入了信息，则将在取消按钮旁边出现通知按钮。选择该通知按钮将提醒下一个负责的装运参加者。如果察看者具有批准该装箱单的权限，则在取消按钮旁边出现完成按钮。在某些实施例中，可能在选择了完成按钮之后出现更改按钮，以允许具有权限的参与者解除对该发票的完成动作。
图12B-I显示装箱单用户界面的替换实施例。图12B-I显示该替换实施例的装箱单GUI的汇总选项卡。图12B-C显示汇总选项卡。图12D-E显示该装箱单GUI的详情选项卡。图12F-G显示产品选项卡。图12H-I显示该装箱单GUI的页面日志选项卡。
图13A-B允许输入有关于提单或空运单的信息。该显示屏幕的主要组成部分包含导航条1310、货运描述信息1320、汇总状态信息1330、以及审计轨迹日志1340。主要组成部分还包含状态信息1351、承运人(carrier)名称与提单或空运单号码1352、委托人(shipper)名称、预定号码与出口参考号1353、收货人(consignee)与货运代理(forwarding agent)名称与地址1354、起运地点或国家1355、通知方与指示1356、来自第三方出口系统的AES XTNNo.1357、装货码头与移动类型(loading pier terminal and type ofmove)1358、运费条款1359、其他装运信息1361-1362、以及有关于该货运阶段中进一步处理的信息1360。在该例子中，状态信息指示是否要已经收到并且上传了提单或空运单的证据(proof)与最终版本。在上传之后，就可下载提单的证据或最终版本。例如，该提单不能由出口商准备或者至少不能由其批准，因为该提单承认运输公司已经收到了货物，并且作为此运输目的的标题。附加装运信息可以包含前程运输(pre-carriage)、接货地点或港口、装货卸货以及船名/船次或航班/号码信息1360、交货地点1361、以及装备信息1362。有关于该货运阶段中进一步处理的信息包含对于负责朝向该阶段完成的下一动作的装运参加人的指示1370。在该例子中，箭头指向出口商。如果在该图中输入了信息，则会在取消按钮旁边出现通知按钮。选择该通知按钮将提醒下一个负责的装运参加者。如果察看者具有批准该发票的权限，则在取消按钮旁边出现完成按钮。在某些实施例中，可能在选择了完成按钮之后出现更改按钮，以允许具有权限的参与者解除对该发票的完成动作。
图13C-L显示提单用户界面的替换实施例。图13C-E显示汇总选项卡。图13F-H显示该提单GUI的详情选项卡。图13I-J显示产品选项卡。图13K-L显示该提单GUI的页面日志选项卡。
DC/LC系统最好支持报告。标准报告可以包含LC状态报告。此类报告可能包含所有或部分的LC号码、LC日期、卖方名称、买方名称、LC到期日、发票号、海运提单号、提单号、以及系统管理员选择的其他字段。也可以支持临时(ad-hoc)报告。应该允许对标准报告进行基于参数的搜索，其包含与上述所列字段不同的字段作为参数。作为参数的起止日期将允许过滤信息。报告的基本功能可以包括按照不同列排序、打印、通过选择特定交易/超链接(例如发票号等等)而深入到(drilling down)实际的单据/交易、以及根据访问控制权限允许从该屏幕访问以编辑相应单据。
对于DC系统的管理方面的支持应该符合该DC系统所运行的环境。可以预测将提供支持来设立域(domain)、公司、贸易、经理、以及用户的角色。还应该将用户与角色相关联。用户对于DC/LC系统可能具有的权限(permissions)包括创建LCI、更改LCI、察看LCI、以及删除LCI；创建LCApp、更改LCApp、察看LCApp、以及删除LCApp；确认LC；上传和管理单据以及发送所管理的单据；创建LCAmend、更改LCAmend、察看LCAmend、以及删除LCAmend；察看报告，创建Party Master(一方主管)、更改PartyMaster、以及察看Party Master。
可以如下定义DC/LC准备的阶段以及准备阶段中的状态第一阶段——指示；第二阶段——申请；第三阶段——修改。考虑到LC的性质，用户不应该能够返回到前一阶段。如果早些的阶段未完成，则应该在后继阶段开始之前完成或取消它。安全设置应该定义用户对于每个阶段以及阶段内的状态的权限和特权。用户应该能够向指定的人员、管理者或者下一动作期间的贸易伙伴联系人发送通知，尤其是针对LC的所需单据。应该允许用户应用或保存模板。上述每个阶段中的状态为指示——进行中或完成；申请——进行中、完成、或已确认；以及修改——进行中或完成。
该系统可以根据用户角色区分用户，例如创建草本DC/LC申请的不同人员以及批准申请以发送给银行的人员。对于各种单据来说，不同的工作流、提醒、以及通知可能是适当的。对于LC指示，代表卖方的某人准备它并且将其发送给买方。可以支持管理卖方活动的第二人进行中间批准。由系统就LCI提醒买方。对于LC申请，代表买方的某人准备它并且将其发送给卖方。在卖方评论或编辑申请、并且将其与修改一道发送给买方的意义上，卖方在发送给银行的申请的准备过程中进行合作。当买卖双方寻求对于条款的一致时，可能反复申请的准备。代表买方的某人将商定的申请发送给表示买方的管理人员进行批准。该买方管理人员将已完成的经批准的申请发送给买方的开证行。可以提醒买卖双方已经将LCApp传送给了银行，并且其已经被开证行批准。更一般地说，对于买卖双方的、关于申请动作的通知将是基于事件的。对于LC修改，买方(或者卖方)准备草本修改。买卖双方就修改条款进行合作。将商定的修改发送给买方管理经理进行批准并且传送给开证行。可以基于事件驱动就LCAmend处理提醒买卖双方。上述图10F显示了提醒的设立。
涉及有关于银行的信息的任何系统也应该关心安全性。可以在以下任一级别或者适当的其他级别上建立安全性。初始级别(initiation level)的安全性可以规定谁有权限设立LC，并且该初始级别的安全性应该在用户/公司级别上控制。关联级别(association level)的安全性可以指示谁可以察看LC信息，并且将其与特定贸易相关联。下游贸易级别(downstream trade level)的安全性可以在用户/贸易级别上控制，而且当发生贸易设立时将授予该访问权限。
可以使用常规集成技术或者任意新发明的技术将DC/LC系统或者包含DC/LC系统的进-出口系统与ERP或者EAI销售商的遗留应用程序集成。集成可能包括允许以XML、EDI、.txt、ASCII、以制表符分割、csv或者类似格式上传与下载。
同步规则定义来自信用证的数据如何被传播给其他单据，包含银行所需单据以及与货运有关的单据。更一般地讲，同步规则定义如何将数据从一个单据传播到其它单据。图14为本发明一个实施例的一组同步规则的一部分。这些规则的子集也实现本发明，并且可能是有用的。图14中的某些规则有关于DC/LC系统运行其中的环境，并且应用本发明不限于DC或LC。通过将其与域Id(未显示)相关联，可以将在图14中所示的规则应用到任何领域，或者应用到选定领域。来源与目的单据类型为字段出现其中的单据类型。这些单据类型可以包含上面或者所引入的申请中所述的单据类型。字段名称为字段的名称，例如图5汇总或者图6-9的输入表单中的字段。来源与目的单据状态指示应用该规则的单据准备的条件。在一个实施例中，这些状态被编码为新1；处理中2；中断(On-Hold)3；完成4；已取消5；被锁定6；等待批准7；已批准8；已确认9；不存在0；以及任意1。有时可以通过应用到多个状态或者通过一般化将触发规则搜索或者应用规则的状态变迁来简化这些规则。“更新范围”列指示将对于字段进行的更新的范围。在该例子中，范围为1、2、或3，对应于一综贸易、一个服务模块、或者跨贸易与跨模块。根据为本发明选择的确切的软件实施例，可以将不同的范围应用于更新。在DC或LC为一种付款形式的环境中，可能有其中没有相关联的DC或LC的交易。相应地，在规则之间具有冗余，从而如果没有LC与交易相关联，则可以指定替换规则。前提条件“LOCTradeExists”对应于在LC与交易相关联的情况下推翻(override)其他规则的规则。
为了观察同步规则的具体实例，考虑第一个信用证到提单规则。当完成信用证并且提单正在朝向完成的处理中时，应用该规则。Beneficiary-address1(受益人地址)字段从信用证拷贝到提单的shipper-address1(委托人地址)字段。该映射确保将最新的信用证信息用于准备委托人可能确认或者采纳的估价提单。类似地，当收到或批准信用证、并且提单正在处理中时，第二个规则映射相同的文件。目的单据字段的灰色阴影指示系统防范正在准备提单的用户推翻信用证的措词。可以将这种防范实现为禁止改变字段、基于人物角色的禁止、或者需要明示推翻、并且将该推翻记录在审计轨迹中的警告。该规则的更新范围为跨贸易。
同步的一种动因在于信用证一般要求完成许多单据，以证明买卖双方已经有效完成交易达到各方(自身、顾客、承运人等等)满意的程度。需要完成与附加这些单据才能让度资金(release fund)。支持以下单据是有用的，这些单据有时用作交易已经完成的证明检验证、保险证、海运提单(Ocean Billof Lading)、空运单、发票、提单(Bill of Lading)、汇票副本、以及产地证。LC将指定需要这些单据的哪些作为单据证明。当创建LC时，应该指定必须完成的所需单据。作为这些单据被“链接”到LC的结果，将应用有关于下游单据创建以及业务规则的业务逻辑。
在不支持所有单据或者不支持LC所需的定制单据(custom documents)的情况的，支持几种单据是有用的。例如，支持发票、提单/空运单、以及海运提单是有用的。虽然这些单据的这些字段应该与LC同步，但是由于在贸易过程中发生的业务处理错误也可能有差异。一个例子为发票，其指示不同于LC的买方名称的不同拼写。允许有意地推翻这些差异是有用的，因为这些差异可能代表了在现实世界或者其他记录系统中实际发生的事情。尤其是如果LC数据是从另一第三方来源上传的，而不是作为LC申请基础输入的，则应该注意对于特定LC，是否应该推翻用于买方名称等等的系统值。
某些字段应该跨越这些单据共享。对于发票准备，进-出口情况分析指示应该根据LC同步买卖双方姓名及地址，而不管LC正确与否，除非LC被明示地推翻，或者LC数据可疑。应该同步销售条款，包含销售条款地(FOBCharlseton)。货物描述应该准确匹配LC，但是可以包含添加的细节。可以在发票上可选地列出LC号码与开立日期。对于提单的准备，应该根据LC同步买卖双方姓名及地址。起运地、目的地名称与地址(如果有的话)应该匹配其他单据与LC。件数、重量、尺寸、立方(cube)应该匹配其他单据与LC。在提单中，货物描述只需要一般地匹配LC，并且可以包含添加的细节。可替换地，其可以匹配LC或者在具有附加细节字段的情况下匹配LC。可以在提单上可选地列出LC号码与开立日期。对于BL/AWB的准备，委托人应该默认为卖方(受益人)，并且具有改变以匹配LC中字段的选项。可以列出收货人与通知方，并且其应该与提供给银行的任何信息(这样的信息可以是可选的，并且不是LC部分(即使被包含在申请表单上))一致。BL/AWB上的件数、重量、以及立方应该匹配提单与LC。货物描述应该一般地匹配LC，并且可以包含航运公司/空运公司所需的添加细节。可替换地，其可以匹配LC或者在具有附加细节字段的情况下匹配LC。可以在BL/AWB上可选地列出LC号码与开立日期。在BL/AWB上的运费，包含费用是预付、收到即付、还是到目的地付款，不应该与LC及发票不一致。收货地、装货港、卸货港、转运目的地(transship to)、以及起运国家与地点不应该与LC不一致。其他承运人注释应该如LC所指示的那样出现。
在偶然情况下，LC可能使用不同的单据首部或标题，例如提单。所生成的单据的单据标题应该匹配LC，包含上述称为商业发票、提单、重量单、检验证等等的单据。正本单据应该在标题附近标注“正本”或者等同表达字样，因为正本与副本经常是来自同一打印机的相继打印的复制件，而不是来自多部分形式的碳写本(carbons from multi-part form)。所有生成的单据都应该具明日期，并且在其上出现的日期不应该其它单据或信用证不一致。
图15显示可以用来声明以及生成系统能够生成的单据的合并(merge)格式。从系统数据合并到该单据中的字段由尖括号<...>以及尖括号之间的字段名称指示。该信件的文本依赖于在系统操作员与收信人之间建立的关系。类似的合并格式可能对于汇票、起运地海运与空运证明、检验证、海运与空运保险通知、输入系统的承载注释的信件、空运单、发票、多次装货的单证(billof ladings)、装货的多张单证(bills of lading)、受益人证、重量单、以及类似单据有用。使用声明式或者合并格式允许非程序员的人员向系统添加单据类型，而不要求对单据的硬编码。
当将数据输入系统时应用的有效性验证规则可能是有用的。
根据上述内容，本领域技术人员显然可以理解根据本发明的各个方面以及组成部分可以构造各种系统与方法。本发明的一个实施例包含一种生成跟单信用证以及相关单据的方法。可选地，可以将该方法实现为系统或者执行该方法步骤的系统。该系统或者设备可以包含组合该方法的各个步骤、方面、选项以及替换实施例的几个实施例。该方法也可以实现为磁介质，该介质印有执行该方法的步骤的程序。该程序可以包含组合该方法的各个步骤、方面、选项以及替换实施例的几个实施例。该生成跟单信用证以及有关单据的计算机辅助方法可以包含提供至少一个用于跟单信用证开立的模板以及一个或多个用于与跟单信用证有关的单据的模板。跟单信用证开立单据可以是跟单信用证指示、跟单信用证申请、或者跟单信用证文件中的一个、两个、或者所有的任意组合。与跟单信用证有关的单据为银行按照相应跟单信用证文件付款所需的多个单据中的单据。该方法还包含从跟单信用证开立模板映射字段到与跟单信用证有关的单据模板，以及接受对于跟单信用证开立模板中至少某些字段的数据。根据本发明的一个实施例，该方法还包含利用该映射填充所述多个与跟单信用证有关的单据中的字段。
在本发明的另一实施例中，前一实施例侧重于准备草本跟单信用证指示或者跟单信用证申请。该草本中的至少某些条款被从第一方传递到第二方，其中第一方与第二方代表贸易伙伴。该系统传递第二方所作的对于草本的批准或编辑。在开立相应的跟单信用证文件之前，并且最好在向开证行提交跟单信用证申请之前，该系统记录第一与第二方有关草本条款的协议。
可以独立实现或者附加于上述实施例的步骤实现的另一实施例包含提供对于跟单信用证条款修改的至少一个模板。该信用证修改模板被映射到与跟单信用证有关的模板以及跟单信用证开立模板。接受对于跟单信用证开立模板中至少某些字段的数据。利用该映射填充所述多个与跟单信用证有关的单据中的字段。可以与该实施例组合的另一方面涉及关于修改条款的合作。该合作方面包含将草本跟单信用证修改的至少某些条款从第一方与第二方中的一方传递到另一方。该系统接受来自另一方的对于草本修改的批准或编辑。在开立相应的经修改的跟单信用证文件之前，并且最好在提交修改请求之前，该系统记录第一与第二方有关草本修改的协议。
与上述任何实施例相结合地，本发明的另一方面包含电子提交对于跟单信用证文件或者跟单信用证文件修改的申请。该电子提交方面包含生成机器可读的跟单信用证申请或者修改申请，并且利用映射填充该申请中的字段。该方法还包含以电子方式将该申请提交给开证行。这一方面还可以包括接收对于跟单信用证文件开立的确认，以及更新为跟单信用证开立模板提供的数据以符合所开立或者经修改的跟单信用证文件。
再次地，根据本发明的各个方面以及组成部分可以构造各种系统与方法。本发明的一个实施例包含用来生成跟单信用证以及相关单据的计算机辅助系统。该系统的元件包含至少一个用于跟单信用证开立的模板以及一个或多个用于与跟单信用证有关的单据的模板。
跟单信用证开立单据可以为跟单信用证指示、跟单信用证申请、或者跟单信用证文件中一个、两个、或者所有的任意组合。跟单信用证有关单据为银行按照相应跟单信用证文件付款所需的多个单据中的单据。该系统还包含将来自跟单信用证开立模板的字段与跟单信用证有关单据模板相关的映射。该系统包含处理对于跟单信用证开立模板中至少某些字段的输入数据、并且利用所述映射填充所述多个跟单信用证有关单据中字段的逻辑。
在该系统的另一实施例中，前一实施例侧重于将草本跟单信用证指示或者跟单信用证申请的至少某些条款从第一方传递到第二方，其中第一方与第二方代表贸易伙伴。处理输入数据的逻辑适用于由第二方批准或编辑该草本，并且在开立相应的跟单信用证文件之前，并且最好在提交跟单信用证文件申请之前，该逻辑记录第一与第二方有关草本条款的协议。
可以独立实现或者附加于上述系统实现的另一实施例包含用于跟单信用证文件条款修改的至少一个模板以及从来自跟单信用证修改模板的字段到跟单信用证有关单据模板的另外的映射。该实施例还包括另外的逻辑，用来接受至跟单信用证修改模板中至少某些字段的输入，以及利用该另外的映射填充跟单信用证有关单据中的字段。该实施例的另一方面支持关于修改条款的合作。在该合作方面，所述用来处理输入数据的另外的逻辑适用于将草本跟单信用证修改的至少某些条款从第一方与第二方中的一方传递到另一方。该系统处理由另一方对于草本修改的批准或编辑，并且在开立相应的经修改的跟单信用证文件之前，并且最好在提交所提议的修改之前，该系统记录第一与第二方有关草本修改条款的协议。
与上述任一系统实施例相结合地，本发明的另一方面包含电子提交跟单信用证申请或者修改申请的逻辑。该实施例还包含利用映射填充跟单信用证申请中的字段并且生成机器可读的跟单信用证申请的逻辑。然后，该系统以电子方式将该申请提交给开证行。这一方面还可以包括以下逻辑接收对于原始或者经修改的跟单信用证文件的开立的确认，以及更新为跟单信用证开立模板提供的数据以符合所开立或者经修改的跟单信用证文件。
虽然通过参照上述优选实施例与详细示例公开了本发明，但是应该理解这些示例出于说明目的，而不是限制意义的。在所述实施例中隐含了计算机辅助处理。相应地，本发明可以实现为计算机辅助处理的方法、包含进行有关于DC或LC的多个单据中字段的同步的逻辑的系统、印有进行有关于DC或LC的多个单据中字段的同步的逻辑的介质、印有进行有关于DC或LC的多个单据中字段的同步的逻辑的数据流、或者进行有关于DC或LC的多个单据中字段的同步的计算机可访问服务。本领域技术人员可以容易地想到各种修改与组合情况，但是这些修改与组合都在权利要求所限定的本发明的精神与范围内。
权利要求
1.一种生成跟单信用证以及相关单据的计算机辅助方法，包含提供至少一个用于跟单信用证开立的模板，包含跟单信用证指示、跟单信用证申请、或者跟单信用证文件中的至少一个；提供一个或多个用于与跟单信用证有关的单据的模板，其中与跟单信用证有关的单据为银行按照相应跟单信用证文件付款所需的多个单据中的单据；从跟单信用证开立模板映射字段到与跟单信用证有关的单据模板；接受对于跟单信用证开立模板中至少某些字段的数据；以及利用所述映射填充所述多个与跟单信用证有关的单据中的字段。
2.如权利要求1所述的方法，其中用于跟单信用证开立的模板相应于卖方的跟单信用证指示。
3.如权利要求1所述的方法，其中用于跟单信用证开立的模板相应于买方的跟单信用证申请。
4.如权利要求1所述的方法，其中用于跟单信用证开立的模板相应于银行开立的跟单信用证文件。
5.如权利要求1所述的方法，其中所述提供数据还包含将草本跟单信用证指示或者跟单信用证申请中的至少某些条款从第一方传递到第二方，其中第一方与第二方代表贸易伙伴；由第二方批准或编辑该草本；以及在开立相应的跟单信用证文件之前，记录第一与第二方有关草本条款的协议。
6.如权利要求1所述的方法，还包含提供用于跟单信用证文件的条款修改的至少一个模板；从跟单信用证修改模板映射字段到与跟单信用证有关的单据模板；接受对于跟单信用证修改模板中至少某些字段的数据；以及利用所述映射填充所述多个与跟单信用证有关的单据中的字段。
7.如权利要求6所述的方法，其中所述提供对于跟单信用证修改模板的数据还包含将草本跟单信用证修改的至少某些条款从第一方与第二方中的一方传递到另一方；由另一方批准或编辑草本修改；以及在开立相应的经修改的跟单信用证文件之前，记录第一与第二方有关草本修改条款的协议。
8.如权利要求1所述的方法，其中所述提供数据步骤针对开证前单据，还包含生成机器可读的跟单信用证申请，利用映射填充该申请中的字段；以及以电子方式将跟单信用证申请提交给开证行。
9.如权利要求8所述的方法，还包含接收对于跟单信用证文件开立的确认；以及更新为跟单信用证开立模板提供的数据以符合所开立的跟单信用证文件。
10.一种生成跟单信用证以及相关单据的计算机辅助系统，包含至少一个用于跟单信用证开立的模板，包含跟单信用证指示、跟单信用证申请、或者跟单信用证文件中的至少一个；一个或多个用于与跟单信用证有关的单据的模板，其中与跟单信用证有关的单据为银行按照相应跟单信用证文件付款所需的多个单据中的单据；将来自跟单信用证开立模板的字段和与跟单信用证有关的单据模板相关的映射；处理对于跟单信用证开立模板中至少某些字段的输入数据的逻辑；以及利用所述映射填充所述多个与跟单信用证有关的单据中的字段的逻辑。
11.如权利要求10所述的计算机辅助系统，其中用于跟单信用证开立的模板相应于卖方的跟单信用证指示。
12.如权利要求10所述的计算机辅助系统，其中用于跟单信用证开立的模板相应于买方的跟单信用证申请。
13.如权利要求10所述的计算机辅助系统，其中用于跟单信用证开立的模板相应于银行开立的跟单信用证文件。
14.如权利要求10所述的计算机辅助系统，其中所述处理输入数据的逻辑适用于将草本跟单信用证指示或者跟单信用证申请中的至少某些条款从第一方传递到第二方，其中第一方与第二方代表贸易伙伴；由第二方批准或编辑该草本；以及在开立相应的跟单信用证文件之前，记录第一与第二方有关草本条款的协议。
15.如权利要求10所述的计算机辅助系统，还包含至少一个用于跟单信用证文件条款修改的模板；从跟单信用证修改模板映射字段到与跟单信用证有关的单据的模板的另一映射；接受对于跟单信用证修改模板中至少某些字段的输入的另一逻辑；以及利用所述另一映射填充所述多个与跟单信用证有关的单据中的字段的另一逻辑。
16.如权利要求15所述的计算机辅助系统，其中所述处理输入数据的另一逻辑适用于将草本跟单信用证修改的至少某些条款从第一方与第二方中的一方传递到另一方；由另一方批准或编辑草本修改；以及在开立相应的经修改的跟单信用证文件之前，记录第一与第二方有关草本修改条款的协议。
17.如权利要求10所述的计算机辅助系统，其中所述处理输入数据的逻辑针对开证前单据，还包含利用映射填充跟单信用证申请中的字段、以及生成机器可读的跟单信用证申请的另一逻辑；以及以电子方式将跟单信用证申请提交给开证行的逻辑。
18.如权利要求17所述的计算机辅助系统，还包含接收对于跟单信用证文件开立的确认的逻辑；以及更新为跟单信用证开立模板提供的数据以符合所开立的跟单信用证文件的逻辑。
全文摘要
提供了一种支持进出口交易的系统与方法。在买方(301)、卖方(302)、开证行(311)和通知行(312)之间建立通信。在步骤(321)，卖方(302)创建信用证指示并将其以电子形式发送到买方(301)。在步骤(322)，买方创建信用证申请并将其发送到卖方(302)。各种通信在这些交易方之间发生并且最终，在步骤(326)，通知行将信用证发送给卖方(302)。
文档编号G06Q10/00GK1739115SQ200380108206
公开日2006年2月22日 申请日期2003年10月29日 优先权日2002年11月4日
发明者马诺杰·纳拉延, 史蒂夫·M·维亚伦戈, 艾伦·R·博恩朔伊尔 申请人:贸易杠杆股份有限公司