# 颂盛

在2020/12/25 14:13上被chinyee he修改
导出
Office Formats
以PDF格式导出
Other Formats

Select the pages to export:

select all / none

以HTML格式导出

Contents

- gdss_case#24_20201125
- gdss_case#23_20201120
- gdss_case#22_20201110
- gdss_case#21_20200915
- gdss_case#20_20200910
- gdss_case#19_20200813
- gdss_case#18_20200701
- gdss_case#17_20200526
- gdss_case#16_20200528
- gdss_case#15_20200525
- gdss_case#14_20200519
- gdss_case#13_20200408
- gdss_case#12_20200407
- gdss_case#11_20200401
- gdss_case#10_20200217
- gdss_case#9_20200117
- gdss_case#8_20200115
- gdss_case#7_20200113
- gdss_case#6_20191204
- gdss_case#5_201911113
- gdss_case#6_20191112
- gdss_case#5_20191031
- gdss_case#4_20191028
- gdss_case#3_20191011
- 颂盛
- gdss_case#2_20190927
- gdss_case#1_20190924

# gdss_case#24_20201125

问题描述：我让我们的统计人员，做了12月1-24号的数据，你们看一下，你们能不能派个技术人员到我们公司现场检查一下，看看底出了哪些问题，看看有没有解决的办法，如果长期存在这样的账单没有车牌号，估计公司会改用其它的系统了

--跟踪

1.首先确认车辆电池是否有写入vin

2.如果有，可以把车牌号和vin录入平台

3.如果没有，建议使用一车一卡 刷卡充电（包括蓄电池充电、平台配置已发操作文档和截图）

4.如果平台上传的车牌号和vin不对应，账单也不会显示车牌号

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：chinyee

# gdss_case#23_20201120

问题描述：补电车有两块电池，一块是车辆自己的电池（有vin），另一块是蓄电池（没有vin），用户需要把蓄电池充电的账单识别出来。

--跟踪

推荐用户使用刷卡充电，一辆补电车对应一张充电卡，蓄电池刷卡充电的账单不显示车牌号和vin，车辆自己电池充电启动方式为站点管理员密码充电，账单有显示vin和车牌。

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：chinyee

# gdss_case#22_20201110

问题描述：车牌号和车架号颂盛平台我都录入对的，就差这一台车牌号没显示

--跟踪

【YD】：在平台上没找到相关的充电记录，让吴去确认单号。

【吴】：

【YD】：疑似用户自己提供的VIN不正确，由他们自行修正观察。

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：YD

# gdss_case#21_20200915

问题描述：罗宾森升级颂盛站点4代桩产生bug，要求提供报文分析。(该更新过程从上周五就有更新，经过bug修复等现场问题。已改动过版本)

--跟踪

【YD】：已记录到相关文件，提供了报文。罗宾森分析报文问题原因汇总.xlsx

罗宾森后续更新了新的版本，更新后效果如何暂不清楚。会继续关注跟踪

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：chinyee YD

# gdss_case#20_20200910

问题描述：为什么9月1号和现在导出的日报表数据不同

--跟踪

【chinyee&YD】：难以通过现有方式查出导出的报表文件之间的区别，转研发

【John】：9月8日上传了一批离线充电账单

TAPD:1000146

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：chinyee YD

# gdss_case#19_20200813

问题描述：报表和充电记录导出 日期选择8.1-8.12 时间类型选择结束充电时间

充电总电量不一致

--跟踪

报表会出现充电开始时间为7.31号的充电记录（正常），但充电记录没有这部分记录；

充电记录会出现结束时间为8.13号的充电记录，但报表没有这部分记录。

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：chinyee YD

# gdss_case#18_20200701

问题描述：

广州颂盛公众号点击寻桩充电后看到的界面变了！

原本应该是这样的

--跟踪

现在刷新看看

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：Chinyee

# gdss_case#17_20200526

广州颂盛榄核站点

账单号：20200526030505347349、20200524012541511583、
20200523030111314958、20200523022413366829

异常问题：充电量与平台不符
问题描述：桩与平台数据不一致

--跟踪

【YD】：这是其中一张的分析，另外3张基本是一样的问题。(报文由niewei提供)罗宾森_20200526-1.log

补充：

【客户】：麻烦帮忙分析这条订单的数据 : 颂盛大北站0200526105801472317

