Show last authors
| 1 | {{box cssClass="box floatinginfobox" title="**Summary**"}} |
| 2 | {{toc/}} |
| 3 | {{/box}} |
| 4 | |
| 5 | = function_case#21_20200416 = |
| 6 | |
| 7 | 系统单元：BO2.0 |
| 8 | 问题描述：在线VIN鉴权充电，见tapd |
| 9 | |
| 10 | |
| 11 | ~-~--跟踪 |
| 12 | |
| 13 | (% class="box" %) |
| 14 | ((( |
| 15 | 【产品】：把vin鉴权增加到目前的车辆车架管理模块。按目前的流程，可单独创建，也可批量导入。导入后，可设置部门和开通鉴权功能。需要增加1、vin鉴权功能，2、增加会员信息展示和输入（如通过会员手机号，关联展示会员相信信息） |
| 16 | [[image:1587029701718-117.png]] |
| 17 | |
| 18 | [[image:1587029800174-976.png]] |
| 19 | |
| 20 | 【shi】： |
| 21 | ~~必要功能： |
| 22 | 1 能沿用到原车架管理的数据。 |
| 23 | 2 报表查询可以查到充电数据。 |
| 24 | 3、纯粹vin校验，实际仅从车的纬度就可以完成，不用考虑人纬度。目前，车也可以直接归到某部门中（是否必须要和人关联可以再考虑下？增加操作使用复杂度）。 |
| 25 | ~~实施原则： |
| 26 | 1、 考虑到vin鉴权是会被广泛高频使用的特色功能，整体功能评估后再决定实施。 |
| 27 | 2、 确保近期小改后先能用（如 ：客户特别急，第一批的甚至可以技术人员代为批量导入等临时处理） |
| 28 | 3、从技术先行 转变 产品设计先行。考虑用户操作维护之 易读易理解易操作。 |
| 29 | ))) |
| 30 | |
| 31 | ~-~--解决 |
| 32 | |
| 33 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 34 | |
| 35 | 售后（跟单）工程师：施文俊 |
| 36 | |
| 37 | = function_case#20_20200408 = |
| 38 | |
| 39 | 系统单元：MC2.0 |
| 40 | 问题描述：银行卡退款 |
| 41 | |
| 42 | ~-~--跟踪 |
| 43 | |
| 44 | (% class="box message" %) |
| 45 | ((( |
| 46 | 【运营中问题】：其中 1转产品评估；2未上线，和产品协商上线时间 |
| 47 | 1、需要填写支行： 公司开户行是工行，除非个人的是工行可以不填开支行，其他银行都要填写开户支行。见下图 |
| 48 | 2、线上、线下退款不同手续费： |
| 49 | 2.1）独立设置。 |
| 50 | 2.2）用户端能看到相关手续费提示。 |
| 51 | [[image:1586324727043-667.png]] |
| 52 | ))) |
| 53 | |
| 54 | ~-~--解决 |
| 55 | |
| 56 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 57 | |
| 58 | 售后（跟单）工程师：施文俊 |
| 59 | |
| 60 | = function_case#19_20200318 = |
| 61 | |
| 62 | 系统单元：bo2.0 |
| 63 | 问题描述：客户对占桩机制质疑和优化 |
| 64 | |
| 65 | ~-~--跟踪 |
| 66 | |
| 67 | (% class="box message" %) |
| 68 | ((( |
| 69 | 【客户】：跟德顺安总沟通了微信客户端“电桩详情”的状态描述。除了我们昨天沟通的内容之外，还有一种状态需要考虑。如果德顺开始收取占桩停车费，当出现因为充电机或平台或网络故障造成客户车辆电池未充满，但是自动跳枪停止充电的情况，此时的状态描述是否也是“占桩中”？是否会计收停车费？如果这种情况也收停车费的话，客户肯定不能接受，需要与“占桩”状态区分开来另行处理。 |
| 70 | ~~~~ |
| 71 | 【令】：针对“充电机或平台或网络故障造成客户车辆电池未充满，但是自动跳枪停止充电”，分析见下： |
| 72 | |
| 73 | **平台占桩提醒机制：** |
| 74 | 1、车辆满电占桩、或微信端主动停止充电时，平台发送“占桩收费”提醒消息，提醒N分钟后即将收取占桩费并含详细的占桩计费信息。（N在平台电价配置） |
| 75 | 2、开始计算占桩费时，平台再次发送微信消息，通知开始收取占桩费。 |
| 76 | 3、启用占桩收费后，微信端启动充电和充电结束阶段，平台发送“占桩收费”消息，包括详细的占桩计费信息。【**待产品评估**确认：启动时增加提醒占桩费】 |
| 77 | \\**造成桩占桩整理之场景：** |
| 78 | 场景1：车辆bms未严格遵循国标，启动阶段，桩端和车辆握手异常，桩主导跳枪。 |
| 79 | 场景2：账户余额不足，充电过程，平台根据阀值自动停止充电。 |
| 80 | 场景3：充电过程中，桩断网，且持续至车辆满电占桩，网络一直未恢复。一段时间后，桩恢复网络，补送设备账单。当符合条件【拔枪时间-充电结束时间>计费策略中设置的免费占桩时间】，此时产生站桩费用。 |
| 81 | \\**责任和解决：** |
| 82 | 其中：场景1、2 应 属于用户这边的问题，可以提前申明告知用户责任。 |
| 83 | 场景1，严格意义是因为用户车辆不符合国标，引起跳枪停止充电时，收到占桩提醒，又未及时拔枪挪车引起，见下**技术细节**。【**niewei**、john确认，此时停止原因多是“bms通讯异常停止”】 |
| 84 | 场景2，因为用户没有保障充足余额，停止充电时，收到占桩提醒，又未及时拔枪挪车引起。 |
| 85 | 场景3，见下 |
| 86 | 1）正常情况，应保障场站的网络稳定，如果发生断网，也应在短时间内恢复场站网络。平台可及时获取最新桩状态，避免用户收到不准确数据。 |
| 87 | 2）如认可第1）项，长时间的断网是严重影响运营，没有网络的情况，桩无法联网启动，此时应优先解决网络故障后再运营场站。 |
| 88 | 3）如果第1）中的场景发生，平台也支持对个别账单的数据修正，参考异常账单修复步骤纠正个别异常数据。 |
| 89 | |
| 90 | **（异常场景）技术细节** |
| 91 | bo希望能收到桩停止充电的状态来决定是否发送占桩消息。 |
| 92 | 1）用户扫码鉴权后，app端点了启动，但桩和车辆因 握手失败，充电启动失败，未拔枪。司机不知情离开，n小时候后回来，发现未充入电量、但收了N小时占桩费。空账单充电时长=0。 |
| 93 | 2）app端点了启动，桩成功启动，期间发了1一个故障 导致充电过程提前结束。 |
| 94 | ))) |
| 95 | |
| 96 | ~-~--解决 |
| 97 | |
| 98 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 99 | |
| 100 | 售后（跟单）工程师：施文俊 |
| 101 | |
| 102 | = function_case#18_20200317 = |
| 103 | |
| 104 | 系统单元：MC2.0 |
| 105 | 问题描述：监控小程序支持1个手机跨运营商登录 配置问题 |
| 106 | |
| 107 | ~-~--跟踪 |
| 108 | |
| 109 | (% class="box infomessage" %) |
| 110 | ((( |
| 111 | **背景：**参见[[jkr_case#33_20200317>>doc:技术.业务支撑.金凯瑞.WebHome]] |
| 112 | |
| 113 | 以金凯瑞账号为例，操作过程出现异常： |
| 114 | 1、新建 “jkr_super_admin”账号，对应角色“金凯瑞超级角色” |
| 115 | 2、jkr_super_admin创建过程只能选单个运营商，或保持默认（即所有） |
| 116 | 3、“金凯瑞超级角色”创建 选了 金凯瑞旗下多个运营商。 |
| 117 | \\结果： |
| 118 | 1、jkr_super_admin 登录 ，界面卡死loading。 |
| 119 | 2、jkr_super_admin 配置选择单个运营商“金凯瑞”、不选子运营商时报错。 |
| 120 | 3、疑问：“监控小程序支持1个手机跨运营商登录 配置” 是以角色还是账号中的运营商为主，后者只能配单个运营商。 |
| 121 | \\【john】：用户管理那里的运营商只是设置账号从属关系，数据显示以角色为准。 jkr_super_admin我设置了运营商为金凯瑞，登录没遇到你说的问题。站点人员(小程序)能看到的数据以绑定的运营商为准 |
| 122 | ))) |
| 123 | |
| 124 | ~-~--解决 |
| 125 | |
| 126 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 127 | |
| 128 | 售后（跟单）工程师：施文俊 |
| 129 | |
| 130 | = function_case#17_20200317 = |
| 131 | |
| 132 | 系统单元：微信端 h5 |
| 133 | 问题描述：部分场景soc显示不友好。 |
| 134 | |
| 135 | ~-~--跟踪 |
| 136 | |
| 137 | **背景：** |
| 138 | 微信终端桩状态关于soc显示的优化，包括以下场景： |
| 139 | 1、充电后占桩的soc显示优化： 。。。 |
| 140 | 2、启动充电前桩占桩时，SOC显示优化： 。。。 |
| 141 | |
| 142 | [[image:1584438663706-955.png]] |
| 143 | |
| 144 | ~-~--解决 |
| 145 | |
| 146 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 147 | |
| 148 | 售后（跟单）工程师：施文俊 |
| 149 | |
| 150 | |
| 151 | = function_case#16_20200304 = |
| 152 | |
| 153 | 系统单元：MC2.0 深圳德顺 |
| 154 | 问题描述：客户希望每个月只能退款一次，制定在每个月的28号，该信息显示在用户手机的退款页面上。 |
| 155 | |
| 156 | [[image:1583315527111-589.png||height="224" width="344"]][[image:1583315543931-173.png||height="428" width="214"]] |
| 157 | \\~-~--跟踪 |
| 158 | |
| 159 | 【产品】：把退款说明做成运营商级别自定义，但是还是能申请的，只是运营商说明每月固定时间审核 |
| 160 | |
| 161 | ~-~--解决 |
| 162 | |
| 163 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 164 | |
| 165 | 售后（跟单）工程师：chinyee |
| 166 | |
| 167 | |
| 168 | = function_case#15_20200303 = |
| 169 | |
| 170 | 系统单元：MC2.0 |
| 171 | 问题描述：完善在线退款入口权限配置 |
| 172 | ~-~--跟踪 |
| 173 | |
| 174 | (% class="box" %) |
| 175 | ((( |
| 176 | **【背景】：** |
| 177 | 1、独立bo客户拥有登录账户配置权，可以配置“全局设置管理”中 “退款手续费率”，当开启退款选项，微信端出现退款入口。（见图） |
| 178 | 2、因自动化退款是高级版功能，不能由客户自动控制。 |
| 179 | |
| 180 | [[image:1583210787973-129.png]] |
| 181 | |
| 182 | **【解决方案】：** |
| 183 | 1、紧急下线“退款手续费率”配置模块。 |
| 184 | 2、取消“自动化退款”（商务上未授权的，如：非高级版运营商） |
| 185 | 3、转产品 评估 完善功能。 |
| 186 | \\**【优先级】：较高** |
| 187 | 原因：紧急下线“退款手续费率”配置模块，客户无法自主调整退款费率等配置。 |
| 188 | ))) |
| 189 | |
| 190 | ~-~--解决 |
| 191 | |
| 192 | [[image:1583317444244-284.png||height="265" width="555"]] |
| 193 | |
| 194 | 【令技术】：平台退款审核页面，手续费显示为0，实际上应该要扣0.6%的手续费。导致这样的结果是因为德顺的数据库退款申请表缺少了手续费字段，估计是数据库版本有点问题，退款手续费没保存到。未审核的退款账单可以修复，已经审核了的账单不可修复，看是否有影响。 |
| 195 | |
| 196 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 197 | |
| 198 | 售后（跟单）工程师：施文俊 |
| 199 | |
| 200 | = function_case#14_20200117 = |
| 201 | |
| 202 | 系统单元：MC2.0 |
| 203 | 问题描述：mc2.0 删除站点的功能（当前不可用），需要增加的原因： |
| 204 | 1）客户建错站点，要删除，空桩数据，显示上不精确 |
| 205 | 2）引起互联互通同步了不该同步数据 |
| 206 | ~-~--跟踪 |
| 207 | 目前情况是： |
| 208 | 1、对于互联互通模式，有个不可见的设置，设置后，第三方运营商平台是看不到站点且启动不了充电。 |
| 209 | 2、自营方只能设置为关闭，关闭后用户端站点运营状态显示为关闭，但是去到站点如果有桩是能启动充电的。 |
| 210 | 3、通过1、2两点能暂时解决无用站点的数据问题。 |
| 211 | 4、我们还是不建议删除站点信息。所以我们重新确定了个站点状态方案，基本能满足可预见的情况 |
| 212 | |
| 213 | (% class="box" %) |
| 214 | ((( |
| 215 | [[image:1579232008611-525.png]] |
| 216 | ))) |
| 217 | |
| 218 | “设置后，第三方运营商平台是看不到站点”满足这点的话，可以不删。现在滴滴接入能看到未删站点. |
| 219 | igo跟滴滴、愉天跟极数充这种，滴滴跟极数充不是令狐充的平台，需要在jarvis去设置。这个“是否可见”只在令狐充saas之前生效。 |
| 220 | 展鹏达和滴滴之间 能满足就可以, 对外的都需要jarvis过滤 |
| 221 | 如果展鹏达自己也需要对这个设置错误的站点做错失，就是在mc把运营状态改为关闭 |
| 222 | 用户端会对应状态改为关闭 |
| 223 | |
| 224 | |
| 225 | ~-~--解决 |
| 226 | |
| 227 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 228 | |
| 229 | 售后（跟单）工程师：施文俊 |
| 230 | |
| 231 | = function_case#13_20200103 = |
| 232 | |
| 233 | 系统单元：MC2.0 南方众悦 |
| 234 | 问题描述：代金卷使用没有导出功能，主要是使用记录 要分析 能够导出在不同站点之间的成本核算啊。包括。这个客户哪些客户使用了多少张啊？这个数据都有对后期的一些作用。 |
| 235 | \\~-~--跟踪 |
| 236 | |
| 237 | ~-~--解决 |
| 238 | |
| 239 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 240 | |
| 241 | 售后（跟单）工程师：chinyee |
| 242 | |
| 243 | = function_case#12_20191223 = |
| 244 | |
| 245 | 系统单元：BO2.0 |
| 246 | |
| 247 | 问题描述：南方众悦 客户想给test（充电站值班室账号）开通修改的权限，给故障账单进行修正，同时可以看到会员管理的会员信息，但不想开放人工充值的权限。 |
| 248 | |
| 249 | [[image:1577072446290-882.png||height="236" width="568"]] |
| 250 | |
| 251 | ~-~-跟踪 |
| 252 | ~~update 20191224 |
| 253 | 增加了一个权限 |
| 254 | [[image:1577182019279-783.png]] |
| 255 | |
| 256 | [[image:file:///C:\Users\wenjun\Documents\Tencent Files\364781508\Image\C2C\{30077117-1933-24D5-8A01-0F76D7D8BBE8}.jpg]] |
| 257 | |
| 258 | = function_case#11_20191211 = |
| 259 | |
| 260 | 系统单元：BO2.0 |
| 261 | 问题描述：互联互通支持刷卡的测试（测试环境） |
| 262 | |
| 263 | ~-~--跟踪 |
| 264 | |
| 265 | 背景： |
| 266 | |
| 267 | 1、A运营商用户的卡在B运营商的桩上刷卡启动，B运营商解析卡号知道属于A运营商才会互联互通到A的boss，所以卡号一定要有A运营商id |
| 268 | 2、意味着卡号前4位必须和db中运营商ID一致。 |
| 269 | |
| 270 | |
| 271 | |
| 272 | 测试摘要： |
| 273 | 1、互联互通刷卡充电，已经更新到测试环境 https:~/~/mc-uat.linghuchongtech.com，需用办公室交流桩做刷卡测试。 |
| 274 | 2、将一台支持刷卡的桩（A）迁移到“内部集成运营商”下站点“互联互通测试”。 |
| 275 | [[image:1576027922341-911.png]] |
| 276 | 3、ubidy用户在测试环境中对应运营商id为2, 即，卡号为0002xxxxxxxxxxxx。 |
| 277 | 4、协助发一张测试卡供 互联互通测试。【请moln协助】 卡号为：0002 0000 0001 0032 |
| 278 | 5、将新发卡片绑定至ubidy其中账户，用新卡刷桩A，记录测试用例和结果。 |
| 279 | |
| 280 | = = |
| 281 | |
| 282 | = function_case#10_20191209 = |
| 283 | |
| 284 | 系统单元：MC2.0 |
| 285 | 问题描述：发票模式从按充值改为按消费开票，产生的遗留问题。 |
| 286 | |
| 287 | ~-~--跟踪 |
| 288 | 我们现在提供了一种切换机制：引入发票遗留金概念 |
| 289 | \\发票遗留金：由于系统开票规则由按充值开票升级为按消费开票，在切换日2019年x月x日 xx:xx前①已消费未开票 ②已开票未消费 的金额称为发票遗留金。 |
| 290 | \\1、已消费未开出发票： |
| 291 | ①在切换日后的首次开发票时，会补开该部分金额的发票。 |
| 292 | ②当选择开票的消费金额+发票遗留金≥最低可开票金额时，可申请开票。 |
| 293 | ③实际开出发票金额=选择开票的消费金额+发票遗留金 |
| 294 | \\2、已开出票未消费： |
| 295 | ①在切换日后的首次开发票时，需扣减发票遗留金。 |
| 296 | ②当选择开票的消费金额-发票遗留金≥最低可开票金额时，可申请开票。 |
| 297 | ③实际开出发票金额=选择开票的消费金额-发票遗留金 |
| 298 | \\注：赠款部分不可开发票。 |
| 299 | 看客户是否采用，如果不采用，就需要他们引入运营资源去处理，处理完后通知我们进行切换 |
| 300 | [[image:1575861008265-279.png]] |
| 301 | 发票遗留金功能已经上线了的 |
| 302 | |
| 303 | |
| 304 | = function_case#9_20191206 = |
| 305 | |
| 306 | 系统单元：MC2.0 |
| 307 | 问题描述：代金券券支持服务费模式（中山平实等挂靠令狐充模式要求） |
| 308 | ~-~--跟踪 |
| 309 | **包含两大类：** |
| 310 | **一、挂靠模式需考虑的功能点：** |
| 311 | 1.1、财务对账结算的影响 |
| 312 | 1.2、充值时未标注代金券适用站点， 也需考虑用户充值时 系统给出 “代金券仅试用指定站点” 类似提示。 |
| 313 | \\**二、代金券支持仅抵扣服务费** |
| 314 | 2.1、产品已计划的改动：设置代金券时，增加一个抵扣适用选择，是消费总额or服务费。【预计12.30完成】 |
| 315 | 2.2、产品未计划的改动：终端UI如微信，如仅抵扣服务费类型，可能需要充值界面金额增加类似提示“此券仅抵扣服务费”。（标记不明确可能产生纠纷,）。【此项请评估工作量是否可和1一起完成】 |
| 316 | |
| 317 | ~~update 20191211 |
| 318 | 1、客户已知悉第二项中功能需要改动后支持。 |
| 319 | 客户希望12.12日做代金券活动。愿意先用总费用抵扣模式，但平台也需先实现1.2中功能 才能提供挂靠客户使用，请评估可行性。（目前已经支持指定站点使用，不过前端需要增加提示显示） |
| 320 | 2、更新新的活动，见[[attach:1_中山12月营销计划.docx||target="_blank"]] |
| 321 | |
| 322 | ~-~--解决 |
| 323 | |
| 324 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 325 | |
| 326 | 售后（跟单）工程师：施文俊 |
| 327 | |
| 328 | = = |
| 329 | |
| 330 | = function_case#8_20191126 = |
| 331 | |
| 332 | 系统单元：bo2.0，刷卡 |
| 333 | |
| 334 | 问题描述： 云卡打印卡号20位，实际系统传输到平台是16位，见下图。 |
| 335 | 示例： |
| 336 | 00010000000000000013 |
| 337 | 0001000000000013 |
| 338 | 原因： |
| 339 | 印刷写卡错误，这批卡号到1000 |
| 340 | 解决： |
| 341 | 给客户配置可以按16位处理 |
| 342 | [[image:1574738028559-110.png]] |
| 343 | |
| 344 | = function_case#7_20191119 = |
| 345 | |
| 346 | 系统单元：MC2.0 |
| 347 | |
| 348 | 问题描述：充电网络/充电站管理 电价计费设置内选择”直流分时充电计费“时，不熟悉平台的客户会优先看到显示的”交流桩电价“和”交流桩服务费“而忽视下面定价时段的电价及服务费，认为计费设置不合理。 |
| 349 | |
| 350 | (% class="box infomessage" %) |
| 351 | ((( |
| 352 | 定价时段内的电价及服务费需要加上”直流桩“几个字，让客户对价格设置能明确理解。（”交流分时充电计费“同理） |
| 353 | [[image:1574404666962-644.png]] |
| 354 | ))) |
| 355 | |
| 356 | ~-~--跟踪 |
| 357 | |
| 358 | ~-~--解决 |
| 359 | |
| 360 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 361 | |
| 362 | 售后（跟单）工程师：施文俊 chinyee YD |
| 363 | |
| 364 | = function_case#6_20191104 = |
| 365 | |
| 366 | 系统单元：MC2.0 令狐充运营商 |
| 367 | 问题描述：筛选查询 中 审核时间条件 疑似 不合理，描述见下： |
| 368 | 1、客户于2019-11-1 申请在线退款，当前为未审核状态。 |
| 369 | 2、进入“首页/客户管理/会员管理/退款审核管理”，筛选条件中申请时间 选 2019-10-30至2019-11-5，审核日期保持初始默认，查询结果为空。（预期有数据） |
| 370 | 3、补充 额外 筛选条件中审核日期 选 2019-10-30至2019-11-5，可以查得待审核数据。（未审核状态单子 是否不需要 选审核日期） |
| 371 | ~-~--跟踪 |
| 372 | |
| 373 | ~-~--解决 |
| 374 | |
| 375 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 376 | |
| 377 | 售后（跟单）工程师：施文俊 |
| 378 | |
| 379 | = = |
| 380 | |
| 381 | = function_case#5_20191015 = |
| 382 | |
| 383 | ~-~-~-~-~-~-- |
| 384 | 问题描述：“首页/客户管理/会员管理/会员管理”，因mc2.0计划保留站点管理员密码充电，此处需参照bo1.0，支持管理员创建虚拟“站点管理员”，可自行命名管理员名称， 用于强可读性的和站点进行绑定。 |
| 385 | ~-~--跟踪 |
| 386 | |
| 387 | ~-~--解决 |
| 388 | |
| 389 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 390 | |
| 391 | 售后（跟单）工程师：施文俊 |
| 392 | |
| 393 | |
| 394 | = function_case#4_20191014 = |
| 395 | |
| 396 | poweredby升级时会涉及到一个账号切换问题： |
| 397 | 1）2.0是以是否有操作权限区分了两批人，超级管理员和普通操作员。 |
| 398 | 2）3.0是以权限划分了三个身份：管理层-可查看业务营收数据，不可进行桩站设置；运维-不可查看业务营收数据，可进行桩站设置；监控人员：不可查看业务营收数据，不可进行桩站设置。 |
| 399 | 3）业务营收数据：营收、电费、服务费。 |
| 400 | 4）切换时，需要给原来的账号对应新角色。系统会自动将原来的普通操作员账号角色换为监控人员；超级管理员账号角色换为管理层。 |
| 401 | 5）需运营协助提前告知客户，及时针对实际情况修改账号角色。 |
| 402 | 产品部提供一份功能介绍文档，供客户查阅。 |
| 403 | |
| 404 | |
| 405 | = function_case#3_20191008 = |
| 406 | |
| 407 | |
| 408 | ~-~-~-~-~-~-- |
| 409 | 问题描述：igo充电记录导出表格，希望可以加上会员昵称这一项（在平台有这一项显示）。 |
| 410 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- |
| 411 | 运营商初步排查结果： |
| 412 | \\~-~--分析 |
| 413 | |
| 414 | |
| 415 | ~-~--解决 |
| 416 | |
| 417 | 状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置 |
| 418 | |
| 419 | 售后（跟单）工程师：施文俊 何倩怡 |
| 420 | |
| 421 | |
| 422 | = function_case#2_20190923 = |
| 423 | |
| 424 | |
| 425 | ~-~-~-~-~-~-- |
| 426 | 问题描述：谷歌浏览器 链接：[[https:~~/~~/mc.linghuchongtech.com>>url:https://mc.linghuchongtech.com/]] 账号：lhc_hyd ，点击"充电桩管理/概览"会跳转到登录界面并需要重新登陆，尝试多次结果一样。 |
| 427 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- |
| 428 | 运营商初步排查结果： |
| 429 | \\~-~--分析 |
| 430 | |
| 431 | 无法重现 |
| 432 | \\~-~--解决 |
| 433 | |
| 434 | 状态（√表示选定 ）： 已解决 | 处理中 | √ 暂搁置 |
| 435 | |
| 436 | 售后（跟单）工程师：施文俊 |
| 437 | |
| 438 | |
| 439 | = function_case#1_20190912 = |
| 440 | |
| 441 | |
| 442 | 关于平台账单中“异常”的可靠性问题及如何在业务层面提供辅助信息补充说明的问题的讨论及建议: |
| 443 | \\1、Dynamic：在平台账单中增加一个标注, 该标志用于标识“平台账单”的可靠性,如发生像离线后在线但充电已结束，则会标识为不可靠, 且在不可靠上区分不同原因, 可扩展且在运营过程中根据实际发生的场景进行补充; |
| 444 | 2、BOSS: |
| 445 | 2.1、利用新增的“可靠性”标识, 决定是否产生异常账单提示; |
| 446 | 2.2、在异常账单中提供辅助信息查询, 可能包括(但不限于)：离线时间,故障时间,故障原因等。 |
| 447 | 大家看看，是否可行及建议。 |
| 448 | |
| 449 | |
| 450 | 4分钟问题，应该是之前考虑用户体验的要求修改的， 之前是15分钟. |
| 451 | |
| 452 | ~-~- |
| 453 | |
| 454 | 售后（跟单）工程师：施文俊 |