网点数智化管理方法及相关装置

技术领域

本申请涉及系统开发、物流配送、物联网和人工智能的技术领域，尤其涉及网点数智化管理方法及相关装置。

背景技术

在现阶段的快递物流和供应链领域中，由于电商行业、直播带货的兴起，造成了快递件量日益增多，尤其是在双11等大促节日的高峰期，面对日均亿级的快递件量，快递公司和网点分部难以对快递件量进行业务量数据的查询、快递问题件发布和处理、快递无头件处理等，因此需要实现对各快递公司、网点的快递件量的精准管理。

数智化是数字化、AI和业务三个要素的交集，数字化是基础，AI与业务的融合是核心，数智化是数字化发展的下一阶段。数智化是以海量大数据为基础，结合人工智能相关技术，打通原来数据“端到端孤岛”，结合具体场景去决策、解决问题，将“人”从繁杂的数字劳动中解脱出来，由此，企业也能通过数据和智能化技术，赋能企业管理和业务，带来商业提效和增长。

专利CN113822392A公开了基于数智化供应链柔性配送方法，所述方法包括：与出入口监测模块相连接的配送库；且出入口监测模块相连接于移动端系统，并相连接于云端服务器；设置有云端数据库，云端数据库包括数据中心、历史数据中心；设置分别与数据中心相连接的云端服务器；且云端服务器分别与历史数据中心相连接，与输入模块相连接，与信息交换模块相连接；信息交换模块与配送数据模块相连接，配送数据模块与烟草销售户端相连接；烟草销售户端与二维码信息单元相连接。该方法采用云端服务器和云端数据库，保证了服务器的稳定运行，以及终端客户端对数据库的随时调用；采用网络电子票据，采用识别二维码的方式，完成配送人员与烟草销售户交接烟草的确认。但是，该方法未提及移动端系统的开发过程，未提及系统的组件化。

基于此，本申请提供了网点数智化管理方法及相关装置，以解决上述现有技术中的问题。

发明内容

本申请的目的在于提供网点数智化管理方法及相关装置，采用MGJRouter组件化多层架构开发网点数智化管理系统，提高开发效率和使用体验。

本申请的目的采用以下技术方案实现：

第一方面，本申请提供了一种网点数智化管理方法，应用于网点数智化管理系统，所述网点数智化管理系统采用MGJRouter组件化多层架构，并且所述网点数智化管理系统设置有MGJRouter、多个调用方以及多个服务方组件；

所述方法包括：

利用交互设备接收针对目标调用方的交互操作，所述目标调用方是多个调用方的其中一个；

响应于所述交互操作，利用所述目标调用方对应的URL，从预先存储于所述MGJRouter的注册表中查询得到所述URL对应的代码块；

利用所述目标调用方通过所述MGJRouter调用与所述代码块相对应的多个服务方组件的其中一个，以使被调用的目标服务方组件执行所述交互操作对应的处理步骤。

该技术方案的有益效果在于：一方面，采用MGJRouter组件化多层架构开发网点数智化管理系统，MGJRouter于开发人员而言容易上手，功能也比较简单，更加适用于页面跳转这种业务比较多的场景，并且，基于不同的调用方调用不同的服务方组件，从而以组件化的方式提供服务，集成度高，代码简洁，降低了开发过程的复杂度，提高了开发效率。另一方面，工作人员可以利用交互设备与网点数智化管理系统的目标调用方进行交互，目标调用方响应于交互操作(例如是查询操作、数据维护操作等)，利用自身对应的URL，从预先存储的注册表中查询得到对应的代码块，再利用代码块调用对应的服务方组件，被调用的目标服务方组件执行交互操作对应的处理步骤，从而实现工作人员所需求的功能；在整个过程中，工作人员只需要(利用交互设备)针对目标调用方发起交互操作，剩下的过程都是(由目标调用方和目标服务方组件)自动执行，自动化程度高，因此提高了工作人员的使用体验。又一方面，利用网点数智化管理系统，为快递公司和网点分部提供例如是业务量数据的查询、快递问题件发布和处理、快递无头件处理等功能，能够实现对各快递公司、网点的快递件业务量的精准管理。

在一些可选的实施方式中，所述网点数智化管理系统利用数据库服务器存储多个网点的网点数据，每个所述网点的网点数据包括每个所述网点对应的订单的扫描数据，每个所述订单的扫描数据用于指示其所对应的订单标识、网点标识和扫描类型；

当所述交互操作是上传操作时，所述目标服务方组件是上传组件，所述上传组件用于接收多个所述交互设备上传的多个所述订单的扫描数据；

所述方法还包括：

