开放平台开发文档对接案例 / 代煎中心
代煎中心
诊所门诊开单并收费后，ABC 生成发药单；可以由诊所员工完成发药，也可以由代煎中心调用发药接口。代煎中心随后回传加工和快递状态。
业务背景
代煎中心承接诊所、连锁或药房开出的代煎处方。机构在 ABC 完成门诊开单和收费后，ABC 生成发药单；代煎中心根据发药单完成审方、调配、煎煮、包装和快递，并把加工状态与快递信息回传 ABC。这样处方、收费、库存和发药记录都留在机构账上，代煎中心不需要再维护一套机构业务数据，患者也能通过机构了解代煎进度和配送情况。
方式一：诊所员工发药
ABC 生成发药单后，由诊所员工在 ABC 完成发药。代煎中心只订阅事件 503，不订阅事件 500。
- ABC门诊开单并收费在 ABC 完成
- ABC生成发药单
- 诊所员工员工点击发药在 ABC 操作
- ABC更新发药单随后推送事件 503 发药携带：id（dispensingSheetId）
- 代煎中心回传加工状态
PUT /dispensing/processing-status - 代煎中心回传快递信息
PUT /dispensing/delivery结束
方式二：代煎中心调用发药接口
代煎中心订阅事件 500，收到创建发药单通知后调用发药接口。调用发药接口后仍会收到事件 503，按 dispensingSheetId 幂等处理，不需要重复发药。
- ABC门诊开单并收费在 ABC 完成
- ABC生成发药单随后推送事件 500 创建发药单携带：id（dispensingSheetId） · sourceSheetId（chargeSheetId）
- 代煎中心调用发药接口
PUT /dispensing/{dispensingSheetId}/dispense-all - 代煎中心回传加工状态
PUT /dispensing/processing-status - 代煎中心回传快递信息
PUT /dispensing/delivery结束
加工状态回传和发药没有严格先后顺序；上图按当前常见顺序展示为先发药，再回传加工状态。
常见问题
只订阅事件 503 时，如何取得发药单 ID？
事件 503 的 id 就是 dispensingSheetId。只处理员工发药的场景不需要先订阅事件 500，直接用 503 中的 id 找到对应发药单即可。
事件 503 是否包含收费单 ID？
不包含。503 的 id 是 dispensingSheetId，不携带 chargeSheetId；如果业务需要收费单关系，应订阅事件 500 并从 sourceSheetId 取得 chargeSheetId，或在收到 500 时保存映射。
代煎处方商品如何映射？
先查询 ABC 商品列表或详情，持久化第三方商品编码到 productId、shortId 的映射，再用 productId 引用商品。接口支持商品编码时，同一请求内应统一使用 productShortId。