财务数据处理方法、装置及计算机系统与流程

本申请涉及财务数据处理
技术领域：
，特别是涉及财务数据处理方法、装置及计算机系统。
背景技术：
：在能够支持“新零售”模式的商品对象信息服务系统中，由于可能涉及到多家线下的实体店铺，而不同的实体店铺可能对应着不同的经营主体，在税务部门注册的核算主体可能也会有多个，另外，由于具体销售的商品对象类目可能会比较多，不同的商品对象对应的计税方式也会有所不同，等等，因此，经常需要定期或者不定期地进行财务记账，对每笔交易产生的经济业务列出相对应的借贷关系及其金额等信息，从而清楚地反映经济业务的归类情况。现有技术中，是在每笔交易完成的同时，基于交易上的业务单据明细，根据预设的会计分录规则，生成每笔交易对应的财务数据明细，也即，每生成一条业务单据明细，就进行一次业务数据到财务数据的映射，生成财务数据明细，再根据财务数据明细进行会计分录处理，生成财务记账明细；最后再将一个记账周期内的财务记账明细进行分组以及汇总计算，生成总账凭证。但是，一次记账周期内产生的交易数量通常会非常多，而具体的业务单据明细通常还需要根据每笔交易订单中的具体商品对象进行拆分，例如，某交易订单中包括3件商品，则可能会对应三份不同的业务单据明细，因此，同一记账周期内产生的业务单据明细的数量就会非常多。例如，在以每月为单位进行记账的情况下，具体的业务单据数量可能会数以几千万甚至数以亿计。并且，随着“新零售”模式的推广，新用户的增加，该数量可能还会进一步增加。而在实际应用中，在进行从业务数据到财务数据的映射时，可能会出现出错的情况，或者，会计分录规则调整导致的需要对数据映射规则进行调整等情况。针对上述情况，如果采用现有技术的方案，则意味着需要重新对数以千万甚至数以亿计的业务单据明细重新进行向财务单据明细的映射，再重新进行会计分录处理，以及最后的生成总帐凭证的处理。该过程需要需要投入大量计算资源在短时间内进行计算，不仅带来大量计算资源的浪费，更严重的是计算时间长，无法在规定时间生成总账凭证。因此，如何更高效地对系统中产生的业务数据进行财务记账处理，成为需要本领域技术人员解决的技术问题。技术实现要素：本申请提供了财务数据处理方法、装置及计算机系统，能够在大数据量交易场景中，准确高效地生成各类总账凭证，即使关账前发生会计分录规则等方面的调整，也可以避免大量的数据重算，节省计算资源。本申请提供了如下方案：一种商品对象信息处理系统，包括：业务系统，与实体店铺相关的商品对象订单处理链路中的链路节点对应，用于在进行订单处理过程中产生对应链接节点上的业务单据明细；财务信息处理系统，用于获得财务信息处理过程中所需的配置信息，并在获得目标记账周期内产生的业务单据明细信息后，按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组并进行组内汇总，生成业务单据汇总数据，根据所述配置信息对所述业务单据汇总数据进行会计分录，生成总账凭证信息。一种财务数据处理方法，包括：获得财务信息处理过程中所需的配置信息；获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。一种财务数据处理装置，包括：配置信息获得单元，用于获得财务信息处理过程中所需的配置信息；业务单据明细获得单元，用于获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；分组汇总单元，用于按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；总账凭证生成单元，用于根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。一种计算机系统，包括：一个或多个处理器；以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:获得财务信息处理过程中所需的配置信息；获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。根据本申请提供的具体实施例，本申请公开了以下技术效果：通过本申请实施例，不需要对每一笔交易进行记账，而是按照会计分录规则，分析出其要求的财务要素，再分析出其对应业务要素，然后根据业务要素对业务数据进行分组，按分组对数据先进行汇总，减少分录记账数据量。如果关账前出现会计规则调整，由于通常是对某一财务要素的会计科目，或者业务要素对应财务要素的映射规则进行调整，但很少对业务要素维度进行调整。比如会调整业务公司对财务公司的映射关系，但通常不会由按公司核算调整成按部门核算，因此分组维度是稳定的。另外，对原始业务单据明细进行分组，然后做汇总计算，不涉及业财数据映射和会计规则，也就不涉及逻辑，因此适于使用包括大数据计算平台或云计算等新型计算工具，可以进一步提升效率。再者，汇总后，数据量只和分组业务维度相关，和同一维度数据量无关。也就说，如果汇总维度是某一个财务公司，那么不管这个财务公司的单据量增大到多少，汇总后也只是一条数据，按业务维度汇总后单据量也指数级减少，由亿级到百或千数量级。因此计算量呈指数级降低，计算时间大幅减少。在汇总后数据上，根据业财数据映射关系，完成业务要素向财务要素的映射，此时单据量已指数级降低，因此计算速度非常快。在根据会计规则做总账时，同样基于汇总后数据进行，在较少数据集上，进行复杂会计规则计算，在提高计算速度同时，准确度也能得到提高。即使在关账前，有会计规则调整，也只需要在汇总后数据上进行，由于单据量已大大减少，重算速度非常快。基于以上所述，通过本申请实施例所提供的方法，解决了大数据量交易场景，准确高效生成各类总账凭证的问题，同时也节省了大量计算资源。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本申请实施例提供的系统的示意图；图2是现有技术中的处理方案示意图；图3是本申请实施例提供的处理方案示意图；图4-1至4-3是本申请实施例提供的配置界面示意图；图5是本申请实施例提供的方法的流程图；图6是本申请实施例提供的装置的示意图；图7是本申请实施例提供的计算机系统的示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。为了便于理解，首先对本申请实施例涉及到的具体系统架构以及实际应用中可能出现的数据映射出错的原因进行介绍。如图1所示，本申请实施例主要涉及到的产品可以是商品对象信息服务系统中使用的财务信息处理系统，通常，而商品对象信息服务系统中还可以包括业务系统，主要用于产生各类业务单据，因此，财务信息处理系统可以从具体的业务系统获得业务单据明细信息。获得业务单据明细之后，财务信息处理系统可以基于这种业务单据明细进行财务方面的记账等处理，以明确各类资金的流入、流出关系、具体的金额(包括税前、税后、税金)等信息。而在进行具体的财务记账处理之前，通常还需要对财务信息处理系统中的一些信息进行配置，例如，具体可以对业务数据与财务数据之间的映射关系，或者，总账凭证中所需字段的信息等进行配置。例如，对于某采购类的业务单据明细中，通常可以包括以下字段：核算主体、客商编码、客商名称、商品对象信息、单据日期、金额(含税金额，税后金额，税金等)、税率，等等。例如，具体如表1所示：表1而在对上述业务单据明细进行记账处理时，在总账凭证单据中，通常需要包括更多的字段，包括借贷关系、公司段、会计日期、业务日期、预算部门段、收益部门段、区域段、会计科目、明细段等等，另外还可以包括客商名称，汇总后的金额信息，等等。例如，对于采购类的业务，对应的总账凭证中，具体包括的字段信息及对应的数据可以如表2所示：表2可见，在根据业务单据明细生成总账凭证的过程中，总账凭证中的一些字段上的数据，需要根据业务单据明细中的数据来生成，但是，由于两个表格中的字段名称等并不完全一致，因此，在此之前，需要进行一些配置。另外，具体总账凭证中的科目等字段上的数据，并不是从业务单据明细中生成的，而是需要预先进行配置，再者，关于总账凭证中具体需要哪些字段上的数据，也都是需要预先进行配置的。在完成了上述配置后，具体在进行记账处理时，就会按照这种映射关系以及配置信息进行记账凭证的生成。但是，上述配置信息通常是由人工方式进行配置的，并且，由于不同类别的业务单据对应的财务信息配置信息可能会各不相同，因此，配置工作的工作量比较大，这就使得配置过程中可能会发生配置错误等现象。而在现有技术中，是在每笔交易完成的同时，基于交易上的业务单据明细，根据预设的会计分录规则，生成每笔交易对应的财务数据明细，也即，每生成一条业务单据明细，就进行一次业务数据到财务数据的映射，生成财务数据明细，再根据财务数据明细进行会计分录处理，生成财务记账明细；最后再将一个记账周期内的财务记账明细进行分组以及汇总计算，生成总账凭证。但是，在此过程中，如图2所示，对于一些大数据量的系统而言，业务单据明细是数以亿计的，则进行了从业务数据到财务数据的映射后，生成的财务单据明细也是数以亿计的，具体在进行会计分录会生成的财务记账明细同样的数以亿计的。但是，一旦在某时刻发现在之前配置的映射关系错误，或者，科目等信息配置错误，则需要从第一步开始，对数以亿计的业务单据明细重新进行从业务数据到财务数据的映射，因此，计算量会非常大，需要占用很多的时间成本以及计算资源。基于上述情况，在本申请实施例中，提供了一种新的处理方式，在该方式中，可以不必在每条业务单据明细生成时进行向财务数据的映射，而是如图3所示，首先对具体的记账周期内的业务单据明细进行分组，之后还可以对组内的业务单据明细进行汇总，例如，每个组可以汇总为一条业务单据汇总数据。然后再根据业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。通过上述方式，通过对业务单据明细的分组并汇总，使得业务单据汇总数据的条数减少，例如，在业务单据明细同样数以亿计的情况下，汇总会得到的业务单据汇总数据可能会是数百或者千级，具体的数据条目大大降低。并且，在进行汇总的过程中，不涉及从业务数据到财务数据的映射，只有在汇总之后，才会涉及到业务数据到财务数据的映射。这样，即使后续发现映射关系配置错误，或者总账凭证字段信息配置错误等情况，只需要对百或者千级的业务单据汇总数据重新进行从业务数据到财务数据的映射即可，显然，相对于对数以亿计的业务单据明细的重新映射而言，计算量得到明显的降低，因此，可以避免在出现映射关系、总账凭证字段信息等配置错误时，造成大量的数据重算。下面对本申请实施例提供的具体实现方案进行详细介绍。实施例一首先该实施例一提供了一种商品对象信息处理系统，其中，由于本申请实施例中涉及到具体商品对象信息处理系统中涉及到的业务信息、财务信息等，在该实施例一中，统称为商品对象信息。具体的，如图1所示，该系统具体可以包括：业务系统101，与实体店铺相关的商品对象订单处理链路中的链路节点对应，用于在进行订单处理过程中产生对应链接节点上的业务单据明细；财务信息处理系统102，用于获得财务信息处理过程中所需的配置信息，并在获得目标记账周期内产生的业务单据明细信息后，按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组并进行组内汇总，生成业务单据汇总数据，根据所述配置信息对所述业务单据汇总数据进行会计分录，生成总账凭证信息。顾名思义，业务系统就是具体信息服务系统中用于对具体的业务进行处理的系统，例如，包括订单、履约、库存、配送等等。其中，在“新零售”等场景中，经常出现交易链路比较长的情况，例如，对于线上下单的情况，用户在线下单后进行付款，之后，需要由具体实体店铺中的作业人员执行拣货、打包等操作，打包完成后的商品对象需要由配送员送到用户手上完成，用户签收商品后才算完成整个交易链路，因此交易付款和商品交付异步完成，两者之间通常相隔1小时至数天不等。并且，整个交易链路可能是由多个不同的业务部门，甚至不同的服务提供商来完成，在进行财务数据结算时，可能会涉及到不同的财务数据收发方。不同类别的商品对象也对应的订单处理链路也可能不同，期间涉及到的部门也会不同，例如，对于蔬菜、水果等，实体店铺只需要进行拣货、打包、配送等处理即可。而如果订单中包括一些需要实体店铺中进行加工制作的餐饮类的商品对象，则还需要由实体店铺的加工制作部门提供加工制作服务，之后才能进行打包、配送。另外，具体交易或者服务过程中，不同的商品对象还可能对应不同的税率等信息，因此，针对具体交易订单中的不同商品对象，通常需要分别生成不同的业务单据明细。其中，交易订单可以包括消费者进行商品对象购买过程中生成的交易订单，还可以包括实体店铺从经销商等处进行商品对象采购过程中生成的采购单，等等。例如，某消费者在线上下单了三件商品对象，分别是黄瓜、某种蛋糕、某类螃蟹，则需要针对这三件商品对象生成三份不同的业务单据明细。这就使得系统中的业务单据明细的数量会非常多，例如，在以月为周期进行财务汇总的情况下，每次所需处理的业务单据明细可能是数千万条甚至上亿条。另外，针对上述链路很长的情况，为了保证数据的完整性以及准确性，如图1所示，还可以提供核对系统103，该核对系统主要用于在复杂链路场景中能够实现对相关单据数据的核对。其中，具体的业务系统中产生的单据数据可以通过一定的通信通道提供给核对系统，在核对系统中对同一链路上各个不同节点所在的业务系统中产生的单据数据进行核对，也可以避免单据数据被其中某个业务节点进行篡改等情况，保证核对结果的准确性及有效性。在存在核对系统的情况下，由于具体业务系统产生的业务数据都会汇总到核对系统进行核对，因此，财务信息处理系统还可以直接从该核对系统获取到业务单据明细信息，而不必直接与各个业务系统分别进行对接，因此，可以提高效率，降低出错的概率。具体实现时，核对系统(当然，也可以有其他的名称)可以与具体的业务系统相独立。当然，本申请实施例中所指的独立具体可以是指功能上的独立，具体的，核对系统可以单独部署在一台或者多台专用的物理设备上。或者，也可以部署在其中某个业务系统的服务器/集群中，但在逻辑上需要与具体的业务处理逻辑相隔离；再或者，具体的核对系统也可以直接部署在财务信息处理系统内的某台或者多台物理设备上，等等。财务信息处理系统在从具体的业务系统或者核对系统获得业务单据明细信息后，可以针对同一记账周期内的业务单据明细进行记账处理。为了实现上述记账处理，如前文所述，通常需要预先在财务信息处理系统中对所述的信息进行配置，例如，具体可以包括业务数据与财务数据之间的映射关系配置信息，和/或，所述总账凭证中所需的字段配置信息等。其中，关于业务数据与财务数据之间的映射，主要是指将业务单据明细中的业务要素(字段)的表达方式，与财务系统中财务要素的表达方式可能会有所不同，例如，同一个公司的代码，在业务系统中与财务系统中的表达方式可能会不同，因此，在记账的过程中需要映射。或者，在业务系统中，某实体店铺内部包括烘焙部门、生鲜部门、水果部门等多个部门，但是，在财务系统中，生鲜部门与水果部门可能对应着财务系统中的同一个“成本中心”，并且，有可能需要在“成本中心”粒度上进行数据汇总，因此，需要配置部门与成本中心之间的映射关系；又或者，不同类别的商品对象可能对应着不同的税率，在业务单据明细中，即使是同一个交易订单中的不同的商品对象，也会对应着不同的业务单据明细，而在具体在进行财务记账时，可能会需要按照税率的粒度进行记账，同一税率的不同商品对象的金额可能会汇总到一起进行记录，因此，也需要对商品对象类别与税率之间的映射关系进行配置，等等。为此，财务信息处理系统中可以提供用于对上述映射关系进行配置的配置界面，具体的映射关系信息可以通过该配置界面进行配置。例如，如图4-1所示，其示出了对“公司”字段的表达方式在业务系统以及财务系统中的代码进行配置的界面。类似的，还可以提供对业务系统中的部门与财务系统中的成本中心之间的映射关系进行配置的界面，或者，对商品对象种类与税率之间的映射关系进行配置的界面，等等。另外，除了上述对映射关系的配置之外，还可能会涉及到对总账凭证中所需字段的信息进行配置，也就是说，关于具体的总账凭证中具体需要展示哪些字段，具体的规则等，都可以预先进行配置。例如，如图4-2所示，其示出了采购单据类的总账凭证的相关信息的配置界面，其中可以对分录说明类型、金额规则、科目设置等进行配置。其中，在点击具体某个分录对应的“科目设置”信息后，可以如图4-3所示，展示出具体的科目详情，其中包括各个具体分录的数值类型等信息。需要说明的是，关于上述具体的映射关系信息、总账凭证中的字段信息等，通常都是需要进行人工配置的，另外，对于不同类的业务单据，例如，交易类的与采购类的，或者交易订单在不同链路节点上产生的业务单据，具体对应的配置信息可能都会不同。因此，需要进行配置的信息会非常多，不同类别的业务对应的配置信息可能会各不相同，但可能又有相似之处，这就使得在配置过程中经常会出现配置出错的问题。例如，尤其是图4-3中所示的“科目”分录的具体数值，也是配置信息中进行配置的，但是，由于该数值通常是由一串长度为10位甚至更多位的数字组成，因此，在人工配置的过程中经常会出现出错的情况。在完成上述配置的基础上，对于当前记账周期内的业务单据明细，就可以首先进行分组汇总处理。其中，具体在进行分组处理时，由于具体的业务单据明细可能是多种不同的业务系统中产生的，而不同类型的业务单据明细中，对应的财务信息处理过程中使用的会计分录规则都可能是不同的，对应的业务数据与财务数据之间的映射关系、总账凭证字段等信息都可能是不同的。例如，交易订单中产生的业务单据明细，与采购订单中产生的业务单据明细，对应的配置信息可能会不同，以便分别进行财务信息处理。另外，商品对象信息服务系统中对商品对象订单的处理链路中可能会多个不同的节点，在进行订单处理的过程中，也可能分别产生不同类别的业务单据明细，这些不同类别的业务也可能对应不同的配置信息，以便分别进行财务信息处理。因此，首先可以将业务单据明细按照不同的业务类别等划分成多类，然后，在对每个具体类别内部的业务单据明细进行分组以及汇总处理。也就是说，在本申请实施例中，可以按照业务类型等信息将具体的业务单据明细划分成多个类别，每个类别下可以划分成多个组，每个组内的多条业务单据明细可以汇总为一条业务汇总数据。其中，具体在进行分组时，主要可以按照会计分录规则中所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组。其中，不同类别的业务可能对应不同的会计分录规则，本申请实施例中的分组都可以默认为是对同一类别的业务对应的业务单据明细进行分组。具体的，关于会计分录规则中所需的最小粒度财务要素信息也可以是在配置信息中进行配置。而财务要素与业务要素之间通常也具有映射关系。其中，本申请实施例中所述的要素，通常是指具体记录中的字段信息，具体的，财务要素可以是指总账凭证中对具体字段上的数据的表达方式。例如，对于交易业务对应的总账凭证中，具体可以包括经营主体，成本中心，汇率，税前金额，税后金额，税金，等等。业务要素则是指业务单据明细中，对具体字段上的数据的表达方式，例如，对于具体可以包括实体店铺名称，部门，商品对象标识，价格，等等。对于采购业务对应的总账凭证中，可能会包括借贷关系、公司、会计日期、预算部门段、收益部门段、区域段、会计科目、明细段等等。而采购业务的业务单据明细中，对具体字段可能会包括核算主体、客商编码、客商名称、商品对象信息、单据日期、金额等。具体的，会计分录规则中所需的最小粒度的财务要素可以根据具体的财务处理需求而定，并且，在不同类别的业务中，对应的最小粒度可能会有所不同。例如，某些类别的业务中，最小粒度可能是成本中心，也即，在财务信息处理时，需要将同一实体店铺同一成本中心对应的各条业务单据明细中的金额合并在一起，给出总账凭证。其中，成本中心这一财务要素对应的业务要素是部门，并且，同一成本中心可能会对应多个部门，因此，在进行分组时，就可以将同一实体店铺中同一成本中心对应的同一部门对应的业务单据明细分为一组。在进行汇总时，可以将该最小粒度财务要素对应的业务要素以及更高粒度的业务要素保留，而将所述业务单据明细中比所述最小粒度财务要素对应的业务要素更低粒度的业务要素对应的字段丢弃，然后，根据剩余的字段，以及组内各条业务单据明细对应的财务金额相关信息的汇总结果，生成一条业务单据汇总数据。例如，在上述以成本中心为最小粒度时，是按照该成本中心要素对应的“部门”要素进行的分组，组内的各条业务单据明细中还包括比“部门”要素粒度更低的业务要素，例如，具体是商品对象要素。而由于在进行会计分录时，不需要考虑不同商品对象之间的区别，直接从“成本中心”粒度上进行汇总，因此，在进行组内业务单据明细的汇总时，就可以将“商品对象”这一字段上的信息丢弃，将各部门对应的业务单据明细中的金额信息进行汇总，生成一条业务汇总数据。例如，假设某实体店铺对应的交易类的业务单据明细如表3所示：表3实体店铺标识部门商品对象标识税前金额税率200001烘焙100001200.16200001烘焙100002500.16200001烘焙100003350.12200001生鲜100004550.12200001生鲜100005850.12200001生鲜1000061500.16200001生鲜100007650.16假设会计分录中需要按照“成本中心”粒度进行汇总，而对于200001这个实体店铺而言，烘焙与生鲜对应同一个成本中心，则可以将烘焙部门对应的业务单据明细分为一组，生鲜部门对应的业务单据明细分为一组，并分别在组内进行数据汇总。在进行数据汇总时，由于业务单据中还包括商品对象标识、税率这两个更小的粒度，因此，可以丢弃。例如，对于前述表3中的例子，汇总会的业务汇总数据可以如表4所示：表4实体店铺标识部门金额200001烘焙105200001生鲜355可见，通过分组汇总后，表3中的6条记录被汇总为2条，后续的数据映射以及总账凭证的生成操作都可以时在上述表4的基础上进行。当然，上述表3以及表4只是用于举例说明，在实际应用中，实际的数据条目数量会更多，汇总后对数据条目数量的减少会更明显。在上述例子中，是以“成本中心”为最小粒度，当然，在其他业务中，最小粒度可能是其他的要素。例如，在一种情况下，还可能是税率，也即在财务信息处理时，需要将同一税率对应的各条业务单据明细中的金额合并在一起，给出总账凭证。此时，财务要素“税率”对应的业务要素也是“税率”，此时，在进行分组时，就可以将同一实体店铺、同一部门以及同一税率的业务单据明细分为一组，并进行汇总。例如，对于前述表3中所示的例子，汇总后的业务汇总数据可以如表5所示：表5实体店铺标识部门税率税前金额200001烘焙0.1670200001烘焙0.1235200001生鲜0.16215200001生鲜0.12290其他类型业务对应的业务单据明细也可以按照类似的方式进行分组以及汇总，例如，对于表1所示的采购类的业务单据明细，假设会计分录中进行汇总时所需的最小粒度的财务要素是“税率”，则可以按照该要素进行分组，在进行汇总时，可以保留核算主体、客商编码、客商名称、税率等字段，而将具体“商品编码”这一列丢弃，等等。需要说明的是，在具体实现时，业务单据明细中通常还可以包括日期要素，而在进行财务记账时，也可能需要按照日期进行分别记账，因此，还可以按照会计分录规则中所需的最小粒度财务要素对应的业务要素，对同一日期内生成的业务单据明细进行分组，以达到上述目的。通过上述方式进行业务单据明细进行分组并汇总后，便可以进行从业务数据到财务数据的映射，并根据具体的会计分录规则，生成具体的总账凭证。关于具体进行会计分录处理的过程，可以与原有的处理方式相似，这里不再进行详述。可见，在本申请实施例中，由于是先进行业务单据明细的分组以及汇总，在此过程中不涉及业务数据到财务数据的映射，在通过汇总使得数据条目数量减少后，再进行业务数据到财务数据的映射，而在进行业务单据明细的分组时，考虑了会计分录规则中进行数据汇总时使用的最小粒度的财务要素的信息，因此，后续生成总账凭证时，也不再需要重新进行汇总。这样，即时后续发现映射关系配置错误，或者，具体总账凭证中的字段配置错误时，在重新修改了配置信息后，也只需要根据汇总后业务汇总数据重新进行数据的映射即可，而业务汇总数据的条目数量远小于最开始的业务单据明细的数量，因此，重算过程中的计算量会得到降低，能够满足在短时间内完成重算的要求。实施例二该实施例二是从具体的财务信息处理系统的角度，提供了一种财务数据处理方法，参见图5，该方法具体可以包括：s501：获得财务信息处理过程中所需的配置信息；s502：获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；s503：按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；s504：根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。具体实现时，如果所述配置信息发生错误，则可以根据修正后的配置信息重新对所述业务单据汇总数据进行会计分录，生成总账凭证信息。其中，所述业务单据明细包括：根据商品对象信息服务系统中与实体店铺关联的商品对象订单生成的业务单据明细，其中，所述订单包括交易订单或采购订单，对于不同类别的订单中生成的业务单据明细，并对应不同的配置信息，以便分别进行财务信息处理。另外，所述商品对象信息服务系统中对商品对象订单的处理链路中包括多个不同的节点，在进行订单处理的过程中，产生不同类别的业务单据明细，并对应不同的配置信息，以便分别进行财务信息处理。其中，所述配置信息包括业务数据与财务数据之间的映射关系配置信息，和/或，所述总账凭证中所需的字段配置信息。具体的，所述业务单据明细包括：根据商品对象信息服务系统中与实体店铺关联的交易订单生成的业务单据明细，所述实体店铺为多个，对应多个不同的经营主体；所述实体店铺中包括多个不同的部门；此时，所述业务单据明细中的业务要素可以包括实体店铺要素以及所述部门要素，对应的财务要素分别为经营主体要素、成本中心要素，其中，同一成本中心对应同一实体店铺中的一个或者多个部门。此时，所述会计分录规则所需的最小粒度财务要素可以包括成本中心要素，这样，具体在将所述业务单据明细进行分组时，可以将同一实体店铺中同一成本中心对应的至少一个部门对应的多个业务单据明细分为一组。其中，在同一订单中包括多个商品对象标识时，可以对应多条业务单据明细；所述业务单据明细中的业务要素还包括商品对象标识要素以及税率要素；此时，所述会计分录规则所需的最小粒度财务要素还可以时税率粒度；具体在将所述业务单据明细进行分组时，可以将同一实体店铺中同一部门、同一税率对应的多个业务单据明细分为一组。另外，所述业务单据明细账还包括交易日期要素，与会计分录中的记账日期要素对应；此时，可以按照会计分录规则中所需的最小粒度财务要素对应的业务要素，对同一日期内生成的业务单据明细进行分组。其中，具体在对同一组内的业务单据明细进行汇总时，可以将所述业务单据明细中比所述最小粒度财务要素对应的业务要素更低粒度的业务要素对应的字段丢弃；然后，根据剩余的字段，以及组内各条业务单据明细对应的财务金额相关信息的汇总结果，生成业务单据汇总数据。总之，本申请实施例提供的方法中，不需要对每一笔交易进行记账，而是按照会计分录规则，分析出其要求的财务要素，再分析出其对应业务要素，然后根据业务要素对业务数据进行分组，按分组对数据先进行汇总，减少分录记账数据量。如果关账前出现会计规则调整，由于通常是对某一财务要素的会计科目，或者业务要素对应财务要素的映射规则进行调整，但很少对业务要素维度进行调整。比如会调整业务公司对财务公司的映射关系，但通常不会由按公司核算调整成按部门核算，因此分组维度是稳定的。另外，对原始业务单据明细进行分组，然后做汇总计算，不涉及业财数据映射和会计规则，也就不涉及逻辑，因此适于使用包括大数据计算平台或云计算等新型计算工具，可以进一步提升效率。再者，汇总后，数据量只和分组业务维度相关，和同一维度数据量无关。也就说，如果汇总维度是某一个财务公司，那么不管这个财务公司的单据量增大到多少，汇总后也只是一条数据，按业务维度汇总后单据量也指数级减少，由亿级到百或千数量级。因此计算量呈指数级降低，计算时间大幅减少。在汇总后数据上，根据业财数据映射关系，完成业务要素向财务要素的映射，此时单据量已指数级降低，因此计算速度非常快。在根据会计规则做总账时，同样基于汇总后数据进行，在较少数据集上，进行复杂会计规则计算，在提高计算速度同时，准确度也能得到提高。即使在关账前，有会计规则调整，也只需要在汇总后数据上进行，由于单据量已大大减少，重算速度非常快。基于以上所述，通过本申请实施例所提供的方法，解决了大数据量交易场景，准确高效生成各类总账凭证的问题，同时也节省了大量计算资源。与上述实施例二相对应，本申请实施例还提供了一种财务数据处理装置，参见图6，该装置具体可以包括：配置信息获得单元601，用于获得财务信息处理过程中所需的配置信息；业务单据明细获得单元602，用于获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；分组汇总单元603，用于按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；总账凭证生成单元604，用于根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。具体实现时，该装置还可以包括：重新计算单元，用于如果所述配置信息发生错误，则根据修正后的配置信息重新对所述业务单据汇总数据进行会计分录，生成总账凭证信息。其中，所述业务单据明细包括：根据商品对象信息服务系统中与实体店铺关联的商品对象订单生成的业务单据明细，其中，所述订单包括交易订单或采购订单，对于不同类别的订单中生成的业务单据明细，并对应不同的配置信息，以便分别进行财务信息处理。所述商品对象信息服务系统中对商品对象订单的处理链路中包括多个不同的节点，在进行订单处理的过程中，产生不同类别的业务单据明细，并对应不同的配置信息，以便分别进行财务信息处理。其中，所述配置信息包括业务数据与财务数据之间的映射关系配置信息，和/或，所述总账凭证中所需的字段配置信息。所述业务单据明细包括：根据商品对象信息服务系统中与实体店铺关联的交易订单生成的业务单据明细，所述实体店铺为多个，对应多个不同的经营主体；所述实体店铺中包括多个不同的部门；此时，所述业务单据明细中的业务要素包括实体店铺要素以及所述部门要素，对应的财务要素分别为经营主体要素、成本中心要素，其中，同一成本中心对应同一实体店铺中的一个或者多个部门。此时，所述会计分录规则所需的最小粒度财务要素包括成本中心要素；所述分组汇总单元具体可以用于，将同一实体店铺中同一成本中心对应的至少一个部门对应的多个业务单据明细分为一组。或者，在同一订单中包括多个商品对象标识时，对应多条业务单据明细；所述业务单据明细中的业务要素还包括商品对象标识要素以及税率要素；所述会计分录规则所需的最小粒度财务要素包括税率粒度；所述分组汇总单元具体可以用于：将同一实体店铺中同一部门、同一税率对应的多个业务单据明细分为一组。其中，所述业务单据明细账还包括交易日期要素，与会计分录中的记账日期要素对应；所述分组汇总单元具体可以用于：按照会计分录规则中所需的最小粒度财务要素对应的业务要素，对同一日期内生成的业务单据明细进行分组。另外，所述分组汇总单元具体可以包括：字段丢弃子单元，用于将所述业务单据明细中比所述最小粒度财务要素对应的业务要素更低粒度的业务要素对应的字段丢弃；汇总子单元，用于根据剩余的字段，以及组内各条业务单据明细对应的财务金额相关信息的汇总结果，生成业务单据汇总数据。另外，本申请实施例还提供了一种计算机系统，包括：一个或多个处理器；以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:获得财务信息处理过程中所需的配置信息；获得目标记账周期内产生的业务单据明细信息，所述业务单据明细信息中包括多项业务要素；按照会计分录规则中进行汇总时所需的最小粒度财务要素对应的业务要素，将所述业务单据明细进行分组以及组内汇总，生成业务单据汇总数据；根据所述配置信息，将所述业务单据汇总数据进行从业务数据到财务数据的映射，并根据映射结果进行会计分录以生成总账凭证信息。其中，图7示例性的展示出了计算机系统的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。其中，处理器710可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。存储器720可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统700运行的操作系统721，用于控制计算机系统700的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及财务数据处理系统725等等。上述财务数据处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。另外，该计算机系统700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。以上对本申请所提供的财务数据处理方法、装置及计算机系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。当前第1页12