从版本< 12.1 >
chinyee he编辑
在2020/01/03 14:12上
到版本
shi chuck编辑
在2019/11/26 11:16上
< >
修改评论 该版本没有评论

Summary

Details

Page properties
文档作者
... ... @@ -1,1 +1,1 @@
1 -XWiki.Chinyee
1 +XWiki.ShiChuck
Content
... ... @@ -2,106 +2,6 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 -= function_case#13_20200103 =
6 -
7 -系统单元:MC2.0 南方众悦
8 -问题描述:代金卷使用没有导出功能,主要是使用记录 要分析
9 -\\~-~--跟踪
10 -
11 -~-~--解决
12 -
13 -状态(√表示选定 ): 已解决 | √处理中 | 暂搁置
14 -
15 -售后(跟单)工程师:chinyee
16 -
17 -
18 -= function_case#12_20191223 =
19 -
20 -系统单元:BO2.0
21 -
22 -问题描述:南方众悦 客户想给test(充电站值班室账号)开通修改的权限,给故障账单进行修正,同时可以看到会员管理的会员信息,但不想开放人工充值的权限。
23 -
24 -[[image:1577072446290-882.png||height="236" width="568"]]
25 -
26 -~-~-跟踪
27 -~~update 20191224
28 -增加了一个权限
29 -[[image:1577182019279-783.png]]
30 -
31 -[[image:file:///C:\Users\wenjun\Documents\Tencent Files\364781508\Image\C2C\{30077117-1933-24D5-8A01-0F76D7D8BBE8}.jpg]]
32 -
33 -= function_case#11_20191211 =
34 -
35 -系统单元:BO2.0
36 -问题描述:互联互通支持刷卡的测试(测试环境)
37 -
38 -~-~--跟踪
39 -
40 -背景:
41 -
42 -1、A运营商用户的卡在B运营商的桩上刷卡启动,B运营商解析卡号知道属于A运营商才会互联互通到A的boss,所以卡号一定要有A运营商id
43 -2、意味着卡号前4位必须和db中运营商ID一致。
44 -
45 -
46 -
47 -测试摘要:
48 -1、互联互通刷卡充电,已经更新到测试环境 https:~/~/mc-uat.linghuchongtech.com,需用办公室交流桩做刷卡测试。
49 -2、将一台支持刷卡的桩(A)迁移到“内部集成运营商”下站点“互联互通测试”。
50 -[[image:1576027922341-911.png]]
51 -3、ubidy用户在测试环境中对应运营商id为2, 即,卡号为0002xxxxxxxxxxxx。
52 -4、协助发一张测试卡供 互联互通测试。【请moln协助】  卡号为:0002 0000 0001 0032
53 -5、将新发卡片绑定至ubidy其中账户,用新卡刷桩A,记录测试用例和结果。
54 -
55 -= =
56 -
57 -= function_case#10_20191209 =
58 -
59 -系统单元:MC2.0 
60 -问题描述:发票模式从按充值改为按消费开票,产生的遗留问题。
61 -
62 -~-~--跟踪
63 -我们现在提供了一种切换机制:引入发票遗留金概念
64 -\\发票遗留金:由于系统开票规则由按充值开票升级为按消费开票,在切换日2019年x月x日 xx:xx前①已消费未开票 ②已开票未消费  的金额称为发票遗留金。
65 -\\1、已消费未开出发票:
66 -①在切换日后的首次开发票时,会补开该部分金额的发票。
67 -②当选择开票的消费金额+发票遗留金≥最低可开票金额时,可申请开票。
68 -③实际开出发票金额=选择开票的消费金额+发票遗留金
69 -\\2、已开出票未消费:
70 -①在切换日后的首次开发票时,需扣减发票遗留金。
71 -②当选择开票的消费金额-发票遗留金≥最低可开票金额时,可申请开票。
72 -③实际开出发票金额=选择开票的消费金额-发票遗留金
73 -\\注:赠款部分不可开发票。
74 -看客户是否采用,如果不采用,就需要他们引入运营资源去处理,处理完后通知我们进行切换
75 -[[image:1575861008265-279.png]]
76 -发票遗留金功能已经上线了的
77 -
78 -
79 -= function_case#9_20191206 =
80 -
81 -系统单元:MC2.0 
82 -问题描述:代金券券支持服务费模式(中山平实等挂靠令狐充模式要求)
83 -~-~--跟踪
84 -**包含两大类:**
85 -**一、挂靠模式需考虑的功能点:**
86 - 1.1、财务对账结算的影响
87 - 1.2、充值时未标注代金券适用站点, 也需考虑用户充值时 系统给出 “代金券仅试用指定站点” 类似提示。
88 -\\**二、代金券支持仅抵扣服务费**
89 - 2.1、产品已计划的改动:设置代金券时,增加一个抵扣适用选择,是消费总额or服务费。【预计12.30完成】
90 - 2.2、产品未计划的改动:终端UI如微信,如仅抵扣服务费类型,可能需要充值界面金额增加类似提示“此券仅抵扣服务费”。(标记不明确可能产生纠纷,)。【此项请评估工作量是否可和1一起完成】
91 -
92 -~~update 20191211
93 -1、客户已知悉第二项中功能需要改动后支持。
94 -客户希望12.12日做代金券活动。愿意先用总费用抵扣模式,但平台也需先实现1.2中功能 才能提供挂靠客户使用,请评估可行性。(目前已经支持指定站点使用,不过前端需要增加提示显示)
95 -2、更新新的活动,见[[attach:1_中山12月营销计划.docx||target="_blank"]]
96 -
97 -~-~--解决
98 -
99 -状态(√表示选定 ): 已解决 | √处理中 | 暂搁置
100 -
101 -售后(跟单)工程师:施文俊
102 -
103 -= =
104 -
105 105  = function_case#8_20191126 =
106 106  
107 107  系统单元:bo2.0,刷卡
... ... @@ -110,12 +110,9 @@
110 110  示例:
111 111  00010000000000000013
112 112  0001000000000013
113 -原因:
114 -印刷写卡错误,这批卡号到1000
115 -解决:
116 -给客户配置可以按16位处理
117 117  [[image:1574738028559-110.png]]
118 118  
15 +
119 119  = function_case#7_20191119 =
120 120  
121 121  系统单元:MC2.0
1575861008265-279.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ShiChuck
Size
... ... @@ -1,1 +1,0 @@
1 -88.7 KB
Content
1576027922341-911.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ShiChuck
Size
... ... @@ -1,1 +1,0 @@
1 -9.4 KB
Content
1577072446290-882.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.Chinyee
Size
... ... @@ -1,1 +1,0 @@
1 -16.1 KB
Content
1577182019279-783.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ShiChuck
Size
... ... @@ -1,1 +1,0 @@
1 -88.7 KB
Content
1_中山12月营销计划.docx
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ShiChuck
Size
... ... @@ -1,1 +1,0 @@
1 -22.8 KB
Content