CN108711045A - 一种收银系统和收银方法 - Google Patents

Abstract

本发明涉及一种收银系统，包括：收银台前端，其用于接收交易请求，返回支付结果；支付平台接口，其用于响应于交易请求与第三方支付平台通信，发送支付请求并从第三方支付平台接收支付结果；以及收银台服务系统，其用于记录支付状态。

Description

一种收银系统和收银方法

技术领域

本发明涉及软件技术领域，特别地涉及一种收银系统和收银方法。

背景技术

基于云平台的软件服务已经在企业活动的各个方面得到了应用。然而，对于现有企业软件服务而言，业务软件与财务软件仍处于相互独立的状态，缺少衔接的渠道，形成了信息的孤岛，在事件处理、信息流动和日常管理方面都带来了诸多不便。本领域需要一种更为高效的收银系统和方法。

发明内容

针对现有技术中存在的技术问题，本发明提出了一种收银系统，包括：收银台前端，其用于接收交易请求，返回支付结果；支付平台接口，其用于响应于交易请求与第三方支付平台通信，发送支付请求并从第三方支付平台接收支付结果；以及收银台服务系统，其用于记录支付状态。

如上所述的系统，其中收银台前端响应于用户操作，确认支付信息。

如上所述的系统，其中收银台服务系统根据交易请求在交易池中生成唯一的交易号，并将交易号返回收银台前端。

如上所述的系统，其中收银台服务系统异步向业务系统发送支付结果和交易明细。

如上所述的系统，其中收银台包括收银台管理模块，其用来执行基础数据管理、交易查询、支付补登和退款功能中的一者或多者。

如上所述的系统，其中收银台与用来提供收银台使用者鉴权服务的数据中心通信。

如上所述的系统，其中收银台用来记录收银台的交易详情的日志服务模块通信。

如上所述的系统，其中收银台与经调用向用户发送短信息的短信服务模块通信。

如上所述的系统，其中收银台包括收银台数据库。

如上所述的系统，其中收银台服务系统包括：第一收银台服务模块，用于与收银台数据库交互；以及第二收银台服务模块，用于接收支付请求以及支付结果，并控制第一收银台服务模块更新收银台数据库。

如上所述的系统，其中收银台包括三层构架：用户界面层，其包括收银台前端和收银台管理模块；业务逻辑层，其包括收银台服务系统；数据访问层，其包括收银台数据库。

如上所述的系统，收银台数据库包括：交易池表，其用来记录交易的状态；交易请求表，其用来记录交易请求；以及交易结果表，其用来记录交易请求对应的交易结果。

如上所述的系统，收银台数据库包括：交易池表包括交易池主表，其用来记录交易的状态；以及交易池子表，其用来记录交易请求的状态。

如上所述的系统，收银台数据库包括：交易请求表，其用来记录收银台数据库中已有的交易请求。

如上所述的系统，收银台数据库包括：退款请求表，其用来记录收银台数据库中已有的退款请求。

根据本发明的另一个方面，提出一种收银方法，包括：接收交易请求，返回支付结果；响应于交易请求与第三方支付平台通信，发送支付请求，记录支付状态；以及从第三方支付平台接收支付结果。

如上所述的方法，包括响应于用户操作，确认支付信息。

如上所述的方法，包括根据交易请求在交易池中生成唯一的交易号。

如上所述的方法，包括从第三方支付平台接收交易明细。

如上所述的方法，包括异步向业务系统发送支付结果和交易明细。

附图说明

下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：

图1是根据本发明一个实施例的业财一体化系统的示意图；

图2是根据本发明一个实施例的业财一体化系统数据流动示意图；

图3是根据本发明一个实施例的收银台的结构示意图；

图4是根据本发明一个实施例的收银台系统技术实现示意图；

图5是根据本发明一个实施例的收银台系统布置示意图；

图6是根据本发明一个实施例的收银台数据库结构示意图；

图7是根据本发明一个实施例的数据库流程示意图；

图8是根据本发明一个实施例的财务数据处理系统的示意图；

图9是根据本发明一个实施例的业财一体化管理方法；

图10是根据本发明一个实施例的清分对账方法；

图11是根据本发明一个实施例的异常财务数据处理的流程图；

图12是根据本发明一个实施例的退款的方法示意图；

图13是根据本发明一个实施例的凭证生成方法的示意图；以及

图14是根据本发明一个实施例的财务信息处理方法示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。

本发明提出了一种业财一体化系统，在业务系统和财务系统的基础上，通过增加收银台，在满足支付需求的条件下为业务与财务的整合提供数据支持；通过增加财务数据处理系统实现了业务、支付和财务体系的一体化融合，能够极大地提高企业业务和财务部门的工作效率，并且为企业的精细化管理提供技术上的基础。

图1是根据本发明一个实施例的业财一体化系统的示意图。如图所示，业财一体化系统100包括业务系统10、收银台20和财务数据处理系统30、财务系统40。

业务系统10包括业务系统前台101和业务系统后台102。业务系统前台101提供多种类型界面以与用户进行互动。这些界面包括但不限于业务界面：网站界面(例如PC官网)、APP界面(APP)、手机网页端界面(M站)、第三方应用中的程序界面(例如，微信公众号、微信小程序、支付宝应用等)等；以及金融界面：营帐系统界面、会员余额系统界面、储值卡系统界面、V4系统界面等。

业务系统前台101根据用户在上述界面上的操作生成订单。订单中至少包括业务信息和待支付信息。业务信息包括但不限于：订单号、业务类型、业务内容、用户信息、和服务提供者的信息中的一者或多者。待支付信息包括但不限于：待支付金额、币种等信息中的一种或多者。业务系统前台101根据订单向收银台发送交易请求。

业务系统后台102为业务系统前台提供支持。业务系统后台102记录用户提交的订单，并从用户提交的订单中提取相应的订单数据。

收银台20包括收银台前端201、支付平台接口202和收银台服务系统203。收银台前端201接收来自业务系统前台101的交易请求。交易请求包括一部分业务信息以及待支付信息，例如，订单号和待支付信息。收银台前端201向用户或店员提供支付页面，根据用户的操作确认支付渠道、支付方式、支付金额等信息，调用支付平台接口202向第三方支付平台发起支付请求，并接收支付结果和交易明细。

支付平台接口202用于与第三方支付平台通信，发送支付请求，接收支付结果和交易明细。第三方支付平台包括但不限于：银企直联、聚合支付、会员余额、储值卡等方式中的一种或多种；其中聚合支付包括但不限于：银行POS、银联快捷、支付宝、微信支付、ApplyPay、Samsung Pay、Huawei Pay、PayPal中的一种或多种。本领域技术人员应当注意，某些第三方支付平台，例如会员余额系统或者储值卡系统，可能与业财一体化系统为共同主体所有或者运营。对于收银台20而言，这些平台可以认为是外部的第三方支付平台。

收银台服务系统203收银台前端201和支付平台接口202提供支持。进一步地，收银台服务系统203提供交易记录服务。具体而言，收银台服务系统203接收来自收银台前端201的交易请求，在所建立的交易池添加新的交易并为每个交易提供唯一的交易号，并记录和更新交易的状态。根据本发明的一个实施例，一个交易请求可以对应多个交易号。

收银台前端201接收来自收银台服务系统203的交易号，调用支付平台接口202向第三方支付平台发出支付请求。根据本发明的一个实施例，支付请求至少包括交易号和其他支付信息。在一些实施例中，支付请求还可以包括订单号等其他信息。

