让价格依据和商务决定留在报价上。
报价往往要汇集客户要求、服务范围、数量、币种和折扣。信息散在对话或表格里时，审批人难以核对当前版本。ORYH让销售、智能体和审批人围绕同一份报价记录办理业务。
这体现了AI原生ERP的工作方式：人通过智能体交办和确认，智能体调用获准的能力，企业系统校验并保存结果。
从一句交办，到一项可核对的决定。
「按约定的服务包做明远的续约报价，这次的折扣走特批，出完先给我看完整版。」
智能体确认客户、产品和当前价格依据
ORYH 校验行项目、数量、币种和归属
完整报价单回读，等待确认
记录版本并启动审批流程
审批人看到的是同一份可追溯的报价事实
客户接受报价后，可以通过报价转销售订单流程承接已接受的商务事实，并保留来源引用。
智能体整理，人核对和决定。
- 客户与产品
- 核对客户、联系人、服务范围和产品引用，补齐缺失条件。
- 价格与明细
- 查看数量、币种、单价、折扣和合计，确认价格依据。
- 例外与审批
- 说明特批原因，核对有权处理该例外的审批路径。
员工确认与审批人决定是不同动作。智能体的建议不会自动成为审批结果，哪些操作可以执行，由企业配置的权限与审批边界决定。
办没办成，要看企业留下的记录。
折扣理由、版本变化和审批意见都挂在同一张报价单上，不散落在聊天记录里。
记录核对清单 · 非客户运行截图
- 客户与联系人引用
- 报价版本链
- 行项目价格依据
- 审批事实
- 最终商务状态
演示时打开实际保存的单据，检查来源、状态、决定与变更历史。对话中说“完成了”，仍然需要业务记录作为依据。相关模型见ORYH平台能力。
把例外情况也跑一遍。
价格或商务条件缺失
由智能体补问，员工提供依据。尚未确认的条件不应被补写成已达成的商务约定。
折扣需要特批
调价权限与特批阈值由企业配置的流程决定，聊天中的要求不会增加权限。
客户要求改价
保留来源版本，核对变更后的完整报价，再按配置处理确认和审批。
审批通过后要发给客户
报价获批和对外发送是不同动作。文档生成、邮件或客户系统发送，需要已实现的对接或由有权的人接手。
如何验证你们的流程？
按企业习惯选择 WorkBuddy、Codex、Claude Code、Hermes、OpenClaw 等兼容客户端。客户端接入与本场景验证分别核对，具体范围以企业启用的能力为准。
- 准备一份脱敏报价、产品与价格依据，以及一个折扣例外。
- 用选定智能体演示正常报价、缺少价格和退回修改。
- 检查报价版本与审批记录，再核对已接受报价转销售订单的来源关系。
由流程负责人约定通过、退回、拒绝和可追溯的标准，记录核对时间、修正情况与最终证据，再决定是否扩展。可先查看企业试点准备。