function_case#15_20200303

系统单元：MC2.0 
问题描述：完善在线退款入口权限配置
---跟踪

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊

function_case#14_20200117

系统单元：MC2.0 
问题描述：mc2.0 删除站点的功能（当前不可用），需要增加的原因：
  1）客户建错站点，要删除，空桩数据，显示上不精确
  2）引起互联互通同步了不该同步数据
---跟踪
目前情况是：
1、对于互联互通模式，有个不可见的设置，设置后，第三方运营商平台是看不到站点且启动不了充电。
2、自营方只能设置为关闭，关闭后用户端站点运营状态显示为关闭，但是去到站点如果有桩是能启动充电的。
3、通过1、2两点能暂时解决无用站点的数据问题。
4、我们还是不建议删除站点信息。所以我们重新确定了个站点状态方案，基本能满足可预见的情况

“设置后，第三方运营商平台是看不到站点”满足这点的话，可以不删。现在滴滴接入能看到未删站点.
igo跟滴滴、愉天跟极数充这种，滴滴跟极数充不是令狐充的平台，需要在jarvis去设置。这个“是否可见”只在令狐充saas之前生效。
展鹏达和滴滴之间 能满足就可以, 对外的都需要jarvis过滤
如果展鹏达自己也需要对这个设置错误的站点做错失，就是在mc把运营状态改为关闭
用户端会对应状态改为关闭

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊

function_case#13_20200103

系统单元：MC2.0 南方众悦
问题描述：代金卷使用没有导出功能，主要是使用记录 要分析 能够导出在不同站点之间的成本核算啊。包括。这个客户哪些客户使用了多少张啊？这个数据都有对后期的一些作用。

---跟踪

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：chinyee

function_case#12_20191223

系统单元：BO2.0

问题描述：南方众悦 客户想给test（充电站值班室账号）开通修改的权限，给故障账单进行修正，同时可以看到会员管理的会员信息，但不想开放人工充值的权限。

--跟踪
~update 20191224
增加了一个权限

function_case#11_20191211

系统单元：BO2.0
问题描述：互联互通支持刷卡的测试（测试环境）

---跟踪

背景：

1、A运营商用户的卡在B运营商的桩上刷卡启动，B运营商解析卡号知道属于A运营商才会互联互通到A的boss，所以卡号一定要有A运营商id
2、意味着卡号前4位必须和db中运营商ID一致。

测试摘要：
1、互联互通刷卡充电，已经更新到测试环境 https://mc-uat.linghuchongtech.com，需用办公室交流桩做刷卡测试。
2、将一台支持刷卡的桩（A）迁移到“内部集成运营商”下站点“互联互通测试”。

3、ubidy用户在测试环境中对应运营商id为2, 即，卡号为0002xxxxxxxxxxxx。
4、协助发一张测试卡供 互联互通测试。【请moln协助】  卡号为：0002 0000 0001 0032
5、将新发卡片绑定至ubidy其中账户，用新卡刷桩A，记录测试用例和结果。

function_case#10_20191209

系统单元：MC2.0 
问题描述：发票模式从按充值改为按消费开票，产生的遗留问题。

---跟踪
我们现在提供了一种切换机制：引入发票遗留金概念

发票遗留金：由于系统开票规则由按充值开票升级为按消费开票，在切换日2019年x月x日 xx:xx前①已消费未开票 ②已开票未消费  的金额称为发票遗留金。

1、已消费未开出发票：
①在切换日后的首次开发票时，会补开该部分金额的发票。
②当选择开票的消费金额+发票遗留金≥最低可开票金额时，可申请开票。
③实际开出发票金额=选择开票的消费金额+发票遗留金

2、已开出票未消费：
①在切换日后的首次开发票时，需扣减发票遗留金。
②当选择开票的消费金额-发票遗留金≥最低可开票金额时，可申请开票。
③实际开出发票金额=选择开票的消费金额-发票遗留金

注：赠款部分不可开发票。
看客户是否采用，如果不采用，就需要他们引入运营资源去处理，处理完后通知我们进行切换

发票遗留金功能已经上线了的

function_case#9_20191206

系统单元：MC2.0 
问题描述：代金券券支持服务费模式（中山平实等挂靠令狐充模式要求）
---跟踪
包含两大类：
一、挂靠模式需考虑的功能点：
    1.1、财务对账结算的影响
    1.2、充值时未标注代金券适用站点， 也需考虑用户充值时 系统给出 “代金券仅试用指定站点” 类似提示。