根据本发明的一个实施例，在发起支付之前，将支付信息显示在支付界面上以使得用户能够再次确认支付信息。支付平台接口202从收银台前端201接收支付请求，根据支付渠道的类型将支付请求经过格式转换后发送到相应的第三方支付平台。进一步地，支付平台接口202接收支付结果并将支付结果发送到收银台前端201。进一步地，支付平台接口202将支付结果和交易明细发送到收银台服务系统203。收银台服务203根据来自支付平台接口202的支付结果和交易明细更新记录。收银台服务203异步将支付结果和交易明细发送到业务系统的业务系统后台102。

财务数据处理系统30包括业务数据库301、清分数据库302以及财务凭证系统303。业务数据库301接收来自业务系统10的业务系统后台102的业务数据。业务数据包括：订单数据、交易数据、和支付结果。其中，订单数据包括业务信息或其一部分。交易数据包括交易号，或交易号及交易明细或其一部分。清分数据库302接收来自第三方支付平台的清分数据，即定期从银行或会员余额系统接收其推送的清分数据。财务凭证系统303利用业务数据库301的业务数据和清分数据库的清分数据，进行清分对账，并根据财务系统的要求制作业务凭证和清分凭证。

财务系统40包括凭证数据库401。凭证数据库401接收来自财务数据处理系统30的财务凭证系统303的清分凭证。

由此，本发明的业财一体化系统实现了业务系统10与财务系统40之间的整合。在业财一体化系统内部的各个系统之间实现了数据共享和过程关联，能够极大地提高企业的运行效率，给使用者带来更好的客户体验。

本发明的业财一体化系统能够适用于多种业务形态。举例而言，本发明的业务系统可以适用于车辆租赁系统、网络约车系统、外卖系统等各种业态。这些业务形态的一个特点在于交易频率高、交易地点的范围广、客户体验的要求高、财务数据处理的难度大。在业务系统与财务系统分离的情况下，企业必须投入大量的人力去处理每天产生的海量业务数据和财务数据，进行财务的清分和对账，制作相关的财务凭证。这成为企业运营成本居高不下的重要原因之一。在应用本发明的业财一体化系统的一些实施例中，独立统一的收银台能够适应这些企业的交易频率和交易地点的特点。财务数据处理系统通过对业务数据和清分数据的整合能够实现自动清分对账并制作财务凭证。这能够极大地降低企业的运营成本。

图2是根据本发明一个实施例的业财一体化系统数据流动示意图。为了更好地说明数据在各个系统之间的流转，收银台20的支付平台接口202被单独表示出来。然而，支付平台接口202仍应当被认为是收银台20的一部分。

根据本发明的一个实施例，收银台20进一步包括收银台管理模块204。收银台管理模块204用于支持运维人员对收银台20进行配置和管理。

根据本发明的一个实施例，收银台与外部的数据中心205、日志服务模块206、以及APPID服务模块207连接以获得相关的服务。为了更好地说明数据的流动和服务的关联，数据中心205、日志服务模块206、以及APPID服务模块207在图2中被单独地表示。在本发明的其他一些实施例中，它们也可以相互整合成一个或多个提供多种服务功能的实体。

数据中心205用于对运维人员，例如客服人员或者管理员，提供登录和鉴权服务。数据中心205从收银台20的收银台前端201获得登录收银台20人员的登录信息，鉴权后将鉴权结果返回收银台前端201。日志服务模块206和APPID服务模块207从收银台20的收银台服务系统203获得日志数据和密钥，提供日志服务和加密密钥鉴权服务。

如图所示，业务系统10的用户或者门店会员通过业务系统10产生订单。在本发明的一些实施例中，业务系统10的订单包括用户使用业务系统提供的服务产生的订单，例如：约车订单、租车订单、外卖订单等等。这些订单无论是先付费或者是后付费都可以应用本发明的业财一体化系统。这些信息是财务系统40所关心的。另一方面，业务系统10的订单也包括使用类似金融功能产生的订单，例如储值卡充值订单、储值卡消费订单、会员积分消费订单、营帐系统变动订单等等。这些订单并不涉及与银行的清分对账。但是，对这些订单所涉及的储值卡信息、会员信息或者营帐信息的变动也需要与会员余额系统清分对账并制作相关凭证。

业务系统10根据订单向收银台20发送交易请求。为了降低数据传输的负担，业务系统10仅将订单中与交易相关的数据发送到收银台20。根据本发明的一个实施例，交易请求仅包括订单号和待支付信息，例如订单号、支付方式、支付金额、币种。业务系统10将包括订单详情的业务数据发送到财务数据处理系统30以生成财务凭证。根据本发明的一个实施例，业务数据包括：订单号、业务代码、用户信息、提供服务者的信息、交易号、支付方式、支付金额、币种等信息。交易请求的数据量较少保证了传输的高效率以及负载处于可控制的范围。业务数据中包括了更多的订单数据，交易数据和支付结果。虽然数据量较大，但是由于对于实时性要求不高，并不会为系统增加较大的负担。而且，业务数据具有足够的信息量能够满足后续制作业务凭证和清分对账的需要，也能够在出现清分对账失败时，财务人员能够容易地发现清分对账失败的原因，提高工作效率。

进一步地，收银台20的收银台前端201实时地向业务系统发送支付结果，以通知业务系统支付是否成功。而且，收银台20的收银台服务系统203也异步地向业务系统发送支付结果和支付明细。这种方式既保证了结果反馈的实时性，也避免了由于传输等原因而造成的信息缺失，使得业务系统能够保存完整的与订单有关的信息。

财务数据处理系统定期从第三方支付机构(包括会员余额系统)获得清分数据。财务数据处理系统利用业务数据和清分数据，进行清分对账，制作财务凭证(包括业务凭证和清分凭证)并将其推送到财务系统40。

本领域技术人员应当注意，以上的数据流转过程可以充分地说明本发明的业财一体化系统的优势。本发明的业财一体化系统中业务系统通过云端的负载均衡应对大量的突发流量。现有技术中已经存在非常成熟的技术，在此不再赘述。在现有的体系中，收银功能通常与业务功能整合而实现负载均衡。但是，由于业务与财务很多项目并不对应，甚至是完全是两套不同的体系，兼具业务和收银功能的系统结构会变得非常复杂，难以提供更多财务方面的支持。本发明的业财一体化系统中收银台被分离而成为独立的系统，因此本发明的收银台也需要解决负载均衡的问题。为此，本发明通过重新定义业务系统与收银台之间的交易请求，交易请求仅包括很少的数据量，减少了两个系统之间数据交换的规模，避免了频繁的数据交换。另一方面，本发明的收银台也采取了相应的服务分类和负载均衡措施(随后详述)。这使得本发明同样能够适应大量的突发流量，从而增加系统的稳定性。类似地，数据中心、日志和APPID服务的外部支持也有利于负载均衡。

与收银台不同，财务数据处理系统对计算能力有要求但是对实时性要求不高，因此不需要特别地考虑负载平衡。业务系统发送到财务处理系统的数据为业务数据，其包括了来自收银台的交易数据和支付结果。清分数据也同样发送到财务数据处理系统。财务数据处理系统可以配置在云端，利用云端的计算能力；也可以配置在企业内部的服务器上。

财务人员使用企业内部服务器上的财务系统并可以查看凭证数据库中的凭证。进一步地，财务人员可以在授权范围内使用财务数据处理系统以进行人工清分对账和手动制作财务凭证。财务人员一般不被允许直接访问业务系统以及收银台。财务数据处理系统可以包括相应的接口实现业务系统和收银台的受限查询。在保证财务人员能够获得所需信息的基础上避免了不必要的权限授权。或者，财务人员通过有授权的运维人员获得所需信息。这样可以进一步保证业财一体化系统的信息安全。

