- 主题:etc为毛不这样搞？
中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
【 在 monkey80 的大作中提到: 】
: 是天经地义，必须得显示，不过实现起来有技术难度，正在解决中。工期这么紧，只能先解决能用的问题，再解决好用的问题，被老百姓骂好过丢乌纱帽。。
--
FROM 223.167.152.*
显示的问题其实还是小问题，无非是当时看不到扣费金额，如果有问题不能当时PK罢了。大问题是ETC的扣费明细和银行卡的扣费明细对不上，甚至出现一条ETC扣费记录对应多条银行卡的重复扣费操作，这他妈的就吓人了，谁还敢用ETC啊
另外还有走高速辅路也被收了费的，这ETC感应器是黑洞吗，周围的车只要带ETC OBU的都要吸进去，雁过拔毛啊
【 在 nezo (nezo) 的大作中提到: 】
中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
【 在 monkey80 的大作中提到: 】
: 是天经地义，必须得显示，不过实现起来有技术难度，正在解决中。工期这么紧，只能先解决能用的问题，再解决好用的问题，被老百姓骂好过丢乌纱帽。。
--
修改:wangjiguo FROM 221.221.235.*
FROM 221.221.235.*
没错。国家给补贴了很多钱！！！
【 在 GoogleGlass 的大作中提到: 】
: 这本来是最经济高效的办法，但是高速公司却没某任何好处。
: 所以他们就借着改革掺沙子，非要搞按路径收费，他们肯定测算过这样能多收不少钱。
:
: ...................
--
FROM 123.114.46.*
哈哈哈！！！
【 在 wangjiguo 的大作中提到: 】
: 显示的问题其实还是小问题，无非是当时看不到扣费金额，如果有问题不能当时PK罢了。大问题是ETC的扣费明细和银行卡的扣费明细对不上，甚至出现一条ETC扣费记录对应多条银行卡的重复扣费操作，这他妈的就吓人了，谁还敢用ETC啊
: 另外还有走高速辅路也被收了费的，这ETC感应器是黑洞吗，周围的车只要带ETC OBU的都要吸进去，雁过拔毛啊
: 中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
--
FROM 123.114.46.*
你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
【 在 nezo 的大作中提到: 】
: 中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
: 【 在 monkey80 的大作中提到: 】
: : 是天经地义，必须得显示，不过实现起来有技术难度，正在解决中。工期这么紧，只能先解决能用的问题，再解决好用的问题，被老百姓骂好过丢乌纱帽。。
: ...................
--来自微水木3.5.1
--
FROM 223.104.3.*
更说不过去的是，如果350毫秒内就能读取到所有分段的明细消费的话，为何用户自己不能马上收到这些明细，要等半个月甚至更久？
【 在 monkey80 (monkey) 的大作中提到: 】
你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
【 在 nezo 的大作中提到: 】
: 中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
: 【 在 monkey80 的大作中提到: 】
: : 是天经地义，必须得显示，不过实现起来有技术难度，正在解决中。工期这么紧，只能先解决能用的问题，再解决好用的问题，被老百姓骂好过丢乌纱帽。。
: ...................
--来自微水木3.5.1
--
FROM 221.221.235.*
总结额一定要到最后出闸口再算吗？没经过一个闸口其实都在计费了，同步算就可以了，出口的时候只需要加上最近的一次扣费信息就可以了
你在京东购物，购物车的金额难道不是随着你每次往里加商品一直在变吗？强东也没说你点结算的时候在算出总结额来
【 在 monkey80 的大作中提到: 】
: 你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
--
FROM 192.176.1.*
因为现在系统最多算个α版，问题很多
【 在 wangjiguo 的大作中提到: 】
: 更说不过去的是，如果350毫秒内就能读取到所有分段的明细消费的话，为何用户自己不能马上收到这些明细，要等半个月甚至更久？
:
: 【 在 monkey80 (monkey) 的大作中提到: 】
: ...................
--来自微水木3.5.1
--
FROM 223.104.3.*
这个为啥要到出口才从各省调取，每经过一个门架就进行累加并把累加结果并传送到总调配中心，到出口时提取这个累加数再加上最后一段的费用不就完了。
【 在 monkey80 的大作中提到: 】
: 你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
--
FROM 61.129.7.*
所以我打算半年内非免费期不上高速了
【 在 monkey80 (monkey) 的大作中提到: 】
因为现在系统最多算个α版，问题很多
【 在 wangjiguo 的大作中提到: 】
: 更说不过去的是，如果350毫秒内就能读取到所有分段的明细消费的话，为何用户自己不能马上收到这些明细，要等半个月甚至更久？
:
: 【 在 monkey80 (monkey) 的大作中提到: 】
: ...................
--来自微水木3.5.1
--
FROM 221.221.235.*