基于每个所述订单对应的网点标识，将每个所述订单的扫描数据存储至其所对应的网点所对应的待传送队列；

当检测到其中一个待传送队列中存储的扫描数据的数量不小于预设数量时，将所述其中一个待传送队列中的所有订单的扫描数据批量上传至所述数据库服务器。

该技术方案的有益效果在于：利用网点数智化管理系统可以提供扫描数据的上传服务(上传至数据库服务器)，但由于网点众多(一个快递公司可能有几千个网点)，因此需要上传扫描数据的交互设备很多，如果这些交互设备同时访问数据库服务器，则可能给数据库服务器造成较大压力，甚至可能导致服务器过载、崩溃等。因此，可以以网点为维度，将每个订单的扫描数据按照网点存储至网点对应的待传送队列中，每个待传送队列可以对应一个或多个网点，这样，交互设备并不直接将扫描数据上传至数据库服务器，而是将待上传的扫描数据基于网点分流至多个待传送队列，经过待传送队列的中转存储至数据库服务器；并且，待传送队列并非进行实时中转，而是当存储的扫描数据的数量不小于预设数量时，将这些扫描数据批量上传至数据库服务器；一方面，大大减少了访问数据库服务器的外部设备数量，另一方面，采用延时批量上传，大大减少了访问数据库服务器的次数。

在一些可选的实施方式中，当所述交互操作是标记操作时，所述目标服务方组件是标记组件，所述标记组件用于将一个或多个所述订单标记为问题件；

所述方法还包括：

针对每个所述问题件执行以下处理：

获取所述问题件的订单标识以及所述问题件的订单标识关联的网点标识；

基于所述问题件的订单标识，从所述数据库服务器中查询是否存在所述订单的扫描数据，当存在时，将查询得到的扫描数据存储至所述缓存区域；

基于所述问题件的订单标识关联的每个网点标识，从每个所述网点标识对应的网点的待发送队列中查询是否存在所述问题件的扫描数据，当存在时，将查询得到的扫描数据存储至预设的缓存区域；

当所述缓存区域中存在查询得到的扫描数据时，基于查询得到的扫描数据，生成所述问题件的扫描记录并存储至所述数据库服务器。

该技术方案的有益效果在于：一般而言，每个订单从生成到完成配送需要经过多次扫描，产生多个扫描数据(例如在每个分拨站点就有卸车扫描和装车扫描两次扫描，产生两个扫描数据)，当出现问题件时，问题件可能已经配送到终端收件人手中，但也可能处于运输过程或者配送过程中，与此同时，问题件的一部分扫描数据可能已经存储到数据库服务器中，另一部分扫描数据可能还在多个网点对应的待传送队列中、尚未上传至数据库服务器，因此，可以从这两类存储位置分别查询是否存在该问题件的扫描数据，用以生成对应的扫描记录，扫描记录可以用于后续的信息发布或者退款、退货等处理事宜。当标记组件用于将多个订单标记为问题件时，可以针对多个问题件进行批量处理，提高问题件的处理效率。

在一些可选的实施方式中，每个所述网点的网点数据还包括每个所述网点对应的罚款数据；

当所述交互操作是针对所述问题件的仲裁操作时，所述目标服务方组件是仲裁组件，所述仲裁组件用于确定是否需要罚款以及当需要罚款时被罚款的网点和金额；

所述方法还包括：

生成一条罚款数据并存储至所述数据库服务器，所述罚款数据用于指示被罚款的网点和金额。

该技术方案的有益效果在于：有时候出现问题件的原因可能是网点操作不当造成的，因此需要对承担责任的网点进行罚款，在网点数智化管理系统中设置仲裁组件，用于为工作人员提供仲裁服务，工作人员可以利用仲裁组件选择对一个或多个网点进行罚款，并且当需要罚款时还可以录入(或者系统自动计算得到)每个网点被罚款的金额，有利于对网点进行精细化管理。

在一些可选的实施方式中，每个所述网点的网点数据还包括每个所述网点对应的历史业务量数据、订单数据、应收应付账单数据和预付款数据。

该技术方案的有益效果在于：历史业务量数据能够指示过去的业务量(有史以来或者一段时间段内的)，可以用于后续的数据挖掘过程，评估每个网点的业务能力等；订单数据能够指示订单的发件人、收件人、发件地址、收件地址、物品类型、保价类型等，可以用于后续的数据查询、数据挖掘过程；应收应付账单数据能够指示应收应付金额，便于每个网点进行线上收账、付款的管理；预付款数据能够指示预付款情况，便于每个网点甄别优质客户、有针对性地提供定制化服务。

