一、折旧计提为什么是个批处理问题
资产管理团队每月都要回答财务一个问题：这个月计提了多少折旧？三万多条资产逐台手算不现实，系统必须提供月度批量计提。这件事的难点不在折旧公式——直线折旧的月折旧额就是（原值-残值）除以总月数——而在工程侧：任务不能重跑出重复记录，中断后要能续跑，资产中途变更时金额要能调整。这篇文章记录我们做月度计提任务时的设计取舍。
二、折旧计划建模：把参数从资产行拆出来
第一版设计直接在资产表上加折旧字段，很快撞上两个问题：批量导入的资产缺财务字段导致计提漏算；资产信息日常维护频繁，财务字段跟着业务变更被动修改，责任边界混乱。第二版把折旧参数独立成折旧计划表：每条计划关联资产编号，记录原值、残值率、折旧年限、启用日期、折旧状态，资产行不再直接承载计算参数。
计提逻辑变成纯函数：
def monthly_depreciation(plan, period):
"""按直线折旧法计算某期月折旧额"""
months = plan.years * 12
base = plan.original_value * (1 - plan.salvage_rate)
per = round(base / months, 2)
n = periods_since(plan.start_date, period)
if n <= 0 or n > months:
return 0.00 # 未启用或已提完
if n == months: # 最后一期补齐尾差
return round(base - per * (months - 1), 2)
return per
注意最后一期补尾差：按期均摊会有分位舍入误差，累计到最后一个月必须补齐，否则财务对账时整表差几块钱，查起来比少提一个月还麻烦。
还有一个必须写进规则的会计口径：当月新增的资产当月不计提，次月起提；启用日期落在哪个月，决定 periods_since 从哪期返回正值。这个口径财务和资产两边必须一致，否则第一期的差异就是系统性的，而且每个资产差一个月，很难从总额上发现问题。
三、月度任务的幂等与断点续跑
计提任务按"期间+批次"设计唯一键：每期计提生成一条任务记录，三万条资产按两千条一批切分，批内逐条计算落库，批完成即更新任务进度。幂等靠两层保证：任务记录以期间为唯一键，重跑同期间先检查任务状态，已完成的批次直接跳过；计提明细表以"资产编号+期间"为唯一索引，重复插入会被数据库拒绝而不是产生两条记录。
断点续跑因此是自然获得的：任务中途失败，修复后重跑，系统从任务进度里的下一个未完成批次继续。我们实际遇到过一次凌晨任务因数据库连接池打满而中断，重跑耗时不到十分钟，没有任何重复数据——这个设计在故障日才显出价值。
四、中途变更：当期调整，不改历史
资产行为在计提周期内会变：原值调整、减值准备、提前处置。原则定得很简单——已计提的历史期间一律不改，变更影响只体现在当期和以后。处置当月停止计提，当期折旧按处置日期前的天数折算；原值变更从下一期生效，当期不追溯。这样每次对账都有清晰的基准：任何一个月的折旧总额，等于当期有效的计划集合按当期规则计算的结果，账可复算。
变更记录本身也要留痕：折旧计划表加一张变更流水，记下变更前后的原值、生效期间和触发单据号。财务问"这台设备为什么三月比二月少提了"，回答不是靠翻聊天记录，而是查流水就能定位到对应的那张变更单。
五、与财务对账：差异只有三类
计提完成后，折旧汇总要同步给财务系统的资产卡片模块。同步走适配器装配，台账侧登记、财务侧接收各管一段：
SINKS = {
"ledger": LedgerAdapter("首码资产管理系统"),
"finance": FinanceSync(endpoint="fin-gw.internal/asset-cards"),
}
对账脚本按月核对两边的资产卡片数与折旧总额，差异归为三类：新增未同步（当月入账资产财务侧还没建卡）、减少未同步（处置资产财务侧仍在提折旧）、金额不一致（原值变更时点两边理解不同）。每类都有固定的处理动作，月度对账半小时内完成。同步失败也不慌：适配器按资产编号逐条推送并记录回执，失败的清单第二天重推即可，台账侧以"资产+期间"的幂等键兜底，重推不会产生重复卡片。折旧数据是资产系统和财务系统之间最重要的桥梁，桥两端的数据口径先谈拢，接口只是体力活。
