物流、家装、旅游数据的处理方法、装置及电子设备

技术领域

本申请涉及一种物流、家装、旅游数据的处理方法、装置及电子设备，属于计算机技术领域。

背景技术

目前的物流行业现状是合同订购、结算数字化程度低。合同签订大部分依赖线下签订，合同报价数据纸质化，缺乏相应产品标准。结算系统处于半自动系统甚至纯人工结算状态，报价需要结算人员解析，和实操系统脱节，和实际的工作脱节。另外，物流行业具有较为复杂的工作场景，同时会涉及到供应链上下游的多个企业，例如运输公司、仓储公司、物流末端配送的企业等上游客户(服务供应方)以及作为物流服务对象的商家或者个人等下游客户(服务需求方)。

基于这些原因，在现有技术的物流行业的运转过程中，各个环节很难形成统一，整个服务链路的数字化程度较低，结算工作人员数量庞大，既需要对每一份纸质合同报价进行解析，又需要去统计实操数据，效率极低，资源浪费严重，结算周期较长，也难以进行精细化管理。

发明内容

本发明实施例提供一种物流、家装、旅游数据的处理方法、装置及电子设备，以提高物流工作的处理效率。

为了实现上述目的，本发明实施例提供了一种物流数据的处理方法，包括：

在订购域中生成订购数据；

基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的物流活动数据和所述计费数据；

在物流活动执行完成后，根据所述计费数据执行结算处理。

本发明实施例还提供了一种物流数据的处理装置，包括：

订购数据生成模块，用于在订购域中生成订购数据；

数据映射处理模块，用于基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的物流活动数据和所述计费数据；

结算处理模块，用于在物流活动执行完成后，根据所述计费数据执行计费处理。

本发明实施例还提供了一种家装数据的处理方法，包括：

接收用户的家装订单，并对所述家装订单进行拆解，生成装修任务子订单和/或装修材料子订单；

根据所述装修任务子订单和/或装修材料采购子订单，在订购域中生成订购数据，所述订购数据包括装修任务数据和/或装修材料数据；

基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的家装活动数据和所述计费数据，所述家装活动数据包括装修任务执行数据和/或装修材料采购数据；

在家装活动执行完成后，根据所述计费数据执行结算处理。

本发明实施例还提供了一种旅游数据的处理方法，包括：

接收用户的旅游订单，根据旅游行程和/或旅游服务项目，对所述旅游订单进行拆解，生成多个旅游子订单；

根据所述多个旅游子订单，在订购域中生成订购数据；

基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的旅游活动数据和所述计费数据，所述旅游活动数据包括旅游行程进展数据和/或旅游服务提供数据；

在旅游活动结束后，根据所述计费数据执行结算处理。

本发明实施例还提供了一种电子设备，包括：

存储器，用于存储程序；

处理器，用于运行所述存储器中存储的所述程序，以执行上述的物流数据的处理方法。

本发明实施例的物流数据的处理方法、装置及电子设备，通过建立订购域、实操域及结算域之间的数据映射关系，将物流工作中的三个主要环境进行统一，打通了订购到结算的各个环节，从而实现了以结算为中心的物流数据处理，从而能够提高物流工作的数据化管理程度和管理效率，并且会极大提高结算效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

图1为本发明实施例的示例性的物流服务平台的结构示意图；

图2为本发明实施例的物流服务平台的应用环境示意图；

图3为本发明实施例的物流数据的处理方法的流程示意图；

图4为本发明实施例的物流数据的处理装置的结构示意图；

图5为本发明实施例的电子设备的示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

下面通过一些具体实施例来进一步说明本发明的技术方案。

本发明实施例基于对物流领域的工作进行抽象和建模，将整个物流领域划分为三个大的域：订购域、实操域及结算域，并建立对应的数据映射关系，从而实现三者的统一和联动，打通物流领域的三个主要环节。另外，在数据映射和模型构建方面，体现了以结算为中心，从而能够有效提高结算效率。在本发明实施例中域的概念包括了不同领域的工作处理系统、工作模型以及数据库模型等，例如，在订购域中，其对应着订购系统，其工作模型和数据模型侧重于订购关系的建立，而在结算域中，其对应着结算系统，其工作模型和数据模型侧重于计费关系和财务管理等。

