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
..
2026-05-21 14:09:57 +08:00
2026-09-22 14:09:08 +08:00
2026-05-27 09:57:01 +08:00
2026-01-26 13:47:53 +08:00
2026-09-10 10:14:17 +08:00
2026-08-03 09:22:50 +08:00
2026-09-21 14:13:14 +08:00
2026-09-21 14:13:14 +08:00
2026-09-17 09:18:02 +08:00
2026-07-13 15:12:22 +08:00
2026-08-03 15:53:10 +08:00
2026-09-20 16:43:37 +08:00
2026-09-18 14:31:00 +08:00
2026-01-26 13:47:53 +08:00
2026-09-23 09:11:26 +08:00
2026-09-18 14:30:53 +08:00
2026-09-18 14:36:02 +08:00
2026-09-16 17:14:17 +08:00
2026-09-17 09:18:02 +08:00
2026-09-22 13:13:53 +08:00
2026-09-22 13:13:53 +08:00
2026-09-18 09:43:25 +08:00