在一些可选的实施方式中，所述方法还包括：

将多个识别码数据存储至所述数据库服务器，并将每个所述识别码数据的分配状态初始化为未分配，每个所述识别码数据包括一个识别码及其识别码标识；

每隔预设时长，针对每个所述网点执行以下处理：

基于所述网点的历史业务量数据，预测得到所述网点在预设时间段内所需要的识别码数量，所述预设时间段的起始时刻在当前时刻之后；

将未分配的识别码数据中与所述网点所需要的识别码数量相应的识别码数据的分配网点设置为所述网点，并将完成分配的识别码数据的分配状态调整为已分配。

该技术方案的有益效果在于：每隔预设时长，为每个网点分配一定数量的识别码数据，其中，每个网点分配得到的识别码数量是基于该网点的历史业务量数据预测得到的。这样做的好处是，一方面，通过网点数智化管理系统提供自动分配识别码的功能，进一步提升了系统的集成度，提高了工作人员分配识别码的效率；另一方面，在实际应用中，由于每个网点的业务量不同，所需要的识别码数量不同，因此对识别码进行平均分配是不够科学、合理的，采用上述分配方式，首先预测得到每个网点所需要的识别码数量，再从未分配的识别码数据中将相应数量的识别码数据分配给对应网点，实现了识别码的智能化分配；又一方面，利用分配状态这一字段指示识别码是否被分配，容易开发和实现。

在一些可选的实施方式中，所述基于所述网点的历史业务量数据，预测得到所述网点在预设时间段内所需要的识别码数量，包括：

从所述网点的历史业务量数据中获取与所述预设时间段相应的历史业务量数据；

将所获取的历史业务量数据输入业务量预测模型，得到所获取的历史业务量数据对应的预测业务量；

基于所获取的历史业务量数据对应的预测业务量，确定所述网点所需要的识别码数量；

其中，所述业务量预测模型的训练过程包括：

获取训练集，所述训练集包括多个训练数据，每个所述训练数据包括一个用于训练的历史业务量数据及其对应的预测业务量的标注数据；

针对每个所述训练数据，执行以下处理：

将所述训练数据中的历史业务量数据输入预设的深度学习模型，得到所输入的历史业务量数据对应的预测业务量的预测数据；

基于所输入的历史业务量数据对应的预测业务量的预测数据和标注数据，对所述深度学习模型的模型参数进行更新；

检测是否满足预设的训练结束条件；如果是，则将训练得到的深度学习模型作为所述业务量预测模型；如果否，则利用下一个所述训练数据继续训练所述深度学习模型。

该技术方案的有益效果在于：一方面，基于预设时间段的长度、所处区间的不同，网点所需要的识别码数量不同(例如促销活动期间网点需要的识别码数量会大大上升)，因此需要基于预设时间段，动态调整为网点分配的识别码数量。另一方面，有针对性地基于不同的预设时间段，从全部历史业务量数据中筛选得到部分历史业务量数据用于后续的预测过程，能够得到更精准的预测业务量(例如用去年同期来预测今年同期，用一个促销期间来预测另外的促销期间)。又一方面，业务量预测模型可以由大量的训练数据训练得到，能够针对不同的输入数据预测得到相应的预测业务量，适用范围广，智能化水平高。通过设计，建立适量的神经元计算节点和多层运算层次结构，选择合适的输入层和输出层，就可以得到预设的深度学习模型，通过该预设的深度学习模型的学习和调优，建立起从输入到输出的函数关系，虽然不能100％找到输入与输出的函数关系，但是可以尽可能地逼近现实的关联关系，由此训练得到的业务量预测模型，可以实现获取历史业务量数据对应的预测业务量的功能，且计算结果准确性高、可靠性高。

第二方面，本申请提供了一种网点数智化管理系统，所述网点数智化管理系统采用MGJRouter组件化多层架构，并且所述网点数智化管理系统设置有MGJRouter、多个调用方以及多个服务方组件；

每个所述调用方用于：

响应于交互操作，利用自身对应的URL，从预先存储于所述MGJRouter的注册表中查询得到所述URL对应的代码块；

通过所述MGJRouter调用与所述代码块相对应的多个服务方组件的其中一个；

其中，所述交互操作是利用交互设备接收的针对每个所述调用方自身的操作；

每个所述服务方组件用于：

当被调用时，执行所述交互操作对应的处理步骤；

在所述网点数智化管理系统的开发过程中，采用HyBrid App开发模式，并且采用weex框架作为开发框架。

第三方面，本申请提供了一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项方法的步骤。

附图说明

下面结合附图和实施方式对本申请进一步说明。

