连锁餐饮点餐系统先按经营与收款关系选，再用两家测试店核对独立接单、总部汇总、菜单变更和员工授权。验收应测发布失败如何恢复、员工调店后旧权限是否撤销，以及跨日退款如何追溯。微订公开说明列有店内点单和商家子账号，可作为自有线上点餐项目的演示候选；跨店会员、总部菜单下发、供应链与断网营业需逐项确认版本和交付范围。
适用场景：多家餐饮门店准备采购点餐系统
门店需要各自接单，总部需要统一看数据，这两个要求要分开验收。先列经营主体、收款主体、门店账号及堂食、外卖、自提入口。直营店和加盟店的资金、会员与管理授权可以不同，不宜仅按店数判断所需模块。
本文提供采购核对方法，不给厂商排名、统一报价或经营效果保证。连锁组织中的菜单下发、跨店储值、中央厨房和离线营业，均应按自己的业务需求列为专项测试项。
业务流程：先试门店，再核对总部
- 负责人列经营关系：为每店登记经营主体、收款主体、菜单负责人、员工角色及订单入口，形成一份门店范围表。
- 店长与总部各用测试账号：在测试店A下单，由A接单；再让B账号查A订单并尝试改价、退款和导出。按事先约定记录应允许或应拒绝的动作，不用管理员演示替代员工验收。
- 商品负责人验证门店差异：用同一测试菜品设置门店不同价格、可售时段和售罄状态，查看是否影响其他店。若要求总部发布后门店局部调整，单独演示发布、覆盖和撤回规则。
- 财务按订单明细核对总部汇总：约定时间区间、门店范围、支付成功、退款和取消的计入规则，再把门店明细与总部汇总逐笔核对；记录数据更新周期，不把看板数字默认当实收。
- 业务负责人验证专项能力：对跨店会员、储值归属、加盟收款、供应链及断网恢复分别指定测试输入和预期结果；要求展示实际项目版本及设备，结果未确认时保留待确认。
- 采购方确认交付与退出：把模块、账号、设备、接口、费用项目、培训、故障责任、备份和数据导出写进附件；试点门店完成约定测试后，再决定推广范围。
连锁点餐采购验收清单
| 核对对象 | 现场操作 | 保存结果与判定边界 |
|---|---|---|
| 门店与总部 | A下单，B查A订单；总部看相同订单集合 | 各账号允许/拒绝结果，订单归属与统计截止时刻 |
| 菜单首次发布 | 在批准的测试范围发布菜品版本V1，A成功，B模拟失败 | 发布批次、目标店、成功失败店、时间与当前版本；失败店不算完成 |
| 门店局部改价 | A保留约定差异价，总部发布V2，再检查A/B | 哪些字段覆盖、哪些保留由规则先定；同时看历史已付订单金额 |
| 重试与回退 | 只对失败范围按批准方式处理，再尝试撤回或恢复 | 核菜品是否重复、价格/售罄是否恢复；有权限的负责人确认最终版本 |
| 员工调店与离职 | A店员工改到B或撤销账号，核旧会话与重新登录 | 查看、商品编辑、改价、退款、导出分别核验；即时生效与否单列 |
| 跨日部分退款 | 前日A订单次日退部分，按同集合汇总 | 原订单日、支付日、退款发生日及成功状态；归属与展示口径先约定 |
| 交付与专项 | 按需测跨店会员、支付、设备、供应链与断网恢复 | 未确认项目分别留待确认，不从点餐或子账号推定已支持 |
异常用例：菜单、人员和财务各自留记录
菜单测试先保存两店原菜品、价格和可售状态，注明总部模板及门店差异字段。发布V1时只在获准测试环境模拟B店失败，记录A、B各自的结果和生效时间。测试负责人核对失败店实际菜单后，再决定补发范围；不要把点击发布或显示已发送当成每店已生效。
继续用V2验证总部修改与门店局部调整的冲突：哪些字段覆盖、哪些字段保留，先写预期，再观察结果。需要回退时，明确是恢复整份菜单还是恢复单个字段，同时检查售罄状态、商品是否重复及已付款订单金额是否按约定保留。V1、V2只是本次测试版本标记，不是微订已上线的产品版本；发布和回退能力需项目演示确认。
员工调店测试保留变更前后的授权清单。A店员工改到B店后，在原浏览器会话和重新登录的会话中分别尝试查A订单、编辑商品、改价、退款及导出；离职撤权也按同样方式核对。记录授权变更时间、操作结果与提示，确认旧权限何时失效。这里列的是建议测试路径，不承诺系统采用某种会话实现或权限即时刷新。
财务用同一批测试订单、相同门店范围和截止时刻核对，记录支付成功、退款申请、处理中及已成功退款。前一营业日成交、次日部分退款时，原单日期与退款发生日期都保留；先约定按交易发生日还是原单归属日展示，再比较总部与门店明细。订单金额、优惠、渠道实收、退款和结算分列，不能拿不同截止时间的看板直接相减。
出现差异时，先按订单编号定位原支付和每次退款，再核门店筛选、营业日切点、退款状态、数据刷新时间及金额舍入。若只是刷新延迟，保存再次查询的时间和结果；无法解释的差异列为未通过项，写明负责人和复核依据。上述清单用于验收记录，不给出统一刷新时限、自动对账或资金清算承诺。
进一步验收：旧回执、在途导出与历史范围
总部先发布测试菜单V1，再发布V2；若V1的成功回执随后才到，核对界面显示与两店实际生效内容。记录目标店、发布批次、期望版本、实际版本、发送时间和确认时间。旧批次结果应如何展示由项目先约定，但不能仅因回执晚到就把实际新版误记为旧版。V1、V2是用例标签，不是产品版本或现成功能承诺。
员工撤权还要覆盖已经开始的操作。让A店员工在允许范围申请订单导出，文件尚未生成或尚未下载时撤销其权限，再分别试旧页面、文件列表和原下载地址。核对申请时、生成时和下载时的权限及文件范围。若文件此前已经下载到个人设备，应通过人员交接和数据管理处理；系统撤权不能保证收回已离线复制的文件。
总部报表另存查询门店集合与统计截止时刻。测试中先让报表覆盖A、B两店，再关闭B店或调整总部账号的可见范围，重新查看旧报表与新查询。约定历史财务数据的保留责任及访问权限，不能把停业店直接删出既有账期，或因组织变化使同一份历史报表悄然改变。
交付时为每项用例留下预期、实际、差异、负责人和复验结果。门店最终菜单、撤权后的下载结果以及同一账期的订单明细分别确认；一项通过不能替代其余项目。这里只给验收方法，未提供微订项目版本的上述用例通过记录。
公开依据与适用边界
微订官网子帐号管理说明介绍按店铺或运营岗位分配独立账号及权限。采购时可据此安排店铺员工授权演示，总部、区域与跨店隔离范围应另外核对。
店内点单公开说明列有代客下单、创建台号和进入云收银系统等操作，可作为门店营业路径的演示入口。桌码、打印设备、厨显与断网能力，按项目版本逐项确认。
产品服务说明列有独立管理后台、商家端、配送端和用户端。多个角色端提供了采购核对的对象；连锁总部报表、跨店会员和供应链是否符合需求，仍须查看具体模块与交付清单。
常见问题
门店数量能直接决定买哪套系统吗？
先看经营关系和所需动作。同样是多店，直营、加盟、自有线上点餐和中央厨房涉及不同的权限与资金责任。店数可用于列采购范围，不能替代功能验收。
总部能看全店数据就代表门店隔离通过吗？
分别验证查看与修改。总部汇总可见、店长仅见本店，以及员工是否能退款或改价，是不同测试项。用各角色账号实际操作并保存结果。
子账号功能能证明完整连锁权限吗？
微订公开子账号说明支持店铺授权管理。采购中还需验证总部、区域与各店的可见和操作范围，不能直接从店铺子账号推定所有组织层级。
跨店储值和优惠券能放在一个测试项吗？
分别测试。优惠券核销看适用店、金额和退款规则；储值还涉及余额归属、消费扣减、退款及收款责任，需要相应支付与合同约定。
没有中央厨房要先采购供应链吗？
按实际需要确认。若当前只需门店点餐与线上订单，可先把采购、调拨、原料成本等列为扩展评估项；存在现行流程时，再验证所需模块和接口。
跨日退款后总部看板与门店明细怎么对？
固定同一订单集合、门店范围和截止时刻，把原单日期、支付日期与退款发生日期分别记录。只把已成功退款计入约定扣减口径，处理中单列，再核营业日切点和刷新时间。结算与订单实收分开验收。
微订适配说明
优先匹配：希望经营自有公众号、小程序或App点餐入口，并需要核对门店订单、员工授权和商家配送协作的项目，可将微订纳入演示候选。
适配前提：提供门店经营关系、菜单、账号角色和收款责任，明确先上线的订单入口，再按需求逐项确认。
建议先确认：总部菜单下发、跨店会员储值、加盟资金、供应链、离线营业、接口、数据导出及实施服务。让供应商用项目版本完成清单，再确定开通与合同范围。
参考资料与更新时间
更新时间：2026-10-31。
