【问题标题】:How to reserve a transaction in a double entry eccounting database design!如何在复式会计数据库设计中撤销交易!
【发布时间】:2011-06-26 01:01:31
【问题描述】:

对我的交易预留数据库设计不满意

场景,用户从系统(应用程序/游戏、平台等)取款到他的银行账户。

银行拒绝银行转账,因此提款交易失败。现在系统需要将资金返还给用户,减去拒绝/失败交易的费用。

要执行提款,有 4 个交易条目(创建 4 条记录),然后要执行交易的撤消,还有另外 6 个交易条目。总共10个交易条目! (已创建 10 条记录!)

我觉得可能有更好的方法来做到这一点!也许可以将记录标记为保留,并为保留事务添加逻辑到软件???

我做得对吗?

如何在复式记账数据库设计中保留交易?

编辑:保留交易,不是 指重新评估数据库 交易,而是储备 资金。

【问题讨论】:

  • 等等,什么?原始提现应该有单个事务,否则操作不会是原子的,可能会导致不一致。
  • 看起来“交易”这个词有两种不同的用法。 001大概是指货币交易的商业概念,而Oli是指数据库交易的技术概念。
  • 这里使用的事务是指一个条目。例如 CR 用户、DR 用户(即两个条目)。
  • 保留或冲销,这更像是一个会计问题。但是,如果您最初有 4 个,那么您需要 4 个来逆转,再加上 2 个拒付费用。听起来很合理

标签: sql-server database oracle database-design accounting


【解决方案1】:

我不确定这是一个编程问题。这里的问题是会计要求。在我们的系统中,我们会将借记记入 AR 明细账,然后将贷记/借记记入总账。如果我们随后收到拒绝、退回支票或其他任何情况,我们会发布新的交易来扭转它。没有它,就没有实际发生的事情的记录。

我们确实使用信用卡来避免其中的一些问题,因为我们可以在后期解决这些问题。如果交易未能结算,则 AR 批次不会发布,店员必须去修复它或删除交易。 AR 子账本交易上有一个已过帐标志,必须翻转才能影响余额,并且在成功过帐之前不会调整 GL。如果它确实发布成功但我们收到了退款,我们仍然使用上述方法。

实际上,这取决于您的主计长想要保留什么样的记录。他们可能希望跟踪失败的交易以进行报告和可能的欺诈检测。一般规则是一旦发布,就永远不要更改。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-11-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-09
    • 2017-12-06
    • 2021-05-19
    相关资源
    最近更新 更多