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

[yeyeye]

上次说到要写一个简单的系统（本人是 PHP 菜鸟），但是涉及到钱的问题，单据的增删改都将影响金钱的支付和收取，在付款多的情况下，别人当然很乐意悄悄的收下，付款如果少了，那么对方也会计算出来找我们对质……

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

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

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

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

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

写得有点罗嗦了，用词也不是很专业，感谢您耐心看完。

[klesh]

一般的电商系统会采用第 3 种，像淘宝、京东这些，是转化到余额再提现。这种方案要考虑 3 大问题：
1. 一致性，订单在结算时，必须同时完成订单的状态转化以及余额的变化，要么一起成功，要么一起失败，可通过事务解决。
2. 原子性，要考虑客户端并发提交结算请求，必须保证事务只执行一次。
3. 安全性，牵涉到钱的问题，那整个系统必须尽量安全，起码 sql 注入是必须要考虑并防止的，数据 库的保密工作要做好，不允许外部连接之类是必须的，备份要做好。 https 神马的必须要上，金额巨大必须要有第三方校验。
至少追踪，那日志系统是必须的，每次余额的变化都要写日志， 把当前余额，变动量，什么原因，相关订单号纪录起来以便追溯。

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

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

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

总而言之，事世无绝对，你要考虑到第一个相关的部分都可能出问题，可能被攻破，可能会崩溃。

[yeyeye]

@klesh

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

由于人力不充足 如果在钱上出毛病亏的也是自家的（家人创业） 所以好犹豫 哈哈 好啦 感谢你的耐心解答以及补充 帮助很大！

[Mac]

这取决于你的数据量，小企业的财务数据，随便你用 1 、 2 、 3 都完全没有问题。你完全不用考虑性能问题，该考虑的是前端怎样让财务的操作更简便，比如对账和销帐。

[dxwwym]

作为一名对会计有一些了解的人的给几点建议
1.一般企业财务系统记账原则要按权责发生制而不是收付实现制，应收、应付、预收、预付账款的概念。
2.不论出于什么原因要删除某笔记账数据都算抹账或者叫红蓝字冲正，而不是简单的从数据库删除该笔数据，原则上要对原有数据进行保留冲正该笔后再记正确的。
3.考虑数据正确性校验可以参考银行的做法每日批量，也可以每 10 日进行批量校验，最起码月底要试算平衡。
4.如果是单独的进销存...可以设计的宽松一些

[billlee]

就缺一个产品经理了

[sensui7]

@dxwwym 传说中的"有借必有贷, 借贷必相等"

[yeyeye]

@Mac 业务量和数据库性能比起来是很少了 用户操作问题慢慢优化吧……谢谢！


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

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

@sensui7 谢谢