|
|
张兄，终于出现了
最初由 holyfei 发布
[B]处理错单问题的最好方法是回退，统计表做负统计，然后从预处理重新处理。
发生这种错误的原因基本是参数没有维护好，而且错误一般只需处理一次，在下次基本问题已经改正，不会再犯，所以该功能用到的机会不大，但又不能没有，否则靠手工处理还是很麻烦的！ [/B]
关于结算：
1.我们要求规范，我们期望规范，我们呼吁规范
但是
——人生不如意，十之八九；
2.一旦不规范，我们怎么做？
从结算的错单回收的角度讲，大致有：
a。参数的有无问题：这个可以在应用系统中给予报警示错，等待系统的回收策略；
b。参数的正确性问题：即参数本身是有的，只是相应地信息提供错了，或者维护错了，但是系统毕竟不是万能的，它会当作正确的参数按照流程走到底，事实上错误已经造成了。
——遇到马虎一点的用户，显然不一定发现，只是最终报表什么地有所不偏差，管他呢，随便找点理由就可以糊过了——毕竟是结算吗。——恭喜了
——遇到认真一点的用户，惨了，从前到后，问题如何产生的，影响面有多大，如何解决——还得搞的一条不差，一分不差。——同样的，我也恭喜你了——如果正好在帐期的左右的话，你可以安排几个人日的加班和不睡觉了。
c。回收回退策略：
回收：因为系统示错，没有进正确的统计等后续流程，显然可以直接从错单库中给予提取，利用小闭环重新处理（前提是将参数维护了之后——从无到有），还有一个就是别忘了对于错单统计等信息作负统计。
回退：说来话长了。
从流程的角度讲，没有卡壳。但是就是结果不对。
这个时候需要针对不同的产生原因地可能性分别描述，具体问题具体分析。
1.话单信息解析错误（甚至于交换机下单信息不够准确、全面），没有办法，可以回退，但是往往不建议这样子做，一方面是由于没有什么效果，解决不了最终问题，还有就是回退的资源太大，说不定得不偿失。——建议执行清表清库、清文件系统等操作（如何设计上已然考虑的话），取原始文件重新处理。
——快速、高效、安全、省心（多快好省 ）
2.业务逻辑参数的错误维护：
回退，负统计。
这个中间，其实又可以适当地取巧——如果在设计上，你是真正懂结算业务的，同时又是采用了参数驱动等思想的应用（不排除还有其他的技术实现手段），还有就是对于一些参数的维护进行了一些地提炼和异常设想，必要的时候可以通过调整参数，重新结算达到目的，基本上回避了回退。
——当然，有些情况是没有办法回避的，那么请你面对现实吧，如果，系统的承包商还行的话，这点问题应该没有问题的。
好了，时间来不及了，我要去加班了。
faint。不周之处，请大家见谅。
如果有空，张兄不妨电话我。
——那边的兄弟不卖力？他们这些都是应该是知道的，起码的要求。 |
|
楼主: mengmeng
IP卡
狗仔卡
发表于 2003-8-21 12:59
显身卡
楼主
