CN114303164A - 使用事件驱动平台的供方发票对账和支付 - Google Patents

Abstract

公开了一种用于自动供方发票对账的系统。该系统可以从供方系统接收与采购订单PO相关联的订单确认。系统可以从买方系统接收与订单确认相关联的PO。系统可以从供方系统接收与PO和订单确认相关联的第一发票。系统可以在PO、第一发票和订单确认之间进行对账以生成第二发票。系统可以将第二发票传送给买方系统。

Description

使用事件驱动平台的供方发票对账和支付

相关申请的交叉引用

本申请要求2019年6月28日提交的、题为“SUPPLIER INVOICE RECONCILIATIONAND PAYMENT USING EVENT DRIVEN PLATFORM(使用事件驱动平台的供方发票对账和支付)”序列号为16/456,203的共同待定的美国专利申请的优先权和权益。

技术领域

本公开大体涉及用于自动发票对账和支付的系统和方法。

背景技术

传统的发票对账方法通常依赖于买方与供方之间支付流程之前的一系列采购订单和发票。存在的技术问题在于，支付量受限于传输采购订单的效率、采购订单的数量以及买方、供方和支付方之间的发票数量。此外，由于系统之间的对账过程主要是手动性质，可能会引入错误。就该方面而言，利用传统的人工方法的供方发票分析和核对对账通常很耗时，需要相对大量的用户输入，并且可能无法容忍信息错误。

发明内容

在各个实施例中，公开了用于自动供方发票对账的系统、方法和制品(统称为“系统”)。该系统可以从供方系统接收与采购订单(PO)相关联的订单确认。该系统可以从买方系统接收与订单确认相关联的PO。该系统可以从供方系统接收与PO和订单确认相关联的第一发票。该系统可以在PO、第一发票和订单确认之间进行对账。该系统可以响应于该对账生成第二发票。该系统可以将第二发票传送给买方系统。

在各个实施例中，该系统可以消费(consume)订单确认消息并将订单确认记录到订单确认表中。该系统可以将订单确认消息发布到买方系统的订单确认API，并接收买方订单确认响应消息。该系统可以基于买方订单确认响应消息更新订单确认的状态。该系统可以响应于错误而向订单确认API重新发送订单确认消息。

在各个实施例中，该系统可以将第一发票与第一发票表中的多个发票进行比较以确定新发票。该系统可以响应于确定新发票而将第一发票写入发票表。该系统可以拉取(fetch)或接收PO和订单确认。该系统可以匹配发票、PO和订单确认。在各个实施例中，该系统可以从第一发票、PO和订单确认中的每一个中读取多个行项目。该系统可以基于共同属性确定匹配的行项目集，该匹配的行项目集包括在第一发票、PO和订单确认中的每一个上相同的行项目集。该系统可以基于项目价格和项目数量计算匹配的行项目集的运行总计(running total)。

在各个实施例中，该系统可以从第一发票表中拉取第一发票。该系统可以基于PO、第一发票和运行总计生成第二发票。该系统可以将第二发票传送给买方系统的电子发票API，并且可以接收回复。该系统可以基于回复更新记录在第二发票表中的第二发票的状态。在各个实施例中，该系统可以生成生成支付指令文件(PIF)消息。该系统可以响应于生成的PIF消息而基于第一发票和PO生成JSON PIF。该系统可以将JSON PIF传送给系统的支付API，并且可以接收支付确认标识ID作为响应。该系统可以将支付确认标识ID或JSON PIF中的至少一个与第二发票相关联。

除非本文另外明确指出，否则前述特征和元素可以以各种组合进行组合而没有排他性。根据以下描述和附图，所公开的实施例的这些特征和元素以及操作将变得更加显而易见。

附图说明

在说明书的结尾部分特别指出并明确要求了本公开的主题。然而，当结合附图考虑时，可以通过参考具体描述和权利要求来获得对本公开的更完整的理解，其中，相同的标号表示相同的元素。

图1是示出根据各种实施例的用于供方发票对账的系统的各种系统组件的框图；

图2示出了根据各种实施例的用于供方发票对账的系统中的订单确认过程；

图3示出了根据各种实施例的用于供方发票对账的系统中的发票处理方法；

图4示出了根据各种实施例的用于供方发票对账的系统中的发票匹配过程；

图5示出了根据各种实施例的用于供方发票对账的系统中的发票生成过程；以及

图6示出了根据各种实施例的用于供方发票对账的系统中的支付信息文件生成过程。

具体实施方式

该系统为供方发票对账过程提供了更高水平的复杂性和控制。本公开的益处可以适用于发票系统和采购订单系统的任何适当使用。例如，本公开可应用于消费者销售环境、企业对企业(B2B)或物流环境。尽管本公开可能指的是“供方发票”，但本领域技术人员将理解该系统可应用于任何类型的发票、账单、费用或请求。

如上所述，虽然现有技术的系统通常包括买方与供方之间的时间延迟支付和核对的技术问题，但当前系统通过在事件平台处对支付进行对账来提供技术解决方案。在这方面，系统可以通过事件平台进行的自动对账来提高支付处理的速度和效率。该系统可以减少用户参与支付过程的处理时间。例如，支付过程可以从几个月或几周缩短到几天。该系统还可以减少冗余的PO确认请求和发票，从而减少对系统资源的需求。该系统可以通过减少用户交互的次数来增强用户体验，并简化消息分类、路由和对账处理。

该过程改进了计算机的功能。例如，该过程通过减少用户输入的数量和/或避开用户输入请求的数量来对PO、发票、PO确认进行对账并生成支付，从而提高供方对账的可靠性和速度。类似地，该流程通过实现自动对账和发票支付来提高数据呈现的可靠性和速度。该系统往往可以通过将信息传送给对PO、发票和/或PO确认进行对账的系统来提高可靠性。在这方面，系统资源不会被可能是无效的、重复的或未决的数据所负担，从而倾向于减少退出人工干预等。在各个实施例中，本文描述的过程可以通过减少前端和后端过程调用和/或网络跳来提高网络可用性。这些过程还可以节省处理资源，包括CPU时间、内存资源和网络资源。例如，传统系统可能倾向于为每个法律实体、企业资源计划(ERP)和/或市场配置单独的采购目录(punchout catalog)，以便捕获PO、发票、PO确认等并对其进行对账。在这方面，传统系统往往会增加对处理和数据资源的需求。本文公开的过程和系统倾向于实现按市场的单次采购(punchout)，这可以自动对PO、发票、PO确认等进行对账。

在各个实施例中，参考图1，用于供方发票对账和支付的系统100可以包括事件平台102、用户装置104、买方系统106、供方系统108和金融机构系统110。这些组件中的任何一个都可以外包和/或经由网络与事件平台102进行通信。系统100可以是基于计算机的，并且可以包括处理器、有形的非暂时性计算机可读存储器和/或网络接口，以及其他合适的系统软件和硬件组件。如本文所述，存储在有形的非暂时性存储器上的指令可以允许系统100执行各种功能。在各个实施例中，事件平台102可以被配置为中央网络元件或集线器以访问系统100的各种系统、引擎和组件。

系统100可以包括事件驱动架构(也称为消息驱动架构)，其是促进生产、检测、消费和对事件进行反应的架构模式。事件可以被限定为状态的显著改变。事件驱动架构可以包括事件生成器、事件消费者和事件通道。事件生成器可以以消息的形式发布事件，并且可能不知道消费事件。事件消费者订阅已发布的事件，并且可能忽略其他事件消费者。事件消费者可以以不同步方式处理事件。事件通道可以处理事件的订阅、存储和递送。

在各个实施例中，事件驱动架构可以是卡夫卡(Kafka)架构，其包括消费者组和生产者组，该消费者组包括多个事件消费者，该生产者组包括多个事件生成器。Kafka架构包括Kafka集群，其包括多个事件代理和动物园管理员(zookeeper)。事件代理可以响应于来自消费者组的拉取而传送从生产者组推送的消息。Zookeeper可以维护事件消费者组偏移、主题(topic)列表、领导者选举和总体状态信息。Kafka集群和/或事件代理可以限定多个事件主题，并且事件生成器可以将事件消息发布到事件主题。

