Odoo AI 导入映射：核验供应商价格

返回

Kevin Riedl

12 分钟 阅读 · 2026年11月5日
最近审核 2026年11月5日

下一篇

假设供应商文件写着：一箱 24 件，价格 EUR 1,200.00。映射建议计算出了完全合法的数值 50.00，却把目标采购单位保留为“箱”。除法没有错，最终价格表达的却已经不是供应商原来的报价。

让 AI 提出 Odoo 导入映射，再依据独立批准的源数据定义和对照表核验。保留既有记录标识，以及每个采购单位对应的计价依据。含义不清的项目交给数据负责人确认；批准导入之前，还需要受控的原生环境演练。

资料核验日期：2026 年 11 月 5 日。产品事实依据 Odoo 20 官方文档。我们用 Python 和 Decimal 运算执行了十二个合成映射用例。候选映射均由人工构造，没有使用 AI 生成。我们没有向 Odoo 导入数据，也没有测试原生单位换算。原生验收检查仍为 NOT_RUN。

AI 在 Odoo 导入映射中应该负责什么？

AI 可以建议源列对应哪个目标字段，也可以找出需要解释的行。该建议能否接受，应由独立审核的映射约定决定。在一个看似合理的字段对应关系变成业务记录修改指令前，数据负责人必须确定源含义、允许的转换和用于更新的记录标识。

更新供应商价格时，只有“价格”还不够。你需要知道这笔金额能购买多少数量，以及具体要修改哪条既有供应商价格行。模型若自信地补全这些缺口，就超出了源文件能够支持的证据范围。

官方导入指南使用 External ID 识别记录和重建关联。本例的验收约定补充了标识本身无法表达的业务含义。

本文关注导入前的决定。迁移验收指南处理迁移后记录与流程的对照。重复到达的供应商交期更新则属于另一项架构选择，可参考Odoo 规则、n8n 与 AI 智能体比较。

哪些源数据含义必须先确定？

转换供应商价格前，先固定源标识和值的表达规则。标识按文本保留，价格和最低数量注明单位依据，产品与供应商引用通过获准对照表解析。如果源数据不能确定日期格式或每箱数量，就必须先由负责人作出决定，映射才能继续处理。

虚构文件包含两行，均使用公司 A 的供应商代码 0042。另一条对照记录在公司 B 使用相同供应商代码。产品代码 00123 和 00124 是文本，前导零属于已约定标识的一部分。

源规则明确接受小数逗号，并允许用点作分组千位分隔符；小数部分必须有两位。按这一规则，1.200,00 转为十进制值 1200.00。解析器的范围刻意限定于此，不能自动识别任意电子表格数字格式。

日期约定也来自独立输入。已批准日／月／年时，01/03/2026 转为 2026-03-01。如果没有这一约定，检查器会暂缓该用例。模型倾向采用哪种解释，不能消除源数据歧义。

既有报价标识要与产品标识区分。实际目录中，同一供应商对同一产品可能有多条价格条件。本例对照表指明的是两条具体既有记录，并未声称“供应商加 SKU”可以唯一识别所有阶梯价格或有效期。

为什么价格必须与采购单位一起核验？

供应商价格与采购单位共同表达一项商务含义。只改金额、不改单位，或只改单位、不改金额，都可能产生不同报价。最低采购量也必须使用同一声明依据。任何标准化之前，应把价格、单位和最低数量作为同一项映射决定批准。

Odoo 的计量单位文档将采购单位放在供应商行，并区分采购单位与库存单位。因此，正确目标单位取决于实际产品及供应商配置。

L01 的 EUR 1,200.00 ÷ 24 件 = 每件 EUR 50.00。最低 2 箱对应48 件。本例批准的映射保留箱价依据：采购单位为 24 件装箱，价格 1200.00，最低数量 2。

L02 的 EUR 48.00 ÷ 12 = 每件 EUR 4.00，3 箱包含 36 件。这些计算帮助审核人核对源含义，不是要求在保留箱价的同时再导入一套额外价格字段。

经独立批准，转换为按件计价也可能有效。但它需要相匹配的价格和最低数量，并证明目标流程正确使用这一依据。所附检查器只执行一套明确约定，并不禁止所有其他一致的映射方案。

如何独立核验映射建议？

