CN110706017A - 结算方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本公开的实施例提供了一种结算方法、装置、电子设备及可读存储介质，所述方法包括：接收结算请求，所述结算请求包括：交易类型、交易金额；根据所述交易类型获取具有依赖关系的多个构建器；将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

Description

结算方法、装置、电子设备及可读存储介质

技术领域

本公开的实施例涉及电子商务技术领域，尤其涉及一种结算方法、装置、电子设备及可读存储介质。

背景技术

随着电子商务的迅速崛起，人们可以通过网络购买商家提供的商品。而实际应用中，商家通常基于网络平台销售商品，从而使得交易更加方便，但此时引入了结算的问题，用户支付的金额直接由网络平台代收，然后由网络平台结算给商家。

现有技术中，网络平台结算给商家的金额通常通过公式计算得到。例如，对于一个金额为100的订单，用户实际支付的金额为70，平台营销的金额为20，商家营销的金额为10，佣金率为10％，则平台结算给商家的金额为(用户实际支付的金额+平台营销的金额)*(1-佣金率)＝(70+20)*(1-10％)＝81。

发明人对上述结算方案进行研究的过程中发现，上述方案得到一个总的结算金额，无法获取结算金额的详细依据。

发明内容

本公开的实施例提供一种结算方法、装置、电子设备及可读存储介质，可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

根据本公开的实施例的第一方面，提供了一种结算方法，所述方法包括：

接收结算请求，所述结算请求包括：交易类型、交易金额；

根据所述交易类型获取具有依赖关系的多个构建器；

将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；

根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

根据本公开的实施例的第二方面，提供了一种结算装置，所述装置包括：

结算请求接收模块，用于接收结算请求，所述结算请求包括：交易类型、交易金额；

构建器获取模块，用于根据所述交易类型获取具有依赖关系的多个构建器；

构建器运行模块，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；

交易记录生成模块，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

根据本公开的实施例的第三方面，提供了一种电子设备，包括：

处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现前述结算方法。

根据本公开的实施例的第四方面，提供了一种可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行前述结算方法。

本公开的实施例提供了一种结算方法及装置，所述方法包括：接收结算请求，所述结算请求包括：交易类型、交易金额；根据所述交易类型获取具有依赖关系的多个构建器；将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

附图说明

为了更清楚地说明本公开的实施例的技术方案，下面将对本公开的实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1示出了本公开的一种实施例中的结算方法步骤流程图；

图2示出了本公开的另一种实施例中的结算方法步骤流程图；

图3示出了本公开的结算过程示意图；

图4示出了本公开的一种实施例中的结算装置的结构图；

图5示出了本公开的另一种实施例中的结算装置的结构图；

图6示出了本公开的一种实施例中的电子设备的结构图。

具体实施方式

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

实施例一

参照图1，其示出了本公开的一种实施例中的结算方法的步骤流程图，具体如下。

步骤101，接收结算请求，所述结算请求包括：交易类型、交易金额。

其中，交易类型包括但不限于：支付和取消支付两种。

步骤102，根据所述交易类型获取具有依赖关系的多个构建器。

其中，每个构建器用于构建从一个或多个第一账户中扣款或向第二账户进款的一个交易记录，构建器之间相互依赖，即其中一个构建器的输入为另一个构建器的输出，从而使得构建器之间存在先后调用关系，只有前面的构建器运行结束之后后面的构建器才可以运行。

需要说明的是，若一个构建器不依赖于其他构建器，则该构建器为起始构建器；若不存在其他构建器依赖于一个构建器，则该构建器为结束构建器。

可以理解，起始构建器和结束构建器均可以为一个或多个，如图3所示，从用户账户中扣除用户支付款的构建器、从平台营销账户中扣除平台营销款的构建器、从商家营销账户中扣除商家营销款的构建器为起始构建器，向平台佣金账户中进账佣金款的构建器、向商家结算账户进账免用款、盈利款的构建器、向商家营销账户进款商家营销款的构建器为结束构建器。