在各个实施例中，事件平台102可以包括网络、基于计算机的系统和/或软件组件，被配置为向系统100的各种系统、引擎和组件提供跨买方系统106、供方系统108和金融机构系统110的接入点。买方系统106可以与用户装置104和事件平台102进行操作和/或电子通信。在这方面，事件平台102可以允许从用户装置104到系统100的系统、引擎和组件的通信。在各个实施例中，任何事件平台102可以包括一个或多个数据中心、云存储等，并且可以包括软件(例如，应用程序接口API)，其被配置为检索数据并将数据写入系统100的各种系统、引擎和元件。

在各个实施例中，用户装置104可以包括经由网络与买方系统106进行通信的软件和/或硬件，该网络包括被配置为允许交易账户所有者、用户等访问邮件事件平台102和/或供方系统108的硬件和/或软件。用户装置104可以包括被配置为允许用户与系统100的元件和网络进行通信的任何合适的装置。用户装置104可以包括例如个人计算机、个人数字助理、蜂窝电话、自助服务终端等，并且可以允许用户传输语音通信和/或电子消息。

在各个实施例中，买方系统106可以使买方能够与系统100交互以提交采购订单请求(即，PO)、查看供方报价和理财产品、完成购买等。买方系统106可以包括硬件、软件和/或数据库组件的任何合适的组合。例如，买方系统106可以包括计算机/处理器形式的至少一个计算装置或计算机/处理器的集合，尽管可以使用其他类型的计算单元或系统，例如诸如服务器、网页服务器、池化服务器(pooled server)等。买方系统106还可以包括一个或多个数据中心、云存储等，并且可以包括被配置为检索数据并将数据写入事件平台102的软件(例如API)。在各个实施例中，买方系统106可以包括一个或多个处理器和/或一个或多个有形的非暂时性存储器，并且能够实现逻辑。处理器可以被配置为响应于指令(例如，存储在非暂时性有形计算机可读介质上的指令)的执行而实现各种逻辑操作，如本文进一步讨论的。

尽管本公开参考了买方系统106，但应当理解，本公开的原理可以应用于具有与事件平台102互连的任何合适数量的供方系统的供方发票对账和支付系统。

在各个实施例中，供方系统108可以使卖方能够与系统100进行交互以检索和查看采购订单请求、提交报价、完成买方订单等。供方系统108可以包括硬件、软件和/或数据库组件的任何合适的组合。例如，供方系统108可以包括计算机/处理器形式的至少一个计算装置或计算机/处理器的集合，尽管可以使用其他类型的计算单元或系统，例如诸如服务器、网页服务器、池化服务器等。供方系统108还可以包括一个或多个数据中心、云存储等，并且可以包括被配置为检索数据并将数据写入区块链的软件(例如API)。在各个实施例中，供方系统108可以包括一个或多个处理器和/或一个或多个有形的非暂时性存储器，并且能够实现逻辑。处理器可以被配置为响应于指令(例如，存储在非暂时性有形计算机可读介质上的指令)的执行而实现各种逻辑操作，如本文进一步讨论的。供方系统108还可以包括任何合适数量的后端系统以提供物品库存、交易处理、物品装运和/或交付等。

尽管本公开参考了供方系统108，但应当理解，本公开的原理可以应用于具有与事件平台102互连的任何合适数量的供方系统的供方发票对账和支付系统。

在各个实施例中，金融机构系统110可以与系统100进行交互，以检索和查看PO、支付授权、发票、供方报价等，提交理财产品，传输支付以完成买方订单等。金融机构系统110可以包括硬件、软件和/或数据库组件的任何合适的组合。例如，可以包括一个或多个网络环境、服务器、基于计算机的系统、处理器、数据库等。金融机构系统110可以包括计算机/处理器形式的至少一个计算装置或计算机/处理器的集合，尽管可以使用其他类型的计算单元或系统，例如诸如服务器、网页服务器、池化服务器等。金融机构系统110还可以包括一个或多个数据中心、云存储等，并且可以包括被配置为检索数据并将数据写入事件平台102的软件(例如API)。在各个实施例中，金融机构系统110可以包括一个或多个处理器和/或一个或多个有形的非暂时性存储器，并且能够实现逻辑。处理器可以被配置为响应于指令(例如，存储在非暂时性有形计算机可读介质上的指令)的执行而实现各种逻辑操作，如本文进一步讨论的。

在各个实施例中，金融机构系统110可以包括事件平台102或与事件平台102进行交互以促进购买和支付、授权交易和/或结算交易。例如，金融机构系统110可以表示现有的专有网络，其目前适应信用卡、借记卡和/或其他类型的交易账户或交易工具的交易。金融机构系统110可以是防止窃听者的封闭网络。在各个实施例中，金融机构系统110可以包括示例性交易网络，例如，美国运通(AMERICAN

)、维萨

万事达卡

探索卡

加拿大借记卡

法国信用卡(Cartes Bancaires)、JCB

专用网络(例如，百货商店网络)和/或任何其他支付网络。金融机构系统110可以包括与金融和/或交易系统和过程相关的系统和数据库，例如诸如一个或多个授权引擎、认证引擎和数据库、结算引擎和数据库、应收账款系统和数据库、应付账款系统和数据库等。例如，金融机构系统110可以授权和结算支付交易，并维护交易账户成员数据库、应收账款数据库、应付账款数据库等。在各个实施例中，金融机构系统110可以包括发行方系统、收单方系统、支付处理器等。

尽管本公开参考了金融机构系统110，但应当理解，本公开的原理可以应用于具有与事件平台102互连的任何合适数量的供方系统的供方发票对账和支付系统。

参考图2，示出了用于供方发票对账和支付的系统中的订单确认过程200(例如，在系统100中)。买方系统106可以生成采购订单(PO)201并将PO 201传送给供方系统108(步骤202)。步骤202包括经由买方目录采购(punchout)在用户装置104上显示供方目录。步骤202包括经由买方目录采购建立PO 201。例如，建立PO可以包括从买方目录采购中选择多个库存编号。在各个实施例中，买方系统106可以经由商业可扩展标记语言(cXML)协议将PO 201传送给供方系统108。本领域技术人员将理解，可以采用任何合适的协议在系统100的各个模块之间传递数据文件。响应于接收到PO 201，供方系统108可以将cXML PO确认发布到事件平台102的订单确认应用程序接口API 206(步骤204)。在各个实施例中，cXML PO确认消息可以包括PO 201或者可以与PO 201相关联。例如，cXML PO确认消息可以经由PO编号与PO201相关联。响应于接收到cXML PO确认消息，订单确认API 206可以将cXML PO确认消息发布到Kafka架构的订单确认主题208(步骤210)。

订单确认消费者212可以消费来自订单确认主题208的cXML PO确认消息(步骤214)。响应于消费cXML PO确认消息，订单确认消费者212将订单确认记录到订单确认表216(步骤218)。在各个实施例中，事件平台102可以被配置为将订单确认传送给买方系统106。订单确认消费者212可以将订单确认消息发布到订单确认发布主题220(步骤222)。订单确认发布API消费者224可以从订单确认发布主题220读取订单确认消息(步骤226)。订单确认发布API消费者224可以将订单确认消息发布到买方系统106的订单确认API 228(步骤230)。订单确认发布API消费者224可以从订单确认API 228接收买方订单确认响应消息，并且作为响应，可以更新记录在订单确认表216中的订单确认的状态(步骤232)。例如，步骤232可以包括为订单确认设置订单确认接受标志。过程200包括确定订单确认是否已成功发布到买方系统106的订单确认API 228，并且如果未成功发布，则将订单确认发布到订单确认主题208(步骤234)。在这方面，该过程可以在步骤214处循环，从而趋向于将订单确认重新发送到买方系统106并确保接收到订单确认。例如，系统可以响应于指示错误的买方订单确认响应消息而将XML PO确认消息重新发送到订单确认API 228。

