duxingchen/KCGL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,031 Commits 5 Branches 0 Tags
f24797ff1fd904085c3f23210c967f4b0d5be27a
Commit Graph

107 Commits

Author SHA1 Message Date
yueli
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
yueli
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
yueli
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
yueli
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
yueli
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
yueli
aeb852c64d feat(stocktake): 新增盘点会话表 StocktakeSession 
盘点原本只有 stocktake_draft（草稿行），没有会话实体，导致三个问题：

1. 盲盘/明盘、全盘/抽盘这类**会话级配置**无处存放，塞进草稿表就要每行
   冗余一份，改一次配置得 UPDATE 上万行；
2. 「空会话」无法表示 —— 会话开了但还没扫码时草稿表里没有行，旧实现只能
   靠 max(scan_time) 猜哪个会话活跃，于是新开的空会话会被其他 PDA 忽略、
   反而加入上一轮的旧会话，多端协同直接分裂；
3. 没有状态字段，generate-missing 跑完后旧会话仍被当成活跃。

本表把活跃会话判定变成 company_name + status='active' 的精确查询。

迁移的要点：
- 唯一部分索引 uq_stocktake_session_one_active 保证「一个公司同时只有一个
  活跃会话」，从数据库层挡住多台 PDA 并发开启导致的进度分裂；
  因此 /draft/start-new 必须先把原有活跃会话置为 finished 再插入新记录。
- CHECK 约束限定 mode/scope_type/status 的取值域。
- 不回填存量：旧草稿没有对应会话行，部署后显示「无进行中的盘点」，数据不丢。

执行: docker exec -i inventory_db psql -U test -d inventory_system < db_migrations/add_stocktake_session.sql
 2026-09-11 13:28:43 +08:00
yueli
6586d3cb75 feat(stocktake): 盘点草稿表增加公司隔离字段 
stocktake_draft 原本没有任何公司维度，导致开启新盘点清空整表时会误删
其他公司的进度，扫码时也无法区分不同公司的同码物料。

- StocktakeDraft 增加 company_name（带索引），to_dict 同步输出
- 新增迁移 add_stocktake_draft_company_name.sql：加列 + (company_name,
  session_id) 复合索引；存量行保持 NULL（超管仍可见），不做删除

执行: docker exec -i inventory_db psql -U test -d inventory_system < db_migrations/add_stocktake_draft_company_name.sql
 2026-09-11 11:33:04 +08:00
yueli
ec66c33b06 feat(scan-draft): 扫码草稿表与接口，支持暂停后继续扫码 
场景
----
扫码出库/借库的作业可能很长（一张单几十项），工人常需中途暂停去处理
更紧急的单据。改造前切换单据会清空已扫内容，刷新/退出页面则全部丢失。

由于库存在申请审批通过时已**预占**，暂停期间货不会被他人抢走 ——
因此草稿只记录「扫到哪了」，**不涉及任何库存操作**。即使草稿丢失也只是
需要重扫，不会造成库存错乱。

隔离粒度
--------
按 (user_id, biz_type, request_id) 一人一单：每个人扫自己的草稿，互不影响；
同一人可同时持有多张单据的草稿（正是「暂停 A 去出 B」的场景）。
user_id 一律取自 JWT，不接受入参覆盖，故不可能读写他人草稿。

为什么整单存一个 JSON（而非每条明细一行）
------------------------------------------
1. 保存是「全量覆盖」语义，逐行存无增量更新的收益；
2. 恢复时需要物料名称/规格/库位等展示字段，逐行方案只能回查申请单的
   items_json —— 而历史单据的 items_json 不含 stock_id，回查会错配。
   整单快照把展示字段一并存下，恢复零依赖，对老单据同样可靠。

接口
----
GET    /api/v1/scan-draft           读取草稿
POST   /api/v1/scan-draft           保存（全量覆盖；空清单则删除）
DELETE /api/v1/scan-draft           清除（提交成功后调用）
GET    /api/v1/scan-draft/overview  各单据进度，供下拉徽标

实现要点
--------
· items_json 列是 jsonb，模型必须用 db.JSON —— 用 db.Text 会让 psycopg2
  拿到 Python list/dict 时无法适配，报 "can't adapt type 'dict'"，而异常
  被接口的 except 吞掉后 POST 仍返回"成功"，问题极难发现（开发中实际踩到）；
· 概览接口做防御：残留的空草稿不参与展示。

