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