在各个实施例中并且另外参考图3，示出了用于供方发票对账和支付的系统中的发票处理过程300。响应于接收到PO 201，供方系统108可以生成cXML协议的发票301(即，第一发票)。响应于生成发票301，供方系统108可以将包括发票301的cXML发票消息发布到事件平台102的发票API 302(步骤304)。发票API 302可以通过将发票301与存储在发票表306中的发票进行比较来检查发票301是否是重复发票(步骤308)。发票API 302响应于确定发票不是重复发票而将cXML发票消息发布到新/重新处理发票主题310(步骤312)。处理发票消费者314消费来自新/重新处理发票主题310的cXML发票消息以接收发票301(步骤316)。响应于消费cXML发票消息，处理发票消费者314将发票301写入发票表306(步骤318)。换句话说，系统可以确定发票301是新发票，并且作为响应，将发票301写入发票表306。在各个实施例中，事件平台102可以被配置为从买方系统106拉取采购订单201。处理发票消费者314可以调用买方系统106的获取PO API 320并且可以相应地接收PO 201(步骤322)。获取POAPI 320可以返回cXML或XML PO。处理发票消费者314可以响应于接收到PO 201而将PO 201写入采购订单表324(步骤326)。

处理发票消费者314可以验证发票301与PO 201和/或订单确认相关联(步骤328)。步骤328可以包括例如读取订单确认表216并且基于PO编号和发票编号将发票301与订单确认匹配。步骤328可以包括基于PO编号和发票编号将PO 201与发票301进行匹配。步骤328可以包括在PO编号、发票编号和订单确认编号匹配的情况下确定发票有效。PO编号和相关的外部字段在PO、订单确认和发票间对应。在这方面和所有文件中，PO编号可能匹配。因此，系统可以通过与PO 201和订单确认相关联来验证发票301。响应于确定发票301为有效发票，处理发票消费者314可以将与发票301相关联的准备开始匹配消息发布至准备开始匹配主题330(步骤332)。在各个实施例中，处理发票消费者314可以生成错误消息并相应地更新发票表306(步骤334)。步骤334可以包括例如在PO编号、发票编号和订单确认编号中的任何一个不匹配的情况下将发票301标记为无效。在各个实施例中，在发票没有被插入到发票表306中或通过与PO的关联进行验证的情况下，系统可以周期性地和/或异步地将包括发票的发票消息重新发布到新/重新处理发票主题310(步骤336)。

在各个实施例中并且另外参考图4，示出了用于供方发票对账和支付的系统中的发票匹配过程400。开始匹配消费者402订阅准备开始匹配主题330并且消费与发票301相关联的准备开始匹配消息以触发匹配过程(步骤404)。开始匹配消费者402从发票表306拉取发票301(步骤406)。开始匹配消费者402从订单确认表216拉取相关联的订单确认(步骤408)。开始匹配消费者402从采购订单表324拉取相关联的PO 201(步骤410)。在各个实施例中，PO 201、发票301和订单确认中的每一个都可以包括结构数据(例如，XML或cXML)，包括与购买相关联的行项目。每个行项目可以包括与项目相关联的各种属性，例如诸如项目编号、项目价格、项目数量等。在各个实施例中，行项目可以例如通过库存编号、库存单位(SKU)、项目编号等与采购相关联。开始匹配消费者402可以将PO 201、发票301和订单确认中的每一个传送给事件平台102的匹配模块412。

事件平台102的匹配模块412可以确定匹配的行项目集，该匹配的行项目集包括在PO 201、发票301和订单确认中的每一个上相同的行项目集(步骤414)。步骤414可以包括匹配模块412比较PO 201、发票301和订单确认的每个行项目，以确定关于每个行项目的相应各PO 201、发票301和订单确认的行项目的匹配。例如，PO 201可以包括与第一数量和第一价格相关联的第一行项目。在各个实施例中，匹配模块412可以基于诸如SKU、项目编号和/或库存编号之一的共同属性来对齐和/或匹配PO 201、发票301和订单确认行项目中的每一个行项目。步骤414可以包括匹配模块412搜索发票301和订单确认中的每一个的多个行项目以验证发票301和订单确认中的每一个包括具有第一数量和第一价格的行项目。步骤414可以包括比较每个匹配的行项目的每个属性以验证PO 201、发票301和订单确认中的每一个包括相同的行项目集和相关联的属性。在这方面，系统可以在PO 201、发票301和与PO201相关联的订单确认之间进行对账。在各个实施例中，匹配模块412可以计算信用(例如，负支付)。例如，匹配模块412可以处理发票和/或支付指令的符号转换(正到负，或反之亦然)，从而处理支付和信用。在各个实施例中，可以基于包括在发票中的发票类型查找代码来计算支付或信用。

对于每个匹配的行项目，系统可以基于项目价格和项目数量计算匹配的行项目的运行总计(步骤416)。在各个实施例中，发票与PO和/或订单确认之间可能存在多对一的关系。在这方面，可以通过在多个发票上匹配行项目来计算运行总计。步骤416包括将每个匹配的行项目的运行总计插入到运行总计表418中。匹配模块412响应于生成匹配的行项目集而将准备生成电子发票消息发布到准备生成发票主题420(步骤422)，该匹配的行项目集包括在PO 201、发票301和订单确认中的每一个上相同的行项目集。当确定PO 201、发票301和订单确认的任何行项目之间不匹配时，匹配模块412可以调用异常过程424(步骤426)。

在各个实施例中并且另外参考图5，示出了用于供方发票对账和支付的系统中的发票生成过程500。生成电子发票消费者502订阅准备生成发票主题420并消费准备生成电子发票消息，从而触发发票生成过程(步骤504)。生成电子发票消费者502从发票表306拉取发票301(步骤506)。生成电子发票消费者502从采购订单表324拉取相关联的PO 201(步骤508)。生成电子发票消费者502可以将PO 201和发票301传送给事件平台102的发票生成模块510。发票生成模块510可以基于PO 201和发票301生成第二发票(步骤512)。步骤512可以包括读取运行总计表418并基于PO 201、发票301和运行总计生成第二发票。发票生成模块510可以响应于生成第二发票而将准备发布发票消息发送到准备发布发票主题514(步骤516)。

发布电子发票消费者518订阅准备发布发票主题514并消费准备发布发票消息以恢复第二发票(步骤520)。发布电子发票消费者518可以将第二发票传送给买方系统106的电子发票API 522(步骤524)。发布电子发票消费者518可以接收来自电子发票API 522的回复，并且作为响应，可以更新记录在电子发票表526中的第二发票的状态(步骤232)。步骤232可以包括将第二发票记录在电子发票表526中。在各个实施例中，来自电子发票API522的回复可以指示传送第二发票失败，并且系统可以重新发送准备发布发票消息到准备发布发票主题514(步骤528)。在这方面，过程500可以在步骤520处循环，从而趋向于将第二发票重新发送到买方系统106并确保接收到第二发票。

在各个实施例中并且另外参考图6，示出了用于供方发票对账和支付的系统中用于支付指令文件(PIF)生成的过程600。异步PIF发布方602可以周期性地生成生成PIF消息并将生成PIF消息发布到准备生成PIF主题604(步骤601)。开始PIF生成消费者606订阅准备生成PIF主题604并且消费准备生成PIF消息以触发PIF生成过程(步骤608)。PIF生成消费者606从发票表306拉取发票301(步骤610)。PIF生成消费者606从采购订单表324拉取相关联的PO 201(步骤612)。PIF生成消费者606可以将PO 201和发票301传送给事件平台102的PIF生成模块614。PIF生成模块614基于PO 201和发票301生成包括PIF的JSON PIF消息(步骤617)。PIF生成模块614将JSON PIF消息发送到准备发布PIF主题616(步骤618)。