从数据流的处理角度来看，当订购关系建立后，会在订购域中产生订购数据，例如，在系统中完成合同签订后，就会形成订购关系并生成订购数据。在本发明实施例中，订购数据的产生也是基于统一的数据模型，并且与实操域及结算域是具有映射关系，从而能够同时触发在实操域和结算域中的物流活动数据和计费数据。其中，物流活动数据中包括了物流活动的具体任务以及使用的逻辑资源等，而计费数据是最终结算的数据基础，随着物流活动的进展，会触发计费处理。进一步地，物流活动数据可能会随着物流活动而不断更新，这种更新也会同步变化到计费数据中，从而在完成部分或者全部物流活动后，就可以进行结算操作。

本发明实施例提出的物流数据的处理方法可以应用于物流服务平台上，该物流服务平台可以对物流产业上下游客户提供物流工作方面的服务，将上下游客户的需求进行对接。如图1所示，其为本发明实施例的示例性的物流服务平台的结构示意图，该物流服务平台包括客户管理系统、产品模块、数字化订购系统、物流实操系统以及结算系统。

1)客户管理系统

客户管理系统主要用于对上下游的客户对接，接收下游客户的物流服务需求和对向上游客户进行物流资源采购。由于物流产业的供应链下游和上游客户的工作形态以及入驻流程区别很大，客户管理系统可以通过商家(对应于物流服务需求方)CRM(客户关系管理)平台和供应商(对应于物流服务提供方)平台来分别对外提供服务。

2)产品模块

产品模块用于将物流资源数字化形成逻辑资源，并将该逻辑资源进行有机组合形成产品，产品可以被下游的物流服务需求方订购。上述的逻辑资源来自于物流服务平台对上游的物流服务供应方的实际的物流资源的采购。图中的产品模块包括资源中心和产品中心，其中资源中心用于管理物流服务平台向上游物流服务供应方采购的物流资源，将这些物流资源映射为逻辑资源并进行记录。物流资源是指具有提供物流服务能力事物，比如车辆、配送人员、仓库、运输线路等都可视为物流资源。产品中心用于对各种逻辑资源进行组合，形成产品并进行记录。

进一步地，从供应链的资源流向角度，可以将产品分为售卖型服务产品与招采型服务产品，分别面向供应链下游河上游的客户。物流服务平台可以将采购的多个招采型服务产品直接进行组合，从而形成售卖型服务产品以提供给下游客户，例如将采购多个公司的短途运输线路产品进行组合形成一条长途运输线路产品，再例如将采购的运输线路产品、仓储服务产品以及末端配送产品进行有机组合，形成整套的物流服务产品。另外，物流服务平台也采购规模较大的招采型服务产品，并拆散为多个逻辑资源，然后进行重新组合，形成售卖型服务产品。

3)数字化订购系统

数字化订购系统用于对订购关系进行数据化处理。订购的含义为买卖双方通过契约形成商务关系，一方提供服务，另一方消费服务。在本发明实施例中，一方面，物流服务平台可以作为物流企业的角色，可以与上游的物流服务提供方形成订购关系，对其物流资源进行采购，还可以与下游的物流服务需求方形成订购关系，利用其采购的物流资源为物流服务需求提供服务。针对上下游的订购关系可以是彼此独立，并进行分别的结算处理。另一方面，物流服务平台也可以直接形成上游的物流服务提供方和下游的物流服务需求方之间的订购关系。需要说明的是，对于同一项物流服务需求，可能会涉及多个上游的物流服务提供方，即通过多个物流服务提供方来满足一个物流服务需求方的某个物流需求，例如，从A地向B地发送一批货物，可以通过长途运输公司C、仓储公司D和市内配送服务公司E来共同完成。由此可见，本发明实施例的物流服务平台起到一个物流资源整合和调配的作用。

需要说明的是，在执行物流工作的过程中，对于上游的物流服务提供方的费用结算和下游的物流服务需求方的费用结算可能并不是同步的，例如，在承运工作完成后，物流服务平台就可以对上游的承运公司进行结算，此时，整个物流工作并未完成，一般会等到最终货物配送到目的地并确认收货后，再对下游的商家进行费用结算。

