V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
yeyeye
V2EX  ›  问与答

PHP 编写关系到财务这样重要的系统,设计应该每次变动都算账,还是月底统一算账?

  •  
  •   yeyeye · 2016-05-07 22:57:23 +08:00 · 3088 次点击
    这是一个创建于 2882 天前的主题,其中的信息可能已经有所发展或是发生改变。
    上次说到要写一个简单的系统(本人是 PHP 菜鸟),但是涉及到钱的问题,单据的增删改都将影响金钱的支付和收取,在付款多的情况下,别人当然很乐意悄悄的收下,付款如果少了,那么对方也会计算出来找我们对质……

    所以说准确性要够高……但是对于单据的增删改,每个单据里每一条物品的增删改,都将影响金钱问题,涉及到如此精密的操作,生怕哪里没设计好,产生 BUG ,造成经济损失,同时因为涉及到钱钱钱,每次都要小心翼翼的修改代码……

    如此一来会产生 3 个代码设计方向,还请指导。

    (1)单据的增删改及作废不影响钱的数据,等到单据审核后,产生金钱影响,将数值更新到各个相关的表,然后就不准再改了,打死也不准改。
    (2)因为我这个系统,和客户算钱的时候(找客户要钱的时候),一般都是算一段时间的帐,偏向于记账,所以想法就是客户要结账的时候,再计算所有单据的钱,生成报表,这时候来变更各表金钱的数值,另外每个月生成报表(比如每个客户的消费、欠款情况),并锁定起来不准再改这个月的数据。
    (3)单据中每个物品的增删改及作废,都实时的影响钱的数值(包括单据金额,每个客户,月帐,年帐及其他相关的)

    对于以上 3 种情况 哪种更好呢? 其实我更偏向于第三种 虽然每次都要修改很多地方 甚至设计上也很繁琐 但是相对的数据更准确,但是一旦出现设计上的失误,就会发生查起来比较麻烦的问题(担心使用者同时也过于信任系统导致损失,我们目前的系统在有些环节的数据是有所不精准的,所以重新写过一个就得考虑良多),第二条也不错,但是问题就是如果数据录入错了,时间久了难以查单据啊。很容易忽略掉错误的单据?第一种看起来不错,其实和第三种类似,但是编写代码的时候会简单许多。因为复杂操作频率较低

    另外一个考虑就是要用 php 编写,所以有点担心集中处理数据的时候效率问题或数据库占用 cpu 太久被服务商吊打。不知道各位达人在这种场景的时候是以哪种方式呢?好吧我猜一下,应该是第三种,每次有哪怕是再细微的变更,也影响各个表的所有相关数值……?

    写得有点罗嗦了,用词也不是很专业,感谢您耐心看完。
    7 条回复    2016-05-09 00:06:14 +08:00
    klesh
        1
    klesh  
       2016-05-07 23:39:03 +08:00   ❤️ 3
    一般的电商系统会采用第 3 种,像淘宝、京东这些,是转化到余额再提现。这种方案要考虑 3 大问题:
    1. 一致性,订单在结算时,必须同时完成订单的状态转化以及余额的变化,要么一起成功,要么一起失败,可通过事务解决。
    2. 原子性,要考虑客户端并发提交结算请求,必须保证事务只执行一次。
    3. 安全性,牵涉到钱的问题,那整个系统必须尽量安全,起码 sql 注入是必须要考虑并防止的,数据 库的保密工作要做好,不允许外部连接之类是必须的,备份要做好。 https 神马的必须要上,金额巨大必须要有第三方校验。
    至少追踪,那日志系统是必须的,每次余额的变化都要写日志, 把当前余额,变动量,什么原因,相关订单号纪录起来以便追溯。

    不过你们是月结,其实方案 2 也挺不错的,复杂性会低很多,也不用去冻结什么的,你反正给他一个搜索指定时间段内的数据,然后统计给结果,至于实际上财务怎么去结算由他们自己去纪录,这样风险反而更小。方案 1 是最不现实的,只要有人用的东西就不可能存在绝对不犯错的情况,不允许修改,错了怎么办?

    无论采用什么方案, cpu 及数据库负载不会太大的,我算你每天一万单,一个月也不过区区三十万条纪录, sql 操作很快的,若是分单结算,瞬间负载不值一提。

    无论采用哪种方案,人工校验都是必须的!隔一段时间对一下帐很有必要,特别是初期实施的时候,即使你写的逻辑滴水不露,服务器上面也不可能百分百安全。

    总而言之,事世无绝对,你要考虑到第一个相关的部分都可能出问题,可能被攻破,可能会崩溃。
    yeyeye
        2
    yeyeye  
    OP
       2016-05-08 01:22:21 +08:00
    @klesh

    关于你说的一致性 事务我也是想到了的 到时候肯定用它!
    关于你说的原子性 我接入过 QQ 互联接口 知道用随机字符来防止重复提交 !
    关于你说的安全性 我也充分觉得必须上 https 尽可能的保障安全(多地要使用这个系统) SQL 部分全部绑定数据(没有这方面的经验,但是为了防止 SQL 注入的问题 这头也是必须的),没有上传模块,所以搞定 SQL 注入和 XSS 以及 HTTPS 就基本上 OK 啦 我甚至考虑了前端只暴露出一个验证用户密码的接口 后端目录名随机生成个 至于服务器安全…… 说真的 我倒是最担心操作人员的账号安全问题 所以我认为锁数据是有必要的 当然锁之前肯定是要每天人工检查检查 想象很完美 或许要办到太难了 但是我这边有一个特性 就是单据是要传给另一人逐个操作的(每一小单都是要联系客户的 照着单据来联系 有错可以调整回来 除非忘记了……)

    由于人力不充足 如果在钱上出毛病亏的也是自家的(家人创业) 所以好犹豫 哈哈 好啦 感谢你的耐心解答以及补充 帮助很大!
    Mac
        3
    Mac  
       2016-05-08 04:36:13 +08:00   ❤️ 1
    这取决于你的数据量,小企业的财务数据,随便你用 1 、 2 、 3 都完全没有问题。你完全不用考虑性能问题,该考虑的是前端怎样让财务的操作更简便,比如对账和销帐。
    dxwwym
        4
    dxwwym  
       2016-05-08 08:22:29 +08:00 via iPhone   ❤️ 1
    作为一名对会计有一些了解的人的给几点建议
    1.一般企业财务系统记账原则要按权责发生制而不是收付实现制,应收、应付、预收、预付账款的概念。
    2.不论出于什么原因要删除某笔记账数据都算抹账或者叫红蓝字冲正,而不是简单的从数据库删除该笔数据,原则上要对原有数据进行保留冲正该笔后再记正确的。
    3.考虑数据正确性校验可以参考银行的做法每日批量,也可以每 10 日进行批量校验,最起码月底要试算平衡。
    4.如果是单独的进销存...可以设计的宽松一些
    billlee
        5
    billlee  
       2016-05-08 14:11:21 +08:00   ❤️ 1
    就缺一个产品经理了
    sensui7
        6
    sensui7  
       2016-05-08 20:43:05 +08:00   ❤️ 1
    @dxwwym 传说中的"有借必有贷, 借贷必相等"
    yeyeye
        7
    yeyeye  
    OP
       2016-05-09 00:06:14 +08:00
    @Mac 业务量和数据库性能比起来是很少了 用户操作问题慢慢优化吧……谢谢!


    @dxwwym 我这边有个好处就是流程简单 东西经手后有问题也是要再联络的 否则就是按照系统打印出来的单据一个个处理 所以如果操作人员写错了 在流程完毕前改好就行了 然后专人审核一下每天的单据情况 一般没什么问题的 财务方面的知识不多 多谢补充 谢谢!

    @billlee 由于编程经验较少 对财务知识也了解少 所以多了解一下才动手啊 不然以后出问题就惨了 编程经验少可以慢慢写 但是逻辑不先考虑好 以后就得改死人了……

    @sensui7 谢谢
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1250 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 18:00 · PVG 02:00 · LAX 11:00 · JFK 14:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.