CN114663210A - 数据处理方法、装置、系统、电子设备及存储介质 - Google Patents

Abstract

本公开提供了数据处理方法、装置、系统、电子设备及存储介质，涉及大数据处理等领域。具体实现方案为：响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；基于所述至少一个待处理条目，生成待处理列表；响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息。本公开实施例能够提升数据处理效率以及处理准确性。

Description

数据处理方法、装置、系统、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及大数据处理技术领域，具体涉及一种数据处理方法、装置、系统、电子设备及存储介质。

背景技术

随着计算机技术的发展，采用计算机技术所能够处理的数据类型也越来越多，基于计算机技术对报收类业务进行处理的需求也越来越高。然而，如何提升数据处理效率以及处理准确性，就成为需要解决的问题。

发明内容

本公开提供了一种数据处理方法、装置、系统、电子设备及存储介质。

根据本公开的第一方面，提供了一种数据处理方法，包括：

响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

基于所述至少一个待处理条目，生成待处理列表；

响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息。

根据本公开的第二方面，提供了一种数据处理装置，包括：

聚合模块，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

生成模块，用于基于所述至少一个待处理条目，生成待处理列表；

待处理条目获取模块，用于响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目；

传输模块，用于向所述第二设备反馈所述目标待处理条目的相关信息。

根据本公开的第三方面，提供了一种数据处理系统，包括：

数据处理装置，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；基于所述至少一个待处理条目，生成待处理列表；响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息；

所述第一设备，用于向所述数据处理装置发送所述第一命令；

所述第二设备，用于向所述数据处理装置发送所述选取信息，并接收所述数据处理状态反馈的所述目标待处理条目的相关信息。

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

至少一个处理器；以及

与该至少一个处理器通信连接的存储器；其中，

该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行前述第一方面的方法。

根据本公开的第五方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使该计算机执行前述方法。

根据本公开的第六方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现前述方法。

本实施例提供的方案，可以响应于第一命令，基于初始源数据所生成的候选计划条目确定待处理列表，最终可以反馈所述待处理列表中的目标待处理条目的相关信息。如此，可以实现针对不同的初始源数据所得到的候选计划条目，均采用相同的处理流程完成处理，避免了相关技术中，不同的初始源数据需要采用不同的处理逻辑所带来的效率较低的问题，提升了数据处理效率并且保证了处理准确性。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开一实施例的数据处理方法的流程示意图；

图2是根据本公开一实施例的服务器中预先设置的报收核心模型的示意图；

图3是根据本公开一实施例的服务器中预先设置的所述报收核心模型之间的逻辑关系示意图；

图4是根据本公开一实施例的系统架构的场景示意图；

图5是根据本公开一实施例的命令以及查询的处理场景示意图；

图6是根据本公开一实施例的数据处理架构的场景示意图；

图7是根据线上以及线下报收处理内容的场景示意图；

图8是根据线上报收部分的处理流程示意图；

图9是根据邮件对账的报收过程的处理流程示意图；

图10是根据相关技术中的报收系统组成架构示意图；

图11是根据本公开一实施例的数据处理装置的一种组成结构示意图；

图12是根据本公开另一实施例的数据处理装置的另一种组成结构示意图；

图13是根据本公开一实施例的数据处理系统的一种组成结构示意图；

图14是根据本公开另一实施例的数据处理系统的另一种组成结构示意图；

图15是用来实现本公开实施例的数据处理方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本公开第一方面实施例提供一种数据处理方法，如图1所示，包括：

S101：响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

S102：基于所述至少一个待处理条目，生成待处理列表；

S103：响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息。

本实施例提供的所述数据处理方法可以由数据处理装置执行，所述数据处理装置具体可以为一个电子设备，所述电子设备可以为服务器。

再具体的，所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)，或称为报收核心处理模型(或模块)、或称为报收业务模型(或模块)、或称为领域模型(或模块)等等，本实施例不对其可能的名称进行穷举。

所述数据处理装置(即所述服务器)与所述第一设备之间可以具备第一端口。所述第一设备可以指的是用户侧使用的用户设备，比如，可以为台式机、笔记本电脑、平板电脑等等，不对其进行穷举。所述数据处理装置(即所述服务器)与所述第二设备之间可以具备第二端口。所述第二设备同样可以指的是用户侧使用的用户设备，比如，可以为台式机、笔记本电脑、平板电脑等等，不对其进行穷举。

前述第一设备与所述第二设备可以是不同的，再具体的，所述第一设备与所述第二设备可以是不同身份或不同职务的用户使用的用户设备。示例性的，所述第一设备可以指的是销售或运营部门的用户使用的用户设备，所述第二设备可以为财务部门的用户使用的用户设备。

所述多个候选计划条目可以为基于从多个端口获取的多个初始源数据生成的。所述多个候选计划条目中，任意一个候选计划条目可以是基于所述多个初始源数据中的至少之一生成的。

其中，所述多个端口可以指的是所述数据处理装置(即所述服务器)的全部端口中的至少部分端口。所述多个端口的数量可以为10个、8个，或更多或更少，本实施例不进行限定。所述多个端口中任意一个端口的功能可以包括：在用户设备与所述数据处理装置(即所述服务器)之间进行数据传输。所述用户设备指的可以为任意一个用户侧使用的设备。前述第一设备可以为所述用户设备中之一，同样的前述第二设备也可以为所述用户设备中之一。

所述多个初始源数据中，任意一个初始源数据可以是任意一个用户通过其使用的所述用户设备发来的；所述任意一个初始源数据可以指的是交易数据或交易记录，比如原始合同、原始订单等等。

所述待处理列表中可以包含至少一个待处理条目；所述一个或多个待处理条目中任意一个待处理条目可以是基于所述任意一个候选计划条目生成。

所述目标待处理条目为所述至少一个待处理条目中至少之一，具体的，所述目标待处理条目的数量与所述第二设备发来的所述选取信息的具体内容相关。

