如何管理交易、债务、利息和罚金？
我正在为一家类似银行的机构制作一个 BI 系统。该系统应管理信用合同、发票、付款、罚款和利息。
现在，我需要制定一种创建发票的方法。我必须计算客户现在需要支付多少钱。他有债，他必须偿还。他还必须支付利息。如果他迟到了应付款，则迟到的每一天都会受到处罚。
我认为有两种方法可以做到这一点：
- 只有 1 个原始状态 - 合约的原始状态。每次计算客户必须支付的每月付款时，请考虑实际支付的付款。
- 通过不断地创建中间状态，从最后一个中间状态开始，并仅考虑这两个中间状态之间发生的事件。这意味着有一个定期（每天、每月）执行的作业，它采用最后保存的状态，应用更改（到期付款、实际付款、全局常量的更改，例如由中央银行控制的罚金率），然后保存结果状态。
第一个变体的好处：
- 始终实际。如果更改是在过去的日期进行的（一个人在向银行付款 5 天后收到了已付款的发票），这些更改将正确反映在结果中。
第一个变体的缺陷：
- 计算时间较长
- 如果正确的数据由于输入回溯日期的操作而发生变化，则使用当前结果打印的文档可能会有所不同。
第二种变体的优点：
- 工作速度快，并且聚合数据始终可用于搜索和报告。
- 计算更简单
第二个变体的缺陷：
- 容易失败作业。
- 过去的错误一直传播到最后，传播到最终的结果。
- 如果过去事务中的新数据到达，则无法更改中间结果（可以，但是这很困难，并且会产生很多影响，因此我宁愿将其标记为禁忌）
- 如果存在未完成的事务，则作业无法成功执行且不会出现问题（已开具但尚未付款的发票）
还有其他方法吗？我可以结合这两者的好处吗？您遇到过的其他类似系统中使用的是哪一种？请分享任何经验。
I am making a BI system for a bank-like institution. This system should manage credit contracts, invoices, payments, penalties and interest.
Now, I need to make a method that builds an invoice. I have to calculate how much the customer has to pay right now. He has a debt, which he has to pay for. He also has to pay for the interest. If he was ever late with due payment, penalties are applied for each day he's late.
I thought there were 2 ways of doing this:
- By having only 1 original state - the contract's original state. And each time to compute the monthly payment which the customer has to make, consider the actual, made payments.
- By constantly making intermediary states, going from the last intermediary state, and considering only the events that took place between the time of these 2 intermediary states. This means having a job that performs periodically (daily, monthly), that takes the last saved state, apply the changes (due payments, actual payments, changes in global constans like the penalty rate which is controlled by the Central Bank), and save the resulting state.
The benefits of the first variant:
- Always actual. If changes were made with a date from the past (a guy came with a paid invoice 5 days after he made the payment to the bank), they will be correctly reflected in the results.
The flaws of the first variant:
- Takes long to compute
- Documents printed with the current results may differ if the correct data changes due to operations entered with a back date.
The benefits of the second variant:
- Works fast, and aggregated data is always available for search and reports.
- Simpler to compute
The flaws of the second variant:
- Vulnerable to failed jobs.
- Errors in the past propagate until the end, to the final results.
- An intermediary result cannot be changed if new data from past transactions arrives (it can, but it's hard, and with many implications, so I'd rather mark it as Tabu)
- Jobs cannot be performed successfully and without problems if an unfinished transaction exists (an issued invoice that wasn't yet paid)
Is there any other way? Can I combine the benefits from these two? Which one is used in other similar systems you've encountered? Please share any experience.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这种性质的问题总是比最初出现时更加复杂。这
这是我称之为未知未知的拉姆斯菲尔德问题的结果。
基本上，无论你现在做什么，都要准备好根据未来的任意规则进行调整。
这是一个艰难的提议。一些可能对未来产生重大影响的可能性
您的计算模型是回溯的付款、调整和费用。
宽恕的利息期限也可能成为一个问题（特别是如果回溯）。要求
根据“已知”时间提供各种时间点 (PIT) 计算
该 PIT（过去的过去视图）或考虑在参考 PIT 之后发生的交易
追溯到参考之前的 PIT（过去的当前视图）。这种性质的计算可以是
真是头疼。
我的建议是从“从头开始”计算（即第一个变体）。仅实施优化（例如第二个变体）
必要时以满足性能限制。从一开始就进行计算是计算密集型的
模型，但在适应意外左转方面通常更灵活。
如果性能是一个问题，但复杂因素的频率（例如回溯交易）
相对较低，您可以探索采用两种变体中最好的一种混合模型。在这里您存储
当前状态并计算未来
仅使用自上次存储状态以来发布的那些事务来创建新的当前状态。如果你击中了
“并发症”重新做整个帐户
开始重建当前状态。
从长远来看，能够适应意外情况而不触发重写可能更重要
比现在减少计算时间。除非必要，否则不要对您的计算模型施加限制。保存
当前的状态通常会带来一些内置的假设和限制，从而减少了回旋余地
满足未来的要求。
Problems of this nature are always more complicated than they first appear. This
is a consequence of what I like to call the Rumsfeldian problem of the unknown unknown.
Basically, whatever you do now, be prepared to make adjustments for arbitrary future rules.
This is a tough proposition. some future possibilities that may have a significant impact on
your calculation model are back dated payments, adjustments and charges.
Forgiven interest periods may also become an issue (particularly if back dated). Requirements
to provide various point-in-time (PIT) calculations based on either what was "known" at
that PIT (past view of the past) or taking into account transactions occurring after the reference PIT that
were back dated to a PIT before the reference (current view of the past). Calculations of this nature can be
a real pain in the head.
My advice would be to calculate from "scratch" (ie. first variant). Implement optimizations (eg. second variant) only
when necessary to meet performance constraints. Doing calculations from the beginning is a compute intensive
model but is generally more flexible with respect to accommodating unexpected left turns.
If performance is a problem but the frequency of complicating factors (eg. back dated transactions)
is relatively low you could explore a hybrid model employing the best of both variants. Here you store the
current state and calculate forward
using only those transactions that posted since the last stored state to create a new current state. If you hit a
"complication" re-do the entire account from the
beginning to reestablish the current state.
Being able to accommodate the unexpected without triggering a re-write is probably more important in the long run
than shaving calculation time right now. Do not place restrictions on your computation model until you have to. Saving
current state often brings with it a number of built in assumptions and restrictions that reduce wiggle room for
accommodating future requirements.