进一步地，在本发明实施例的订购系统中，可以屏蔽具体工作流程与客户属性，将物流服务提供方和物流服务需求方均抽象为客户，并与对应的产品进行绑定，形成用户，在形成用户的过程中，相当于将物流平台中的产品进行了实例化，即应用于具体的订购关系中。其中，客户可以是发生订购关系的自然人或者法人，自然人可以用身份证、护照等做作为唯一凭证，法人可以企业登记号作为唯一凭证。用户是指产品和客户的结合体，在物流服务平台中可以通过用户编码来记录。用户可以贯穿订购与、实操域以及结算域的各种处理，从而便于进行数据管理以及最终的结算处理。即，前面提到的订购数据、物流活动数据以及计费数据都会与用户进行关联。同一个客户可以与不同的产品进行组合，从而在物流服务平台中形成多个用户。

以物流服务平台分别与上下游客户形成订购关系为例，物流服务平台在与服务需求方确立了订购关系后，订购关系中包含了分配给该服务需求方的产品，而这些产品又与一个或多个服务提供方相关联，从而会存在至少两方面的用户。一方面，在建立与下游客户的订购关系时，服务需求方的编码与产品编码进行绑定，形成与下游客户对应的用户，例如下游的商家编码+下单码作为该用户的唯一标志，下单码对应了基于该商家的某个订单而配置的产品。另一方面，在物流服务平台向上游客户采购物流资源时，会将服务提供方的编码与产品编码进行绑定，形成与上游客户对应的用户。上述的用户将会应用于后续的实操域和结算域的数据处理，从而将上下游的客户进行统一处理并打通了订购、实操和结算环节。

进一步地，数字化订购系统主要包括如下几方面的功能模块：用户管理模块、订购同步模块、订购关系管理模块、报价模块。

用户管理模块主要用于根据订购关系生成用户编码，并且这些编码规则与结算系统中的用户编码规则是一样的，即这里生成的用户编码会映射到结算系统中作为计费用户。如前面介绍的，用户编码的生成逻辑基于两个维度：客户和产品。例如，对于运输工作，承运商是客户，客户编码是C00001，运输线路是产品资源，产品编码是S00001，运输用户的生成规则为承运商编码+运输线路编码，则运输用户的用户编码为C00001_S00001。相应地，在计费调度中心，抽取单据中承运商信息与线路信息，通过承运商编码+线路编码的规则可以确定前述的用户作为计费处理的计费用户。订购系统中的用户编码规则和结算系统中的用户编码规则一致，从而实现订购、结算一体化。

报价模块主要用于报价模式管理和报价模板管理这两方面功能。在订购交互过程中使用的报价模板与结算处理中的批价模块中计费模板是统一的，即报价模板与计费模板之间具有映射关系，结算系统将计费模板与计费能力会透传给订购系统，从而避免系统功能冗余，也能保证系统间数据逻辑一致性。

订购关系管理模块用于对前面生成的用户与订购关系的生命周期管理，当一项订购关系结束后，例如某项物流服务完成，释放用户资源。

订购同步模块，用于打通订购域和结算域之间的数据联系，订购域和结算域之间的数据同步的核心在于用户模型的同构和报价与结算模型的同构。当新的订购关系生成时，会触发同步事件，同步订购数据到结算域中。同步的最细粒度可以是用户维度，同步的内容包括但不限定于：客户信息，用户信息，报价信息，产品信息，账户信息。

4)电子合同系统

电子合同系统用于提供了在线签约的交互功能，数字化的订购关系通过合同系统以电子文本的形式展示，签约双方主体通过电子签章实现在线签约，一旦双方签署完成，订购关系生效，触发订购同步模块向结算系统或者向结算系统和物流实操系统同步订购数据。

5)物流实操系统

物流实操系统用于对实际的物流操作进行监控和管理，并提供物流履行的单据。物流实操系统包括但不限定于履行系统、运输系统、配送系统、仓储系统，这些子系统分别对应了物流活动的各个环节。在各个子系统中，会根据各项物流活动的流程特点，设置多个物流节点，当物流节点的状态发生变化时，会触发计费事件，结算系统对各个用户进行计费处理。这里所说的物流节点是指物流活动的主要环节上设置的监控节点，可以是时间属性的节点，也可以是地理位置属性的节点。例如，在运输系统中，会对运输线路上设置多个物流节点，当运输车辆到达某个物流节点时，会将运输距离同步到结算系统中，触发计费事件，对该用户(承运商+运输线路)对应的运输费用进行计费。再例如，在仓储系统中，当可以月为单位计算时间，那么将每月的固定时间设置为物流节点，并在时间点触发计费事件。具体触发计费事件的方式可以是物流实操系统向结算系统发送物流单据，从而触发结算系统基于该物流单据进行计费。

