Wiki源代码颂盛
Version 31.1 by chinyee he on 2020/05/28 14:11
Hide last authors
 |
1.1 | 1 | {{box cssClass="floatinginfobox" title="**Contents**"}} |
| 2 | {{toc/}} | ||
| 3 | {{/box}} | ||
| 4 | |||
| |
31.1 | 5 | = gdss_case#16_20200528 = |
| 6 | |||
| 7 | 问题描述： | ||
| 8 | |||
| 9 | 广州颂盛大北站 | ||
| 10 | |||
| 11 | 账单号：20200524152830578065、20200524153120840584、 20200524161944876736 | ||
| 12 | |||
| 13 | 麻烦帮我分析一下这三个单号文报，罗宾森那边需要这些文报 | ||
| 14 | |||
| 15 | ~-~-跟踪 | ||
| 16 | |||
| 17 | 【Chinyee】：第一张单状态显示正常，充了一分钟的电，平台记录充电电量为0；第二张单状态是充电点电量与平台不符 设备账单电量61.23 平台账单电量122.14；第三张单状态显示正常 设备账单电量23.8 平台账单电量7450.09 | ||
| 18 | |||
| 19 | 【技】：[[attach:罗宾森_20200524-3.log||target="_blank"]][[attach:罗宾森_20200524-2.log||target="_blank"]][[attach:罗宾森_20200524-1.log||target="_blank"]] | ||
| 20 | |||
| 21 | ~-~-解决 | ||
| 22 | |||
| 23 | 状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置 | ||
| 24 | 售后（跟单）工程师：Chinyee | ||
| 25 | |||
| 26 | |||
| |
27.10 | 27 | = gdss_case#15_20200525 = |
| 28 | |||
| 29 | 问题描述：我在颂盛大岗站点已经绑好两张卡了，怎么就不刷不上卡呢 | ||
| 30 | |||
| 31 | ~-~-跟踪 | ||
| 32 | |||
| 33 | 【YD】：确认是站点管理员绑定卡号。查询数据库看看卡号是否有绑其他用户。 | ||
| 34 | |||
| |
27.11 | 35 | 【Chinyee】：0010000000000012,0010000000000013分别另外绑定了id：88261749，69410307的用户，建议确认这两个用户是否有使用卡再决定是否解绑。 |
| |
27.10 | 36 | |
| |
27.11 | 37 | 【客户】：已解绑，帮我查看9、10、11号卡绑定哪里了 |
| |
27.10 | 38 | |
| 39 | 【Chinyee】：58181399，41100430，20088347。这三张卡分别绑定了这三个用户id 以后如果要绑卡号 你这边也需要记录一下 | ||
| 40 | |||
| 41 | 【YD】：确认开始的两张卡号可以刷卡充电 | ||
| 42 | |||
| 43 | ~-~-解决 | ||
| 44 | |||
| 45 | 状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置 | ||
| 46 | 售后（跟单）工程师： YD Chinyee | ||
| 47 | |||
| |
27.9 | 48 | = gdss_case#14_20200519 = |
| |
27.2 | 49 | |
| 50 | 广州颂盛大北站点 | ||
| 51 | |||
| 52 | 账单号：20200519000048277368、20200518235932015491、20200518155717891654 | ||
| 53 | 桩号：44011300040000250006、44011300040000250008、44011300040000250004 | ||
| 54 | 充电时间： | ||
| 55 | 结束时间： | ||
| 56 | 异常问题：充电电量与平台不符 | ||
| 57 | 问题描述：此站点安装电能表刷新55.15版本之后出现充电电量与平台不符异常 | ||
| 58 | 麻烦查看是否平台原因？ | ||
| 59 | |||
| 60 | ~-~-跟踪 | ||
| 61 | |||
| |
27.5 | 62 | 【YD】：转研发(niewei) 研发反应都是桩的问题 |
| |
27.2 | 63 | |
| |
27.4 | 64 | 这是其中一张单的分析 另外那单估计情况差不多 20200518155717891654这单不是充电电量与平台不符。 |
| 65 | |||
| |
27.2 | 66 | [[attach:罗宾森_20200519-1(1).log||target="_blank"]] |
| 67 | |||
| |
27.4 | 68 | //~~补充：20200520// |
| |
27.2 | 69 | |
| |
27.7 | 70 | **罗宾森需要令狐充提供原始数据，四代设备没有log** |
| |
27.2 | 71 | |
| 72 | [[attach:罗宾森_20200519-2.log||target="_blank"]] | ||
| 73 | |||
| 74 | **罗宾森：能查到这条机器上一单的充点前电表读数和充电后电表读数吗** | ||
| 75 | |||
| 76 | 3041.82 / 3052.44 | ||
| 77 | |||
| 78 | **罗宾森：后台估算的电量大 感觉不是3052 3093跳变吧？是不是中间出现了0的问题跳变？** | ||
| 79 | |||
| 80 | 没有 | ||
| 81 | |||
| 82 | ~-~-解决 | ||
| 83 | |||
| |
27.8 | 84 | 状态（☑表示选定 ）： 已解决 | 处理中 | 暂搁置 |
| |
27.2 | 85 | 售后（跟单）工程师： YD |
| 86 | |||
| |
25.2 | 87 | = gdss_case#13_20200408 = |
| 88 | |||
| 89 | 问题描述：这是颂盛站点，车架号和车牌号显示这样的 | ||
| 90 | |||
| 91 | [[image:1586338347138-373.png||height="302" width="869"]] | ||
| 92 | |||
| 93 | ~-~-跟踪 | ||
| 94 | |||
| 95 | 【YD】：与之前金凯瑞的问题不同(参考jkr_case#35_20200408)，不确定原因 转研发 | ||
| 96 | |||
| 97 | 【技术】：这种是车发了不能解析的乱码，如果是社会车辆 不用管，如果是公交车 那要查一下公交车里面是不是写错了。社会车辆的vin是乱写的 | ||
| 98 | |||
| 99 | ~-~-解决 | ||
| 100 | |||
| 101 | 状态（☑表示选定 ）：☑ 已解决 | 处理中 | 暂搁置 | ||
| 102 | 售后（跟单）工程师： YD | ||
| 103 | |||
| |
24.8 | 104 | = gdss_case#12_20200407 = |
| 105 | |||
| 106 | 问题描述：请问一下，广州颂盛在微信上充值之后为什么要20分钟以后才到账呢 | ||
| 107 | |||
| 108 | ~-~-跟踪 | ||
| 109 | |||
| 110 | 【YD】：这是个别现象？还是很多用户这样？ | ||
| 111 | |||
| 112 | 【客户】：全部都是，从平台升级之后就变成这样了 | ||
| 113 | |||
| 114 | ~-~-解决: | ||
| 115 | 状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置 | ||
| 116 | 售后（跟单）工程师：YD | ||
| 117 | |||
| 118 | |||
| |
24.7 | 119 | = gdss_case#11_20200401 = |
| 120 | |||
| 121 | 问题描述: bo升级2.0计划。时间2020年4月2日（星期四）下午14:30-16:00 | ||
| 122 | |||
| 123 | ~-~-跟踪 | ||
| 124 | |||
| 125 | 【概况】： | ||
| 126 | 1、原广州颂盛后台各子运营商登录账号 升级后 无法第一时间登录。 | ||
| 127 | 1.1）原广州颂盛后台各子运营商登录账号 同步至 MC2.0 的方案，包括：原子账号名、角色名、密码不变。权限由广州颂盛配置见1.2 。【John】 | ||
| 128 | 1.2） 涉及到权限细节，由广州颂盛 逐个配置。【 广州颂盛 优先级高的子客户 需先配】 | ||
| 129 | 1.3） 因子账号的权限配置较复杂， 升级后，也可先提供小程序，进行站点管理员 配置。【执行：广州颂盛】 | ||
| 130 | 2、升级2.0过程约持续1个半小时。 | ||
| 131 | 3、2020-4-2 上午 将办公室交流桩转至广州颂盛下，确保可以正常充电。【lhc运维】 | ||
| 132 | 4、升级后测试 基本充电功能，包括： | ||
| 133 | 4.1）首次关注时弹出的拦截页是否正确。 | ||
| 134 | 4.2）扫码充电基本功能。(制作二维码，对应url：http:~/~/gdss.linghuchongtech.com/boss/front/opPanel/a.htm?did=xxx) | ||
| 135 | 4.3）检查微信支付功能。 | ||
| |
24.8 | 136 | 4.4）首页右上角进入“搜索”，检查站点信息：a）是否包含不属于当前运营商的电站。b）数据显示是否正常，如 卡loading。 |
| 137 | 4.5）现场测试桩端充电功能。【桩厂商、客户执行】 | ||
| |
24.7 | 138 | 5、bo2升级后提醒 客户 必须配置的项，以下列出几项优先级最高。【执行：广州颂盛】 |
| 139 | 5.1）配置正确的充值面额。 | ||
| 140 | 5.2）配置个人余额阀值（自动停止）。 | ||
| 141 | 5.3）见1.3. | ||
| 142 | 6、配置&提供mc2.0 登录管理账号【lhc运维】 | ||
| 143 | 7、如客户有MC2.0使用疑问，提供必要支撑。【执行：令狐充 运营】 | ||
| 144 | 8、按照约定，升级后，广州颂盛安排车、1台直流桩进行至少一次实测。【执行：广州颂盛】 | ||
| 145 | |||
| 146 | **【计划过程和注意事项】：** | ||
| 147 | |||
| 148 | **主要分2部分：第一部分由 shi 操作、第二部分由john操作。 | ||
| 149 | 第一部分：** | ||
| 150 | bo1升级bo2 基于 boVersion:20190810_101130_09614a | ||
| 151 | |||
| 152 | 1. 更新数据库 | ||
| 153 | 2. mc的boss_token表加⼀一下配置数据 | ||
| 154 | 3. boss的access_token表加⼀一下配置数据 | ||
| 155 | 4 导入sys_setting | ||
| 156 | 5 update sys_setting | ||
| 157 | 6 广州颂盛 javris配 营业执照 | ||
| 158 | 7 微信底部菜单更新。 | ||
| 159 | 8 升级前要求客户在腾讯商户平台新增安全支付路径。步骤：【执行：广州颂盛】((( | ||
| 160 | 1）登录https:~/~/pay.weixin.qq.com/ | ||
| 161 | 2）（可选，如已配置可忽略）依次进入“【账户中心】-》【api安全】-》【设置api秘钥】-》【提供我方秘钥】” | ||
| 162 | 3）在微信支付平台配置支付授权目录：http:~/~/gdss.linghuchongtech.com/boss/newui/ 步骤：依次进入“【产品中心】-【开发配置】-【支付配置】中修改” | ||
| 163 | ))) | ||
| 164 | |||
| 165 | #bo2 和bo1差异 sql | ||
| 166 | create | ||
| 167 | |||
| 168 | CREATE TABLE `wx_reply` ( | ||
| 169 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 170 | `keyword` varchar(32) DEFAULT NULL, | ||
| 171 | `content` text, | ||
| 172 | PRIMARY KEY (`id`) | ||
| 173 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; | ||
| 174 | |||
| 175 | CREATE TABLE `access_token` ( | ||
| 176 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 177 | `access_code` varchar(32) NOT NULL DEFAULT '', | ||
| 178 | `secret_key` varchar(32) NOT NULL DEFAULT '', | ||
| 179 | `restrict_ip` varchar(1024) DEFAULT NULL COMMENT '限制客户端ip，多个ip用,隔开', | ||
| 180 | `is_admin` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0-普通客户端， 1-超级客户端', | ||
| 181 | PRIMARY KEY (`id`) | ||
| 182 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; | ||
| 183 | |||
| 184 | CREATE TABLE `coupon` ( | ||
| 185 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 186 | `name` varchar(32) NOT NULL DEFAULT '' COMMENT '券名', | ||
| 187 | `issueCondition` int(11) NOT NULL DEFAULT '1' COMMENT '1-充额定值赠, 2-新用户赠', | ||
| 188 | `minCharge` int(11) DEFAULT NULL COMMENT '最低充值金额, 分', | ||
| 189 | `denomination` int(11) NOT NULL DEFAULT '0' COMMENT '面额。 分', | ||
| 190 | `perNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次赠送券数量', | ||
| 191 | `packNum` int(11) NOT NULL DEFAULT '0' COMMENT '总份数', | ||
| 192 | `issuedPackNum` int(11) NOT NULL DEFAULT '0' COMMENT '已送出券份数', | ||
| 193 | `departIds` varchar(1024) DEFAULT NULL COMMENT '限制部门id, 用|隔开并且前后也要有|', | ||
| 194 | `subOpIds` varchar(1024) DEFAULT NULL COMMENT '限制子运营商id, 用|隔开并且前后也要有|', | ||
| 195 | `stationIds` varchar(1024) DEFAULT NULL COMMENT '限制可用站点id. 用|隔开并且前后也要有|', | ||
| 196 | `useNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次充电可用数量', | ||
| 197 | `fromDate` datetime NOT NULL COMMENT '上架时间', | ||
| 198 | `toDate` datetime NOT NULL COMMENT '上架结束时间', | ||
| 199 | `validType` int(11) NOT NULL DEFAULT '1' COMMENT '1-特定天数有效，2-特定时间段有效', | ||
| 200 | `validDays` int(11) DEFAULT NULL COMMENT '有效期天数', | ||
| 201 | `expireFrom` date DEFAULT NULL COMMENT '有效期开始时间', | ||
| 202 | `expireTo` date DEFAULT NULL COMMENT '有效期结束时间', | ||
| 203 | `status` int(11) NOT NULL DEFAULT '1' COMMENT '1-有效, 0-下架', | ||
| 204 | `remark` varchar(1024) DEFAULT NULL COMMENT '描述信息', | ||
| 205 | `threshold` int(11) NOT NULL DEFAULT '0' COMMENT '最低消费额度, 分', | ||
| 206 | `C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人', | ||
| 207 | `C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间', | ||
| 208 | `C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人', | ||
| 209 | `C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间', | ||
| 210 | PRIMARY KEY (`id`) | ||
| 211 | ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8; | ||
| 212 | |||
| 213 | CREATE TABLE `member_coupon` ( | ||
| 214 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 215 | `couponId` int(11) NOT NULL COMMENT '券id', | ||
| 216 | `memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员id', | ||
| 217 | `amount` int(11) NOT NULL DEFAULT '0' COMMENT '金额, 分', | ||
| 218 | `stationIds` varchar(1024) DEFAULT NULL COMMENT '限制可用站点id. 用|隔开并且前后也要有|', | ||
| 219 | `useNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次充电可用数量', | ||
| 220 | `validFrom` datetime NOT NULL COMMENT '生效时间', | ||
| 221 | `expireTime` datetime NOT NULL COMMENT '有效期到期时间', | ||
| 222 | `billingId` varchar(32) DEFAULT NULL COMMENT '充电账单号', | ||
| 223 | `mbTransaction` varchar(32) DEFAULT NULL COMMENT 'member_bill 的订单号', | ||
| 224 | `issuedTime` datetime NOT NULL COMMENT '赠送时间', | ||
| 225 | `usedTime` datetime DEFAULT NULL COMMENT '使用时间', | ||
| 226 | `threshold` int(11) NOT NULL DEFAULT '0' COMMENT '最低消费额度, 分', | ||
| 227 | PRIMARY KEY (`id`), | ||
| 228 | KEY `couponId` (`couponId`), | ||
| 229 | KEY `memberId` (`memberId`), | ||
| 230 | KEY `billingId` (`billingId`) | ||
| 231 | ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; | ||
| 232 | |||
| 233 | CREATE TABLE `refund_apply` ( | ||
| 234 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 235 | `memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员id', | ||
| 236 | `amount` int(11) DEFAULT NULL COMMENT '退款金额，分', | ||
| 237 | `commission` int(11) DEFAULT '0' COMMENT '扣取手续费， 分', | ||
| 238 | `status` int(11) NOT NULL DEFAULT '0' COMMENT '0-待审核，1-审核不通过，2-审核通过', | ||
| 239 | `progress` int(11) NOT NULL DEFAULT '0' COMMENT '0-用户申请、1-平台审核、2-完成退款, 3-部分退款, 4-退款失败', | ||
| 240 | `reason` varchar(1024) DEFAULT NULL COMMENT '原因', | ||
| 241 | `settlementRefundFee` int(11) NOT NULL DEFAULT '0' COMMENT '实际退款金额', | ||
| 242 | `C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人', | ||
| 243 | `C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间', | ||
| 244 | `C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人', | ||
| 245 | `C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间', | ||
| 246 | PRIMARY KEY (`id`), | ||
| 247 | KEY `memberId` (`memberId`) | ||
| 248 | ) ENGINE=InnoDB AUTO_INCREMENT=35 DEFAULT CHARSET=utf8 COMMENT='退款申请'; | ||
| 249 | |||
| 250 | CREATE TABLE `refund_audit` ( | ||
| 251 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 252 | `refundId` int(11) NOT NULL COMMENT '退款申请ID', | ||
| 253 | `status` int(11) NOT NULL DEFAULT '0' COMMENT '0-待审核，1-审核不通过，2-审核通过', | ||
| 254 | `reason` varchar(1024) DEFAULT NULL COMMENT '原因', | ||
| 255 | `C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人', | ||
| 256 | `C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间', | ||
| 257 | `C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人', | ||
| 258 | `C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间', | ||
| 259 | PRIMARY KEY (`id`), | ||
| 260 | KEY `refundId` (`refundId`) | ||
| 261 | ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8 COMMENT='退款申请审核历史'; | ||
| 262 | |||
| 263 | CREATE TABLE `refund_record` ( | ||
| 264 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 265 | `raId` int(11) DEFAULT NULL COMMENT 'refund_apply的id', | ||
| 266 | `memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员ID', | ||
| 267 | `openId` varchar(255) DEFAULT NULL COMMENT '微信用户openId', | ||
| 268 | `mchId` varchar(32) DEFAULT NULL COMMENT '商户号', | ||
| 269 | `nonceStr` varchar(32) DEFAULT NULL COMMENT '随机字符串', | ||
| 270 | `sign` varchar(32) DEFAULT NULL COMMENT '签名', | ||
| 271 | `signType` varchar(32) DEFAULT NULL COMMENT '签名类型. MD5或者HMAC-SHA256', | ||
| 272 | `transactionId` varchar(32) DEFAULT NULL COMMENT '微信充值订单号', | ||
| 273 | `outTradeNo` varchar(32) DEFAULT NULL COMMENT '对应wc_payment_msg表的C_INNER_TRANSACTION_NO和member_bill表的C_TRANSACTION', | ||
| 274 | `outRefundNo` varchar(32) DEFAULT NULL COMMENT '商户退款单号', | ||
| 275 | `totalFee` int(11) NOT NULL DEFAULT '0' COMMENT '充值订单金额', | ||
| 276 | `refundFee` int(11) NOT NULL DEFAULT '0' COMMENT '退款金额', | ||
| 277 | `status` int(11) NOT NULL DEFAULT '1' COMMENT '0-退款失败, 1-退款中, 2-成功退款, 3-撤销', | ||
| 278 | `resultCode` varchar(16) DEFAULT NULL COMMENT '业务结果。 提交申请结果，不表示退款成功', | ||
| 279 | `errCode` varchar(32) DEFAULT NULL COMMENT '错误代码', | ||
| 280 | `errCodeDes` varchar(128) DEFAULT NULL COMMENT '错误代码描述', | ||
| 281 | `refundId` varchar(32) DEFAULT NULL COMMENT '微信退款单号', | ||
| 282 | `settlementRefundFee` int(11) NOT NULL DEFAULT '0' COMMENT '应结退款金额', | ||
| 283 | `C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人', | ||
| 284 | `C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间', | ||
| 285 | `C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人', | ||
| 286 | `C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间', | ||
| 287 | PRIMARY KEY (`id`), | ||
| 288 | KEY `raId` (`raId`), | ||
| 289 | KEY `memberId` (`memberId`) | ||
| 290 | ) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8 COMMENT='退款记录'; | ||
| 291 | |||
| 292 | CREATE TABLE `member_flag` ( | ||
| 293 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 294 | `name` varchar(32) NOT NULL DEFAULT '' COMMENT '标签名称', | ||
| 295 | `type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-固定标签， 1-自定义标签', | ||
| 296 | `criteria` tinyint(4) DEFAULT NULL COMMENT '固定标签条件', | ||
| 297 | `params` varchar(256) DEFAULT NULL COMMENT '固定标签条件参数', | ||
| 298 | `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '0-下线，1-在线', | ||
| 299 | `C_CREATE_BY` varchar(255) DEFAULT NULL, | ||
| 300 | `C_CREATE_DATE` datetime DEFAULT NULL, | ||
| 301 | `C_UPDATE_BY` varchar(255) DEFAULT NULL, | ||
| 302 | `C_UPDATE_DATE` datetime DEFAULT NULL, | ||
| 303 | `C_DELETE_FLAG` tinyint(4) NOT NULL DEFAULT '0' COMMENT '删除标记：0-未删除，1-已删除', | ||
| 304 | PRIMARY KEY (`id`) | ||
| 305 | ) ENGINE=InnoDB AUTO_INCREMENT=100 DEFAULT CHARSET=utf8; | ||
| 306 | |||
| 307 | CREATE TABLE `member_flag_rel` ( | ||
| 308 | `id` int(11) unsigned NOT NULL AUTO_INCREMENT, | ||
| 309 | `memberId` varchar(255) DEFAULT NULL COMMENT '会员id', | ||
| 310 | `flagId` int(11) unsigned DEFAULT NULL COMMENT '标签id', | ||
| 311 | `C_CREATE_DATE` datetime DEFAULT NULL, | ||
| 312 | PRIMARY KEY (`id`), | ||
| 313 | KEY `memberId` (`memberId`), | ||
| 314 | KEY `flagId` (`flagId`) | ||
| 315 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; | ||
| 316 | |||
| 317 | ---alter-- | ||
| 318 | alter table sub_operator add column `isOut` tinyint(1) DEFAULT '0' COMMENT '1-对方系统计费，0-本方系统计费'; | ||
| 319 | alter table sub_operator add column `domain` varchar(64) DEFAULT NULL COMMENT '第三方系统二维码的域名'; | ||
| 320 | alter table sub_operator add column `urlParamFormat` varchar(1024) DEFAULT NULL COMMENT '二维码链接参数格式'; | ||
| 321 | |||
| 322 | alter table wc_payment_msg add column `C_REFUND_FEE` int(11) NOT NULL DEFAULT '0' COMMENT '已退款金额. 分'; | ||
| 323 | alter table t_department_account add column `C_PARENT_BILLING` tinyint(1) NOT NULL DEFAULT '0' COMMENT '1-使用上级部门账户扣费'; | ||
| 324 | |||
| 325 | alter table member add column `C_REFUNDABLE_AMOUNT` int(11) NOT NULL DEFAULT '0' COMMENT '可退款金额, 分'; | ||
| 326 | |||
| 327 | #alter table recharge_history add column `C_STATION_ID` int(11) DEFAULT NULL COMMENT '站点ID'; | ||
| 328 | |||
| 329 | |||
| 330 | alter table recharge_history add (C_CONNECTOR varchar(32) DEFAULT NULL COMMENT '充电接口id', | ||
| 331 | C_QRCODE varchar(1024) DEFAULT NULL COMMENT '扫码充电二维码' | ||
| 332 | ); | ||
| 333 | |||
| 334 | alter table member_bill add column C_COUPON_AMOUNT int(11) DEFAULT '0' COMMENT '代金券扣减金额，分'; | ||
| 335 | |||
| 336 | ALTER TABLE `recharge_history` ADD INDEX unionBillingId ( `C_UNION_BILLINGID` ); | ||
| 337 | \\**第二部分:** | ||
| 338 | 继续更新近期bo2涉及的sql等。 | ||
| 339 | |||
| 340 | |||
| 341 | (% class="box" %) | ||
| 342 | ((( | ||
| 343 | 【更新结果】： | ||
| 344 | 1、错误1：充值报错 | ||
| 345 | 2、解决：补sql | ||
| 346 | alter table member_bill add column `C_BALANCE_BEFORE` int(11) DEFAULT NULL COMMENT '消费/充值前余额，分'; | ||
| 347 | alter table member_bill add column `C_BALANCE_AFTER` int(11) DEFAULT NULL COMMENT '消费/充值后余额，分'; | ||
| 348 | ))) | ||
| |
24.8 | 349 | |
| |
24.7 | 350 | ~-~-解决 |
| 351 | |||
| 352 | 状态（☑表示选定 ）： 已解决 | 处理中 | 暂搁置 | ||
| 353 | 售后（跟单）工程师： 施文俊 | ||
| 354 | |||
| |
24.4 | 355 | = gdss_case#10_20200217 = |
| |
24.2 | 356 | |
| 357 | 问题描述：http:~/~/cloud.linghuchongtech.com/DynamicAdmin2/login.html | ||
| 358 | |||
| |
24.7 | 359 | ~-~-跟踪 |
| 360 | |||
| |
24.2 | 361 | 账号：ssxny |
| 362 | 吴小英说这个账号无法登录。 | ||
| |
24.3 | 363 | 【YD】：我试了下该账号出现了“同时登陆用户数量超过限制”的提示。**与之前金凯瑞jkr_case#28_20200211属于同样的问题，故以同样的方式处理。** |
| |
24.6 | 364 | 1、他的账号有同时登陆数量15的限制 |
| |
24.2 | 365 | |
| 366 | **客户不按规则操作，故给他同时登录次数设到100，避免再出现** | ||
| 367 | |||
| 368 | ~-~-解决 | ||
| 369 | |||
| 370 | 状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置 | ||
| |
24.7 | 371 | 售后（跟单）工程师： YD |
| |
24.2 | 372 | |
| |
24.1 | 373 | = gdss_case#9_20200117 = |
| 374 | |||
| 375 | (% class="wikigeneratedid" %) | ||
| 376 | 问题描述：截止到今 颂盛未处理异常账单统计 | ||
| 377 | |||
| 378 | (% class="box infomessage" %) | ||
| 379 | ((( | ||
| 380 | 提供一份数据：1）未处理异常账单统计。 | ||
| 381 | |||
| 382 | 1）异常账单统计：下表为 **2019年3月到至今**之未处理异常代码统计 | ||
| 383 | |||
| 384 | |**异常代码\统计时间段**|**201903-至今** | ||
| 385 | |**1-账单丢失**|261 | ||
| 386 | |((( | ||
| 387 | **3- 时间异常** | ||
| 388 | )))|219 | ||
| 389 | |**11-电量丢失**|294 | ||
| 390 | |**2-账单丢失（设备离线）**|7 | ||
| 391 | |**3，4（充电电量异常），5（充电时长异常），8（充电电量与平台不符），9（充电时长与平台不符）**|1 | ||
| 392 | |**3,5,7（充电时间重叠）,8,9**|2 | ||
| 393 | |**3,5,8,9**|1 | ||
| 394 | |**3，6（占桩时长异常）**|18 | ||
| 395 | |**3，8**|273 | ||
| 396 | |**3，8，6**|115 | ||
| 397 | |**3，8，9**|3 | ||
| 398 | |**4，8，6**|1 | ||
| 399 | |**6**|1291 | ||
| 400 | |**7**|15 | ||
| 401 | |**7，8**|3 | ||
| 402 | |**7，8，9**|20 | ||
| 403 | |**7，8，9，6**|44 | ||
| 404 | |**7，9，6**|15 | ||
| 405 | |**8**|77854 | ||
| 406 | |**8,6**|32902 | ||
| 407 | |**8,9**|536 | ||
| 408 | |**8,9,6**|1347 | ||
| 409 | |**9**|36 | ||
| 410 | |**9,6**|33 | ||
| 411 | |**合计**|115291 | ||
| 412 | ))) | ||
| 413 | |||
| 414 | ~-~-解决: | ||
| 415 | 状态（☑表示选定 ）： ☑ 已解决 | 处理中 | 暂搁置 | ||
| 416 | |||
| 417 | 数据统计人：Chinyee | ||
| 418 | |||
| 419 | |||
| |
22.4 | 420 | = gdss_case#8_20200115 = |
| 421 | |||
| |
22.6 | 422 | 问题描述：旧平台 |
| |
22.4 | 423 | 1.吴小英说他误修复了几张异常账单，希望把那几张单改回异常状态。 |
| 424 | |||
| 425 | 2.修复后报表里多了这几张单，颂盛的客人那边会出现前后报表不一致的情况。他想避免这情况 | ||
| 426 | |||
| |
22.5 | 427 | 3.旧平台上他反应未修复的账单也能在报表看到20200108165713818444 20200111022016826908 这两个账单是没修复过的 |
| |
22.4 | 428 | |
| 429 | ~-~-跟踪 | ||
| 430 | |||
| 431 | 【YD】： | ||
| 432 | |||
| 433 | 1）2）已修复的，我们不能随意修改客户数据，如果客人问起来您需要向他们解释。 | ||
| 434 | 3）颂盛这边一直都是配置成允许异常账单先结算扣款，后续人工修复再补扣，所以报表能看到 | ||
| |
23.2 | 435 | 【shi】：1、下图配置的意思是允许异常账单先结算扣款，后续人工修复再补扣。 |
| 436 | 2、一些客户不能及时修复账单，是用了先结算， bo2和bo1的机制是一样的。 | ||
| 437 | 3、建议客户及时处理异常账单，特别是公交周期结算前 是必须处理完的。 | ||
| 438 | [[image:1579061130998-533.png]] | ||
| |
22.4 | 439 | |
| |
23.2 | 440 | |
| 441 | |||
| |
22.4 | 442 | ~-~-解决: |
| 443 | 状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置 | ||
| 444 | |||
| 445 | 售后（跟单）工程师：施文俊 YD | ||
| 446 | |||
| |
22.2 | 447 | = gdss_case#7_20200113 = |
| 448 | |||
| 449 | 问题描述： | ||
| 450 | |||
| 451 | 颂盛旧系统平台 | ||
| 452 | 日期：2020-01-13 | ||
| 453 | 桩站名称：颂盛站点 | ||
| 454 | 手机号： | ||
| 455 | 订单号：20200113131916994301、20200113130454355822、20200113130336691650、20200113130240664036、20200113125312202217、20200113125311761057、20200113125203914204、20200113124854037470、20200113124637079267、20200113124544419307、20200113123331114379、20200113123029340160、20200113122916302241、20200113122040542106、20200113120748494182、20200113120300119547、20200113115846103652、20200113115828334527、20200113114219467743、20200113113813352135 | ||
| 456 | 充电桩号：44011300040000200055、、44011300040000250003、44011300040000240001、44011300040000210006、44011300040000200085、44011300040000200054、44011300040000210005、44011300040000200083、44011300040000240002、44011300040000200053、44011300040000200093 | ||
| 457 | 充电枪号： | ||
| 458 | 充电时间： | ||
| 459 | 结束时间： | ||
| 460 | 现场网络连接状态：正常 | ||
| 461 | 异常状态：充电电量与平台不符 | ||
| 462 | 问题描述：充电电量与平台不符，请帮忙查看一下是什么原因，见下图： | ||
| 463 | |||
| 464 | [[image:1578900456181-994.png||height="469" width="942"]] | ||
| 465 | |||
| 466 | ~-~-跟踪 | ||
| 467 | |||
| 468 | 【YD】：转研发确认是否与gdss_case#6_20191204的原因一致。 | ||
| |
22.3 | 469 | 【令技术】：以上账单中出现的“充电电量与平台不符”的异常, 都是由于充电桩在充电前上送心跳的电表总读数均为0， 启动充电后，电表总读数变为一个较大的值 造成的 计算异常。 |
| |
22.2 | 470 | |
| 471 | ~-~-解决: | ||
| |
22.3 | 472 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 |
| |
22.2 | 473 | |
| 474 | 售后（跟单）工程师：施文俊 YD | ||
| 475 | |||
| |
20.3 | 476 | = gdss_case#6_20191204 = |
| |
20.1 | 477 | |
| |
20.2 | 478 | 广州颂盛旧系统平台 |
| 479 | 日期：2019-12-04 | ||
| 480 | 桩站名称：塘坑站点、大岗站点、桥南站点、 | ||
| 481 | 手机号： | ||
| 482 | 订单号： | ||
| 483 | 充电桩号： | ||
| 484 | 充电枪号： | ||
| 485 | 时间：2019年11月份 | ||
| |
20.3 | 486 | \\现场网络连接状态：正常 |
| |
20.2 | 487 | 异常状态：金额、峰、平、谷值都为0 |
| 488 | 问题描述：今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0，见表格下： | ||
| 489 | |||
| 490 | 20191108112557047049 | ||
| 491 | 20191109045929266559 | ||
| 492 | 20191112002225771301 | ||
| 493 | 20191116000001501830 | ||
| 494 | 20191125001902046919 | ||
| 495 | 20191127001635518809 | ||
| 496 | 20191106044333115970 | ||
| 497 | 20191109000104273153 | ||
| 498 | |||
| 499 | ~-~-跟踪 | ||
| 500 | |||
| 501 | 【YD】：这些单都为“账单丢失”，但手动修正里有部分单的修正电量过大。 | ||
| 502 | |||
| |
21.3 | 503 | 【niewei】20191205 出现几万度电的情况， 是由于罗宾森桩的电表读数异常造成的。 需要人工处理。 |
| 504 | |||
| |
21.2 | 505 | [[image:1575445987388-997.png||height="365" width="842"]] |
| 506 | |||
| |
20.2 | 507 | ~-~-解决: |
| |
21.4 | 508 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 |
| |
20.2 | 509 | |
| 510 | 售后（跟单）工程师：施文俊 YD | ||
| 511 | |||
| 512 | |||
| 513 | = gdss_case#5_201911113 = | ||
| 514 | |||
| |
20.1 | 515 | 广州颂盛旧系统充电平台 |
| 516 | |||
| 517 | 日期：2019-11-13 | ||
| 518 | 桩站名称： | ||
| 519 | 手机号： | ||
| 520 | 订单号：20191108112557047049/20191109000104273153/20191109045929266559 | ||
| 521 | 充电桩号： | ||
| 522 | 充电枪号： | ||
| 523 | 开始充电时间： | ||
| 524 | 现场网络连接状态：正常 | ||
| 525 | 异常状态： | ||
| 526 | 问题描述：现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象 | ||
| 527 | |||
| 528 | ~-~-跟踪 | ||
| 529 | |||
| 530 | 【令】：排查结果如下，都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩， 这个电表读数异常的问题，还存在。 | ||
| 531 | |||
| 532 | [[image:1573633992288-441.png]] | ||
| 533 | |||
| 534 | ~-~-解决: | ||
| 535 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 | ||
| 536 | |||
| 537 | 售后（跟单）工程师：施文俊 何倩怡 | ||
| 538 | |||
| 539 | |||
| |
17.2 | 540 | = gdss_case#6_20191112 = |
| 541 | |||
| 542 | 广州颂盛旧系统平台 | ||
| 543 | 日期：2019-11-12 | ||
| 544 | 桩站名称：广州颂盛桥南充电站 | ||
| 545 | 手机号： | ||
| 546 | 订单号：20191112001934329341 | ||
| 547 | 充电桩号：44011300040000200061 | ||
| 548 | 充电枪号： | ||
| 549 | 开始充电时间：2019-11-12 00:23:38 | ||
| 550 | 结束时间：2019-11-12 03:50:36 | ||
| 551 | 现场网络连接状态：正常 | ||
| 552 | 异常状态：充电量与平台不符 | ||
| 553 | |||
| 554 | [[image:1573546978385-211.png||height="334" width="705"]] | ||
| 555 | |||
| 556 | ~-~-跟踪 | ||
| 557 | |||
| 558 | 【令】：已转研发 | ||
| |
18.3 | 559 | 【shi】： 罗宾森桩的问题看来是比较多啊。见附件 [[attach:罗宾森_20191112001934329341问题排查.log||target="_blank"]]，罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了， 用设备账单来计费。 |
| |
18.2 | 560 | to 金凯瑞许总： |
| 561 | 请关注罗宾森桩程序目前的问题。 | ||
| 562 | 联想到贵司伙伴即将在深圳运营，不禁有些担忧。按照我的经验，深圳市社会车辆 充电业务量的数量级是其他城市几倍，用户对充电数据精准性不是公交充电能比的（仅月底看一次数据。） | ||
| 563 | 附件是我司技术对问题账单分析，我按照通俗易懂方式给您解释如下： | ||
| 564 | 1）背景知识：计算机需要按照约定的协议严格执行协议流程。 | ||
| 565 | 2）类比举例： | ||
| 566 | 吃饭需要5步，即：1，2，3，4，5。 | ||
| 567 | 小明实际吃饭步骤：1,3,4,5 或 1,3,2,4,5 或 1,2,2,2,3,4,5 等类似不按约定协议执行。 | ||
| 568 | 3）因为第2项的原因，充电桩在一些情况下（蒙混过关）看来是完成充电了，因为运营环境的复杂，实际上会很大概率出现各种无法预期的异常。 | ||
| 569 | 4）第2项 这个问题 从第一个罗宾森桩投入运营上线至今似乎一直存在，未彻底解决。看如何彻底解决。 | ||
| |
18.3 | 570 | 5）如果 大家认同 运营稳定排第一位。 所谓 RS485 丢包造成，是否可以更换 相应的模块配件。 |
| |
17.2 | 571 | |
| 572 | ~-~-解决: | ||
| 573 | 状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置 | ||
| 574 | |||
| 575 | 售后（跟单）工程师：施文俊 YD | ||
| 576 | |||
| |
11.1 | 577 | = gdss_case#5_20191031 = |
| 578 | |||
| 579 | |||
| 580 | 问题描述：这怎么修复只充了34分钟就要244.40元了 | ||
| 581 | |||
| |
13.1 | 582 | 账单号：20191024144331381526 |
| 583 | |||
| |
11.1 | 584 | [[image:1572491525002-420.png||height="381" width="766"]] |
| 585 | |||
| 586 | |||
| |
15.1 | 587 | ~-~-跟踪 |
| |
11.1 | 588 | |
| |
15.1 | 589 | [[image:1572492802252-387.png||height="180" width="783"]] |
| |
16.2 | 590 | 【chinyee】： |
| 591 | 该账单号的充电心跳，其中： | ||
| 592 | 1、充电数据是线性增长，未察觉异常 | ||
| 593 | 2、2019-10-24 15：10：28到15：17：30之间没有心跳上传，且15：17：30当前状态为8充电异常。 | ||
| 594 | 【shi】：异常账单中查到 账单丢失，平台估算电量 128.63度，超正常值。 需转研发分析。 | ||
| |
16.3 | 595 | 【令狐充技术】： |
| 596 | |||
| 597 | (% class="box infomessage" %) | ||
| 598 | ((( | ||
| 599 | 1、该充电桩在充电过程中发生离线， 所有有一段时间没有心跳； | ||
| 600 | 2、平台估算电量为128.63度， 是因为该充电桩在本次充电之前上传的电表总读数为0所致， 所以这个估算值是不准确的。 | ||
| 601 | 开始充电后，电表读数直接跳到92.27 | ||
| 602 | 估计这个才是实际值 | ||
| 603 | 之后充电中离线了一段时间，恢复后状态已经变成空闲 | ||
| 604 | 但是账单一直没上传 | ||
| 605 | ))) | ||
| 606 | |||
| 607 | 【shi】： 疑似电桩老问题未解决，需客户协调罗宾森 厂家 排查解决。 | ||
| |
16.2 | 608 | |
| |
15.1 | 609 | |
| |
11.1 | 610 | ~-~-解决: |
| 611 | 状态（√表示选定 ）： 已解决 | √ 处理中 | 暂搁置 | ||
| 612 | |||
| 613 | 售后（跟单）工程师：施文俊 何倩怡 | ||
| 614 | |||
| |
9.1 | 615 | = gdss_case#4_20191028 = |
| 616 | |||
| 617 | 广州颂盛旧系统充电平台 | ||
| 618 | |||
| 619 | 日期：2019-10-28 | ||
| 620 | 桩站名称： | ||
| 621 | 手机号： | ||
| 622 | 订单号：20191027034932615917/20191027142506967167/20191027140716525520/20191024124035938813/20191024144331381526 | ||
| 623 | 充电桩号： | ||
| 624 | 充电枪号： | ||
| 625 | 开始充电时间： | ||
| 626 | 现场网络连接状态：正常 | ||
| 627 | 异常状态： | ||
| 628 | 问题描述：充电日报表分不到峰平谷值 | ||
| 629 | |||
| 630 | ~-~-跟踪 | ||
| 631 | |||
| 632 | 【令】：以上几个账单都为故障账单，异常类型为账单丢失，人工修正即可 | ||
| 633 | |||
| 634 | ~-~-解决: | ||
| 635 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 | ||
| 636 | |||
| 637 | 售后（跟单）工程师：施文俊 何倩怡 | ||
| 638 | |||
| 639 | |||
| |
7.1 | 640 | = gdss_case#3_20191011 = |
| 641 | |||
| 642 | 桩站名称： | ||
| 643 | 手机号： | ||
| 644 | 订单号： 20190901220059873970/20190914201254659429/20190914210510578166 | ||
| 645 | 问题描述：客户说不是个人扫码付费充电的，是用站点的密码充电的，在后台显示是扫码付费的，客人怀疑我们后台出现问题了 | ||
| 646 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- | ||
| 647 | 运营商初步排查结果：通过客户提供过来的账号查找充电记录，发现都是个人扫码社会车辆充电。 | ||
| 648 | |||
| |
8.1 | 649 | ~-~-跟踪 |
| 650 | |||
| 651 | 【shi】：根据客户提供之订单号，查询结果如下： | ||
| 652 | 账单号 | 充电发起人 | ||
| 653 | 20190901220059873970 | 明基水产丰少 | ||
| 654 | 20190914201254659429 | ZION | ||
| 655 | 根据平台数据证实，以上2条都是个人扫码社会车辆充电。 | ||
| 656 | 重要注意： 针对云浮新兴站， 如用站点密码启动 则 充电记录中 昵称都是 “云浮新兴站”（请咨询May，她为客户配置） | ||
| 657 | \\【chinyee】：以下图为3个订单号对应的充电发起人，都是个人启动充电 | ||
| 658 | |||
| |
7.1 | 659 | [[image:1570785879995-291.png||height="70" width="701"]] |
| 660 | |||
| 661 | [[image:1570786018549-143.png||height="107" width="698"]] | ||
| 662 | |||
| 663 | [[image:1570786092126-721.png||height="89" width="697"]] | ||
| 664 | |||
| |
8.1 | 665 | 【客】：不认同。并强调：客户说不是个人扫码付费充电的，是用站点的密码充电的，在后台显示是扫码付费的，客人怀疑我们后台出现问题了。 |
| 666 | 【shi】：我方是根据客户认为有问题的账单号进行分析。如果不认同请其提供进一步证据，比如， 监控视频等其他证据 | ||
| |
7.1 | 667 | |
| 668 | ~-~-解决: | ||
| 669 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 | ||
| 670 | |||
| 671 | 售后（跟单）工程师：施文俊 何倩怡 | ||
| 672 | |||
| |
27.9 | 673 | = = |
| |
7.1 | 674 | |
| |
3.2 | 675 | = gdss_case#2_20190927 = |
| 676 | |||
| 677 | 问题描述：(客户原话) | ||
| 678 | |||
| 679 | 金凯瑞平台管理员黎美桥: | ||
| 680 | 这个我在金凯瑞后台看到他是管理员的！ | ||
| 681 | |||
| 682 | 金凯瑞平台管理员黎美桥: | ||
| 683 | 而且是后台充值，我们公司没有这个人 | ||
| 684 | |||
| 685 | [[image:1569571800883-235.png||height="450" width="943"]] | ||
| 686 | |||
| 687 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- | ||
| 688 | 运营商初步排查结果： | ||
| 689 | |||
| 690 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- | ||
| 691 | ~-~--跟踪 | ||
| 692 | |||
| 693 | 【令】：使用客户账号登录金凯瑞确实查到此条记录，建议客户仔细回想是否自己进行的此操作。 | ||
| 694 | |||
| 695 | 【运营商】： | ||
| 696 | 我没有操作过 | ||
| 697 | 那个微信呢称也不是我 | ||
| 698 | 所以奇怪就问下你们那边 | ||
| 699 | 那个时间下班了，我也没登录上去操作 | ||
| 700 | |||
| |
3.3 | 701 | 【令】：由于可能是客户内部人员使用 管理员 账号进行该操作，暂时不能确定该操作详情，客户那边开始内部查找操作原因。 |
| |
3.2 | 702 | |
| 703 | 【运营商】：我查到了，是客户退款了，我领导操作了不好意思 | ||
| 704 | |||
| 705 | ~-~-解决: | ||
| 706 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 | ||
| 707 | |||
| 708 | |||
| |
1.1 | 709 | = gdss_case#1_20190924 = |
| 710 | |||
| 711 | ~#~# 平台相关工单 | ||
| |
2.1 | 712 | 问题描述：广州颂盛大岗公交车站充电站 新站 充电反应平台无记录。 |
| |
1.1 | 713 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- |
| 714 | 运营商初步排查结果： | ||
| 715 | |||
| 716 | ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- | ||
| 717 | ~-~--跟踪 | ||
| 718 | |||
| |
2.1 | 719 | 【令】：9.24 21:20登录系统 查电站充电记录可以看到 此电站充电记录，无法重现客户问题。 |
| 720 | |||
| |
2.2 | 721 | 9.25 使用客户提供的账号登录查询“大岗公交站”没有记录，更改成“大岗公交车站”有记录，客户确认是其所需要的数据。 |
| 722 | |||
| 723 | 【运营商】：是，那日报表没有记录？ | ||
| 724 | |||
| 725 | 【令】：大岗公交车站充电站 查询条件子运营“颂盛”无法查到数据，“全部运营商”可以查到数据。可能是没有绑定站点与子运营 | ||
| 726 | |||
| 727 | 【运营商】：已经绑定了呀 | ||
| 728 | |||
| 729 | 【令】：如果是今天绑定的 那需要再看看 绑定前的用子运营是查不到 | ||
| 730 | |||
| 731 | 【运营商】：好像是昨天还是今天绑定的 | ||
| 732 | |||
| 733 | 【令】：先观察两天看看 | ||
| 734 | |||
| |
1.1 | 735 | ~-~-解决: |
| 736 | 状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置 | ||
| |
2.1 | 737 | |
| 738 | 售后（跟单）工程师：施文俊 | ||
| |
21.5 | 739 | |
| 740 | |||
| 741 | ~#~##番禺项目汇报-20180724 | ||
| 742 | 人员： | ||
| 743 | 罗宾森售后 | ||
| 744 | 金凯瑞工程人员、项目经理、平台管理员 | ||
| 745 | 令狐充平台工程师 | ||
| 746 | 番禺场站公交负责人、运维人员 | ||
| |
22.5 | 747 | \\阶段性成果： |
| |
21.5 | 748 | a、介绍平台功能和基本使用情况。客户运维、金凯瑞平台运维和令狐充运维 建微信群 计划初期对运营进行支撑和维护。 |
| 749 | b、目前支持站点密码为场站之车辆进行充电。 | ||
| 750 | c、少量电桩完成平台接入，并通过公交充电测试。其余待网络、电力设备就绪后逐个接入平台。 | ||
| 751 | |||
| 752 | |||
| 753 | 联调之问题汇总： | ||
| 754 | 1、桩的程序存在漏洞，界面无法更改服务器IP等参数，暂时由罗宾森售后用烧写器改参数并逐个上线。罗宾森尽快修改。【优先级:高】 | ||
| 755 | 2、桩目前无法将VIN上传后台，影响充电记录，无法知道哪些车辆进行了充电，罗宾森尽快修改。【优先级:高】 | ||
| 756 | 3、车牌号、vin、集团/企业部门 三者之间的关系录入系统。【优先级:高，由施工和may处理】 | ||
| 757 | 4、桩对接平台之刷卡功能。【优先级:中，需罗宾森支持】 |