联网设备断网时，门店是否还能营业要按任务判定

断网回退的目标不是证明“门店照常营业”，而是证明每项任务在失去云端、互联网或局域网某个节点后，仍有可识别的状态、受控的替代路径和明确的停止条件。订单能写在纸上，不代表付款、食品安全记录、设备保护功能和库存都能继续；其中任何关键能力没有证据，就应缩小服务范围或停止相关任务。

Hatco介绍餐饮设备软件服务时指出，此类服务可能包含云端托管、更新、数据分析、界面和第三方网络依赖，具体设备还可能同时存在本地软件。[1]这只能说明“联网”不是一个单一开关，不能证明某家门店、某套软件或某台设备具有离线能力。演练前仍须取得本项目的网络图、版本资料、合同服务边界和厂商书面说明。

先把“断网”拆成故障点

门店先列关键任务，再画每项任务实际经过的节点：终端、接入点、交换或路由设备、本地服务、互联网、云端身份服务、支付通道、第三方配送平台以及设备控制器。故障情景至少区分互联网中断、局域网中断、云服务不可用、账号认证失败和单一终端失效。不同情景可能呈现相同的“转圈”，回退动作却不同。

每个节点记录可见信号、确认人、确认方法和禁止动作。员工可以根据既定信号进入人工接单，但不得因页面无响应就重启生产设备、清空本地数据或反复提交付款。无法判断故障范围时，由值班负责人先暂停可能产生重复、丢失或安全后果的动作，再由信息技术或服务方确认。

用一张表决定继续、限量还是停止

下表是通用判定框架，不是任何特定系统的能力声明。门店应将“离线证据”替换为当前版本的实测结果和批准文件。

关键任务	离线时必须看见的证据	回退方式	限制或停止条件
设备安全与关键控制	保护功能是否本地执行、报警是否仍可见、厂商允许的离线状态	只按已批准的本地程序操作并人工记时	保护能力不明、报警不可见或状态异常，停止该设备任务
食品安全监测与记录	关键读数能否本地取得，人工表单和复核人是否就位	按批准频次人工读取、双人复核并留存	读数不可取得、记录中断或偏差无法处置，停止相关食品任务
订单接收与制作	唯一订单号、版本、接收与完成状态可连续追踪	使用预编号票据，限制菜单和渠道	身份可能重复、特殊要求无法传递或厨房负荷失控，限量或停接
付款	支付方确认的离线规则、额度、凭证和失败处置	仅使用已批准方式，把未知状态标为待核	授权状态不明且无合规替代方式，停止该支付方式，不把“稍后再扣”当默认
库存与报损	人工领用、报损表可与订单关联	先记事件，恢复后再入系统	无法保持批次或品项追溯时，限制相关品项
顾客与内部沟通	可用渠道、统一话术、升级联系人	告知可售范围与延迟，不承诺未知结果	无法联系关键责任人或现场秩序不可控时，缩小或暂停服务

这张表的核心是将“不确定”转成限制条件。即使接单和制作可以人工完成，只要支付不可确认，也只能换成获准的其他方式；只要关键温度或时间记录无法取得，就不能以顾客已经下单为由继续相应食品任务。

人工票据只留必要字段

纸面或离线表单使用预编号，不沿用可能与系统自动生成冲突的简单流水号。字段至少包括演练或真实事件标识、唯一票号、创建时点、渠道、菜品版本、特殊要求、制作状态、交付状态、付款状态、库存或报损关联号和经手人。付款状态只写“已由指定方式确认”“待核”或“未收”等受控值，不记录完整卡号等无必要个人资料。

票据在接单、厨房和交付之间的每次移交都留下时点和责任人。修改不涂掉原记录，而是划线、签名并写新值。断网前已进入系统但尚未完成的订单，先抄录原系统身份；无法确认是否已经提交的订单，不创建看似全新的身份来掩盖未知。

十张模拟单只是桌面用例，不是通过门槛

可用十张模拟单演示交界状态，但“十张无错”不能证明可以营业。这组数量只是便于桌面讨论的假设，应覆盖不同状态，而非十张完全相同的正常单。例如：断网前已付款未制作、已制作未交付、已交付但系统未写回、付款结果未知、顾客取消、厨房收到重复票、特殊要求修改、部分品项缺货、库存已扣但订单未完成，以及恢复时云端出现同身份记录。

演练者逐张说明哪个记录是主身份、哪个状态仍未知、谁有权更正、哪些动作不得自动重放。故意加入重复号、缺少时点和字迹不清等异常，验证人员能否把它们隔离。桌面演练验证的是规则理解，不接入真实收银、不产生真实扣款、不触发真实生产，也不能替代受控技术测试。

受控断网测试必须与真实业务隔离

测试前由系统负责人、运营负责人和涉及的服务方批准范围，确认备份、观察点、恢复条件、现场安全措施和中止权限。测试环境应与真实订单和真实付款隔离；若只能在生产环境观察，应采用服务方认可的只读检查或另行设计窗口，不能因为“非高峰”就直接拔线。低客流并不会消除数据损坏、设备异常或安全风险。

一次测试只改变一个已定义节点，并记录断开前后时间、各终端显示、报警、任务状态、本地数据位置和网络恢复事件。操作人员只执行批准步骤。出现设备异常、关键读数消失、真实业务被影响、无法辨认数据归属或恢复路径与方案不一致时，立即中止；随后保持现场和日志，不自行复位来追求一次“成功”。

测试通过也只适用于记录中的设备、软件版本、网络拓扑、账号角色和场景。更新软件、改变支付服务、增加配送平台或更换网络设备后，都要判断原证据是否仍有效。本文不把G32DAG、ZL-2K或PC-1200x600-FC视为联网设备，也不对这些型号作离线能力判断。

恢复后分三本账核对

网络恢复不等于可以立刻退出人工模式。先冻结自动重发和批量导入，由指定人员分别建立订单账、付款账和库存账。订单账核对系统记录、人工票据、厨房完成与实际交付；付款账由获授权人员核对授权、结算和退款状态；库存账核对领用、报损和实际余量。三本账通过同一唯一订单身份关联，但未知状态不得互相推定。

逐笔结果可标为一致、系统缺记录、人工缺记录、重复、金额或品项不一致、状态未知。只在证据充分且权限明确时更正；付款是否补收或退款按支付方和组织规则处理，不由厨房记录推断。所有差异保留原始记录、处理人、依据、时点和关闭结果，不能为了让总数相等而删除。

退出人工模式至少满足：故障原因和恢复范围已确认；新订单身份不会与人工票冲突；三个账本的未知项已隔离且有责任人；关键设备和安全记录处于可接受状态；系统负责人批准恢复自动流程。尚未解决的单据可以继续调查，但必须与新业务分开，避免旧差异再次进入生产队列。

演练结论写成能力边界

最终记录不写笼统的“断网可营业”，而写成条件句：在某版本、某故障点和某时长内，哪些任务经何种证据验证可以继续，允许的菜单、渠道、支付方式和单量限制是什么；哪些任务必须停止；超过什么条件升级为关停。每个结论附测试日志、见证人、差异清单和复审日期。

门店真正需要的不是一张乐观证明，而是一套让值班人员在未知出现时也能收缩风险的规则。只要关键安全能力、记录连续性或付款状态不能确认，“继续营业”的正确含义就应改为继续有限且已验证的任务，而不是维持原有服务表象。

参考资料

• Hatco: How To Educate Your Customers on SaaS for Foodservice Equipment