一种用户管理方法、装置及系统与流程

1.本技术涉及数据处理技术领域，尤其涉及一种用户管理方法、装置及系统。


背景技术：

2.在民航业中，机票分销代理人常常使用软件进行机票的订票和出票。航信分销前端系统对于无国际航协iata资质用户未提供能够支持服务的管理功能，从产品技术角度而言，航信分销前端系统支持传统具有iata资质代理的机票分销，在系统中通过公司代码officecode和iata号、操作员agent工作号的创建生成和后台分配定义用户的相关信息，并与产品账号进行关联捆绑，从而便于航空公司渠道管理和票证结算数据的安全处理。
3.随着民航机票平台批发零售模式的发展以及行业门槛的降低，黄牛二代甚至个人不断加入，航信分销前端系统需要能够支持无iata资质的用户加入，即目前航信分销前端系统无法满足用户多样化需求。


技术实现要素：

4.有鉴于此，本技术的目的在于提供了一种用户管理方法、装置及系统，为无国际航协资质的用户提供入行接口，优化用户的入行流程和手续，从而解决的问题，其具体技术方案如下：
5.第一方面，本技术提供了一种用户管理方法，所述方法包括：
6.接收客户端发送的注册请求，所述注册请求包括用户基本信息；
7.基于所述用户基本信息，判断所述注册请求对应的用户是否具有国际航协iata资质；
8.若所述用户不具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号以及虚拟城市代码pcc码；
9.向所述客户端发送注册成功消息。
10.在一种可能的实现方式中，在所述判断所述用户是否具有iata资质之后，所述方法还包括：
11.若所述用户具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号和企业代码。
12.在一种可能的实现方式中，所述方法还包括：
13.接收所述客户端发送的菜单展示请求；
14.基于所述菜单展示请求，判断所述菜单展示请求对应的用户是否为pcc管理员；
15.若所述菜单展示请求对应的用户为pcc管理员，向所述客户端发送所述菜单展示请求对应的菜单，所述菜单包括多个可签约对象；
16.接收所述客户端发送的签约请求，所述签约请求包括待签约对象；
17.生成与所述签约请求对应的签约信息；
18.将所述签约信息发送给所述待签约对象；
19.接收所述待签约对象发送的签约结果；
20.将所述签约结果发送给所述客户端。
21.在一种可能的实现方式中，在所述向所述客户端发送注册成功消息之后，所述方法还包括：
22.接收所述客户端发送的二维码生成请求；
23.基于所述二维码生成请求，生成用于关联操作员的二维码；
24.将所述二维码发送给所述客户端。
25.在一种可能的实现方式中，在所述向所述客户端发送注册成功消息之后，所述方法还包括：
26.接收所述客户端发送的权限分配请求，所述权限分配请求包括各个操作员及其对应的权限；
27.基于所述权限分配请求，将所述权限分配请求中的权限分配给对应的操作员。
28.第二方面，本技术还提供了一种用户管理装置，所述装置包括：
29.接收模块，用于接收客户端发送的注册请求，所述注册请求包括用户基本信息；
30.判断模块，用于基于所述用户基本信息，判断所述注册请求对应的用户是否具有国际航协iata资质；
31.生成模块，用于若所述用户不具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号以及虚拟城市代码pcc码；
32.发送模块，用于向所述客户端发送注册成功消息。
33.在一种可能的实现方式中，所述生成模块，还用于：
34.若所述用户具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号和企业代码。
35.在一种可能的实现方式中，所述接收模块，还用于接收所述客户端发送的二维码生成请求；
36.所述生成模块，还用于基于所述二维码生成请求，生成用于关联操作员的二维码；
37.所述发送模块，还用于将所述二维码发送给所述客户端。
38.在一种可能的实现方式中，所述装置还包括：权限分配模块，
39.所述接收模块，还用于接收所述客户端发送的权限分配请求，所述权限分配请求包括各个操作员及其对应的权限；
40.所述权限分配模块，用于基于所述权限分配请求，将所述权限分配请求中的权限分配给对应的操作员。
41.第三方面，本技术还提供了一种用户管理系统，包括：服务器和客户端；
42.所述服务器，用于执行上述第一方面或第一方面任一项所述的方法；
43.所述客户端，用于：
44.向所述服务器发送注册请求，所述注册请求包括用户基本信息；
45.接收所述服务器发送的注册成功消息。
46.本技术实施例提供的方法，包括：接收客户端发送的注册请求，注册请求包括用户基本信息；基于用户基本信息，判断注册请求对应的用户是否具有国际航协iata资质；若用户不具有iata资质，基于用户基本信息，生成与用户基本信息对应的账号以及虚拟城市代
码pcc码；向客户端发送注册成功消息。本技术实施例为无航协资质的用户提供入行接口，优化用户的入行流程和手续，使得无国际航协资质的用户也能安全地开展机票采购等操作，也便于航空公司渠道管理和票证结算数据的安全处理。
附图说明
47.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
48.图1示出了本技术实施例提供的一种用户管理系统的针对无航协资质代理人的功能示意图；
49.图2示出了本技术实施例提供的一种用户管理方法实施例的流程图；
50.图3示出了本技术实施例提供的一种注册流程图；
51.图4示出了本技术实施例提供的一种pcc管理员签约的流程图；
52.图5示出了本技术实施例提供的一种用户管理装置的结构示意图；
53.图6示出了本技术实施例提供的一种用户管理系统的结构示意图。
具体实施方式
54.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
55.在民航业中，机票分销代理人常常使用软件进行机票的订票和出票。航信分销前端系统对于无国际航协iata资质用户未提供能够支持服务的管理功能，从产品技术角度而言，航信分销前端系统支持传统具有iata资质代理的机票分销，在系统中通过公司代码officecode和iata号、操作员agent工作号的创建生成和后台分配定义用户的相关信息，并与产品账号进行关联捆绑，从而便于航空公司渠道管理和票证结算数据的安全处理。
56.随着民航机票平台批发零售模式的发展以及行业门槛的降低，黄牛二代甚至个人不断加入，航信分销前端系统需要能够支持无iata资质的用户加入，即目前航信分销前端系统无法满足用户多样化需求。
57.航信分销前端系统需要通过前端系统用户体系、开户申请流程、前中后台的开放化技术改造，简化、优化入行复杂流程和管理手续，支持无iata资质用户安全地开展机票采购，使无iata资质用户能够方便、灵活地通过前端查订销售机票，赚取上游航司或批发商的佣金及服务，也能使上游航司或批发商安全可控地进行渠道管理。
58.具体来说，发明人通过研究发现现有的方案存在如下缺点，导致前端系统无法支持无iata资质用户的加入和权限管理：
59.1、用户体系架构：未对无iata资质用户在系统数据库中进行标准规范的定义；前端用户存在平台分销商、小号用户、个人用户等不同角色的交叉混用，用户类型未严格区分和打标识别；未能结合渠道用户的实际业务需要，进行管理员、操作员的不同层级的功能权
限设置；渠道操作员(个人用户)均可以与批发商直接签约，导致批发商渠道审核管理存在混乱和困难；
60.2、缺失一对一的agent工作号实名绑定及双因素安全认证；对于用户的信息变更、登录、销售订单、历史操作未有全面、准确地记录和统计；
61.3、通用前端客户端、移动端、网页端三端部分打通，对于无资质用户与有资质批发商的信息关联、授权管理未能完全整合衔接、共享同步更新，后台数据库存在相对割裂问题。
62.在本技术实施例中，可以通过渠道用户管理体系的技术改进、增强完善满足无iata资质用户产品账号的开户申请，以及账号或扫码两种常用方式登录前端进行机票等内容的采购以及全流程业务管理的支持调整；还可以利用移动端应用(application，app)扫码登录、捆绑切换不同角色账号的技术处理方式，支持实现了同一用户安全衔接、快捷访问三端的需要；将无iata资质用户通过分支审核、在线签约批发商等功能的技术处理实现关键信息的实时通知和传递校验，及时纳入到上游批发商的渠道管理和支持服务中；不同层级的管理员对于无iata资质用户进行功能权限管理设置，支持实现黑屏、白屏机票等不同内容功能的安全使用。
63.首先，对本技术实施例中可能出现的一些名词进行解释。
64.通用前端(腾云)：以travelweb用户管理体系为核心打通通用前端腾云三端，结合批发零售模式整合新增内容功能，为国内外代理渠道客户提供机票查订、优价搜索、订单管理等黑白屏的支持服务。
65.三端：eterm客户端(pc端)、travelweb网页端、app移动端。
66.通用前端渠道用户：包括有office航协资质的传统机票代理和无office资质的公司(新渠道)操作员以及个人用户。成为通用前端腾云用户(travelweb&app)所做的申请登记备案流程，一般需填写：账号、密码、邮箱、手机号、同意用户协议、真实姓名、身份证件、营业执照等。
67.bsp航协资质：由国际航空运输协会(internationalairtransport association，iata)颁发的国际航协iata资质证书，分为iata一类客运资质和iata二类客运资质，分别对应bsp国际票和国内票销售。国际航空运输协会具备管理全球所有bsp会员航空公司的票证的权利，主要负责管理航空公司于代理人之间的票证问题、结算问题、奖励与罚单问题。
68.虚拟城市代码(pseudocitycode，pcc)：作为无航协资质代理即新渠道公司型客户代码的前三位；无资质代理用户即pcc新渠道，包括管理员和操作员两种类型。
69.在线签约批发商：无资质代理管理员需要与有资质代理office的批发商签约获取上游供应的功能授权，之后方可分配权限给下属操作员，并由操作员在系统中进行机票价格的查询、预订和出票等采购服务。
70.请参见图1，示出了本技术实施例提供的一种用户管理系统的针对无航协资质代理人的功能示意图。本用户管理系统攻克无航协资质代理人未能支持服务管理功能的技术壁垒，使得无航协资质的代理人也可以享受到和有航协资质代理人相同的机票的采购以及全流程业务管理的服务支持。对于无代理office资质零售渠道用户的在线申请、签约开通、内容功能授权的销售管理以及黑屏配置流量统计、收费结算的后台销售管理系统支持完善，以腾云travelweb为核心进行用户体系的统一整合、改造打通。
71.pcc公司管理员可以进行权限的控制、对操作员的添加和相关的权限分配、对流量套餐的申请和分配、查看操作员的流量使用情况等；还可以建立共享流量账号，跟踪申请单的详细情况；附加功能主要有优价搜索和航e家。
72.pcc操作员可以进行机票预订、黑屏指令操作等重要操作，同时在菜单栏中，有通航、ndc和航e家等多个外部链接，均是为了能给用户带来更好的体验引入的外部系统功能。ndc是基于xml的，介于航空公司和代理人之间的，用于增强他们之间的数据传输能力的一种数据传输标准。
73.具体的，管理员的功能包括：
74.t-web前端开户申请、在线注册；签约批发商、供应商；获取分配的配置套餐、机票和非机票的功能内容权限；管理和审核操作员以及分配权限；
75.黑屏流量套餐充值申请；订单查询与统计；用户信息维护。
76.操作员的功能包括：
77.前端功能权限查询；白屏优价搜索、查订支付出票；非机票内容查询、产品采购；机票黑屏查订指令；订单查询与统计；用户信息维护；积分查询、奖励兑换。
78.请参见图2，示出了本技术实施例提供的一种用户管理方法实施例的流程图，本技术实施例至少包括以下步骤：
79.s1，接收客户端发送的注册请求，注册请求包括用户基本信息。
80.在本技术实施例中，当用户需要开户注册时，通过客户端发送注册请求，注册请求包括用户基本信息，用户基本信息包括用户名、密码、邮箱、手机号、同意用户协议、真实姓名、身份证件、企业营业执照电子版、企业名称、企业所在省市、手机短信或邮箱验证信息和iata资质号等。iata资质号即企业在国际航协中获得的国际航协iata资质证书的编号。
81.用户可以通过客户端主页左下角点击“开户申请”按钮，再点击“无航协资质开户申请”按钮申请pcc管理员账号。
82.用户输入用户基本信息，点击“提交”按钮后，该开户申请成功提交。用户提交开户申请后，由所属分支机构进行审批，pcc管理员可以通过注册时填写的邮箱收到账号成功申请的相关信息，或通过手机短信收到账号成功申请的相关信息。收到账号信息时，pcc公司管理员就可以登录用户管理系统。
83.s2，基于用户基本信息，判断注册请求对应的用户是否具有国际航协iata资质。
84.接收到客户端发送的注册请求后，基于注册请求中的用户基本信息，判断注册请求对应的用户是否具有iata资质。
85.基于用户基本信息，判断注册请求对应的用户是否具有iata资质，包括：
86.s201，若用户基本信息中包括iata资质号，确定注册请求对应的用户具有iata资质；
87.s202，若用户基本信息中不包括iata资质号，确定注册请求对应的用户不具有iata资质。
88.若用户基本信息中包括iata资质号，在确定注册请求对应的用户具有iata资质之前，还可以判断用户基本信息中的iata资质号对应的企业名称是否为用户基本信息中的企业名称。若用户基本信息中的iata资质号对应的企业名称为用户基本信息中的企业名称，则确定注册请求对应的用户具有iata资质。
89.本技术实施例通过用户基本信息中是否包括iata资质号，确定注册请求对应的用户是否具有iata资质。用户所在企业具有iata资质，则用户也具有iata资质。
90.s3，若用户不具有iata资质，基于用户基本信息，生成与用户基本信息对应的账号以及虚拟城市代码pcc码。
91.若用户不具有iata资质，基于用户基本信息，生成与用户基本信息对应的账号以及pcc码。
92.基于用户基本信息，生成与用户基本信息对应的pcc码，包括：
93.根据用户基本信息中的企业营业执照或根据用户基本信息中的企业所在省市和企业名称，生成与用户基本信息对应的pcc码。
94.需要说明的是，若当前用户注册成功，则当前用户即为pcc管理员。
95.s4，若用户具有iata资质，基于用户基本信息，生成与用户基本信息对应的账号和企业代码。
96.若用户具有iata资质，可以基于用户基本信息，生成与用户基本信息对应的账号和企业代码officecode。
97.基于用户基本信息，生成与用户基本信息对应的企业代码，包括：
98.根据用户基本信息中的企业营业执照和iata资质号，或根据用户基本信息中的企业所在省市、企业名称和iata资质号，生成与用户基本信息对应的企业代码。企业代码与iata资质号一一对应。
99.请参见图3，示出了本技术实施例提供的一种注册流程图。生成与用户基本信息对应的账号，说明用户注册成功。生成与用户基本信息对应的账号的同时，还生成与用户基本信息对应的唯一pcc码或生成与用户基本信息对应的唯一企业代码，以便航信分销前端系统根据pcc码和企业代码对office管理员和pcc管理员进行识别、统计和管理。office管理员为所属企业具有iata资质的管理员，pcc管理员为所属企业或个人不具有iata资质的管理员。
100.s5，向客户端发送注册成功消息。
101.在生成与用户基本信息对应的账号和pcc码/企业代码之后，向客户端发送注册成功消息，使用户可以根据手机号或者邮箱和密码进行登录。其中，注册成功消息包括pcc码或企业代码。生成pcc码或企业代码后，用户自动拥有白屏系统的部分功能。
102.类似于有iata资质代理的officecode(例如bjs000c)，系统中分支审核通过无资质代理(新渠道)的在线注册、开户申请后，用户管理系统自动新增分配了唯一的pcc码信息(虚拟code)，pcc码生成的标准规则便于进行长期的国内或海外用户拓展数量和规模管理。为了能够在移动端进行用户身份唯一性保证，除手机号信息外，(海外)邮箱信息也可作为重要的登录凭据。个人用户采用腾云app进行手机号注册登录后，需要补充证件信息以便自动成为航e家会员、后续订做出票能够进行积分的自动记录和积累；同时作为无iata资质代理的操作员可以通过扫码方式与上级管理员进行关联，使上级管理员分享相关的权限和功能服务。
103.s6，接收客户端发送的二维码生成请求。
104.在用户登录用户管理系统后，可以通过客户端发送二维码生成请求，使得用户可以关联操作员。
105.s7，基于二维码生成请求，生成用于关联操作员的二维码。
106.在接收到客户端发送的二维码生成请求之后，基于二维码生成请求，生成与二维码生成请求对应的用于关联操作员的二维码。
107.操作员包括pcc操作员和office操作员。在基于二维码生成请求，生成用于关联操作员的二维码，包括：
108.判断二维码生成请求对应的用户是否为管理员；
109.若二维码生成请求对应的用户是管理员，判断管理员是否为pcc管理员；
110.若管理员为pcc管理员，则基于二维码生成请求，生成用于关联pcc操作员的二维码；
111.若管理员不为pcc管理员，则基于二维码生成请求，生成用于关联office操作员的二维码。
112.s8，将二维码发送给客户端。
113.将生成的二维码发送给客户端，以便操作员可以通过扫描二维码的形式与管理员进行关联。
114.s9，接收客户端发送的权限分配请求，权限分配请求包括各个操作员及其对应的权限。
115.本技术实施例还可以接收客户端发送的权限分配请求。当用户需要对操作员进行权限分配时，通过客户端发送权限分配请求，权限分配请求包括各个操作员以及各个操作员对应的权限。
116.s10，基于权限分配请求，将权限分配请求中的权限分配给对应的操作员。
117.在接收到客户端发送的权限分配请求之后，将权限分配请求中的权限分配给对应的操作员。
118.在将权限分配请求中的权限分配给对应的操作员之前，本技术实施例还包括：判断权限分配请求对应的用户是否为管理员。只有当权限分配请求对应的用户为管理员时，才能将权限分配请求中的权限分配给对应的操作员。
119.管理员可以通过用户管理系统进行员工管理和权限管理，为下属操作员分配需要的查询、预订、出票、订单统计等业务功能权限。
120.请参见图4，示出了本技术实施例提供的一种pcc管理员签约的流程图，本技术实施例还可以包括以下步骤：
121.s11，接收客户端发送的菜单展示请求；
122.s12，基于菜单展示请求，判断菜单展示请求对应的用户是否为pcc管理员；
123.s13，若菜单展示请求对应的用户为pcc管理员，向客户端发送菜单展示请求对应的菜单，菜单包括多个可签约对象；
124.s14，接收客户端发送的签约请求，签约请求包括待签约对象；
125.s15，生成与签约请求对应的签约信息；
126.s16，将签约信息发送给待签约对象；
127.s17，接收待签约对象发送的签约结果；
128.s18，将签约结果发送给客户端。
129.以上为用户进行签约的过程，对于用户与待签约对象的签约需要进行身份角色的
必要判断，无iata资质代理只有pcc管理员可以与批发商(供应商)签约，pcc操作员无需查询关心签约协议的内容和状态，无需进行签约相关操作处理，只需要与上级管理员签约保持一致并由上级管理员进行相关权限的分配即可。
130.无iata资质的新渠道pcc管理员的开户申请信息被系统审核通过后(注册提交的邮箱将收到通知的邮件或短信通知)就拥有了pcc码和白屏优价搜索的功能权限，即可使用web账号(手机号即用户名)和自设的密码登录腾云travelweb，通过优价搜索进行航班查询(批发商的政策价格显示)、批发商签约(审核确认方可通过、一次性完成后无需重复签约)等，而预订、在线支付和自动出票等白屏功能则主要由管理员下属的操作员负责实施。系统审核通过的pcc管理员可以通过腾云app套餐管理或web端继续向系统进行黑屏流量及白屏机票等功能权限的充值申请，以及员工管理中创建生成二维码分享给下属操作员进行扫码关联或添加自己成为操作员，新渠道的操作员可以根据上级管理员的签约情况，使用特定批发商提供的黑屏office进行机票查订指令以及白屏的查订出等机票销售。管理员还可在员工管理中查看下属员工(操作员)的剩余流量。
131.因此，本技术实施例还包括：
132.s19，接收所述客户端发送的充值申请请求，充值申请请求包括待充值对象和待充值数值；
133.s20，基于所述充值申请请求为所述充值申请请求对应的用户进行充值；
134.s21，接收所述客户端发送的流量查看请求，流量查看请求包括待查看对象；
135.s22，基于所述流量查看请求，获取待查看对象的剩余流量数值；
136.s23，将剩余流量数值发送给客户端。
137.pcc管理员注册成功后，默认无可用配置，需要上级分支分配配置套餐，上级分支分配完配置套餐后，pcc管理员可以在“配置管理”下的“申请新配置”中进行申请。点击“申请新配置”，进入配置申请页面，pcc管理员可以查询可销售配置单价及实际应缴款情况，从而提交新配置申请。
138.pcc管理员在配置申请成功后，可以对已有配置进行充值，进入配置充值页面，可以查询配置现有余额、配置的每月单价，pcc管理员可根据这些信息申请配置使用时长，对配置进行充值。
139.pcc管理员可以进入“申请单管理”进行已提交申请的状态跟踪查询。在“申请单管理”页面中，可根据申请单类型(充值申请、新配置申请)、状态(未审批、已通过、已拒绝)进行查询。
140.流量指黑屏发送指令条数，需要注意的是：
141.(1)pcc管理员在套餐管理里面查看到的剩余流量，是扣除全部下属操作员实际使用的流量后的流量数据；管理员分配给操作员的额度(因为未实际使用)不扣减管理员的当前剩余流量；管理员给操作员分配的额度上限不能超过管理员当前的剩余总流量(剩余总流量与可分配额度是大于等于的关系)即管理员每次给每个操作员可分配的(流量)额度最多为管理员当前的剩余总流量；操作员的可用额度，可以超过管理员当前的剩余流量。
142.(2)管理员分配给操作员a/b/c的剩余额度要根据操作员的流量实际使用情况实时扣除、减少(即剩余额度可查)；且操作员a+b+c可实际使用的额度流量要始终限制在《＝共享管理员的剩余总流量(共享管理员的剩余总流量是动态变化的)；操作员在使用黑屏指
令流量后，可用剩余额度(实时)的减少数值即已用流量的增加数值；管理员、操作员除了剩余的流量额度外，还增加实际已使用的流量，便于核对管理或问题发现。两个流量额度分配管理的核验公式：
143.1.新渠道管理员申请充值(上级分支审核确认)的总流量＝管理员剩余流量+全部操作员已用流量；
144.2.新渠道每个操作员被管理员分配的总额度＝操作员剩余额度+操作员已用流量；
145.(3)新渠道操作员在被管理员分配的可用剩余额度内共享管理员的剩余总流量，操作员可用(黑屏)流量的有效期与管理员剩余流量的有效期保持一致。
146.(4)当管理员账号被关停取消后，关联的操作员无法使用管理员分配的(黑屏)流量及功能权限，可通过解绑自行恢复个人用户的角色身份；但腾云app原有的基础功能(如优价搜索)仍可用。
147.(5)新渠道管理员、操作员通过腾云app查看到的流量情况，如剩余额度或已用流量，与扫码登录web端的查看功能和内容保持一致。
148.(6)一个腾云app(手机)账号只能绑定、对应一个管理员账号(要么是office管理员，要么是pcc管理员，不可能同时成为两类管理员)。一个腾云app账号可以扫码关联、绑定成为多个不同office或一个pcc管理员的操作员账号。
149.(7)如果在线注册被分支审核通过的pcc管理员，不可以再扫码关联、申请成为其它pcc管理员的操作员；但是可以扫码关联、申请成为一家或多家office管理员的操作员，以一家或多家office管理员的操作员的账号身份获取的黑屏流量不可以再向下分配；
150.(8)如果是office管理员的腾云app账号，目前能扫码关联、申请成为多个其它office管理员的操作员；也能扫码关联pcc管理员，成为pcc管理员的操作员。
151.新渠道指在原有的office用户体系下，新增了pcc管理员和pcc操作员两种角色。
152.本技术实施例通过对无iata资质用户在前端系统中的标准规范、打标定义及用户体系架构的改造，对以往的平台分销商、小号用户、个人用户等不同角色有了严格而清楚地区分，支持无资质渠道管理员针对操作员进行功能权限设置和授权管理；在三端部分关联打通基础关键信息的共享同步更新，实现用户信息变更、登录、销售订单、历史操作等全面、准确地记录和统计，从而满足无iata资质用户的实际业务销售和安全管理的需要。
153.在本技术实施例中，接收客户端发送的注册请求，注册请求包括用户基本信息；基于用户基本信息，判断注册请求对应的用户是否具有国际航协iata资质；若用户不具有iata资质，基于用户基本信息，生成与用户基本信息对应的账号以及虚拟城市代码pcc码；向客户端发送注册成功消息。本技术实施例为无航协资质的用户提供入行接口，优化用户的入行流程和手续，使得无航协资质的用户也能安全地开展机票采购等操作，也便于航空公司渠道管理和票证结算数据的安全处理。
154.接下来对本技术提供的一种用户管理装置进行介绍，下文介绍的一种用户管理装置与上文介绍的一种用户管理方法可相互对应参照。
155.请参见图5，示出了本技术提供的一种用户管理装置的结构示意图，所述装置包括：
156.接收模块501，用于接收客户端发送的注册请求，所述注册请求包括用户基本信
息；
157.判断模块502，用于基于所述用户基本信息，判断所述注册请求对应的用户是否具有国际航协iata资质；
158.生成模块503，用于若所述用户不具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号以及虚拟城市代码pcc码；
159.发送模块504，用于向所述客户端发送注册成功消息。
160.在本技术实施例中，所述生成模块503，还用于：
161.若所述用户具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号和企业代码。
162.在本技术实施例中，所述接收模块501，还用于接收所述客户端发送的菜单展示请求；
163.所述判断模块502，还用于基于所述菜单展示请求，判断所述菜单展示请求对应的用户是否为pcc管理员；
164.所述发送模块504，还用于若所述菜单展示请求对应的用户为pcc管理员，向所述客户端发送所述菜单展示请求对应的菜单，所述菜单包括多个可签约对象；
165.所述接收模块501，还用于接收所述客户端发送的签约请求，所述签约请求包括待签约对象；
166.所述生成模块503，还用于生成与所述签约请求对应的签约信息；
167.所述发送模块504，还用于将所述签约信息发送给所述待签约对象；
168.所述接收模块501，还用于接收所述待签约对象发送的签约结果；
169.所述发送模块504，还用于将所述签约结果发送给所述客户端。
170.在本技术实施例中，所述接收模块501，还用于接收所述客户端发送的二维码生成请求；
171.所述生成模块503，还用于基于所述二维码生成请求，生成用于关联操作员的二维码；
172.所述发送模块504，还用于将所述二维码发送给所述客户端。
173.在本技术实施例中，所述装置还包括：权限分配模块，
174.所述接收模块501，还用于接收所述客户端发送的权限分配请求，所述权限分配请求包括各个操作员及其对应的权限；
175.所述权限分配模块，用于基于所述权限分配请求，将所述权限分配请求中的权限分配给对应的操作员。
176.请参见图6，示出了本技术提供的一种用户管理系统的结构示意图，所述系统包括：服务器61和客户端62。
177.服务器61，用于执行上述方法实施例所述的方法；
178.客户端62，用于：
179.向所述服务器发送注册请求，所述注册请求包括用户基本信息；
180.接收所述服务器发送的注册成功消息。
181.在本技术实施例中，接收客户端发送的注册请求，注册请求包括用户基本信息；基于用户基本信息，判断注册请求对应的用户是否具有国际航协iata资质；若用户不具有
iata资质，基于用户基本信息，生成与用户基本信息对应的账号以及虚拟城市代码pcc码；向客户端发送注册成功消息。本技术实施例为无航协资质的用户提供入行接口，优化用户的入行流程和手续，使得无航协资质的用户也能安全地开展机票采购等操作，也便于航空公司渠道管理和票证结算数据的安全处理。
182.需要说明的是，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例、系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
183.对于前述的各实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
184.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
185.对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
186.以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。