可见，通过采用上述方案就可以响应于第一命令，基于初始源数据所生成的候选计划条目确定待处理列表，最终可以反馈所述待处理列表中的目标待处理条目的相关信息。如此，可以实现针对不同的初始源数据所得到的候选计划条目，均采用相同的处理流程完成处理，避免了相关技术中，不同的初始源数据需要采用不同的处理逻辑所带来的效率较低的问题，提升了数据处理效率并且保证了处理准确性。

在一种实现方式中，将前述多个候选计划条目中任意一个候选计划条目称为第i个候选计划条目，下面针对所述第i个候选计划条目的生成方式进行说明，可以包括：

从所述多个初始源数据中，选取至少一个待处理源数据；

基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

所述多个初始源数据中，任意一个初始源数据可以是任意一个用户通过其使用的所述用户设备发来并保存在所述数据处理装置(即所述服务器)的。所述任意一个初始源数据可以指的是交易数据或交易记录，比如原始合同、原始订单等等。

需要指出的是，本实施例提供的方案中，所述数据处理装置(即所述服务器)接收并保存任意一个初始源数据时，可以对其进行对象提取(或信息提取)，比如，对所述任意一个初始源数据提取得到其时标型对象、身份对象、描述对象、参与对象；其中，所述时标型对象可以指的是所述初始源数据在某一个时刻或某一段时间内的状态，比如初始源数据-1在第A1段时间内为订单，初始源数据-2在第A2段时间内为账单，当然，还可以包括其他时标型对象，比如合同、项目、商品等等，这里不做穷举。所述身份对象可以指的是所述初始源数据的关联人物的角色或身份，比如初始源数据-1的关联人物为代理商等等。所述参与对象指的是参与所述初始源数据的相关人物，比如可以包括客户、员工等等。所述描述对象，用于表示所述参与对象的属性，比如参与对象-1为客户B1，则其描述对象可以为所述客户B1的具体属性。

其中，所述从所述多个初始源数据中，选取至少一个待处理源数据，可以包括：基于聚合维度，从所述多个初始源数据中选取所述至少一个待处理源数据。

所述聚合维度可以包括以下至少之一：用户类型、产品类型、时间范围。所述聚合维度可以与报收类型相关，所述报收类型可以是财务部门提供的，比如该财务部门指定报收类型为某一类产品，则所述聚合维度可以包括产品类型；该财务部门制定报收类型为从第一时刻开始到第二时刻结束的全部交易，则所述聚合维度可以包括所述时间范围，该时间范围可以为从所述第一时刻开始到所述第二时刻结束；该第一时刻早于该第二时刻。

所述至少一个待处理源数据的数量可以为一个或多个，这里不对其进行限定。

所述基于所述至少一个待处理源数据，得到第i个聚合数值，可以包括：将所述至少一个待处理源数据分别对应的原始数值相加，得到所述第i个聚合数值。其中，所述至少一个待处理源数据分别对应的原始数值，具体可以指的是：所述至少一个待处理源数据分别对应的金额；相应的，所述第i个聚合数值，具体可以是：所述第i个聚合金额。

所述基于所述第i个聚合数值，生成第i个候选计划条目，可以包括：基于第i组聚合属性以及所述第i个聚合数值，生成所述第i个候选计划条目。

其中，所述第i组聚合属性，可以包括以下至少之一：所述第i个候选计划条目的聚合时间属性信息；所述第i个候选计划条目的标识(ID)、所述第i个候选计划条目的类型、所述第i个候选计划条目的原始标识(ID)、所述第i个候选计划条目的原始类型、所述第i个候选计划条目的计算日期、所述第i个候选计划条目的交易的起始时间和终止时间。

示例性的，前述已经说明，本实施例提供的所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)。前述获取第i个候选计划条目的处理，具体可以由如图2中所示的，所述数据处理装置(即所述服务器)中预先设置的所述报收核心模型中的“履约项”(或称为履约项处理模型(或子模块)，或称为履约项子处理逻辑)来实现。

以候选计划条目为候选履约项、目标计划条目为目标履约项为例，结合图3，具体可以采用以下代码来对以上“履约项”处理逻辑(或称为履约项处理模型)的处理进行示例性说明：

{String id()；

String type()；

String fromId()；

String fromType()；

Date calculateDate()；

Date fromDate()；

Date toDate()；

BigDecimal calculateAmount()；}

其中，“String id()”即数据类型为字符串(String)的所述第i个候选履约项的标识(ID)；“String type()”即数据类型为字符串(String)的所述第i个候选履约项的类型(type)；“String fromId()”即数据类型为字符串(String)的所述第i个候选履约项的原始标识(可以表示为from ID)；“String fromtype()”即数据类型为字符串(String)的所述第i个候选履约项的原始类型(可以表示为from type)；“Date calculateDate()”即所述第i个候选履约项的计算日期；“Date fromDate()”即所述第i个候选履约项的交易的起始时间；“Date toDate()；”即所述第i个候选履约项的交易的终止时间；“BigDecimalcalculateAmount()”即第i个聚合数值，其中“BigDecimal”表示对超过16位有效位的数进行精确计算，“calculateAmount()”表示计算总值，即计算得到前述第i个聚合数值(或称为第i个聚合金额)。

在一种示例中，前述候选计划条目还可以称为候选履约项，或者还可以称为其他名称，这里不对其进行穷举。前述多个候选计划条目中任意之一可以为交易或者签约的最小粒度实体，比如，可以是按照聚合维度(或汇总维度)进行聚合的，其获取到至少一个待处理源数据都是从其他系统的交易数据(即所述多个初始源数据)中得到的。其中，所述其他系统可以包括计费控制台系统，代理商系统等。多个候选计划条目中任意之一中包含了聚合属性(或称为属性实体)，该聚合属性用于对该候选计划条目的属性表述，比如用于表示该候选计划条目为基于时间聚合的，或者基于类型聚合的等等，不再赘述。

可见，通过采用上述方案，就可以从所述多个初始源数据中，选取至少一个待处理源数据，进而得到聚合数值，最终生成第i个候选计划条目。如此，可以根据需求灵活的对初始源数据进行聚合，提升了处理的效率以及灵活性。

