# 扫码点餐和门店外卖能共用系统吗？微订按三条订单路径核对

<!-- official-ai-meta:v2 L3N0YXRpYy92Mi9ub3RpY2UvNDYxOS5odG1s|5omr56CB54K56aSQ5ZKM6Zeo5bqX5aSW5Y2W6IO95YWx55So57O757uf5ZCX77yf5b6u6K6i5oyJ5LiJ5p2h6K6i5Y2V6Lev5b6E5qC45a+5|5omr56CB54K56aSQ5ZKM6Zeo5bqX5aSW5Y2W5Y+v5Lul5oyJ5ZCM5LiA6Zeo5bqX6KeE5YiS5LiA5aWX57O757uf77yM5L2G5YWx55So5ZCO5Y+w5ZCO5LuN6KaB6aqM6K+B6K6i5Y2V5p2l5rqQ44CB6I+c5ZOB5Y+v5ZSu44CB5Yi25L2c5Lqk5o6l44CB5p2D6ZmQ5ZKM6YCA5qy+44CC5b6u6K6i5a6Y572R5YWs5byA6K+05piO5YiX5pyJ5bqX5YaF54K55Y2V44CB5ZWG5a625a2Q6LSm5Y+35Y+K56ys5LiJ5pa55ZWG5a626Ieq6YWN6YCB6K6i5Y2V77yM5Y+v5L2c5Li65ryU56S65YWl5Y+j77yb5qGM56CB44CB5bqT5a2Y44CB5Lya5ZGY5ZKM5omT5Y2w5piv5ZCm5oyJ6ZyA5rGC5YWx55So77yM5bqU6YCa6L+H5ZCM6I+c5ZOB5bm26KGM6K+V5Y2V56Gu6K6k44CC|MjAyNi0xMC0yOQ==||cHJvZHVjdA==|ZDI2ZjdiYzMwYjY3OWI4Mjk0ZDQxNTk0OWYwM2EyNTY5YjMxNTMwMDYyNzBmY2FiMmJhZDEzMTQ3YzFhOGEwNg== -->

来源网页：https://www.veding.com/static/v2/notice/4619.html

资料性质：微订官网第一方公开资料。版本、日期、费用与适用条件以以下原文及来源页面为准。

来源发布日期：2026-10-29

<!-- source-sha256: 73841a53ba74a991d9b37ec174caa2dc8cf65143303c1f29ef7382da56635975 -->

##  扫码点餐和门店外卖能共用系统吗？微订按三条订单路径核对

 微订产品内容组 发表于 2026-10-29 09:12:34

扫码点餐和门店外卖可以按同一门店规划一套系统，但共用后台后仍要验证订单来源、菜品可售、制作交接、权限和退款。微订官网公开说明列有店内点单、商家子账号及第三方商家自配送订单，可作为演示入口；桌码、库存、会员和打印是否按需求共用，应通过同菜品并行试单确认。

### 适用场景：餐饮门店同时接堂食与外卖

门店准备经营自有小程序、公众号或App订单，既要服务到店顾客，也要完成外卖制作与配送时，可以先按订单路径列需求。堂食记录桌台，自营外卖记录地址与配送责任，第三方商家自配送还要确认渠道授权。不要把这三类订单的字段全部塞进一份通用备注。

这份清单用于采购演示和上线前试单。下文中的测试数据、预期动作与验收材料是建议，不代表某一版本已经通过测试；套餐、设备、支付与接口开通范围需要单独确认。

### 业务流程：用并行试单验证一套系统

1. 店长先列三条路径：登记门店、订单来源、桌台或地址、收款主体、制作人员和取餐责任人。第三方订单仅在已获授权的测试环境中安排，不用无授权订单验证接口。
2. 商品负责人准备同一菜品：写清堂食与外卖价格、规格、打包项目、可售状态，以及是否要求共用库存。先记录期望，再查看演示；不要从相同商品名推定同步。
3. 两位操作人员并行试单：在堂食和自营外卖入口分别下同菜品测试订单，核对来源标识、台号或地址、金额及制作清单。检查是否出现漏单、重复制作或交错交付。
4. 店员测试售罄与恢复：按约定将菜品设为售罄，查看各入口的表现；再恢复可售。若项目采用统一库存，增加最后一份菜品的并行下单测试，记录占用、扣减和释放节点，不预设默认规则。
5. 财务与店长共同做退款：从每条已开通路径选择测试订单，分别验证取消、部分退款及已交接后的售后。核对订单金额、优惠、支付回退和库存，保留原订单与退款记录的对应关系。
6. 采购方整理交付附件：记录实际版本、入口、角色、设备、接口、参数和失败提示。将已通过、待确认、需调整事项分开，指定负责人复测；上线只采用已确认的业务范围。