图1示出了本申请提供的一种网点数智化管理方法的流程示意图。

图2示出了本申请提供的一种上传扫描数据的流程示意图。。

图3示出了本申请提供的一种生成扫描记录的流程示意图。

图4示出了本申请提供的一种分配识别码的流程示意图。

图5示出了本申请提供的一种确定识别码数量的流程示意图。

图6示出了本申请提供的一种网点数智化管理系统的结构示意图，

图7示出了本申请提供的一种电子设备的结构框图。

图8示出了本申请提供的一种用于实现网点数智化管理方法的程序产品的结构示意图。

具体实施方式

下面，结合附图以及具体实施方式，对本申请做进一步描述，需要说明的是，在不相冲突的前提下，以下描述的各实施例之间或各技术特征之间可以任意组合形成新的实施例。

参见图1，图1示出了本申请提供的一种网点数智化管理方法的流程示意图。所述网点数智化管理方法应用于网点数智化管理系统，所述网点数智化管理系统采用MGJRouter组件化多层架构，并且所述网点数智化管理系统设置有MGJRouter、多个调用方以及多个服务方组件；

所述方法包括：

步骤S101：利用交互设备接收针对目标调用方的交互操作，所述目标调用方是多个调用方的其中一个；

步骤S102：响应于所述交互操作，利用所述目标调用方对应的URL，从预先存储于所述MGJRouter的注册表中查询得到所述URL对应的代码块；

步骤S103：利用所述目标调用方通过所述MGJRouter调用与所述代码块相对应的多个服务方组件的其中一个，以使被调用的目标服务方组件执行所述交互操作对应的处理步骤。

本申请中，所述目标调用方通过所述MGJRouter调用与所述代码块相对应的多个服务方组件的其中一个，即被调用的目标服务方组件。

由此，一方面，采用MGJRouter组件化多层架构开发网点数智化管理系统，MGJRouter于开发人员而言容易上手，功能也比较简单，更加适用于页面跳转这种业务比较多的场景，并且，基于不同的调用方调用不同的服务方组件，从而以组件化的方式提供服务，集成度高，代码简洁，降低了开发过程的复杂度，提高了开发效率。

另一方面，工作人员可以利用交互设备与网点数智化管理系统的目标调用方进行交互，目标调用方响应于交互操作(例如是查询操作、数据维护操作等)，利用自身对应的URL，从预先存储的注册表中查询得到对应的代码块，再利用代码块调用对应的服务方组件，被调用的目标服务方组件执行交互操作对应的处理步骤，从而实现工作人员所需求的功能；在整个过程中，工作人员只需要(利用交互设备)针对目标调用方发起交互操作，剩下的过程都是(由目标调用方和目标服务方组件)自动执行，自动化程度高，因此提高了工作人员的使用体验。

又一方面，利用网点数智化管理系统，为快递公司和网点分部提供例如是业务量数据的查询、快递问题件发布和处理、快递无头件处理等功能，能够实现对各快递公司、网点的快递件业务量的精准管理。

所述网点数智化管理系统采用MGJRouter组件化方案多层架构。MGJRouter是一个单例对象，在其内部维护着一个“URL->block(即代码块)”格式的注册表，通过这个注册表来保存服务方组件注册的block，以及使调用方可以通过URL映射出block，并通过MGJRouter对服务方组件发起调用。在服务方组件中都对外提供一个接口类，在接口类内部实现block的注册工作，以及block对外提供服务的代码实现。每一个block都对应着一个URL，调用方可以通过URL对block发起调用，从而实现对服务方组件的调用。在实际应用中，需要将所有服务方的接口类实例化，以完成注册工作，以使MGJRouter中所有服务方组件的block可以正常提供服务。

本申请中的网点例如可以包括起始站点(网点)、分拨站点(网点)和末端站点(网点)。

本申请对调用方不作限定，其例如是所述网点数智化管理系统的前端显示页面中的功能按钮，例如是上传按钮、查询按钮、新增按钮、删除按钮、编辑按钮等。前端显示页面中可以设置有一个或多个功能按钮，本申请对此不作限定。

本申请对服务方组件不作限定，其例如可以包括上传组件、查询组件、仲裁组件、数据维护组件等。

本申请对交互设备不作限定，其例如可以包括巴枪、手机、平板电脑、笔记本电脑、台式计算机、智能终端设备等。与所述网点数智化管理系统进行数据交互的可以包括快递公司对应的交互设备和各网点对应的交互设备，例如是网点(快递站)的站长的台式计算机、快递员甲的手机、快递员乙的巴枪等。每个网点对应的交互设备可以是一个或多个。所述网点数智化管理系统可以服务于一家多或多家快递公司。