可以理解，交易类型不同需要构建不同的构建器以及构建器之间的依赖关系。例如，对于支付流程，起始构建器用于从用户账户、商家营销款账户、平台营销款账户分别扣除用户支付款、商家营销款、平台营销款，对于取消支付流程，起始构建器用于向用户账户、商家营销款账户、平台营销款账户返还之前扣除的用户支付款、商家营销款、平台营销款。可以看出，取消支付的每个构建器均对应支付流程中的一个构建器，两者的代码逻辑为互逆的过程。若对于支付流程，存在构建器1依赖于构建器2，而对于取消支付，存在与构建器1互逆的构建器3，与构建器2互逆的构建器4，从而构建器4依赖于构建器3。如图3所示，对于支付流程，向平台佣金账户进账佣金款的构建器，依赖于从平台代收账户扣除佣金款的构建器；而对于取消支付流程，向平台代收账户进账佣金款的构建器，依赖于从平台佣金账户扣除佣金款的构建器，而向平台佣金账户进账佣金款的构建器，与从平台佣金账户扣除佣金款的构建器为互逆的构建器，从平台代收账户扣除佣金款的构建器，与向平台佣金账户进账佣金款的构建器为互逆的构建器。

在实际应用中，可以针对每种交易类型，建立构建器，并将构建器以及构建器之间的依赖关系存储，以后续调用。

步骤103，将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额。

其中，起始构建器的扣款账户包括用户账户，若还存在用于支付的营销账户，例如，平台营销账户、商家营销账户，则扣款账户还包括：平台营销账户、商家营销账户。

在实际应用中，构建器可以为按照一定逻辑从账户信息中扣款或向账户信息进款的代码程序，包括但不限于：函数、类等。从而运行构建器即为运行代码程序。

可以理解，起始构建器不依赖于其余构建器，即：起始构建器的输入金额不依赖于其他构建器的输出金额，其输入金额为用户支付的金额和/或营销金额。

步骤104，根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

具体地，首先确定依赖于起始构建器的构建器，并运行该构建器生成其对应的交易记录；然后确定依赖于所述构建器的下一个构建器，并运行该下一个构建器生成其对应的交易记录，以此类推，一直至最后一个构建器。

可以理解，在运行构建器的过程中，对于构建器A，若存在直接依赖于构建器A的两个构建器B和C，且B和C之间不存在依赖关系，则可以多线程同时执行B和C，从而可以有助于提高交易记录的生成效率。

综上所述，本公开的实施例提供了一种结算方法，所述方法包括：接收结算请求，所述结算请求包括：交易类型、交易金额；根据所述交易类型获取具有依赖关系的多个构建器；将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

实施例二

参照图2，其示出了在本公开的另一种实施例中的结算方法的具体步骤流程图，具体如下。

步骤201，根据预设账户信息、预设科目信息、预设交易方向建立构建器。

其中，预设账户信息可以为根据实际应用场景设定，本发明实施例对其不加以限制。

可选地，在本发明的另一种实施例中，所述账户信息包括：

用户账户、用于存储平台营销款的平台营销账户、用于存储商家营销款的商家营销账户、用于代收商家款的平台代收账户、商家结算账户、平台佣金账户、用于将商家营销款从所述商家结算账户转至商家营销账户的平台中转账户其中的至少一种。

用户账户为用户用于支付的账户，可以包括但不限于：银行账户、网络虚拟账户(微信、支付宝账户等具有支付功能的账户)。

平台营销账户存储平台营销款，当平台设置了平台优惠策略时，会向平台营销账户中存储一定的平台营销款，并在用户支付时从中扣除一定的平台营销款，与用户支付的费用一起用于支付订单费用。

