- 主题:etc为毛不这样搞？
是这个理
先看看屁民的反应。
【 在 wangjiguo 的大作中提到: 】
: 先有目的，再根据目的去找方法。目的就是不想让你当时就看到消费总额，设计字段时当然就必须“忘记”定义这个字段了
: 这个是很自然的逻辑，都想不到?我真不太相信。
--
FROM 223.167.152.*
现在再在数据库里加上这个字段，然后增加使用这个字段进行随时累计消费总额的功能，并没有什么技术上的问题。
【 在 nezo (nezo) 的大作中提到: 】
是这个理
先看看屁民的反应。
【 在 wangjiguo 的大作中提到: 】
: 先有目的，再根据目的去找方法。目的就是不想让你当时就看到消费总额，设计字段时当然就必须“忘记”定义这个字段了
: 这个是很自然的逻辑，都想不到?我真不太相信。
--
FROM 221.221.235.*
我的意思是，跟后面账单和扣费对不上相比，显示只是小问题而已
其实出口显示总金额、ETC APP账单总金额、银行扣费总金额这三个数字，有可能两两都不一样。这才是最大的问题。
出口显示10元，银行卡扣费10000，你能忍么？
所以只要求出口显示总金额是不够的，应该在此基础上，出口出去一分钟之内收到银行扣费短信，且扣费金额和出口显示总金额一致，扣费短信中含有本次路线的明细，包含进口、出口、总里程、上下口的具体时间，每段收费明细等等，这样才行。
【 在 nezo (nezo) 的大作中提到: 】
其他问题先不论。
显示还真不是小问题，当时花了钱半个月才知道
就和你外出吃饭购物，人家让你刷卡，但半个月后你才知道花了多少钱一样。
【 在 wangjiguo 的大作中提到: 】
: 显示的问题其实还是小问题，无非是当时看不到扣费金额，如果有问题不能当时PK罢了。大问题是ETC的扣费明细和银行卡的扣费明细对不上，甚至出现一条ETC扣费记录对应多条银行卡的重复扣费操作，这他妈的就吓人了，谁还敢用ETC啊
: 另外还有走高速辅路也被收了费的，这ETC感应器是黑洞吗，周围的车只要带ETC OBU的都要吸进去，雁过拔毛啊
: 中间逻辑也许有技术难度，都算出结果了，“显示”能有什么技术难度，欺负我们不懂啊。
--
修改:wangjiguo FROM 221.221.235.*
FROM 221.221.235.*
只要车牌号是真的，下次上高速的时候补上。AND 这个属于另外一个问题，不能因为部分极低底线行为的人，导致大家一起难受。
AND 我说的也是改进软件问题。
AND 仅在出口处发一条扣费短信对于ETC方来说肯定是改进后可以的，但是问题是如果用户是绑定的信用卡，又开通了扣费提醒（短信或者微信），照样会被吵死，因为这个提醒不是ETC发出，是银行发出。
【 在 monkey80 的大作中提到: 】
: 车都跑了补算有啥用？新疆，内蒙这些地势平坦地区，拆开护栏就能下高速了。当务之急应该改进软件，仅在出口时发一条扣费总额短信，中间扣费对用户应该透明，用户不关心某一区段的费用。
--
FROM 111.201.10.*
车开到出口才想起来去部中心调数据，这也太笨了吧
比如说我从北京去山东，只要一出北京界，北京的扣费数据应该立刻从北京传递到河北，同时上传部中心备份;等到从河北进入山东后，累计扣费数据随即也传递到山东，并上传部中心。等到从山东出高速，扣费数据都在山东数据中心提取出来就够了，这样的话，和以前各省本地核算在在时间上就没有区别了
而且，也不需要经过一次龙门架就和银行结算费用，只需要省数据中心对经过龙门架产生的费用进行累加即可，等到出高速后再与银行进行结算。这样也减轻了银行的的通信负载和计算负载。
【 在 monkey80 的大作中提到: 】
: 你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
--
修改:inmatrix FROM 125.39.45.*
FROM 125.39.45.*
目前的方案，从顶层设计上就不靠谱。前面有人说是层层转包给了皮包公司，看着很像。根本不像是有大系统设计经验的人和公司搞出来的东西
【 在 inmatrix 的大作中提到: 】
: 车开到出口才想起来去部中心调数据，这也太笨了吧
: 比如说我从北京去山东，只要一出北京界，北京的扣费数据应该立刻从北京传递到河北，同时上传部中心备份;等到从河北进入山东后，累计扣费数据随即也传递到山东，并上传部中心。等到从山东出高速，扣费数据都在山东数据中心提取出来就够了，这样的话，和以前各省本地核算在在时间上就没有区别了
: 而且，也不需要经过一次龙门架就和银行结算费用，只需要省数据中心对经过龙门架产生的费用进行累加即可，等到出高速后再与银行进行结算。这样也减轻了银行的的通信负载和计算负载。
: ...................
--
FROM 125.39.45.*
上面的算法，再把每个龙门架的扣费以图形化的形式进行费用分段显示，让用户在ETC APP上可以查看，就更完美了。
【 在 inmatrix (bright) 的大作中提到: 】
车开到出口才想起来去部中心调数据，这也太笨了吧
比如说我从北京去山东，只要一出北京界，北京的扣费数据应该立刻从北京传递到河北，同时上传部中心备份;等到从河北进入山东后，累计扣费数据随即也传递到山东，并上传部中心。等到从山东出高速，扣费数据都在山东数据中心提取出来就够了，这样的话，和以前各省本地核算在在时间上就没有区别了
而且，也不需要经过一次龙门架就和银行结算费用，只需要省数据中心对经过龙门架产生的费用进行累加即可，等到出高速后再与银行进行结算。这样也减轻了银行的的通信负载和计算负载。
【 在 monkey80 的大作中提到: 】
: 你还就是不懂啊，没有你想的那么容易。。出口要知道总费额，需要出口车道从省中心调取这辆车所有门架扣费信息累加， 如果是跨省车辆，还要通过部中心调取沿线省份扣费记录，这都不是问题，问题是这些操作必须在350毫秒内完成。。一点点网络延迟就失败了。
--
修改:inmatrix FROM 125.39.45.*
FROM 221.221.235.*
编程和app这些都是小问题。顶层设计，总体方案和技术路线才是大问题，开头方向错了后面纠错的成本大了去了
【 在 wangjiguo 的大作中提到: 】
: 上面的算法，再把每个龙门架的扣费以图形化的形式进行费用分段显示，让用户在ETC APP上可以查看，就更完美了。
: 车开到出口才想起来去部中心调数据，这也太笨了吧
: 比如说我从北京去山东，只要一出北京界，北京的扣费数据应该立刻从北京传递到河北，同时上传部中心备份;等到从河北进入山东后，累计扣费数据随即也传递到山东，并上传部中心。等到从山东出高速，扣费数据都在山东数据中心提取出来就够了，这样的话，和以前各省本地核算在在时间上就没有区别了
: ...................
--
FROM 125.39.45.*
顶层设计根本就是不想让用户知道扣了多少，然后用数量众多的扣费短信掩盖后台乱扣费（就是银行扣费和ETC明细不能一一对应，尤其是金额会有差异）的手段，让用户眼花缭乱无从查起而不得不认栽
【 在 inmatrix (bright) 的大作中提到: 】
编程和app这些都是小问题。顶层设计，总体方案和技术路线才是大问题，开头方向错了后面纠错的成本大了去了
【 在 wangjiguo 的大作中提到: 】
: 上面的算法，再把每个龙门架的扣费以图形化的形式进行费用分段显示，让用户在ETC APP上可以查看，就更完美了。
: 车开到出口才想起来去部中心调数据，这也太笨了吧
: 比如说我从北京去山东，只要一出北京界，北京的扣费数据应该立刻从北京传递到河北，同时上传部中心备份;等到从河北进入山东后，累计扣费数据随即也传递到山东，并上传部中心。等到从山东出高速，扣费数据都在山东数据中心提取出来就够了，这样的话，和以前各省本地核算在在时间上就没有区别了
: ...................
--
FROM 221.221.235.*
真是难以置信，一个国家层面搞得东西居然这么荒唐。
【 在 wangjiguo 的大作中提到: 】
: 顶层设计根本就是不想让用户知道扣了多少，然后用数量众多的扣费短信掩盖后台乱扣费（就是银行扣费和ETC明细不能一一对应，尤其是金额会有差异）的手段，让用户眼花缭乱无从查起而不得不认栽
: 编程和app这些都是小问题。顶层设计，总体方案和技术路线才是大问题，开头方向错了后面纠错的成本大了去了
--
FROM 223.167.152.*