图3是根据本发明一个实施例的收银台的结构示意图。图4是根据本发明一个实施例的收银台技术实现方式的示意图。如图所示，收银台采用分层架构，包括：收银台服务T2/T1、收银台前端T3、收银台管理T3；其中收银台服务T1以业务逻辑层BLL形式体现在收银台服务T2/T1中；收银台数据库以数据访问层DAL形式体现在收银台服务T2/T1中。

收银台服务T2/T1是收银台的核心。如图所示，业务系统10通过调用收银台前端T3提供的支付页面推送交易请求(1)；收银台前端T3调用收银台服务T2推送交易请求(2)，调用APPID服务完成鉴权(3)。APPID服务用来对接收的数据进行验证。完成鉴权后进入支付阶段。收银台服务T2/T1调用支付平台接口202向对应的第三方支付平台推送支付请求(4)，并返回支付结果和交易明细(5),调用APPID服务完成鉴权(6)。收银台服务T2/T1将支付结果和交易明细推送到业务系统10(7)，调用日志服务推送日志信息(8)。如果需要向用户发送短信，收银台服务T2/T1调用短信服务(9)，通知用户。由此，完成了交易。

对于储值卡或者会员积分等消费订单，收银台前端T3将推送订单数据到支付平台接口202(10)，支付平台接口202返回支付结果和交易明细到收银台前端T3(11)，收银台服务T3调用收银台服务T2/T1(12)，收银台服务T2/T1调用数据处理服务T2/T1(13)，实现三级账更新。收银台服务T2/T1调用日志服务推送日志信息。

对于运维人员对于收银台的管理，收银台管理T3调用收银台服务T2/T1完成收银台的管理(14)，调用APPID服务完成鉴权,收银台服务T2/T1调用日志服务推送日志信息。

参考图4，进一步说明在分层架构下收银台服务的配置情况。如图所示，收银台可以分成用户界面层UI层、业务逻辑层BLL层和数据访问层DAL层。具体而言，收银台前端T3和收银台管理T3可以被认为处于UI层，用于界面展示、与用户信息的获取和反馈。举例而言，收银台前端T3可以向用户提供支付界面并确认用户的支付服务。收银台管理T3用户向运维人员，例如客服人员或管理员提供基础数据管理、交易记录查询、支付补登和退款等功能的界面。收银台服务T2和T1可以被认为处于业务逻辑层。收银台服务T2实现了收银台的主要数据处理功能，包括订单支付、基础数据管理、交易记录查询、支付补登和退款等。进一步地，收银台服务T2可以调用收银台的数据处理服务；或者收银台的数据处理服务可以被认为整合在收银台服务T2中。收银台服务T1为与收银台数据库相关的服务，例如基于EntityFramework开发的服务。通过使用收银台服务T1，开发者可以摆脱SQL。换言之，即使不懂SQL也能完成对数据库的操作。由此，本发明的收银台可以更具有开发的灵活性和更高的适应性。即使数据库的部分有所改变，收银台并不需要重新开发。进一步地，收银台数据库、数据中心、日志服务、APPID服务以及短信服务可以被认为处于数据访问层DAL，或者T0层。以收银台数据库为例，收银台数据库支持交易数据、基础数据管理、交易记录查询、支付补登和退款等记录的存储。根据本发明的一个实施例，与日志服务互动的功能也可以被整合到收银台数据库中而由收银台数据库实现与日志服务有关的操作。

图5是根据本发明一个实施例的收银台布置示意图。如图所示，收银台前端可以布置在前端网络的客户侧服务器群上。前端网络通过防火墙501、负载均衡器502和读写分离系统503与业务系统相连。收银台服务T2/T1可以布置在公共网络的公共服务器群上，其通过负载均衡器504与前端网络相连。收银台数据库可以布置在数据库网络上，其通过读写分离系统505与公共网络相连。收银台管理T3可以布置在企业的管理网络上。管理网络通过VPN506与业务系统相连。管理网络进一步地与前端网络、公共网络和数据库网络都相互连接。通过将收银台布置在多个网络上，并通过适当的负载平衡系统使得本发明的收银台即使在应对大量突发流量时也能保持系统的稳定。

图6是根据本发明一个实施例的收银台数据库结构示意图。图7是根据本发明一个实施例的数据库流程示意图。如图6所示，数据库主要存储表为交易池主表和交易池子表。交易池主表反映交易的状态，例如交易池主表S＝(0-待交易、1-交易成功、2-交易失败、3-交易超时、4-交易取消)。交易池子表反映交易请求的状态，例如交易池子表S＝(0-未请求、1-已请求、2-交易成功、3-交易失败、4-交易超时、5-交易取消、6-重复交易)。相应地，数据库维持与数据中心有关的数据中心推送主表和数据中心推送子表，二者与交易池主表和交易池子表相连。

对于已经存在的请求，数据库维持交易请求信息表和退款请求信息表。二者与交易池主表和子表相互连接。进一步地，数据库维持支付请求信息表，包括但不限于会员余额支付请求信息表、聚合支付支付请求信息表、有线POS支付请求信息表、无线POS支付请求信息表等。相应地，数据库维持支付结果信息表，包括但不限于会员余额支付结果信息表、聚合支付支付结果信息表、有线POS支付返回表、无线POS接收表。

参考图7，C、U、R、和D四个字母分别代表新增C、修改U、读取R、删除D；S：表示交易状态。订单号：由各业务系统生成，收银台不做限制和规定。交易号：由收银台生成，例如交易流水号。支付号：由各支付平台生成，若支付平台不产生支付号，则取用具有参考意义的唯一号码，例如：银行POS支付方式取用POS流水号。图7中的相同交易是指收银台目前允许交易池主表存在一笔待支付交易(状态码为0)，多笔已请求交易(状态码为1)。

以下以数据库的变动为线索，详细表示收银台的交易过程。整个交易过程700中从请求检测完成开始(点击立即支付)-交易完成(包括成功、失败、超时、取消)，不包括交易信息返回。具体包括如下步骤：

在步骤701，交易请求进入，首先根据交易类型TradeType、订单号OrderCoding和交易流水号JYLS查找交易请求表TradeRequest；

在步骤702，判断是否是第一次发起的交易，查找无记录则是，有记录则不是；

在步骤703，无记录则请求表TradeRequest新增一条记录；否则，直接转到步骤707；

在步骤704，收到立即支付确认后，主表DealTradeMain新增一条记录，状态DealStatus为0待交易；子表DealTradeChild新增一条记录，状态Status为0未请求

在步骤705，收银台自动向第三方渠道发起支付请求。详述如下：

若是会员余额交易，则向会员余额请求表插入一条请求记录，同时子表DealTradeChild状态Status修改为1已请求；

若是微信或支付宝或银行卡等现在支付交易，则向现在支付请求表插入一条请求记录，同时子表DealTradeChild状态Status修改为1已请求；

若是有线POS交易，则向有线POS请求表插入一条请求记录，同时子表DealTradeChild状态Status修改为1已请求；

若是无线POS交易，则向无线POS请求表插入一条请求记录，同时子表DealTradeChild状态Status修改为1已请求；

在步骤706，待第三方支付完成后，根据不同情况采取如下动作：

若是会员余额交易，则向会员余额返回表插入一条响应记录，同时子表DealTradeChild状态Status根据实际交易结果修改(2成功、3失败、4超时)，主表DealTradeMain状态DealStatus修改(1成功、2失败、3超时)

若是微信或支付宝或银行卡等现在支付交易，则向现在支付同步返回表插入一条记录，现在支付异步通知返回表插入一条记录，同时子表DealTradeChild状态Status根据实际交易结果修改(2成功、3失败、4超时)，主表DealTradeMain状态DealStatus修改(1成功、2失败、3超时)