发布PIF消费者620订阅准备发布PIF主题616并消费JSON PIF消息以触发PIF发布过程(步骤622)。发布PIF消费者620可以调用系统100(例如，买方系统106、金融机构系统110或事件平台102)的支付API 624并接收支付确认标识ID(步骤626)。步骤626可以包括经由支付API 624将PIF传送给事件平台102，并且接收包括支付确认标识ID的回复作为响应。发布PIF消费者620更新记录在电子发票表526中的PIF的状态(步骤628)。步骤628可以包括将PIF和支付确认标识ID记录在电子发票表526中，并将PIF和支付确认标识ID与第二发票相关联。在各个实施例中，来自支付API 624的回复可以指示传送PIF失败，并且系统可以将JSON PIF消息重新发送到准备发布PIF主题616(步骤630)。在这方面，过程600可以在步骤622处循环，从而倾向于重新发送PIF并确保接收到PIF和支付确认标识ID。在各个实施例中，事件平台102可以将支付确认标识ID传送给金融机构系统110。

本文各种实施例的详细描述参考附图和图片，附图通过说明的方式示出了各种实施例。尽管足够详细地描述了这些各种实施例以使本领域技术人员能够实践本公开，但是应该理解，在不脱离本公开的精神和范围的情况下，可以实现其他实施例并且可以进行逻辑的和机械的改变。因此，仅出于说明而非限制的目的本文给出详细描述。例如，在任何方法或过程描述中记载的步骤可以以任何顺序执行，并且不限于所呈现的顺序。此外，任何功能或步骤都可以外包给一个或多个第三方或由一个或多个第三方执行。在不脱离本公开的范围的情况下，可以对本文描述的系统、设备和方法进行修改、添加或省略。例如，系统和设备的组件可以集成或分离。此外，本文公开的系统和设备的操作可以由更多、更少或其他组件执行，并且描述的方法可以包括更多、更少或其他步骤。此外，可以以任何合适的顺序执行步骤。如本文档中所使用的，“每个”是指集合的每个成员或集合的子集的每个成员。此外，对单数的任何引用都包括多个的实施例，并且对多于一个组件的引用都可以包括单个的实施例。尽管本文已经列举了具体的优点，但是各种实施例可以包括一些列举的优点、不包括列举的优点或包括所有列举的优点。

提供了系统、方法和计算机程序产品。在本文的详细描述中，对“各种实施例”、“一个实施例”、“实施例”、“示例实施例”等的引用指示所描述的实施例可以包括特定的特征、结构或特性，但是每个实施例可以不必包括该特定的特征、结构或特性。而且，这样的短语不一定指相同的实施例。此外，当结合实施例描述特定的特征、结构或特性时，认为结合其他实施例(无论是否明确描述)影响该特征、结构或特性是在本领域技术人员的知识范围内。在阅读了说明书之后，如何在替代实施例中实现本公开对于相关领域的技术人员而言将显而易见的。

如本文中所使用的，“满足(satisfy)”、“符合(meet)”、“匹配(match)”、“与...相关联(associated with)”或类似短语可以包括相同匹配、部分匹配、符合某些标准、匹配数据的子集、相关、满足特定标准、对应关系、关联以及算法关系等。类似地，如本文中所使用的，“认证(authenticate)”或类似术语可以包括精确认证、部分认证、认证数据的子集、对应、满足某些标准、关联以及算法关系等。

类似于“关联(associate)”和/或其变形的术语和短语可以包括标记、标识、关联、使用查找表或任何其他方法或系统来指示或创建元素(例如，诸如(i)交易帐户和(ii)项目(例如，要约、奖励和折扣)和/或数字信道)之间的关系。此外，响应于任何适当的动作、事件或时间段，关联可以在任何时间发生。关联可以以预定间隔、周期地、随机地、一次、不止一次或响应于适当的请求或动作而发生。可以经由软件启用的链接来分发和/或访问任何信息，其中可以经由电子邮件、文本、帖子、社交网络输入和/或本领域中已知的任何其他方法来发送链接。

术语“非暂时性”应被理解为仅从权利要求范围中除去传播暂时性信号本身，而不放弃对不仅是传播暂时性信号的所有标准计算机可读介质的权利。

在此已经关于特定实施例描述了益处、其他优点以及问题的解决方案。然而，益处、优点、问题的解决方案以及可能导致任何益处、优点或解决方案出现或变得更加明显的任何元素均不应被解释为本公开的关键、必需或必要特征或元素。因此，本公开的范围仅受所附权利要求的限制，在所附权利要求中，除非明确地如此指出，否则以单数形式提及元素并不旨在表示“一个且仅一个”，而是“一个或多个”。此外，在权利要求书或说明书中使用与‘A、B和C中的至少一个’或‘A、B或C中的至少一个’类似的短语时，意图将该短语解释为：实施例中可以单独存在A、实施例中可以单独存在B、实施例中可以单独存在C、或者在单个实施例中可以存在元素A、B和C的任何组合；例如，A和B、A和C、B和C或A和B和C。尽管本公开包括方法，但是可以预期其可以实施为有形计算机可读载体(诸如磁或光存储器或磁盘或光盘)上的计算机程序指令。此外，装置或方法不必解决本公开寻求解决的每个或各个问题，本公开被本权利要求所涵盖。此外，无论在权利要求中是否明确叙述了本公开的元素、组件或方法步骤，都不旨在将这些元素、组件或方法步骤贡献给公众。如本文所使用的，术语“包括”、“包含”或者其任何其他变型意在涵盖非排他性的包含，从而使得包括一系列元素的过程、方法、物品或者设备不仅包括那些元素，而且还可以包括没有明确列出的或者这样的过程、方法、物品或者设备固有的其他元素。

计算机程序(也称为计算机控制逻辑)存储在主存储器和/或辅助存储器中。也可以经由通信接口来接收计算机程序。这样的计算机程序在被执行时使计算机系统能够执行本文所讨论的特征。特别地，计算机程序在被执行时使处理器能够执行各种实施例的特征。因此，这样的计算机程序代表计算机系统的控制器。

这些计算机程序指令可以被加载到通用计算机、专用计算机或其他可编程数据处理设备上以产生机器，使得在计算机或其他可编程数据处理设备上执行的指令创建用于实现一个或多个流程图块中指定的功能的装置。这些计算机程序指令还可以存储在计算机可读存储器中，该计算机可读存储器可以指导计算机或其他可编程数据处理设备以特定方式起作用，使得存储在计算机可读存储器中的指令产生包括指令方法的工业产品，该工业产品实现一个或多个流程图块中指定的功能。也可以将计算机程序指令加载到计算机或其他可编程数据处理设备上，以使一系列操作步骤在计算机或其他可编程设备上执行以产生计算机实现的过程，使得在计算机或其他可编程设备上执行的指令提供用于实现在一个或多个流程图块中指定的功能的步骤。

在各个实施例中，软件可以存储在计算机程序产品中并使用可移动存储驱动器、硬盘驱动器或通信接口加载到计算机系统中。当由处理器执行时，控制逻辑(软件)使处理器执行如本文所述的各种实施例的功能。在各个实施例中，硬件组件可以采用专用集成电路(ASIC)的形式。硬件状态机器的执行以执行本文描述的功能对于相关领域的技术人员将是显而易见的。

如本领域普通技术人员将理解的，该系统可以具体化为现有系统的定制、附加产品、执行升级软件的处理设备、独立系统、分布式系统、方法、数据处理系统、用于数据处理的装置和/或计算机程序产品。因此，系统或模块的任何部分可以采取执行代码的处理设备、基于互联网的实施例、完全硬件的实施例、或结合互联网、软件和硬件的各方面的实施例的形式。此外，该系统可以采取计算机可读存储介质上的计算机程序产品的形式，该计算机可读存储介质具有体现在该存储介质中的计算机可读程序代码装置。可以利用任何合适的计算机可读存储介质，包括硬盘、CD-ROM、BLU-RAY、

