如何在复式记账数据库设计中保留交易！
对我的交易预留数据库设计不满意
场景，用户从系统（应用程序/游戏、平台等）提取资金到他的银行帐户。
银行拒绝银行转账，因此提款交易失败。现在，系统需要将资金返还给用户，减去拒绝/失败交易的费用。
为了执行提款，有 4 个交易条目（创建 4 条记录），然后为了执行交易的逆转，还有另外 6 个交易条目。总共10笔交易记录！ （创建了10条记录！）
我觉得可能有更好的方法来做到这一点！也许可以将记录标记为保留，并为保留事务添加逻辑到软件？？？
我这样做对吗？
如何在复式记账数据库设计中保留交易？
编辑：保留交易不是 指的是数据库的重新设置 交易，而是储备 资金。
Not happy with my transaction reserval database design
Scenario, User withdraw money from the system (application/game, platform etc etc) to his bank account.
The bank declines the bank transfer therefore the withdraw transaction failed. Now the system needs to return the funds back to the user minus a fee for the declined/failed transaction.
To perform the withdraw, there is 4 transactions entry (4 records created), then to perform the reversal of the transaction, there is another 6 transaction entry. In total 10 transaction entries! (10 records created!)
I feel that there may be a better way to do this! maybe could just flag the records as reserved, and add logic to the software for the reserved transaction???
Am i doing it right?
how do you reserve a transaction in a double entry accounting database design?
EDIT: reserving a transaction, is not
referring to a reseval of a database
transaction but rather the reserve of
funds.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定这是一个编程问题。这里的问题是会计要求。在我们的系统中，我们会将借方记入 AR 明细账，然后将贷方/借方记入总账。如果我们收到拒绝、退回支票或其他任何情况，我们会发布新的交易来逆转它。没有它，就不会有实际发生的事情的记录。
我们确实用信用卡来阻止其中一些，因为我们可以在邮寄时解决这些问题。如果交易未能结算，AR 批次不会过帐，店员必须修复它或删除交易。 AR 子账本交易上有一个已发布的标志，必须翻转该标志才能影响余额，并且在成功发布之前不会调整 GL。如果确实发布成功但随后我们收到退款，我们仍然使用上述方法。
实际上，这取决于您的审计员想要保留什么样的记录。他们可能希望跟踪失败的交易以进行报告和可能的欺诈检测。一般规则是，一旦发布某些内容，就永远不应更改。
I'm not sure this is a programming question. The issue here is the accounting requirements. In our system we would post a debit to the AR subsidiary ledger and then a credit/debit to the general ledger. If we then get a decline, bounced check, or whatever else, we post new transactions that reverse it. Without that there would be no record of what actually happened.
We do head off some of this with credit cards because we can settle those at post time. If a transaction fails to settle, the AR batch doesn't post and the clerk has to go fix it or delete the transaction. There's a posted flag on the AR sub-ledger transaction that must be flipped before it will impact the balance, and the GL is not adjusted until a successful post. If it does post successfully but then we get a chargeback, we still use the above method.
Really it comes down to what kind of records your comptroller wants to keep. They may want to keep track of the failed transactions for reporting and possible fraud detection. The general rule is once something is posted it should never changed.