若是有线POS交易，则向有线POS返回表插入一条记录，同时子表DealTradeChild状态Status根据实际交易结果修改(2成功、3失败、4超时)，主表DealTradeMain状态DealStatus修改(1成功、2失败、3超时)

若是无线POS交易，则向无线POS返回表插入一条请求记录，同时子表DealTradeChild状态Status根据实际交易结果修改(2成功、3失败、4超时)，主表DealTradeMain状态DealStatus修改(1成功、2失败、3超时)

在步骤707，如果有记录则不是第一次发起，则根据请求表TradeRequest的主键TradeRequestID查找主表DealTradeMain和子表DealTradeChild

在步骤708，如果若主表和子表没有记录，则按704到706步骤流程规则处理；

在步骤709，如果若主表DealTradeMain状态DealStatus＝1,子表DealTradeChild状态Status＝2表示成功，则跳转到相应成功页面；

在步骤710，如果主表DealTradeMain状态DealStatus＝2,子表DealTradeChild状态Status＝3表示失败，则向子表DealTradeChild插入一条记录，状态Status为0未请求，随后按照705到706步骤流程规则处理；

在步骤711，如果主表DealTradeMain状态DealStatus＝3,子表DealTradeChild状态Status＝4表示超时，则向子表DealTradeChild插入一条记录，状态Status为0未请求，随后按照705到706步骤流程规则处理；

在步骤712，如果主表DealTradeMain状态DealStatus＝0,子表DealTradeChild状态Status＝0表示未请求，按如下情况处理：

如果不是无线POS交易，未向第三方支付发起请求，则更新原交易信息，随后按照705到706步骤流程规则处理；

如果是无线POS交易，判断时间差＝(系统当前时间-子表DealTradeChild创建时间CreateTime)，小于120秒提示“已存在无线POS待支付交易，请返回业务系统查看”，否则提示是否取消交易；

在步骤713，如果主表DealTradeMain状态DealStatus＝0,子表DealTradeChild状态Status＝1表示已请求，即第三方支付正在进行，提示是否取消原交易；

在步骤714，如果选择不取消则结束流程；

在步骤715，如果选择取消则重新查询主表和子表；如果当前主表DealTradeMain状态Satus不等于1，则主表状态为0，子表状态为1的记录更改为5取消然后按照705到706步骤流程规则处理；

在步骤716，如果选择取消然而原交易继续进行，则成功后根据异步推送的交易请求单号匹配子表记录，将子表DealTradeChild状态Status修改为6重复交易，主表状态DealStatus更新为1。

在步骤717，如果原交易请求成功，根据交易请求号查找对应的交易池子表记录；

在步骤718，如果子表S＝1，则表示交易成功；

在步骤719，如果子表S不等于1，则代表确实发出了重复交易，将子表DealTradeChild状态Status修改为6重复交易，主表状态DealStatus更新为1。

根据本发明的一个实施例，订单池主表一个交易请求只有一个条交易单信息。子表有多条交易记录，分别对应不同交易请求，但是正常的成功状态Status＝1只有一条，可以有多条重复交易成功信息Status＝6。

根据本发明的一个实施例，所有更新交易池子表交易状态和交易池主表交易状态，都要注意：若交易池主表是交易成功Status＝1,则只更新交易池子表状态，不更新交易池主表状态。

图8是根据本发明一个实施例的财务数据处理系统的示意图。如图所示，财务数据处理系统包括业务数据库801、清分数据库802、清分对账模块803、业务凭证模块804、清分凭证模块805和凭证推送模块806。

业务数据库801用于从业务系统接收业务数据。业务数据包括订单数据、交易数据和支付结果。根据本发明的一个实施例，业务系统每次推送数据至财务数据处理平台时，业务数据中均需包含订单详细信息。根据本发明的一个实施例，业务数据包括：业务类型、订单号、用户信息、服务提供者信息、服务地点、交易时间、交易金额、交易状态、支付渠道、支付号、支付方式、币种等信息。

清分数据库802用于从第三方支付平台接收清分数据。清分数据包括银行清分数据和会员余额清分数据。举例而言，银行的清分数据包括银行代码、汇总金额、清分日期、交易号、金额、手续费、交易日期等信息。会员余额清分数据包括支付会员信息、收款会员信息、业务类型、清分日期、交易号、金额、手续费、交易日期等信息。

清分对账模块803用于实现自动或手动的清分对账功能。具体而言，清分对账，即第三方支付机构提供的清分数据与业务流水明细进行对账。

举例而言，银行的对账可以按照如下规则进行：在银行提供的清分明细数据中某交易号的交易金额与业务系统中该交易号的交易金额相比较；如果金额相等，则该交易号对应的清分明细对账相符，即对账成功；如金额不等，则该交易号对应的清分明细对账不平，即对账失败。

举例而言，会员余额的对账可以按照如下规则进行：会员余额对账分为汇总对账和明细对账。如果某交易号数据汇总对账和明细对账成功，则该交易数据会员余额清分对账成功；如某交易号数据汇总对账或明细对账失败，则该交易数据会员余额清分对账失败。

对于汇总对账，会员余额提供的清分明细数据中某交易号交易金额与业务系统数据中该交易号交易金额比较，如金额相等，则该交易号对应的清分汇总对账相符，即对账成功；如金额不等，则该交易号对应的清分汇总对账不平，即对账失败。

对于明细对账，某交易号对应的清分汇总对账对符后，进行该交易号明细对账，分别核对实充金额、实储金额、返利金额是否相等；如实充金额、实储金额、返利金额分别相等，则该交易号对应的清分对账对符，即对账成功；如对应金额分别不等，则交易号对应的清分对账不平，对账失败。当然如某交易数据的汇总清分对账不平，该数据不再进行明细对账。

业务凭证模块804用于根据业务数据制作业务凭证。业务凭证包括但不限于：预收凭证、收入凭证、退款凭证、充值凭证、储值卡售卡还款凭证、储值卡过期凭证等。

清分凭证模块805用于根据清分对账模块803的对账结果制作清分凭证。清分凭证包括第三方支付机构提供的清分数据与其对应的业务明细数据，其包括但不限于银行清分凭证和会员余额清分凭证。

举例而言，银行清分凭证包括：所属银行代码、汇总金额及明细金额数据、匹配的订单号、支付号、交易时间、清分时间、服务者信息等信息。会员余额清分凭证包括汇总及明细数据、实充、实储金额、交易时间、清分时间、会员信息等信息。

凭证推送模块806将业务凭证与清分凭证推送到财务系统。根据本发明的一个实施例，业务凭证模块804、清分凭证模块805和凭证推送模块806可以统一配置为一个凭证制作模块或有其他配置。这些配置都在本发明的保护范围之中。

由此，财务数据处理系统实现了自动地清分对账和财务凭证制作功能。这可以极大地减少财务人员的工作负担，提高工作效率，降低企业的成本。更为重要的是，对于移动互联网的业务场景，本发明的财务数据处理系统同其他系统分离而不必面对大量的突发数据，从而既保证了系统的运行平稳也降低了企业的负担。

图9是根据本发明一个实施例的业财一体化管理方法。该方法包括如下步骤：

在步骤901，从业务系统接收交易请求；

在步骤902，利用收银台完成支付并向业务系统返回支付结果；

在步骤903，从业务系统接收业务数据；

在步骤904，从第三方支付平台接收清分数据；

在步骤905，在财务数据处理系统利用接收的订单数据和交易数据以及清分数据进行清分对账；

在步骤906，在财务数据处理系统利用接收的订单数据和交易数据以及清分数据制作财务凭证；以及

在步骤907，向财务系统推送财务凭证。

图10是根据本发明一个实施例的清分对账方法，包括如下步骤：