技术特征：
1.一种用户管理方法，其特征在于，所述方法包括：接收客户端发送的注册请求，所述注册请求包括用户基本信息；基于所述用户基本信息，判断所述注册请求对应的用户是否具有国际航协iata资质；若所述用户不具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号以及虚拟城市代码pcc码；向所述客户端发送注册成功消息。2.根据权利要求1所述的方法，其特征在于，在所述判断所述用户是否具有iata资质之后，所述方法还包括：若所述用户具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号和企业代码。3.根据权利要求1所述的方法，其特征在于，所述方法还包括：接收所述客户端发送的菜单展示请求；基于所述菜单展示请求，判断所述菜单展示请求对应的用户是否为pcc管理员；若所述菜单展示请求对应的用户为pcc管理员，向所述客户端发送所述菜单展示请求对应的菜单，所述菜单包括多个可签约对象；接收所述客户端发送的签约请求，所述签约请求包括待签约对象；生成与所述签约请求对应的签约信息；将所述签约信息发送给所述待签约对象；接收所述待签约对象发送的签约结果；将所述签约结果发送给所述客户端。4.根据权利要求1至3任一项所述的方法，其特征在于，在所述向所述客户端发送注册成功消息之后，所述方法还包括：接收所述客户端发送的二维码生成请求；基于所述二维码生成请求，生成用于关联操作员的二维码；将所述二维码发送给所述客户端。5.根据权利要求1至3任一项所述的方法，其特征在于，在所述向所述客户端发送注册成功消息之后，所述方法还包括：接收所述客户端发送的权限分配请求，所述权限分配请求包括各个操作员及其对应的权限；基于所述权限分配请求，将所述权限分配请求中的权限分配给对应的操作员。6.一种用户管理装置，其特征在于，所述装置包括：接收模块，用于接收客户端发送的注册请求，所述注册请求包括用户基本信息；判断模块，用于基于所述用户基本信息，判断所述注册请求对应的用户是否具有国际航协iata资质；生成模块，用于若所述用户不具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的账号以及虚拟城市代码pcc码；发送模块，用于向所述客户端发送注册成功消息。7.根据权利要求6所述的装置，其特征在于，所述生成模块，还用于：若所述用户具有iata资质，基于所述用户基本信息，生成与所述用户基本信息对应的
账号和企业代码。8.根据权利要求6至7任一项所述的装置，其特征在于，所述接收模块，还用于接收所述客户端发送的二维码生成请求；所述生成模块，还用于基于所述二维码生成请求，生成用于关联操作员的二维码；所述发送模块，还用于将所述二维码发送给所述客户端。9.根据权利要求6至7任一项所述的装置，其特征在于，所述装置还包括：权限分配模块，所述接收模块，还用于接收所述客户端发送的权限分配请求，所述权限分配请求包括各个操作员及其对应的权限；所述权限分配模块，用于基于所述权限分配请求，将所述权限分配请求中的权限分配给对应的操作员。10.一种用户管理系统，其特征在于，包括：服务器和客户端；所述服务器，用于执行如权利要求1至5任一项所述的方法；所述客户端，用于：向所述服务器发送注册请求，所述注册请求包括用户基本信息；接收所述服务器发送的注册成功消息。

技术总结
本申请实施例提供了一种用户管理方法、装置及系统，该方法包括：接收客户端发送的注册请求，注册请求包括用户基本信息；基于用户基本信息，判断注册请求对应的用户是否具有国际航协IATA资质；若用户不具有IATA资质，基于用户基本信息，生成与用户基本信息对应的账号以及虚拟城市代码PCC码；向客户端发送注册成功消息。本申请实施例为无航协资质的用户提供入行接口，优化用户的入行流程和手续，使得无国际航协资质的用户也能安全地开展机票采购等操作，也便于航空公司渠道管理和票证结算数据的安全处理。的安全处理。的安全处理。


技术研发人员：陈鹏 杨毅 李珂 邢浩 吴一凡 冉瑛 段琴月 陈俊安
受保护的技术使用者：中国民航信息网络股份有限公司
技术研发日：2023.04.04
技术公布日：2023/9/22