从版本< 33.1 >
chinyee he编辑
在2019/11/26 16:39上
到版本
chinyee he编辑
在2019/12/04 09:19上
< >
修改评论 上传新附件1575422351371-202.png

Summary

Details

Page properties
Content
... ... @@ -2,6 +2,70 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 += zpd_case#21_20191126 =
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 +问题描述:这个车天天在我这里充电,今天怎么都充不了了!这个报错是什么意思?
55 +
56 +[[image:1574757543672-178.png||height="375" width="281"]][[image:1574757558197-103.png||height="379" width="284"]]
57 +
58 +~-~-跟踪
59 +
60 +【chinyee】:从充电记录来看,充电停止原因:[2]与车辆通信超时
61 +
62 +【shi】:bms 和电桩握手时超时,车的bms问题,然后让他去找车厂
63 +
64 +~-~-解决:
65 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 
66 +售后(跟单)工程师:施文俊 chinyee
67 +
68 +
5 5  = zpd_case#20_20191126 =
6 6  
7 7  问题描述:
... ... @@ -17,6 +17,36 @@
17 17  聚能桩记录中有相当部分的状态开始是这样从2-3-2-3的情况 盛弘桩基本都是2-3-3-3
18 18  
19 19  账单号:20191125004937842819、20191125202531894994
84 +~~update 20191127
85 +【john】:从日志上看是2-2-3-3这个顺序的,因为数据库日期字段精度问题丢失了毫秒,所以你这个查询排序有问题。另外因为变化太快,前端UI可能直接就拿到3了。
86 +【shi】:根据john回覆,应该不是2-3-2-3 问题。 以下新的分析发现, 鉴权 到 枪状态变化 的时间较长 可能是 聚能桩 目前问题所在(聚能桩存在状态1,且1-》2的时间消耗较多,对比盛弘桩不存在状态1)。
87 +~~~~~~~~聚能桩 3例
88 +~~44030900210000200006 | 20191125004937842819 鉴权轨迹  ,状态1-》2 用了55秒,状态2 -》3 用了37秒
89 +时间  状态
90 +2019-11-25 00:49:38  1
91 +2019-11-25 00:50:33  2
92 +2019-11-25 00:51:10  3
93 +~~44030900210000200007  | 20191127055345257233  鉴权轨迹  ,状态1-》2 用了30秒,状态2 -》3 用了22秒
94 +时间  状态
95 +2019-11-27 05:53:46  1
96 +2019-11-27 05:54:16  2
97 +2019-11-27 05:54:38  3
98 +~~44030900210000200008  | 20191127080234995388  鉴权轨迹  ,状态1-》2 用了20秒,状态2 -》3 用了19秒
99 +时间  状态
100 +2019-11-27 08:02:34  1
101 +2019-11-27 08:02:54  2
102 +2019-11-27 08:03:13  3
103 +\\~~~~~~~~盛弘桩 2 例,皆不存在 状态 1,说明都是插枪后 鉴权,桩上送的是2-枪准备就绪
104 +~~ 44030900210000200001 | 20191127085834682518  鉴权轨迹  ,状态2 -》3 用了33秒
105 +时间  状态
106 +2019-11-27 08:58:34  2
107 +2019-11-27 08:59:07  3
108 +~~ 44030900210000200001 | 20191127085816880169  鉴权轨迹  ,状态2 -》3 用了27秒
109 +时间  状态
110 +2019-11-27 08:58:33    2
111 +2019-11-27 08:59:00  3
112 +【客户】:现场试充电桩,已经没有延迟问题。
113 +【shi】:聚能未报告有做改动。令狐充未做改动,待观察,后续有类似情况请用户:1)拍视频。2)提供账单号
20 20  
21 21  ~-~-解决:
22 22  状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 
... ... @@ -153,7 +153,7 @@
153 153  状态(☑表示选定 ):  已解决 | 处理中 | 暂搁置 
154 154  售后(跟单)工程师:施文俊  CHinyee
155 155  
156 -= =
250 += =
157 157  
158 158  = zpd_case#13_20191104 =
159 159  
... ... @@ -231,7 +231,7 @@
231 231  状态(☑表示选定 ): ☑ 已解决 | 处理中 | 暂搁置 
232 232  售后(跟单)工程师:施文俊  CHinyee
233 233  
234 -= =
328 += =
235 235  
236 236  = zpd_case#10_20191024 =
237 237  
... ... @@ -325,7 +325,7 @@
325 325  4.2、登录后台查数据,进行分析,将结果汇报现场人员。
326 326  4.3、不能解决的问题,填写工单提供令狐充,包括:数据、问题描述。(详细见 工单模板)
327 327  
328 -= =
422 += =
329 329  
330 330  = zpd_case#7_20191023 =
331 331  
1575422351371-202.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.Chinyee
Size
... ... @@ -1,0 +1,1 @@
1 +858.5 KB
Content