实测：保存/读回、跨单据隔离（B 读 A 的草稿为 0 项）、全量覆盖、
      提交后清除，全部符合预期。
 2026-09-10 17:21:14 +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
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
yueli
ffbb2199f0 feat(scrap): 报废申请审批流 + 按单报废（后端） 
- ScrapApproval 模型 + ScrapApprovalService：提交/列表/审批/执行(锁库存扣 available_quantity 写 TransScrap)
- 新路由 POST /scrap/request、/request/check-approval、GET /request、PATCH /request/<id>/approve、POST /request/<id>/execute；权限码 scrap_apply/scrap_approval/scrap_execute（无角色硬编码）
- 旧 /scrap 直接报废入口保持不变
- /inbound/stock/list 每项返回 source_table，供按单流程精准选库存
 2026-09-10 09:46:57 +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
91fb6c1a03 feat(bom): 自制件子件选版本落库/强校验 + 独立启停 + 状态筛选 
- save_bom 落库 child_bom_no/child_bom_version；自制件必选且须属于启用未归档配方集，外购件置空；跨版本查重纳入引用版本
- get_bom_detail 改为读存储列，空则回退最新启用配方；候选/校验/回退读取均排除 is_archived
- 新增 GET /bom/self-bom-versions（子件候选版本）；新增 POST /bom/status 独立启停（update_enabled 清缓存）
- 草稿链路 save_draft/get_draft_detail/publish 持久化引用版本
- get_bom_list/get_bom_summary 支持 status(enabled/disabled) 过滤
 2026-09-08 10:14:44 +08:00
yueli
478b90fe50 feat: 出库类型贯穿申请→扫码出库——申请单加 outbound_type，申请时选类型、扫码出库自动带出 2026-09-07 14:01:13 +08:00
yueli
b274ed1ed1 feat: TransBorrow 归还人 to_dict 自动把数字 user id 映射为用户名（历史记录不再显示数字，lru_cache 防 N+1） 2026-09-04 16:12:36 +08:00
yueli
1527d552d4 feat: 出库/借库记录记录并展示库位快照（DB加列+后端写入+记录页展示） 2026-09-04 11:42:44 +08:00
yueli
fbb4160787 feat: 采购申请新增库管'完结'功能(仿出库审批) 
- 后端:approve 接口支持 action=close(已通过→已完结 status 1→4),模型 status_text 支持已完结
- 前端:采购申请状态tab加'已完结',已通过单显示'完结'按钮(库管)
 2026-09-01 16:15:48 +08:00
yueli
f499346f74 refactor(purchase): 批次概念改为基于 request_no 前缀推导，撤销数据库字段 
按用户反馈：不需要新增数据库字段，现有 request_no (PUR-20260831-1021-0001)
本身就能推导批次——去掉末尾4位流水号即为批次前缀。

- 撤销 purchase_request.batch_no 字段（模型/数据库）
- 撤销 create 接口的 batch_no 参数与 generate_batch_no
- 批次标识 = request_no 去掉末尾 -XXXX 段
  getBatchKey('PUR-20260831-1021-0001') = 'PUR-20260831-1021'
- 按批次查询/批量审批接口改用 batch_key (request_no LIKE 前缀)
- 前端列表批次号列、整批弹窗、一键审批本批均基于前缀推导
- 零数据库迁移，历史数据立即可用
 2026-08-31 13:49:11 +08:00
yueli
664127ee30 feat(purchase): 采购批次号支持，同一批提交的记录可分组查看/统计 
背景: 循环提交把一批物品生成多条独立申请，无法识别'哪些是同一批采购'

后端:
- purchase_request 模型新增 batch_no 字段（同一批提交共享）
- create 接口接收 batch_no，无则自动生成 BATCH-yyyyMMdd-HHmm-随机
- 新增 GET /purchase/batch/<batch_no> 按批次查询所有记录
- 批量审批接口支持按 batch_no 一键审批整批

前端:
- 提交时生成 batch_no 共享给所有行
- 列表新增批次号列（可点击）
- 新增'整批查看'弹窗：显示同批次所有记录 + 一键批量通过本批
- 操作列新增'整批'按钮

数据库需执行: ALTER TABLE purchase_request ADD COLUMN batch_no VARCHAR(100);
 2026-08-31 13:46:46 +08:00
yueli
39f3f8af45 feat(outbound): 审批单手动完结/作废功能 
- 后端: outbound_service 新增 close_request 方法（状态 1-已通过 → 4-已完结）
- 后端: 新增 POST /api/v1/outbound/request/<id>/close 接口
- 模型: status_text 数组增加「已完结」
- 前端: create.vue 审批单选择区新增「强制完结此单」按钮
  完结后刷新列表，该单从已通过下拉中移除
- 权限: 超级管理员/审批人/拥有 outbound_create:operation 的用户可完结（库管可操作）
 2026-08-31 10:15:33 +08:00
yueli
23fc10a25f fix: Day2就绪 — 删除硬化+索引补全+全局异常处理 
## base_service.py — MaterialBase删除硬化
- 新增 BomTable 引用检查(bom_usage_count)
- 物料被BOM引用时禁止删除,提示「请先解除BOM绑定」

