2026-06-18｜软件订单交付查询能力优化与回归验证

一、今日主要工作#

围绕软件订单在订单交付查询中无法正常展示的问题，完成现有查询链路、产品筛选规则和明细展开逻辑的梳理。
设计并落地纯软件订单查询优化方案，明确“纯软件订单展示软件产品行，硬件或配件混合订单保持现有展示规则不变”的兼容性原则。
完成后端查询 SQL、订单产品过滤逻辑、SN 明细加载判断、报价单物料匹配逻辑及前端明细展开条件的代码调整。
构造纯第三方软件、纯自有软件测试数据，并结合配件订单开展回归验证，形成从方案设计、代码实现到接口测试和数据清理的完整工作闭环。

二、核心完成内容#

1. 方案设计与问题分析#

梳理订单交付查询的产品加载逻辑，确认现有 listProductsByTid 查询主要覆盖 6.% 物料和第三方产品，未覆盖 2.%、4.% 等自有软件物料，导致纯自有软件订单无法返回产品行。
分析明细展开链路，确认后端 shouldLoadDeliverySnDetail 和前端 orderDeliveryExpandable 仅允许硬件、配件及部分第三方产品展开，pmGenre=2 的软件产品无法加载和展示序列号明细。
排查 cost-approval-match 审批单号校验链路，发现其对 CPQ 物料同样存在仅保留 6.% 物料的问题，纯软件报价单会被过滤为空。
综合业务展示要求和现有订单行为，确定以下优化原则：
纯软件订单中保留软件产品行，并支持展开查看软件序列号；
硬件或配件与软件组成的混合订单继续过滤软件行，保持现有页面展示和业务行为不变；
软件产品仅展示序列号信息，不展示快递单号和物流轨迹；
V3 订单关注调度器保持原有过滤规则，不将软件订单纳入推送范围。

2. 模块开发与代码实现#

2.1 扩展订单产品查询范围#

调整 OrderDeliveryMapper.java 中 listProductsByTid 的查询条件，在原有 6.% 物料和第三方产品基础上，增加 2.%、4.% 软件物料查询。
解决纯自有软件订单在数据层无法被查询到的问题，为后续软件订单识别和序列号加载提供完整产品数据。

2.2 增加纯软件与混合订单识别逻辑#

在 OrderDeliveryService.queryOrder 中增加硬件、配件存在性判断。
当订单中存在 pmGenre=1 的硬件或 pmGenre=3 的配件时，按照原有规则过滤软件产品行，保证混合订单展示行为不变。
当订单中不存在硬件和配件时，将订单识别为纯软件订单，保留软件产品行并进入后续明细加载流程。
通过先查询完整产品集合、再按订单类型进行筛选的方式，兼顾纯软件订单展示需求和已有订单逻辑的兼容性。

2.3 放开软件序列号明细加载#

调整 shouldLoadDeliverySnDetail 判断条件，在硬件和配件基础上增加 pmGenre=2 软件类型。
使纯自有软件订单可以继续查询 order_sninfo，返回对应的软件序列号或 thirdPartySn 信息。
保持软件产品的快递单号和物流字段为空，避免将无实体物流的软件订单错误展示为物流发运产品。

2.4 优化审批单号物料匹配逻辑#

调整 IvscOrderInfoService.java 中 CPQ 物料处理逻辑。
获取报价单全部物料后，先判断是否存在 6.% 硬件或配件物料：
存在 6.% 物料时，仅保留该类物料，继续沿用混合订单原有处理逻辑；
不存在 6.% 物料时，保留全部软件物料，支持纯软件报价单的审批单号匹配。
解决纯软件报价单因物料前缀过滤导致匹配结果为空的问题。

2.5 同步前端明细展开规则#

修改 app.js 中 orderDeliveryExpandable 的判断条件，将 pmGenreNum === 2 纳入可展开范围。
保证后端返回软件 SN 明细后，前端能够正常显示展开入口和软件序列号。
前后端使用一致的产品类型判断规则，避免出现后端已返回数据但页面仍无法展开的问题。

3. 测试验证与回归处理#

3.1 测试场景设计#

围绕本次优化设计了三类测试场景：

纯第三方软件订单：验证第三方软件产品行能够展示、明细能够展开，并正确返回 thirdPartySn。
纯自有软件订单：验证自有软件产品行能够展示、明细能够展开，并正确返回软件序列号。
纯配件订单回归：验证前一日完成的配件物流明细能力不受本次软件订单优化影响，快递单号和物流信息仍可正常返回。