在一种实施方式中，所述响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目，包括：响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值。

所述第一命令可以指的是添加命令，该第一命令可以用于从所述多个候选履约行中确定至少一个目标计划条目。举例来说，假设所述第一设备可以指的是运营部门的用户使用的设备；相应的，该运营部门的用户通过该第一设备与所述服务器之间的端口，获取并展示所述服务器当前保存的所述多个候选计划条目；该用户可以在所述第一设备的操作界面中针对所述多个候选计划条目中的至少一个目标计划条目进行选取，响应于针对所述多个候选计划条目中的至少一个目标计划条目执行的选取操作，生成所述第一命令；所述第一设备向所述服务器发送所述第一命令；所述服务器基于接收到的所述第一命令，从所述多个候选计划条目中，确定所述至少一个目标计划条目。

所述基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值，可以包括：获取所述至少一个目标计划条目分别对应的聚合数值，将所述至少一个目标计划条目分别对应的聚合数值相加，得到所述汇总值。

前述实施例已经说明第i个候选计划条目中包含的第i个聚合数值指的是第i个聚合金额；相应的，所述至少一个目标计划条目分别对应的聚合数值指的是：所述至少一个目标计划条目分别对应的聚合金额。所述汇总值具体指的是汇总金额。具体的，所述将所述至少一个目标计划条目分别对应的聚合数值相加，得到所述汇总值，可以为：将所述至少一个目标计划条目分别对应的聚合金额相加，得到所述汇总金额。

上述至少一个目标计划条目以及所述汇总值可以构成来源实体(或称为收入来源实体)中的内容。前述实施例也已经说明，任意一个候选计划条目可以为一个待处理源数据，也可以为多个待处理源数据。也就是说，所述来源实体(或称为收入来源实体)可以是基于一个待处理源数据得到的，或者可以是基于多个待处理源数据聚合得到的，即所述报收来源实体可以为账单数据，或者可以为聚合后的数据。

另外，还可以包括：获取来源标识和/或获取来源类型。其中，所述获取来源标识可以指的是获取所述至少一个目标计划条目的标识；所述获取来源类型可以指的是获取所述至少一个目标计划条目的类型。

示例性的，前述已经说明，本实施例提供的所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)。前述基于所述至少一个目标计划条目(或称为目标履约项)分别对应的聚合数值，确定汇总值的处理，具体可以由如图2中所示的，所述数据处理装置(即所述服务器)中预先设置的所述报收核心模型(或报收业务模型、或领域模型等等)中的“收入来源”(或称为收入来源处理模型(或子模块)，或称为收入来源子处理逻辑)来实现。

以候选计划条目为候选履约项、目标计划条目为目标履约项为例，结合图3，具体可以采用以下代码来对以上“收入来源”(或称为收入来源处理模型(或子模块)，或称为收入来源子处理逻辑)执行的处理进行示例性说明：

{String getSourceId()；

String getSourceType()；

BigDecima1 calculateReportAmount()；

List<ObligationItem>aggregateSource()；}

其中，“String getSourceId()”表示获取来源标识(SourceID)其数据类型为字符串(String)；

“String getSourceType()”表示获取来源类型(SourceType)其数据类型为字符串(String)；

“BigDecima1 calculateReportAmount()”即将所述至少一个目标履约项分别对应的聚合金额相加得到所述汇总金额，其中，“calculate()”表示计算总金额的函数，“ReportAmount”表示报收总额(即前述汇总金额)，“calculateReportAmount()”表示计算得到汇总金额，即计算得到报收汇总金额，“BigDecimal”表示对超过16位有效位的数进行精确计算；

“List<ObligationItem>”表示至少一个目标履约项所组成的列表，“aggregateSource”表示聚合目标履约项，即前述从所述多个候选履约项中，确定至少一个目标履约项。

在一种实施方式中，所述基于所述至少一个待处理条目，生成待处理列表，包括：将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。具体可以包括：将所述至少一个待处理条目添加至任务中的所述待处理列表中，获取所述汇总值，将所述汇总值作为所述待处理列表的总数值。

其中，所述至少一个待处理条目中任意一个待处理条目所包含的具体内容可以包括至少一种属性以及总数值；所述至少一种属性包括以下至少之一：待处理条目的名称、待处理条目的标识(ID)、待处理条目的类型、待处理条目的交易日期、待处理条目的报收日期、待处理条目的相关信息；所述待处理条目的相关信息可以包括报收需要的凭证文件。所述总数值即待处理条目的报收总金额。

上述待处理条目还可以称为报收项，或者还可以称为其他名称，这里不对其进行穷举。

可见，通过采用上述方案，就可以根据多个候选计划条目，确定至少一个待处理条目，最终将至少一个待处理条目并添加至待处理列表中，还可以得到待处理列表的总数值。如此，灵活的根据需求对聚合得到的候选计划条目进行选取，进而生成本次的待处理列表，从而可以保证整体处理的准确性以及效率。

在一种实施方式中，还包括以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

所述第一设备可以为任意一个用户设备。前述第一命令可以用于向所述待处理列表中添加待处理条目，该第一命令具体可以为添加待处理条目的命令。关于基于所述第一命令执行的具体处理在前述实施例已经说明，这里不做重复说明。

在本实施方式中，所述第一设备还可以发送第二命令以及第三命令。

分别来说：

所述响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目，可以包括：响应于接收到所述第一设备发送的第二命令，基于所述第二命令从所述待处理列表中确定待删除待处理条目，将所述待删除待处理条目作为所述第一待处理条目，从所述待处理列表中删除第一待处理条目。这里，所述第一待处理条目的数量可以为一个或多个，本实施例不对其进行限定。上述第一待处理条目还可以称为第一报收项，或者还可以称为其他名称，这里不对其进行穷举。

所述第二命令具体可以用于将第一待处理条目从待处理列表中删除，以完成销账或关账。比如，第二命令具体用于将第一报收项从报收列表中删除。

