我以为这是支付问题。我错了。

Source: Dev.to

我在尝试正确建模 Strata Finance 后的收获

当我第一次开始思考这个问题时，我以为它很简单。
Strata finance 只不过是跟踪付款，对吧？谁付了，谁没付，欠了多少。但当我尝试正确建模时，这个假设就崩溃了。

这不是支付问题

乍一看，似乎主要工作就是记录金钱：

• 创建收费
• 记录付款
• 计算余额

这部分很直接。

真正的复杂性出现在你尝试回答以下问题时：

• 为什么这个单元仍然逾期？
• 他们已经付款了吗？
• 有人跟进了吗？
• 上周发生了什么？

这时你会意识到：这不仅仅是金钱的问题，而是关于随时间推移的事务追踪。

用一个单元来思考

为了简化问题，我不再考虑整个系统，而是只关注一个单元——比如 Unit A‑12。

每个月都会发生一件可预测的事：会生成一个新费用。该费用代表该单元当月应付的金额。到目前为止，没有什么复杂的。

然后付款进来

在某个时点，住户会进行付款。但这正是现实生活中开始变得混乱的地方。付款并不总是与应付金额相符。有人可能会：

• 部分付款
• 一次性支付多个月的费用
• 发送错误的金额
• 提交没有明确备注的凭证

而最关键的是：系统不能立即假设该付款有效。因此，系统不能直接标记为“已付款”，而是必须暂停。付款已存在，但它正等待验证。这个小细节非常重要，因为混乱往往正是从这里开始的。

单笔付款，多项费用

单笔付款很少是单纯的。如果一个单位欠三个月的费用并一次性付清，这笔付款需要在多个费用之间分配。因此系统必须回答：

• 首先支付的是哪项费用？
• 每项费用分配多少？
• 还有哪些费用未付？

这对电子表格来说是个难题，因为这不再只是一个列表——而是一种关联关系。

系统实际上是一个时间线

最大的思维转变来源于这样的认识：一个单元并非仅仅是“已付”或“未付”。它会经历不同的状态。在不同的时间点，同一个单元可能是：

• 新计费
• 逾期
• 已跟进
• 承诺付款
• 部分付款
• 有争议

这些状态并不是相互替代的；它们是层层叠加的。这意味着系统需要记住：

• 发生了什么
• 何时发生的
• 谁执行的

而不仅仅是最终的数字。

跟进比数字更重要

大多数系统关注费用和付款，但很少跟踪管理员实际做了什么。实际上，催收在很大程度上取决于：

• 给居民打电话
• 发送提醒
• 协商付款
• 升级案件

如果这些没有记录，系统就是不完整的。最重要的问题仍未得到回答：目前已采取了哪些行动？

并非所有人都以相同方式付款

另一层复杂性来自人类行为。一些居民：

• 总是准时付款
• 偶尔会延迟
• 除非被催促，否则从不付款
• 申请分期付款

把所有单元一视同仁是行不通的。系统需要一种 行为分类 的方式——不是给人贴标签，而是为了优先关注，因为并非所有逾期案件都同等重要。

从跟踪到清晰

此时，我意识到我并不仅仅在构建一种记录数据的方式。我在尝试构建一种能够回答一个简单而有力的问题的东西：谁现在需要关注？

这与“谁还没付款？”截然不同。前者会促使行动；后者只会生成一个名单。

这对我有什么改变

这彻底改变了我对系统的思考方式。与其关注功能，我现在关注的是：

• 信息如何流动
• 状态如何随时间变化
• 决策是如何做出的

系统不再是关于存储数据，而是关于让当前情况清晰。

接下来的计划

现在工作流程已经更清晰，下一步是将其转化为结构化的系统——一个能够：

• 正确跟踪费用和付款
• 处理部分付款和多月付款
• 持续记录跟进
• 自动分类单元
• 突出需要关注的事项

这就是我接下来要构建的内容。

如果你正面临这种情况

如果你曾经需要管理催收、跟进逾期付款，或手动整理财务记录，你可能已经见过这种情况。我正在积极在这个领域进行建设，并且愿意与希望改进内部系统的团队合作。

你可以通过这里联系我: