Wiki源代码颂盛

在2020/12/25 14:13上被chinyee he修改

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

Wiki源代码颂盛

导航

Applications