商家营销账户存储商家营销款，为平台设置的用于垫付商家营销款的账户，当商家设置了商家营销策略时，会在用户支付时从中扣除一定的商家营销款，与用户支付的费用一起用于支付订单费用。可以理解，商家营销款、平台营销款、用户支付的金额的总和为订单费用。

平台代收账户用于收取订单费用，并将订单费用按照一定策略结算给平台和商家。其中，结算给平台的部分为佣金款，其余部分结算给商家，佣金款存储至平台佣金账户，其余结算给商家的部分存储至商家结算账户。

商家结算账户为商家设置的用于收款的账户，商家结算账户中的金额为商家的实际盈利金额。

在本发明实施例中，平台中转账户用于将平台预先垫付的商家营销款从商家结算账户中返还给商家营销账户。

可选地，在本发明的另一种实施例中，步骤201包括子步骤2011至2012：

子步骤2011，若预设交易方向为扣款，所述输出金额为扣款金额，则建立根据输入金额以及所述预设科目信息从所述账户信息中扣除扣款金额，并生成交易记录的构建器。

在本发明实施例中，科目信息不同，则输入金额和输出金额之间的关系不同，即构建器的实现逻辑不同。

例如，如图3所示，若科目信息为用户支付款，则需要构建从用户账户扣除用户支付款的构建器A，构建器A的输入金额为0，即构建器A为起始构建器，构建器A的输出金额为用户支付款70。可以看出，构建器A的输出金额为用户支付的金额，在实际应用中需要获取针对订单用户支付的金额作为构建器A的输出金额。

若科目信息为平台营销款，则需要构建从平台营销账户中扣除平台营销款的构建器B，构建器B的输入金额为0，即构建器B为起始构建器，构建器B的输出金额为平台营销款20。可以看出，构建器B的输出金额为平台营销款，在实际应用中，需要根据平台营销策略以及订单应付的金额确定平台营销款的金额作为构建器B的输出金额。

若科目信息为商家营销款，则需要构建从商家营销账户中扣除商家营销款的构建器C，构建器C的输入金额为0，即构建器C为起始构建器，构建器C的输出金额为商家营销款10。可以看出，构建器C的输出金额为商家营销款，在实际应用中，需要根据商家营销策略以及订单应付的金额确定商家营销款的金额作为构建器C的输出金额。

若科目信息为代收的免佣款，则需要构建从平台代收账户扣除免佣款的构建器D，构建器D的输入金额为平台代收账户代收的商家款(即如图3所示的用户支付款+平台营销款20+商家营销款10＝100)，构建器D的输出金额为根据预设规则设定的免佣款，例如，免佣款固定设置为10，即输出金额为10；当然还可以设定免佣款与代收的商家款相关，例如，免佣款为代收的商家款的10％。本发明实施例对免佣款的设置不加以限制。

若科目信息为佣金款，则需要构建从平台代收账户中扣除佣金款的构建器E，构建器E的输入金额为代收的商家款100，构建器E的输出金额为根据预设收佣规则得到的佣金款，例如，如图3所示，佣金款36为输入金额100减去免佣款10之后乘以收佣系数0.4的金额。本发明实施例对收佣规则不加以限制。

若科目信息为盈利款，则需要构建从平台代收账户中扣除盈利款的构建器F，构建器F的输入金额为代收的商家款100，如图3所示，构建器F的输出金额54为代收的商家款100减去收佣金款36、免佣款10之后的金额。

若科目信息为商家营销款，则需要构建从商家结算账户扣除商家营销款的构建器G，由于商家营销款为最开始从商家营销账户中扣除的扣款金额，从而构建器G的输出金额与输入金额不存在对应关系，如图3所示，商家营销款为10；此外，还需要构建从平台中转账户扣除商家营销款的构建器H，构建器H的输出金额与输入金额相同，均为商家营销款10。子步骤2012，若所述交易方向为收款，所述输入金额为收款金额，则建立向所述账户信息进账所述收款金额，并生成交易记录的构建器。