本申请对交互操作不作限定，其例如可以包括上传操作、数据维护操作、标记操作、仲裁操作等。其中，数据维护操作例如可以包括增加操作、删除操作、编辑操作等。

本申请中的URL是指统一资源定位符(Uniform Resource Locator)。

所述交互操作对应的处理步骤可以是一个或多个处理步骤。

参见图2，图2示出了本申请提供的一种上传扫描数据的流程示意图。在一些可选的实施方式中，所述网点数智化管理系统利用数据库服务器存储多个网点的网点数据，每个所述网点的网点数据包括每个所述网点对应的订单的扫描数据，每个所述订单的扫描数据用于指示其所对应的订单标识、网点标识和扫描类型；

当所述交互操作是上传操作时，所述目标服务方组件是上传组件，所述上传组件用于接收多个所述交互设备上传的多个所述订单的扫描数据；

所述方法还可以包括：

步骤S201：基于每个所述订单对应的网点标识，将每个所述订单的扫描数据存储至其所对应的网点所对应的待传送队列；

步骤S202：当检测到其中一个待传送队列中存储的扫描数据的数量不小于预设数量时，将所述其中一个待传送队列中的所有订单的扫描数据批量上传至所述数据库服务器。

利用网点数智化管理系统可以提供扫描数据的上传服务(上传至数据库服务器)，但由于网点众多(一个快递公司可能有几千个网点)，因此需要上传扫描数据的交互设备很多，如果这些交互设备同时访问数据库服务器，则可能给数据库服务器造成较大压力，甚至可能导致服务器过载、崩溃等。

因此，可以以网点为维度，将每个订单的扫描数据按照网点存储至网点对应的待传送(消息)队列中，每个待传送队列可以对应一个或多个网点，这样，交互设备并不直接将扫描数据上传至数据库服务器，而是将待上传的扫描数据基于网点分流至多个待传送队列，经过待传送队列的中转存储至数据库服务器；并且，待传送队列并非进行实时中转，而是当存储的扫描数据的数量不小于预设数量时，将这些扫描数据批量上传至数据库服务器。一方面，大大减少了访问数据库服务器的外部设备数量，另一方面，采用延时批量上传，大大减少了访问数据库服务器的次数。

每个所述订单的扫描数据还可以用于指示每个订单所对应的扫描时间。

本申请对订单标识不作限定，其例如可以采用中文、字母、数字、符号、特殊符号中的一种或多种来表示。

本申请对网点标识不作限定，其例如可以采用中文、字母、数字、符号、特殊符号中的一种或多种来表示。

本申请中的扫描类型，例如可以包括寄件扫描、收件扫描、卸车扫描、装车扫描等。

本申请对预设数量不作限定，其例如可以是100、1000、10000、100000等。

在一些可选的实施方式中，所述方法还可以包括：当检测到其中一个待传送队列中存储的扫描数据的数量小于预设数量时，不做任何操作。

参见图3，图3示出了本申请提供的一种生成扫描记录的流程示意图。在一些可选的实施方式中，当所述交互操作是标记操作时，所述目标服务方组件是标记组件，所述标记组件用于将一个或多个所述订单标记为问题件；

所述方法还可以包括：

针对每个所述问题件执行以下处理：

步骤S301：获取所述问题件的订单标识以及所述问题件的订单标识关联的网点标识；

步骤S302：基于所述问题件的订单标识，从所述数据库服务器中查询是否存在所述订单的扫描数据，当存在时，将查询得到的扫描数据存储至所述缓存区域；

步骤S303：基于所述问题件的订单标识关联的每个网点标识，从每个所述网点标识对应的网点的待发送队列中查询是否存在所述问题件的扫描数据，当存在时，将查询得到的扫描数据存储至预设的缓存区域；

步骤S304：当所述缓存区域中存在查询得到的扫描数据时，基于查询得到的扫描数据，生成所述问题件的扫描记录并存储至所述数据库服务器。

由此，一般而言，每个订单从生成到完成配送需要经过多次扫描，产生多个扫描数据(例如在每个分拨站点就有卸车扫描和装车扫描两次扫描，产生两个扫描数据)，当出现问题件时，问题件可能已经配送到终端收件人手中，但也可能处于运输过程或者配送过程中，与此同时，问题件的一部分扫描数据可能已经存储到数据库服务器中，另一部分扫描数据可能还在(订单标识关联的多个网点标识对应的)多个网点对应的待传送队列中、尚未上传至数据库服务器，因此，可以从这两类存储位置分别查询是否存在该问题件的扫描数据，用以生成对应的扫描记录，扫描记录可以用于后续的信息发布或者退款、退货等处理事宜。

