在POS机时代，商户和收单行仍以日终批量方式结算
菜鸟 [8:58]: 问个问题，现在信用卡刷卡后，收单行是不是实时将钱记入商户的账号，还是商户在日终时凭签购单请求收单行批量进账？ 大师M [8:59]: 日终批次 菜鸟 [9:00]: 收单行和发卡行之间的划账 又要一个日终批次了？ 那商户在提供商品后，岂不是要等两天才能拿到钱？ 大师M [9:01]: 有的还很多天
Month: July 2008
ISO 8583 [wiki]
ISO 8583 From Wikipedia, the free encyclopedia Jump to: navigation, search ISO 8583 Standard for Financial Transaction Card Originated Messages – Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. Introduction A card-based transaction typically travels from a transaction acquiring device, such …
几个客服相关术语
CTI — Computer Telephony Integration IVR — Interactive Voice Response CSR — Customer Service Representative
优化AppFuse 1.9.3 SpringMVC IBatis：使后台管理功能更现实
AppFuse提供的某些功能和在某方面表现出来的风格使它不像一个典型的业务系统，我们应该裁减、修改一些东西，使它符合我们的习惯。本文谨介绍一下本人在应用AppFuse所做的改动，包括改动的功能和改动的方法。 1. 用户属性重新配置 a. 调整User的属性。去掉User Bean及User表中的非必要属性，只保留一些最基本的属性，并新增一个fullName属性作为用户真实姓名 b. 禁止删除用户：去掉UserManager中的 removeUser方法，去掉userForm.jsp中的 “删除”按钮 c. 禁止修改用户名：修改userForm.jsp d. 用户中的enable, expired,locked 三个属性中只要使用enable一个就行了。其他的两个应从userForm.jsp 中抹除，不过，下层代码和数据库不必修改 2. 二级或多级管理员体系 一个业务系统里应设置两级或两级以上后台管理员，较低级管理员执行日常的、不太危险的管理操作，较高级管理员则有权执行危险性较高的操作，而且只在必要的情况下动手。在用户数年较多的系统中，较低级的管理员可以有多个，较高级管理员则控制在一两个之内。个人认为这是平衡操作风险与管理工作量的较好模式。 若在AppFuse中采用这种模式，则需要修改的地方包括且不限于：security.xml 、 UserSecurityAdvice.java 和 menu-config.xml 另外，我还建议将用户管理权限的判断放到 UserSecurityAdvice代码中，而不是通过 Spring-Bean "userManagerSecurity" （见security.xml）来实现。这样做的好处是免于在security.xml中重载userManager
优化AppFuse 1.9.3 SpringMVC IBatis：适配Oracle数据库
原版本中的sql是mysql风格的，它和Oracle数据库不太兼容。 主要问题有： 1. 自增主键问题。Oracle中没有自增主键，须自定义Sequence。具体有： a. 新增一个专用于权限子系统的sequence CREATE SEQUENCE security_sequence INCREMENT BY 1 — 每次加几个 START WITH 1 — 从1开始计数 NOMAXVALUE — 不设置最大值 NOCYCLE — 一直累加，不循环 CACHE 10; b.修改UserSql.xml中的addUser，应用这个sequence 2. sql语句的分号问题。使用Ibatis + Oracle时，sql中不能使用分号。因此应去掉ibatis sql文件中各语句的分号
优化AppFuse 1.9.3 SpringMVC IBatis：移除文件上传功能
正式的业务系统里用不上这个功能，应移除。具体办法： 去掉fileUploadController这个bean及其相应的class 、url 、jsp和validation.xml
优化AppFuse 1.9.3 SpringMVC IBatis：去除Bug
我在使用 AppFuse_1.9.3_SpringMVC_IBatis 时发现了一些Bug，现在我把这些bug给出来，并提供个人的解决办法。不过，有的BUG我在处理时只记录了解决办法，却没有记录问题，不好意思…… Bug1: 不记得了…… 解决办法：UserDaoiBatis.java文件中有句话 List userRoles = getSqlMapClientTemplate().queryForList("getUserRoles", user.getUsername()); 其中的getUsername()应改为 getId() 或者直接去掉这句话，因为它没有任何作用 Bug2：在后台为某用户分配多个角色，结果该用户只获得了所选角色中的第一个 解决办法：在UserDaoiBatis.java文件中找到 if (userRoles.isEmpty()) { getSqlMapClientTemplate().update("addUserRole", newRole); } 然后去掉这个 if条件 Bug3：admin menu按权限显示时出莫名奇妙的问题 解决办法：将struts-menu版本升级到 2.4.3，并将cssHorizontalMenu.vm 和 cssVerticalMenu.vm替换为 appFuse2.0中的版本。 Bug4：不记得了…… 解决办法：UserFormController中的 return new ModelAndView(new …
两个系统如果共用一套用户，要注意是否为一对一
要注意是否存在精确的一对一关系 假设两个系统分别为系统A和系统B 1.A中的某个用户在B中一定有吗？ 2.A中的用户Jude在B中也叫Jude吗？ 会不会冒用？ 3.A中的用户Jude在B中仅对应一个用户吗？ 会不会对应多个？
要主动考虑会计复核
验证金融系统的正确性时，除了按程序本身的逻辑设计用例进行测试，还可以通过金融业务中常用的会计复核机制来实现 而且有时候，这不仅是一种可选的手段，可能还是一个必须满足的条件：很多金融业务就要求通过审计手段来保证业务的正确。
反思：不要过度追求参数化
以权限配置为例，在用户、角色、权利 三个实体中，角色和权利其实都应该写死，管理员只需配置用户和角色的关系就可以了。 否则： 1. 管理员直接配置业务逻辑，增加业务风险。管理员直接配置了角色和权利，相当于直接干预了业务逻辑，这给用户带来灵活性，但也带来了比较大的风险 —- 管理员配错权限怎么办? 比如管理员把“系统管理员”这一角色的管理权利给取消了，那怎么办？ 2. 这给代码组织、程序发布也带来了麻烦。由于配置的东西太多，配置项可能写在SQL语句文件中，或者写在XML配置文件中，当权限规则发生微调时，这些文件也会发生微调，部署到生产系统后又要进行微调，经验证明，这很容易出错，因为XML和SQL的语法语义检查没有编译器来保证；而且，比起直接复制JAVA CLASS文件，部署XML和SQL的烦恼指数也高很多