把候选映射与另行批准的源规则和引用对照表比较。逐行核对预期标准化字段，保留完整行覆盖和准确目标标识。候选方案的置信度、解释文字或“已自查”声明，都不应决定比较是否通过。判断依据必须来自候选之外的获准资料。

下载样例将源行、已批准规则对象和候选行作为独立输入。检查器从源规则推导预期值，在公司范围内解析供应商引用，再逐字段比较。差异会带上源行标识，便于审核人定位受影响的数据。

这里的独立性指决定权的独立。如果同一个模型编造每箱数量，并把它同时写入映射和所谓参考表，两个输出吻合仍然只依赖一个无依据假设。负责人应把包装定义关联到供应商规格或获准产品记录。

向 AI 服务发送真实供应商数据前，应遵守该服务获准的数据路径决定。Odoo AI 数据驻留审查处理这一独立问题。本文样例只包含虚构记录。

十二个映射检查说明了什么？

十二个构造用例全部得到预期分类：1 个 READY_FOR_REHEARSAL、8 个 REJECT、3 个 HOLD。这些结果说明检查器在声明样例上的行为符合预期，不能衡量 AI 映射准确率，也不能证明 Odoo 导入会成功。两类结论需要不同的实证。

将检查器和样例文件放到同一目录，然后运行：

python3 mapping-validator.py

将输出与已记录结果比较。进程成功退出表示十二个分类都符合预期，包括故意拒绝和暂缓的情况，并不代表已批准导入。

脚本只接受声明的 JSON 结构和源规则。它不能打开任意电子表格，不能自动发现原生字段，也不覆盖所有税务、币种和定价规则。标准化键是供审查的中间格式，不是可直接上传的 Odoo CSV。

什么时候应交给人工审核并暂缓映射？

权威源含义或目标引用缺失时应暂缓；已批准含义明确、候选却与之冲突时应拒绝。两种状态对应不同下一步：错误价格需要修正映射，未知包装规格则需要数据负责人提供证据。把所有问题都标成同一种错误，会掩盖真正缺少的决定。

映射审核记录模板将建议转换与批准证据分开。记录源文件身份和映射版本，再指定谁能解决每个未决字段。暂缓应附带具体问题，例如“最低 2 指两箱还是两件？”

除非已批准范围包括创建产品，否则不要把缺失的产品引用自动变成新建产品指令。本例只更新已有供应商价格记录。创建产品或新报价会改变任务，需要自己的验收要求。

检查器也无法证明获准对照表本身正确。如果公司 A 的供应商引用在源规则审批时就批错了，候选可能与它完全一致。依赖绿色比较结果之前，先审查参考数据，并保留支持该关联的证据。

Odoo 原生演练需要证明什么？

原生演练应确认，已审查映射使用真实目标字段，并产生预期的供应商价格行为。检查安装环境中的引用和单位，再验证目标更新及一条有代表性的采购草稿流程。合成检查器只能证明中间建议符合声明约定，无法替代这些实际运行证据。

Odoo 的供应商价目表指南建议导出现有记录作为模板，并区分价格与最低数量。应从实际目标结构开始，不要仅重命名样例键就假定它们是原生导入列。

原生验收包包含十四项拟议检查，全部为 NOT_RUN，验收状态为 PENDING。实际证据与审核人字段均为空。

检查采购草稿不等于授权发送订单或确认采购。除非业务负责人另行纳入范围，这些动作应留在演练之外。此处的目的是在生产更新前观察映射后果。

保留演练使用的准确文件和获准转换版本。如果供应商下个月改变某列含义，表头看起来熟悉也不足以证明旧规则仍适用。应重新评估受影响映射，并重复相关检查。

导入前我们会批准什么？

只有当源含义和目标标识已确定、已知反例会被正确拒绝，并且原生演练支持预期更新时，才应批准某个具体映射版本。未决行继续暂缓。证据中应能找到接受供应商价格含义的负责人，也应明确谁负责执行导入。

先确认价格、单位、最低数量的组合，以及准确的既有报价标识。这些决定关系到转换是否保留供应商条款、是否更新正确记录。再补上格式和关联检查，并保留源文件供审核。

更广泛的发布判断可参考软件 QA 清单。Wavect 的软件质量保障服务可以帮助定义并独立审核导入流程的验收证据。准备好源数据规范，以及业务含义仍有争议的映射。