当标记组件用于将多个订单标记为问题件时，可以针对多个问题件进行批量处理，提高问题件的处理效率。

本申请对标记问题件的原因不作限定，问题件例如是寄件人发起退单的订单，或者是收件人拒收快递件的订单，或者是对应的快递件发生损坏或者丢失的订单，或者是因为不可抗力的原因已经无法完成配送的订单(例如由于瘟疫的影响需要销毁，或者牵扯到刑事案件需要作为证据)。

所述问题件的订单标识关联的网点标识可能是一个或多个网点标识。这是因为每个订单从生成到完成配送，一般会经过多个网点。

本申请对预设的缓存区域不作限定，其例如可以是交互设备的缓存。

在一些可选的实施方式中，所述方法还可以包括：当所述缓存区域中不存在查询得到的扫描数据时，生成用于指示不存在扫描数据的提示信息，并利用所述交互设备显示所述提示信息。

在一些可选的实施方式中，每个所述网点的网点数据还包括每个所述网点对应的罚款数据；

当所述交互操作是针对所述问题件的仲裁操作时，所述目标服务方组件是仲裁组件，所述仲裁组件用于确定是否需要罚款以及当需要罚款时被罚款的网点和金额；

所述方法还可以包括：

生成一条罚款数据并存储至所述数据库服务器，所述罚款数据用于指示被罚款的网点和金额。

由此，有时候出现问题件的原因可能是网点操作不当造成的，因此需要对承担责任的网点进行罚款，在网点数智化管理系统中设置仲裁组件，用于为工作人员提供仲裁服务，工作人员可以利用仲裁组件选择对一个或多个网点进行罚款，并且当需要罚款时还可以录入(或者系统自动计算得到)每个网点被罚款的金额，有利于对网点进行精细化管理。

在一些可选的实施方式中，每个所述网点的网点数据还包括每个所述网点对应的历史业务量数据、订单数据、应收应付账单数据和预付款数据。

由此，历史业务量数据能够指示过去的业务量(有史以来或者一段时间段内的)，可以用于后续的数据挖掘过程，评估每个网点的业务能力等；订单数据例如可以包括订单的发件人、收件人、发件地址、收件地址、物品类型、保价类型等，可以用于后续的数据查询、数据挖掘过程；应收应付账单数据能够指示应收金额和应付金额，便于每个网点进行线上收账、付款的管理；预付款数据能够指示预付款情况(例如每个客户的预付款金额)，便于每个网点甄别优质客户、有针对性地提供定制化服务。

参见图4，图4示出了本申请提供的一种分配识别码的流程示意图。在一些可选的实施方式中，所述方法还可以包括：

将多个识别码数据存储至所述数据库服务器，并将每个所述识别码数据的分配状态初始化为未分配，每个所述识别码数据包括一个识别码及其识别码标识；

每隔预设时长，针对每个所述网点执行以下处理：

步骤S401：基于所述网点的历史业务量数据，预测得到所述网点在预设时间段内所需要的识别码数量，所述预设时间段的起始时刻在当前时刻之后；

步骤S402：将未分配的识别码数据中与所述网点所需要的识别码数量相应的识别码数据的分配网点设置为所述网点，并将完成分配的识别码数据的分配状态调整为已分配。

由此，每隔预设时长，为每个网点分配一定数量的识别码数据，其中，每个网点分配得到的识别码数量是基于该网点的历史业务量数据预测得到的。

这样做的好处是，一方面，通过网点数智化管理系统提供自动分配识别码的功能，进一步提升了系统的集成度，提高了工作人员分配识别码的效率；另一方面，在实际应用中，由于每个网点的业务量不同，所需要的识别码数量不同，因此对识别码进行平均分配是不够科学、合理的，采用上述分配方式，首先预测得到每个网点所需要的识别码数量，再从未分配的识别码数据中将相应数量的识别码数据分配给对应网点，实现了识别码的智能化分配；又一方面，利用分配状态这一字段指示识别码是否被分配，容易开发和实现。

本申请对识别码的类型不作限定，其例如可以包括条形码(条码)和/或二维码。

本申请对识别码标识不作限定，其例如可以采用中文、字母、数字、符号、特殊符号中的一种或多种来表示。

参见图5，图5示出了本申请提供的一种确定识别码数量的流程示意图。在一些可选的实施方式中，所述步骤S401可以包括：

步骤S501：从所述网点的历史业务量数据中获取与所述预设时间段相应的历史业务量数据；