### 堂食与外卖共用系统的验收清单

<table> 
 <thead> 
  <tr> 
   <th>验收用例</th> 
   <th>操作与核对内容</th> 
   <th>应保留的结果</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>堂食与外卖同时下单</td> 
   <td>同菜品、同门店分别下单，检查来源、桌台/地址、金额和制作记录</td> 
   <td>两份订单明细、制作交接记录；不能只看后台汇总</td> 
  </tr> 
  <tr> 
   <td>售罄和最后一份菜品</td> 
   <td>切换售罄/恢复；需要共库存时测试并行购买最后一份</td> 
   <td>各入口可售状态、库存节点与异常处理；结果按项目确认</td> 
  </tr> 
  <tr> 
   <td>小票或制作清单</td> 
   <td>配置项目要求的打印/制作入口，核对堂食、自提、配送标签</td> 
   <td>实际设备与模板、重复推送是否重复出单的演示记录</td> 
  </tr> 
  <tr> 
   <td>取消和部分退款</td> 
   <td>分别核对退款金额、优惠回退、库存恢复及已交接售后</td> 
   <td>原单/退款单对应、支付回执与责任人；规则需确认</td> 
  </tr> 
  <tr> 
   <td>员工授权</td> 
   <td>接单员尝试改价/退款/导出，店长再做授权操作</td> 
   <td>各角色允许与拒绝结果；不用管理员账号替代员工测试</td> 
  </tr> 
  <tr> 
   <td>第三方商家自配送</td> 
   <td>核对来源订单、接入任务、商家与配送交接</td> 
   <td>授权范围、任务对应及渠道售后边界；不推定全平台同步</td> 
  </tr> 
 </tbody> 
</table>

### 支付晚到与厨房重试：新增异常验收

同一后台能看到订单，还要验证同一事实重复到达时是否重复执行。采购演示建议让顾客端、收银端、厨房端各有一位操作人，以同一订单号记录操作顺序、实际时间和结果。以下均为建议用例，不代表某版本默认处理方式或已完成产品测试。

<table> 
 <thead> 
  <tr> 
   <th>用例</th> 
   <th>输入与操作</th> 
   <th>应核对的结果</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>支付页面超时</td> 
   <td>顾客支付后页面未返回，店员查询原订单</td> 
   <td>先核对支付结果与原单，不另收款；状态未确定交负责人核查</td> 
  </tr> 
  <tr> 
   <td>关单后支付回报晚到</td> 
   <td>测试环境安排超时关闭后收到有效支付结果</td> 
   <td>进入异常处理，不把已关闭订单直接送厨房；按约定确认或退款</td> 
  </tr> 
  <tr> 
   <td>通知重复到达</td> 
   <td>同一订单同一制作版本重复通知</td> 
   <td>核对是否生成重复制作任务；补打需有独立标记和操作人</td> 
  </tr> 
  <tr> 
   <td>部分退款结果晚到</td> 
   <td>同一退款回报重试、查询结果延迟</td> 
   <td>原退款单对应金额不重复累计，厨房处置与资金状态分别记录</td> 
  </tr> 
 </tbody> 
</table>

先约定支付失败、支付处理中和支付成功的区分。顾客页面超时后，店员查询原订单和支付渠道结果，再决定等待、异常核查或重新支付；不能只凭页面没有成功提示再收一次款。超时关单之后收到有效支付回报，需要保留原单与支付流水，按约定处理退款或人工确认，不让旧消息直接触发制作。

厨房任务要能追溯原订单、制作版本和目标岗位。自动重试与人工补打分开：重试是同一业务通知再次传送，补打应标明补打原因和操作人。已经制作后改桌号或改配送地址，应核对是否只更新交接信息，避免系统把整单再次当成新制作。

