eafdf992c7
fix(borrow): 借还记录「归还人」列错标成了经手库管，拆成两列
...
问题
----
列表里那一列标着「归还人」，读的却是 trans_borrow.return_operator —— 而该字段
存的是**办理还库的库管**，不是来还东西的人。两者本就是不同的人：
· returner_id（trans_borrow_return）—— 把东西交回窗口的人，已校验 == 当时持有人
· return_operator —— 经手办理的库管
实测（借用行 120）：return_operator = 杜邢宸/duxingchen（库管），
而实际归还人是 returner_id = 21（测试）—— 页面却显示成了「杜邢宸」。
改动
----
一、后端 get_records 增补 returners：从 trans_borrow_return 取 returner_id 并
反查 sys_user 得到姓名（去重按明细挂回）。批量查一次，不做 N+1。
二、前端拆成两列，各自名副其实：
「归还人」 ← returners（后端新增）
「经手库管」 ← return_operators（原列改为正确标签）
三、顺带修展示口径：return_operator 存的是**完整 username**（高闯/gaochuang），
未按全站口径截断。_display_borrow_operator 现统一归一到展示名
（数字 id 反查 / 姓名、斜杠前段 / 已是展示名 原样），并修正其 docstring
—— 它原本也把该字段称作「归还人」，是同一个误解的源头。
★ 历史数据的现实
实际归还人流水是二期才建的，**历史归还没有这个记录**。这部分行的「归还人」
显示为空并挂 tooltip 说明「该笔归还发生在实际归还人记录上线之前」——
刻意不拿库管的名字顶上，那正是本次要修的错。
验证
BOR-20260918-0001 → 归还人=['测试']、经手库管='杜邢宸' ✓ 两者分开
BOR-20260914-0001 → 归还人=[]（历史）、经手库管='高闯' ✓
归一化：'高闯/gaochuang'→'高闯'、'21'→'测试' ✓
前端 vite build 通过；本次无需 DB 迁移。
2026-09-18 09:43:25 +08:00
681607bd43
feat(borrow): 拒收原因独立成列，与转交备注彻底分离
...
背景
----
拒收原因此前是**拼进 remark** 的：
transfer.remark = f"{remark}\n[拒绝原因] {reason}"
前端拿到的是「3333\n[拒绝原因] 5555」这样一坨，时间线上两句挤在一起，
无法分辨哪句是发起备注、哪句是对方拒收的原因。
改动
----
· trans_borrow_transfer 新增 reject_reason text 列；
reject_transfer 改为写入该列，不再拼进 remark。
· 存量按 '[拒绝原因] ' 标记切分回填（实测仅 #22：
remark 3333 / reject_reason 5555）。
· 时间线事件带出 reject_reason，前端才能分行展示。
★ 为什么拆列而不是让前端解析字符串
1) 拼接格式是隐式契约：改分隔符或加前缀，前端解析就静默失效且难排查；
2) 用户完全可能在备注里自己打出 '[拒绝原因]' 字样，按标记切分必然误判 ——
已加测试用例锁定该场景；
3) 结构化字段才能参与查询与统计（如按拒收原因归类）。
存储层能表达的东西，不该靠字符串约定去还原。
★ 一个迁移期踩到的坑：btrim 默认只去空格、不去换行。
拼接留下的是 '3333\n'，只写 btrim(x) 会残留换行；必须显式给出字符集
btrim(x, E' \t\r\n')。已修正脚本并对存量做了一次清理。
验证（7 项断言全通过）
备注不被污染、原因写独立列、无原因时为 None、
用户备注含同名标记也不误判、库存零副作用、数据零残留。
2026-09-17 10:46:31 +08:00
f24797ff1f
feat(borrow): 拒收须告知发起方（责任回到他手上，不能静默）
...
背景
----
双向握手补上了「接收人确认」，却只做了单向告知：接收人能看到待办，发起方却
对结果一无所知。**被拒绝时物品责任仍在发起方手上** —— 他若不主动查列表，
就会误以为已经交接出去，责任链出现静默断点。
（ACCEPTED 不需要告知：东西已经交出去了，发起方无需动作。）
改动
----
· trans_borrow_transfer 新增 reject_seen_at（NULL 且 REJECTED = 尚未告知）。
★ 为什么需要持久标记而不是前端去重：换台电脑、换个浏览器就会重新提醒；
而这条信息的分量（责任归属）值得一个持久标记。
★ 存量已拒绝的流水一律标记为已告知：它们产生于本功能上线之前，
追溯提醒只会打扰（实测仅 1 条：#22，验收时的测试数据）。
· get_unseen_rejects(user_id)：返回「我发起、被拒、尚未告知我」的转交，
并批量解析物料名 —— 只说「某笔转交被拒」发起方仍不知是哪件东西还在
自己手上，必须让他一眼认出来。
· ack_rejects(user_id, ids)：发起方确认后写 reject_seen_at，幂等。
· GET .../transfer/pending-count 的响应并入 rejects：与待接收数量共用同一次
轮询，前端不必多打一个请求。
· POST .../transfer/reject-ack：无 permission_required，同 accept/reject。
顺带补一处同源显示缺口
----
流转时间线里，被拒绝的转交与成功的长得一模一样 —— 发起方翻记录时同样会
误判。现将转交状态一并带出时间线事件。
验证（15 项断言全通过）
----
发起方收到待告知的拒绝（含物料名/接收人/拒绝原因）；接收人与无关人看不到；
ack 后不再提醒且幂等；ACCEPTED 不产生告知；None/非法 user_id 均安全返回；
库存零副作用、数据零残留。
2026-09-17 10:44:00 +08:00
b271ca3a49
feat(borrow): 转交流水表补 borrow_no 与 status（双向握手数据层）
...
背景
----
1) **单内撕裂**：原 /transfer 收的是**明细行 ID**，只更新那一行。一张单有
2 条明细时，转交后一条归接收人、另一条仍是原借用人 —— 前端按 borrow_no
聚合便同时显示两个名字（实测 BOR-20260917-0001：108→测试 / 109→杜邢宸）。
2) **单向强塞**：原实现发起即生效，接收人在毫不知情的情况下背上资产责任。
本次改动
----
· 新增 borrow_no —— 单据身份。一次转交要覆盖该单**多行**，单行 ID 表达不了
覆盖范围；accept 时据此批量更新。borrow_id 保留为「发起时的代表明细」供追溯。
· 新增 status —— PENDING / ACCEPTED / REJECTED 状态机。
· 存量 1 行按旧语义（发起即生效）标记为 ACCEPTED 并回填 borrow_no：
它事实上已经生效，若标 PENDING，接收人会收到一条早已生效的待办。
· 建 borrow_no / status / (to_user_id,status) 索引，后者支撑「待我接收」查询。
同单号同一时刻只允许一条 PENDING（应用层强制），避免两个接收人争抢同一批实物。
2026-09-17 10:04:05 +08:00
b998b00889
feat(borrow): 借库转交一期数据层（迁移、转交/归还流水表、发货操作人列）
...
背景
----
原 trans_borrow 是单行记录模式，身份维度只有 borrower_name 一个字符串：
「谁借的」与「谁现在还拿着」是同一个字段，无法表达持有权变更；归还时
return_time/return_operator/return_signature 被逐次覆盖，部分归还下
「谁在什么时候还了多少」永久丢失。
本次改动（全部增量，无破坏性 DDL，可回滚）
----
1) trans_borrow 补列
· borrower_id / current_holder_id / current_holder_name —— 身份锚点
· dispatch_operator —— 执行借出的库管（operator_name 形参此前被接收却从未落库）
2) 新建 trans_borrow_transfer —— 转交流水，一行=一次转交，不做覆盖式更新
3) 新建 trans_borrow_return —— 归还流水，逐次记录，根治部分归还失忆症
4) 历史回填（已执行）：85 行中 84 行 borrower_id 唯一命中 sys_user；
未归还的 32 行全部绑定 current_holder
5) 注册 borrow_transfer 权限码（无冒号形式，避免 _expand_operation_perms
前缀桥接把权限放大给所有持有 op_borrow:operation 的角色）
设计取舍
----
· current_holder 只回填「未归还」行：已归还=物品已回库、无人持有，保持 NULL。
这样「current_holder_id IS NOT NULL」本身就是「仍在某人手上」的有效信号，
归还校验不会对已结清单据误触发。
· 三张表都不建外键：与 trans_return / trans_defective_goods 一致 ——
库存行会被入库模块物理删除（实测已有悬空），台账必须能独立存活。
· dispatch_operator 不回填历史：执行人信息从未被采集，系统中不存在可回填的
数据源；用申请人或借用人冒充实物交接人比留空更危险。
验证：迁移已对 inventory_db 执行，核对段全部通过。
2026-09-17 09:17:51 +08:00
9eb4792d4a
feat(return): 退回流水看板接口与权限收口
...
新增只读台账接口：
- GET /api/v1/outbound/returns 退回流水（分页 + 关键词 + 类型 + 时间过滤）
返回 原出库单号 / 物料名称 / 规格 / SKU / 退回类型 / 退回数量 / 原因 /
操作人 / 退回时间 / 公司。出库单号经 trans_outbound 批量补齐，物料名按
多态来源批量解析，均为批量查询无 N+1。
权限收口（配合 db_migrations 里的三个权限码）：
- return-from-outbound inventory_stocktake:operation -> outbound_return
- GET /stock/defective inventory_stocktake -> defective_list
- restock inventory_stocktake:operation -> defective_restock
- scrap inventory_stocktake:operation -> defective_scrap
- change-status inventory_stocktake:operation -> stock_change_status
原先这四个接口搭的是「盲盘作业」权限的便车，职责错配、审计不合规。
实测 SALES（销售）角色持有 inventory_stocktake，意味着销售人员能读整份
不良品台账——与业务对台账可见性的要求不符。全部改用无冒号专用码后，
实测「只授予 inventory_stocktake:operation」对四个接口均返回 403，便车已封。
trans_return 补 company_name 快照：
退回流水的隔离判定原先只能靠 join 链推，而库存行会被入库模块物理删除
（实测 1077 条出库记录中已有 7 条悬空），链路一断记录就会对普通用户
静默消失。改由退回时落快照，隔离不再依赖任何 join。
2026-09-16 16:45:52 +08:00
69c38a1bf7
feat(return): 逆向物流数据模型与迁移
...
新增原单退回与不良品在管的持久化结构。
- TransOutbound 增 returned_quantity（numeric(19,4)，非 float）：该值参与
「return_qty <= quantity - returned_quantity」判等，浮点误差会让反复部分
退回后出现「已退满却判定未退满」的错判
- 新增 TransReturn：退回流水，每次退回写一条而非覆盖式更新。刻意与
trans_borrow 划清界限——后者部分归还时会覆盖 return_time/operator，
导致归还历史永久丢失
- 新增 TransDefectiveGoods：不良品在管台账。坏件全程不入库存表，因为
status 是行级属性而质量是件级属性，把坏件加回原行只能整行打不良
（实测 stock_buy 单行最大 4789 件、中位 8 件，整行打不良会凭空损失良品）
- 状态机：待处理 → 处理中 → {已回库|已报废|已闭环}。终态由累计去向推导
而非「最后一次动作」——一批坏件可能既回库过又报废过，按最后动作定状态
会产生误导
- restocked_qty/scrapped_qty 两列：二期用 quantity-remaining_qty 反推回库量，
三期加入报废出口后该反推失效
- 审计白名单与模型预加载同步登记（监听器绑定 18 → 20 个模型）
迁移脚本均为纯追加式 DDL，含预检、回滚段与执行后核对。首个脚本用
COALESCE 包裹数量列——库存表允许数量为 NULL，而「NULL 大于 0」求值为
NULL 而非真，裸写会让脏行在预览与诊断两次查询里凭空消失。
2026-09-16 15:45:22 +08:00
98e657e289
fix(scrap): TransScrap 补 scrap_request_no 列映射
...
报废执行写台账时以关键字传入 scrap_request_no，但该列只存在于 DB
（db_migrations/add_scrap_approval.sql）而未在 ORM 声明，执行报废必然抛
TypeError: 'scrap_request_no' is an invalid keyword argument for TransScrap，
被 500 捕获后连同库存扣减一起回滚，整条按单报废链路不可用。
2026-09-10 10:14:14 +08:00
b274ed1ed1
feat: TransBorrow 归还人 to_dict 自动把数字 user id 映射为用户名（历史记录不再显示数字，lru_cache 防 N+1）
2026-09-04 16:12:36 +08:00
1527d552d4
feat: 出库/借库记录记录并展示库位快照（DB加列+后端写入+记录页展示）
2026-09-04 11:42:44 +08:00
3085d9f447
feat(repair): decouple material base, sync global sku sequence and add scan/print features
2026-04-08 19:36:14 +08:00
ec468b266d
refactor(repair): upgrade TransRepair model with base_id, status, and SN for independent operation
2026-04-08 18:23:22 +08:00
79d4a365e0
feat: add partial return support with returned_quantity tracking
2026-03-18 10:41:19 +08:00
cd192624b9
fix: 统一系统生成时间为北京时间(UTC+8)并优化审计日志表格列展示
2026-03-10 17:33:14 +08:00
cc33108e88
feat: add TransBorrow.get_borrowed_quantity method
...
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat >
2026-02-28 11:43:10 +08:00
164988ab62
(no commit message provided)
...
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat >
2026-02-09 11:59:35 +08:00
b57e9f5bba
(no commit message provided)
...
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat >
2026-02-09 11:50:03 +08:00
c06b96f149
(no commit message provided)
...
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat >
2026-02-09 11:44:24 +08:00
04ee938cd1
借库逻辑实现
2026-02-06 17:11:47 +08:00
fd5600b65b
修改登录退出逻辑
2026-02-04 14:29:59 +08:00
13590b1fac
超级管理员登录设置
2026-02-04 13:30:07 +08:00
ee9f4aed3e
修正git管理关系
2026-01-26 13:47:53 +08:00
