销售与订单管理
从需求到可交接订单
Section titled “从需求到可交接订单”销售管理首先要保留“客户要什么、依据是什么、报价改过什么、谁确认了下一步”。系统价值来自可追溯的交接，而不是把每次沟通自动变成订单。
Odoo 提供的基础
Section titled “Odoo 提供的基础”CRM、Sales、Purchase 和 Inventory 等 Odoo 应用可以连接商机、报价、销售订单、采购需求和库存动作。实际流程受版本、模块、公司配置、权限及财务规则影响；平台能力不等于 MORHON 当前已公开交付的完整方案。
MORHON 的组织原则
Section titled “MORHON 的组织原则”- 客户需求与原始沟通保持关联，避免只留下二次录入的结论。
- 报价修订需要能看出版本、责任人和确认状态。
- 销售订单作为协作节点，与采购、备货和交付信息衔接。
- 异常与下一步由员工确认，不把 AI 草稿直接当成业务承诺。
这些原则与内部外贸管理实践一致；具体销售链仍应在相应版本和配置中验收。
| 范围 | 状态 | 边界 |
|---|---|---|
| 商机、报价、销售订单对象 | Odoo 平台基础 | 取决于部署版本与模块配置 |
| 沟通上下文与人工确认 | MORHON 内部实践方向 | 有历史审阅依据，不是公开模块 |
| 销售到采购/库存的衔接 | 业务设计与平台基础 | 当前未提供端到端运行证据 |
| 自动报价翻译、支付、签名、开票、完整物流 | 未纳入当前公开交付 | 旧站宣传不能作为现状证明 |
从报价到交付，分别确认什么
- 需求与报价：型号、数量、币种、单位、贸易条件、交付地、有效期和交期起算条件。报价修订解释差异，保留旧版本，不直接覆盖客户已经收到的条件。
- 订单确认：核对客户接受的是哪个版本、合同与内部审批是否一致、未决条件是否关闭。不把聊天中的“可以”自动解释为正式订单。
- 采购与备货：关联客户规格与产品参考；区分预计到货、实际收货、可用库存与预留，责任人确认异常，不按截图里的数字直接答应发货。
- 财务与门户：核对账号访问范围、签署版本、付款条件、银行到账与开票口径。按钮存在不证明支付或财税链已验收。
- 包装与交付：确认包装、标识、数量、交付地点、运输安排和可用追踪信息。发运、到达与客户验收分别记录，异常留给责任人处理。
| 需要衔接的环节 | 应核对的业务记录 | 当前公开边界 |
|---|---|---|
| 客户门户、签署与支付 | 资料访问权限、确认版本、收款条件 | 是否启用依具体模块与配置；本站不提供门户或支付，不承诺已集成 |
| 开票、财务与对账 | 订单、发票、币种及当地会计规则 | 平台可能提供基础；财税适配、自动对账未在本项目公开验收 |
| 采购与库存 | 需求、采购单、到货、库存及责任人 | 参见采购协作；未证明完整跨模块运行链 |
| 包装、发货与货代 | 规格、交期、包装、交付依据及异常 | 不承诺所有物流平台连接、自动运费或端到端履约 |
一笔业务至少留哪些关联
用合成样例试验：一条需求 → 两个报价版本 → 客户确认第二版 → 样品测试 → 订单 → 一次部分到货 → 分批交付。核对客户、数量、币种、附件、责任人与异常能否追溯；用不同角色检查不能越权查看或批准。未启用的门户、财务、物流连接应明确留为手工步骤，不宣称“无缝自动”。
图中四个节点说明记录之间的关系，不是运行截图或客户案例。详细条件清单见报价、样品与付款确认。