KCGL/inventory-backend at c272c013887fc4cf34365d7a3d2afe9adeeeb984 - KCGL

Files

yueli c272c01388 feat(track): 出库回调补发单据上下文，让 Track 能展示「对应哪张单」

MOM 出库 webhook 此前只发 7 个字段（event/source_table/serial_number/quantity/
outbound_type/company_name/operator），单据信息在 MOM 侧全都有、但从来没被塞进
payload —— Track 侧扫码只能看到「已出库」，不知道是为谁、凭什么出的库。

补 6 个键：outbound_no / request_no / consumer_name / applicant_name /
outbound_time / remark。这些字段整批共用，直接读 common_data 与 approval
（两者在 notify_track 处都在作用域内），track_notifications 元组不必改结构。

同时补 common_data['request_id'] = approval.id —— 这是**表里真实存在的列**
（见上一个提交的迁移），让出库流水能反查回来源申请单。

⚠️ request_no / applicant_name 刻意**不**写进 common_data：它会被 ** 展开进
   TransOutbound(**common_data)，多一个不在表里的键直接 TypeError。只有真实
   列才进 common_data，纯展示字段只在 payload 字典里现算。
⚠️ 两者都必须在 approval 取出并校验**之后**赋值 —— common_data 在该行之前就已
   构造，提前引用会 UnboundLocalError（上线时踩过，源码有注释记着）。
⚠️ outbound_time 必须 .isoformat()：current_time 是 naive datetime，直接进 JSON
   会序列化失败。
⚠️ applicant_name 复用 OutboundApproval._get_user_name()（to_dict 已在用），
   在 MOM 侧解析成人名再发出去，避免 Track 拿着 applicant_id 跨库反查 sys_user
   —— Track 的 mom_cache 是按 username 索引的，对整型 ID 无能为力。

notify_track() 本身不动 —— 它不做字段白名单，payload 原样 httpx.post(json=...)。

2026-09-23 09:11:26 +08:00