步骤S502：将所获取的历史业务量数据输入业务量预测模型，得到所获取的历史业务量数据对应的预测业务量；

步骤S503：基于所获取的历史业务量数据对应的预测业务量，确定所述网点所需要的识别码数量；

其中，所述业务量预测模型的训练过程包括：

获取训练集，所述训练集包括多个训练数据，每个所述训练数据包括一个用于训练的历史业务量数据及其对应的预测业务量的标注数据；

针对每个所述训练数据，执行以下处理：

将所述训练数据中的历史业务量数据输入预设的深度学习模型，得到所输入的历史业务量数据对应的预测业务量的预测数据；

基于所输入的历史业务量数据对应的预测业务量的预测数据和标注数据，对所述深度学习模型的模型参数进行更新；

检测是否满足预设的训练结束条件；如果是，则将训练得到的深度学习模型作为所述业务量预测模型；如果否，则利用下一个所述训练数据继续训练所述深度学习模型。

由此，一方面，基于预设时间段的长度、所处区间的不同，网点所需要的识别码数量不同(例如促销活动期间网点需要的识别码数量会大大上升)，因此需要基于预设时间段，动态调整为网点分配的识别码数量。

另一方面，有针对性地基于不同的预设时间段，从(网点对应的)全部历史业务量数据中筛选得到部分历史业务量数据用于后续的预测过程，能够得到该网点的更精准的预测业务量(例如用去年同期来预测今年同期，用一个促销期间来预测另外的促销期间)。

又一方面，业务量预测模型可以由大量的训练数据训练得到，能够针对不同的输入数据预测得到相应的预测业务量，适用范围广，智能化水平高。

通过设计，建立适量的神经元计算节点和多层运算层次结构，选择合适的输入层和输出层，就可以得到预设的深度学习模型，通过该预设的深度学习模型的学习和调优，建立起从输入到输出的函数关系，虽然不能100％找到输入与输出的函数关系，但是可以尽可能地逼近现实的关联关系，由此训练得到的业务量预测模型，可以实现获取历史业务量数据对应的预测业务量的功能，且计算结果准确性高、可靠性高。

本申请对所获取的历史业务量数据对应的预测业务量以及所述网点所需要的识别码数量之间的大小关系不作限定，二者可以是相同的，也可以是不同的。也就是说，该预测业务量可以等于该识别码数量，或者，该预测业务量可以大于该识别码数量，或者，该预测业务量可以小于该识别码数量。一般而言，二者之间的差值的绝对值不宜过大。

本申请对预设时长不作限定，其例如可以是一天、一个星期、一个月或者三个月等。

本申请对预设时间段不作限定，其例如可以是从明天开始的未来一个星期或者未来一个月。

本申请对标注数据的获取方式不作限定，例如可以采用人工标注的方式，也可以采用自动标注或者半自动标注的方式。

本申请对业务量预测模型的训练过程不作限定，其例如可以采用上述监督学习的训练方式，或者可以采用半监督学习的训练方式，或者可以采用无监督学习的训练方式。

本申请对预设的训练结束条件不作限定，其例如可以是训练次数达到预设次数(预设次数例如是1次、3次、10次、100次、1000次、10000次等)，或者可以是训练集中的训练数据都完成一次或多次训练，或者可以是本次训练得到的总损失值不大于预设损失值。

在另一些可选的实施方式中，获取所获取的历史业务量数据对应的预测业务量的步骤，可以包括：将所获取的历史业务量数据输入预设的业务量计算公式，计算得到所获取的历史业务量数据对应的预测业务量。

本申请对预设的业务量计算公式不作限定，其例如是一元多项式或者多元多项式，又例如是线性多项式或者非线性多项式。利用该业务量计算公式和自变量(所获取的历史业务量数据)，计算得到因变量(该历史业务量数据对应的预测业务量)。基于计算公式的计算过程，所消耗的计算资源少，所耗费的计算时间短，计算效率较高。

参见图6，图6示出了本申请提供的一种网点数智化管理系统的结构示意图，其具体实现方式与上述方法实施方式中记载的实施方式、所达到的技术效果一致，部分内容不再赘述。

所述网点数智化管理系统采用MGJRouter组件化多层架构，并且所述网点数智化管理系统设置有MGJRouter、多个调用方以及多个服务方组件。

每个所述调用方用于：

响应于交互操作，利用自身对应的URL，从预先存储于所述MGJRouter的注册表中查询得到所述URL对应的代码块；

通过所述MGJRouter调用与所述代码块相对应的多个服务方组件的其中一个；

其中，所述交互操作是利用交互设备接收的针对每个所述调用方自身的操作。

