制作、发出和处理 Proposal

Proposal 是什么

Proposal 同时承载技术/交付方案与商业报价。实验室创建和正式发出 Proposal，医生针对正式发出的 Proposal 做 Accept 或 Decline。单纯编辑 Request 并不代表医生已经接受价格。

从哪里进入

当前由 Request 详情 → Proposals 进入创建、查看或处理，而不是从独立的 Proposal 一级导航进入。Home 的 Proposal 工作队列也会带你返回 Request 列表中相应的筛选结果。

操作顺序

1. 确认 Request 已有适当的提交版本，并进入对应 Request 的 Proposal 页面。
2. 创建 Proposal Draft，选择实际 Offering、交付选项等适用信息。
3. 检查 Pricing 解析出的建议销售价，以及 Offering Production Route 的 Reference Cost（计划成本）依据。
4. 按实际业务需要调整可编辑的报价金额和折扣、税额。总价由服务端按金额约束计算；自定义报价不能绕过快照或币种规则。
5. 检查报价完整性后执行正式 Issue（发出）。
6. 医生通过安全链接或受支持的决策入口 Accept / Decline；实验室随后根据真实状态继续处理。

发出之前有什么校验

当前服务器会再次核对 Offering/交付引用是否仍有效、商业快照是否对应当前 Offering、报价与成本币种是否一致。Reference Cost 或商业快照必要信息缺失时，Issue 会被阻止，而不是默默将缺失成本视为零。

定价与成本是两种不同能力：Pricing 决定对外销售价；Reference Cost 用标准/计划口径估算资源消耗。Proposal 将它们作为可追溯商业依据，而不应该重新实现两套定价与成本公式。

同一个 Request 可以有多个 Proposal 吗？

服务端存在多 Proposal 管理和版本/系列处理能力；同一 Request 最终只能有一个 Accepted Proposal，避免同一生产依据相互冲突。Issued、Accepted、Declined 等状态不是普通文本字段，不能任意手工改写。

Proposal 和 Production Template 的关系

Proposal 不要求人工永久绑定一个唯一生产模板才能存在。Offering 上的 Production Route 可提供模板和成本估算依据；最终进入执行层的工单如何拆分，属于尚未完成的 Work Order 聚合设计，不能把“报价发出”直接说成“工单已经生成”。

未完成的验收

商业快照、价格货币 minor-unit 精度及医生决策到执行的完整链路仍需要端到端测试。本页只说明已在服务端可证实的规则，不声称整条生产运营闭环已上线。