Show last authors
| 1 | = nfzy_requirement#3_20200203 = |
| 2 | |
| 3 | **需求背景**: |
| 4 | |
| 5 | 1、应公交公司要求,报表中充电记录查询 涉及之“充电时间” 需 “以充电开始时间”界定 |
| 6 | 2、当前系统的规则是以结束时间界定。(如:日期选择0101-0201 是从结束时间为0101号开始算起的(开始时间为1231)) |
| 7 | |
| 8 | **优先级: 当前不急,按产品规划制定** |
| 9 | |
| 10 | **需求分类**(“☑”代表选定) |
| 11 | |
| 12 | ☑ 界面 |
| 13 | |
| 14 | ☑ 功能 |
| 15 | |
| 16 | **详细: ** |
| 17 | |
| 18 | **项目轨迹:** |
| 19 | |
| 20 | 2020-2-3 提出需求。 shi初步想法:考虑到不同客户不同策略和系统灵活性, 报表可加个筛选条件“按充电开始/结束时间” |
| 21 | |
| 22 | = nfzy_requirement#2_20200103 = |
| 23 | |
| 24 | **需求背景**: |
| 25 | |
| 26 | 代金卷使用查询导出功能,主要是使用记录 要分析 能够导出在不同站点之间的成本核算。包括:哪些客户使用了多少张啊?这个数据都有对后期的一些作用。 |
| 27 | |
| 28 | **优先级: 待定** |
| 29 | |
| 30 | **需求分类**(“☑”代表选定) |
| 31 | |
| 32 | ☑ 界面 |
| 33 | |
| 34 | ☑ 功能 |
| 35 | |
| 36 | **详细: ** |
| 37 | |
| 38 | **项目轨迹:** |
| 39 | |
| 40 | 2020-1-3 提出需求。 需求较粗,可能需细分到具体功能点。 |
| 41 | |
| 42 | = nfzy_requirement#1_20190928 = |
| 43 | |
| 44 | **需求背景**: |
| 45 | |
| 46 | (值班室)的场景: |
| 47 | 站点A绑定了值班室人员(子运营商A), 公交车绑定了子运营商B, 那么子运营商B能看到公交车的充电,值班室人员(子运营商A)能看到站点A 所有的的充电数据。 |
| 48 | |
| 49 | **优先级: 高** |
| 50 | |
| 51 | **需求分类**(“√”代表选定) |
| 52 | |
| 53 | 界面 |
| 54 | |
| 55 | √ 功能 |
| 56 | |
| 57 | **详细: ** |
| 58 | |
| 59 | 功能代号:登录账号关联值班室+公交的混合场景。 |
| 60 | |
| 61 | * ~~~~这个场景,子运营商之间会有互相覆盖可能, 值班室人员(子运营商A)可能看不到 覆盖后 子运营商B的充电记录。 |
| 62 | * ~~~~子运营商设计的原则:各子账户只看到属于自己运营商的车辆记录信息。 |
| 63 | * ~~~~值班室+公交的混合场景,牵涉到两个维度(站点、子运营),系统需要另外设计调整来实现此需求。 |
| 64 | |
| 65 | **项目轨迹:** |
| 66 | |
| 67 | 2019-9-28 陈佳提出 |
| 68 | |
| 69 | 2019-9-28 功能分析(公司内部) |
| 70 | |
| 71 | 2019-9-29 【方案调整】不改界面,查询逻辑需要改后满足,如果子运营商绑定了站点,那就可以查询对应站点所有数据,如果没有绑定站点而是绑定了部门/车辆, 那就只查询相应部门/车辆的记录。仅bo1.0 ,预计9.30日周一完成改动,可部署。 |
| 72 | |
| 73 | ---- |
| 74 | |
| 75 | (% class="box infomessage" %) |
| 76 | ((( |
| 77 | 【令】:值班室 账号绑定单站点,不绑定子运营商,只应用到充电记录界面(看到此站点所有充电记录) |
| 78 | 【客户】:确认同意 |
| 79 | 【令】:仅bo1.0 ,预计9.30日周一完成改动,可部署。 |
| 80 | -below 2019-9-29 |
| 81 | 【方案调整】不改界面,查询逻辑需要改后满足,如果子运营商绑定了站点,那就可以查询对应站点所有数据,如果没有绑定站点而是绑定了部门/车辆, 那就只查询相应部门/车辆的记录。 |
| 82 | ))) |