在步骤1001，从第三方支付平台接收清分数据。清分数据包括从银行接收的银行清分数据或者从会员余额系统接收的会员余额清分数据。银行或者会员余额系统可以定期(例如每天)向财务数据处理系统发送清分数据。本领域技术人员应当理解，根据不同企业业务类型的不同，清分数据也可能有其他的来源。

表1是根据本发明一个实施例的银行清分数据的例子：

在步骤1002，接收业务数据。业务数据包括订单详细数据、交易数据和支付结果。根据本发明的一个实施例，业务数据包括订单详细数据以使得业务凭证模块能够以此制作业务凭证，进行清分对账，并且使得财务人员在大多数情况下能够查询订单详情而确定未能清分对账成功的原因，以提供工作效率。

表2是根据本发明一个实施例的业务数据的例子：

名称	类型	说明
			业务代码	文本	(略)
订单号	文本
			业务流水号	文本
交易号	文本
			会员ID	文本
交易日期	文本
			服务商品	文本
服务者代码1	文本
			服务者代码2	文本
订单状态	文本
			收费名称	文本
收费合计	文本
			交易类型	文本
支付渠道	文本
			支付号	文本
支付方式	文本
			支付金额	文本
币种	文本
			参考检索号	文本

在步骤1003，匹配业务数据与清分数据。如果针对一项交易，业务数据与清分数据相符合，则匹配成功；否则，匹配失败。根据本发明的一个实施例，所谓“相符合”是指交易相符并且金额相符。举例而言，如果在业务数据中和清分数据中都包括了指向同一项交易的数据，则业务数据中和清分数据中指向该项交易的数据可以被认为是交易相符的数据。如果交易相符的数据中，业务数据的金额与清分数据的金额也相同，则可以认为交易相符的数据金额也相符。由此，可以认为匹配成功。

以下以银行清分数据和会员余额清分数据的清分对账为例，详细说明业务数据与清分数据的匹配方法。本领域技术人员应当理解，其他类型的清分数据也可以比照该两种清分数据以类似的方法进行。

在本发明的一些实施例中，银行清分数据的匹配可以按照如下方法进行：

在步骤1010，选择在银行清分数据中一个交易号；

在步骤1011，在业务数据中查找该交易号；

在步骤1012，响应于在业务数据中查找到该交易号，比较银行清分数据中该交易号对应的交易金额与业务数据中该交易号对应的交易金额；

在步骤1013，响应于银行清分数据中该交易号对应的交易金额与业务数据中该交易号对应的交易金额相等，则该交易号对应的清分明细对账相符，即匹配成功；

在步骤1014，响应于在业务数据中未查找到该交易号，或者银行清分数据中该交易号对应的交易金额与业务数据中该交易号对应的交易金额不相等，则无该交易号对应的业务明细或者该交易号对应的清分明细对账不平，即匹配失败。

本领域技术人员应当理解，以上的清分对账采用的索引是交易号。也可以采用银行清分数据中的其他标识作为索引来进行清分对账，例如参考检索号。当然，该索引也应当包括在业务数据之中。

在本发明的一些实施例中，对于预授权业务，将其视为一项单独的交易，使用原刷取预授权业务的交易号进行对账。后续消费也视为一项单独的交易，使用消费时的交易号进行对账。在本发明的一些实施例中，对于退款业务，不再将其视为一项单独的交易。在进行匹配时，使用原刷取消费时的交易号进行对账。对于预售前业务的退款，使用刷取预售前业务的交易号进行对账。这样的设定可以保证匹配的顺利进行。

在本发明的一些实施例中，会员余额清分数据的匹配可以按照如下方法进行：

在步骤1020，选择在会员余额清分数据的一个交易号；

在步骤1021，在业务数据中查找该交易号；

在步骤1022，响应于在业务数据中查找到该交易号，比较会员余额清分数据中该交易号对应的汇总金额与业务数据中该交易号对应的汇总金额；

在步骤1023，响应于会员余额清分数据中该交易号对应的汇总金额与业务数据中该交易号对应的汇总金额相等，则比较该汇总金额下的各个分项金额；

在步骤1024，响应于会员余额清分数据中该交易号对应的汇总金额下各个分项金额与业务数据中该交易号对应的汇总金额下各个分项金额相等，则该交易号对应的清分明细对账相符，即匹配成功；其中各个分项金额包括但不限于：实充金额、实储金额、返利金额等。

在步骤1025，响应于以下情况，该交易号对应的清分明细对账不相符，即匹配不成功：

1.在业务数据中未查找到该交易号对应的交易；

2.会员余额清分数据中该交易号的对应的汇总金额与业务数据中该交易号对应的汇总金额不相等；

3.会员余额清分数据中该交易号对应的汇总金额下各个分项金额中任何一个分项金额与业务数据中该交易号对应的汇总金额下各个分项金额中对应的分项金额不相等。

本领域技术人员应当理解，以上的清分对账采用的索引是交易号。也可以采用银行清分数据中的其他标识作为索引来进行清分对账，例如参考检索号。当然，该索引也应当包括在业务数据之中。

在本发明的一些实施例中，会员余额系统可能有着更为复杂的结构，可能包括更多的分项金额，更复杂的计算规则。为了提高会员余额清分对账的效率，可以仅针对同一会员最后一次交易进行清分对账。如果最后一次交易清分对账的是匹配的，那么针对之前的清分对账可以仅比较汇总金额，而不必比较分项金额。如果最后一次交易清分对账是不匹配的，那么继续针对上一次交易清分对账，并以此类推。

在步骤1004，将匹配的业务数据与清分数据相关联。匹配的业务数据与清分数据为自动清分对账成功的数据。将匹配的业务数据与清分数据相互关联，从而完成清分对账。

在步骤1005，将未匹配的业务数据与清分数据进行展示。自动清分对账虽然简单方便，能够自动地完成大部分的清分对账工作，但是仍会有部分业务数据与清分数据存在不匹配的情况。这些情况将被归入出现异常财务数据的情况。

出现业务数据与清分数据存在不匹配的原因可能是业务系统或者银行系统的记录存在的不同所导致的。例如，对于某一交易号，其仅出现在了业务数据/清分数据中，清分数据/业务数据中缺少对应的匹配项。或者，对于某一交易号，业务数据与清分数据中交易相符的数据出现金额不符的情况。

业务数据与清分数据存在不匹配的原因还可能是形式问题。例如，交易号或金额出现格式错误，例如交易号或金额前面多了个“0”或者空格、交易号后面出现了空格、金额出现的位置错误等。这些形式问题也可能导致财务数据处理系统无法自动完成对账。

对于异常财务数据，财务人员可以以手工的方式将业务数据与清分数据相关联，进行手动清分对账。因此，在本步骤中，展示未匹配的业务数据与清分数据，以实现后续的手动清分对账。

在步骤1006，手动关联业务数据与清分数据。如前所介绍的，在本步骤中，财务人员以手动的方式将业务数据与清分数据关联，实现手动清分对账。财务人员比较未能匹配的业务数据与清分数据，确定未能匹配的原因。如果未能匹配的原因是格式问题等原因，财务人员可以在财务数据处理系统中将业务数据与财务数据关联，完成手动清分对账。

图11是根据本发明一个实施例的异常财务数据处理的流程图。对于异常财务数据，财务人员可以进行手工对账。进一步地，对于业务系统或者银行系统的记录不同导致的异常财务数据，财务人员需要查询导致记录不同的原因。

根据本发明的一个实施例，异常财务数据处理方法包括如下步骤：

