2026-06-15｜价格审批单号供应能力查询 CPQ 修复与真实数量接入

一、今日主要工作#

围绕价格审批单号查询供应能力时数量不准确的问题，梳理从前端审批单号输入、CPQ 物料查询、后端数据转换到盘古供应能力接口调用的完整链路。
定位 CPQ 接口地址、响应成功判断、数据结构解析及采购数量来源等问题，形成供应能力查询 CPQ 修复方案。
完成 CPQ 接口配置、响应 DTO、数据解析逻辑及审批单物料转换逻辑的代码改造，使供应能力查询使用 CPQ 返回的真实采购数量。
整理接口验证点和技术文档，明确改动范围、保持不变的业务逻辑以及后续联调关注项。

二、核心完成内容#

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

梳理价格审批单号查询供应能力的现有业务链路：
用户输入 13 位价格审批单号；
后端调用 CPQ 接口获取报价单物料；
将 CPQ 物料转换为供应能力查询参数；
根据整机或配件类型调用盘古对应的供应能力接口。
分析发现原有实现存在以下问题：
CPQ 接口地址仍指向 IT-GW 代理地址，与当前实际调用地址不一致；
代码同时依赖 success 和 code 字段判断调用是否成功，但 CPQ 实际响应中不存在 success 字段；
CPQ 返回的 data 是包含 itemCode、purchaseQty 和 unit 的对象数组，原代码按照字符串数组解析，导致真实采购数量丢失；
后端通过统计物料编码出现次数生成需求数量，无法反映 CPQ 报价单中的真实采购数量；
未过滤非供应能力查询范围内的物料，可能将非 6. 开头的物料传入后续盘古查询链路。
根据问题分析确定改造原则：
CPQ 接口改为直接访问 SIT 地址，不再经过 IT-GW JWT 鉴权；
CPQ 调用成功仅以返回字段 code == 0 为准；
使用 DTO 同时承接物料编码和采购数量；
供应需求数量直接使用 CPQ 返回的 purchaseQty；
仅保留 itemCode 以 6. 开头的供应物料；
保持原有整机、配件识别规则及盘古调用方式不变，降低改造影响范围。

2. 配置与数据模型改造#

2.1 CPQ 接口配置调整#

修改 application-dev.yml 中 CPQ 配置：
将 item-code-url 从 IT-GW 代理地址调整为 https://cpq-sit.sangfor.com/api/quote/open/quotation/item_code；
将 auth-with-it-gw-jwt 保持为 false，明确直连 CPQ 无需获取 IT-GW JWT。
同步整理生产环境配置变更要求，保证不同环境下 CPQ 接口地址和鉴权方式保持一致。

2.2 新增 CPQ 物料 DTO#

新增 CpqItemDto 数据对象，用于承接 CPQ 返回的：
itemCode：物料编码；
purchaseQty：真实采购数量。
将原有仅返回物料编码字符串的结构升级为包含编码和数量的结构，避免在服务层转换时丢失 CPQ 原始业务数据。

3. 服务层代码实现#

3.1 优化 CPQ 响应解析#

修改 CpqQuotationItemCodeService 返回类型，由 List<String> 调整为 List<CpqItemDto>。
调整 CPQ 调用成功判断逻辑：
修改前：同时判断 success == true 和 code == 0；
修改后：仅判断 code == 0。
调整 data 节点解析方式：
修改前：将数组元素直接按字符串读取；
修改后：分别读取对象中的 itemCode 和 purchaseQty 字段。
对空物料编码进行过滤，并保留 CPQ 返回的采购数量，为审批单物料转换提供完整输入。
对 CPQ 非成功响应增加异常处理，使用返回的 msg 信息辅助后续问题定位。

3.2 优化审批单物料转换逻辑#

修改 IvscOrderInfoService 中 buildLinesFromCpqItemCodes 方法，使其接收 List<CpqItemDto>。
删除通过物料编码出现次数统计数量的原有逻辑，改为直接解析并使用 purchaseQty。
增加供应物料过滤条件，仅保留物料编码以 6. 开头的数据，避免软件或其他非供应查询物料进入盘古接口。
对每条有效物料完成以下参数转换：
salesModelNum 使用 CPQ 的 itemCode；
demandQuantity 使用 CPQ 的 purchaseQty；
materialNameCn 继续通过 SCM 物料表解析；
accessory 继续调用原有 isHardwareSupplyMaterialCode 判断整机和配件。
保持 /cost-approval-match 接口签名不变，避免前端和其他调用方同步修改。

