一种统一活动管理方法和系统与流程

1.本发明涉及数据处理领域，尤其涉及一种统一活动管理方法和系统。


背景技术：

2.快消品企业面向售点渠道端进行商品推广活动时，往往会对商品在售点的陈列表现有所要求，通常是指活动或者活动下属生动化中对售点内商品摆放的要求。所谓生动化是每个活动的子活动。对活动情况的检查都需要由业务代表或者店主或者检查员人工检查并作出判断。目前，在管理这些活动时，业内所用的管理方法和系统都是针对单一类型活动的，即只针对一种类型的活动进行设置和分发，再由人工检查活动场景，判断活动执行结果并将判断结果同步上传到一种执行工具上，进而通知管理系统。这种单一活动管理方式无法做到对活动执行情况进行自动判定，更无法对各种不同类型的活动进行统一的管理，效率低下，需要耗费大量人力物力参与管理中。
3.因此，本领域的技术人员致力于开发一种统一活动管理方法和系统，以实现对各种不同类型活动的统一的自动化的管理，减少对人力的依赖，提高管理效率。


技术实现要素：

4.有鉴于现有技术的上述缺陷，本发明所要解决的技术问题包括：
5.(1)如何通过不依赖于人工判断的高效自动化方式对活动的执行情况进行自动判定，得到判定结果；
6.(2)如何针对不同活动的不同对象提供自动报表功能；
7.(3)如何对不同类型的活动进行统一的管理，如何搭建统一的问卷管理平台，搭建统一的场景列表；
8.(4)如何对不同执行工具的不同拍照方式进行兼容。
9.为实现上述目的，本发明提供了一种统一活动管理方法，包括以下步骤：
10.步骤1、创建基础问卷；
11.步骤2、创建活动；包括创建所述活动下属的生动化，设置所述生动化同至少一个拍照场景的关联关系，设置所述生动化同至少一个所述基础问卷的关联关系，设置活动规则，设置所述活动规则的输出项和所述生动化之间的关联关系；
12.步骤3、定义活动检查计划；包括设置与所述活动对应的售点、执行工具以及时间范围；
13.步骤4、分发活动；包括通过api接口、批量文件或者共享数据中的任意一种方式告知所述执行工具所述活动的详情；所述详情包括：所述售点需要参加的至少一个活动，所述至少一个活动中的每一个活动的所述生动化、所述拍照场景、所述基础问卷，以及与所述生动化所对应的陈列要求和成功图像；
14.步骤5、活动检查；包括利用所述执行工具对所述拍照场景进行拍摄、填写所述基础问卷，以及将拍摄的场景照片和填写的所述基础问卷的答案以接口方式通知统一活动管
理系统；
15.步骤6、图像识别调度；包括由统一活动管理系统根据收到的所述场景照片、所述基础问卷的所述答案以及检查走访自带产生的数据，通过判断逻辑来控制如何进行图像识别，如何调用规则引擎，以基于所述规则引擎最终获得活动的检查结果；
16.步骤7、检查结果回盘；包括从所述规则引擎获得所述检查结果并录入所述统一活动管理系统的数据库，以及将所述检查结果推送给执行工具或者提供查询api接口供所述执行工具查询所述检查结果。
17.进一步地，所述基础问卷具有问卷id，所述问卷id被配置为管理所述基础问卷的主键。
18.进一步地，所述执行工具被配置为执行所述活动检查的前端工具，包括app和小程序。
19.进一步地，所述时间范围和所述执行工具的与运算值被配置为所述活动计划的唯一键。
20.进一步地，还包括查询/下载一个所述活动的所述检查结果。
21.本发明还提供一种统一活动管理系统，包括基础模块和核心业务模块；
22.其中，所述基础模块包括售点库、场景库、权限模块和活动类型表；
23.所述核心业务模块包括问卷管理平台模块、活动管理模块、活动分发模块、活动检查结果接受模块、图像识别调度模块、检查结果回盘接收模块和检查结果查看模块；
24.所述问卷平台模块包括问卷列表，所述问卷列表的字段包括创建时间、问卷id、问卷名称、问卷题型、问卷纬度、场景类型、所属业务单位；
25.所述活动管理模块包括创建检查项目页面、配置生动化页面、设置完成页面、生动化映射页面和设置整改要求页面；
26.所述活动分发模块包括检查计划模块和活动分发接口；所述检查计划模块被配置为用于设置活动检查计划，包括配置执行工具及时间页面和配置售点页面；活动分发接口包括请求参数和返回参数；
27.所述检查结果接受模块包括上传活动场景照片/基础问卷答案的接口，以及活动检查结束接口；
28.所述图像识别调度模块被配置为根据收到的所述场景照片、所述基础问卷答案以及检查走访自带产生的数据，通过判断逻辑来控制如何进行图像识别，如何调用规则引擎，以基于所述规则引擎获得活动的检查结果。
29.进一步地，所述售点库包括售点明细表、组织架构表、市场区隔表；
30.所述售点明细表包括序号字段、零眸需求字段、太古对应字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段；
31.所述组织架构表包括配置表字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段；
32.所述市场区隔表包括配置表字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段、取数逻辑字段、备注字段。
33.进一步地，所述场景库包括场景数据表；所述场景数据表包括场景类型字段、场景类型名称字段、场景类型二级名称字段、场景代码字段。
34.进一步地，所述检查结果回盘接收模块被配置为将所述检查结果并录入统一活动管理系统的数据库，以及将所述检查结果推送给执行工具或者提供查询api接口供所述执行工具查询所述检查结果。
35.进一步地，所述检查结果查看模块被配置为用于查询和下载一个活动的所述检查结果。
36.与现有技术相比，本发明的有益技术效果在于：
37.(1)通过搭建统一的场景列表，便于将不同活动的检查项目合并，实现场景聚合，提高检查效率。
38.(2)通过提供接口api等方式来统一对接外部执行工具，以便于统一管理。
39.(3)能够通过图像识别来对活动场景照片进行自动识别，通过规则引擎调度，自动推送规则引擎，并得到规则引擎的计算结果。
40.(4)能够将引擎的结果记录，并对不同活动提供不同列对象的结果报表下载功能。
41.以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。
附图说明
42.图1是本发明的一个较佳实施例的流程图；
43.图2是本发明的一个较佳实施例的售点明细表；
44.图3是本发明的一个较佳实施例的组织架构表；
45.图4是本发明的一个较佳实施例的市场区隔表；
46.图5是本发明的一个较佳实施例的场景库中的数据构成；
47.图6是本发明的一个较佳实施例的系统菜单的一个示例；
48.图7是本发明的一个较佳实施例的页面；
49.图8是本发明的一个较佳实施例的页面；
50.图9是本发明的一个较佳实施例的各页面的权限设置；
51.图10是本发明的一个较佳实施例的问卷平台模块所展示的页面
52.图11是本发明的一个较佳实施例的创建检查项目页面；
53.图12是本发明的一个较佳实施例的配置生动化页面；
54.图13是本发明的一个较佳实施例的设置完成页面；
55.图14是本发明的一个较佳实施例的生动化映射页面；
56.图15是本发明的一个较佳实施例的设置整改要求页面；
57.图16是本发明的一个较佳实施例的配置执行工具及时间页面；
58.图17是本发明的一个较佳实施例的配置售点页面；
59.图18是本发明的一个较佳实施例的活动分发接口定义示意图；
60.图19是本发明的一个较佳实施例的上传活动场景拍照/基础问卷答案的接口定义示意图；
61.图20是本发明的一个较佳实施例的活动检查结束接口定义示意图；
62.图21是本发明的一个较佳实施例的检查结果列表页面。
具体实施方式
63.以下参考说明书附图介绍本发明的多个优选实施例，使其技术内容更加清楚和便于理解。本发明可以通过许多不同形式的实施例来得以体现，本发明的保护范围并非仅限于文中提到的实施例。
64.现有技术在管理供应商的推广活动时，都是只针对单一的活动进行设置和分发，再由人工判断活动执行结果并将判断结果同步上传到一种执行工具上，进而通知管理系统。这样一来，如果有三项推广活动，那么一方面，需要分别对它们进行单独的管理，效率低。另一方面，每一项活动的执行情况都是依靠人工来判断的，缺乏自动化的手段来进行活动执行结果的自动判定。针对这些缺点，需要从以下几方面来改善。
65.第一，如果要将不同活动整合在一起进行检查，就需要有相应的聚合方式，例如搭建统一的问卷管理平台，搭建统一的场景列表，以便将不同活动的检查项目合并，以提高检查效率。
66.第二，人工执行检查时会用到多种外部执行工具，如供应商各自的app、小程序等，不同商家的活动会涉及到多种执行工具，因此需要提供一定方式来统一对接这些外部执行工具，以便于统一管理。
67.第三，需要采取一定方法对接一些自动化的工具尤其是发明人自己研发的基于规则引擎的图像识别工具来实现对活动场景图片的自动识别和判断，而不依赖于人工。
68.基于以上想法，本发明提出了一种统一活动管理方法和系统。如图1所示为该方法的流程图，该方法包括以下步骤：
69.1、创建基础问卷
70.由于在执行工具检查多个活动时，会遇到多个活动的问卷相同的情况，为了提高处理效率，就无需再对每个活动都处理一次问卷检查，而是进行问卷聚合，也就是合并问卷检查。那么相应的就需要一套统一的问卷，以问卷id作为主键进行管理。这样当一个售点有具备相同问卷id的多个活动时，即可进行问卷聚合，以提高处理效率。为了实现上述技术效果，所以，在该方法中，基础问卷具有问卷id，并且问卷id被配置为管理基础问卷的主键。
71.2、创建活动
72.活动是指快消品企业面向售点渠道端的商品推广活动，往往会对商品在售点的陈列表现有所要求。活动类型包括：短期协议类活动，长期协议类活动和非协议类活动等。生动化是指每个活动的子活动，按照甲方客户的概念，统一定义为生动化。每个活动有多个子活动(即生动化)，而检查的要求，包括要求拍照的场景和需要填写的基础问卷，这些都是基于生动化来设置的。通常，每个生动化可以有多个场景，即该子活动需要拍摄多个场景。每个生动化还可以有多个基础问卷。所以在这一步骤中，需要设置生动化同拍照场景之间的关联关系，设置生动化同基础问卷之间的关联关系。此外，为了最终判定子活动即生动化是否合格，除了需要设置活动规则以外，还需要绑定规则引擎输出项和生动化之间的关系，因为有时候有些规则输出项只是作为统计用，不作为判定生动化是否合格的必要条件，所以需要对必要的规则引擎输出项进行绑定。
73.综上，为了达到上述技术效果，在“创建活动”这一步骤中，包括创建活动下属的生动化，设置生动化同至少一个拍照场景的关联关系，设置生动化同至少一个基础问卷的关联关系，设置活动规则，设置活动规则的输出项和生动化之间的关联关系。
74.3、定义活动检查计划
75.单纯创建好的活动，只是一套活动定义，此时活动还无法进入对活动执行检查阶段，因为不知道哪些售点要在哪些时间范围做这个活动，而且也不知道由哪个执行工具来检查。所以首先需要定义活动检查计划。
76.首先，定义活动检查计划要设置售点。
77.其次，因为在同一时间范围可以由多个执行工具进行检查，或者同一执行工具可以分时间段进行检查。从数据库角度可以理解为，不同执行工具在同一时间范围的活动计划是存储在数据库中的多条活动检查计划记录，相同执行工具在不同时间范围的活动计划也是存储在数据库中的多条活动检查计划记录，所以需要同时指定执行工具和时间范围信息才能唯一确定一条对应的活动检查计划记录。也就是说，时间范围和执行工具的与运算值是活动检查计划的唯一键，通过设置唯一键来避免数据重复,也就是说保证系统中执行工具和时间范围的与运算的值不重复,从而保证定义活动检查计划中不会出现完全相同的活动，全部是不同的活动，确保系统对不同活动进行统一管理，执行活动检查计划。
78.综上，定义活动计划包括设置与活动对应的售点、执行工具及时间范围；时间范围和执行工具的与运算值是活动计划的唯一键。
79.4、分发活动
80.在定义好活动检查计划之后，接下来需要将定义好的活动检查计划分发给执行工具。分发方式可以是非聚合方式发送，也可以是聚合方式推送。
81.非聚合方式分发是指可以通过api接口，或者提前编写好的批量文件，或者共享数据将活动检查计划发送给执行工具。因为执行工具有时候需要以离线模式工作，所以希望在人员每天登录系统时完成检查数据的初始化录入。当使用api接口方式将活动计划发送给执行工具时，api接口的内容可以是售点的详细活动、生动化、场景、基础问卷、陈列要求、成功图像等详情信息。执行工具在收到上述这些发送的活动检查计划的详情信息后，由执行工具根据这些详情信息，自行控制选择参加哪些活动检查计划，显示哪些活动检查计划的场景、基础问卷以待检查。
82.聚合方式推送是指将不同活动检查计划中的各个场景和基础问卷聚合在一起，即将不同活动的场景和问卷进行合并，直接推送给执行工具。这种情况下，执行工具不能自行控制参加哪些活动检查计划，而是被动接受要显示哪些场景、哪些基础问卷以待检查。例如，某售点需要执行活动检查，同时为其创建了2个活动检查计划，a活动检查计划对应的是活动a，需要检查ko冰柜、客户自有冰柜、货架3个场景，需要检查001、003、005共3个问卷。b活动检查计划对应的是活动b，需要检查ko 冰柜、ko地堆、货架3个场景，需要检查001、002、003共3个问卷。那么当通过聚合方式推送给执行工具时，会直接告诉执行工具需要检查ko冰柜、ko地堆、客户自有冰柜、货架4个场景，外加001、002、003、005共4个问卷。
83.综上，分发活动包括通过api接口、批量文件或者共享数据中的任意一种方式告知执行工具关于活动的详情。详情包括：所述售点需要参加的至少一个活动，所述至少一个活动中的每一个活动的所述生动化、所述拍照场景、所述问卷，以及与所述生动化所对应的陈列要求和成功图像。
84.分发活动还包括将不同活动检查计划中的各个场景和基础问卷聚合在一起，即将不同活动的场景和问卷进行合并，直接推送给执行工具，以待执行工具检查。
85.5、活动检查
86.活动检查包括走访人员利用执行工具对拍照场景进行拍摄、填写基础问卷，以及在活动检查结束时将拍摄的场景照片和填写的基础问卷答案以接口方式通知统一活动管理系统。如果在上一步分发活动中是以非聚合方式推送给执行工具的，还需要额外告知所拍摄的场景是属于哪个活动的哪个生动化。如果在上一步分发活动中是以聚合方式推送给执行工具的，走访结束以后也需要告知活动管理系统，告知时可以额外以补充字段告知系统本次活动进行聚合检查时检查了哪些活动。
87.6、图像识别调度
88.统一活动管理系统根据收到的执行工具上传的场景拍摄照片、填写的基础问卷答案等信息以及本次走访自带产生的数据(例如走访的售点等)，通过逻辑来控制如何进行图像识别，如何调用规则引擎，以最终获得活动检查的结果。
89.对于执行工具上传的场景拍摄照片，默认除了基础问卷的补充图片(有特殊字段控制)之外，都需要进行图像识别。由于门店内不止一项活动，所以对于执行工具采集的场景照片和问卷答案，有两种做法：一是对所有活动都采集；二是因门店有些活动还没正式执行参加，所以只采集部分活动。相应地，判断当前结束的走访所属的活动有哪些，一般也分2种模式：一种为不告知。不告知时，则默认为当前售点在当时关联到的所有活动计划；另一种为执行工具已告知场景照片和问卷答案是属于哪些活动的。如果上传的场景照片属于多个不同活动，则分多次针对每一个活动挨个调用规则引擎计算检查结果，那么一次走访会产生多条规则引擎的结果，对应多个不同的活动。
90.7、检查结果回盘
91.将上一步得到的规则引擎计算结果录入到统一活动管理系统的数据库中。该数据库中有一张名为engine_result的表，用于存放规则引擎计算完的结果。
92.对于需要推送检查结果的执行工具，将检查结果推送至执行工具。对于无推送机制的执行工具，则提供查询api，由执行工具自行调用查询api后获得规则引擎计算出的检查结果。由于在“创建活动”步骤中，设置了活动规则的输出项和生动化之间的关联关系，因此，检查结果一般以这种关联关系方式向执行工具呈现。
93.8、检查结果查看
94.得到规则引擎计算出的检查结果以后，需要提供一个途径供人查阅和下载。由于每个活动需要检查的输出项是不一样的，所以每个活动的检查结果输出列也是不同的，因此每次只能选择一个活动的检查结果进行查看或者下载。
95.为了将上述统一活动管理方法付诸于实践，本发明提供了一种统一活动管理系统，包括基础模块和核心业务模块。其中，基础模块包括售点库、场景库、权限模块和活动类型表。核心业务模块包括问卷管理平台模块、活动管理模块、活动分发模块、活动检查结果接受模块、图像识别调度模块、检查结果回盘接收模块和检查结果查看模块。下面分别予以介绍。
96.一、基础模块
97.基础模块包括售点库、场景库、权限模块和活动类型表。
98.1、售点库
99.由于活动的分发需要最终面对售点，因此首先需要搭建售点库。售点库包括售点
明细表、组织架构表，以及其他关联数据表(如城市等级表、市场区隔表等)。售点库对接甲方客户的售点对接模块，以实现售点主数据自动更新。售点明细表的更新方式为全表初始化，以及在每日凌晨增加更新日次的变更数据，判断增量更新的条件为表中某条数据的updatetime字段为前一日。增量更新时，根据售点明细表的主键id来判断，如果在原表中不存在增量数据中的id，做将增量数据作为新数据插入原表中，如果在原表中存在有增量数据中的id，则利用新的增量数据对原表中的旧数据进行覆盖。其余的组织架构表、城市等级表和市场区隔表等的更新方式为全量覆盖。
100.如图2所示为售点明细表。该表的字段包括序号字段、零眸需求字段、太古对应字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段；
101.如图3所示为组织架构表。该表的字段包括配置表字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段。
102.如图4所示为市场区隔表。该表的字段包括配置表字段、接口字段名称字段、数据类型字段、字段长度字段、是否必填字段、取数逻辑字段、备注字段。
103.2、场景库所述
104.由于需要对场景进行聚合，并且规则引擎也支持针对不同场景做不同的判断，所以需要有一套统一的场景定义，即场景库。场景包括大类和小类，其中大类小类是业务上的定义，大类包括冰柜、货架、地堆等，小类包括ko冰柜、百事冰柜等。由于对场景的定义为统一的、初始的，后续很少有改动，所以场景库可以直接以数据库的形式存在于系统中。场景库包括场景数据表。该表的字段包括场景类型字段、场景类型名称字段、场景类型二级名称字段、场景代码字段。如图5所示为场景库中的数据构成。
105.3、权限模块
106.考虑到是本发明所提出的统一活动管理系统是一个业务系统，因此所有的页面都需要有权限管理。具体来说，包括菜单权限、按钮权限、数据区隔权限等。本系统通过对接甲方客户的权限系统获得权限码和角色属性，在本系统的页面中需要根据权限码和角色属性实现权限控制。其中菜单权限和按钮权限根据权限码控制，具体包括菜单列表权限，功能查看权限，功能编辑权限。数据区隔根据角色的组织架构属性控制，中央服务部门拥有对所有数据的查看权限，但各地厂房只能看到自己的数据。
107.在用户登录的时候，系统获取登录者所属的菜单权限码、按钮权限码以及所属的组织架构，首先判断用户是所属客户的央服，还是下属的某个子公司。
108.用户在统一后台能看到的菜单列表，由用户的菜单权限码控制，没有权限码的用户看不到已上线的其他菜单，图6所示为系统菜单的一个示例。
109.每个页面上的按钮分成具有查看功能和具有编辑功能的属性，也可以根据需要再新增其他功能分类。拥有该页面查看按钮权限码的用户，可以点击具有查看功能的按钮，例如图7所示页面中的“查看”按钮，来查看相关信息。拥有该页面编辑按钮权限码的用户，可以点具有编辑功能的按钮，例如图7所示页面中的“新建”按钮，来进行编辑新建的检查计划。
110.根据页面需求，在部分页面上，用户可以利用央服账号查询出所有的数据，但某个子公司账号只能查看自己的数据，如图8所示，浙江分公司的账号只能看到浙江分公司自己的检查计划。
111.如图9所示，列出了各个页面中的事件以及事件对应的权限码。
112.4、活动类型表
113.由于需要对不同类型的活动分开定义，所以需要一张活动类型表，该表可以以数据库形式存在。例如建立一张名为standard的表，使活动类型作为其中的一个属性字段。活动类型可以包括协议类短期活动、协议类长期活动和非协议类活动。还可以根据需要在活动类型表中新增活动类型，具体可以通过维护数据库来实现。例如，利用一张数据表来维护活动类型的值(value)，可以根据需要设置value为下述值：协议类长期协议、协议类短期协议、非协议ine检查、非协议3p检查等。
114.二、核心业务模块
115.核心业务模块包括问卷管理平台模块、活动管理模块、活动分发模块、活动检查结果接受模块、图像识别调度模块、检查结果回盘接收模块和检查结果查看模块。
116.1、问卷管理平台模块
117.如图10所示，为问卷平台模块所展示的页面。问卷平台模块包括问卷列表，其中包括了问卷的一些基本信息，例如创建时间、问卷id、问卷名称、问卷题型、问卷纬度、场景类型、所属业务单位。基础问卷包括场景问卷和售点问卷。基础问卷的题型包括选择题、判断题、可选填空题、填空题。根据可否进行图像识别，还将基础问卷分为ir(图像识别)问卷和非ir问卷。当图像识别无法执行检查其中前者为门店老板不允许检查人员拍照时，即只能通过人工手动模式检查时需要填写的问卷。对于场景问卷，因为有些时候需要根据场景进行聚合，所以需要将每个场景问卷绑定到一个具体的场景小类，例如ko冰柜、百事冰柜等。
118.考虑到基础问卷一旦被启用后，如果有修改，可能会对问卷答案的上传产生影响，所以一律规定基础问卷被启用以后都不允许再修改。如果想更换问卷，可以重新设置新的基础问卷。
119.2、活动管理模块
120.如图11-14所示，活动管理模块的页面包括创建检查项目页面、配置生动化页面、设置完成页面、生动化映射页面以及设置整改要求页面。这些页面的功能包括活动的创建，活动下生动化的创建，生动化下的问卷添加，活动规则设置，绑定活动规则的输出项和生动化之间的关联关系。活动的属性除了名称之外，还有活动类型、描述等；生动化除了名称之外，还有对应需要拍照的场景、对应问卷(含ir问卷和非ir问卷)，生动化的陈列要求描述、生动化的成功图像等。
121.3、活动分发模块
122.如图15-18所示，活动分发模块包括检查计划模块和活动分发接口。检查计划模块被配置为用于设置活动检查计划，包括配置执行工具及时间页面和配置售点页面。如图15所示，检查计划列表中列出了现有的活动检查计划，可以点击“新建”按钮新增检查计划。如图16和17所示，在配置执行工具及时间页面和配置售点页面可以对单个检查计划进行设置，设置内容包括检查项目、检查时间、和执行工具、售点、售点所属的组织架构，以及售点有无冰柜等。其中对售点的设置，可以支持售点列表导入，或者分发到各种售点属性的且或非集合。例如，如图17，当选择将活动分发到杭州区且卖场渠道时，系统会从售点库中筛选所有浙江bu(business unit业务单位)下杭州区且售点渠道组为卖场渠道的售点，若选择将活动分发到杭州区或卖场渠道时，系统会从售点库中筛选所有浙江bu下杭州区或售点渠
道组为卖场渠道的售点。
123.图18显示了活动分发接口定义的请求参数和返回参数。
124.一般，一个活动在同一时间，可以有多个检查计划但必须分不同的执行工具来执行这些检查计划，即实现同时多工具检查。另外也可以由同一工具在不同时间执行多个检查计划，即分阶段检查。
125.正常情况下，一个活动在同一时间，可以有多个检查计划但必须分不同的执行工具，即同时多工具检查。同时也可以同一工具在不同时间有多个计划，即分阶段检查。
126.4、活动检查结果接受模块
127.活动检查结果接受模块包括上传活动场景拍照/基础问卷答案的接口，以及活动检查结束接口。如图19所示，显示了上传活动场景拍照/基础问卷答案的接口中定义的请求函数和返回函数。如图20所示，显示了活动检查结束接口中定义的请求函数和返回函数。
128.5、图像识别调度模块
129.图像识别调度模块被配置为根据收到的活动场景照片、基础问卷的答案以及本次走访自带产生的数据，通过判断逻辑来控制如何进行图像识别，如何调用规则引擎(即拿哪些数据传规则引擎、传几次规则引擎、传哪几条规则等)，以基于规则引擎最终获得活动的检查结果。
130.对于执行工具上传的场景拍摄照片，默认除了基础问卷的补充图片(有特殊字段控制)之外，都需要进行图像识别。判断当前结束的走访所属的活动有哪些，一般分 2种模式，一种为执行工具已告知所属哪些活动；一种为不告知。不告知时，则默认为当前售点在当时关联到的所有活动计划。如果上传的场景拍摄照片属于多个不同活动，则分多次针对每一个活动挨个调用规则引擎计算检查结果，那么一次走访会产生多条规则引擎的结果，对应多个不同的活动。
131.6、检查结果回盘接收模块
132.如图21所示，检查结果回盘接收模块包括显示了检查结果列表的页面。该模块将规则引擎计算结果录入到统一活动管理系统的数据库中。对于需要推送检查结果的执行工具，将检查结果推送至执行工具。对于无推送机制的执行工具，则提供查询api，由执行工具自行调用查询api后获得规则引擎计算出的检查结果。由于设置了活动规则的输出项和生动化之间的关联关系，因此，检查结果一般以这种关联关系方式向执行工具呈现。
133.7、检查结果查看模块
134.检查结果查看模块包括检查结果报表查看页面与检查结果报表下载页面。得到规则引擎计算出的检查结果以后，需要提供一个途径供人查阅和下载。由于每个活动需要检查的输出项是不一样的，所以每个活动的检查结果输出列也是不同的，因此每次只能选择一个活动的检查结果进行查看或者下载。
135.以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。