## models/base.py + bom.py — 缺失索引补全
- material_base: company_name + is_enabled 添加 index=True
- bom_table: is_enabled 添加 index=True

## __init__.py — 全局异常处理
- @app.errorhandler(ValueError) → 400 + 自定义消息
- @app.errorhandler(404/405) → 标准错误
- @app.errorhandler(Exception) → 500 + 通用消息
  堆栈仅记录服务器日志,不泄露到前端
 2026-07-16 14:14:43 +08:00
yueli
4934cd4d8f feat: 采购管理税率+分开单价总价列 + 按单出/借库锁定扫描 + 含税法计算 
- purchase: 新增tax_rate字段(model+service+frontend), 表格拆分为不含税单价/总价/税率三列
- buy.vue: 含税法计算(含税总价=数量×含税单价), 含税总价自动计算可手动覆盖
- create.vue: 按单出库模式下未选审批单时锁定摄像头和SKU输入
- borrow.vue: 未选审批单时锁定摄像头和SKU输入
- deploy_production.sql: 整合全部数据库变更(表结构+权限码+角色分配)
 2026-07-15 16:07:59 +08:00
yueli
538b6cb818 feat: 采购单导入自动填充采购人/邮箱/详情链接 + 实时搜索 
- PurchaseRequest.to_dict() 新增 requester_email
- 导入时自动填入: 采购人(requester_name) + 邮箱(requester_email) + 详情链接(supplier_link)
- 移除原始链接/详情链接的历史 autocomplete, 改为纯输入框+权限守卫
- 采购单导入搜索改为实时输入搜索(300ms防抖), 保留搜索按钮
 2026-07-14 16:29:19 +08:00
yueli
a11b7972c3 feat: 打通采购申请与入库的按单入库链路 
后端变更:
- PurchaseRequest 新增 base_id 硬关联 MaterialBase，StockBuy 新增 request_id 关联采购单
- handle_inbound 支持 request_id 入参，入库后自动反写采购单状态为已完成
- 新增 get_approved_requests 接口，返回已审批未入库采购单列表（含物料信息+历史数据回退匹配）
- create_purchase_request 新增 name+spec_model 自动匹配 MaterialBase
- 新增 SQL 和 Alembic 数据库迁移脚本

前端变更:
- 入库表单新增"从采购单导入"弹窗，支持搜索/选中已审批采购单并一键填充物料和商务信息
- 单价/总价交叉推算，缺项自动补全
- 选中行蓝色高亮+点击整行选中，行级交互优化
 2026-07-14 15:25:00 +08:00
yueli
760f78e016 feat: 添加参考价格列 + 修复公司筛选跨域问题 + CLIP模型持久化 
## 新增功能
- material_base 表新增 reference_price 列（NUMERIC(10,2)）
- 基础信息 list.vue / buyOdoo.vue 页面增加「参考价格」列展示和编辑
- 新增 material_list:referencePrice 权限元素，支持按角色控制可见性

## Bug 修复
- 入库三页面（buy/product/semi）公司筛选：非超管用户 company=ALL 不再传给旧版后端
- 基础信息两页面（list/buyOdoo）：buyOdoo 增加 v-if=isSuperAdmin 与 list.vue 行为统一
- company=ALL 默认值在各页面 getList/fetchData 中自动过滤，兼容旧版后端

## 运维优化
- docker-compose.prod.yml 增加 models_prod 卷挂载，CLIP模型持久化免重复上传
- deploy_code.sh 增加 models_prod 目录检查与模型文件存在性告警
 2026-07-13 17:30:52 +08:00
yueli
4f5965db02 feat: JWT多租户数据权限隔离 & 主管系统管理权限 & 含税单价补齐 
## 多租户公司数据隔离
- 新增 get_current_company_filter() 工具函数 (decorators.py)
  SUPER_ADMIN: 可传company_name参数过滤或传ALL看全量
  其他角色: 强制隔离到JWT中的company_name
- 重构 base_service.py / buy_service.py: 用集中式函数替换内联公司过滤
- SysRolePermission 表新增 company_name 字段，支持同角色不同公司权限
- get_user_permissions() 新增 company_name 参数，查公司定制+全局模板权限
- permission.py API 新增 @permission_required 拦截 + 公司过滤
- 19个API/service文件传递 company_name 到权限查询

## 主管系统管理权限
- delete_user() 允许SUPERVISOR删除同公司用户 (原仅SUPER_ADMIN)
- get_all_users() 新增 company_name 参数过滤
- 用户列表/权限分配 API 应用 get_current_company_filter()
- 前端 UserCreate.vue: 超管可见公司下拉框，主管隐藏部门字段