4. 盘古供应能力参数映射梳理#

明确 CPQ 数据到盘古供应能力查询参数的映射关系：
CPQ itemCode → salesModelNum；
CPQ purchaseQty → demandQuantity；
6.xxx.101 类型物料识别为整机，accessory=false；
其他符合规则的 6. 物料识别为配件，accessory=true。
保持 PangugongSupplyService.searchSupplyCapacity 原有调用逻辑不变：
整机继续调用整机供应能力接口；
配件继续调用配件供应查询接口。
通过在 CPQ 数据转换层完成修复，减少对盘古调用层和前端展示层的影响。

5. 测试验证与文档沉淀#

整理有效 13 位价格审批单号的接口验证流程，重点验证：
/cost-approval-match 返回 matched=true；
返回物料行的 salesModelNum 均以 6. 开头；
demandQuantity 与 CPQ 返回的 purchaseQty 一致，不再采用编码聚合次数；
6.xxx.101 正确识别为整机，其他物料正确识别为配件；
前端发起供应能力查询后，盘古接口能够正常返回供应能力数据。
以 CPQ 示例数据中的采购数量 1、12、2 为核对依据，验证数量映射逻辑。
完成《供应能力查询—价格审批单号走 CPQ 真实数量》修复方案和《供应能力查询—价格审批单 CPQ 真实数量接入》技术文档，沉淀问题背景、数据链路、代码改动和验证要求。

三、今日工作产出#

完成价格审批单号供应能力查询链路的问题定位和修复方案设计。
完成 CPQ 接口地址及鉴权配置调整。
新增 CpqItemDto，完善 CPQ 物料编码和采购数量的数据承接。
完成 CpqQuotationItemCodeService 的成功判断和对象数组解析改造。
完成 IvscOrderInfoService 的真实采购数量接入及 6. 物料过滤改造。
明确 CPQ 物料到盘古供应能力查询参数的完整映射关系。
形成修复方案和技术文档，为后续接口联调、代码评审及回归测试提供依据。

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

问题：CPQ 实际响应不存在 success 字段，原有成功判断会导致正常响应被错误识别为失败。
处理：调整为仅根据 code == 0 判断 CPQ 调用成功。
结果：响应判断逻辑与 CPQ 实际接口协议保持一致。
问题：CPQ 返回对象数组，但原有代码按照字符串数组解析，导致 purchaseQty 丢失。
处理：新增 CpqItemDto，分别解析 itemCode 和 purchaseQty。
结果：后端能够完整获取报价单物料编码及真实采购数量。
问题：原有需求数量通过物料编码出现次数聚合，不能反映实际采购数量。
处理：将 demandQuantity 改为直接使用 CPQ 返回的 purchaseQty。
结果：供应能力查询的需求数量与报价单数据保持一致。
问题：CPQ 返回数据可能包含非供应查询物料。
处理：在审批单物料转换阶段仅保留以 6. 开头的物料。
结果：减少无效物料进入盘古供应能力查询链路的风险。

五、明日计划#

使用实际有效的 13 位价格审批单号开展接口联调，核对 CPQ 返回值与后端转换结果。
验证整机和配件物料在盘古供应能力接口中的路由及返回结果。
对异常数量、空物料编码、CPQ 失败响应等边界场景补充测试。
根据联调结果完善异常提示、日志记录及相关测试文档。
对本次修改进行回归检查，确认订单号查询链路、前端接口协议和原有盘古调用逻辑不受影响。

六、总结#

今日主要围绕价格审批单号查询供应能力时 CPQ 采购数量丢失的问题展开工作，完成了完整数据链路梳理、问题定位、修复方案设计和核心代码改造。通过调整 CPQ 接口配置、完善对象数组解析、引入物料 DTO、接入真实 purchaseQty 并过滤非 6. 物料，使审批单供应能力查询能够基于 CPQ 真实采购数量构造盘古查询参数，同时保持前端接口、整机配件判断和盘古调用逻辑不变，降低了改造风险并为后续联调验证提供了完整技术依据。