所述响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中，具体可以包括：响应于接收到所述第一设备发送的第三命令，基于所述第三命令从所述待处理列表中确定所述第二待处理条目，基于所述第三命令包含的更新内容，对所述第二待处理条目的内容进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。所述第二待处理条目的数量可以为一个或多个，本实施例不对其进行限定。上述第二待处理条目还可以称为第二报收项，或者还可以称为其他名称，这里不对其进行穷举。

其中，所述第三命令中可以包括：第二待处理条目的标识、名称中任意之一。所述第三命令还可以包括：更新内容；所述更新内容可以为所述第二待处理条目的至少一种属性和/或总数值的更新内容，所述至少一种属性包括以下至少之一：所述第二待处理条目的名称、所述第二待处理条目的标识(ID)、所述第二待处理条目的类型、所述第二待处理条目的交易日期、所述第二待处理条目的报收日期、所述第二待处理条目的相关信息；所述第二待处理条目的相关信息可以包括报收需要的凭证文件。所述总数值即所述第二待处理条目的报收总金额。

比如，所述第二命令可以用于指示修改第二待处理条目的总数值为新数值，此时所述第二命令可以为退款命令。

可见，通过采用上述方案，可以对当前待处理列表中包含的任意待处理条目进行删除或更新，从而可以避免现有技术中对已有的待处理条目的修改较为复杂的问题，提升了修改效率，最终保证了整体的处理效率。

在一种实施方式中，还可以包括：响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到多个子任务；基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目；其中，所述第j个候选计划条目为所述多个候选计划条目中之一，j为大于等于1的整数。

具体的，所述响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到多个子任务，可以包括：响应于接收到所述第一设备发送的第四命令，基于所述第四命令中包含的所述划分维度对所述第一任务进行划分，得到多个子任务。

其中，所述第一任务可以指的是多个任务中的任意之一，可以根据实际情况从多个任务中进行选取。其中，多个任务中的任意一个任务可以指的是一个对象在多个预计收入时间节点分别对应的预计收入子计划。其中，对象可以指的是合同。

所述划分维度信息包括：时间维度；其中，所述时间维度可以为用户通过第一设备设置的，比如可以包含按照每个月划分，或者按照每周划分等等。

进一步地，所述基于所述第四命令中包含的所述划分维度对所述第一任务进行划分，得到多个子任务，具体可以包括：基于所述第四命令中包含的所述划分维度对第一任务划分，得到的多个目标时间节点中不同目标时间节点对应的预计收入子计划，将多个目标时间节点对应的预计收入子计划作为多个子任务。其中，目标时间节点之间的间隔可以根据前述第四命令中包含的划分维度相关，而预计收入时间节点之间的间隔可以与合同本身的划分相关。举例来说，第四命令中包含的划分维度可以为3个月的时间间隔，相应的目标时间节点之间的间隔为3个月，而预计收入时间可以为1个月的时间间隔。

基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目，可以包括：根据当前时间从所述多个子任务确定至少一个子任务，基于至少一个子任务分别对应的数值，计算得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目。其中，至少一个子任务分别对应的数值，可以指的是至少一个子任务分别对应的金额；所述第j个聚合数值可以指的是第j个聚合金额。基于至少一个子任务分别对应的数值，计算得到第j个聚合数值指的是，将至少一个子任务分别对应的数值相加得到第j个聚合数值。

本实施方式中，第一任务还可以称为第一收入计划，当然还可以称为其他名称，这里不对其进行穷举。子任务还可以称为收入子计划，当然还可以称为其他名称，这里不对其进行穷举。

示例性的，本实施例提供的所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)。进一步地，前述基于第一命令从多个候选计划条目中，确定至少一个待处理条目并生成待处理列表；响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中；以及响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到多个子任务；以上处理可以由如图2中所示的，所述数据处理装置(即所述服务器)中预先设置的所述报收核心模型中的“收入计划”(或称为收入计划处理模型(或子模块)，或称为收入计划子处理逻辑)来实现。

以候选计划条目为候选履约项、待处理条目为报收项、待处理列表为报收列表、第一任务为第一收入计划、子任务为收入子计划为例，结合图3，以“收入计划”(或称为收入计划处理模型(或子模块)，或称为收入计划子处理逻辑)的处理进行示例性说明：

IncomeSource getIncomeSource()；

List<ReportItem>reportPlans()；

void addReportPlan(ReportItem reportItem)；

void deleteReportPlan(ReportItem reportPlan)；

void updateReportPlan(ReportItem reportPlan)；

List<IncomePlan>getSubIncomePlan()；

List<IncomePlan>generateSubIncomePlan()；

其中，“IncomeSource getIncomeSource()”表示获取收入来源(IncomeSource)，即前述获取所述汇总值的处理，“get()”即获取指令；

“List<ReportItem>reportPlans()”表示将所述至少一个报收项(表示为reportItem)添加至收入计划中的所述报收列表，最终得到包含该报收列表的报收计划(即reportPlan)；

“void addReportPlan(ReportItem reportItem)”即响应于接收到第一设备发来的第一命令，从多个候选履约项中，确定至少一个报收项；其中，第一命令表示为“addReportPlan”即添加报收项的命令，报收项表示为“ReportItem”。

“void deleteReportPlan(ReportItem reportPlan)”即响应于接收到所述第一设备发送的第二命令，从所述报收列表中删除第一报收项；其中，“deleteReportPlan”即第二命令，“(ReportItem reportPlan)”表示从报收计划ReportPlan的报收列表中删除第一报收项(ReportItem)。

“void updateReportPlan(ReportItem reportPlan)”即响应于接收到所述第一设备发送的第三命令，对所述报收列表中的第二报收项进行更新，得到更新后的第二报收项，将所述更新后的第二报收项保存在所述报收列表中；其中，“updateReportPlan()”即第三命令，“(ReportItem reportPlan)”表示从报收计划ReportPlan的报收列表中更新第二报收项(ReportItem)。

