修改评论 Edited comment
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -1,32 +1,26 @@ 1 -= nfzy_requirement# 2_20200103=1 += nfzy_requirement#1_20190928 = 2 2 3 3 **需求背景**： 4 4 5 -代金卷使用查询导出功能，主要是使用记录 要分析 能够导出在不同站点之间的成本核算。包括：哪些客户使用了多少张啊？这个数据都有对后期的一些作用。 5 +（值班室）的场景： 6 +站点A绑定了值班室人员（子运营商A）， 公交车绑定了子运营商B， 那么子运营商B能看到公交车的充电，值班室人员（子运营商A）能看到站点A 所有的的充电数据。 6 6 7 -**优先级： 待定**8 +**优先级： 高** 8 8 9 -**需求分类**（“☑”代表选定） 10 - 11 -☑ 界面 12 - 13 -☑ 功能 14 - 15 -**详细： ** 16 - 17 17 **项目轨迹：** 18 18 19 -20 20-1-3需求。 需求较粗，可能需细分到具体功能点。12 +2019-9-28 陈佳提出 20 20 21 - = nfzy_requirement#1_20190928=14 +2019-9-28 功能分析（公司内部） 22 22 23 -**需求背景**： 16 +(% class="box infomessage" %) 17 +((( 18 +【令】：值班室 账号绑定单站点，不绑定子运营商，只应用到充电记录界面（看到此站点所有充电记录） 19 +【客户】：确认同意 20 +【令】：仅bo1.0 ，预计9.30日周一完成改动，可部署。 21 +))) 24 24 25 -（值班室）的场景： 26 -站点A绑定了值班室人员（子运营商A）， 公交车绑定了子运营商B， 那么子运营商B能看到公交车的充电，值班室人员（子运营商A）能看到站点A 所有的的充电数据。 27 27 28 -**优先级： 高** 29 - 30 30 **需求分类**（“√”代表选定） 31 31 32 32 界面 ... ... @@ -40,22 +40,3 @@ 40 40 * ~~~~这个场景，子运营商之间会有互相覆盖可能， 值班室人员（子运营商A）可能看不到 覆盖后 子运营商B的充电记录。 41 41 * ~~~~子运营商设计的原则：各子账户只看到属于自己运营商的车辆记录信息。 42 42 * ~~~~值班室+公交的混合场景，牵涉到两个维度（站点、子运营），系统需要另外设计调整来实现此需求。 43 - 44 -**项目轨迹：** 45 - 46 -2019-9-28 陈佳提出 47 - 48 -2019-9-28 功能分析（公司内部） 49 - 50 -2019-9-29 【方案调整】不改界面，查询逻辑需要改后满足，如果子运营商绑定了站点，那就可以查询对应站点所有数据，如果没有绑定站点而是绑定了部门/车辆, 那就只查询相应部门/车辆的记录。仅bo1.0 ，预计9.30日周一完成改动，可部署。 51 - 52 ----- 53 - 54 -(% class="box infomessage" %) 55 -((( 56 -【令】：值班室 账号绑定单站点，不绑定子运营商，只应用到充电记录界面（看到此站点所有充电记录） 57 -【客户】：确认同意 58 -【令】：仅bo1.0 ，预计9.30日周一完成改动，可部署。 59 --below 2019-9-29 60 -【方案调整】不改界面，查询逻辑需要改后满足，如果子运营商绑定了站点，那就可以查询对应站点所有数据，如果没有绑定站点而是绑定了部门/车辆, 那就只查询相应部门/车辆的记录。 61 -)))