光学存储装置、磁存储装置等。

本文中，可以根据功能块组件、屏幕截图、可选选择和各种处理步骤来描述系统和方法。应当理解，可以通过被配置为执行指定功能的任何数量的硬件和/或软件组件来实现这样的功能块。例如，系统可以采用各种集成电路组件，例如存储元件、处理元件、逻辑元件、查找表等，其可以在一个或多个微处理器或其他控制装置的控制下执行各种功能。类似地，可以使用任何编程或脚本语言(例如C、C++、C#、

对象符号(JSON)、VBScript、Macromedia COLD FUSION、COBOL、

公司的动态服务页面)、汇编、

PHP、awk、

Visual Basic、SQL存储过程、PL/SQL、任何

外壳脚本和可扩展标记语言(XML)来实现系统的软件元素，其中各种算法通过数据结构、对象、过程、例程或其他编程元素的任意组合来实现。此外，应当注意，系统可以采用任何数量的常规技术来进行数据传输、信号传递、数据处理和网络控制等。更进一步，系统可以被用来检测或防止诸如JAVASCRIPT、VBScript之类的客户端脚本语言的安全问题。

本文参考根据各种实施例的方法、设备和计算机程序产品的屏幕截图、框图和流程图说明来描述该系统和方法。将理解，框图和流程图图示中的每个功能块以及框图和流程图图示中的功能块的组合分别可以通过计算机程序指令来实现。

因此，框图和流程图的功能块支持用于执行指定功能的装置的组合、用于执行指定功能的步骤的组合以及用于执行指定功能的程序指令装置。还应理解，框图和流程图图示的每个功能块以及框图和流程图图示中的功能块的组合可以通过执行指定功能或步骤的基于专用硬件的计算机系统来实现，或通过专用硬件和计算机指令的适当组合来实现。此外，过程流的图示及其描述可以参考用户

应用、网页、网站、网页表单(webform)、提示等。从业人员将认识到，本文描述的图示步骤可以包括任何数量的配置，包括使用

应用、网页、网页表单、弹出

应用和提示等。还应当理解，图示和描述的多个步骤可以组合成单个网页和/或

应用，但是为了简单起见已被扩展。在其他情况下，图示和描述为单个处理步骤的步骤可以分为多个网页和/或

应用，但为了简单起见已被组合。

在各个实施例中，系统的软件元素也可以使用

运行时环境来实现，该环境被配置为在网络浏览器外执行

代码。例如，系统的软件元素也可以使用NODE.

组件实现。NODE.

程序可以实现几个模块来处理各种核心功能。例如，诸如

的包管理模块可以实现为开源库，以帮助组织第三方NODE.

程序的安装和管理。NODE.

程序还可以实现过程管理器，例如并行多线程机(ParallelMultithreaded Machine，“PM2”)；资源和性能监视工具，例如节点应用程序指标(“appmetrics”)；用于构建用户界面的库模块；和/或任何其他合适和/或所需的模块。

中间件(middleware)可以包括适当地被配置为促进异构计算系统之间的通信和/或处理事务的任何硬件和/或软件。中间件组件是可商购的并且是本领域已知的。中间件可以通过可商购的硬件和/或软件、通过定制的硬件和/或软件组件、或通过其组合来实现。中间件可以处于各种配置中，并且可以作为独立系统存在，或者可以是驻留在互联网服务器上的软件组件。出于本文所公开的任何目的，中间件可以被配置为处理应用服务器的各种组件与任何数量的内部或外部系统之间的事务。

有限公司(纽约州阿蒙克)的

MQTM(以前的MQSeries)是可商购的中间件产品的示例。企业服务总线(“ESB”)应用程序是中间件的另一个示例。

本文讨论的计算机可以提供用户可访问的合适的网站或其他基于互联网的图形用户界面。在一个实施例中，将

公司的互联网信息服务(IIS)、交易服务器(MTS)服务和SQL

数据库与

操作系统、WINDOWS

网页服务器软件、SQL

数据库和

商业服务器一起使用。另外，诸如

软件、SQL

数据库、

软件、

软件、

软件、

软件、

软件等组件可用于提供符合活动数据对象(Active Data Object，ADO)的数据库管理系统。在一个实施例中，

网页服务器与

操作系统、

数据库以及

PHP和/或

编程语言结合使用。

为了简洁起见，本文中将不详细描述系统(以及系统的各个操作组件的组件)的常规数据联网、应用程序开发和其他功能方面。此外，在此包含的各个附图中示出的连接线旨在表示各个元素之间的示例性功能关系和/或物理联接。应当指出，在实际系统中可以存在许多替代或附加的功能关系或物理连接。

在各个实施例中，使用在此描述的各种特定机器来实现在此描述的方法。如本领域技术人员将立即认识到的，可以以任何合适的组合使用以下特定机器以及以后开发的那些机器来实施本文描述的方法。进一步地，从本公开中可以清楚地看出，本文描述的方法可以得到某些物品的各种变换。

本文讨论的各种系统组件可以包括以下的一个或多个：主机服务器或包括用于处理数字数据的处理器的其他计算系统；与处理器耦接的存储器，用于存储数字数据；输入数字转换器(digitizer)，其耦接到处理器，用于输入数字数据；应用程序，存储在存储器中，并且可由处理器访问用于指导处理器对数字数据的处理；显示装置，其耦接到处理器和存储器，用于显示从处理器处理的数字数据得出的信息；以及多个数据库。这里使用的各种数据库可以包括：客户端数据；商家数据；金融机构数据；和/或对系统运行有用的类似数据。如本领域技术人员将理解的，用户计算机可以包括操作系统(例如，

等)以及通常与计算机相关联的各种常规支持软件和驱动器。

本系统或其任何部分或功能可以使用硬件、软件或其组合来实现，并且可以在一个或多个计算机系统或其他处理系统中实现。然而，由实施例执行的操纵通常是用例如匹配或选择的术语来指代的，这些术语通常与人类操作员执行的智力操作相关。在本文所述的任何操作中，人类操作员的这种能力在大多数情况下都不是必需的或需要的。而是，这些操作可以是机器操作，或者任何操作可以通过人工智能(AI)或机器学习来进行或增强。人工智能通常可以指对感知周围世界、制定计划并做出决策以实现其目标的代理(例如，机器、基于计算机的系统等)的研究。人工智能的基础包括数学、逻辑、哲学、概率、语言学、神经科学和决策理论。许多领域都属于AI的范畴，例如，计算机视觉、机器人技术、机器学习和自然语言处理。用于执行各种实施例的有用的机器包括通用数字计算机或类似装置。

在各个实施例中，这些实施例针对能够执行本文所述功能的一个或多个计算机系统。计算机系统包括一个或多个处理器。处理器连接到通信基础结构(例如，通信总线、交叉条(cross-over bar)、网络等)。按照该示例性计算机系统描述了各种软件实施例。在阅读该描述之后，对于相关领域的技术人员来说，如何使用其他计算机系统和/或架构来实现各种实施例将变得显而易见。计算机系统可以包括显示接口，该显示接口转发来自通信基础结构(或来自未示出的帧缓冲器)的图形、文本和其他数据，用于在显示单元上显示。

计算机系统还包括主存储器，例如随机存取存储器(RAM)，并且还可以包括辅助存储器。辅助存储器可以包括例如硬盘驱动器、固态驱动器和/或可移动存储驱动器。可移动存储驱动器以众所周知的方式从可移动存储单元读取和/或写入可移动存储单元。如将理解的，可移动存储单元包括其中存储有计算机软件和/或数据的计算机可用存储介质。

在各个实施例中，辅助存储器可以包括用于允许将计算机程序或其他指令加载到计算机系统中的其他类似装置。这样的装置可以包括例如可移动存储单元和接口。这样的示例可以包括程序盒式存储器和盒式接口(例如在视频游戏装置中找到的)、可移动存储芯片(例如可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM))和相关嵌套、或其他可移动存储单元和接口，其允许将软件和数据从可移动存储单元传送到计算机系统。

