Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -2,55 +2,9 @@
2	2	{{toc/}}
3	3	{{/box}}
4	4
	5	+(% class="wikigeneratedid" %)
5	5	= zpd_case#21_20191126 =
6	6
7		-问题描述：办理企业号客户反应了两个问题！
8		-
9		-~-~-跟踪
10		-
11		-【shi】：以下问题皆基于刷卡充电前提，需分用户类型讨论，
12		-类型1：真实个人注册了微信充电服务-简称：【真实用户】
13		-类型2：未注册微信充电服务-简称：【虚拟用户】
14		-
15		-1.每次充电电度，地点和金额能不能通过微信或者短信的方式通知到客户？客户知道在哪里消费了多少金额！
16		-答：
17		-【真实用户】方案：真实用户之微信号+【选择部门扣费渠道】。
18		-【虚拟用户】方案：虚拟用户 分配 在1个部门（子运营商），提供给部门管理员平台的子账号，可登录后台查看相关充电记录。
19		-\\2，客户余额能否设置个报警告知客户卡上余额不多了需要充值？
20		-答：
21		-【真实用户】方案：“首页/客户管理/会员管理/会员管理”中配置 【账号余额提醒】阀值，余额达到指定金额，系统给出微信消息提示。
22		-【虚拟用户】方案： ”首页/客户管理/企业部门管理“中定位虚拟用户对应指定部门，页面右上角 配置 【账号余额提醒】阀值，余额达到指定金额，系统给出微信消息提示。查看部门操作见下：
23		-a）“首页/客户管理/会员管理/会员管理“ 找到指定虚拟用户绑定的部门。
24		-b）”首页/客户管理/企业部门管理“中定位部门，为其设置手机号。
25		-\\具体操作需根据客户选择，再给出操作步骤。
26		-
27		-~~update 12.3
28		-
29		-【chinyee】：客户选择了虚拟用户类型进行操作配置。
30		-帮客户新建了一个账号whly（供车队使用） 权限为查看充电记录
31		-新建了一个子运营商 深圳市为华旅游运输有限公司 部门已绑定子运营商
32		-【shi】：人工补救处理办法。 shi已处理。
33		-1、查询部门id=28的充电记录之条件sql 如下，知悉11.22日后此部门下用户开始充电，发现此部门下只有1个虚拟需用，useId=00072889
34		-where 1=1
35		-and rh.C_CREATE_DATE>'2019-11-22 02:00'
36		-#and rh.C_SUBOPERATOR=16
37		-and m.C_ENTERPRISE_ID=28
38		-
39		-2、根据1分析结果，执行纠正数据（因运营数据之关键，执行需确保100%无误）
40		- a 确认需纠正数据，比如数量。
41		- SELECT id from recharge_history rh where rh.C_CREATE_DATE>'2019-11-22 02:00' and rh.C_MEMBER_ID in (select id from member where c_user_id='00072889');
42		- b  执行纠正数据
43		- update recharge_history rh set C_SUBOPERATOR=16 where rh.C_CREATE_DATE>'2019-11-22 02:00' and rh.C_MEMBER_ID in (select id from member where c_user_id='00072889');
44		-
45		-~-~-解决:
46		-状态（☑表示选定 ）： 已解决 | 处理中 | 暂搁置
47		-售后（跟单）工程师：施文俊
48		-
49		-
50		-
51		-
52		-= zpd_case#21_20191126 =
53		-
54	54	问题描述：这个车天天在我这里充电，今天怎么都充不了了！这个报错是什么意思？
55	55
56	56	[[image:1574757543672-178.png||height="375" width="281"]][[image:1574757558197-103.png||height="379" width="284"]]