--- title: "Odoo 邮件 PDF 报价草稿审核：产品与价格" canonical: https://wavect.io/zh/blog/odoo-email-pdf-quotation-review/ language: zh description: "把邮件和 PDF 请求准备成可审核的 Odoo 销售报价草稿。逐行核对产品规格、包装数量和价格权限，区分目标价与获批价，并用验收表检查发送前审批。" image: "https://wavect.io/img/blog/headers/header_odoo-email-pdf-quotation-review.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 邮件与 PDF 报价：先核对产品和价格 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-invoice-ocr-ai-exception-workflow/) 要点速览 保留客户请求，在报价草稿中显示未决产品、单位和价格。将目标价与获批商业值分开，把审批绑定到准确版本。先演示实际 Odoo 接入路径，再验证各操作的放行规则。下载表包含 12 个建议验收用例，没有模型或真实 Odoo 执行结果。 客户询价 3 箱螺栓和 5 套密封件。PDF 能读清楚，商业决定却还没完成：每箱多少件、对应哪个目录产品、客户提出的价格是否已经获批？ **Odoo 邮件与 PDF 报价草稿审核，应是一套受控转换流程。**保留原始请求，用获批目录核对产品和单位，从指定权威来源取得价格，并在发送前把审批绑定到准确的草稿版本。含义不明的明细和已变化的条款必须重新审核，不能靠猜测变成对客户的承诺。 **资料核查日期：2026年11月5日。**产品事实来自 Odoo 官方 20.0 文档源码。请求、目录和价格均为虚构示例。下载表中的检查未在 Odoo 或 AI 模型上执行，只用于规定实现应证明的行为。 ## 请求接入流程应该生成什么？ 接入流程应生成销售报价草稿，保留客户原始请求，并显示每条未解决的明细。信息提取和草稿准备只获得所需权限。发送报价与确认订单需要分别决策，因为内部审核通过，并不能证明客户已经接受这些条款。 Odoo 20 文档区分 [发送与确认操作](https://github.com/odoo/documentation/blob/20.0/content/applications/sales/sales/sales_quotations/create_quotations.rst) ，确认会生成销售订单。它也提供可配置的 Mandatory Product 设置。要求关联产品，并不证明选中的产品符合客户请求。 选择接入技术前，先定义目标行为。本文建议的技术身份可以准备草稿并附上审核证据，但不能发送、确认、承诺交货或新建目录产品。获授权人员通过批准的销售流程放行审核后的报价。 这些是待实现和测试的要求，不是对 Odoo 默认权限的描述。隐藏按钮不能证明其他写入路径已被限制。请实现负责人使用实际集成身份和应用控制演示结果。 | 步骤 | 允许的结果 | 所需证据 | | --- | --- | --- | | 保存请求 | 用请求编号关联消息和附件。 | 原始内容与收到的版本。 | | 准备候选值 | 建议客户、产品、数量和条款。 | 每个候选值的原文位置。 | | 确定商业明细 | 选择获批的目录产品、单位和价格。 | 已确认标识、价格上下文与未决事项。 | | 审核草稿 | 批准当前版本执行允许的下一步。 | 审核人、版本和审核过的重要值。 | | 放行报价 | 通过获授权的销售流程发送。 | 有效审批及实际发送的准确文档。 | ## 应该先演示哪些 Odoo 原生能力？ 提出定制开发需求前，先在已安装的 Odoo 版本上演示输入路径和生成的报价。确认由哪个应用、配置或模块接收请求，创建什么记录，之后还能执行哪些操作。某个文档功能可以解决部分流程，但未必证明产品匹配或商业审批已经到位。 [PDF Quote Builder 文档](https://github.com/odoo/documentation/blob/20.0/content/applications/sales/sales/sales_quotations/pdf_quote_builder.rst) 描述的是组合对外发送的报价文档。该页面不能证明产品能够接入任意客户 PDF。 带一份获准用于演示的真实样本，并记录准确输出。原始明细是否保留？未知产品编码如何处理？准备好的明细能否未经审核就发送？核实具体版本、版本类型、托管方式和模块要求，不要从另一款名称相似的应用推断兼容性。 Odoo 的 [价目表文档](https://github.com/odoo/documentation/blob/20.0/content/applications/sales/sales/products_prices/prices/pricing.rst) 说明，建议价格可以在销售订单中被覆盖。选定价目表本身不能证明价格审批规则得到执行。 如果需要外部工作流，实施前先确认其访问方式和托管条件。无论由哪种机制准备草稿，报价审核规则都应保持一致。本文评估销售决策，并不声称 Odoo 没有任何原生接入方式，也不预设必须定制 AI 流程。 ## 审核人需要看到每条报价明细的哪些信息？ 审核人应能并排看到原始请求、已确定的商业明细，以及仍需暂停的原因。区分客户写了什么、提取过程建议了什么、业务最终批准了什么。这样才能直接发现产品、单位或价格错误，而不必重新梳理整个邮件往来。 | 证据 | 示例 | 支持的判断 | | --- | --- | --- | | 来源引用 | RFQ-204.pdf，第 1 页，第 1 行。 | 能否找到对应请求？ | | 客户原文 | “3 箱 BOLT-M8-20，每箱 100 件”。 | 请求的是哪种产品、多少数量？ | | 目录匹配 | 获批产品标识和选定规格。 | 是否选中了客户所需的可销售产品？ | | 单位换算 | 3 箱 × 100 件 = 300 件。 | 计价数量的单位是否正确？ | | 价格上下文 | 客户、币种、适用日期和获批规则。 | 为什么允许使用这个单价？ | | 异常 | 两个目录候选，或客户要求改价。 | 剩余问题由谁决定？ | | 审批引用 | 审核人和草稿版本。 | 审批是否覆盖当前明细？ | 客户身份核对和产品匹配应分别处理。如果多个客户账户适用不同条件，仅认出公司名称并不够。如果 HubSpot 参与客户交接，可参考 [客户字段权责与身份匹配指南](/zh/blog/hubspot-odoo-customer-data-ownership/) 。 模型可以建议匹配项，但审核包应保留候选值及选择理由。未知客户料号需要获批映射或进一步确认。不能因为新建明细比较容易，就悄悄把未知料号变成目录中的新产品。 ## 单位与价格会怎样改变报价草稿？ 把草稿金额当作报价总额前，先解决单位和价格权限。即使文字提取完全正确，把一箱当成一件、把目标价当成获批价，仍会算出错误的商业金额。未决明细必须保持可见，排除这些明细的合计要明确标为不完整。 虚构请求 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 恢复指南](/zh/blog/odoo-n8n-idempotency-recovery/) 讨论作出这个业务判断后的重试与重复效果处理。 ## 如何验收流程，而不虚构 AI 准确率？ 用约定请求的实际业务结果验收流程，其中应包含有歧义和被修改的输入。只有运行选定模型后才能测量其行为。设计检查表可以规定预期结果，但不能证明提取准确率、审核耗时或从未执行过的连接器可靠性。 [包含 12 个用例的报价审核表](/downloads/odoo-email-pdf-quotation-review/quotation-review-acceptance.csv) 覆盖示例明细、缺失包装数量、未知客户编码、币种歧义、重复请求、修改附件，以及应禁止的发送或确认操作。全部执行状态从 `NOT_RUN` 开始。 1. **确定接入范围。** 列出支持的文档类型、语言、客户和目录类别。其他请求进入人工队列。 2. **批准预期商业结果。** 先由销售审核负责人确定产品、单位、价格和暂停决定，再评估模型建议。 3. **保留完整审核包。** 保存每行的原文位置、候选值、最终决定和草稿版本。 4. **检查禁止的状态变化。** 证明未决明细和过期审批不能按约定规则放行报价。 5. **记录修正与工作量。** 真实执行后，再统计审核工作和仍进入最终草稿的错误。 6. **根据观察到的失败决定下一步范围。** 反复出现规格歧义，可能先需要整理目录或联系客户，而不是更换模型。 较大导入任务中的映射建议，可参考 [Odoo AI 映射验证指南](/zh/blog/odoo-ai-data-mapping-validation/) 。这里的验收包针对报价商业明细，不是通用文档提取基准测试。 每个禁止操作都应配一个能成功的允许操作。拒绝所有发送的流程固然不会发错报价，却也没有完成销售任务。放行证据必须展示正确且经过审核的文档进入允许的下一步。 ## 我们会先自动化哪部分？ 我们会从有限的产品目录和只能准备草稿的接入角色开始，让一名审核人看着来源证据完成整个商业审核。观察真实修正和异常后，再扩大范围。先演示原生能力，只为明确缺失的行为安排开发，并指定负责人和验收条件。 [标准软件与定制开发决策指南](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 可帮助比较模块与持续维护的工作流。讨论 Wavect 的 [API 集成服务](/zh/services/api-integration/) 时，带上一份代表性请求、已批准报价和目前最费审核时间的异常，便能界定具体的首次交付。 ## Odoo 邮件与 PDF 报价常见问题 ### 这和 Odoo 采购询价单是一回事吗？ 本文讨论卖方收到客户请求后准备销售报价。采购询价则是你的组织向供应商索取报价。范围、示例和权限中都要明确区分这两个方向。文档名称相似，不代表产品确认、价格决定或审批责任相同。 ### 未知客户产品编码能否自动创建目录产品？ 只有获批流程另外允许创建目录产品，并规定相应审核时才可以。本文建议范围中，未知编码保持未解决状态，直到负责人选择现有产品或批准映射。创建一个看似合理的产品记录会掩盖缺失决定，并可能影响之后的下单和履约。 ### 置信度很高就能放行报价吗？ 不能。模型分数不能证明客户身份、商业权限或审批版本仍有效。若已针对实际任务评估过该分数，可以把它作为一个信号。放行仍须符合企业批准的产品、单位、价格和状态规则；未解决的明细继续等待审核。 ### 转发请求或修改后的 PDF 应如何处理？ 保留业务请求编号，并比较内容版本。转发副本可以归入现有接入记录；数量或附件变化则需要审核差异。不能仅凭新邮件标识创建另一份报价，也不能仅凭旧主题行就断定内容没有变化。 ### 接入流程可以承诺库存或交货日期吗？ 只有存在获批数据来源和决定规则时，才把这些承诺纳入流程。客户希望的日期不能证明企业能够做到。把请求日期与拟议承诺分开，保留对应的可用性检查，并把不确定事项交给负责交货承诺的人。 ### 示例是否测量了模型准确率？ 没有。示例和 CSV 是带预期结果的虚构规范，不是模型或 Odoo 实测。真实评估需要获准且有代表性的输入、选定模型与配置、独立确定的预期答案和实际业务结果。执行后才能报告数据，并说明样本量与未解决用例。 架构与平台 ## 接下来读什么 对长期交付产生影响的框架、平台与系统设计选择。 [从这里开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [Odoo 与 n8n：重试创建订单，如何避免重复写入](/zh/blog/odoo-n8n-idempotency-recovery/) - [HubSpot 与 Odoo：谁有权修改客户数据？](/zh/blog/hubspot-odoo-customer-data-ownership/) - [Odoo 供应商交期变更：原生规则、n8n 还是 AI 智能体？](/zh/blog/odoo-native-automation-n8n-ai-agent/) - [Odoo 发票 OCR：什么时候需要定制异常审核流程？](/zh/blog/odoo-invoice-ocr-ai-exception-workflow/) - [Odoo Online 转 Odoo.sh：先证明集成需求](/zh/blog/odoo-online-to-sh-integration-decision/) [上一篇文章**HubSpot 与 Odoo：谁有权修改客户数据？**](/zh/blog/hubspot-odoo-customer-data-ownership/) [下一篇文章**Odoo 供应商交期变更：原生规则、n8n 还是 AI 智能体？**](/zh/blog/odoo-native-automation-n8n-ai-agent/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-invoice-ocr-ai-exception-workflow/)