3.2 测试数据构造#

在 productsys 测试库中构造纯第三方软件订单 999900000002：
产品为 NAP 系统软件；
productAttribute=2；
构造 3 条 thirdPartySn 数据。
在 productsys 测试库中构造纯自有软件订单 999900000003：
产品为 VPN 网关管理平台 V7.0；
productAttribute=1、pmGenre=2；
构造 3 条自有软件序列号数据。
在 SCM 测试库的 ivsc_order_info 中补充对应订单和销售物料编码，保证订单查询及审批单号匹配链路具备完整测试数据。
复用配件测试订单 999900000001 进行回归测试，覆盖软件查询改造对已有配件物流能力的影响。

3.3 API 接口验证#

通过开发环境登录接口获取访问令牌。
分别调用以下订单交付查询接口：
999900000002：纯第三方软件订单；
999900000003：纯自有软件订单；
999900000001：纯配件回归订单。
对接口返回的 products、snList、thirdPartySn 和 deliverExpressNum 等字段进行核对。

3.4 结果核对#

纯第三方软件订单能够返回 1 条产品记录和 3 条 SN 明细，thirdPartySn 正常展示，快递单号为空，符合软件无实体物流的业务特征。
纯自有软件订单能够返回 1 条产品记录和 3 条软件序列号明细，页面具备展开条件，快递单号为空。
配件回归订单仍返回 1 条产品记录和 5 条 SN 明细，原有快递单号 SF9998887771 至 SF9998887775 保持正常。
验证了新增软件订单能力未影响配件订单已有物流明细查询逻辑。

3.5 测试数据清理#

补充 productsys 和 SCM 两个测试库的清理 SQL。
测试完成后可删除构造的订单头、产品行、SN 明细和审批单号匹配数据，避免测试数据长期残留影响后续查询。

三、今日工作产出#

完成《软件订单交付查询—优化方案》，明确纯软件订单和混合订单的差异化处理规则。
完成订单产品查询、订单类型识别、SN 明细加载、审批单号物料匹配和前端展开逻辑的代码实现。
完成纯第三方软件、纯自有软件及配件回归三类测试场景的测试数据构造和接口验证。
形成《软件订单交付查询—测试文档》，沉淀测试 SQL、接口调用方式、预期结果和数据清理脚本。
打通了从问题分析、方案设计、代码修改到测试回归的完整开发流程，为纯软件订单交付信息查询提供了基础支持。

四、遇到的问题与解决情况#

问题：订单交付查询 SQL 仅覆盖 6.% 物料和第三方产品，纯自有软件订单无法查询到产品行。处理：扩展 Mapper 查询范围，增加 2.% 和 4.% 软件物料，同时在 Service 层区分纯软件订单和混合订单。结果：纯软件订单可以保留软件产品行，混合订单仍维持原有展示规则。
问题：后端和前端均未允许 pmGenre=2 软件产品加载和展开 SN 明细。处理：同步修改后端明细加载条件和前端展开判断，增加软件产品类型。结果：软件订单可以展示并展开软件序列号，前后端判断逻辑保持一致。
问题：审批单号匹配链路固定过滤非 6.% 物料，纯软件报价单会被处理为空。处理：改为先判断报价单中是否包含硬件或配件物料，再决定是否执行 6.% 过滤。结果：纯软件报价单能够保留全部软件物料，混合报价单继续保持现有行为。
问题：新增软件订单支持可能影响前一日完成的配件物流查询逻辑。处理：将纯配件订单纳入回归测试，重点验证 SN 数量、快递单号和物流字段。结果：配件订单原有查询能力保持正常，本次改动未破坏已有功能。

五、明日计划#

使用实际业务中的纯软件订单和报价单进一步开展联调验证，核对真实数据下的软件序列号完整性。
补充硬件与软件混合订单、硬件与配件混合订单的回归测试，进一步确认软件过滤规则符合现有业务要求。
整理本次改动涉及的代码差异和测试结果，为后续 UAT 验证及代码评审提供材料。
根据联调结果处理可能存在的数据差异或边界场景，并完善相关技术文档。

六、总结#

今日主要围绕软件订单交付查询能力优化展开工作，完成了问题链路分析、兼容性方案设计、后端与前端代码实现，并通过纯第三方软件、纯自有软件和配件订单回归场景完成测试验证。此次优化在不改变混合订单现有行为和 V3 推送规则的前提下，补充了纯软件订单产品展示及序列号查询能力，形成了较完整的方案、开发、测试和文档沉淀闭环。