“List<IncomePlan>getSubIncomePlan()”表示响应于接收到所述第一设备发送的第四命令，获取第一收入计划；“getSubIncomePlan()”即表示获取收入子计划。

“List<IncomePlan>generateSubIncomePlan()”表示生成收入子计划，即前述得到收入子计划；“generateSubIncomePlan()”即生成收入子计划的指令或处理指令。

可见，通过采用上述方案，就可以对当前已有的任务进行进一步的划分，得到至少一个子任务，从而可以采用更细粒度的划分方式得到更细粒度的子任务，为后续的处理提供更加准确的参考依据。

另外，所述响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，向所述第二设备反馈所述目标待处理条目的相关信息的处理中，所述第二设备可以为财务人员使用的用户设备，在财务人员需要对待处理列表中的待处理条目进行报收时，可以获取所述目标待处理条目，并得到目标待处理条目的相关信息，进而完成报收，得到报收结果。其中，所述目标待处理条目的相关信息可以包括：所述目标待处理条目的关联信息，比如该目标待处理条目报收需要的相应的凭证文件。

向所述第二设备反馈所述目标待处理条目的相关信息中还可以包括以下至少之一：所述目标待处理条目的标识、所述目标待处理条目的状态、所述目标待处理条目的名称、所述目标待处理条目的类型、所述目标待处理条目的总数值、所述目标待处理条目的交易日期、所述目标待处理条目的报收日期等等。

此外，还可以包括：响应于接收到所述第二设备发送的第二任务获取请求，为所述第二设备发送所述第二任务的相关信息。其中，所述第二任务的相关信息可以包括第二任务的总金额。

前述已经说明，本实施例提供的所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)。前述响应于接收到所述第二设备发送的第二任务获取请求，为所述第二设备发送所述第二任务的相关信息的处理，具体可以由如图2中所示的，所述数据处理装置(即所述服务器)中预先设置的所述报收核心模型的“报收项”(或称为报收模型，或称为报收子处理逻辑)来实现。

以候选计划条目为候选履约项、待处理条目为报收项、目标待处理条目为目标报收项、待处理列表为报收列表、第二任务为第二收入计划为例，结合图3，以“报收项”(或称为报收模型，或称为报收子处理逻辑)进行示例性说明：

“String getReportItemId()；

String getReportItemName()；

ReportItemType getReportItemType()；

BiaDecimal getReportAmount()；

BigDecimal getIncomeAmount()；

Timestamp getBillingDate()；

Timestamp getReportDate()；

Timestamp getIncomeDate()；

List<Attachment>getAttachments()；”

其中，“String getReportItemId()”表示获取报收项的标识(表示为ReportItemID)其数据类型为字符串(String)；

“String getReportItemName()”表示获取报收项的名称(ReportItemName)其数据类型为字符串(String)；

“ReportItemType getReportItemType()”表示获取报收项的类型(ReportItemType)；

“BiaDecimal getReportAmount()”即将获取报收项的所述总数值(ReportAmount)；

“BigDecimal getIncomeAmount()”即获取第二收入计划的总金额(表示为IncomeAmount)；

“Timestamp getIncomeDate()”即获取第二收入计划的计收日期(IncomeDate)；

“Timestamp getBillingDate()”即获取所述目标报收项的交易日期(BillingDate)；

“Timestamp getReportDate()”即获取所述目标报收项的报收日期(ReportDate)；

“List<Attachment>getAttachments()”即获取目标报收项的关联信息，比如该目标报收项报收需要的相应的凭证文件，其最终可以形成列表形态(即List<Attachment>)。

以上代码可以仅为示例性说明，实际处理中还可以包括如图3所示的获取状态(status)的处理代码，比如“getStatus()”，这里不做穷举。

另外，图2和图3中还示意出“报收项的类型”的属性项，可以为财务根据实际获取，比如产品的类型等等，这里不做穷举。此外，图2、图3中的“I”可以表示一个处理逻辑或者一个执行模块，“E”可以表示一个属性项。

在一种实施方式中，还包括以下至少之一：

响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；

将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

所述第三设备为前述多个用户设备中任意之一。所述第三设备与前述第一设备可以相同或不同，所述第三设备与前述第二设备可以相同或不同，这里不对其进行限定。

所述查询指令中可以包括查询关键信息，比如，可以是：初始源数据、候选计划条目、待处理条目之一的标识；初始源数据、候选计划条目、待处理条目之一的类型；初始源数据、候选计划条目、待处理条目之一的时间范围；查询范围等等。

所述目标对象，具体可以指的是以下至少之一：查找到的初始源数据中的至少部分信息、查找到的候选计划条目中的至少部分信息、查找到的待处理条目中的至少部分信息。其中，所述查找到的初始源数据中的至少部分信息，可以是所述查找到的初始源数据的标识、类型、名称等至少一种；所述查找到的候选计划条目中的至少部分信息，可以是所述查找到的候选计划条目的标识、名称、类型、交易起始时间、交易的终止时间、计算日期中的至少一种；所述查找到的待处理条目中的至少部分信息，可以包括：所述查找到的待处理条目的标识、名称、类型、交易日期、总金额、凭证文件等等的至少一种。

可见，通过采用上述方案，就可以对当前已经构建得到的初始源数据、候选计划条目、待处理条目之一的相关信息进行查询并反馈查询结果，从而保证了可以及时的获取当前任意类型的数据，便于后续进行更改、删除以及添加等操作，提升了整体处理效率。

针对前述实施例提供的数据处理方法，结合图4～图6进一步进行示例性说明：

