duxingchen/KCGL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
933 Commits 5 Branches 0 Tags
9925bf2b99dc6a3211e5e0c69d98e0bf12cea579
Commit Graph

12 Commits

Author SHA1 Message Date
yueli
9925bf2b99 fix(inventory): 撤回/作废单据时释放预占库存，消除库存泄漏 
问题
----
系统原本已有「完结」功能（出库/借库），但它只改状态、不释放预占：

    approval.status = 4   # 已完结
    db.session.commit()   # ← 库存没还回去

申请阶段 reserve_for_items() 扣掉的 available_quantity 就此永久泄漏 ——
货被一张永不执行的作废单锁死，谁也领不走。

核查存量 23 张 status=4 的单，所幸均为预占改造前提交（items_json 无
stock_id），尚未造成实际损失。但缺陷本身是真实的。

改动（三个模块统一）
--------------------
出库 outbound_service.close_request
借库 borrow_service.mark_completed
  · 调用 release_reserved(approval.get_items()) 按 items_json 原样归还；
  · 明确「仅 status==1（已通过待执行）可撤回」—— 执行成功后
    create_outbound_batch / execute_dispatch 会把 status 置为 3，
    故该状态判断本身即执行守卫，已执行或已撤回的单都进不来；
  · 返回消息带上释放条数，便于操作者确认。

报废 scrap_approval_service.withdraw（新增能力）
  · 报废原先只有 approve/reject，没有撤回入口，补齐；
  · 复用同一个 release_reserved()：报废当前尚未接入预占，调用它会安全
    跳过（无 reserved 标记），但将来报废接入预占时该段代码自动生效；
  · 新增端点 POST /api/v1/scrap/request/<id>/withdraw（权限 scrap_apply）。

未采用按流水表二次校验：request_no(APR-OUT-…) 与 outbound_no(OUT-…)
格式不同、无关联字段，按单号比对是无效的，状态判断已足够。

实测
----
决定性用例（证明释放真实生效，非账面功夫）：
  A单预占5 → available=1
  B单要5   → 400 拒绝（被A占住）
  撤回A    → available=6
  B单再要5 → 200 成功，available=1     ★ 释放的库存真的可被复用

三模块：
  出库 撤回后 4→10 完全恢复，stock 未变（货没动）
  借库 撤回后 6→10 完全恢复
  报废 撤回成功，重复撤回被正确拒绝

状态码说明：报废复用出库/借库已有的 4=已完结 作为「已撤回」，
而非引入 -1，避免同一系统出现两套编号（其 2 已被「已驳回」占用）。
 2026-09-10 15:08:32 +08:00
yueli
b57c21a4cd feat(inventory): 库存预占生命周期，消除出库/借库超卖 
问题：库存超卖
--------------
改造前出库/借库申请只记录「要什么、要多少」，不绑定具体库存行，
真正的 available_quantity 扣减发生在执行阶段。于是多张申请可以同时
claim 同一批货，等到工人拿扫码枪时才发现货已被别人领走。

生命周期（三阶段）
------------------
  提交申请（预占）  reserve_for_items()
     用分配器把需求落到具体库存行，立即扣减 available_quantity，
     并把 (stock_id, source_table, allocated_qty, reserved) 写回 items_json。

  驳回（释放）      release_reserved()
     遍历 items_json 把预占量还回池子，避免货被永不执行的单永久占住。

  扫码执行（覆盖）  verify_scanned() + restore_then_deduct()
     校验实扫身份/数量未超批准范围 → 释放全部预占 → 对实扫批次
     同时扣减 available_quantity 与 stock_quantity。

身份键：base_id 主键 + SKU 兜底（重要设计决策）
-----------------------------------------------
本系统中 SKU 是**批次级**编号：同一 base_id 下每个入库批次各有不同的
SKU（实测 stock_buy 有 183 个物料是多批次的，如 base_id=2405 下有
0000001685 与 0000001974 两个 SKU）。

若以 SKU 作为身份主键，「申请时锁定 A 批、工人现场改扫 B 批」会被判为
身份不符而拒绝 —— 恰好否定了「物理覆盖」这个核心能力。
故改用 base_id（物料级、跨批次稳定，spec_model 由其唯一确定），
历史数据无 base_id 时降级为 (name, spec_model)。

可用量校验按物料汇总，而非按单批次
----------------------------------
开发中修正的一处缺陷：若逐行要求「该批次可用量 >= 该批次扫码量」，
工人改扫小批次时会被误拒。例如本单预占 A 批 5 件，改扫 B 批 2 件 +
C 批 3 件，B 批自身只有 2 件可用，逐行校验即失败。实际这 5 件都是本单
锁定的货，理应允许。现按物料汇总校验可用量，按行校验实物库存。

改动文件
--------
· 新增 app/services/inventory_reservation.py（通用服务层）
· outbound_service.create_request     —— Phase 1 预占
· outbound_service.approve(reject)    —— Phase 2 释放
· outbound_service.create_outbound_batch —— Phase 3 覆盖（移除原逐行扣减）
· borrow_service.submit_approval      —— Phase 1
· borrow_service.approve(reject)      —— Phase 2
· trans_service.execute_dispatch      —— Phase 3，并用统一身份键替换
                                         原有的 (name, spec_model) 字符串匹配

