业务规则、决策边界与常见问题排查 (Policy & FAQ)
适用角色：全体业务人员、实施顾问、一线客服、系统管理员
1. 核心业务规则与判定决策矩阵
为保证复杂网络环境和多终端交互下状态的一致性，系统定义了以下核心仲裁矩阵：
| 判定维度 | 触发条件 | 系统行为与仲裁逻辑 | 业务目的与价值 |
|---|---|---|---|
| 时间有效窗口 | 客户近 48 小时 内提交过询价单 | 纳入“待处理询价单”候选集合 | 超过 48 小时的单据通常已线下处理或过期，避免过早的历史单被误拉回 |
| 单据状态限制 | 必须严格处于 sent 状态 | 允许恢复为草稿；若已成单 (sale) 或已取消 (cancel) 则绝对不弹窗 | 防止篡改已经进入仓库拣货或已归档作废的历史业务单据 |
| 多单冲突仲裁 | 客户 48h 内存在 2 张以上 sent 单 | 默认自动选取最新提交的一张 进行提示 | 极简化交互，避免在弹窗罗列过多列表增加客户认知负担 |
| 触发频率控制 | 仅在客户 购物车为空 (qty=0) 时首次加购触发 | 购物车已有商品时，后续加购直接入车，不重复弹窗 | 消除干扰，确保客户常规连续选购时的流畅度 |
| 数据防御保护 | 浏览器 sessionStorage 存在残留缓存 | 采用**「徽标与缓存双端一致」**校验，以服务端为准 | 彻底解决因浏览器本地缓存残留导致的不弹窗隐患 |
2. 连续询价追加场景深度拆解
【客户点击商品加入购物车】
│
▼
【检查当前购物车件数】
┌────────┴────────┐
▼ ▼
[件数 > 0] [件数 == 0]
│ │
▼ ▼
[直接常规加购] 【检查 48h 内是否有 sent 询价单】
(不打扰用户) ┌────────┴────────┐
▼ ▼
[无符合单据] [存在符合单据]
│ │
▼ ▼
[新建草稿单] [弹出引导弹窗]
┌─────┴─────┐
▼ ▼
[点击恢复追加] [点击新建单据]
│ │
▼ ▼
[拉回原单并追加] [开辟新购物车]
3. 高频业务常见问题解答 (FAQ)
Q1：为什么客户点击加购时，没有弹出恢复历史询价单的弹窗？
请按以下步骤逐一排查：
- 检查单据状态：该客户的历史单据是否已被销售员点击了【确认订单】变为了销售订单（
sale）？只有状态为sent（报价单已发送）的单据才会触发提示； - 检查创建时间：距离上次提报是否已经超过了 48 小时？超过 48 小时的单据系统自动视作历史归档，不再提示恢复；
- 检查购物车状态：客户购物车中是否已经有其他商品？若购物车非空，系统默认用户正在进行当前选购，不会弹窗打扰；
- 检查登录状态：客户是否处于未登录（访客）状态？未登录用户不具备单据所有权，直接走原生流程。
Q2：如果销售员正在后台修改单据，客户在前台点击“恢复并追加”，会发生什么？
- 系统采用行级锁与标准 Odoo
action_draft()机制； - 客户拉回草稿时，新商品将直接追加至明细行末尾；
- 销售人员在后台刷新页面即可看到新追加的商品行与最新总额，有效避免信息脱节。
Q3：为什么部分直客被加入了白名单，依然看到了“提交询价单”而不是直接支付？
请检查该客户的 【联系人档案】➔【销售与采购】➔【商城成单权限】：
- 如果此处被人工配置为了 「禁止直接成单 (Block Direct Order)」，则单客的强制限制优先级高于标签白名单；
- 将其改回 「继承 (Inherit)」 或 「允许 (Allow)」 即可恢复直接支付成单。
Q4：在多语言环境下，提示文案和弹窗按钮是否会显示英文？
- 系统已对所有新增的提示文本、引导弹窗、按钮词条进行了标准国际化抽取；
- 在中文环境下显示「待处理询价单提示」、「恢复购物车并追加」与「创建全新询价单」；
- 在英文站点下自动切换为官方标准的英文字典，绝无中英文混杂问题。