【YD】：niewei建议客户先解决上面的问题

【客户】：这个单所属的站点会有计量所来检测所以比较急

【YD】：罗宾森_20200526-2.log(由niewei提供)

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：YD

# gdss_case#16_20200528

问题描述：

广州颂盛大北站

账单号：20200524152830578065、20200524153120840584、 20200524161944876736

麻烦帮我分析一下这三个单号文报，罗宾森那边需要这些文报

--跟踪

【Chinyee】：第一张单状态显示正常，充了一分钟的电，平台记录充电电量为0；第二张单状态是充电点电量与平台不符 设备账单电量61.23 平台账单电量122.14；第三张单状态显示正常 设备账单电量23.8 平台账单电量7450.09

【技】：罗宾森_20200524-3.log 罗宾森_20200524-2.log 罗宾森_20200524-1.log

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：Chinyee

# gdss_case#15_20200525

问题描述：我在颂盛大岗站点已经绑好两张卡了，怎么就不刷不上卡呢

--跟踪

【YD】：确认是站点管理员绑定卡号。查询数据库看看卡号是否有绑其他用户。

【Chinyee】：0010000000000012,0010000000000013分别另外绑定了id：88261749，69410307的用户，建议确认这两个用户是否有使用卡再决定是否解绑。

【客户】：已解绑，帮我查看9、10、11号卡绑定哪里了

【Chinyee】：58181399，41100430，20088347。这三张卡分别绑定了这三个用户id 以后如果要绑卡号 你这边也需要记录一下

【YD】：确认开始的两张卡号可以刷卡充电

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师： YD Chinyee

# gdss_case#14_20200519

广州颂盛大北站点

账单号：20200519000048277368、20200518235932015491、20200518155717891654
桩号：44011300040000250006、44011300040000250008、44011300040000250004
充电时间：
结束时间：
异常问题：充电电量与平台不符
问题描述：此站点安装电能表刷新55.15版本之后出现充电电量与平台不符异常
麻烦查看是否平台原因？

--跟踪

【YD】：转研发(niewei) 研发反应都是桩的问题

这是其中一张单的分析 另外那单估计情况差不多 20200518155717891654这单不是充电电量与平台不符。

罗宾森_20200519-1(1).log

~补充：20200520

罗宾森需要令狐充提供原始数据，四代设备没有log

罗宾森_20200519-2.log

罗宾森：能查到这条机器上一单的充点前电表读数和充电后电表读数吗

3041.82 / 3052.44

罗宾森：后台估算的电量大 感觉不是3052 3093跳变吧？是不是中间出现了0的问题跳变？

没有

--解决

状态（☑表示选定 ）： 已解决 | 处理中 | 暂搁置
售后（跟单）工程师： YD

# gdss_case#13_20200408

问题描述：这是颂盛站点，车架号和车牌号显示这样的

--跟踪