实测（真实 HTTP 全链路）
------------------------
初始 available=10
  ① 提交申请(需5)   → 200，available 10→5    预占生效
  ② 审批通过        → available 仍为 5        预占保留
  ③ 扫码执行(改扫另一批次 4 件) → 200
     原批次恢复满额、实扫批次扣减(0,0)，available=6, stock=6

单场景验证：预占 A 批改扫 B 批放行；驳回后可用量完全恢复；
           扫其他物料被拒；批准 6 扫 8 被拒。
 2026-09-10 14:59:10 +08:00
yueli
8755837fe8 fix(timezone): 审批单据时间统一为 naive 北京时间，消除 8 小时偏差 
成因：approved_at / executed_at 列是 timestamp without time zone，而赋值用了
带时区的 datetime.now(timezone(timedelta(hours=8)))。psycopg2 对 naive 列不会
剥掉 tzinfo，而是转成 naive UTC 再写入，结果比同为北京时间的 created_at 早 8 小时。
（代码里并无 datetime.utcnow()，真实成因是 aware 值被驱动的隐式 UTC 转换。）

改动：
  · outbound_service / borrow_service 的审批分支
    datetime.now(beijing_tz).replace(tzinfo=None) → beijing_time()
    （免审批分支已在上一轮改为 beijing_time，此处补齐审批分支）；
  · purchase_service 审批/完结分支同源缺陷一并修复；
  · scrap_approval / scrap_approval_service 的 _beijing()、_beijing_now() 由
    tz-aware 改为 naive —— 配合上述迁移把列类型改为 naive，
    若仍返回 aware 值，timestamptz→timestamp 后会反向早 8 小时。

实测四表（scrap/outbound/borrow/purchase）created_at 与 approved_at 差值
均在同一秒内（-1ms ~ -12ms）。
 2026-09-10 10:14:31 +08:00
yueli
1dbf74b7bc feat(borrow): 借库审批补「完结」能力（对齐出库 status=4） 
- mark_completed 改为 1→4 已完结（真正扫码借出完成仍为 status=3）
- 前端审批页新增「已完结」筛选项与状态映射；审批信息列对 3/4 显示审批人
 2026-09-10 09:47:07 +08:00
yueli
044e6dbd98 feat(borrow,outbound): 库管(WAREHOUSE_MGR)代建申请强制审批 
- submit/create 新增 force_approval：库管建单无视物料是否需审批，一律走审批
- 路由按当前角色为 WAREHOUSE_MGR 传 true；未选审批人返回明确业务错误
 2026-09-09 16:19:38 +08:00
yueli
aa9322bcbc feat(borrow): 借库申请后端必填校验——申请原因、预计归还日期(长期借用除外) 
- submit_approval 校验：申请原因非空；未勾长期借用时必须有 expected_return_time，否则 ValueError 拦截
 2026-09-09 10:53:12 +08:00
yueli
d06ce45a72 feat(borrow,outbound): 需审批判定收敛——ID优先 + 名称精确AND核心规格(斜杠前段) 
- approval_control 重写：带 base_id 按主键绝对判定；无 id 才名称100%一致 AND 核心规格(_code_of)一致兜底，杜绝同名不同规误杀
- 借/出库服务命中需审批但未选审批人时，报错列出需审批物料名/规格
 2026-09-09 10:47:24 +08:00
yueli
4cd3eefdf4 feat(borrow,outbound): 默认免审批改造——命中物料需审批才走原流程 
- models/base.py 加 is_approval_required 列及 isApprovalRequired 序列化；field_permissions 登记
- 新增 POST /inbound/base/batch-approval（批量设需审批，仿批量质检）
- borrow_service.submit_approval / outbound_service.create_request：明细含需审批物料→须选审批人走原审批；否则创建即 status=1(待库管执行)、不发审批邮件
- 判定按 (name,spec_model) 反查启用物料
 2026-09-09 09:31:18 +08:00
yueli
f3c946d584 fix: 借库审批同样修复 — sys_element 补充 op_borrow_approval:operation，can_approve 增加 RBAC 权限判断 2026-07-17 15:22:54 +08:00
yueli
9988d1b7eb fix: 补全审计/出库审批/采购管理/借库审批的权限保护+公司隔离 
- audit.py: 补@permission_required(system_audit)+import, 审计日志通过split_part关联用户表过滤公司
- outbound.py: 出库审批5个端点全补@permission_required(outbound_list)
- purchase.py: 采购管理7个端点全补@permission_required(inbound_buy)
- borrow_service: 借库审批列表通过applicant_id关联用户表过滤公司
- outbound_service: 出库审批列表通过applicant_id关联用户表过滤公司
- purchase_service: 采购列表通过base_id+requester_id双路过滤公司
- base_service/search_material: 去除debug日志
- decorators: 去除debug日志
 2026-07-15 11:49:53 +08:00
DXC
5c0c1632c3 fix(审批邮件): items_json序列化Bug修复 + 邮件方法出库/借库物理隔离 2026-06-12 15:04:57 +08:00
DXC
941bd20fbd fix(借库审批): borrow_service pytz时区修复 + transactions except块traceback增强 2026-06-12 14:06:17 +08:00