在步骤1101，展示在清分对账过程中未能自动匹配的业务数据和清分数据。在一些实施例中，业务数据和清分数据分为两栏显示，并且按照相同的规则排序。举例而言，业务数据和清分数据都按照交易号以升序或者降序排列。进一步地，交易号相同的业务数据和清分数据可以在两栏中处于相同或接近的水平位置，以方便财务人员处理。当然，业务数据和清分数据也可以按照其他方式排序，例如按照交易时间进行排序。

财务人员检视未能自动匹配的业务数据和清分数据，根据不同的情况转到步骤1102和1105或者1108。

在步骤1102，展示在清分对账过程中自动匹配的业务数据和清分数据。在一些实施例中，业务数据和清分数据未能匹配的原因是财务数据处理系统在自动清分对账时将错误的业务数据和清分数据关联。因此，财务人员在进行手工对账时可能需要取消错误的自动匹配结果。在一些实施例中，业务数据和清分数据分为两栏显示，并且按照相同的规则排序。举例而言，业务数据和清分数据都按照交易号以升序或者降序排列。进一步地，交易号相同的业务数据和清分数据可以在两栏中处于相同或接近的水平位置，以方便财务人员处理。当然，业务数据和清分数据也可以按照其他方式排序，例如按照交易时间进行排序。

在步骤1103，取消业务数据与清分数据之间的关联。财务人员经过核对后，发现错误的自动匹配，则可以在此步骤中取消错误的自动匹配。

在步骤1104，手动关联业务数据与清分数据。财务人员取消错误匹配后，可以重新回到未匹配页面，手动关联业务数据与清分数据，实现手动清分对账。

在步骤1105，对于交易号未在业务数据中查询到的清分数据，查询与该交易号相关的日志。在本发明的一些实施例中，收银台在完成交易时所产生的日志可以存储在独立的日志服务模块或者收银台的数据库中。由于交易号是在收银台维持的交易池中顺序产生的，每个交易号都会有相应的日志。财务人员通过查询相应的日志就可以了解到交易的详细过程以及该交易号对应的信息未被发送到业务系统的原因。进一步地，财务人员可以由此了解该交易号对应的信息未被转发到财务数据处理平台的原因以及该交易号被银行或者会员余额系统记录的原因。具体而言，财务数据处理系统可以包括第一查询接口，财务人员可以通过该接口输入查询信息(例如交易号)向日志服务模块或者收银台数据库发出请求。日志服务模块或者收银台收到请求后，调取相应的日志发送给财务数据处理模块，供财务人员浏览。根据本发明的一个实施例，日志服务模块或者收银台数据库，或者财务数据处理系统包括日志翻译模块。由于对于非技术人员，日志可能很难理解。通过日志翻译模块可以将日志翻译成财务人员或者业务人员能够理解的方式呈现。对于属于收银台或业务系统的原因，转到步骤1106；否则，直接转到步骤1109。

在步骤1106，生成该交易号对应的业务数据并将该交易号对应的业务数据与该交易号对应的清分数据相关联。由于收银台或业务系统的原因导致该交易号对应的业务数据未被发送到财务数据处理系统的情况，财务人员可以手动合并订单详细数据与该交易号对应的交易数据而生成业务数据，并手动完成业务数据与清分数据的关联。

在步骤1107，对于交易号相符但金额不符的情况，查询与该交易号相关的日志以及业务系统的订单。在本发明的一些实施例中，收银台在完成交易时所产生的日志可以存储在独立的日志服务模块或者收银台的数据库中。财务人员通过查询相应的日志就可以了解到交易的详细过程以及交易金额。具体的步骤与步骤1105类似，这里不再赘述。进一步地，财务人员可以查询业务系统，以获得更多业务方面的信息。具体而言，财务数据处理系统可以包括第二查询接口，财务人员可以通过该接口输入查询信息(例如交易号)向业务系统发出请求。业务系统收到请求后，调取相应的订单发送给财务数据处理模块，供财务人员浏览。对于属于业务系统或者收银台的原因，转到步骤1108；否则，转到步骤1109。

在步骤1108，修改该交易号对应的业务数据并将该交易号对应的业务数据与该交易号对应的清分数据相关联。由于收银台或业务系统的原因导致该交易号对应的业务数据金额与清分金额不符的情况，财务人员可以手动修改订单详细数据或者该交易号对应的交易数据而生成新的业务数据，并手动完成该业务数据与清分数据的关联。

在步骤1109，导出未匹配的清分数据。对于这一部分未能匹配的清分数据，造成未匹配的原因可能是银行或者会员余额系统的出现了问题。这一部分清分数据可以导出。导出后的数据可以发送回银行或者会员余额系统。

根据本发明另一个实施例，财务人员并不被授权查询业务系统以及收银台。财务数据处理系统也就不必包括第一查询接口和第二查询接口。在步骤1104之后，财务数据处理系统将未能匹配也未能找出原因的业务数据和清分数据导出，并将这些导出的数据发送给运维人员。运维人员具有更高的权限，能够查询业务系统和收银台系统。运维人员查询这些导出的数据对应的订单和交易日志。如果未能匹配的原因是业务系统或者收银台的原因，运维人员做出相应的修改再将修改后的业务数据推送到财务数据处理系统进行自动清分对账。或者，运维人员将这些内容返回给财务人员。财务人员利用这些信息进行手动清分对账。对于未能匹配的原因不属于业务系统或收银台的情况，财务人员将其导出并返回给银行或者会员余额系统。

对于异常财务数据的追踪和改正是现有的财务系统或者业务系统无法完成的工作，往往需要财务人员以电话或者电子邮件的方式联系业务部门核对订单及支付情况，费时费力而且效率极低。在本发明的财务数据处理系统中已经包括了业务数据(包括订单详细数据和交易数据)以及清分数据。对于大多数的异常财务数据，财务人员根据财务数据处理系统中已有的数据已经能够判断问题的来源，并进行手工清分对账。进一步地，财务数据处理系统可以包括查询业务系统和收银台相关信息的接口，以进一步从业务系统和收银台获得与异常财务数据有关的信息，方便财务人员发现业务数据和清分数据未能匹配的原因，从而实现对异常财务数据的处理。

图12是根据本发明一个实施例的退款的方法示意图。退款申请可以由用户提出，经过业务系统审核认为符合退款条件，即可以发起退款请求。或者，财务人员经过清分对账发现存在需要退款的情况，财务人员也可以发起退款请求。根据本发明的一个实施例，退款方法包括如下步骤：

在步骤1201，接收退款请求。收银台作为执行退款的主体，可以从业务系统或者财务数据处理系统(财务人员)接收退款请求。

在步骤1202，根据退款请求中的原交易号，查询原交易信息；并比较退款请求中的交易信息与查询的原交易信息。收银台首先要确定退款请求中的原交易号与退款请求中的交易信息是否匹配。收银台根据退款请求中的原交易号查询收银台中存储的交易信息，然而将查询得到的交易信息与退款请求中的交易信息进行比较。如果比较的结果不一致，则直接退回退款请求。

在步骤1203，响应于原交易号与原交易信息一致，判断原交易号的交易余额是否超过本次退款请求金额。原交易号可能已经发生过退款。原交易号对应交易的交易金额与累计已发生的退款金额总和之差即为原交易号的交易余额。如果交易余额小于退款请求金额，说明退款请求存储错误，则直接退回退款请求。根据本发明的一个实施例，已经发生过的退款，即包括退款已经实际完成的退款请求，也包括退款进行中但是退款请求提出的时间早于本次退款请求的退款请求。