本实施例提供的所述数据处理方法可以由所述数据处理装置(即所述服务器)中预先设置的处理逻辑来执行，本实施例中将所述数据处理装置(即所述服务器)中预先设置的所述处理逻辑称为报收核心模型(或报收核心处理单元，或报收核心处理逻辑)。该报收核心模型(或报收核心处理单元，或报收核心处理逻辑)和业务技术分离，其逻辑架构可以如图4所示，可以为六边形架构，将输入和输出都放在边缘部分。如图4中所示，数据处理装置可以是从业务系统(比如图4中的计费系统、计收中心、代理商客户端、项目中心等等)中获取到数据(比如前述初始源数据)、或指令(比如前述第一命令、第二命令等)或信息(比如前述选取信息)，还可以从数据仓库中(如图4中的数据中心)获取到数据(比如前述初始源数据)或指令(比如前述第一命令、第二命令等)或信息(比如前述操作信息)，或者还可以是从其他类型的文件中获取到数据(比如前述初始源数据)或指令(比如前述第一命令、第二命令等)或信息(比如前述操作信息)，都不影响数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)的处理。

本实施例通过采用图4所示的这种模式，可以将数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)和外部业务隔离开，保证了数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)不受外界影响，保证了最终处理的准确性。

另外，图4中的端口(Port)即前述第一设备、第二设备或第三设备分别与服务器之间的端口，第一设备、第二设备、第三设备在图4中可以为计费系统、代理商客户端、项目中心等等中的用户设备。并且，如图4所示，所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)进行数据输入和数据输出时，可以通过各个适配器分别与各个端口对应。

本实施例提供的方案中，所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)可以接收第一设备发送的第一命令、第二命令、第三命令，所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)还可以接收第二设备发送的选取信息，以及接收第三设备发送的查询指令。结合图5进行说明：

第一、所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)进行命令处理的说明：

所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)会提供API(Application Programming Interface，应用程序接口)，通过该API可以获取到命令，比如报收(即前述第一命令)、销账(比如第二命令)、退款(如第三命令)、关账(如第二命令)；

在所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)接收到命令后，执行并处理命令；比如收到前述第一命令、第二命令或第三命令中任意之一的情况下，所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)可以执行并处理前述第一命令、第二命令或第三命令(具体的执行并处理的方式与前述实施例相同，这里不做重复说明)；

该所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)处理命令之后，可以将处理结果保存在存储器的资料库中。

第二、所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)对查询指令进行处理的说明：

所述数据处理装置中的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)，在通过API接收到第三设备发来的查询指令的时候，可以通过查询API通过数据层以及事件总线从所述存储器的资料库中获取到查询结果，该查询结果可以包括初始源数据、待处理条目(即报收项)等等中至少之一的目标对象，通过API返回查询结果。

前述实施例中，执行前述数据处理方法的数据处理装置的处理架构，可以如图6所示，包括：用户接口层、应用层、领域层以及基础设施层和存储层。其中，所述领域层中包含了执行前述数据处理方法的所述报收核心模型(或报收核心处理单元，或报收核心处理逻辑)；所述用户接口层可以用于接收用户设备发来的信息(比如前述第一命令、第二命令、第三命令、操作信息、查询指令等等)，所述用户接口层可以包含前述图4中的多个端口；所述应用层可以响应于各种应用的操作进行处理；所述基础设施层则可以用于维护所述报收核心模型(或报收核心处理单元，或报收核心处理逻辑)，比如定期查看报收核心模型(或报收核心处理单元，或报收核心处理逻辑)是否存在处理错误，并及时修复等等，不对其进行穷举；所述存储层用于保存各类数据(比如前述初始源数据、前述待处理条目(即报收项)、前述候选计划条目(即候选履约项)等等，不再穷举)。

最后，结合相关技术对本实施例的效果进行说明：

在相关技术中的财务计收,是将线上控制台交易和线下合同交易的金额，按时间计入财务收入的过程，具体可以指的是：每月销售运营根据线上产生的账单收入金额、及线下客户经理上报的收入金额，进行统计汇总并上报财务的过程。即商品交付后(履约义务完成)，根据双方确认的账单金额，把收入记到公司财务账上的过程。由于产商品在售卖的过程中，会有不同的交易方式、计费方式、出账方式、付费方式，计收方式等，报收流程和上报的报收金额，会根据这些不同点而不同。在业务的不断扩展和升级，财务要求的收入的精细化程度的提高，账单的灵活调整等需求下，要求报收需要灵活的应对各种业务需求，上报的产商品符合会计准则的交易金额。

报收从最开始的完全的线下化报收到目前的半线上化报收，到接下来的完全的线上化报收的需求，要求报收系统能够灵活的对接入的各种类型的交易金额数据进行报收。然而，在相关技术中的报收系统在支持完全线上化复杂度比较高，给财务计收的报收数据统一性不高，对新增加的需要线上化的业务或者是需要应对财务的会计计收方式适应性也不够。在报收的过程中会对一些交易的数据进行调整，比如销账，退款，金额调增等，并且不同类型的交易数据对应着不同的处理逻辑，随着线上化要求的增加这些逻辑也会随着增加。如果在现有系统的基础上进行扩展，将会导致现有的报收系统的复杂性越来越高，对后续业务的扩展难度会不断的增加。

会计计收准则要求企业需要将交易的金额按照会计的要求的准则计入到财务，针对目前产商品的不同售卖方式和计费方式，计收方式，付费方式等的不同。目前有Billing控制台的售卖后直接出账单是否需要邮件对账方式等，进行了不同的逻辑计算和统计报收总金额数据，在报收过程中需要不同的角色进行参与和流程的审核过程。

产商品的外部收入包括线上收入报收和线下收入报收两个部分。其中，如图7所示，所述线上收入报收的内容(参见)包括：线上账单、线上账单销账、调整账单收入等等；线下收入报收的内容包括：线下收入、预置账单调整账单、合同拆分调整、现金券报收等等。线上报收部分的会使用不同的流程分支，如图8所示，包括：首先判断是否为线上业务，若是，则判断出账方式为线上业务计费账单或线上业务手工账单；若为线上业务计费账单，则设置其报收来源为计费账单，基于该账单进行报收；若为线上业务手工账单，或者为线下业务，则设置其报收来源为履约商品行，基于该账单的履约方式按照履约业务进行报收。

在报收过程中，会从不同的系统获取源交易数据，对源交易数据进行计算，最终确认需要进行推送给财务进行计收的总量或者总金额，比如邮件对账的报收过程如图9所示，可以包括：

