每天关店前,后厨核对当天用掉的五花肉、青椒、豆瓣酱,再手动改Excel里库存数——漏改一次,月底盘点就差20斤五花肉;多改一格,采购单又多订两箱啤酒。这不是个别现象,中国烹饪协会《2023中小餐饮运营痛点报告》指出,超67%的10人以下门店仍依赖人工录入进销存,平均每周因库存误录导致食材浪费或临时缺货达3.2次。问题不在人不用心,而在流程没闭环:采购单、入库单、出库单、报损单四张表各自为政,改A表忘了同步B表,数据越积越乱。今天就聊一个实打实能落地的解法:一套适配小餐馆的Excel进销存模板(自动计算),不换系统、不学新软件,只靠Excel原生功能+简单逻辑,让库存数字自己跑起来。
💰 流程拆解:从4张纸到1个自动联动的Excel
很多老板以为进销存就是记账,其实本质是‘动作→数据→决策’的闭环。比如:厨师长领走5斤土豆(动作),系统该立刻减库存、生成出库记录、触发补货提醒(数据),店长据此判断是否要明天下单(决策)。传统方式把这三步拆成不同人、不同时间、不同表格,断点太多。我们用Excel搭建的轻量级闭环,核心是把采购、入库、销售、报损四个动作对应到同一工作簿的四个独立Sheet页,通过SUMIFS、VLOOKUP和数据验证规则实现跨表自动汇总。不需要编程,但得理清谁在什么节点填哪张表——这是后续不出错的前提。
谁填?什么时候填?填在哪一页?
关键不是功能多炫,而是操作人清楚自己的责任边界。采购员只管‘采购单’页,填完就不用动其他表;收货员在‘入库单’页勾选已收货,系统自动累加库存;服务员在点单时,后厨按订单在‘销售单’页登记实际消耗(不是按菜单预估);报损由店长每日巡检后填写‘报损单’页。所有动作都留痕,所有变动都可追溯。亲测有效的一点是:把‘销售单’页打印贴在备餐台,厨师做完一道菜就划掉一行,比手机打字更不容易漏。
- 采购员在【采购单】页填写商品名称、计划采购量、供应商、预计到货日(操作节点:每周二上午;操作主体:采购员);
- 收货员收到货后,在【入库单】页选择对应采购单号,输入实收数量并勾选‘已验收’(操作节点:货物送达当日下午;操作主体:仓管/收银员);
- 后厨按每单实际耗材,在【销售单】页填写菜品编号、对应原料及用量(操作节点:每单出餐后2分钟内;操作主体:切配岗);
- 店长每日闭店前,在【报损单】页登记当日过期、破损、试菜损耗数量(操作节点:21:00-21:30;操作主体:店长);
- 系统自动在【库存总表】页刷新当前可用库存=期初+入库-销售-报损(操作节点:任意Sheet保存后实时更新;操作主体:Excel公式);
🔧 痛点解决方案:3类易错场景怎么堵住
手动更新最常翻车的不是不会算,而是‘不知道该不该算’。比如:试菜用的半斤牛肉,算不算销售?昨天剩的3个蛋挞,今天打包送客,算不算报损?模板不解决哲学问题,但通过结构化字段设计,把模糊地带变明确选项。我们在【销售单】页加了‘用途类型’下拉菜单(堂食/外卖/试菜/员工餐),在【报损单】页区分‘临期预警’‘物理破损’‘口味异常’三类原因。这样月底分析损耗率时,就能看出是管理问题(临期预警占比高)还是操作问题(物理破损集中出现在某时段)。
场景一:同一种原料多个规格混用
比如‘酱油’,采购用5L桶装,厨房取用用小瓶分装,销售单上却写‘酱油1勺’——单位不统一,库存永远对不上。我们的方案是在【基础资料】页建原料主数据表,强制规定:所有采购、入库、销售、报损必须使用标准计量单位(如‘酱油’统一为‘毫升’),并在各单据页设置数据验证,输入非标准单位会弹出提示。同时提供换算系数列(1勺=15ml),由切配岗在首次使用时填写并锁定,避免每次重复换算。
场景二:临时调拨没走流程
A店急用2kg冻虾仁,从B店借调,双方口头说好,结果B店忘记在系统里做调出,A店也没做调入,月底两边库存都虚高。模板新增【调拨单】页,要求调出方填写调出数量并签名,调入方确认收货后勾选‘已接收’,系统自动双向更新库存。关键是——没有‘已接收’标记,调出方的库存不会减少。这倒逼流程必须走完,而不是凭信任打白条。
场景三:促销活动导致用量突变
周末‘小龙虾买一送一’,后厨多用了80斤冰鲜虾,但销售单仍按日常单量填报,库存骤降却无预警。我们在【销售单】页增加‘活动标识’字段,勾选后系统自动将该单原料用量×2计入库存消耗,并在【库存总表】页标红显示‘活动影响库存波动’。店长晨会一看标红项,就知道哪些原料要优先补货,不用等盘点才发现缺货。
📊 实操案例:杭州‘巷子味’小炒店落地记
‘巷子味’是杭州湖滨银泰旁一家12张桌的小炒店,主营杭帮家常菜,日均客流60-80人,员工7人(含2名兼职)。此前用纸质登记+Excel手工汇总,每月盘点误差率约12%,主要集中在调味料和冻品。2024年3月引入该模板,由店长用2小时完成初始化(录入32种常用原料基础信息、设置数据验证规则),之后全员按上述5步操作。4月起,盘点误差稳定在2.3%以内(中国饭店协会《2024餐饮供应链管理白皮书》将中小餐饮合理误差阈值定为±3%),且报损分类数据帮助他们发现:76%的临期损耗发生在周三至周五的酱料缸,遂调整酱料制作频次为隔日小批量,调味料月均浪费下降明显。整个过程未增加人力,也未采购新工具。
| 对比维度 | 传统方式 | 优化后Excel模板 |
|---|---|---|
| 库存更新时效 | 每日闭店后集中录入,延迟6-8小时 | 动作发生即更新,实时可见 |
| 错误溯源难度 | 需翻查4本手写本+3个Excel文件,平均耗时42分钟/次 | 点击库存数可追溯至原始单据行,平均3秒 |
| 损耗归因能力 | 仅知‘本月酱油少了12瓶’,不知原因 | 可筛选查看‘临期预警’‘物理破损’等分类占比 |
| 补货决策依据 | 凭经验估摸‘差不多该买了’ | 库存低于安全线时,自动标黄并关联采购单模板 |
📈 数据可视化:一张图看懂库存健康度
光有数据不够,得让人一眼看出问题。我们在模板中嵌入三个HTML图表(兼容PC端直接打开),全部用原生HTML+CSS绘制,无需插件:
① 折线图:近30天‘冻虾仁’库存趋势(X轴日期,Y轴公斤数),标出采购到货日(▲)和销售高峰日(●);
② 条形图:本月各品类损耗量对比(调味料/冻品/蔬菜/干货),直观识别损耗主力;
③ 饼图:当前库存中‘临期(7天内)’‘正常’‘富余(超安全库存2倍)’三类占比,辅助判断是否需要促销清仓。
💡 搭贝低代码平台的自然延伸
当‘巷子味’客流增长到日均120人,他们开始尝试把Excel模板里的【销售单】页对接搭贝低代码平台(https://www.dabeicloud.com),用扫码枪扫桌码自动生成销售单行,后厨平板点选即可提交。这不是为了炫技,而是解决‘高峰期手忙脚乱漏登’的老问题。整个过程只用了搭贝的表单组件和数据联动功能,没写一行代码,店长自己花了半天配置完成。这里想强调的是:Excel模板和低代码不是替代关系,而是递进关系——先用Excel把流程跑通、把数据理清,再用低代码放大效率。踩过的坑是:一开始就上平台,反而因为字段定义不清,导致数据更混乱。
两个关键衔接点
一是数据格式对齐:搭贝表单导出的CSV必须与Excel模板的【销售单】页字段顺序、命名完全一致(如‘菜品编号’不能写成‘菜ID’),否则公式无法识别;二是权限隔离:搭贝端只开放‘提交销售单’权限给后厨,库存查询和报表分析仍保留在Excel端,避免一线员工误操作核心数据。这种分工让技术真正服务于人,而不是让人适应技术。
⚠️ 注意事项:这些细节决定成败
再好的模板,执行走样也会失效。我们梳理出几个餐饮老板最容易忽略的细节,全是实操中反复验证过的:
- 风险点:多人共用同一Excel文件,修改冲突导致数据丢失;规避方法:改用OneDrive或企业微信文档共享,开启‘自动保存’和‘版本历史’,每次编辑前先刷新最新版;
- 风险点:新员工不理解‘用途类型’含义,把试菜全填成‘堂食’;规避方法:在【销售单】页首行插入批注,用大白话举例‘试菜=厨师长尝味用的,员工餐=咱自己吃的,别混淆’;
- 风险点:安全库存值设太高,长期不触发补货提醒;规避方法:参考过去3个月日均用量×3天,再加10%缓冲,而非拍脑袋定‘50kg’;
- 风险点:模板升级后未同步培训,老员工仍用旧版;规避方法:每次更新在【首页】加红色水印‘V2.3-20240415’,并邮件通知全体成员。
📋 表格工具包:3个即用型行业表格
除了主模板,我们还配套了3个高频使用的辅助表格,全部按餐饮真实场景设计:
| 表格名称 | 适用场景 | 核心字段 | 使用频率 |
|---|---|---|---|
| 周采购计划拆解表 | 每周二制定下周采购清单 | 菜品名称、预估销量、单份用量、周需总量、安全库存、建议采购量 | 每周1次 |
| 临期原料预警跟踪表 | 每日检查即将过期原料 | 原料名称、生产日期、保质期、到期日、当前库存、建议处理方式(促销/试菜/报损) | 每日1次 |
| 供应商履约评估表 | 每月复盘供应商表现 | 供应商名称、送货准时率、货品合格率、价格稳定性、服务响应速度、综合评分 | 每月1次 |
比如‘周采购计划拆解表’,它把‘毛血旺’这道菜拆解成鸭血、毛肚、黄喉等12种原料,再乘以预估销量,自动算出每种原料下周该买多少。这样采购员对着表去市场,不会漏掉黄喉这种小众但关键的料。建议收藏,直接复制到自己Excel里就能用。
最后说句实在话:没有万能模板,只有适配你家店的模板。有的店用得顺,是因为把‘销售单’页打印出来贴灶台边;有的店效果好,是因为店长坚持每天花5分钟看饼图里的‘临期占比’。真正起作用的,从来不是那个Excel文件,而是你愿意每天认真填、认真看、认真改的那个动作。库存数据手动更新,易出错的问题,本质上是个习惯问题,不是技术问题。把动作固化下来,数据自然就准了。