在步骤1204，响应于原交易号的交易余额是否超过本次退款请求金额，生成交易单。经过步骤1202和1203后，退款请求已经通过了收银台的审核，收银台生成退款交易单，开始执行退款操作。根据本发明的一个实施例，收银台保存退款信息并生成GUID唯一码并获取退款渠道信息。GUID唯一码用于数据库操作，能够加快数据库检索的速度。进一步地，收银台在交易池中生成本次退款交易的交易码，并将本次退款请求信息存入交易池。然后，根据退款渠道信息，生成用于退款的退款交易单。

在步骤1205，响应于原交易号与原交易结果匹配，生成交易请求参数，发出退款交易请求；响应于原交易号与原交易结果不匹配，根据原始交易信息生成交易请求参数，并发出退款交易请求。收银台通过验证原交易号与原交易结果的对应关系来确定正确的交易请求参数，以发出退款交易单的退款请求。如果原交易号与原交易结果不匹配，例如退款请求中原交易号对应的交易结果是超时，而收银台记录的原交易结果是成功，那么有可能是交易请求参数有误。因此，收银台以原始交易信息生成交易请求参数向第三方支付机构或会员余额系统发出退款交易请求。

根据本发明的一个实施例，如果是会员余额系统的退款，还需要考虑会员余额交易是否处于余额冻结的状态。如果会员余额系统中该会员未处于余额冻结状态，则利用余额退款专用接口发出退款请求。如果会员余额系统中该会员已经处于余额冻结状态，则可以暂时通过会员余额冻结、撤销接口撤销会员余额冻结状态，然后完成退款。

如前所述，退款交易也被作为交易的一种。收银台利用与消费交易类似的方式处理交易。以图7实施例所描述的实施例为例，退款交易也具有自己的交易号而在交易池中与其他类型的交易以相同的方式处理。

在步骤1206，响应于退款交易成功，接收退款交易结果。进一步地，收银台可以将交易结果异步反馈到业务系统。

在步骤1207，响应于退款交易失败，转为人工处理。

在步骤1208，响应于退款交易超过预定时间(例如1分钟)，收银台生成退款查询，并定时轮询待确认退款交易的状态。由于第三方支付机构或者会员余额系统也可能需要审核退款交易，因此第三方支付机构或者会员余额系统反馈时间可能比较长。因此，仍然将其保留在交易池中会占用过多的系统资源。因此，收银台单独通过一个任务轮询机制重复确认退款交易状态，直到交易成功/失败。

图13是根据本发明一个实施例的凭证生成方法的示意图。如图所示，凭证生成方法包括如下步骤：

在步骤1301，接收业务数据。业务数据包括订单详细数据、交易数据和支付结果。根据本发明的一个实施例，业务系统可以将订单详细数据、交易数据和支付结果整合为业务数据并发送到财务数据处理系统。表2示出了一个业务数据的例子。

表3是根据本发明一个实施例的营帐类型业务数据的例子：

名称	类型	说明
			预付	文本+数字	(略)
先付	文本+数字
			押金	文本+数字
预授权	文本+数字
			现结收费	文本+数字
付转	文本+数字
			退款	文本+数字
扣款	文本+数字
			内部结算	文本+数字

表4是根据本发明一个实施例的会员余额系统的业务数据的例子：

在步骤1302，根据业务数据制作业务凭证。根据本发明的一个实施例，业务凭证包括但不限于预收凭证、收入凭证、退款凭证、以及会员充值凭证。业务凭证的内容根据财务系统的具体要求不同而会有所不同。在一些实施例中，业务凭证包括但不限于以下内容：订单号、业务类型、会员ID、服务提供商、服务商品、收费金额、收费详情、交易类型、交易号、支付渠道、支付方式等信息。

根据本发明的一个实施例，制作业务凭证具体可以包括如下步骤：

在步骤1320，从业务数据中提取数据。财务数据处理系统从业务数据库中的业务数据根据业务凭证的要求提取所需的数据。

在步骤1321，根据转换表转换提取的数据。转换表包括但不限于：业务系统构架转换表、基础数据转换表、以及业务代码转换表。财务数据处理系统通过转换表来对数据进行转换。财务系统中对于组织机构、基础数据和业务代码的设置与业务系统会有所不同。而且，业务系统由于需要调整的频繁程度也远远高于财务系统。因此，业务数据中的很多数据，例如组织机构、基础数据和业务代码，财务系统并不直接了解其含义。而各个转换表的作用就在于将业务数据翻译成财务系统能够了解的数据。

以业务系统架构转换表为例，业务数据中可能显示一笔交易来自南京的第二门店。而财务系统中只存在南京分公司。因此，需要利用组织结构转换表将业务数据中南京第二门店转换为南京分公司。经过转换后的数据生成的凭证财务数据才能理解，进而审核通过成为合规的凭证。

以基础数据转换表为例，业务数据中可能显示一笔交易的类型是“储值卡返利”。而财务系统中此类交易归为“内部往来不收款”。因此，需要利用基础数据转换表将“储值卡返利”翻译为“内部往来不收款”。

以业务代码转换表为例，业务数据中可能显示一笔交易的业务代码是“DZ03”，其表示针对某一大型客户的短租业务。然而，财务系统将此类业务都归为短租业务DZ。因此，需要利用业务代码转换表将“DZ03”翻译为“DZ”。

本领域技术人员应当理解，以上三种类型的转换表仅仅是为了说明的目的。转换表的类型和形式并不限于这三种类型。例如，交易类型、支付方式、支付渠道等也可以利用相似的转换表进行转换。引入转换表的另一个优点在于，在相互独立的业务系统和财务系统建立起沟通的渠道。而无论是业务系统或者财务系统的更新，只需要修改转换表就能够实现新的关联。

在步骤1322，生成业务凭证，并推送到财务系统。财务数据处理系统可以直接利用经过转换后的数据生成业务凭证。财务数据处理系统可以即时或者定期向财务系统推送生成的业务凭证。根据本发明的一个实施例，业务凭证可以根据规则而推送到不同的目的地，用于实现财务记录实际经济往来，进行财务管理。

在步骤1323，响应于业务凭证推送失败，展示转换后的数据。业务凭证如果推送失败，则可能是业务凭证未能通过财务系统的审核。通过向财务人员展示转换后的数据，财务人员可以了解未能通过审核的原因并对凭证进行修改。

在步骤1323，手动生成业务凭证。财务人员查看后可以手工生成业务凭证。进一步地，财务人员可以手动向财务系统推送业务凭证，并可以实时获得财务系统的反馈。由此，实现业务凭证的制作和推送。

转到步骤1302，在步骤1303，接收清分对账成功的结果。对于清分对账成功的清分数据，财务数据处理系统生成清分凭证。

在步骤1304，根据清分对账成功的结果，制作清分凭证。清分凭证包括银行清分凭证和会员余额清分凭证。根据本发明的一个实施例，制作清分凭证的方法可以包括如下步骤：

在步骤1340，从清分数据中提取数据。财务数据处理系统从清分对账成功的清分数据中提取制作清分凭证所需的数据。

在步骤1341，根据转换表转换提取的数据。转换表包括但不限于：银行/会员余额系统构架转换表、基础数据转换表、以及业务代码转换表。对清分数据进行转换的转换表的作用与对业务数据进行转换的转换表类似，这里不再赘述。

在步骤1342，生成清分凭证，并推送到财务系统。财务数据处理系统利用转换后的数据生成清分凭证并即时或定期推送到财务系统。根据本发明的一个实施例，清分凭证可以根据规则而推送到不同的目的地，用于实现财务记录实际经济往来，进行财务管理。

在步骤1343，响应于推送失败，展示经过转换后的数据。在此步骤，财务人员可以查看并修改清分凭证中的数据。

在步骤1344，手动生成清分凭证。财务人员手动生成清分凭证，并可以即时将手动生成的清分凭证推送到财务系统。根据财务系统的反馈，财务人员被允许再次修改清分凭证并再次推送，直到推送成功。