在本发明实施例中，对于交易方向为收款的构建器，输入金额和输出金额相同，均为收款金额，收款的构建器的输入金额为多个其依赖的构建器的输出金额之和。

例如，如图3所示，平台代收账户的输入金额包括三部分：用户实付款、平台营销款、商家营销款，其输入金额和输出金额均为100，需要构建向平台代收账户进账输入金额为100的构建器I，构建器I的输入金额为构建器I依赖的构建器A、构建器B及构建器C，从而构建器I的输入金额为构建器A、构建器B及构建器C的输出金额之和。

对于平台佣金账户，需要构建向平台佣金账户进账佣金款的构建器J，构建器J依赖于构建器E，构建器J的输入金额为构建器E的输出金额36。

对于商家结算账户，需要构建向商家结算账户进账盈利款的构建器K，构建器K依赖于构建器F，构建器K的输入金额为构建器F的输出金额54；此外，还需要构建向商家结算账户进账免佣款的第十构建器B，构建器L依赖于构建器D，构建器L的输入金额为构建器D的输出金额10。

对于平台中转账户，需要构建向商家结算账户进账商家营销款的构建器M，构建器M依赖于构建器G，构建器M的输入金额为构建器G的输出金额10；此外，还需要构建向商家营销账户进账商家营销款的构建器N，构建器N依赖于构建器H，构建器N的输入金额为构建器H的输出金额10。

步骤202，接收结算请求，所述结算请求包括：交易类型、交易金额。

该步骤可以参照步骤101的详细说明，在此不再赘述。

步骤203，根据所述交易类型获取具有依赖关系的多个构建器。

该步骤可以参照步骤102的详细说明，在此不再赘述。

步骤204，将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额。

该步骤可以参照步骤103的详细说明，在此不再赘述。

步骤205，若所述其余构建器中存在依赖于所述起始构建器的第一中间构建器，则将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录，所述交易记录还包括：账户信息、科目信息、交易方向、输出金额其中的至少一种。

其中，科目信息用于说明输出金额的类型和作用，方便用户可以直接明了的明白交易记录的详细内容。科目信息可以包括但不限于：用户支付款、平台营销款、商家营销款、佣金款、代收的商家款。平台营销款为平台基于一定的优惠策略向用户提供的优惠款，商家营销款为商家基于一定的优惠策略向用户提供的优惠款，例如，当订单所需支付的总金额满100元时，平台提供20元的优惠券，商家提供10元的优惠券，从而平台营销款为20元，商家营销款为10元。代收的商家款为平台替代商家收取的款，在网络销售平台上，商家入驻平台之后可以在平台上销售商品，销售商品所得的金额由平台替代商家统一收取，最后按照一定策略结算给商家。佣金款为商家每成交一个订单，均需要向平台支付的佣金。

交易方向包括：扣款和收款两个方向，对于账户信息，当交易方向为扣款时，代表从该账户信息扣除一定金额，当交易方向为收款时，代表向该账户进款一定金额。

可以理解，本发明实施例需要按照依赖关系逐个运行每个构建器，直至最后一个构建器，从而实现所有构建器的运行，从而生成多个具有顺序的交易记录。

步骤206，循环执行如下第二步骤：若所述其余构建器中存在依赖于所述第一中间构建器的第二中间构建器，则将所述第一中间构建器作为起始构建器，以及将所述第二中间构建器作为所述第一中间构建器，并执行如下第一步骤：将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录。

本发明实施例可以在每运行第一中间构建器之后，可以将该第一中间构建器作为起始构建器，并运行该第一中间构建器之后的构建器，直至最后一个构建器。

步骤207，针对所述结算请求，按照所述依赖关系将所述构建器对应的所述输出金额、所述账户信息、所述科目信息、所述交易方向输出至交易流水清单。

具体地，可以首先输出起始构建器对应的交易记录，然后输出依赖于所述起始构建器的中间构建器的交易记录，直至最后一个构建器的交易记录。对应于如图3的账户关系，生成如表1中所示的交易流水清单。