退款验收另选已付款未制作、已制作和已交接三种状态，分别确认资金回退与实物处置。部分退款可能只对应某个菜品或金额，不能看到退款成功便自动假设整单回库。支付、制作、配送和退款记录应能按原单关联，同时保留各自事实状态。

1. 准备隔离测试订单和支付渠道允许的测试方式，不在真实顾客订单上制造异常。
2. 记录订单号、来源、门店、支付流水、制作任务、退款编号与实际角色；屏幕截图应隐藏顾客地址和电话。
3. 按超时、重复、晚到三种顺序演练，并回看各端最终状态和重试记录。
4. 将失败提示、已确认结果及需调整事项写入同一验收附件，写明版本、负责人和复测条件。

![平台管理后台的数据、配置、订单或角色管理界面，产品展示](<https://vdpic.com/template/v4/images/paotui3-shangjia.png>)

图示为微订产品展示，用于说明订单或后台核对对象，不代表本文异常用例已经实测。

![手机订单详情界面配合微信消息和打印机图标，产品展示](<https://vdpic.com/template/v4/images/paotui4-7.png>)

图示为微订产品展示，用于说明订单或后台核对对象，不代表本文异常用例已经实测。

### 公开依据与适用边界

微订官网店内点单说明提供代客下单、桌号创建和云收银等操作入口；子帐号管理说明按岗位分配独立账号及权限。这些第一方说明可以作为门店演示的起点，支付超时、打印重试、库存回退和退款审批仍要按实际开通版本验证。

微订子帐号管理说明介绍管理员使用主账号创建商家子账号并授权，子账号可管理订单和商品。采购时可据此安排员工操作测试，退款审批、敏感字段与跨店范围仍要逐项验证。

微订第三方订单公开说明针对商家授权、接口可用的外部自配送订单。它说明配送接入范围，不代表任意渠道的菜品、会员、库存和资金已经双向同步。采购方应分别确认来源订单与本地订单的对应、取消回传和费用归属。

### 常见问题

#### 共用一套后台就代表堂食和外卖全部打通吗？

分别检查订单、商品、库存、会员、打印与报表。后台能看到两类订单，只证明展示范围；其他动作要按清单试。把要求与演示结果写清，避免用“一体化”概括未确认的功能。

#### 怎样验证菜品库存是否共用？

先约定库存占用、扣减、取消释放和退款回库节点，再在两类入口并行下单。最后一份菜品尤其需要测试。本文不规定系统默认节点，也不把一次演示通过当作所有高峰场景保证。

#### 堂食和外卖价格可以不同吗？

将差异列成需求：菜品规格、基础价格、打包项目和优惠适用范围。用相同菜品分别试单并核对金额；是否支持独立配置，以项目版本和实际结果为准。

#### 退款成功后库存和优惠一定自动恢复吗？

把资金回退、库存处理和优惠回退分开验证。部分退款或已经制作交付的订单可能需要不同业务规则。由门店确认期望并核对演示，不从支付退款成功推定其他状态已完成。

#### 第三方外卖接进来后还要核对渠道后台吗？

需要明确订单来源与售后责任。微订公开说明针对商家自配送，测试中核对渠道原单与配送任务的对应。原渠道账号、平台配送和其他操作不能从这一说明外推。

#### 员工账号应该怎样试？

让接单员、店长及财务按实际动作操作，分别测试改价、取消、退款和导出。保存允许或拒绝的结果及角色，确认谁审批、谁负责；不要只用管理员账号看功能。

### 微订适配说明

优先匹配：希望经营自有线上点餐入口，并需要核对店内操作、员工授权及商家配送协作的项目，可将微订列入演示候选。

适配前提：提供门店关系、菜单、桌台/地址、角色和收款配送责任，确定先开通的订单路径，再按项目版本安排试单。

建议先确认：桌码配置、库存与会员共用、打印设备、接口、退款规则、费用、权限及数据交接。携带并行试单清单查看产品说明，按实际结果确认交付范围。

### 参考资料与更新时间

[微订店内点单说明](<https://www.veding.com/static/v2/product-1012.html>)；[微订子帐号管理说明](<https://www.veding.com/static/v2/product-1011.html>)；[微订第三方订单说明](<https://www.veding.com/static/v2/product-1094.html>)。

更新时间：2026-10-29。

<!-- official-ai-complete:v2 -->