财务数据处理系统集合了订单数据、交易数据以及清分数据，是数据汇集的中心。独立的财务数据处理系统，无需承担业务系统以及收银台对实时性的苛刻要求，也无需承担财务系统严格的保密和权限要求，成为辅助财务系统实现清分对账和生成财务凭证功能的重要工具，降低企业的成本，提高企业的运转效率。

图14是根据本发明一个实施例的财务信息处理方法示意图。在现有的业务系统和财务系统分离的体系中，业务系统和财务系统按各自的流程分别运作，经常出现信息更新不及时或者信息追踪困难的问题。在本发明的业财一体化体系中，提出了一种事件驱动的财务信息处理方法，其具体包括如下步骤：

在步骤1401，响应于财务事件的发生，分配第一标识符。根据本发明的实施例，财务事件的发生可以成为驱动业财一体化系统运行，处理财务相关信息，同步各个系统数据的起始点。在本发明的一些实施例中，财务事件包括但不限于：消费事件、交易补登事件、预授权事件、会员充值事件、会员返利事件和退款事件。

所谓消费事件包括用户使用企业所提供的服务并支付相应费用，既包括用户直接使用银行卡、支付宝、微信、ApplyPay等工具进行支付或者利用会员余额/储值卡进行支付。所谓交易补登事件包括用户使用现金支付或者其他原因未实时将交易录入业务系统时，由企业员工将交易补登方式录入系统。所谓预授权事件包括用户使用信用卡等情形在用户实际支付前先以预授权的方式获得后续支付的保证。所谓会员充值事件包括用户向储值卡或者会员余额中充入金额。所谓退款事件是指向用户或者会员余额/储值卡退回金额。本领域技术人员应当理解，以上仅仅是财务事件的一些实例。本发明的业财一体化系统可以包括更多或者不包括其他的财务事件。

当财务事件发生时，将第一标识符分配给所述财务事件。第一标识符包括订单号、业务流水号、复合代码(业务类型+发生地点代码+发生时间)等信息。当需要信息回溯时，根据第一标识符能够确定第一标识符所对应的财务事件以及该财务事件的详细信息。

在步骤1402，接收包括第一标识符的交易请求，分配第二标识符，生成包括第一标识符和第二标识符的支付请求。当财务事件发生后，生成交易请求向第三方支付平台(包括会员余额系统)发起支付。作为财务信息处理和数据留痕的要求，与第三方支付平台(包括会员余额系统)之间的支付也需要记录。在发起支付请求之前，分配第二标识符。第二标识符的一个实施例是交易号。本领域技术人员应当理解，其他能够区分支付请求的标识符也可以作为第二标识符。支付请求包括第一标识符和第二标识符，即可以包括订单号和交易号。根据本发明的一个实施例，一个第一标识符可以对应多个第二标识符。举例而言，一个订单号可以对应多个交易号。

在步骤1403，发起支付请求，接收包括第三标识符的支付结果。第三标识符，例如支付号或者检索参考号是第三方支付平台(会员余额系统)生成的标识符。第三方支付平台(会员余额系统)收到支付请求后，为分配请求分配支付号，并返回包括支付号的支付结果。根据本发明的一个实施例，支付结果中也包括第二标识符或者第一标识符和第二标识符。

在步骤1404，根据财务事件以及支付结果，生成业务数据；其中，业务数据至少包括第二标识符。业务数据是业务系统向财务数据处理系统推送的数据，包括了财务数据处理系统进行清分对账所需的数据，包括但不限于与财务事件有关的数据和与交易有关的数据以及支付结果。为了清分对账，业务数据至少包括第二标识符。根据本发明的一个实施例，业务数据也包括第一标识符和/或第三标识符。

在步骤1405，接收清分数据，所述清分数据至少包括第二标识符。清分数据来自于第三方支付平台(包括会员余额系统)。清分数据反映了经过第三方支付平台(包括会员余额系统)确认发射的支付行为。为了与业务数据进行对账，清分数据至少应当包括第二标识符。根据本发明的一个实施例，清分数据也包括第一标识符和/或第三标识符。

在步骤1406，利用业务数据与清分数据进行清分对账。利用第二标识符或者其他标识符，匹配清分数据与对应的业务数据。如果二者相匹配，则表示清分对账成功。关于清分对账的具体方式，可以参见之前的描述。

在步骤1407，响应于清分对账成功，制作清分凭证，并发送到财务系统。通过将清分凭证发送到财务系统，实现了从业务系统到财务系统的全流程财务信息的处理，在业务系统与财务系统之间建立起了桥梁。如果清分对账不成功，财务人员可以利用第二标识符，或者其他标识符，查询财务事件以及财务事件对应的交易和支付行为，从而可以了解未能对账成功的原因，并作出相应的处理。

上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。

Claims (20)

1.一种收银系统，包括：

收银台前端，其用于接收交易请求，返回支付结果；

支付平台接口，其用于响应于交易请求与第三方支付平台通信，发送支付请求并从第三方支付平台接收支付结果；以及

收银台服务系统，其用于记录支付状态。

2.根据权利要求1所述的系统，其中收银台前端响应于用户操作，确认支付信息。

3.根据权利要求2所述的系统，其中收银台服务系统根据交易请求在交易池中生成唯一的交易号，并将交易号返回收银台前端。

4.根据权利要求2所述的系统，其中收银台服务系统异步向业务系统发送支付结果和交易明细。

5.根据权利要求2所述的系统，其中收银台包括收银台管理模块，其用来执行基础数据管理、交易查询、支付补登和退款功能中的一者或多者。

6.根据权利要求1所述的系统，其中收银台与用来提供收银台使用者鉴权服务的数据中心通信。

7.根据权利要求1所述的系统，其中收银台用来记录收银台的交易详情的日志服务模块通信。

8.根据权利要求1所述的系统，其中收银台与经调用向用户发送短信息的短信服务模块通信。

9.根据权利要求2所述的系统，其中收银台包括收银台数据库。

10.根据权利要求9所述的系统，其中收银台服务系统包括：

第一收银台服务模块，用于与收银台数据库交互；以及

第二收银台服务模块，用于接收支付请求以及支付结果，并控制第一收银台服务模块更新收银台数据库。

11.根据权利要求9所述的系统，其中收银台包括三层构架：

用户界面层，其包括收银台前端和收银台管理模块；

业务逻辑层，其包括收银台服务系统；

数据访问层，其包括收银台数据库。

12.根据权利要求11所述的系统，收银台数据库包括：

交易池表，其用来记录交易的状态；

交易请求表，其用来记录交易请求；以及

交易结果表，其用来记录交易请求对应的交易结果。

13.根据权利要求12所述的系统，收银台数据库包括：交易池表包括

交易池主表，其用来记录交易的状态；以及

交易池子表，其用来记录交易请求的状态。

14.根据权利要求12所述的系统，收银台数据库包括：交易请求表，其用来记录收银台数据库中已有的交易请求。

15.根据权利要求12所述的系统，收银台数据库包括：退款请求表，其用来记录收银台数据库中已有的退款请求。

16.一种收银方法，包括：

接收交易请求，返回支付结果；

响应于交易请求与第三方支付平台通信，发送支付请求，记录支付状态；以及

从第三方支付平台接收支付结果。

17.根据权利要求16所述的方法，包括响应于用户操作，确认支付信息。

18.根据权利要求16所述的方法，包括根据交易请求在交易池中生成唯一的交易号。

19.根据权利要求16所述的方法，包括从第三方支付平台接收交易明细。

20.根据权利要求19所述的方法，包括异步向业务系统发送支付结果和交易明细。