文档更改展鹏达
在2020/06/11 15:02上被chinyee he修改
修改评论 该版本没有评论
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Attachments (0 modified, 5 added, 0 removed)
Details
- Page properties
-
- 文档作者
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. Chinyee1 +XWiki.yuandong - Content
-
... ... @@ -2,6 +2,156 @@ 2 2 {{toc/}} 3 3 {{/box}} 4 4 5 += zpd_case#27_20200108 = 6 + 7 +问题描述:展鹏达对接小桔(即 滴滴app扫码充电) 8 + 9 +~-~-跟踪 10 +【背景】: 对接需要满足以下: 11 +1、技术对接。【niewei】 12 +2、站点和桩的基础数据完整性。(类似粤易充之必填数据)。【我方指导客户操作】 13 +3、子运营商配置(类似坚信对接小桔)。【我方配置】 14 + 15 +【YD】:20200109 16 + 17 +2)松岗鑫展鸿工业园 和 石岩108物流园 的资料已在平台配置好,剩余站点待客户发送资料。 18 + 19 +3)已在平台配置好//**(冻结中)**// 20 +~-~-解决: 21 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 22 +售后(跟单)工程师:施文俊 23 + 24 + 25 + 26 += zpd_case#26_20200102 = 27 + 28 +问题描述:财务需知道19年3、4季度桩枪数变化 29 + 30 +~-~-跟踪 31 +【shi】:见下图 32 +2019第三季度 33 +[[image:1577938362114-288.png]] 34 +2019第四季度 35 +[[image:1577938300443-831.png]] 36 +~-~-解决: 37 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 38 +售后(跟单)工程师:施文俊 39 + 40 += zpd_case#25_20191230 = 41 + 42 +问题描述:河背2号桩1号枪扫码后不显示自动充满!其他没有问题! 43 + 44 +~-~-跟踪 45 +【令】: 44030900210000200007这个桩的1号枪 客户扫码后手机没有 自动充满 这个选项 导致用户取消服务 都去2号桩充电去了 我看了近几日数据都是这样 46 + 47 +【令技术】:桩有问题,上传的状态一直都是枪没有插上。界面上应该是提示他们插枪,如果插了枪也没变化就有可能是充电枪坏了 (考虑到换到2号枪就没问题可以排除程序问题和车问题) 48 +~-~-解决: 49 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 50 +售后(跟单)工程师:chinyee 施文俊 51 + 52 += zpd_case#24_20191217 = 53 + 54 +问题描述:有没有那种下个微信公众号,绑定充电卡,客户可以自己往卡里面充值? 55 + 56 +~-~-跟踪 57 +【令】: 可以让客户关注展鹏达微信号并注册,您这边去会员管理通过手机号找到他,点击编辑 输入充电卡号就可以,然后直接微信充值就行 卡里和账户余额的钱是一样的。 58 +~-~-解决: 59 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 60 +售后(跟单)工程师:chinyee 61 + 62 + 63 += zpd_case#23_20191205 = 64 + 65 +问题描述:客户在部门管理新建了一个部门,采用刷卡和密码充电,开通一个子账户给部门客户查看充电记录。 66 + 67 +~-~-跟踪 68 +【令】: 帮客户新建了一个账号jybj(供车队使用) 权限为查看充电记录 69 +新建了一个子运营商 玖月搬家公司 部门已绑定子运营商。该部门为这周开始设置,需要导入之前的充电记录。 70 +~-~-解决: 71 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 72 +售后(跟单)工程师:施文俊 chinyee 73 + 74 + 75 += zpd_case#22_20191204 = 76 + 77 +问题描述:松岗3号桩用密码充不了电 78 + 79 +[[image:1575422351371-202.png||height="376" width="501"]] 80 + 81 +~-~-跟踪 82 + 83 +【令】:查看该时间段出现桩故障,让客户检查网络是否稳定。 84 + 85 +[[image:1575422415927-246.png||height="38" width="654"]] 86 + 87 +~-~-解决: 88 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 89 +售后(跟单)工程师:chinyee 90 + 91 + 92 += zpd_case#21_20191126 = 93 + 94 +问题描述:办理企业号客户反应了两个问题! 95 + 96 +~-~-跟踪 97 + 98 +【shi】:以下问题皆基于刷卡充电前提,需分用户类型讨论, 99 +类型1:真实个人注册了微信充电服务-简称:【真实用户】 100 +类型2:未注册微信充电服务-简称:【虚拟用户】 101 + 102 +1.每次充电电度,地点和金额能不能通过微信或者短信的方式通知到客户?客户知道在哪里消费了多少金额! 103 +答: 104 +【真实用户】方案:真实用户之微信号+【选择部门扣费渠道】。 105 +【虚拟用户】方案:虚拟用户 分配 在1个部门(子运营商),提供给部门管理员平台的子账号,可登录后台查看相关充电记录。 106 +\\2,客户余额能否设置个报警告知客户卡上余额不多了需要充值? 107 +答: 108 +【真实用户】方案:“首页/客户管理/会员管理/会员管理”中配置 【账号余额提醒】阀值,余额达到指定金额,系统给出微信消息提示。 109 +【虚拟用户】方案: ”首页/客户管理/企业部门管理“中定位虚拟用户对应指定部门,页面右上角 配置 【账号余额提醒】阀值,余额达到指定金额,系统给出微信消息提示。查看部门操作见下: 110 +a)“首页/客户管理/会员管理/会员管理“ 找到指定虚拟用户绑定的部门。 111 +b)”首页/客户管理/企业部门管理“中定位部门,为其设置手机号。 112 +\\具体操作需根据客户选择,再给出操作步骤。 113 + 114 +~~update 12.3 115 + 116 +【chinyee】:客户选择了虚拟用户类型进行操作配置。 117 +帮客户新建了一个账号whly(供车队使用) 权限为查看充电记录 118 +新建了一个子运营商 深圳市为华旅游运输有限公司 部门已绑定子运营商 119 +【shi】:人工补救处理办法。 shi已处理。 120 +1、查询部门id=28的充电记录之条件sql 如下,知悉11.22日后此部门下用户开始充电,发现此部门下只有1个虚拟需用,useId=00072889 121 +where 1=1 122 +and rh.C_CREATE_DATE>'2019-11-22 02:00' 123 +#and rh.C_SUBOPERATOR=16 124 +and m.C_ENTERPRISE_ID=28 125 + 126 +2、根据1分析结果,执行纠正数据(因运营数据之关键,执行需确保100%无误) 127 + a 确认需纠正数据,比如数量。 128 + 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'); 129 + b 执行纠正数据 130 + 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'); 131 + 132 +~-~-解决: 133 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 134 +售后(跟单)工程师:施文俊 135 + 136 + 137 + 138 += zpd_case#21_20191126 = 139 + 140 +问题描述:这个车天天在我这里充电,今天怎么都充不了了!这个报错是什么意思? 141 + 142 +[[image:1574757543672-178.png||height="375" width="281"]][[image:1574757558197-103.png||height="379" width="284"]] 143 + 144 +~-~-跟踪 145 + 146 +【chinyee】:从充电记录来看,充电停止原因:[2]与车辆通信超时 147 + 148 +【shi】:bms 和电桩握手时超时,车的bms问题,然后让他去找车厂 149 + 150 +~-~-解决: 151 +状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置 152 +售后(跟单)工程师:施文俊 chinyee 153 + 154 + 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 170 +~~update 20191127 171 +【john】:从日志上看是2-2-3-3这个顺序的,因为数据库日期字段精度问题丢失了毫秒,所以你这个查询排序有问题。另外因为变化太快,前端UI可能直接就拿到3了。 172 +【shi】:根据john回覆,应该不是2-3-2-3 问题。 以下新的分析发现, 鉴权 到 枪状态变化 的时间较长 可能是 聚能桩 目前问题所在(聚能桩存在状态1,且1-》2的时间消耗较多,对比盛弘桩不存在状态1)。 173 +~~~~~~~~聚能桩 3例 174 +~~44030900210000200006 | 20191125004937842819 鉴权轨迹 ,状态1-》2 用了55秒,状态2 -》3 用了37秒 175 +时间 状态 176 +2019-11-25 00:49:38 1 177 +2019-11-25 00:50:33 2 178 +2019-11-25 00:51:10 3 179 +~~44030900210000200007 | 20191127055345257233 鉴权轨迹 ,状态1-》2 用了30秒,状态2 -》3 用了22秒 180 +时间 状态 181 +2019-11-27 05:53:46 1 182 +2019-11-27 05:54:16 2 183 +2019-11-27 05:54:38 3 184 +~~44030900210000200008 | 20191127080234995388 鉴权轨迹 ,状态1-》2 用了20秒,状态2 -》3 用了19秒 185 +时间 状态 186 +2019-11-27 08:02:34 1 187 +2019-11-27 08:02:54 2 188 +2019-11-27 08:03:13 3 189 +\\~~~~~~~~盛弘桩 2 例,皆不存在 状态 1,说明都是插枪后 鉴权,桩上送的是2-枪准备就绪 190 +~~ 44030900210000200001 | 20191127085834682518 鉴权轨迹 ,状态2 -》3 用了33秒 191 +时间 状态 192 +2019-11-27 08:58:34 2 193 +2019-11-27 08:59:07 3 194 +~~ 44030900210000200001 | 20191127085816880169 鉴权轨迹 ,状态2 -》3 用了27秒 195 +时间 状态 196 +2019-11-27 08:58:33 2 197 +2019-11-27 08:59:00 3 198 +【客户】:现场试充电桩,已经没有延迟问题。 199 +【shi】:聚能未报告有做改动。令狐充未做改动,待观察,后续有类似情况请用户:1)拍视频。2)提供账单号 20 20 21 21 ~-~-解决: 22 22 状态(☑表示选定 ): 已解决 | 处理中 | 暂搁置
- 1574757558197-103.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.Chinyee - Size
-
... ... @@ -1,0 +1,1 @@ 1 +817.5 KB - Content
- 1575422351371-202.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.Chinyee - Size
-
... ... @@ -1,0 +1,1 @@ 1 +858.5 KB - Content
- 1575422415927-246.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.Chinyee - Size
-
... ... @@ -1,0 +1,1 @@ 1 +9.2 KB - Content
- 1577938300443-831.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.ShiChuck - Size
-
... ... @@ -1,0 +1,1 @@ 1 +36.0 KB - Content
- 1577938362114-288.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.ShiChuck - Size
-
... ... @@ -1,0 +1,1 @@ 1 +23.1 KB - Content