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