计算机系统还可以包括通信接口。通信接口允许软件和数据在计算机系统和外部装置之间传送。通信接口的示例可以包括调制解调器、网络接口(例如以太网卡)、通信端口等。经由通信接口传送的软件和数据是信号的形式，信号可以是电子的、电磁的、光的或其他能够被通信接口接收的信号。这些信号经由通信路径(例如，信道)被提供给通信接口。该信道承载信号，并且可以使用电线、电缆、光纤、电话线、蜂窝链路、射频(RF)链路、无线和其他通信信道来实现。

在各个实施例中，服务器可以包括应用服务器(例如，

POSTGRES PLUS ADVANCED

等)。在各个实施例中，服务器可以包括网页服务器(例如，Apache、IIS、

Web Server、SUN

System Web Server、在

或

操作系统上运行的

虚拟机)。

网页客户端(web client)包括经由任何网络通信的任何装置或软件，例如诸如本文所讨论的任何装置或软件。网页客户端可以包括安装在计算单元或系统内的互联网浏览软件，以进行在线事务和/或通信。这些计算单元或系统可以采用计算机或计算机组的形式，尽管可以使用其他类型的计算单元或系统，包括个人计算机、膝上型计算机、笔记本电脑、平板电脑、智能手机、蜂窝电话、服务器、池化服务器、大型机、分布式计算集群、自助服务终端、终端、销售点(POS)装置或终端、电视或任何其他能够通过网络接收数据的装置。网页客户端可以包括操作系统(例如，

WINDOWS

操作系统、

操作系统、

操作系统、

操作系统等)以及通常与计算机相关联的各种常规支持软件和驱动器。网页客户端还可以运行

INTERNET

软件、

软件、

软件、

软件或任何其他可用于浏览互联网的各种软件包。

如本领域技术人员将理解的是，网页客户端可以与或可以不与服务器(例如，应用服务器、网页服务器等，如本文所讨论的)直接联系。例如，网页客户端可以通过另一个服务器和/或硬件组件访问服务器的服务，该另一服务器和/或硬件组件可以直接或间接连接到互联网服务器。例如，网页客户端可以通过负载平衡器与服务器进行通信。在各个实施例中，网页客户端访问是通过网络或互联网通过可商购的网络浏览器软件包进行的。在这方面，网页客户端可以在具有网络访问权限的家庭或商业环境中。网页客户端可以实现安全协议，例如，安全套接层(Secure Sockets Layer，SSL)和传输层安全(Transport LayerSecurity，TLS)。网页客户端可以实现几种应用层协议，包括HTTP、HTTPS、FTP和SFTP。

本文讨论的任何通信、输入、存储、数据库或显示可以通过具有网页的网站来促进。本文所使用的术语“网页(web page)”并不意味着限制可以用于与用户交互的文档和应用程序的类型。例如，除了标准的HTML文档之外，典型的网站还可以包括各种形式，

小程序、

程序、活动服务器页面(ASP)、常用网关接口脚本(CGI)、可扩展标记语言(XML)、动态HTML、级联样式表(CSS)、AJAX(异步JAVASCRIPT和XML)程序、助手程序应用程序、插件等。服务器可以包括从网页服务器接收请求的web服务，该请求包括URL和IP地址(例如，192.168.1.1)。网页服务器检索适当的网页并将该网页的数据或应用程序发送到IP地址。web服务是能够通过通信手段(例如互联网)与其他应用程序进行交互的应用程序。web服务通常基于标准或协议，例如XML、SOAP、AJAX、WSDL和UDDI。web服务方法在本领域中是众所周知的，并且在许多标准文本中都有介绍。例如，代表性状态转移(REST)或RESTful、web服务可以提供启用应用程序之间的互操作性的一种方式。

网页客户端的计算单元可以进一步配备有使用标准拨号、电缆、DSL或本领域已知的任何其他互联网协议而连接到互联网或内联网的互联网浏览器。起源于网页客户端的事务可以经过防火墙，以防止其他网络用户的未经授权的访问。此外，可以在CMS的不同组件之间部署附加防火墙，以进一步增强安全性。

加密可以通过本领域现在可用或可能变得可用的任何技术来执行，例如，Twofish、RSA、El Gamal、Schorr签名、DSA、PGP、PKI、GPG(GnuPG)、HPE格式-保留加密(FPE)、电压、三重DES、Blowfish、AES、MD5、HMAC、IDEA、RC6以及对称和非对称密码系统)。这些系统和方法还可以并入SHA系列密码方法(例如，ECC、ECDH、ECDSA等)和/或其他正在开发的后量子密码算法。

本文讨论的任何数据库可以包括关系数据库、层次数据库、图形数据库、区块链数据库、面向对象的结构数据库和/或任何其他数据库配置。任何数据库还可以包括平面文件结构，其中，数据可以在没有用于索引的结构并且在记录之间没有结构关系的情况下以行和列的形式存储在单个文件中。例如，平面文件结构可以包括定界的文本文件、CSV(逗号分隔值)文件和/或任何其他合适的平面文件结构。可用于实现数据库的常见数据库产品包括

(纽约州阿蒙克市)的

可从

公司(加利福尼亚州红木海岸)获得的各种数据库产品、

公司(华盛顿州雷德蒙德市)的MICROSOFT

或MICROSOFT SQL

MySQL AB(瑞典乌普萨拉)的

的

Redis、APACHE

或

公司的MapR-DB或任何其他合适的数据库产品。而且，任何数据库可以以任何适当的方式来组织，例如，作为数据表或查找表。每个记录可以是单个文件、一系列文件、一系列链接的数据字段或任何其他数据结构。

某些数据的关联可以通过任何期望的数据关联技术来完成，例如本领域中已知或实践的那些技术。例如，关联可以手动或自动完成。自动关联技术可以包括例如数据库搜索、数据库合并、GREP、AGREP、SQL、在表中使用关键字段来加快搜索速度、对所有表和文件进行顺序搜索、根据已知的顺序对文件中的记录进行排序以简化查找，等等。关联步骤可以通过数据库合并功能来完成，例如，使用预选数据库或数据区中的“关键字段”。考虑使用各种数据库调优步骤来优化数据库性能。例如，可以将诸如索引之类的频繁使用的文件放置在单独的文件系统上，以减少入/出(“I/O”)瓶颈。

更具体地，“关键字段”根据由关键字段限定的对象的高级类别对数据库进行分区。例如，可以将某些类型的数据指定为多个相关数据表中的关键字段，然后可以基于关键字段中的数据类型来链接数据表。优选地，每个链接的数据表中的与关键字段相对应的数据是相同的或是相同类型的。但是，例如，也可以通过使用AGREP链接在关键字段中具有尽管不相同但是类似的数据的数据表。根据一个实施例，可以利用任何合适的数据存储技术来存储数据而没有标准格式。数据集可以使用任何适当的技术来存储，包括例如：使用ISO/IEC 7816-4文件结构存储各个文件；实现域，由此选择专用文件，该专用文件暴露包含一个或多个数据集的一个或多个基本文件；使用分级文件系统使用存储在各个文件中的数据集；被存储为在单个文件中的记录的数据集(包括压缩、SQL可访问的、经由一个或多个密钥被哈希处理的、数字的、通过第一元组按字母顺序的等等)；存储为二进制大对象(BLOB)的数据；存储为使用ISO/IEC 7816-6数据元素编码的未分组数据元素的数据；存储为使用在ISO/IEC 8824和8825中的ISO/IEC抽象语法符号(ASN.l)编码的未分组数据元素的数据；可以包括分形压缩方法、图像压缩方法等的其他专有技术。