步骤901：数据中心脚本接口调用报收系统，比如该脚本接口调用的具体为邮件对账的报收系统。

步骤902：所述报收系统生成计划行；比如该计划行可以为计划代码为B开头的计划行。

步骤903：所述报收系统生成报收信息。

步骤904：所述报收系统向计费系统请求销账和退款金额。比如，可以是针对步骤903生成的报收信息(或称为计费账单)的销账和退款金额。

步骤905：所述报收系统获取计费系统返回的实际应收金额。其中，所述实际应收金额可以为计费系统基于销账和退款金额，在报收信息的基础上计算得到的。

步骤906：所述报收系统生成收入信息。具体指的是，所述报收系统基于所述实际应收金额计算得到所述收入信息。

步骤907：所述报收系统生成调整数据以及调整的详细信息。本步骤可以是根据实际需求执行的。所述调整数据可以指的是金额的具体调整数据，调整的详细信息中可以包含报收信息的相关信息等等，比如报收信息的标识、类型等等。

步骤908：销售经理进行报收，上传对账材料。具体的，销售经理获取所述报收系统中的报收信息，对报收信息进行报收，并上传相关的对账材料。

步骤909：报收管理员进行审核。具体指的是，报收管理员接入所述报收系统后，对报收信息及其相关的对账材料进行审核。

步骤910：所述报收系统将报收信息发送至计收中心。也就是在报收管理员审核通过的情况下，报收系统将报收信息发送至计收中心。

步骤911：财务审核后下发报收数据至所述报收系统。其中，报收数据可以指的是报收结果。

由于交易入口的不同，数据来源不同，报收系统涉及的上下游会也是比较多，如图10所示：数据来源可以包括有项目中心、销售、产研方、计收中心、财务计收中心、计费系统、数据中心、收款系统等等；上述数据来源分别与报收系统通过不同的交易入口传输数据。而在报收系统内，也包含多种处理模块包括了收入/报收管理、手工账单、收入分成等等。每个数据来源在报收系统中对应的报收场景(比如线上报收和线下报收)都用自己的报收模型或报收逻辑，统一性不够。

可以看出，相关技术的方案存在以下问题：没有统一的报收逻辑；报收和账单的调整耦合度高，导致代码的耦合度高，不利于将来扩展场景等等。

本申请实施例所提供的方案，抽象建立出统一的报收核心模型(或报收核心处理单元，或报收核心处理逻辑)，对接入的报收数据进行统一和业务细节上的拆分，可以统一进行不同业务场景下的报收处理，也就是均可以执行以下处理：响应于第一命令，基于初始源数据所生成的候选计划条目确定待处理列表，最终反馈所述待处理列表中的目标待处理条目的相关信息。如此，可以实现针对不同的初始源数据所得到的候选计划条目，均采用相同的处理流程完成报收，避免了相关技术中，不同的初始源数据需要采用不同的处理逻辑实现报收所带来的效率较低的问题，提升了数据处理效率并且保证了处理准确性。并且，可以对在过程中产生的各类数据，可以进行多视角的查询，便于指标的分析和统计，进而为后续的处理提供了更加准确的参考，保证了后续服务的快捷以及准确性。

本公开第二方面实施例提供一种数据处理装置，如图11所示，包括：

聚合模块1101，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

生成模块1102，用于基于所述至少一个待处理条目，生成待处理列表；

待处理条目获取模块1103，用于响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目；

传输模块1104，用于向所述第二设备反馈所述目标待处理条目的相关信息。

在图11的基础上，如图12所示，所述装置还可以包括：

计划条目生成模块1201，用于从所述多个初始源数据中，选取至少一个待处理源数据；基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

所述聚合模块1101，用于响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值；

所述生成模块1102，用于将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。

所述聚合模块1101，用于执行以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

所述聚合模块，用于响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到至少一个子任务；基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目；其中，所述第j个候选计划条目为所述多个候选计划条目中之一，j为大于等于1的整数。

所述装置，还包括：

查询模块1202，用于响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；

所述传输模块1104，用于将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

通过采用上述方案就可以将多个端口获取的多个初始源数据生成多个候选计划条目，进而基于多个候选计划条目确定待处理列表，最终可以响应于第二选取信息，对所述待处理列表中的目标待处理条目进行总金额的确定。

再进一步地，以候选计划条目为候选履约项、待处理条目为报收项、目标待处理条目为目标报收项、待处理列表为报收列表、任务为收入计划为例，结合图2和图12来说，图12中的前述聚合模块可以用于执行图2中的“收入来源”(或称为收入来源处理模型(或子模块)，或称为收入来源子处理逻辑)的相应功能；图12中的生成模块1102可以用于执行图2中的“收入计划”(或称为收入计划处理模型(或子模块)，或称为收入计划子处理逻辑)的相应功能；图12中的待处理条目获取模块1103，可以用于执行图2中“报收项”(或称为报收模型，或称为报收子处理逻辑)的相应功能，另外，图2中的报收项的类型可以是待处理条目获取模块1103能够获取到的相关信息中的一种；图12中的传输模块1104可以包含前述多个端口；图12中的计划条目生成模块1201，可以用于执行图2中“履约项”(或称为履约项处理模型(或子模块)，或称为履约项子处理逻辑)的相应功能。

本公开第三方面实施例提供一种数据处理系统，如图13所示，包括：

数据处理装置1301，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；基于所述至少一个待处理条目，生成待处理列表；响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息；

第一设备1302，用于向所述数据处理装置发送所述第一命令；

第二设备1303，用于向所述数据处理装置发送所述第二命令，并接收所述数据处理状态反馈的所述目标待处理条目的相关信息。

所述数据处理装置1301，用于从所述多个初始源数据中，选取至少一个待处理源数据；基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

所述数据处理装置1301，用于响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值；将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。

所述数据处理装置1301，用于执行以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

所述数据处理装置1301，用于响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到至少一个子任务。

