本文内容
Odoo 邮件与 PDF 报价：先核对产品和价格
客户询价 3 箱螺栓和 5 套密封件。PDF 能读清楚，商业决定却还没完成：每箱多少件、对应哪个目录产品、客户提出的价格是否已经获批？
Odoo 邮件与 PDF 报价草稿审核，应是一套受控转换流程。保留原始请求，用获批目录核对产品和单位，从指定权威来源取得价格，并在发送前把审批绑定到准确的草稿版本。含义不明的明细和已变化的条款必须重新审核，不能靠猜测变成对客户的承诺。
资料核查日期：2026年11月5日。产品事实来自 Odoo 官方 20.0 文档源码。请求、目录和价格均为虚构示例。下载表中的检查未在 Odoo 或 AI 模型上执行，只用于规定实现应证明的行为。
请求接入流程应该生成什么？
接入流程应生成销售报价草稿，保留客户原始请求，并显示每条未解决的明细。信息提取和草稿准备只获得所需权限。发送报价与确认订单需要分别决策，因为内部审核通过，并不能证明客户已经接受这些条款。
Odoo 20 文档区分发送与确认操作，确认会生成销售订单。它也提供可配置的 Mandatory Product 设置。要求关联产品，并不证明选中的产品符合客户请求。
选择接入技术前，先定义目标行为。本文建议的技术身份可以准备草稿并附上审核证据，但不能发送、确认、承诺交货或新建目录产品。获授权人员通过批准的销售流程放行审核后的报价。
这些是待实现和测试的要求，不是对 Odoo 默认权限的描述。隐藏按钮不能证明其他写入路径已被限制。请实现负责人使用实际集成身份和应用控制演示结果。
| 步骤 | 允许的结果 | 所需证据 |
|---|---|---|
| 保存请求 | 用请求编号关联消息和附件。 | 原始内容与收到的版本。 |
| 准备候选值 | 建议客户、产品、数量和条款。 | 每个候选值的原文位置。 |
| 确定商业明细 | 选择获批的目录产品、单位和价格。 | 已确认标识、价格上下文与未决事项。 |
| 审核草稿 | 批准当前版本执行允许的下一步。 | 审核人、版本和审核过的重要值。 |
| 放行报价 | 通过获授权的销售流程发送。 | 有效审批及实际发送的准确文档。 |
应该先演示哪些 Odoo 原生能力？
提出定制开发需求前，先在已安装的 Odoo 版本上演示输入路径和生成的报价。确认由哪个应用、配置或模块接收请求，创建什么记录，之后还能执行哪些操作。某个文档功能可以解决部分流程，但未必证明产品匹配或商业审批已经到位。
PDF Quote Builder 文档描述的是组合对外发送的报价文档。该页面不能证明产品能够接入任意客户 PDF。
带一份获准用于演示的真实样本，并记录准确输出。原始明细是否保留？未知产品编码如何处理？准备好的明细能否未经审核就发送？核实具体版本、版本类型、托管方式和模块要求，不要从另一款名称相似的应用推断兼容性。
Odoo 的价目表文档说明，建议价格可以在销售订单中被覆盖。选定价目表本身不能证明价格审批规则得到执行。
如果需要外部工作流，实施前先确认其访问方式和托管条件。无论由哪种机制准备草稿，报价审核规则都应保持一致。本文评估销售决策，并不声称 Odoo 没有任何原生接入方式，也不预设必须定制 AI 流程。
审核人需要看到每条报价明细的哪些信息？
审核人应能并排看到原始请求、已确定的商业明细，以及仍需暂停的原因。区分客户写了什么、提取过程建议了什么、业务最终批准了什么。这样才能直接发现产品、单位或价格错误，而不必重新梳理整个邮件往来。
| 证据 | 示例 | 支持的判断 |
|---|---|---|
| 来源引用 | RFQ-204.pdf，第 1 页，第 1 行。 | 能否找到对应请求？ |
| 客户原文 | “3 箱 BOLT-M8-20，每箱 100 件”。 | 请求的是哪种产品、多少数量？ |
| 目录匹配 | 获批产品标识和选定规格。 | 是否选中了客户所需的可销售产品？ |
| 单位换算 | 3 箱 × 100 件 = 300 件。 | 计价数量的单位是否正确？ |
| 价格上下文 | 客户、币种、适用日期和获批规则。 | 为什么允许使用这个单价？ |
| 异常 | 两个目录候选，或客户要求改价。 | 剩余问题由谁决定？ |
| 审批引用 | 审核人和草稿版本。 | 审批是否覆盖当前明细？ |
客户身份核对和产品匹配应分别处理。如果多个客户账户适用不同条件，仅认出公司名称并不够。如果 HubSpot 参与客户交接，可参考客户字段权责与身份匹配指南。
模型可以建议匹配项，但审核包应保留候选值及选择理由。未知客户料号需要获批映射或进一步确认。不能因为新建明细比较容易，就悄悄把未知料号变成目录中的新产品。
单位与价格会怎样改变报价草稿？
把草稿金额当作报价总额前，先解决单位和价格权限。即使文字提取完全正确，把一箱当成一件、把目标价当成获批价，仍会算出错误的商业金额。未决明细必须保持可见，排除这些明细的合计要明确标为不完整。
虚构请求 RFQ-204 包含 3 条明细。示例目录和获批价格专为计算而设，不是 Odoo 默认值、市场价格或模型输出。
| 客户请求 | 审核决定 | 示例计算 | 待办事项 |
|---|---|---|---|
| 3 箱 BOLT-M8-20，每箱 100 件。 | 使用获批目录产品，共 300 件。 | 3 × 100 × 0.18 欧元 = 54.00 欧元。 | 确认包装和适用价格。 |
| 2 个 FX-2 滤芯。 | FX2-A 与 FX2-B 都仍是合理规格候选。 | 暂不选择价格和明细金额。 | 询问所需规格。 |
| 5 套 SK-4 密封件，目标价每套 12 欧元。 | 把请求价与示例获批价每套 15 欧元分开。 | 5 × 15 欧元 = 75.00 欧元；请求金额为 60.00 欧元。 | 批准商业价格，或继续协商。 |
第 1 条与第 3 条的部分小计为 54.00 欧元 + 75.00 欧元 = 129.00 欧元。其中没有未解决的滤芯明细、税费和运费。把 129.00 欧元展示为完整报价，会掩盖尚未完成的决定。
5 套密封件合计相差 15.00 欧元。如果流程直接把客户目标价写入获批单价字段，就相当于未经业务决定作出了这项让价。保留两个值，让审核人看清批准会改变什么。
再把第 1 条中的“每箱 100 件”删掉。文档仍写着 3 箱，但换算关系尚未确定。除非获批目录或客户协议规定了包装数量，否则应暂停该明细。模型给出一个看似熟悉的估计，不能替代这项依据。
如果修订请求把 3 箱改成 4 箱，要重新评估数量和价格上下文。沿用同一示例单价，400 件为 72.00 欧元，但适用价格规则也可能需要复核。不能仅因产品编码没变就沿用旧审批。
已批准的报价何时需要重新审核？
审批覆盖的重要值一旦变化，报价就应重新审核。明确列出这些值：客户账户、产品或规格、数量、单位、价格、币种和商业条款。放行时比较已批版本与当前草稿，不再一致就需要新的决定。
本文建议的审批只授权发送某一版草稿，不授权订单确认、替换产品或之后改价。保留实际发送的准确文档及其版本，以便确认客户最终收到了什么。
所有可能放行的路径都应执行检查。如果集成调用可以绕过规则，界面上的检查就无法保护它。请使用接入身份演示禁止操作，并检查业务记录和对外消息证据。
还要区分重复请求与新修订。转发的同一请求应按约定身份规则关联到现有接入记录；修改过的附件需要比较和重新审核。Odoo 与 n8n 恢复指南讨论作出这个业务判断后的重试与重复效果处理。
如何验收流程，而不虚构 AI 准确率？
用约定请求的实际业务结果验收流程，其中应包含有歧义和被修改的输入。只有运行选定模型后才能测量其行为。设计检查表可以规定预期结果，但不能证明提取准确率、审核耗时或从未执行过的连接器可靠性。
包含 12 个用例的报价审核表覆盖示例明细、缺失包装数量、未知客户编码、币种歧义、重复请求、修改附件，以及应禁止的发送或确认操作。全部执行状态从 NOT_RUN 开始。
- 确定接入范围。列出支持的文档类型、语言、客户和目录类别。其他请求进入人工队列。
- 批准预期商业结果。先由销售审核负责人确定产品、单位、价格和暂停决定，再评估模型建议。
- 保留完整审核包。保存每行的原文位置、候选值、最终决定和草稿版本。
- 检查禁止的状态变化。证明未决明细和过期审批不能按约定规则放行报价。
- 记录修正与工作量。真实执行后，再统计审核工作和仍进入最终草稿的错误。
- 根据观察到的失败决定下一步范围。反复出现规格歧义，可能先需要整理目录或联系客户，而不是更换模型。
较大导入任务中的映射建议，可参考Odoo AI 映射验证指南。这里的验收包针对报价商业明细，不是通用文档提取基准测试。
每个禁止操作都应配一个能成功的允许操作。拒绝所有发送的流程固然不会发错报价，却也没有完成销售任务。放行证据必须展示正确且经过审核的文档进入允许的下一步。
我们会先自动化哪部分？
我们会从有限的产品目录和只能准备草稿的接入角色开始，让一名审核人看着来源证据完成整个商业审核。观察真实修正和异常后，再扩大范围。先演示原生能力，只为明确缺失的行为安排开发，并指定负责人和验收条件。
标准软件与定制开发决策指南可帮助比较模块与持续维护的工作流。讨论 Wavect 的 API 集成服务时，带上一份代表性请求、已批准报价和目前最费审核时间的异常，便能界定具体的首次交付。