车位资产数字化托管

业务背景

车位是一种「沉默资产」：业主买了车位但自己不用，物业想运营但缺系统。托管模式把这件事变成三方合约—— 业主把车位托管给平台，平台代运营并分账，租户按月付费。

角色	关心什么	系统里对应什么
业主（委托方）	车位有没有租出去、每月分到多少钱	托管合同、账单、分账流水
平台（代运营方）	招租效率、履约风险、账目能不能对上	车位池、租赁合同、账单与对账
租户（承租方）	价格、租期、押金、能不能续	租赁合同、续租、退租与押金退款

三方共用同一份车位与合同数据，但看到的信息不同——这是这条线在权限与展示上最费心的地方。

系统做了什么

环节	系统能力
托管	托管合同录入、审核、生效，绑定车位与业主
招租	可租车位展示、租赁规则（价格、最短租期、押金）配置
签约	在线签约，租金 + 押金 + 服务费 + 物业费 + 车位管理费合并支付
履约	续租（顺延）、退租申请、后台审核、押金退款
结账	分账接收方与比例配置、按笔分账、账单与对账

我做的部分

签约是最容易出错的一段：一笔支付要拆成五种费用，各自进不同的账；续租要沿原到期日顺延而不是从当天重算； 退租要走审核再触发退款。我把这几段的状态流转与金额计算在后端收敛成一套明确的状态机，前端只负责展示与 跳转，避免两端各算一遍。

后台侧补上了分账接收方与比例的配置、押金退款的审核入口，以及合同信息的统一维护（乙方主体、协议名称、 品牌信息）。

金额与状态

托管线的金额不是「一个订单一个金额」，而是五类费用各自成账：

签约支付  ──拆──┬─ 租金        → 按租期分摊到账单
                ├─ 押金        → 退租审核通过后原路退回
                ├─ 服务费      → 平台收入
                ├─ 物业费      → 归属物业
                └─ 车位管理费  → 归属车场

每一类费用都有独立的退款与对账口径，所以系统里合同、订单、账单是三层对象，而不是把字段堆在一张表上。 状态机也分层：合同有「待生效 / 生效中 / 已到期 / 已终止」，账单有「待支付 / 已支付 / 已退款」，订单只有 「待支付 / 成功 / 关闭」。任何一层状态变化都要能解释另外两层为什么没变。

技术亮点

• 金额可追溯：任何一笔分账都能反查到合同、订单与支付流水
• 状态机而非散布判断：合同、订单、账单三层状态各自收敛，避免“脏状态”
• 配置化分账：比例与接收方在后台维护，业务变更不需要发版
• 三方视图隔离：业主、平台、租户看到同一份数据的不同切面，靠接口裁剪而不是前端隐藏

团队与分工

团队负责车位池与招租、托管合同审核、账单与对账报表、支付与分账通道接入；我负责签约与续租的接口与 小程序流程、退租审核联动、分账配置页面，以及合同信息的统一维护。