feat: payment order and receipt order

business/ARCHITECTURE.md

@@ -32,17 +32,18 @@
 ### 2.3 OrderCounterpartyMixin
 对外暴露统一的 `get_counterparty()` 接口，通过 `get_counterparty_field_name()`（或 `counterparty_field_name` 属性）确定具体业务主体字段。这样采购单/销售单分别返回 `Supplier` 与 `Customer`，但调用方只需面对一个接口。
 
-### 2.4 PurchaseOrder / SalesOrder
-两类订单模型均继承上述三个 Mixin：
+### 2.4 订单类型
+当前业务对象覆盖：
 
-- 采购单：`get_direction()` 返回 `1`，`get_counterparty_field_name()` 返回 `supplier`
-- 销售单：`get_direction()` 返回 `-1`，`get_counterparty_field_name()` 返回 `customer`
-- 其余字段（`merchant/warehouse/operator/status/items`）保持一致，便于服务、序列化与统计逻辑复用
+- **PurchaseOrder**（采购单）：`direction=1`，`counterparty=supplier`，含库存明细。
+- **SalesOrder**（销售单）：`direction=-1`，`counterparty=customer`，含库存明细；严进严出模式需记录 `consume_detail_ids`。
+- **PaymentOrder**（付款单）：`direction=-1`，`counterparty=supplier`，仅金额字段，不触发库存。
+- **ReceiptOrder**（收款单）：`direction=-1`，`counterparty=customer`，仅金额字段，不触发库存。
 
-通过 mixin，两个模型天然具备：
-- 金额聚合与带方向金额计算
-- 统一的业务主体读取接口
-- 与库存/财务交互时一致的 `StockFlowService` payload
+通过 mixin，所有单据都具备：
+- 统一的金额聚合与方向计算（资金/库存可共用 `get_signed_total_amount()`）
+- 一致的业务主体接口（供应商/客户）
+- 可扩展的服务与序列化模式（有无库存由具体模型决定）
 
 ## 3. 服务层约定
 
@@ -52,10 +53,10 @@
 
 ## 4. 未来演进建议
 
-1. **新增单据**：若未来出现调拨单、退货单等，优先继承 `OrderItemsAggregationMixin + OrderDirectionMixin + OrderCounterpartyMixin`，仅通过 `get_direction()` / `get_counterparty_field_name()` 区别方向与主体，减少重复实现。
+1. **新增单据**：若未来出现调拨单、退货单或更多资金类单据，优先复用 `OrderDirectionMixin + OrderCounterpartyMixin`（如有明细再叠加 `OrderItemsAggregationMixin`），仅通过 `get_direction()` / `get_counterparty_field_name()` 区别方向与主体，减少重复实现。
 2. **审批/状态机**：采购与销售如需共享状态流转，可提炼状态机或 service 层 mixin，而无需在模型层合并。
 3. **统计与报表**：财务/库存统计应依赖 `get_signed_total_amount()` / `get_direction()`，确保采购/销售、退货/正向都能通过统一接口处理。
 4. **文档同步**：新增单据或服务时必须更新本文件，描述新增模型如何复用 mixin、如何影响下游模块，保持设计透明。
 
-以上约定的目标是：**保持采购单与未来销售单等业务对象的独立性，同时通过 mixin/服务层抽象复用绝大多数公共逻辑**。如需变更此架构（例如重新合并模型或修改核心 mixin 行为），请在评估后更新本文件，明确变化原因与迁移方案。 
+以上约定的目标是：**保持各类业务单据的独立性，同时通过 mixin/服务层抽象复用绝大多数公共逻辑**。如需变更此架构，请在评估后更新本文件，说明原因与迁移方案。