## 前端多租户适配
- material/list.vue / buy.vue: 公司下拉框仅超管可见，默认ALL
- UserCreate.vue: 新增搜索栏公司筛选，部门字段按角色显隐
- auth.ts: getUserList() 支持 params 参数

## Bug修复: 含税单价字段补齐
- buy.vue: 表格列/高级筛选/排序/权限映射新增 post_tax_unit_price
- buy_service.py: allowed_fields/sort_field_map 新增 post_tax_unit_price
 2026-07-13 15:12:22 +08:00
yueli
ffafa635bb feat: 将产品图/说明书备注字段从JSON数组中分离为独立数据库列 
- 数据库新增 product_image_remark 和 manual_link_remark 两个TEXT列
- 备注文字不再与上传文件URL混存在 generalImage/generalManual JSON数组中
- 前端输入框改为textarea，绑定独立的备注字段
- 修复 handlePasteLink 忽略field参数的bug
- 新增 isInternalFile 辅助函数，用于区分上传文件与纯文本
- 同步修改 list.vue 和 buyOdoo.vue 两个页面
 2026-07-10 10:52:23 +08:00
DXC
7ef22a3830 feat(借库审批流): 完整前后端实现 2026-06-12 14:08:19 +08:00
DXC
c7b84ff3c6 fix: BOM草稿模块缺陷修复（事务回滚 + 外键约束 + 前端状态清理） 2026-06-10 11:30:07 +08:00
DXC
1da4b454cd feat: 新增物料/入库单实时 CLIP 向量提取（新建+更新），修复 I/O 延迟和路径解析静默失败 2026-05-25 10:04:32 +08:00
DXC
6e1e1aa998 perf: 为库存三表/BOM/物料基础表补全高频查询列索引，防止全表扫描 2026-05-19 10:21:50 +08:00
dxc
3c9d7a999d fix(purchase): 审批人下拉隐藏角色/物料搜索下拉/价格弹窗确认/图片必填校验 2026-05-12 17:27:51 +08:00
dxc
9dfcb93146 feat(purchase): 新增采购申请模块后端（模型+Service+API路由） 2026-05-12 16:33:18 +08:00
dxc
259f3a7e0d 4.29扫码获取库位小工具接口 2026-04-29 15:40:43 +08:00
dxc
183b93012e 4.28 2026-04-28 16:07:11 +08:00
DXC
62c0e3738e fix(outbound+trans): 修复POST接口错误数据清洗导致的sku/quantity字段被清除Bug，并新增出库审批工作流全链路 2026-04-28 16:02:34 +08:00
DXC
3085d9f447 feat(repair): decouple material base, sync global sku sequence and add scan/print features 2026-04-08 19:36:14 +08:00
DXC
ec468b266d refactor(repair): upgrade TransRepair model with base_id, status, and SN for independent operation 2026-04-08 18:23:22 +08:00
DXC
46dd8f1c3a fix(auth,audit): ensure display_name persists in token refresh and add fallback in audit log 2026-03-25 11:16:13 +08:00
DXC
faea0379da refactor: replace transfer outbound type with production outbound across frontend and backend 2026-03-19 17:13:24 +08:00
DXC
6cc3d1b6e0 feat: upgrade adjustment workflow to require explicit inbound SKU or outbound tracking number and fix UTC timezone issue 2026-03-19 15:26:40 +08:00
DXC
09869667c8 fix: add extend_existing=True to StockAdjustment model to resolve MetaData conflict 2026-03-19 14:25:43 +08:00
DXC
c55eed0d75 fix: remove duplicate StockAdjustment model from stocktake.py to fix SQLAlchemy MetaData conflict 2026-03-19 14:20:27 +08:00
DXC
d8a57ab66e feat: initialize inventory profit and loss adjustment module 2026-03-19 12:06:32 +08:00
DXC
83745caacc feat: create models and SQL schemas for stocktake remarks and inventory adjustments 2026-03-19 10:56:40 +08:00
DXC
79d4a365e0 feat: add partial return support with returned_quantity tracking 2026-03-18 10:41:19 +08:00
DXC
c1c494893f feat: implement dynamic inspection requirement logic based on material master data 2026-03-17 11:56:04 +08:00
DXC
332f928c78 refactor: simplify stocktake flow without DB schema changes and remove invalid field queries 2026-03-13 10:45:37 +08:00
DXC
7e23141870 refactor: redesign stocktake flow to require manual discrepancy audit and individual adjustments 2026-03-13 09:59:01 +08:00
dxc
d2d9abe201 全局审计日fix: 使用鸭子类型强制安全解包 SQLAlchemy Row 对象，彻底解决 to_dict 报错志 2026-03-11 13:11:16 +08:00