不少团队以为 Tax Return 的标准流程一定是“审核 → 提交 → 付款”。但企业版 account.return 明确允许不同 return type 走不同 workflow，关键不在步骤看起来完整，而在每一步是否真的有业务意义。
参考入口：
enterprise/account_reports/tests/test_account_returns.py中test_state_progression等enterprise/account_reports/models/account_return.py
一、workflow 不是写死的，return type 决定状态路径
测试里至少覆盖了几种模式：
- only pay
- only review
- review + submit
- review + submit + pay（或带支付结果收敛）
这说明 Odoo 不把所有国家、所有申报表的后续动作强塞进同一模板里。
二、review 的意义在于生成并锁定工作文件，不只是点通过
action_validate() 往往伴随检查、附件生成、锁定动作或 closing context 准备。所以 review 不是“领导看过了”，而是申报资料从可编辑口径转入可提交口径。
三、submit 不一定等于下一步一定是 paid
对某些 workflow，action_submit() 后会进入 submitted；对另一些模式，如果没有实际待付金额或该类型不需要独立支付阶段，状态可能直接收敛到完成态。测试 test_account_return_state_review_submit_pay 还特地覆盖了有实际税额待付时，支付向导如何接管最后一步。
四、pay 动作的前提是 amount-to-pay 真的存在
Odoo 不是为了流程完整而硬加付款步骤。只有 return 计算出可支付金额、并且 workflow 需要这一阶段时，action_pay() 和支付向导才有意义。否则“已提交”就可能已经是流程终点。
五、实战建议
- 上线前按国家/报表类型确认 states_workflow，不要默认套一个全球流程。
- 看到某类 return 没有 submit 或 pay 按钮，先查 workflow 配置和 amount-to-pay 语义。
- 培训财务时，强调状态机代表的是法定动作分层，不是 UI 缺按钮。
六、结论
Tax Return 的 workflow 设计，核心不是把 review、submit、pay 全凑齐，而是让每一步都对应真实的合规动作。没有金额、不需要支付、不要求单独提交时，少一步反而更准确。
DISCUSSION
评论区