邮政储蓄系统“行内异地交易零差错”解决方案探讨 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

一、 系统内异地交易的现状
银行储蓄系统行内异地交易目前存在着以下一些问题需要解决：
1、 异地存取款业务差错率在网络异常时较高，增加了人工调整的工作量。
2、 资金风险大，容易造成资金流失。
3、 前台营业员操作异地交易难度大，对于不成功交易不好判断收付款，开户方未上帐但收款、或者开户方已上帐但不付款容易引起客户不满，造成服务质量下降。
4、 调整不能及时入帐，容易造成客户不满。
5、 异地存取计算单当日不一致，造成上下级核帐不便。
二、 交易现状分析
造成邮政储蓄系统交易现状的原因，归结如下：
1、 网络原因，由于网络的不稳定，交换环节比较多，造成交易不完整。
2、 协议原因，由于协议原因，造成了在网络不顺畅时，自动恢复或者自动重发交易增多，反而加大了网络的负载。
3、 业务流程处理设计容易造成资金风险。
三、 “零差错”方案的优点
该方案在分析了邮政储蓄的新旧协议的基础上，借鉴信用卡的成功技术经验，并结合邮政储蓄的实际状况，提出“零差错” 概念，该方案可以有效解决如下几个问题：
1、 解决目前异地差错率高的问题，做到真正的“零差错” 。
2、 解决目前差错交易需要人工调整的交易手段，全国中心和省中心无须进行人工调整。
3、 解决资金风险问题，真正做到“0风险” 。
4、 解决目前前台营业员操作难的问题，收付款不再困惑。
5、 解决目前客户容易投诉的状况，即存款不成开户方未上帐但收用户款的问题，取款不成但开户方扣帐不付款给用户的状况和人工调整不能及时入帐的问题。
6、 该方案的实质是将交易收付款的判定下放到了操作员。而放在这一级是最准确的。
四、 “零差错”方案同旧方案比较
一笔交易需要做一次请求和一次确认，表面上看是交易增加了一次， 实际上是一样的。因为在目前的状况下，营业员一般做异地交易首先也是先做查询。在做实际的帐务交易，“零差错” 方案的第一次请求本质上就等同于查询。
对帐方式更改。旧系统的对帐是在核对明细之前，“零差错”对帐是核对明细之后。
营业前台发起存款业务请求。
交易中心收到存款业务处理请求，登记流水并转发到全国中心。
全国中心收到存款业务处理请求，登记流水并转发到开户中心。
开户中心收到存款业务处理请求，登记流水并检查帐户状态，如正常，则修改分户帐，将 帐户余额＝原帐户余额＋存款金额，止付金额＝原止付金额＋存款金额，可用余额不变，登记明细帐，登记未登折，记异地通存通兑帐。返回存款请求成功的的应答到全国中心。（该部分说明，受理该笔存款但是临时止付该部分存款金额）。
全国中心收到返回成功的结果，修改该笔存款请求交易流水状态为成功，返回交易中心。
交易中心收到返回成功的结果，修改该笔存款请求交易流水状态为成功，将应答回送网点。
网点收到允许存款的请求后，收客户款，发送存款收款确认到交易中心。
交易中心收到网点的收款确认后，更改该笔交易流水状态为收款状态，登记帐务信息，返回网点成功应答（网点收到应答后打印单据，网点交易完成）。同时转发该笔收款确认到全国中心，发送不成登记SAF表。
全国中心收到交易中心的收款确认后，更改该笔交易流水状态为收款状态，登记帐务信息。返回交易中心成功应答。并转发该笔收款确认到开户中心，发送不成登记SAF表。
开户中心收到全国中心的收款确认后，登记帐务信息，修改分户帐，帐户可用余额＝原帐户可用余额＋存款金额，止付金额＝原止付金额－存款金额，帐户余额不变。返回成功应答到全国中心。
2、 正常的窗口取款业务处理
营业前台发起取款业务请求。
交易中心收到取款业务处理请求，登记流水并转发到全国中心。
全国中心收到取款业务处理请求，登记流水并转发到开户中心。
开户中心收到取款业务处理请求，登记流水并检查帐户状态，如正常，则修改分户帐，将 帐户可用余额＝原帐户可用余额－取款金额，止付金额＝原止付金额＋取款金额，登记明细帐，未登折项，记通存通兑帐。返回取款请求成功的的应答到全国中心。（受理该笔取款并止付该部分取款金额）。
全国中心收到返回成功的结果，修改该笔取款请求交易流水状态为成功，返回交易中心。
交易中心收到返回成功的结果，修改该笔取款请求交易流水状态为成功，将应答回送网点。
网点收到允许取款的请求后，发送取款付款确认到交易中心。
交易中心收到网点的付款确认后，更改该笔交易流水状态为付款状态，登记帐务信息，返回网点成功应答（网点收到应答后打印单据，付客户款，网点交易完成）。同时转发该笔付款确认到全国中心，发送不成登记SAF表。
全国中心收到交易中心的付款确认后，更改该笔交易流水状态为付款状态，登记帐务信息。返回交易中心成功应答。并转发该笔付款确认到开户中心，发送不成登记SAF表。
开户中心收到全国中心的付款确认后，登记帐务信息，修改分户帐，帐户余额＝原帐户余额－取款金额，止付金额＝原止付金额－取款金额，帐户可用余额不变。返回成功应答到全国中心。
另：
3、 正常的ATM取款业务处理
ATM发起取款业务请求。
交易中心收到取款业务处理请求，登记流水并转发到全国中心。
全国中心收到取款业务处理请求，登记流水并转发到开户中心。
开户中心收到取款业务处理请求，登记流水并检查帐户状态，如正常，则修改分户帐，将 帐户可用余额＝原帐户可用余额－取款金额，止付金额＝原止付金额＋取款金额，登记明细帐，未登折项，记通存通兑帐。返回取款请求成功的的应答到全国中心。（受理该笔取款并止付该部分取款金额）。
全国中心收到返回成功的结果，修改该笔取款请求交易流水状态为成功，返回交易中心。
交易中心收到返回成功的结果，修改该笔取款请求交易流水状态为成功，将应答回送ATM，ATM吐钞。
交易中心登记帐务信息，转发该笔付款确认到全国中心，发送不成则登记SAF表。
全国中心收到交易中心的付款确认后，更改该笔交易流水状态为付款状态，登记帐务信息。返回交易中心成功应答。并转发该笔付款确认到开户中心，发送不成登记SAF表。
开户中心收到全国中心的付款确认后，登记帐务信息，修改分户帐，帐户余额＝原帐户余额－取款金额，止付金额＝原止付金额－取款金额，帐户可用余额不变。返回成功应答到全国中心。
4、 异常的存取款处理
异地异常的存取款交易有如下几种状况
网点发起存款请求后没有收到应答，这种状况营业员不需要做收款。虽然用户帐户余额表面上是增加了，但该部分钱不能取走，因为止付了，不存在资金风险。
网点发起取款请求后没有收到应答，这种状况营业员不需要付款，因为储户的帐户余额没有发生变化，不会导致客户投诉。
储户的窗口存取款确认请求没有没有应答，这种状况只发生在网点和交易中心之间网络中断和应用系统异常时，营业员不能确定收付款时需要交易确认或者电话确认中心该笔交易的状态从而决定收付款而不需要向开户方查询。
5、 日终处理
全国中心日切开始，各个中心收到全国中心的日切通知后，将当日各中心（包括全国中心）发起的异地交易未做收付款确认和做过收付款确认的交易归类整理，上传到全国中心。
全国中心将各个交易中心（包括全国中心）上送的报文按照开户方归类整理，生成交易文件，对于未收到的收付款确认交易，进行补记帐。
全国中心按照开户中心分类下发未发生收付款确认的报文和发生过收付款确认的交易文件。
各中心收到全国中心下发的交易文件。逐笔核对。
对于未发生收付款确认的帐户，存款类：帐户余额＝原帐户余额－存款请求额，止付金额＝原止付金额－存款请求额，增加一笔明细，摘要为“冲未收款” ，异地通存通兑科目同方向负数记一笔。取款类：帐户可用余额＝原帐户可用余额＋取款请求额。止付金额＝原止付金额－取款请求额，增加一笔冲正明细，摘要为“冲未付款” ，异地通存通兑科目同方向负数记一笔。
对于发生收付款确认的交易，逐笔核对流水，如果未收到该确认，则按照收到存取款确认的流程处理。
6、 对帐
全国中心和各二级中心进行帐务核对，此时帐务是全平。不会出现不一致。
最初由 pygqs 发布
[B]这个问题不是说在同版后已经解决了么？现在是和其他行比是最第的么？ [/B]
广大业务技术人员解决了系统升级与应用升级同主机切换、大规模数据迁移、大规模人员培训、终端设备不统一等一系列难题，确保按计划用 18个月完成全部工作。 2005年一季度，统一版本工程上线后效果明显：异地交易差错率由上线前的 48.6个 /万笔下降为 0.54个 /万笔，远低于商业银行 5.75个 /万笔的平均差错率水平；跨行交易成功率由上线前的 79%提高到 97.49%，在各商业银行中的排名由上线前的末位上升到前列。统一版本投入运行后由于系统稳定且处理能力大增，创造了邮政储蓄发展史上三个记录———首季存款余额净增超 1000亿元、首季异地交易额超 2000亿元、首季跨行交易量超 3000万笔。
目前还是有差错,目前这个方案是要控制为0差错!
最初由 nauxd 发布
[B]取款的时候密码的校验在第几步吖?请求和确认的时候都校验吗 [/B]
第一步! 确认不用校验!
单信息系统VS双信息系统
目前国内核心系统基本是单信息系统，所以避免不了差错。只要在一定范围内，应该可以认可，如果采用确认方式，只是将双信息系统的日终确认修改成实时手工确认。
同时个人感觉只要设置SAF，就有无法避免差错
PS：目前贷记卡系统都是采用双信息系统，所以的日间交易不记账，只是类似于借记卡的冻结