4 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	649eea681b	chore(changelog): #7327 核单住宿失效团期行前端 verified（可删+合计剔除）	2026-09-13 14:39:53 +08:00
API Changelog Bot和Claude Opus 5	779f70f896	docs(7327): 订正 changelog —— PR-2 把「权威消失即软删」推翻为「转 REVOKED 不删」 ... 本篇写于 PR-1(#7600, 49ce99cc8)当天，同日 09:19 合入的 PR-2(#7603, d916986de) 把其中的行为改成了相反的。mmg 手上拿到的是错的，故就地订正而非另起新篇 （另起会把同一批接口的信息分裂到两个文件）。 订正 7 处（代理只报了 4 处，第 5-7 处是收尾时按「概念」做全文残留断言抓出来的）： 1. 关键变化段：GROUP_BATCH_PLAN_REVOKED「本期产生不出来」-> 本期就会出现 2. 对平规则：「权威消失即软删，返回结果里不再出现」-> 不删，就地转 REVOKED + remark 加前缀 [团期来源已失效] ，实付/凭证/确认状态/source_id 锚点全保留， 权威回归时按 source_id 三段认回、不新建重复行 3. 行为对照表「团期权威消失」行 4. 用例名 listHotel_groupAuthorityGone_softDeletes... -> ...revokes... （真名见 SettlementServiceGroupBatchReconcileTest.java:219） 5. sourceType 取值域表里仍写着「本期产生不出来」 6. 读写混合说明里的对平三动作仍写着「权威消失的软删」 7. 「会新建、更新或软删住宿行」加限定（团期行走转 REVOKED，此处软删指其它来源） 另：正文顶部新增「2026-09-13 订正」段集中对账，PR 行补 #7603。 frontend_status: not_required -> pending。原 not_required 闭环是在 「REVOKED 本期产生不出来」这个前提下做的，前提已失效。 它引出一个需要拍板的新问题：一条权威已消失的 REVOKED 行，核单员到底能不能删？ 按现有前端逻辑它是「不可删的派生行」，但上游已不存在 —— 意味着它会永久留在核单页上。 后端这么设计是故意的（保住已录实付与凭证、以及认回锚点），但前端侧怎么展现没定过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-13 14:04:04 +08:00
Mimingguang	a7a687796f	chore(changelog): #7327 回写前端 not_required 核单 Step1 来源透传+584129兜底均兼容	2026-09-13 09:36:00 +08:00
API Changelog Bot和Claude Fable 5.1	31d9cb8b23	docs(order-v3): 团期配房行合流进住宿核单 Step1 changelog（#7327 PR-1） ... 面向 hl-ui：核单 Step1 的 sourceType 扩取值域，团期订单首次出现团期配房派生行 GROUP_BATCH_PLAN；新增行级确认闸业务错误码 584129。 接口路径、HTTP 方法、VO 字段集合均未变化，网关无新增路由。 Refs #7327 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-13 08:53:04 +08:00