{
  "id": "410ab59941ee47351302acc419",
  "serialNumber": "VWCG-1422",
  "description": "# VWCG-1422 备餐中直接核销实施方案\n\n日期：2026-10-12。关联 UC：UC-ORDER-SKIP-SERVING-001 v0.2。\nUse Case ID：UC-ORDER-SKIP-SERVING-001 v0.2。DoR: READY。\n状态：用户已批准方案并要求在develop_binzhou实施；用户已明确10/20均可直接核销完成。本文件不是已开发或已验收声明。\n执行模式：常规Codex，当前仅方案。实施时按跨端状态和并发风险重新选择组织方式。\n\n## 1. 目标与范围\n角色：消费机操作人员扫码取餐码或输入订单编号；手机用户查看本人订单；PC人员按原权限查询；服务端裁定。\n目标：省略扫码出餐仍可核销，已完成状态不回退，手机和叫号屏最终展示一致。\n范围：当前发布环境原核销适用订单，新增允许状态10，保留20；已有有效10/20订单按同一规则处理，不批量改历史数据、不新增后台开关、不扩大跨档口或取餐柜权限。\n主改store与ai_app；ai_api、消费机、点餐机、PC和叫号屏核对契约并回归，有硬编码拦截时才改实际命中处。\n\n## 2. 状态契约\n- 10备餐中：可出餐到20，也可直接核销到30。\n- 20待取餐：可再次叫号并保持20，也可核销到30。\n- 30已完成：拒绝重复核销；出餐返回当前完成状态，不写出餐或叫号信息。\n- 其他状态：仍拒绝核销。\n- 支付成功不自动写30，也不为允许核销而强制写20；各入口原有取餐记录生成方式保持。\n- 手机、PC现有状态文案保持备餐中/待取餐/已完成；不新建“待核销”状态码。\n\n## 3. 前置、触发和后置\n触发：消费机使用既有bookingVerify接口提交取餐码或订单编号。\n前置：设备与API鉴权有效、订单未删除且已支付、未取消/待取消、退款状态0或2、存在非空取餐号、设备/订单/取餐记录范围一致、非取餐柜订单；取餐状态10或20。\n成功：prepare_status=30；complete_type=1；首次核销时间、方式和设备写入一次。\n失败：保持原状态和记录；数据库异常整体回滚，网络不确定时查结果再重试。\n\n## 4. 主/分支流程\n| 步骤 | 动作 | 数据/API | 验收 |\n| --- | --- | --- | --- |\n| M1 | 消费机扫码或输入订单编号 | POST /api/consume/bookingVerify；请求响应结构不变 | AC1 |\n| M2 | 服务端验证原有业务条件，允许10/20 | meal_order、equipment、meal_order_pickup | AC1/AC2/AC4 |\n| M3 | 事务锁定订单及取餐记录，原子核销 | 按现有锁顺序主订单→取餐记录，UPDATE条件状态IN(10,20) | AC1/AC3 |\n| M4 | 消费机得到原有成功响应 | 返回30与首次核销信息 | AC1 |\n| M5 | 手机刷新，PC查询完成信息，叫号队列剔除 | 现有详情及pickupQueue | AC5/AC6 |\n| A1 | 已先出餐的20订单核销 | 复用原路径 | AC2 |\n| A2 | 10直接核销 | 不制造10→20中间事件，不触发叫号 | AC1 |\n| A3 | 30再次核销或随后出餐 | 核销返回已完成；出餐按兼容响应返回当前30，不改变字段 | AC3/AC7 |\n\n## 5. 服务端改动\n### bookingVerify\n移除状态10“订单尚未出餐”拒绝分支；允许集合改为[10,20]，条件UPDATE同步改为IN(10,20)。保留现有订单和取餐记录行锁、事务、设备范围、支付/取消/退款和取餐柜隔离。\n更新字段：prepare_status=30、complete_type=1、pickup_complete_time=当前时间、pickup_verify_type=1扫码或2单号、pickup_equipment_code=核销设备、update_time。\n更新行数0时回读并返回已完成或当前状态错误；不能把未实际更新当成功。重复请求、并发、事务回滚不覆盖首次信息。\n出餐字段pickup_ready_time、serve_equipment_code、last_call_time、call_count保持原值。未出餐默认时间不可当成真实出餐时间展示；已出餐信息保留。\n\n### serveOrder\n避免先读10后按id无条件更新造成30→20：首次出餐必须按id+prepare_status=10条件更新；重叫号必须按id+prepare_status=20条件更新，call_count数据库原子加1。未命中时重新读取状态并按状态处理，禁止依据旧读值返回20。\n核销已先完成则两类出餐更新都不能命中30，不新写叫号；出餐先成功则核销可从20完成。必要事务和锁实现必须保持与核销相容的顺序。\n并发测试区分首次出餐/再次叫号/核销，不能只验证两次核销。\n\n## 6. 手机和其他端\nai_app订单详情将轮询条件从20扩为10/20，并限定有取餐记录的订单；前台onShow立即刷新，单次请求返回后延迟3秒再发，保留单飞、防旧响应覆盖、隐藏/销毁停止。\n30后停止轮询、显示已完成、隐藏取餐码；查询失败保留当前界面并可恢复重试。无取餐码订单沿用订单二维码逻辑。\nai_api既有状态透传优先复用。消费机/点餐机若存在10状态本地拒绝才调整；既有扫码和手输入口、请求结构不变。\nPC详情复用现有核销字段；叫号服务既有查询仅取10/20，30自然退出；叫号屏下一次成功刷新移除号码，清理该号码待播报项。已开始的语音和缓存窗口按现有刷新机制验证，不承诺零延迟撤回已播放语音。\n\n## 7. 数据和兼容\n复用ydy_meal_order_pickup现有字段，不增表、不增字段、不新增状态、不补造出餐、不批量迁移。\n发布前确认原VWCG-1379字段已部署；缺少旧字段的环境先完成原版本依赖，不能直接发本功能。\nMealOrderPickupComplete继续跨日将10/20置30，系统完成complete_type=0，消费机完成=1；自动完成与核销竞争时只允许一方从未完成状态成功，不覆盖核销信息。\n保留万益生现有同步路径，不添加未经确认的新触发；验证两种完成来源及并发下现有同步兼容，不宣称本轮已验证。\n\n## 8. 异常与恢复\n- E1重复/两机并发：最多一次成功，其余已完成；首次信息保持。\n- E2出餐和核销并发：终态30不可回退，完成后不生成新叫号。\n- E3数据库失败：事务回滚，订单仍可按实际状态安全重试。\n- E4请求超时：先回查状态；再次请求不得产生第二次核销记录。沿用已有“订单已完成”响应契约。\n- E5未支付/取消/退款1或3/越权/无取餐号/取餐柜/未知状态：继续拒绝，无副作用。\n- E6手机断网：显示当前已有数据，重新联网后重试或onShow刷新，不能本地猜测已完成。\n\n## 9. 验收与测试\n| 编号 | 给定/操作 | 预期与测试 |\n| --- | --- | --- |\n| AC1 | 合法10订单分别扫码、手输 | 一次到30，核销字段正确，出餐字段原值；API与真机 |\n| AC2 | 合法20订单分别扫码、手输 | 原流程通过，出餐记录不变；API与真机 |\n| AC3 | 重复、两机并发、断网重试 | 只完成一次、首次信息不变；真实DB双连接/故障恢复 |\n| AC4 | 未支付、取消、退款1/3、越权、柜机、无号、未知状态；退款2 | 非法拒绝无变化；退款2按原规则允许；API权限矩阵 |\n| AC5 | 手机10/20前台停留并被核销 | 自动到30、隐藏取餐码、停止刷新；慢请求单飞、后台停止；手机E2E |\n| AC6 | PC及叫号屏刷新 | PC核销信息正确；下一次成功队列刷新无该号；屏E2E |\n| AC7 | 出餐先读10后核销、核销后出餐、20叫号并发核销 | 终态30不回退，不覆盖首次信息；数据库并发测试 |\n| AC8 | 跨日任务与核销竞争、两种完成来源 | 完成来源正确，现有外部同步兼容；集成回归 |\n| AC9 | 旧有效10/20订单、无取餐码订单 | 前者同新规则；后者沿用原展示和限制；回归 |\n\n建议验收时效：接口成功且详情查询单次耗时≤1秒时，手机前台≤5秒反映完成；叫号屏单次查询≤1秒时≤6秒移除（现有5秒轮询）。弱网不承诺此时限，成功回读后收敛。\n增加10状态轮询会增加请求量，采用现有单飞策略，统计活跃页面数与请求率，在目标环境按实际终端数量核对现有容量和SLA；没有现场负载数据不声称性能通过。\n自动化优先修改BookingVerifyTest和手机test-order-detail-pickup-polling.js，补出餐条件更新与核销并发测试；复用原接口鉴权、订单详情、退款、万益生及滨州回归。真实并发不能只用SQLite单元测试代替。\n\n## 10. 实施与交付\n1. 后端放开10核销，并修出餐条件更新；补接口及并发测试。\n2. 手机扩展10/20轮询；多端契约核验，确有本地拦截时补改。\n3. 测试环境完成扫码/手输、手机/叫号屏/PC、退款和旧数据回归。\n4. 建议先发布兼容旧后端的手机刷新版本，再启用新后端，缩短旧手机不刷新窗口；必须按实际客户端版本可用情况安排，不把审核提交视为发布成功。\n5. 不需本需求新增SQL；发布验证原核销字段存在。回滚应用保留30和真实核销信息，不把已完成订单改回去。\n\n## 11. 决策状态\n用户已确认10/20直接到30，原Q-01业务选择关闭；原10/20/30映射已由当前代码确认。\n本方案默认延续原核销范围和取餐柜隔离，叫号完成后退出，无新增配置。同步时效为本方案建议验收值；设备具体版本/现场负载在实施与发布准备核对，不再要求客户重复解释已确认业务。\n2026-10-12 用户授权拆解需求并在develop_binzhou实施。研发完成、发布和真机验收分别记录。\n",
  "status": {
    "name": "待处理",
    "nameEn": "To Do",
    "displayName": "待处理",
    "id": "100005"
  }
}