二、代金券支持仅抵扣服务费
    2.1、产品已计划的改动：设置代金券时，增加一个抵扣适用选择，是消费总额or服务费。【预计12.30完成】
    2.2、产品未计划的改动：终端UI如微信，如仅抵扣服务费类型，可能需要充值界面金额增加类似提示“此券仅抵扣服务费”。（标记不明确可能产生纠纷,）。【此项请评估工作量是否可和1一起完成】

~update 20191211
1、客户已知悉第二项中功能需要改动后支持。
客户希望12.12日做代金券活动。愿意先用总费用抵扣模式，但平台也需先实现1.2中功能 才能提供挂靠客户使用，请评估可行性。（目前已经支持指定站点使用，不过前端需要增加提示显示）
2、更新新的活动，见1_中山12月营销计划.docx

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊

function_case#8_20191126

系统单元：bo2.0，刷卡

问题描述： 云卡打印卡号20位，实际系统传输到平台是16位，见下图。
示例：
00010000000000000013
0001000000000013
原因：
印刷写卡错误，这批卡号到1000
解决：
给客户配置可以按16位处理

function_case#7_20191119

系统单元：MC2.0

问题描述：充电网络/充电站管理 电价计费设置内选择”直流分时充电计费“时，不熟悉平台的客户会优先看到显示的”交流桩电价“和”交流桩服务费“而忽视下面定价时段的电价及服务费，认为计费设置不合理。

---跟踪

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊 chinyee YD

function_case#6_20191104

系统单元：MC2.0 令狐充运营商
问题描述：筛选查询 中  审核时间条件  疑似 不合理，描述见下：
1、客户于2019-11-1 申请在线退款，当前为未审核状态。
2、进入“首页/客户管理/会员管理/退款审核管理”，筛选条件中申请时间 选 2019-10-30至2019-11-5，审核日期保持初始默认，查询结果为空。（预期有数据）
3、补充 额外 筛选条件中审核日期 选 2019-10-30至2019-11-5，可以查得待审核数据。（未审核状态单子 是否不需要 选审核日期）
---跟踪

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊

function_case#5_20191015

-------
问题描述：“首页/客户管理/会员管理/会员管理”，因mc2.0计划保留站点管理员密码充电，此处需参照bo1.0，支持管理员创建虚拟“站点管理员”，可自行命名管理员名称， 用于强可读性的和站点进行绑定。
---跟踪

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊

function_case#4_20191014

poweredby升级时会涉及到一个账号切换问题：
1）2.0是以是否有操作权限区分了两批人，超级管理员和普通操作员。
2）3.0是以权限划分了三个身份：管理层-可查看业务营收数据，不可进行桩站设置；运维-不可查看业务营收数据，可进行桩站设置；监控人员：不可查看业务营收数据，不可进行桩站设置。
3）业务营收数据：营收、电费、服务费。
4）切换时，需要给原来的账号对应新角色。系统会自动将原来的普通操作员账号角色换为监控人员；超级管理员账号角色换为管理层。
5）需运营协助提前告知客户，及时针对实际情况修改账号角色。
产品部提供一份功能介绍文档，供客户查阅。

function_case#3_20191008

-------
问题描述：igo充电记录导出表格，希望可以加上会员昵称这一项（在平台有这一项显示）。
-------------------------
运营商初步排查结果：

---分析

---解决

状态（√表示选定 ）：  已解决  |  √处理中  |  暂搁置

售后（跟单）工程师：施文俊  何倩怡

function_case#2_20190923

-------
问题描述：谷歌浏览器 链接：https://mc.linghuchongtech.com 账号：lhc_hyd ，点击"充电桩管理/概览"会跳转到登录界面并需要重新登陆，尝试多次结果一样。
-------------------------
运营商初步排查结果：

---分析

无法重现

---解决

状态（√表示选定 ）：  已解决  |  处理中  | √ 暂搁置

售后（跟单）工程师：施文俊

function_case#1_20190912

关于平台账单中“异常”的可靠性问题及如何在业务层面提供辅助信息补充说明的问题的讨论及建议:

1、Dynamic：在平台账单中增加一个标注, 该标志用于标识“平台账单”的可靠性,如发生像离线后在线但充电已结束，则会标识为不可靠, 且在不可靠上区分不同原因, 可扩展且在运营过程中根据实际发生的场景进行补充;
2、BOSS: 
2.1、利用新增的“可靠性”标识, 决定是否产生异常账单提示;
2.2、在异常账单中提供辅助信息查询, 可能包括(但不限于)：离线时间,故障时间,故障原因等。
大家看看，是否可行及建议。

4分钟问题，应该是之前考虑用户体验的要求修改的， 之前是15分钟.

--

售后（跟单）工程师：施文俊