6)结算系统

结算系统用来处理上下游客户的计费结算工作，其主要包括收单模块、计费调度中心、批价模块、财务模块以及资金平台。

收单模块是结算系统的入口，其接收并存储来物流实操系统的物流单据，并提供给计费调度中心，触发计费事件。

计费调度中心用于进行计费调度管理，并最终形成结算数据。计费调度中心可以进一步划分为四个模块，包括映射模型模块、用户分析模块、订购分析模块以及调度安排模块，这四个模块也代表计费活动的四个串行步骤。

模型映射模块：将实操域中的数据元素与结算域中数据元素进行转换。模型映射模块主要对异构的实操物流要素转换成结算系统可认知的标准数据。例如将来自于物流实操系统中的运输线路的各种记录信息转换为结算域所需要的行驶里程数据，以用于计费处理。

用户分析模块：通过物流单据中的客户信息和产品资源信息，根据用户生成规则确定结算用户，这里所确定的用户是与订购系统中的用户是一致的。

订购分析模块：根据用户分析模块确定的用户以及物流单据中包含的物流要素、工作时间等信息去查询订购数据，查找到相应的订购数据后，提供给批价模块以进行定价计费处理。其中，查询的订购数据包括但不限定于产品报价、计费单元、结算账期、定价要素等。

调度编排：根据实际工作的计费逻辑进行计费任务调度，例如，运输工作的计费逻辑是按照行驶里程阶段性计费，而仓储工作的计费逻辑是按照所占空间和时间累积进行计费。

批价模块：用于根据物流要素和订购阶段的报价，基于计费模板进行计费，提供的计费能力包括但不限于：事件型计费、周期型(租金类)计费、折扣型计费等。

账务模块：对计费结果进行累账，提供包括账务查询、系统对账、账单出具、账户管理等账务功能。

资金模块：承担账务资金的管理，提供包括银企资金对接、银行对账、支付渠道管理、票据管理等功能。

以上介绍本发明实施例提供物流服务平台的示例，通过该平台对上游的物流服务提供方的资源进行了整合后，为下游的物流服务需求方提供物流服务。该物流服务平台一方面可以作为大型物流服务企业的角色来对上下游客户开展商务工作，另一方面，如图2所示，其为本发明实施例的物流服务平台的应用环境示意图，该物流服务平台还可以作为物流服务的管理系统，为其他第四方的物流企业提供物流资源管理和物流服务订购以及结算等服务。该第四方的物流企业可以将其上下游的客户和物流资源放入到该物流服务平台上，以实现对整个物流工作的运营管理。

实施例一

如图3所示，其为本发明实施例的物流数据的处理方法的流程示意图，该方法可以运行于对物流工作进行管理的物流服务平台上，该方法包括：

S101：在订购域中生成订购数据。在订购域中可以预先设置报价模板，基于报价模板与客户进行交互，响应于客户对报价模板的处理，生成订购数据，其中，报价模板中可以包括服务项目和对应的服务属性，用户可以通过对物流服务项目的选择以及对服务属性的填写等交互处理来生成订购数据。其中，服务项目可以包括执行的物流服务具体内容以及附加要求等，例如，串点服务，装卸服务、运输服务、仓储服务、当日达、次日达、冷藏配送等等，服务属性可以包括：例如对于运输服务而言，选用的车辆的车长、型号、报价方式(例如运输工作中按照包裹数量报价和/或按照里程数报价)等。

S102：基于订购域与实操域和结算域之间的映射关系，生成与订购数据对应的物流活动数据和计费数据。在结算域中，可以存在与订购域中的报价模板对应的计费模板，两者之间具有映射关系。基于这种映射关系，可以在基于报价模板生成了订购数据后或者同时，生成计费数据，并将订购数据中的服务内容同步到实操域，作为物流活动数据。在实操域中，基于服务内容对各种物流资源进行使用，以执行物流活动。其中，服务内容也包括执行的物流服务项目(例如，串点服务，装卸服务、运输服务、仓储服务等)和服务要求(例如当日达、次日达、生鲜冷藏等)。