在各个实施例中，通过将信息存储为BLOB来促进以不同格式存储各种信息的能力。因此，任何二进制信息可以存储在与数据集关联的存储空间中。如上所述，二进制信息可以与系统相关联地存储或在系统外部但与系统有关。BLOB方法可以使用固定的存储分配、循环队列技术或有关存储器管理的最佳实践(例如，分页存储器、最近最少使用等)经由固定的存储器偏移将数据集存储为格式化为二进制块的未分组的数据元素。通过使用BLOB方法，存储具有不同格式的各种数据集的能力有助于由数据集的多个且不相关的所有者将数据存储在数据库中，或与系统关联地存储数据。例如，可以由第一方提供可以存储的第一数据集，可以由不相关的第二方提供可以存储的第二数据集，且可以由与第一方和第二方不相关的第三方提供可以存储的第三数据集。这三个示例性数据集的每一个可以包含使用不同的数据存储格式和/或技术存储的不同的信息。此外，每个数据集可以包含也可以与其他子集不同的数据子集。

如上所述，在各个实施例中，可以不考虑常用格式而存储数据。但是，该数据集(例如，BLOB)当被提供用于操纵数据库或系统中的数据时，可以以标准方式被注释。注释可以包括被配置为传达在管理各种数据集时有用的信息的与每个数据集有关的短头标(header)、尾标(trailer)或其他适当的指示符。例如，注释在本文中可以被称为“条件头标”、“头标”、“尾标”或“状态”，并且可以包括对数据集的状态的指示或者可以包括与数据的特定发布者或所有者相关的标识符。在一个示例中，每个数据集BLOB的前三个字节可以被配置为或可配置为指示该特定数据集的状态：例如，已加载、已初始化、就绪、已阻止、可移除、或已删除。后续的数据字节可用于指示例如发布者的身份、用户、事务/会员账户标识符等。这些条件注释中的每一个在本文中进一步讨论。

数据集注释也可以用于其他类型的状态信息以及各种其他目的。例如，数据集注释可以包括建立访问级别的安全信息。例如，访问级别可以被配置为仅允许某些个人、员工级别、公司或其他实体访问数据集，或被配置为允许基于事务、商家、发布者、用户等访问特定数据集。此外，安全信息可以仅限制/仅允许某些动作，例如，访问、修改和/或删除数据集。在一个示例中，数据集注释指示仅数据集所有者或用户被允许删除数据集，各种标识的用户可以被允许访问该数据集以读取，而其他用户全部被排除在访问数据集之外。但是，也可以使用其他访问限制参数，允许各种实体适当地以各种许可级别访问数据集。

包括头标或尾标的数据可以由独立的交互装置接收，该交互装置被配置为根据头标或尾标添加、删除、修改或扩充数据。因此，在一个实施例中，头标或尾标不与关联的发布者拥有的数据一起存储在事务装置上，而是可以通过在独立装置处向用户提供要采取的动作的适当选项而采取适当的动作。该系统可以考虑数据存储布置，其中，数据的头标或尾标、或者头标或尾标历史被存储在与适当数据相关的系统、装置或事务工具上。

本领域技术人员还将意识到，出于安全原因，任何数据库、系统、装置、服务器或系统的其他组件可以在单个位置或多个位置处由其任何组合组成，其中每个数据库或系统包括各种合适的安全特征中的任何一种，例如防火墙、访问代码、加密、解密、压缩、解压缩等。

从业者还将意识到，存在多种用于在基于浏览器的文档内显示数据的方法。数据可以表示为标准文本，或者可以表示在固定列表、可滚动列表、下拉列表、可编辑文本字段、固定文本字段、弹出窗口内等。同样，存在许多方法可用于修改网页中的数据，例如，使用键盘的自由文本输入、菜单项的选择、复选框、选项框等。

分布式计算集群可以是例如

软件集群，被配置为处理和存储大数据集，其中一些节点包括分布式存储系统，而一些节点包括分布式处理系统。在这方面，分布式计算集群可以被配置为支持在http://hadoop.apache.org/docs/上的Apache软件基金会指定的

分布式文件系统(HDFS)。

如本文所使用的，术语“网(络)”包括结合了硬件和/或软件组件的任何云、云计算系统或电子通信系统或方法。例如，各方之间的通信可以通过任何合适的通信渠道来完成，例如，通过电话网络、企业网、内部网、互联网、交互点装置(销售点装置、个人数字助理(例如，

装置、

装置)、蜂窝电话、自助服务终端等)、在线通信、卫星通信、离线通信、无线通信、应答器通信、局域网(LAN)、广域网(WAN)、虚拟专用网(VPN)、联网或链接的装置、键盘、鼠标和/或任何适当的通信或数据输入形式。此外，尽管本文中经常将系统描述为利用TCP/IP通信协议来实现，但是系统也可以使用IPX、

程序、IP-6、NetBIOS、OSI、任何隧道协议(例如，IPsec、SSH等)或任何数量的现有或将来的协议来实现。如果网络具有公共网络(例如，互联网)的性质，则假定网络不安全并向窃听者开放可能是有利的。与结合互联网使用的协议、标准和应用软件有关的特定信息通常是本领域技术人员已知的，因此在此无需详细说明。

“云”或“云计算”包括这样的模型，其能够对可配置计算资源(例如，网络、服务器、存储、应用程序和服务)的共享池进行方便的、按需的网络访问，可配置计算资源可以用最少的管理工作或服务提供方交互来被快速供应和发布。云计算可以包括位置无关的计算，从而共享服务器可以按需向计算机和其他装置提供资源、软件和数据。

如本文所使用的，“传输(transmit)”可以包括将电子数据从一个系统组件发送到另一系统组件(例如，通过网络连接)。另外，如本文中所使用的，“数据”可以包括涵盖数字或任何其他形式的诸如命令、询问、文件、用于存储的数据等的信息。

类似于“支付处理器”的短语可以包括指定(例如，由商家)处理交易的公司(例如，第三方)。支付处理器可以包括发行方、收单方、授权方和/或交易过程中涉及的任何其他系统或实体。支付处理器可以分为两种类型：前端和后端。前端支付处理器连接到各种交易账户，并为商业银行的商户提供授权和结算服务。后端支付处理器接受来自前端支付处理器的结算，并经由联邦储备银行将资金从发行银行转移到商业银行。在通常花费几秒钟的操作中，支付处理器将通过将详细信息转发给相应帐户的发行银行或卡协会进行验证来检查接收到的详细信息，并且可以对交易执行一系列反欺诈措施。附加参数(包括账户的发行国家及其先前的支付历史)可用于衡量交易被批准的概率。响应于支付处理器接收到交易账户详细信息已被验证通过的确认，该信息可以被转发回商家，然后商家将完成支付交易。响应于验证被拒绝，支付处理器将信息转发给商家，然后商家可能会拒绝交易。

类似于“支付网关”或“网关”的短语可以包括授权针对电子商务、在线零售商和/或传统实体商家的支付的应用服务提供方服务。网关可能相当于位于大多数零售店的物理销售点终端。支付网关可以通过加密敏感信息(例如，交易帐号)来保护交易账户详细信息，以确保信息在客户与商家之间以及商家与支付处理器之间安全传送。

Claims (20)

1.一种方法，包括：

由基于计算机的系统从供方系统接收与采购订单PO相关联的订单确认；

由所述基于计算机的系统从买方系统接收与所述订单确认相关联的PO；

由所述基于计算机的系统从所述供方系统接收与所述PO和所述订单确认相关联的第一发票；

由所述基于计算机的系统在所述PO、所述第一发票和所述订单确认之间进行对账；

响应于所述对账，由所述基于计算机的系统生成第二发票；以及

由所述基于计算机的系统将所述第二发票传送给所述买方系统。

2.根据权利要求1所述的方法，还包括：

由所述基于计算机的系统消费订单确认消息并将所述订单确认记录到订单确认表；

由所述基于计算机的系统将所述订单确认消息发布到所述买方系统的订单确认应用程序接口API并接收买方订单确认响应消息；

由所述基于计算机的系统基于所述买方订单确认响应消息更新所述订单确认的状态；以及

