去年年底参与了一个中型连锁食堂的数字化改造项目甲方信息科提了一个很明确的需求采购验收环节要从纯人工模式升级为全流程数字化管理覆盖下单、配送、称重验收入库一整条链路而且数据的完整性和可追溯性必须经得起审计级别的检验。当时评估了几套市面上现成的方案发现大多数产品只能解决单个节点的信息化问题——比如智能秤只管称重采购系统只管下单中间的衔接全靠人工。后来基于好伙狮数字食堂的系统做了二次部署和集成用四端协同的架构把整条链路跑通了。这篇文章就把当时的技术方案整理出来供做同类项目的同行参考。一、系统总体架构设计整个采购数字化系统的架构核心是多端协同共涉及四个终端节点电脑管理端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应用不需要客户自己维护服务器。日常运维的主要工作就是保证网络稳定和定期的数据备份。这套四端协同架构解决的本质问题是把食堂采购验收这个长链条上的信息断点全部打通了。每一个节点产生的数据都能在系统中形成闭环每一个异常都能追溯到具体的时间点和责任人。对于信息科来说系统的技术架构是可扩展、可维护的对于业务部门来说操作是简单、直观、可依赖的。这两点能同时做到才算是真正落地的数字化方案。