具体地，计费模板中可以包括计费科目和对应的计费要素，前述的报价模板中的服务项目和对应的服务属性分别与计费科目和对应的计费要素具有映射关系。例如，在报价模板中选定了运输服务的服务项目，相应地，在计费模板中也会映射为选定了运输服务的计费项目。对于运输服务而言，填写或者选择了采用的车辆的车长、型号、报价方式(例如运输工作中按照包裹数量报价和/或按照里程数报价)等，这些服务属性也会直接影映射到计费科目的计费要素中，在结算时，根据从选用的车辆的车长、型号以及计费方式(对应于报价方式)进行结算。

S103：当物流活动完成后，根据计费数据执行结算处理。进一步地，物流活动数据可能会随着物流活动而不断更新，这种更新也会同步触发计费数据的更新中，从而便于进行后续的计费和结算处理。具体地，在实操域中，响应于物流活动的执行进度，更新物流活动数据；然后根据实操域和结算域之间的映射关系，对计费数据进行更新。

如前面所介绍地，在实操域中根据不同的服务类型，预设有一些物流节点，这些节点对应于物流作业中的各个环节(例如物品出库、物品发出、物品到达等)，当物流作业进展到预定物流节点后，会触发相应的计费事件，例如物品发出后开始触发运输计费事件，根据计费项目和计费要素开始进行计费，在物品到达后，形成该段运输服务的计费费用，从而实现实操域与结算域的联动。通过这种联动来不断地更新计费数据，从而使得在最终需要结算时，能够基于计费数据来快速结算。

进一步地，在本发明实施例中，可以引入了用户的概念，以用户为管理单位对物流数据以及物流活动进行监控和处理。如前面所介绍的，用户是客户与虚拟的物流资源的结合，这里所说的虚拟的物流资源就是前面提到的数字化的逻辑资源。为了实现物流系统的数字化，将实际物流资源进行编码形成逻辑资源，然后将这些逻辑资源进行有机组合后，形成各种产品，产品可以视为是组合的逻辑资源。在实际的物流工作处理中，订购关系确立之后，会将产品与客户绑定并生成用户，并将订购数据、物流活动数据以及计费数据与用户进行关联，从而通过用户可以贯穿订购与、实操域以及结算域的各种处理，以便于进行订购数据的管理、物流进度监控以及后续计费和结算处理。用户可以通过客户编码和产品资源编码的组合进行标识，例如，对于承运商(客户)和运输线路(产品)组合的用户，可以使用承运商编码+运输线路编码来标识。

在本发明实施例中，客户包括上游客户和下游客户，上游客户包括物流产业链上游的物流服务提供方，这些客户具备提供物流资源的能力，例如提供仓储或者运输服务的企业。下游客户包括物流产业链下游的物流服务需求，可以是商家或者个人，比如需要进行批量配送商品的商家，或者需要邮寄快递的个人等。

在实操域中，可以对用户的物流进度进行监控和管理，从而触发结算域的计费处理。具体地，在实操域中预设有一些物流节点，响应于在物流活动中，产品在各个物流节点的状态变化，触发针对用户进行计费处理的计费事件，更新计费数据。具体地，上述的物流节点对应于物流作业中的各个环节，例如，某个用户为提供仓储服务的企业(客户)和仓库资源(产品)的组合，对于仓储工作，物流节点可设置为货物的入库和出库环节，以及在固定时间周期设置进行仓储时间统计的物流节点，比如，货物在入库和出库会触发物流节点的状态变化，另外在每月的1日，也会触发物流节点的状态变化，并向结算系统发出状态变化的通知，触发结算系统，对该用户的相关仓储费用进行计费，从而实现实操域与结算域的联动。在例如，对于运输工作，可以在运输路线上上设置多个物流节点，当运输车辆到达某个物流节点时，会将运输距离同步到结算系统中，触发计费事件。

本发明实施例提出的物流数据的处理方法，将上下游的资源进行的整合和打通，实现先了统一的数据化的运营支撑。物流服务平台接受下游客户的订购工作，对上游客户进行采购工作，然后通过物流服务平台进行资源配置、物流管理以及统一结算，从而实现高效的数字化物流工作。