表1

综上所述，本公开的实施例提供了一种结算方法，所述方法包括：接收结算请求，所述结算请求包括：交易类型、交易金额；根据所述交易类型获取具有依赖关系的多个构建器；将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

实施例三

参照图4，其示出了在本公开的另一种实施例中的结算装置的结构图，具体如下。

结算请求接收模块301，用于接收结算请求，所述结算请求包括：交易类型、交易金额。

构建器获取模块302，用于根据所述交易类型获取具有依赖关系的多个构建器。

构建器运行模块303，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额。

交易记录生成模块304，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

综上所述，本公开的实施例提供了一种结算装置，所述装置包括：结算请求接收模块，用于接收结算请求，所述结算请求包括：交易类型、交易金额；构建器获取模块，用于根据所述交易类型获取具有依赖关系的多个构建器；构建器运行模块，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；交易记录生成模块，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

实施例三为实施例一对应的装置实施例，详细说明可以参照实施例一，在此不再赘述。

实施例四

参照图5，其示出了在本公开的另一种实施例中的结算装置的结构图，具体如下。

构建器建立模块401，用于根据预设账户信息、预设科目信息、预设交易方向建立构建器。

结算请求接收模块402，用于接收结算请求，所述结算请求包括：交易类型、交易金额。

构建器获取模块403，用于根据所述交易类型获取具有依赖关系的多个构建器。

构建器运行模块404，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额。

交易记录生成模块405，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录；可选地，在本发明的另一种实施例中，所述交易记录生成模块405，包括：

交易记录生成子模块4051，用于若所述其余构建器中存在依赖于所述起始构建器的第一中间构建器，则将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录，所述交易记录还包括：账户信息、科目信息、交易方向、输出金额其中的至少一种。

循环子模块4052，用于循环执行如下第二步骤：若所述其余构建器中存在依赖于所述第一中间构建器的第二中间构建器，则将所述第一中间构建器作为起始构建器，以及将所述第二中间构建器作为所述第一中间构建器，并执行如下第一步骤：将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录。

交易流水清单输出模块406，用于针对所述结算请求，按照所述依赖关系将所述构建器对应的所述输出金额、所述账户信息、所述科目信息、所述交易方向输出至交易流水清单。

可选地，在本发明的另一种实施例中，所述构建器建立模块401包括：

第一构建器建立子模块，用于若预设交易方向为扣款，所述输出金额为扣款金额，则建立根据输入金额以及所述预设科目信息从所述账户信息中扣除扣款金额的构建器，并输出所述账户信息、所述科目信息、所述交易方向、所述输出金额。

第二构建器建立子模块，用于若所述交易方向为收款，所述输入金额为收款金额，则建立向所述账户信息进账所述收款金额的构建器，并输出所述账户信息、所述科目信息、所述交易方向、所述输出金额。

可选地，在本发明的另一种实施例中，所述账户信息包括：

用户账户、用于存储平台营销款的平台营销账户、用于存储商家营销款的商家营销账户、用于代收商家款的平台代收账户、商家结算账户、平台佣金账户、用于将商家营销款从所述商家结算账户转至商家营销账户的平台中转账户其中的至少一种。

综上所述，本公开的实施例提供了一种结算装置，所述装置包括：结算请求接收模块，用于接收结算请求，所述结算请求包括：交易类型、交易金额；构建器获取模块，用于根据所述交易类型获取具有依赖关系的多个构建器；构建器运行模块，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；交易记录生成模块，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。本发明实施例可以通过多个构建器生成结算过程中的交易记录，从而得到结算金额的详细依据。

实施例四为实施例二对应的装置实施例，详细说明可以参照实施例二，在此不再赘述。

本公开的实施例还提供了一种电子设备，参照图6，包括：处理器501、存储器502以及存储在所述存储器502上并可在所述处理器上运行的计算机程序5021，所述处理器501执行所述程序时实现前述实施例的结算方法。