【YD】：与之前金凯瑞的问题不同(参考jkr_case#35_20200408)，不确定原因 转研发

【技术】：这种是车发了不能解析的乱码，如果是社会车辆 不用管，如果是公交车 那要查一下公交车里面是不是写错了。社会车辆的vin是乱写的

--解决

状态（☑表示选定 ）：☑ 已解决 | 处理中 | 暂搁置
售后（跟单）工程师： YD

# gdss_case#12_20200407

问题描述：请问一下，广州颂盛在微信上充值之后为什么要20分钟以后才到账呢

--跟踪

【YD】：这是个别现象？还是很多用户这样？

【客户】：全部都是，从平台升级之后就变成这样了

--解决:
状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师：YD

# gdss_case#11_20200401

问题描述: bo升级2.0计划。时间2020年4月2日（星期四）下午14:30-16:00

--跟踪

【概况】：
1、原广州颂盛后台各子运营商登录账号 升级后 无法第一时间登录。
1.1）原广州颂盛后台各子运营商登录账号 同步至 MC2.0 的方案，包括：原子账号名、角色名、密码不变。权限由广州颂盛配置见1.2 。【John】
1.2） 涉及到权限细节，由广州颂盛 逐个配置。【 广州颂盛 优先级高的子客户 需先配】
1.3） 因子账号的权限配置较复杂， 升级后，也可先提供小程序，进行站点管理员 配置。【执行：广州颂盛】
2、升级2.0过程约持续1个半小时。
3、2020-4-2 上午 将办公室交流桩转至广州颂盛下，确保可以正常充电。【lhc运维】
4、升级后测试 基本充电功能，包括：
4.1）首次关注时弹出的拦截页是否正确。
4.2）扫码充电基本功能。(制作二维码，对应url：http://gdss.linghuchongtech.com/boss/front/opPanel/a.htm?did=xxx)
4.3）检查微信支付功能。
4.4）首页右上角进入“搜索”，检查站点信息：a）是否包含不属于当前运营商的电站。b）数据显示是否正常，如 卡loading。
4.5）现场测试桩端充电功能。【桩厂商、客户执行】
5、bo2升级后提醒 客户 必须配置的项，以下列出几项优先级最高。【执行：广州颂盛】
5.1）配置正确的充值面额。
5.2）配置个人余额阀值（自动停止）。
5.3）见1.3.
6、配置&提供mc2.0 登录管理账号【lhc运维】
7、如客户有MC2.0使用疑问，提供必要支撑。【执行：令狐充 运营】
8、按照约定，升级后，广州颂盛安排车、1台直流桩进行至少一次实测。【执行：广州颂盛】

【计划过程和注意事项】：

主要分2部分：第一部分由 shi 操作、第二部分由john操作。
第一部分：
bo1升级bo2 基于 boVersion:20190810_101130_09614a

1. 更新数据库
   2. mc的boss_token表加⼀一下配置数据
   3. boss的access_token表加⼀一下配置数据
   4 导入sys_setting
   5 update sys_setting
   6 广州颂盛 javris配 营业执照
   7 微信底部菜单更新。
   8 升级前要求客户在腾讯商户平台新增安全支付路径。步骤：【执行：广州颂盛】

   1）登录https://pay.weixin.qq.com/
   2）（可选，如已配置可忽略）依次进入“【账户中心】-》【api安全】-》【设置api秘钥】-》【提供我方秘钥】”
   3）在微信支付平台配置支付授权目录：http://gdss.linghuchongtech.com/boss/newui/ 步骤：依次进入“【产品中心】-【开发配置】-【支付配置】中修改”

#bo2 和bo1差异 sql
create

CREATE TABLE `wx_reply` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`keyword` varchar(32) DEFAULT NULL,
`content` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `access_token` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`access_code` varchar(32) NOT NULL DEFAULT '',
`secret_key` varchar(32) NOT NULL DEFAULT '',
`restrict_ip` varchar(1024) DEFAULT NULL COMMENT '限制客户端ip，多个ip用,隔开',
`is_admin` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0-普通客户端， 1-超级客户端',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `coupon` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(32) NOT NULL DEFAULT '' COMMENT '券名',
`issueCondition` int(11) NOT NULL DEFAULT '1' COMMENT '1-充额定值赠, 2-新用户赠',
`minCharge` int(11) DEFAULT NULL COMMENT '最低充值金额, 分',
`denomination` int(11) NOT NULL DEFAULT '0' COMMENT '面额。 分',
`perNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次赠送券数量',
`packNum` int(11) NOT NULL DEFAULT '0' COMMENT '总份数',
`issuedPackNum` int(11) NOT NULL DEFAULT '0' COMMENT '已送出券份数',
`departIds` varchar(1024) DEFAULT NULL COMMENT '限制部门id, 用|隔开并且前后也要有|',
`subOpIds` varchar(1024) DEFAULT NULL COMMENT '限制子运营商id, 用|隔开并且前后也要有|',
`stationIds` varchar(1024) DEFAULT NULL COMMENT '限制可用站点id. 用|隔开并且前后也要有|',
`useNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次充电可用数量',
`fromDate` datetime NOT NULL COMMENT '上架时间',
`toDate` datetime NOT NULL COMMENT '上架结束时间',
`validType` int(11) NOT NULL DEFAULT '1' COMMENT '1-特定天数有效，2-特定时间段有效',
`validDays` int(11) DEFAULT NULL COMMENT '有效期天数',
`expireFrom` date DEFAULT NULL COMMENT '有效期开始时间',
`expireTo` date DEFAULT NULL COMMENT '有效期结束时间',
`status` int(11) NOT NULL DEFAULT '1' COMMENT '1-有效, 0-下架',
`remark` varchar(1024) DEFAULT NULL COMMENT '描述信息',
`threshold` int(11) NOT NULL DEFAULT '0' COMMENT '最低消费额度, 分',
`C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人',
`C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间',
`C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人',
`C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

CREATE TABLE `member_coupon` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`couponId` int(11) NOT NULL COMMENT '券id',
`memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员id',
`amount` int(11) NOT NULL DEFAULT '0' COMMENT '金额, 分',
`stationIds` varchar(1024) DEFAULT NULL COMMENT '限制可用站点id. 用|隔开并且前后也要有|',
`useNum` int(11) NOT NULL DEFAULT '1' COMMENT '每次充电可用数量',
`validFrom` datetime NOT NULL COMMENT '生效时间',
`expireTime` datetime NOT NULL COMMENT '有效期到期时间',
`billingId` varchar(32) DEFAULT NULL COMMENT '充电账单号',
`mbTransaction` varchar(32) DEFAULT NULL COMMENT 'member_bill 的订单号',
`issuedTime` datetime NOT NULL COMMENT '赠送时间',
`usedTime` datetime DEFAULT NULL COMMENT '使用时间',
`threshold` int(11) NOT NULL DEFAULT '0' COMMENT '最低消费额度, 分',
PRIMARY KEY (`id`),
KEY `couponId` (`couponId`),
KEY `memberId` (`memberId`),
KEY `billingId` (`billingId`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

CREATE TABLE `refund_apply` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员id',
`amount` int(11) DEFAULT NULL COMMENT '退款金额，分',
`commission` int(11) DEFAULT '0' COMMENT '扣取手续费， 分',
`status` int(11) NOT NULL DEFAULT '0' COMMENT '0-待审核，1-审核不通过，2-审核通过',
`progress` int(11) NOT NULL DEFAULT '0' COMMENT '0-用户申请、1-平台审核、2-完成退款, 3-部分退款, 4-退款失败',
`reason` varchar(1024) DEFAULT NULL COMMENT '原因',
`settlementRefundFee` int(11) NOT NULL DEFAULT '0' COMMENT '实际退款金额',
`C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人',
`C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间',
`C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人',
`C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (`id`),
KEY `memberId` (`memberId`)
) ENGINE=InnoDB AUTO_INCREMENT=35 DEFAULT CHARSET=utf8 COMMENT='退款申请';

CREATE TABLE `refund_audit` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`refundId` int(11) NOT NULL COMMENT '退款申请ID',
`status` int(11) NOT NULL DEFAULT '0' COMMENT '0-待审核，1-审核不通过，2-审核通过',
`reason` varchar(1024) DEFAULT NULL COMMENT '原因',
`C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人',
`C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间',
`C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人',
`C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (`id`),
KEY `refundId` (`refundId`)
) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8 COMMENT='退款申请审核历史';

CREATE TABLE `refund_record` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`raId` int(11) DEFAULT NULL COMMENT 'refund_apply的id',
`memberId` varchar(255) NOT NULL DEFAULT '' COMMENT '会员ID',
`openId` varchar(255) DEFAULT NULL COMMENT '微信用户openId',
`mchId` varchar(32) DEFAULT NULL COMMENT '商户号',
`nonceStr` varchar(32) DEFAULT NULL COMMENT '随机字符串',
`sign` varchar(32) DEFAULT NULL COMMENT '签名',
`signType` varchar(32) DEFAULT NULL COMMENT '签名类型. MD5或者HMAC-SHA256',
`transactionId` varchar(32) DEFAULT NULL COMMENT '微信充值订单号',
`outTradeNo` varchar(32) DEFAULT NULL COMMENT '对应wc_payment_msg表的C_INNER_TRANSACTION_NO和member_bill表的C_TRANSACTION',
`outRefundNo` varchar(32) DEFAULT NULL COMMENT '商户退款单号',
`totalFee` int(11) NOT NULL DEFAULT '0' COMMENT '充值订单金额',
`refundFee` int(11) NOT NULL DEFAULT '0' COMMENT '退款金额',
`status` int(11) NOT NULL DEFAULT '1' COMMENT '0-退款失败, 1-退款中, 2-成功退款, 3-撤销',
`resultCode` varchar(16) DEFAULT NULL COMMENT '业务结果。 提交申请结果，不表示退款成功',
`errCode` varchar(32) DEFAULT NULL COMMENT '错误代码',
`errCodeDes` varchar(128) DEFAULT NULL COMMENT '错误代码描述',
`refundId` varchar(32) DEFAULT NULL COMMENT '微信退款单号',
`settlementRefundFee` int(11) NOT NULL DEFAULT '0' COMMENT '应结退款金额',
`C_CREATE_BY` varchar(255) DEFAULT NULL COMMENT '创建人',
`C_CREATE_DATE` datetime DEFAULT NULL COMMENT '创建时间',
`C_UPDATE_BY` varchar(255) DEFAULT NULL COMMENT '更新人',
`C_UPDATE_DATE` datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (`id`),
KEY `raId` (`raId`),
KEY `memberId` (`memberId`)
) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8 COMMENT='退款记录';

CREATE TABLE `member_flag` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(32) NOT NULL DEFAULT '' COMMENT '标签名称',
`type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-固定标签， 1-自定义标签',
`criteria` tinyint(4) DEFAULT NULL COMMENT '固定标签条件',
`params` varchar(256) DEFAULT NULL COMMENT '固定标签条件参数',
`status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '0-下线，1-在线',
`C_CREATE_BY` varchar(255) DEFAULT NULL,
`C_CREATE_DATE` datetime DEFAULT NULL,
`C_UPDATE_BY` varchar(255) DEFAULT NULL,
`C_UPDATE_DATE` datetime DEFAULT NULL,
`C_DELETE_FLAG` tinyint(4) NOT NULL DEFAULT '0' COMMENT '删除标记：0-未删除，1-已删除',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=100 DEFAULT CHARSET=utf8;

CREATE TABLE `member_flag_rel` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`memberId` varchar(255) DEFAULT NULL COMMENT '会员id',
`flagId` int(11) unsigned DEFAULT NULL COMMENT '标签id',
`C_CREATE_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `memberId` (`memberId`),
KEY `flagId` (`flagId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-alter
alter table sub_operator add column `isOut` tinyint(1) DEFAULT '0' COMMENT '1-对方系统计费，0-本方系统计费';
alter table sub_operator add column `domain` varchar(64) DEFAULT NULL COMMENT '第三方系统二维码的域名';
alter table sub_operator add column `urlParamFormat` varchar(1024) DEFAULT NULL COMMENT '二维码链接参数格式';

alter table wc_payment_msg add column `C_REFUND_FEE` int(11) NOT NULL DEFAULT '0' COMMENT '已退款金额. 分';
alter table t_department_account add column `C_PARENT_BILLING` tinyint(1) NOT NULL DEFAULT '0' COMMENT '1-使用上级部门账户扣费';

alter table member add column `C_REFUNDABLE_AMOUNT` int(11) NOT NULL DEFAULT '0' COMMENT '可退款金额, 分';

#alter table recharge_history add column `C_STATION_ID` int(11) DEFAULT NULL COMMENT '站点ID';

alter table recharge_history add (C_CONNECTOR varchar(32) DEFAULT NULL COMMENT '充电接口id',
C_QRCODE varchar(1024) DEFAULT NULL COMMENT '扫码充电二维码'
);

alter table member_bill add column C_COUPON_AMOUNT int(11) DEFAULT '0' COMMENT '代金券扣减金额，分';

ALTER TABLE `recharge_history` ADD INDEX unionBillingId ( `C_UNION_BILLINGID` );
第二部分:
继续更新近期bo2涉及的sql等。

【更新结果】：
1、错误1：充值报错
2、解决：补sql
alter table member_bill add column `C_BALANCE_BEFORE` int(11) DEFAULT NULL COMMENT '消费/充值前余额，分';
alter table member_bill add column `C_BALANCE_AFTER` int(11) DEFAULT NULL COMMENT '消费/充值后余额，分';

--解决

状态（☑表示选定 ）： 已解决 | 处理中 | 暂搁置
售后（跟单）工程师： 施文俊

# gdss_case#10_20200217

问题描述：http://cloud.linghuchongtech.com/DynamicAdmin2/login.html

--跟踪

账号：ssxny
吴小英说这个账号无法登录。
【YD】：我试了下该账号出现了“同时登陆用户数量超过限制”的提示。与之前金凯瑞jkr_case#28_20200211属于同样的问题，故以同样的方式处理。
1、他的账号有同时登陆数量15的限制

客户不按规则操作，故给他同时登录次数设到100，避免再出现

--解决

状态（☑表示选定 ）： ☑已解决 | 处理中 | 暂搁置
售后（跟单）工程师： YD

# gdss_case#9_20200117

问题描述：截止到今 颂盛未处理异常账单统计

提供一份数据：1）未处理异常账单统计。

1）异常账单统计：下表为 2019年3月到至今之未处理异常代码统计

异常代码\统计时间段 | 201903-至今
1-账单丢失 | 261
3- 时间异常 | 219
11-电量丢失 | 294
2-账单丢失（设备离线） | 7
3，4（充电电量异常），5（充电时长异常），8（充电电量与平台不符），9（充电时长与平台不符） | 1
3,5,7（充电时间重叠）,8,9 | 2
3,5,8,9 | 1
3，6（占桩时长异常） | 18
3，8 | 273
3，8，6 | 115
3，8，9 | 3
4，8，6 | 1
6 | 1291
7 | 15
7，8 | 3
7，8，9 | 20
7，8，9，6 | 44
7，9，6 | 15
8 | 77854
8,6 | 32902
8,9 | 536
8,9,6 | 1347
9 | 36
9,6 | 33
合计 | 115291‬

--解决:
状态（☑表示选定 ）： ☑ 已解决 | 处理中 | 暂搁置

数据统计人：Chinyee

# gdss_case#8_20200115

问题描述：旧平台
1.吴小英说他误修复了几张异常账单，希望把那几张单改回异常状态。

2.修复后报表里多了这几张单，颂盛的客人那边会出现前后报表不一致的情况。他想避免这情况

3.旧平台上他反应未修复的账单也能在报表看到20200108165713818444 20200111022016826908 这两个账单是没修复过的

--跟踪

【YD】：

1）2）已修复的，我们不能随意修改客户数据，如果客人问起来您需要向他们解释。
3）颂盛这边一直都是配置成允许异常账单先结算扣款，后续人工修复再补扣，所以报表能看到
【shi】：1、下图配置的意思是允许异常账单先结算扣款，后续人工修复再补扣。
2、一些客户不能及时修复账单，是用了先结算， bo2和bo1的机制是一样的。
3、建议客户及时处理异常账单，特别是公交周期结算前 是必须处理完的。

--解决:
状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 YD

# gdss_case#7_20200113

问题描述：

颂盛旧系统平台
日期：2020-01-13
桩站名称：颂盛站点
手机号：
订单号：20200113131916994301、20200113130454355822、20200113130336691650、20200113130240664036、20200113125312202217、20200113125311761057、20200113125203914204、20200113124854037470、20200113124637079267、20200113124544419307、20200113123331114379、20200113123029340160、20200113122916302241、20200113122040542106、20200113120748494182、20200113120300119547、20200113115846103652、20200113115828334527、20200113114219467743、20200113113813352135
充电桩号：44011300040000200055、、44011300040000250003、44011300040000240001、44011300040000210006、44011300040000200085、44011300040000200054、44011300040000210005、44011300040000200083、44011300040000240002、44011300040000200053、44011300040000200093
充电枪号：
充电时间：
结束时间：
现场网络连接状态：正常
异常状态：充电电量与平台不符
问题描述：充电电量与平台不符，请帮忙查看一下是什么原因，见下图：

--跟踪

【YD】：转研发确认是否与gdss_case#6_20191204的原因一致。
【令技术】：以上账单中出现的“充电电量与平台不符”的异常, 都是由于充电桩在充电前上送心跳的电表总读数均为0， 启动充电后，电表总读数变为一个较大的值 造成的 计算异常。

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 YD

# gdss_case#6_20191204

广州颂盛旧系统平台
日期：2019-12-04
桩站名称：塘坑站点、大岗站点、桥南站点、
手机号：
订单号：
充电桩号：
充电枪号：
时间：2019年11月份
现场网络连接状态：正常
异常状态：金额、峰、平、谷值都为0
问题描述：今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0，见表格下：

20191108112557047049
20191109045929266559
20191112002225771301
20191116000001501830
20191125001902046919
20191127001635518809
20191106044333115970
20191109000104273153

--跟踪

【YD】：这些单都为“账单丢失”，但手动修正里有部分单的修正电量过大。

【niewei】20191205 出现几万度电的情况， 是由于罗宾森桩的电表读数异常造成的。 需要人工处理。

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 YD

# gdss_case#5_201911113

广州颂盛旧系统充电平台

日期：2019-11-13
桩站名称：
手机号：
订单号：20191108112557047049/20191109000104273153/20191109045929266559
充电桩号：
充电枪号：
开始充电时间：
现场网络连接状态：正常
异常状态：
问题描述：现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象

--跟踪

【令】：排查结果如下，都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩， 这个电表读数异常的问题，还存在。

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 何倩怡

# gdss_case#6_20191112

广州颂盛旧系统平台
日期：2019-11-12
桩站名称：广州颂盛桥南充电站
手机号：
订单号：20191112001934329341
充电桩号：44011300040000200061
充电枪号：
开始充电时间：2019-11-12 00:23:38
结束时间：2019-11-12 03:50:36
现场网络连接状态：正常
异常状态：充电量与平台不符

--跟踪

【令】：已转研发
【shi】： 罗宾森桩的问题看来是比较多啊。见附件 罗宾森_20191112001934329341问题排查.log，罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了， 用设备账单来计费。
to 金凯瑞许总：
请关注罗宾森桩程序目前的问题。
联想到贵司伙伴即将在深圳运营，不禁有些担忧。按照我的经验，深圳市社会车辆 充电业务量的数量级是其他城市几倍，用户对充电数据精准性不是公交充电能比的（仅月底看一次数据。）
附件是我司技术对问题账单分析，我按照通俗易懂方式给您解释如下：
1）背景知识：计算机需要按照约定的协议严格执行协议流程。
2）类比举例：
吃饭需要5步，即：1，2，3，4，5。
小明实际吃饭步骤：1,3,4,5 或 1,3,2,4,5 或 1,2,2,2,3,4,5 等类似不按约定协议执行。
3）因为第2项的原因，充电桩在一些情况下（蒙混过关）看来是完成充电了，因为运营环境的复杂，实际上会很大概率出现各种无法预期的异常。
4）第2项 这个问题 从第一个罗宾森桩投入运营上线至今似乎一直存在，未彻底解决。看如何彻底解决。
5）如果 大家认同 运营稳定排第一位。 所谓 RS485 丢包造成，是否可以更换 相应的模块配件。

--解决:
状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 YD

# gdss_case#5_20191031

问题描述：这怎么修复只充了34分钟就要244.40元了

账单号：20191024144331381526

--跟踪

【chinyee】：
该账单号的充电心跳，其中：
1、充电数据是线性增长，未察觉异常
2、2019-10-24 15：10：28到15：17：30之间没有心跳上传，且15：17：30当前状态为8充电异常。
【shi】：异常账单中查到 账单丢失，平台估算电量 128.63度，超正常值。 需转研发分析。
【令狐充技术】：

1、该充电桩在充电过程中发生离线， 所有有一段时间没有心跳；
2、平台估算电量为128.63度， 是因为该充电桩在本次充电之前上传的电表总读数为0所致， 所以这个估算值是不准确的。
开始充电后，电表读数直接跳到92.27
估计这个才是实际值
之后充电中离线了一段时间，恢复后状态已经变成空闲
但是账单一直没上传

【shi】： 疑似电桩老问题未解决，需客户协调罗宾森 厂家 排查解决。

--解决:
状态（√表示选定 ）： 已解决 | √ 处理中 | 暂搁置

售后（跟单）工程师：施文俊 何倩怡

# gdss_case#4_20191028

广州颂盛旧系统充电平台

日期：2019-10-28
桩站名称：
手机号：
订单号：20191027034932615917/20191027142506967167/20191027140716525520/20191024124035938813/20191024144331381526
充电桩号：
充电枪号：
开始充电时间：
现场网络连接状态：正常
异常状态：
问题描述：充电日报表分不到峰平谷值

--跟踪

【令】：以上几个账单都为故障账单，异常类型为账单丢失，人工修正即可

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 何倩怡

# gdss_case#3_20191011

桩站名称：
手机号：
订单号： 20190901220059873970/20190914201254659429/20190914210510578166
问题描述：客户说不是个人扫码付费充电的，是用站点的密码充电的，在后台显示是扫码付费的，客人怀疑我们后台出现问题了
-------------------------
运营商初步排查结果：通过客户提供过来的账号查找充电记录，发现都是个人扫码社会车辆充电。

--跟踪

【shi】：根据客户提供之订单号，查询结果如下：
账单号 | 充电发起人
20190901220059873970 | 明基水产丰少
20190914201254659429 | ZION
根据平台数据证实，以上2条都是个人扫码社会车辆充电。
重要注意： 针对云浮新兴站， 如用站点密码启动 则 充电记录中 昵称都是 “云浮新兴站”（请咨询May，她为客户配置）
【chinyee】：以下图为3个订单号对应的充电发起人，都是个人启动充电

【客】：不认同。并强调：客户说不是个人扫码付费充电的，是用站点的密码充电的，在后台显示是扫码付费的，客人怀疑我们后台出现问题了。
【shi】：我方是根据客户认为有问题的账单号进行分析。如果不认同请其提供进一步证据，比如， 监控视频等其他证据

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊 何倩怡

#

# gdss_case#2_20190927

问题描述：(客户原话)

金凯瑞平台管理员黎美桥:
这个我在金凯瑞后台看到他是管理员的！

金凯瑞平台管理员黎美桥:
而且是后台充值，我们公司没有这个人

-------------------------
运营商初步排查结果：

-------------------------
---跟踪

【令】：使用客户账号登录金凯瑞确实查到此条记录，建议客户仔细回想是否自己进行的此操作。

【运营商】：
我没有操作过
那个微信呢称也不是我
所以奇怪就问下你们那边
那个时间下班了，我也没登录上去操作

【令】：由于可能是客户内部人员使用 管理员 账号进行该操作，暂时不能确定该操作详情，客户那边开始内部查找操作原因。

【运营商】：我查到了，是客户退款了，我领导操作了不好意思

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

# gdss_case#1_20190924

## 平台相关工单
问题描述：广州颂盛大岗公交车站充电站 新站 充电反应平台无记录。
-------------------------
运营商初步排查结果：

-------------------------
---跟踪

【令】：9.24 21:20登录系统 查电站充电记录可以看到 此电站充电记录，无法重现客户问题。

9.25 使用客户提供的账号登录查询“大岗公交站”没有记录，更改成“大岗公交车站”有记录，客户确认是其所需要的数据。

【运营商】：是，那日报表没有记录？

【令】：大岗公交车站充电站 查询条件子运营“颂盛”无法查到数据，“全部运营商”可以查到数据。可能是没有绑定站点与子运营

【运营商】：已经绑定了呀

【令】：如果是今天绑定的 那需要再看看 绑定前的用子运营是查不到

【运营商】：好像是昨天还是今天绑定的

【令】：先观察两天看看

--解决:
状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置

售后（跟单）工程师：施文俊

###番禺项目汇报-20180724
人员：
罗宾森售后
金凯瑞工程人员、项目经理、平台管理员
令狐充平台工程师
番禺场站公交负责人、运维人员
阶段性成果：
a、介绍平台功能和基本使用情况。客户运维、金凯瑞平台运维和令狐充运维 建微信群 计划初期对运营进行支撑和维护。
b、目前支持站点密码为场站之车辆进行充电。
c、少量电桩完成平台接入，并通过公交充电测试。其余待网络、电力设备就绪后逐个接入平台。

联调之问题汇总：
1、桩的程序存在漏洞，界面无法更改服务器IP等参数，暂时由罗宾森售后用烧写器改参数并逐个上线。罗宾森尽快修改。【优先级:高】
2、桩目前无法将VIN上传后台，影响充电记录，无法知道哪些车辆进行了充电，罗宾森尽快修改。【优先级:高】
3、车牌号、vin、集团/企业部门 三者之间的关系录入系统。【优先级:高，由施工和may处理】
4、桩对接平台之刷卡功能。【优先级:中，需罗宾森支持】

标签：
在2019/09/24 20:48上被shi chuck创建

- 评论 （0）
- 附件 （26）
- 记录
- 信息

# Applications

XWiki 10.11.9