响应于错误，由所述基于计算机的系统向所述订单确认应用程序接口API重新发送所述订单确认消息。

3.根据权利要求2所述的方法，还包括：

由所述基于计算机的系统将所述第一发票与第一发票表中的多个发票进行比较以确定新发票；

响应于确定新发票，由所述基于计算机的系统将所述第一发票写入所述第一发票表；

由所述基于计算机的系统拉取所述PO和所述订单确认；以及

由所述基于计算机的系统匹配所述第一发票、所述PO和所述订单确认。

4.根据权利要求3所述的方法，还包括：

由所述基于计算机的系统从所述第一发票、所述PO和所述订单确认中的每一个中读取多个行项目；

由所述基于计算机的系统基于共同属性确定匹配的行项目集，所述匹配的行项目集包括在所述第一发票、所述PO和所述订单确认中的每一个上相同的行项目集；以及

由所述基于计算机的系统基于项目价格和项目数量计算所述匹配的行项目集的运行总计。

5.根据权利要求4所述的方法，还包括：

由所述基于计算机的系统从所述第一发票表拉取所述第一发票；

由所述基于计算机的系统基于所述PO、所述第一发票和所述运行总计生成所述第二发票；

由所述基于计算机的系统将所述第二发票传送给所述买方系统的电子发票应用程序接口API并接收回复；以及

由所述基于计算机的系统基于所述回复更新第二发票表中记录的所述第二发票的状态。

6.根据权利要求5所述的方法，还包括：

由所述基于计算机的系统生成生成支付指令文件PIF消息；

响应于所述生成支付指令文件PIF消息，由所述基于计算机的系统基于所述第一发票和所述PO生成支付指令文件PIF；

由所述基于计算机的系统将所述支付指令文件PIF传送给支付应用程序接口API并接收支付确认标识ID作为响应；以及

由所述基于计算机的系统将所述支付确认标识ID或所述支付指令文件PIF中的至少一个与所述第二发票相关联。

7.一种系统，包括：

处理器；以及

有形的非暂时性存储器，被配置为与所述处理器进行通信，所述有形的非暂时性存储器具有存储在其上的指令，所述指令响应于由所述处理器执行，使所述处理器执行包括如下的操作：

由所述处理器从供方系统接收与采购订单PO相关联的订单确认；

由所述处理器从买方系统接收与所述订单确认相关联的PO；

由所述处理器从所述供方系统接收与所述PO和所述订单确认相关联的第一发票；

由所述处理器在所述PO、所述第一发票和所述订单确认之间进行对账；

响应于所述对账，由所述处理器生成第二发票；以及

由所述处理器将所述第二发票传送给所述买方系统。

8.根据权利要求7所述的系统，还包括：

由所述处理器消费订单确认消息并将所述订单确认记录到订单确认表；

由所述处理器将所述订单确认消息发布到所述买方系统的订单确认应用程序接口API并接收买方订单确认响应消息；

由所述处理器基于所述买方订单确认响应消息更新所述订单确认的状态；以及

响应于错误，由所述处理器向所述订单确认应用程序接口API重新发送所述订单确认消息。

9.根据权利要求8所述的系统，还包括：

由所述处理器将所述第一发票与第一发票表中的多个发票进行比较以确定新发票；

响应于确定新发票，由所述处理器将所述第一发票写入所述第一发票表；

由所述处理器拉取所述PO和所述订单确认；以及

由所述处理器匹配所述第一发票、所述PO和所述订单确认。

10.根据权利要求9所述的系统，还包括：

由所述处理器从所述第一发票、所述PO和所述订单确认中的每一个中读取多个行项目；

由所述处理器基于共同属性确定匹配的行项目集，所述匹配的行项目集包括在所述第一发票、所述PO和所述订单确认中的每一个上相同的行项目集；以及

由所述处理器基于项目价格和项目数量计算所述匹配的行项目集的运行总计。

11.根据权利要求10所述的系统，还包括：

由所述处理器从所述第一发票表拉取所述第一发票；

由所述处理器基于所述PO、所述第一发票和所述运行总计生成所述第二发票；

由所述处理器将所述第二发票传送给所述买方系统的电子发票应用程序接口API并接收回复；以及

由所述处理器基于所述回复更新第二发票表中记录的所述第二发票的状态。

12.根据权利要求10或11所述的系统，还包括：

由所述处理器生成生成支付指令文件PIF消息；

响应于所述生成支付指令文件PIF消息，由所述处理器基于所述第一发票和所述PO生成支付指令文件PIF；

由所述处理器将所述支付指令文件PIF传送给支付应用程序API并接收支付确认标识ID作为响应；以及

由所述处理器将所述支付确认标识ID或所述支付指令文件PIF中的至少一个与所述第二发票相关联。

13.根据权利要求7-12中任一项所述的系统，还包括卡夫卡架构。

14.一种制品，包括其上存储有指令的非暂时性有形计算机可读存储介质，所述指令响应于由基于计算机的系统执行，使所述基于计算机的系统执行包括如下的操作：

由所述基于计算机的系统从供方系统接收与采购订单PO相关联的订单确认；

由所述基于计算机的系统从买方系统接收与所述订单确认相关联的PO；

由所述基于计算机的系统从所述供方系统接收与所述PO和所述订单确认相关联的第一发票；

由所述基于计算机的系统在所述PO、所述第一发票和所述订单确认之间进行对账；

响应于所述对账，由所述基于计算机的系统生成第二发票；以及

由所述基于计算机的系统将所述第二发票传送给所述买方系统。

15.根据权利要求14所述的制品，还包括：

由所述基于计算机的系统消费订单确认消息并将所述订单确认记录到订单确认表；

由所述基于计算机的系统将所述订单确认消息发布到所述买方系统的订单确认应用程序接口API并接收买方订单确认响应消息；

由所述基于计算机的系统基于所述买方订单确认响应消息更新所述订单确认的状态；以及

响应于错误，由所述基于计算机的系统向所述订单确认应用程序接口API重新发送所述订单确认消息。

16.根据权利要求15所述的制品，还包括：

由所述基于计算机的系统将所述第一发票与第一发票表中的多个发票进行比较以确定新发票；

响应于确定新发票，由所述基于计算机的系统将所述第一发票写入所述第一发票表；

由所述基于计算机的系统拉取所述PO和所述订单确认；以及

由所述基于计算机的系统匹配所述第一发票、所述PO和所述订单确认。

17.根据权利要求16所述的制品，还包括：

由所述基于计算机的系统从所述第一发票、所述PO和所述订单确认中的每一个中读取多个行项目；

由所述基于计算机的系统基于共同属性确定匹配的行项目集，所述匹配的行项目集包括在所述第一发票、所述PO和所述订单确认中的每一个上相同的行项目集；以及

由所述基于计算机的系统基于项目价格和项目数量计算所述匹配的行项目集的运行总计。

18.根据权利要求17所述的制品，还包括：

由所述基于计算机的系统从所述第一发票表拉取所述第一发票；

由所述基于计算机的系统基于所述PO、所述第一发票和所述运行总计生成所述第二发票；

由所述基于计算机的系统将所述第二发票传送给所述买方系统的电子发票应用程序接口API并接收回复；以及

由所述基于计算机的系统基于所述回复更新第二发票表中所记录的所述第二发票的状态。

19.根据权利要求18所述的制品，还包括：

由所述基于计算机的系统生成生成支付指令文件PIF消息；

响应于所述生成支付指令文件PIF消息，由所述基于计算机的系统基于所述第一发票和所述PO生成支付指令文件PIF；

由所述基于计算机的系统将所述支付指令文件PIF传送给支付应用程序接口API并接收支付确认标识ID作为响应；以及

由所述基于计算机的系统将所述支付确认标识ID或所述支付指令文件PIF中的至少一个与所述第二发票相关联。

20.根据权利要求14-19中任一项所述的制品，还包括卡夫卡架构。

Images