去年年底参与了一个中型连锁食堂的数字化改造项目，甲方信息科提了一个很明确的需求：采购验收环节要从纯人工模式升级为全流程数字化管理，覆盖下单、配送、称重验收入库一整条链路，而且数据的完整性和可追溯性必须经得起审计级别的检验。当时评估了几套市面上现成的方案，发现大多数产品只能解决单个节点的信息化问题——比如智能秤只管称重，采购系统只管下单，中间的衔接全靠人工。后来基于好伙狮数字食堂的系统做了二次部署和集成，用四端协同的架构把整条链路跑通了。这篇文章就把当时的技术方案整理出来，供做同类项目的同行参考。
一、系统总体架构设计
整个采购数字化系统的架构核心是多端协同，共涉及四个终端节点：电脑管理端（Web端后台管理系统）、智能秤端（嵌入式终端设备）、手持机端（移动PDA应用）、采购方/供应商端（移动APP）。这四个端共享一个中心化的数据底座，通过RESTful API和WebSocket长连接实现数据同步，保证各端之间的状态一致性和实时性。
从技术分层来看，系统分为三层：数据接入层负责各终端的数据采集和指令下发，业务逻辑层处理采购流程的状态机流转和数据校验，数据持久层采用MySQL作为主库、Redis做热点数据缓存。各终端之间的通信走的是统一的消息总线，采购单创建、订单确认、称重入库等关键事件都会在总线上广播，订阅了对应事件的终端自动收到推送。
二、智能秤端：称重拍照溯源的设备层实现
智能秤端的硬件基础是一台工业级电子秤，最大量程150kg，精度等级达到贸易结算级别。秤体通过RS-232串口与一个嵌入式Android工控屏相连，工控屏上运行的是定制化的称重验收应用。这个应用的主要职责就是把称重数据、摄像头采集的影像、操作人员身份信息整合成一条完整的验收记录，然后通过局域网或者4G网络推送到服务端。
称重数据采集这块，串口通信的协议是标准的MODBUS-RTU，波特率9600，数据帧包含了重量值、称重模式和校验位。工控屏上的应用封装了一个SerialPortService守护线程，持续监听串口数据流，当重量稳定在误差范围内超过2秒后，自动锁定读数并触发拍照。这个"稳定判断"的逻辑写得比较关键——食堂验收现场人来人往，经常有人碰到秤台，如果没有稳定判断，数据抖动会让验收人员反复确认，体验很差。
拍照部分用的是工控屏自带的USB摄像头，分辨率1080P。应用调用Android Camera2 API进行拍照，拍完后在本地做一次JPEG压缩（质量参数设为百分之八十五，平衡清晰度和传输效率），然后使用图片水印算法在照片底部叠加一层信息条，包括食材名称、称重结果、日期时间、操作人员姓名。这个水印是在设备端完成的，原始照片不经过服务端处理，从技术上保证了影像资料的原始性和不可篡改性——服务端拿到的是已经加了水印的图片，如果有人试图替换图片，水印信息和数据库里的称重记录对不上，立马就能发现。
数据上传这块，设计了一个本地缓存队列。如果网络异常导致上传失败，验收记录会先写入本地SQLite，网络恢复后按先进先出的顺序补推。这个设计在一个地下室食堂场景下验证过——地下室没有4G信号，验收人员照样可以正常称重入库，等设备搬到有信号的位置，数据自动同步到云端。
三、手持机端：轻量化出入库的移动解决方案
智能秤解决了大宗食材的验收，但食堂仓库里还有品类庞大的小包装物料——调味料、干货、粮油、一次性餐具等，这些物料需要更灵活的操作方式。手持机端本质上是一个基于Android的PDA应用，集成了条码扫描、NFC读取和拍照功能，运行的是系统移动端SDK。
手持端的核心业务流程是扫码出入库。入库时，操作人员用PDA扫描商品包装上的条码，应用的条码解析模块（基于ZXing库做二次封装）解析出商品SKU编码，然后调用系统API查询对应的采购单详情，自动匹配品项和数量。确认无误后点击入库按钮，系统生成入库单并更新库存。出库流程类似，扫描货物条码，选择出库仓库和出库档口，扣减库存。
手持端也支持异常拍照存证。如果拆箱发现货物有破损、过期或者数量不对，操作人员可以直接拍照上传，照片会和该批次的入库记录绑定。后端会创建一个异常工单，通知对应的采购人员和供应商处理。这个功能在后来的运营数据中表现出了实用价值——启用后的一个月内，异常情况从原来的口头沟通、事后扯皮，变成了系统流转、有据可查。
离线模式也是手持端需要重点考虑的。食堂仓库区域网络覆盖不稳定，手持应用使用了本地Room数据库做离线缓存，所有出入库操作在离线状态下正常完成，网络恢复后通过WorkManager的后台任务批量同步到服务端。冲突处理策略采用"最后写入者获胜"，结合服务端时间戳做乐观锁校验。
四、采购助手与供应商助手：采购链两端的信息互通
采购助手是部署在采购方手机上的移动应用，功能包括创建采购单、查看历史采购记录、管理供应商名录。采购单的创建流程设计得很轻量，支持基于历史模板的快速复制和智能推荐——系统会根据过去一段时间的日均用量和当前库存水位，给出建议采购量。这个推荐算法不复杂，本质上是滑动窗口平均加上安全库存系数，但准确率在实际使用中达到相当可观的水平，采购员基本不需要手动调整。
供应商助手则是面向供应商端的应用，核心功能是接单确认和订单标签打印。供应商收到采购单推送后可以一键确认接单，确认后的采购单状态会通过消息总线同步到采购方和管理端。订单标签打印功能用的是移动蓝牙打印协议，通过连接便携式标签打印机输出带条码的配送标签。标签上的条码编码规则是"采购单号+商品SKU+配送日期"的组合码，保证每个标签在全系统维度上的唯一性。
五、数据流转与状态机设计
整个系统最核心的设计是采购单的状态机。一张采购单会经历"草稿→已发布→已确认→配送中→已到货→验收中→已入库"七个状态，每个状态的迁移都有前置条件校验。比如从"配送中"到"已到货"，需要供应商在供应商助手上确认送达；从"验收中"到"已入库"，需要智能秤端完成称重拍照并且手持端完成物料核对。
状态机的实现方式是事件驱动架构。每个状态迁移都会触发一个领域事件，事件会发布到消息队列，对应的消费者进行后续处理。比如"已入库"事件会触发库存更新、采购报表刷新、财务对账数据生成等多个后续动作。这种设计的好处是解耦——后续如果要加新的业务流程，只需要新增一个事件消费者，不需要改动采购单的核心逻辑。
数据同步方面，电脑管理端采用的是WebSocket长连接，保证后台能够实时看到各端的操作动态。智能秤端因为硬件资源有限，采用的是HTTP轮询加增量更新的方式，轮询间隔设置为5秒。手持端因为操作场景对实时性要求没那么高，走的是定时批量同步，配合前台操作的即时上传。
六、实际部署与效果数据
方案落地后运行了半年多，拿实际运营数据来看几个关键指标的变化。称重验收环节，启用拍照溯源之后验收争议下降了约八成以上，平均单次验收时间从原来的四分多钟缩减到一分钟以内。手持端上线后小包装物料的出入库记录完整率从之前的不足六成提升到了接近百分之百。采购流程方面，从下单到供应商确认接单的平均时间从半小时以上压缩到了五分钟以内。
从技术运维的角度，四个端的部署都比较轻量化。智能秤端是标准化的硬件设备，即插即用；手持机和移动端应用通过MDM做统一的分发和权限管理；管理端是SaaS化的Web应用，不需要客户自己维护服务器。日常运维的主要工作就是保证网络稳定和定期的数据备份。
这套四端协同架构解决的本质问题，是把食堂采购验收这个长链条上的信息断点全部打通了。每一个节点产生的数据都能在系统中形成闭环，每一个异常都能追溯到具体的时间点和责任人。对于信息科来说，系统的技术架构是可扩展、可维护的；对于业务部门来说，操作是简单、直观、可依赖的。这两点能同时做到，才算是真正落地的数字化方案。