在图13的基础上，如图14所示，所述系统，还包括：

第三设备1401，用于向所述数据处理装置发送查询指令，接收所述数据处理装置反馈的查询结果；

所述数据处理装置1301，用于响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图15示出了可以用来实施本公开的实施例的示例电子设备1500的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图15所示，电子设备1500包括计算单元1501，其可以根据存储在只读存储器(ROM)1502中的计算机程序或者从存储单元1508加载到随机访问存储器(RAM)1503中的计算机程序，来执行各种适当的动作和处理。在RAM 1503中，还可存储电子设备1500操作所需的各种程序和数据。计算单元1501、ROM 1502以及RAM 1503通过总线1504彼此相连。输入/输出(I/O)端口1505也连接至总线1504。

电子设备1500中的多个部件连接至I/O端口1505，包括：输入单元1506，例如键盘、鼠标等；输出单元1507，例如各种类型的显示器、扬声器等；存储单元1508，例如磁盘、光盘等；以及通信单元1509，例如网卡、调制解调器、无线通信收发机等。通信单元1509允许电子设备1500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1501可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1501的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1501执行上文所描述的各个方法和处理。例如，在一些实施例中，上文所描述的各个方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1508。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1502和/或通信单元1509而被载入和/或安装到电子设备1500上。当计算机程序加载到RAM 1503并由计算单元1501执行时，可以执行上文所描述的各个方法的一个或多个步骤。备选地，在其他实施例中，计算单元1501可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行上文所描述的各个方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或者触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (21)

1.一种数据处理方法，包括：

响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

基于所述至少一个待处理条目，生成待处理列表；

响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息。

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

从所述多个初始源数据中，选取至少一个待处理源数据；

基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

3.根据权利要求1或2所述的方法，其中，所述响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目，包括：响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值；

所述基于所述至少一个待处理条目，生成待处理列表，包括：将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。

4.根据权利要求1-3任一项所述的方法，还包括以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

5.根据权利要求1-3任一项所述的方法，还包括：

响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到多个子任务；

基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目；其中，所述第j个候选计划条目为所述多个候选计划条目中之一，j为大于等于1的整数。

6.根据权利要求1-3任一项所述的方法，还包括：

响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；

将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

7.一种数据处理装置，包括：

聚合模块，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；

生成模块，用于基于所述至少一个待处理条目，生成待处理列表；

待处理条目获取模块，用于响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目；

传输模块，用于向所述第二设备反馈所述目标待处理条目的相关信息。

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

计划条目生成模块，用于从所述多个初始源数据中，选取至少一个待处理源数据；基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

9.根据权利要求7或8所述的装置，其中，所述聚合模块，用于响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值；

所述生成模块，用于将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。

10.根据权利要求7-9任一项所述的装置，其中，所述聚合模块，用于执行以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

11.根据权利要求7-9任一项所述的装置，其中，所述聚合模块，用于响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到至少一个子任务；基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目；其中，所述第j个候选计划条目为所述多个候选计划条目中之一，j为大于等于1的整数。

12.根据权利要求7-9任一项所述的装置，还包括：

查询模块，用于响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；

所述传输模块，用于将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

13.一种数据处理系统，包括：

数据处理装置，用于响应于接收到第一设备发来的第一命令，从多个候选计划条目中，确定至少一个待处理条目；其中，所述多个候选计划条目为基于从多个端口获取的多个初始源数据得到的；基于所述至少一个待处理条目，生成待处理列表；响应于接收到第二设备发来的选取信息，从所述待处理列表中确定目标待处理条目，并向所述第二设备反馈所述目标待处理条目的相关信息；

所述第一设备，用于向所述数据处理装置发送所述第一命令；

所述第二设备，用于向所述数据处理装置发送所述选取信息，并接收所述数据处理状态反馈的所述目标待处理条目的相关信息。

14.根据权利要求13所述的系统，其中，所述数据处理装置，用于从所述多个初始源数据中，选取至少一个待处理源数据；基于所述至少一个待处理源数据，得到第i个聚合数值，并基于所述第i个聚合数值，生成第i个候选计划条目；其中，所述第i个候选计划条目为所述多个候选计划条目中之一，i为大于等于1的整数。

15.根据权利要求14所述的系统，其中，所述数据处理装置，用于响应于接收到所述第一设备发来的所述第一命令，从所述多个候选计划条目中，确定至少一个目标计划条目作为所述至少一个待处理条目，并基于所述至少一个目标计划条目分别对应的聚合数值，确定汇总值；将所述至少一个待处理条目添加至所述待处理列表，将所述汇总值作为所述待处理列表的总数值。

16.根据权利要求13-15任一项所述的系统，其中，所述数据处理装置，用于执行以下至少之一：

响应于接收到所述第一设备发送的第二命令，从所述待处理列表中删除第一待处理条目；

响应于接收到所述第一设备发送的第三命令，对所述待处理列表中的第二待处理条目进行更新，得到更新后的第二待处理条目，将所述更新后的第二待处理条目保存在所述待处理列表中。

17.根据权利要求13-15任一项所述的系统，其中，所述数据处理装置，用于响应于接收到所述第一设备发送的第四命令，基于所述第四命令对第一任务进行划分，得到至少一个子任务；基于所述多个子任务中的至少一个子任务，得到第j个聚合数值，并基于第j个聚合数值，生成第j个候选计划条目；其中，所述第j个候选计划条目为所述多个候选计划条目中之一，j为大于等于1的整数。

18.根据权利要求13-15任一项所述的系统，还包括：

第三设备，用于向所述数据处理装置发送查询指令，接收所述数据处理装置反馈的查询结果；

所述数据处理装置，用于响应于接收到第三设备发送的查询指令，基于所述查询指令从所述多个初始源数据、所述多个候选计划条目以及所述至少一个待处理条目中，选取目标对象；将所述目标对象作为查询结果，将所述查询结果发送至所述第三设备。

19.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-6中任一项所述的方法。

20.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-6中任一项所述的方法。

21.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-6中任一项所述的方法。

Images