本公开的实施例还提供了一种可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行前述实施例的结算方法。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本公开的实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本公开的实施例的内容，并且上面对特定语言所做的描述是为了披露本公开的实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本公开的实施例的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本公开的实施例的示例性实施例的描述中，本公开的实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本公开的实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本公开的实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

本公开的实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本公开的实施例的结算设备中的一些或者全部部件的一些或者全部功能。本公开的实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序。这样的实现本公开的实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本公开的实施例进行说明而不是对本公开的实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开的实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所述仅为本公开的实施例的较佳实施例而已，并不用以限制本公开的实施例，凡在本公开的实施例的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本公开的实施例的保护范围之内。

以上所述，仅为本公开的实施例的具体实施方式，但本公开的实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开的实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的实施例的保护范围之内。因此，本公开的实施例的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种结算方法，其特征在于，所述方法包括：

接收结算请求，所述结算请求包括：交易类型、交易金额；

根据所述交易类型获取具有依赖关系的多个构建器；

将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；

根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

2.根据权利要求1所述的方法，其特征在于，所述根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录的步骤，包括：

若所述其余构建器中存在依赖于所述起始构建器的第一中间构建器，则将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录；

循环执行如下第二步骤：若所述其余构建器中存在依赖于所述第一中间构建器的第二中间构建器，则将所述第一中间构建器作为起始构建器，以及将所述第二中间构建器作为所述第一中间构建器，并执行如下第一步骤：将所述起始构建器对应的输出金额作为所述第一中间构建器的输入金额，并运行所述第一中间构建器得到所述第一中间构建器对应的交易记录。

3.根据权利要求1或2所述的方法，其特征在于，所述交易记录还包括：账户信息、科目信息、交易方向、输出金额其中的至少一种。

4.根据权利要求3所述的方法，其特征在于，在生成构建器对应的交易记录之后，所述方法还包括：

针对所述结算请求，按照所述依赖关系将所述构建器对应的所述输出金额、所述账户信息、所述科目信息、所述交易方向输出至交易流水清单。

5.根据权利要求3所述的方法，其特征在于，在所述接收结算请求的步骤之前，所述方法还包括：

根据预设账户信息、预设科目信息、预设交易方向建立构建器。

6.根据权利要求5所述的方法，其特征在于，所述根据预设账户信息、预设科目信息、预设交易方向建立构建器的步骤，包括：

若预设交易方向为扣款，所述输出金额为扣款金额，则建立根据输入金额以及所述预设科目信息从所述账户信息中扣除所述扣款金额，并生成交易记录的构建器；

若所述交易方向为收款，所述输入金额为收款金额，则建立向所述账户信息进账所述收款金额，并生成交易记录的构建器。

7.根据权利要求6所述的方法，其特征在于，所述账户信息包括：

用户账户、用于存储平台营销款的平台营销账户、用于存储商家营销款的商家营销账户、用于代收商家款的平台代收账户、商家结算账户、平台佣金账户、用于将商家营销款从所述商家结算账户转至商家营销账户的平台中转账户其中的至少一种。

8.一种结算装置，其特征在于，所述装置包括：

结算请求接收模块，用于接收结算请求，所述结算请求包括：交易类型、交易金额；

构建器获取模块，用于根据所述交易类型获取具有依赖关系的多个构建器；

构建器运行模块，用于将所述交易金额作为起始构建器的输入金额并运行所述起始构建器得到所述起始构建器对应的交易记录，所述起始构建器不依赖于所述多个构建器中的其余构建器，所述交易记录包括：输出金额；

交易记录生成模块，用于根据所述起始构建器的输出金额和所述依赖关系生成所述其余构建器对应的交易记录。

9.一种电子设备，其特征在于，包括：

处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-7中任一项所述的结算方法。

10.一种可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如方法权利要求1-7中任一项所述的结算方法。

Images