每个所述服务方组件用于：当被调用时，执行所述交互操作对应的处理步骤。

在所述网点数智化管理系统的开发过程中，采用HyBrid App开发模式，并且采用weex框架作为开发框架。

所述网点数智化管理系统采用优秀的人机交互、操作逻辑和界面美观设计。系统中列出的交互表示状态之间的连续性，表示共享元素之间的关系，并将用户的注意力引用到他们应注意和采取行动的事物上，在开发时可以遵循Material Motion、IBM的动画原则和UX in Motion Manifesto中的指导原则。

目前的主流开发模式包括Native App、Hybrid App、React Native App、Web App等。所述网点数智化管理系统可以采用HyBrid App开发模式或者其他开发模式。HybridApp同时采用网页语言与程序语言进行开发，通过不同的应用商店进行打包与分发，应用的特性更接近原生应用而且又区别与Web应用。但是在开发过程中同时使用了网页语言，所以开发成本与难度大大降低。也就是说Hybrid App兼具了Native App与Web App两者的诸多优点。Hybrid App主要以JS+Native两者相互调用为主，从开发层面实现“一次开发，多处运行”的机制，成为真正适合跨平台的开发。现阶段主流的平台包括PhoneGap，AppCan，appMobi，Titanium等，它们基于webkit开源内核，使用HTML5标准开发，适配机型简单，支持开发人员自定义插件，并能很好的应用于物流行业。

所述网点数智化管理系统可以基于Weex实现网点数智化管理。Weex使用原生组件和原生模块，来最大化利用原生渲染的性能优势以及平台能力，所有的组件和模块都是可插拔、可扩展的；所述网点数智化管理系统在前端可以表现为网点数智化经营管理软件，便于快递公司的各网点、各分部实时查询及问题件处理，及时处理操作流程，提高工作效率。所述网点数智化管理系统能够实现信息移动化、实时化，实现网点及快递公司管理移动在线协同；对快递的业务量、订单、应收应付账单、罚款、预付款、条码分配等进行统一管理；便于快递公司各网点各分部实时查询及问题件处理，及时处理操作流程，因此使用网点数智化经营管理软件，能够提高工作人员的工作效率。

参见图7，图7示出了本申请提供的一种电子设备200的结构框图。电子设备200包括至少一个存储器210、至少一个处理器220以及连接不同平台系统的总线230。

存储器210可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)211和/或高速缓存存储器212，还可以进一步包括只读存储器(ROM)213。

其中，存储器210还存储有计算机程序，计算机程序可以被处理器220执行，使得处理器220实现上述任一项方法的步骤，其具体实现方式与上述方法实施方式中记载的实施方式、所达到的技术效果一致，部分内容不再赘述。

存储器210还可以包括具有至少一个程序模块215的实用工具214，这样的程序模块215包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例的每一个或某种组合中可能包括网络环境的实现。

相应的，处理器220可以执行上述计算机程序，以及可以执行实用工具214。

处理器220可以采用一个或多个应用专用集成电路(ASIC，Application SpecificIntegrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件。

总线230可以为表示几类总线结构的一种或多种，包括存储器总线或者存储器控制器、外围总线、图形加速端口、处理器或者使用多种总线结构的任意总线结构的局域总线。

电子设备200也可以与一个或多个外部设备240例如键盘、指向设备、蓝牙设备等通信，还可与一个或者多个能够与该电子设备200交互的设备通信，和/或与使得该电子设备200能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等)通信。这种通信可以通过输入输出接口250进行。并且，电子设备200还可以通过网络适配器260与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。网络适配器260可以通过总线230与电子设备200的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储平台等。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，所述计算机程序被执行时实现上述任一项方法的步骤，其具体实现方式与上述方法实施方式中记载的实施方式、所达到的技术效果一致，部分内容不再赘述。

参见图8，图8示出了本申请提供的一种用于实现网点数智化管理方法的程序产品300的结构示意图。程序产品300可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品300不限于此，在本申请中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。程序产品300可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等，或者上述的任意合适的组合。可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，程序设计语言包括面向对象的程序设计语言诸如Java、C++等，还包括常规的过程式程序设计语言诸如C语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本申请从使用目的上，效能上，进步及新颖性等观点进行阐述，已符合专利法所强调的功能增进及使用要件，本申请以上的说明书及说明书附图，仅为本申请的较佳实施例而已，并非以此局限本申请，因此，凡一切与本申请构造，装置，特征等近似、雷同的，即凡依本申请专利申请范围所作的等同替换或修饰等，皆应属本申请的专利申请保护的范围之内。