实施例二

如图4所示，其为本发明实施例的物流数据的处理装置的结构示意图，该装置可以设置于对物流工作进行管理的物流服务平台上，该装置包括：

订购数据生成模块11，用于在订购域中生成订购数据。在订购域中可以预先设置报价模板，基于报价模板与客户进行交互，响应于客户对报价模板的处理，生成订购数据，其中，报价模板中可以包括服务项目和对应的服务属性，用户可以通过对物流服务项目的选择以及对服务属性的填写等交互处理来生成订购数据。

数据映射处理模块12，用于基于订购域与实操域和结算域之间的映射关系，生成与订购数据对应的物流活动数据和计费数据。在结算域中，可以存在与订购域中的报价模板对应的计费模板，两者之间具有映射关系。基于这种映射关系，可以在基于报价模板生成了订购数据后或者同时，生成计费数据，并将订购数据中的服务内容同步到实操域，作为物流活动数据。在实操域中，基于服务内容对各种物流资源进行使用，以执行物流活动。

结算处理模块13，用于在物流活动执行完成后，根据计费数据执行计费处理。

进一步地，上述的物流活动数据和计费数据可以随着物流活动的进展而更新，相应地，该装置还可以包括：

物流活动数据更新模块14，用于响应于物流活动的执行进度，更新物流活动数据；

计费数据更新模块15，用于根据实操域和结算域之间的映射关系，对计费数据进行更新。

进一步地，还可以以用户为管理单位对物流数据以及物流活动进行监控和处理，用户的概念在前面已经进行了详细介绍，相应地，该装置还可以包括：

用户生成模块16，用于响应于订购关系的建立，将产品与客户进行绑定，生成用户，产品包括多个逻辑资源的组合，逻辑资源与具有提供物流服务能力的物流资源具有对应关系；

用户关联模块17，用于将订购数据、物流活动数据以及计费数据与用户进行关联。

对于上述处理过程具体说明、技术原理详细说明以及技术效果详细分析在前面实施例中进行了详细描述，在此不再赘述。

本发明实施例提出的物流数据的处理装置，将上下游的资源进行的整合和打通，实现先了统一的数据化的运营支撑。物流服务平台接受下游客户的订购工作，对上游客户进行采购工作，然后通过物流服务平台进行资源配置、物流管理以及统一结算，从而实现高效的数字化物流工作。

实施例三

以上着重介绍了本发明实施例的技术在物流领域的应用，实际上，该技术方案可以拓展到家装和旅游等具有类似工作模式的工作领域。以家装行业为例，越来越多的家庭会选择在线定制家装，这样的需求如果仅采用单独一家装修公司很难满足众多用户的个性化需求，而基于本发明实施例的技术思想，以针对装修领域的综合性工作服务平台作为媒介，来调配和管理各种装修资源，包括装修材料的采购资源、加工资源以及装修服务等资源，并对应在订购域、实操域以及结算域中将资源数字化并建立关联关系，在此基础上，接收大量用户的个性化家装订单，并根据平台中的数字化资源进行灵活拆解，然后通过平台有效地调度资源并对各种资源提供方实现从订购到结算的一系列服务，通过打通了家装领域的上下游产业链，提高了工作执行效率。

具体地，本发明实施例提供的家装数据的处理方法，该方法可以在前述的针对装修领域的综合性工作服务平台上执行，其包括：

S201：接收用户的家装订单，并对所述家装订单进行拆解，生成装修任务子订单和/或装修材料子订单。

S202：根据所述装修任务子订单和/或装修材料采购子订单，在订购域中生成订购数据，所述订购数据包括装修任务数据和/或装修材料数据。这里的所说的装修任务数据和装修材料数据可以根据预先配置在所述服务平台上的上下游的数字化资源来生成订购数据，和前面提到物流领域的订购数据类似，这些订购数据可以采用预设的模板的形式，并与结算域中的结算数据相关联。

S203：基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的家装活动数据和所述计费数据，所述家装活动数据包括装修任务执行数据和/或装修材料采购数据。在实操域中，主要的实操活动会涉及装修任务的开展以及装修材料的采购，这些活动都会直接产生费用，基于实操域与结算域之间的关联关系，触发结算域进行计费处理。

