zuowei/erpnew
1
0
Fork 0
forked from erp-dev/erp
Code Pull Requests Activity

fix: docs

Browse Source
This commit is contained in:
colaftc
2026-06-13 11:44:15 +08:00
parent 0bcaa2db44
commit 9a1c92febf
10 changed files with 195 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/purchase_order_approval_and_red_flush.md
View File

@@ -61,44 +61,41 @@
---
## 7. 下一阶段：库存红冲（对冲）方案规划
## 7. 红冲（对冲）落地状态
### 6.1 目标与原则
- **目标**：允许在采购单及其衍生的出入库记录完成后，通过“红冲”方式撤销或抵消错误的库存变动，同时保持库存快照与主库存的可追溯性。
- **当前状态**：采购单已支持整单红冲。已审批采购单可通过 `POST /api/v1/purchase-orders/<id>/red-flush/` 触发，生成反向余额记录和反向库存记录，同时保持库存快照与主库存的可追溯性。
- **原则**：
- 采用“新增反向记录”方式对冲，而非直接修改原记录；保留每一次实际发生的库存变更。
- 红冲记录需要指向原 `StockChangeRecord` / `StockSnapshot`（如 `offset_to`、`offset_id` 字段），便于审计。
- 红冲动作必须与业务流程挂钩（例如采购单作废或红冲），避免孤立的库存操作。
- 红冲动作必须与业务流程挂钩（例如采购单红冲），避免孤立的库存操作。
### 6.2 行动步骤
1. **业务入口确定**
- 定义哪些业务对象可以触发红冲（采购单、销售单等）。
- 明确触发条件：如采购单审批通过后，允许“创建红冲请求”并指向原采购单。
- 当前支持采购、销售、采购退货、销售退货、付款、收款 6 类正式单据整单红冲。
- 触发条件：单据必须已审批，且尚未红冲。
2. **库存服务层改造**
- 在 `stock.services.StockFlowService` 或相关函数中增加创建红冲记录的能力：
- 根据原 `StockChangeRecord` 生成反向 `StockChangeRecord` 和明细。
- 更新 `StockSnapshot` 的 `offset_to` / `offset_id` / `cancelled` 字段，确保链路闭环。
- 确保 `Inventory` 调整遵循相同的原子逻辑（事务 + 快照）。
- `stock.services.StockFlowService.offset_stock_change()` 已负责根据原 `StockChangeRecord` 生成反向 `StockChangeRecord` 和明细。
- 更新 `StockSnapshot` 的 `offset_to` / `offset_id` / `cancelled` 字段，确保链路闭环。
- `Inventory` 调整遵循相同的原子逻辑（事务 + 快照）。
3. **业务服务与模型扩展**
- 在 `business.services` 中引入“红冲采购单”或“撤销审批”的新方法：
- 校验：原单是否允许红冲、是否存在未处理的红冲记录。
- 调用库存红冲服务并记录关联。
- 必要时在 `PurchaseOrder` 或新模型中记录红冲状态/引用。
- `business.services.red_flush_purchase_order(...)` 负责校验原单是否允许红冲、阻止重复红冲，并调用库存红冲服务记录关联。
- `PurchaseOrder` 记录 `is_red_flushed`、`red_flush_id`、`red_flushed_at`。
4. **API 与文档更新**
- 设计新的红冲 API（例如 `/api/v1/purchase-orders/<id>/offset/`），请求体注明原因、操作者。
- 文档中要说明红冲流程与限制（只能对已审批单据、需管理员权限等）。
- 红冲 API 为 `POST /api/v1/purchase-orders/<id>/red-flush/`，请求体必须包含 `reason`。
- 权限复用现有业务单据员工权限，多商户数据先由 API 查询隔离，再由 service 二次校验。
5. **测试与审计**
- 单元测试：业务 Service、库存 Service、API 都要覆盖正常流程与错误场景。
- 集成测试：验证红冲后库存数量恢复、快照关系正确、消息/通知链路是否需要补充。
- 集成测试：已覆盖红冲后库存数量恢复、快照/库存记录关系、余额反向记录和 API 错误映射。
- 如有需要，增加日志或审计表，记录红冲操作人、时间、关联记录。
通过以上步骤，审批流程与红冲机制可以衔接：审批负责“正向入库”与任务分发，红冲负责在业务需要时生成配对的反向库存记录，保持库存账实一致，同时具备可回溯、可审计的业务闭环。
审批流程与红冲机制已衔接：审批负责“正向入库”与任务分发，红冲负责在业务需要时生成配对的反向库存记录，保持库存账实一致，同时具备可回溯、可审计的业务闭环。详细 API 见 `docs/2026-06-12_business_red_flush_api.md`。
---