零件号发生替换后，不应只保存最终采购号。报价系统还要记录原始输入、替换关系、关联车型、核验依据和最终商品，才能在复核、退换货或售后争议时还原判断过程。

先分清三个官方查询动作

极速车服配件 OE 信息查询 API公开提供了不同的查询步骤：

动作 官方接口 适合回答的问题
搜索零件 parts/search 这个编号对应哪些零件记录和品牌？
反查车型 parts/salecar 该零件记录关联哪些销售车型？
查询替换 parts/replace 该零件是否有替换件或替代关系？

文档示例显示，parts/search返回可能包含 number、number2、brand、brandid、partsid、名称、备注和价格字段；parts/salecar可以返回车型 ID、年款、生产状态、销售状态和车型组；parts/replace则用于查询替换件。字段、计次和授权应以当天官方页面为准。

当前文档明确把 parts/search 的 number 标为必填；但 parts/salecar 和 parts/replace 的参数说明一方面写“零件号+品牌 ID/零件 ID 任选一个”，另一方面又把 partsid 标为必填。由于页面存在这种不一致，接入方应按实际账号联调结果确认参数组合，失败时保留业务状态和原始错误信息。

为什么不能覆盖原始零件号？

如果系统把替换件直接写回原 OE 号，后续人员会看不出：

  • 客户输入的是哪个编号；
  • 哪个接口返回了替换关系；
  • 替换前后是否属于同一品牌或不同品牌；
  • 报价时使用的是原号、替换号还是商城商品号；
  • 适配结论来自 VIN、车型、人工还是供应商。

因此，替换关系应当是有方向的业务事件，而不是简单的字符串替换。下面的表结构是可选的内部建模方案，不是极速车服接口规定的数据库结构。

part_query
  query_id, raw_number, normalized_number, brandid, partsid,
  requested_at, api_name, response_status

part_relation
  relation_id, source_partsid, target_partsid, relation_type,
  source_api, observed_at, evidence_snapshot

fitment_check
  check_id, relation_id, carid, vin_hash, check_state,
  checked_by, checked_at, note

quote_line
  quote_id, check_id, chosen_partsid, product_id,
  supplier_id, quoted_price, price_time, quote_state

raw_number保留客户原始输入，normalized_number用于检索和展示；evidence_snapshot保存当次返回的必要字段或其完整性校验值；vin_hash只在确有业务需要时使用，并按企业隐私规则处理。

推荐的查询与记录顺序

1. 原始输入先落库

收到带空格、后缀或斜杠的零件号时，先保存原文，再做前后空格清理。规范化值用于搜索，不要在第一步删除内部空格或后缀。这样在出现多个候选时，客服可以回看客户原始材料。

2. 搜索结果按候选集保存

调用 parts/search 后，不要只取第一条。先保存 partsid、品牌、零件名称、number、number2 和备注等字段，把结果标为“待确认”。如果一个编号对应多个品牌或多个零件记录，应让业务人员选择，或补充 VIN、车型和旧件照片。

3. 替换关系另建记录

调用 parts/replace 后，保存源零件、目标零件、查询时间、接口和业务状态。可以把关系类型分为“官方替换关系”“供应商替代建议”“人工确认替代”三类，但这属于内部标签，不能写成官网的字段或授权结论。

4. 反查车型并写入适配证据

对候选原号和替换号分别调用 parts/salecar，保留 carid、车型名称、年款、生产状态、销售状态和车型组。销售车型列表说明的是关联范围，不等于当前车辆一定适配；若存在冲突，必须回到 VIN、具体车款、安装位置和实物确认。

5. 报价引用“确认后的零件记录”

报价单不要只保存一个可变的零件名称。应引用 check_id 或等价的核验记录，连带保存选中的 partsid、商品 ID、供应商、报价时间和价格快照。这样替换号更新后，历史报价仍能解释当时为什么这样报价。

用数据溯源思路检查链路完整性

W3C 的 PROV-O: The PROV Ontology将可追溯信息抽象为实体、活动和责任主体。把它映射到汽配报价场景，可以得到一个简单检查表：

溯源对象 汽配业务中的对应物
实体 原始零件号、查询结果、替换件、车型记录、商品和报价快照
活动 搜索、替换查询、车型反查、人工复核、报价生成
责任主体 客服、采购员、系统任务、供应商

每条报价至少要能沿着“输入 → 搜索 → 替换 → 车型核验 → 商品选择 → 报价”向前回溯。若只保存最终商品名，发生售后问题时就无法判断是编号输入、车型适配还是供应商承诺出了问题。

失败和边界也要记录

  1. 零件号不存在。 保存原始输入和“无结果”状态，方便后续人工核对。
  2. 一个编号对应多个记录。 不自动选第一条，要求品牌 ID、零件 ID 或车辆条件进一步收敛。
  3. 替换接口返回空。 空结果只表示本次查询未得到替换记录，不代表“绝对没有替代件”。
  4. 销售车型过宽。 关联车型不能替代 VIN 和实车核验。
  5. 价格发生变化。 报价保存时间和供应商快照，不把接口返回的价格当成未来成交价。
  6. 接口或授权异常。 将 HTTP 错误、业务状态和人工状态分开，避免把系统失败误显示为“没有配件”。

最小可行实现

如果暂时不改造完整数据库，至少在报价记录中增加以下字段：原始零件号、规范化零件号、原始 partsid、替换 partsid、车型 ID、核验方式、API 查询时间、商品 ID、供应商、报价时间和确认人。每日或每次批量任务都保存一份返回摘要，必要时再保存完整响应，避免只留下无法解释的最终价格。

总结

零件号替换后的报价追溯，核心不是把新号码查出来，而是保留“为什么从原号走到替换号、为什么认为它适配、为什么选择这个商品”的证据链。极速车服的 parts/search、parts/replace 和 parts/salecar分别承担检索、替换和车型反查；企业应在接口结果之外补齐版本、状态、责任人和报价快照，才能让查询、采购和售后真正连起来。

标签：