S204：在家装活动执行完成后，根据所述计费数据执行结算处理。最后，在整个家装活动执行完成后，对用户和装修资源的提供方进行结算。这里所说的装修资源的提供方可以是提供装修服务的企业、生产或者销售装修材料的厂家或者店铺、提供材料加工服务的企业等，并通过本实施例中的平台统一进行结算。

下面再介绍一下应用于旅游领域的实施例。旅游领域同样会涉及到上下游的多方资源，例如，一个旅游项目可能会涉及到交通、餐饮、住宿、娱乐等多个方面，同时，旅游项目也可能会涉及较长的行程，可能会涉及到多个目的地，行程多段旅游。针对这样的工作特点，同样可以为旅游服务领域构建综合性工作服务平台，以此为媒介来调配和管理各种旅游资源，包括旅行公司、交通工具、宾馆、餐厅、旅游景点、娱乐设施等等，并对应在订购域、实操域以及结算域中将资源数字化并建立关联关系，在此基础上，接收大量用户的旅游订单，并根据平台中的数字化资源进行灵活拆解，然后通过平台有效地调度资源并对各种资源提供方实现从订购到结算的一系列服务，通过打通了旅游领域的上下游产业链，提高了工作执行效率。

具体地，本发明实施例提供的旅游数据的处理方法，该方法可以在前述的针对旅游域的综合性工作服务平台上执行，其包括：

S301：接收用户的旅游订单，根据旅游行程和/或旅游服务项目，对所述旅游订单进行拆解，生成多个旅游子订单。旅游订单至少可以从两个维度来拆分，一方面可以按照旅游行程来进行阶段划分，比如，旅行行程会从先到A地区然后到B地区，则可以划分为在A地区的旅游子订单和在B地区旅游的子订单，从而可以分别由A地区和B地区的旅行公司来承接服务，另一方面，还可以从旅游服务内容来进行拆分，例如交通、餐饮以及住宿等等。

S302：根据所述多个旅游子订单，在订购域中生成订购数据。在形成子订单后，结合预先在订购域中配置的模板，生成订购数据。

S303：基于所述订购域与实操域和结算域之间的映射关系，生成与所述订购数据对应的旅游活动数据和所述计费数据，所述旅游活动数据包括旅游行程进展数据和/或旅游服务提供数据。基于对旅行活动数据的采集，同时触发结算域中的计费活动，为后续结算做好准备。

S304：在旅游活动结束后，根据所述计费数据执行结算处理。该结算处理同样会涉及到用户，以及旅游产品的上下游的资源提供方。

需要说明的是，上述的订购域、实操域以及结算域中的数据处理和数据形态，其核心技术原理与前面与物流领域的实施例是一样的，只是在本实施例中，订购域、实操域以及结算域中的数据内容具有家装和旅游行业的特点。

实施例四

前面实施例描述了物流数据的处理流程及处理装置的结构，上述的方法和装置的功能可借助一种电子设备实现完成，如图5所示，其为本发明实施例的电子设备的结构示意图，具体包括：存储器110和处理器120。

存储器110，用于存储程序。

除上述程序之外，存储器110还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器110可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器120，耦合至存储器110，用于执行存储器110中的程序，以执行前述实施例中所描述的物流数据的处理方法的操作步骤。

此外，处理器120也可以包括前述实施例所描述的各种模块以执行物流数据的处理，并且存储器110可以例如用于存储这些模块执行操作所需要的数据和/或所输出的数据。

此外，作为另一种实施方式，上述的电子设备还可以通过存储器110存储程序，并通过处理器120执行存储器110中的程序，以执行前述实施例中所描述的家装数据的处理方法或旅游数据的处理方法。

对于上述处理过程具体说明、技术原理详细说明以及技术效果详细分析在前面实施例中进行了详细描述，在此不再赘述。

进一步，如图所示，电子设备还可以包括：通信组件130、电源组件140、音频组件150、显示器160等其它组件。图中仅示意性给出部分组件，并不意味着电子设备只包括图中所示组件。

通信组件130被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件130经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件130还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件140，为电子设备的各种组件提供电力。电源组件140可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件150被配置为输出和/或输入音频信号。例如，音频组件150包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器110或经由通信组件130发送。在一些实施例中，音频组件150还包括一个扬声器，用于输出音频信号。

显示器160包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。