文档更改迭代

在2020/04/21 14:30上被yuandong he修改
从版本< 2.1 >
由chinyee he编辑
在2019/10/08 15:25上
到版本
由shi chuck编辑
在2019/12/11 13:01上
< >
修改评论 该版本没有评论

Summary

Details

Page properties
文档作者
... ... @@ -1,1 +1,1 @@
1 -XWiki.Chinyee
1 +XWiki.ShiChuck
Content
... ... @@ -2,10 +2,157 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 -= funcation_case#3_20191008 =
5 += function_case#11_20191211 =
6 6  
7 +系统单元：BO2.0
8 +问题描述：互联互通支持刷卡的测试（测试环境）
7 7  
10 +~-~--跟踪
11 +
12 +背景：\\
13 +
14 +1、A运营商用户的卡在B运营商的桩上刷卡启动，B运营商解析卡号知道属于A运营商才会互联互通到A的boss，所以卡号一定要有A运营商id
15 +2、意味着卡号前4位必须和db中运营商ID一致。
16 +
17 +
18 +
19 +测试摘要：
20 +1、互联互通刷卡充电，已经更新到测试环境 https:~/~/mc-uat.linghuchongtech.com，需用办公室交流桩做刷卡测试。
21 +2、将一台支持刷卡的桩（A）迁移到“内部集成运营商”下站点“互联互通测试”。
22 +[[image:1576027922341-911.png]]
23 +3、ubidy用户在测试环境中对应运营商id为2, 即，卡号为0002xxxxxxxxxxxx。
24 +4、协助发一张测试卡供 互联互通测试。【请moln协助】
25 +5、将新发卡片绑定至ubidy其中账户，用新卡刷桩A，记录测试用例和结果。
26 +
27 +(% class="wikigeneratedid" %)
28 += =
29 +
30 += function_case#10_20191209 =
31 +
32 +系统单元：MC2.0 
33 +问题描述：发票模式从按充值改为按消费开票，产生的遗留问题。
34 +
35 +~-~--跟踪
36 +我们现在提供了一种切换机制：引入发票遗留金概念
37 +\\发票遗留金：由于系统开票规则由按充值开票升级为按消费开票，在切换日2019年x月x日 xx:xx前①已消费未开票 ②已开票未消费  的金额称为发票遗留金。
38 +\\1、已消费未开出发票：
39 +①在切换日后的首次开发票时，会补开该部分金额的发票。
40 +②当选择开票的消费金额+发票遗留金≥最低可开票金额时，可申请开票。
41 +③实际开出发票金额=选择开票的消费金额+发票遗留金
42 +\\2、已开出票未消费：
43 +①在切换日后的首次开发票时，需扣减发票遗留金。
44 +②当选择开票的消费金额-发票遗留金≥最低可开票金额时，可申请开票。
45 +③实际开出发票金额=选择开票的消费金额-发票遗留金
46 +\\注：赠款部分不可开发票。
47 +看客户是否采用，如果不采用，就需要他们引入运营资源去处理，处理完后通知我们进行切换
48 +[[image:1575861008265-279.png]]
49 +发票遗留金功能已经上线了的
50 +
51 +
52 += function_case#9_20191206 =
53 +
54 +系统单元：MC2.0 
55 +问题描述：代金券券支持服务费模式（中山平实等挂靠令狐充模式要求）
56 +~-~--跟踪
57 +**包含两大类：**
58 +**一、挂靠模式需考虑的功能点：**
59 + 1.1、财务对账结算的影响
60 + 1.2、充值时未标注代金券适用站点， 也需考虑用户充值时 系统给出 “代金券仅试用指定站点” 类似提示。
61 +\\**二、代金券支持仅抵扣服务费**
62 + 2.1、产品已计划的改动：设置代金券时，增加一个抵扣适用选择，是消费总额or服务费。【预计12.30完成】
63 + 2.2、产品未计划的改动：终端UI如微信，如仅抵扣服务费类型，可能需要充值界面金额增加类似提示“此券仅抵扣服务费”。（标记不明确可能产生纠纷,）。【此项请评估工作量是否可和1一起完成】
64 +
65 +~~update 20191211
66 +客户已知悉第二项中功能需要改动后支持。
67 +客户希望12.12日做代金券活动。愿意先用总费用抵扣模式，但平台也需先实现1.2中功能 才能提供挂靠客户使用，请评估可行性。（目前已经支持指定站点使用，不过前端需要增加提示显示）
68 +
69 +~-~--解决
70 +
71 +状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置
72 +
73 +售后（跟单）工程师：施文俊
74 +
75 += =
76 +
77 += function_case#8_20191126 =
78 +
79 +系统单元：bo2.0，刷卡
80 +
81 +问题描述： 云卡打印卡号20位，实际系统传输到平台是16位，见下图。
82 +示例：
83 +00010000000000000013
84 +0001000000000013
85 +原因：
86 +印刷写卡错误，这批卡号到1000
87 +解决：
88 +给客户配置可以按16位处理
89 +[[image:1574738028559-110.png]]
90 +
91 += function_case#7_20191119 =
92 +
93 +系统单元：MC2.0
94 +
95 +问题描述：充电网络/充电站管理 电价计费设置内选择”直流分时充电计费“时，不熟悉平台的客户会优先看到显示的”交流桩电价“和”交流桩服务费“而忽视下面定价时段的电价及服务费，认为计费设置不合理。
96 +
97 +(% class="box infomessage" %)
98 +(((
99 +定价时段内的电价及服务费需要加上”直流桩“几个字，让客户对价格设置能明确理解。（”交流分时充电计费“同理）
100 +[[image:1574404666962-644.png]]
101 +)))
102 +
103 +~-~--跟踪
104 +
105 +~-~--解决
106 +
107 +状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置
108 +
109 +售后（跟单）工程师：施文俊 chinyee YD
110 +
111 += function_case#6_20191104 =
112 +
113 +系统单元：MC2.0 令狐充运营商
114 +问题描述：筛选查询 中  审核时间条件  疑似 不合理，描述见下：
115 +1、客户于2019-11-1 申请在线退款，当前为未审核状态。
116 +2、进入“首页/客户管理/会员管理/退款审核管理”，筛选条件中申请时间 选 2019-10-30至2019-11-5，审核日期保持初始默认，查询结果为空。（预期有数据）
117 +3、补充 额外 筛选条件中审核日期 选 2019-10-30至2019-11-5，可以查得待审核数据。（未审核状态单子 是否不需要 选审核日期）
118 +~-~--跟踪
119 +
120 +~-~--解决
121 +
122 +状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置
123 +
124 +售后（跟单）工程师：施文俊
125 +
126 += =
127 +
128 += function_case#5_20191015 =
129 +
8 8  ~-~-~-~-~-~--
131 +问题描述：“首页/客户管理/会员管理/会员管理”，因mc2.0计划保留站点管理员密码充电，此处需参照bo1.0，支持管理员创建虚拟“站点管理员”，可自行命名管理员名称， 用于强可读性的和站点进行绑定。
132 +~-~--跟踪
133 +
134 +~-~--解决
135 +
136 +状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置
137 +
138 +售后（跟单）工程师：施文俊
139 +
140 +
141 += function_case#4_20191014 =
142 +
143 +poweredby升级时会涉及到一个账号切换问题：
144 +1）2.0是以是否有操作权限区分了两批人，超级管理员和普通操作员。
145 +2）3.0是以权限划分了三个身份：管理层-可查看业务营收数据，不可进行桩站设置；运维-不可查看业务营收数据，可进行桩站设置；监控人员：不可查看业务营收数据，不可进行桩站设置。
146 +3）业务营收数据：营收、电费、服务费。
147 +4）切换时，需要给原来的账号对应新角色。系统会自动将原来的普通操作员账号角色换为监控人员；超级管理员账号角色换为管理层。
148 +5）需运营协助提前告知客户，及时针对实际情况修改账号角色。
149 +产品部提供一份功能介绍文档，供客户查阅。
150 +
151 +
152 += function_case#3_20191008 =
153 +
154 +
155 +~-~-~-~-~-~--
9 9  问题描述：igo充电记录导出表格，希望可以加上会员昵称这一项（在平台有这一项显示）。
10 10  ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~--
11 11  运营商初步排查结果：
... ... @@ -12,16 +12,14 @@
12 12  \\~-~--分析
13 13  
14 14  
15 -\\~-~--解决
162 +~-~--解决
16 16  
17 17  状态（√表示选定 ）： 已解决 | √处理中 | 暂搁置
18 18  
19 19  售后（跟单）工程师：施文俊  何倩怡
20 20  
21 -(% class="wikigeneratedid" %)
22 -= =
23 23  
24 -= funcation_case#2_20190923 =
169 += function_case#2_20190923 =
25 25  
26 26  
27 27  ~-~-~-~-~-~--
... ... @@ -37,9 +37,8 @@
37 37  
38 38  售后（跟单）工程师：施文俊
39 39  
40 -= =
41 41  
42 -= funcation_case#1_20190912 =
186 += function_case#1_20190912 =
43 43  
44 44  
45 45  关于平台账单中“异常”的可靠性问题及如何在业务层面提供辅助信息补充说明的问题的讨论及建议:
... ... @@ -55,5 +55,3 @@
55 55  ~-~-
56 56  
57 57  售后（跟单）工程师：施文俊
58 -
59 -
1574404652323-218.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +96.8 KB
Content
1574404666962-644.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +96.8 KB
Content
1574738028559-110.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +397.4 KB
Content
1575861008265-279.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +88.7 KB
Content
1576027922341-911.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +9.4 KB
Content