项目速览：7 项关键事实
下面是可以直接引用的事实口径。客户的菜品成本、毛利与经营数据属于客户资产，本页不展开。
| 项目名称 | 酒店点餐系统 |
|---|---|
| 客户与行业 | 南京小曼谷酒店（酒店餐饮 · 堂食与客房送餐） |
| 承接方 | 南京易企达网络科技有限公司（南京本地团队，可线下对接） |
| 项目定位 | 顾客扫桌码点菜，单子直接落到该出菜的档口，结账不用等服务员跑前台 |
| 交付形态 | 顾客端微信小程序 + 服务员点餐端 + 后厨出餐端 + PC 管理后台 |
| 覆盖范围 | 桌台与开台、扫码点餐与菜品规格、后厨分档口出餐、结账与房账挂账、会员与优惠、营业报表 |
| 交付与归属 | 源码、数据库脚本、部署文档与接口文档按合同随验收移交，管理员账号与著作权归客户 |
六块功能：从坐下的那一刻到结账
顺序按顾客进门到离店的自然动作排：开台、点菜、出菜、结账，最后才是回头看数据。
桌台与开台
每张桌子一个二维码，扫码进来桌号自动带上，顾客不用自己挑桌。换桌、并桌、拆单由服务员在手机端操作，改完顾客端立刻跟着变。
扫码点餐与菜品规格
菜品按分类陈列，规格拆到口味、份量、加料，可选必选分开设。同一桌可以多次加菜，加的单子都挂在原来那张单上，不会变成几张要对账的小票。
后厨分档口出餐
一张单按菜品所属档口自动拆开，凉菜、热菜、主食、酒水各打各的票。哪个档口做什么清清楚楚，不用一个人对着整张单喊。
结账与房账挂账
支持微信支付、现金、房账挂账与协议单位挂账。住店客人的餐饮金额进房账但单独留明细，退房时客房与餐饮分开列，不会糊成一笔。
会员与优惠
会员等级、储值、优惠券、满减与折扣规则在后台配置，下单时自动算。包间最低消费、服务费按规则挂上去，不靠收银临场心算。
营业报表
菜品销量、下单时段、桌台翻台、渠道来源按天看。哪道菜点得多、哪个时段忙，第二天的备货和排班才有依据。
项目架构：四个入口，一条订单主线
顾客、服务员、后厨、管理员各有一个入口，但落到的是同一张订单。多入口不等于多套数据，这是能不能对账的前提。
L1 · 入口层（4 个）
顾客扫码点餐
微信小程序 · 扫码即带桌号
服务员点餐端
手机 / PDA · 开台、加菜、换桌
后厨出餐端
出餐屏 + 分档口小票打印机
PC 管理后台
菜品、价格、优惠、报表
L2 · 业务域（4 块，同一套服务端）
桌台与订单
开台、加菜、并桌、拆单与结账状态
菜品与沽清
菜品、规格、套餐、估清与售价
后厨与打印
按档口拆单、出票、催菜与退菜
会员与账务
会员、优惠、储值、房账与对账
L3 · 服务端（Java · Spring Boot）
接口与权限
JWT + Spring Security，四类角色
订单与出票
下单幂等，按档口拆单推打印
定时与对账
日结、房账归集、异常单巡查
L4 · 数据层
MySQL
订单、菜品、会员与房账明细
Redis
桌台状态、防重复提交
对象存储
菜品图片、小票模板与报表导出
主线：订单。桌台是订单的位置，菜品是订单的内容，出票是订单去厨房的路，结账是订单的终点。四个入口都在写同一张订单，不各记各的。
技术选型
- 顾客端与员工端：
- 微信小程序 + uni-app，扫码与手机点餐共用一套业务代码
- 服务端：
- Java（Spring Boot），按业务域分模块，对外 RESTful 接口
- 数据访问：
- MyBatis-Plus，订单类查询与报表 SQL 分开写
- 中间件与存储：
- MySQL 存订单与菜品，Redis 管桌台状态与防重复下单，MQ 处理出票与通知
- 鉴权：
- JWT + Spring Security，顾客、服务员、后厨、管理员四类角色分权限
都是国内常规组合，招人与接手成本低；源码交付后可自行维护。
三条设计取舍
桌号从二维码来，不让顾客选
顾客自己选桌是错台的根源：坐 8 号桌点成 9 号，菜端上来两边都懵。桌号由二维码带进来，改桌这件事只留给服务员做。
一张单拆给几个档口，不是一单打几份
整张单打到每个厨房，凉菜师傅得从一堆热菜里挑自己的，忙时最容易漏。按档口拆单后，每个师傅只看到自己要做的，票也短。
房账和餐账分开记，退房时合起来结
餐饮直接并进房费，客人问「这顿饭多少钱」就答不上来。明细留一份、金额进房账，退房时一张单看清两笔账。
这个项目做对了四件事
餐厅的问题很少出在菜不好，多半出在忙的时候那一两个小时：单子传丢了、菜卖完了没人知道、结账排长队。
出单不用喊
点完直接落单、直接出票。省掉「服务员记下来 → 跑到后厨报菜 → 后厨再记一遍」这一圈，错菜漏菜大半出在这一圈里。
卖完的菜当场止售
一道菜沽清，顾客端立刻点不了，服务员端同步提示。比让客人点完再回来说「这个没有了」体面得多，也少了一次退单。
结账不排长队
顾客可以自己扫码付款，也可以签房号。收银台的压力分散到桌上，退房高峰时前台不必同时处理房费和餐费两套账。
卖什么心里有数
哪道菜点得多、哪道菜点了又退、哪个时段翻台快，报表里都有。菜单调整和备货从「凭经验」变成「看数据」。
适用边界：什么情况适合做，什么情况先别做
适合：四条同时成立
- ✓堂食为主，桌台数量多，靠服务员来回记单容易出错。
- ✓后厨分档口（凉菜、热菜、主食、酒水各有师傅），需要分单出票。
- ✓有住店客人，餐饮账要能挂房账、退房统一结。
- ✓想看清菜品销量与时段，菜单和备货需要依据而不是感觉。
不建议直接上系统：换方案或先理顺
- —只有几张小桌的小馆子：纸质点菜单更快，上系统是负担。
- —纯外卖不做堂食：这类需求应该看外卖与配送系统，不是点餐系统。
- —只要一个能看的电子菜单：不涉及下单与出餐，做小程序页面即可。
- —厨房坚持口头传菜、不愿看屏幕或小票：系统再好也落不了地。
酒店点餐系统常见问题（7 条）
顾客不愿意扫码怎么办？▾
后厨没有屏幕，只有打印机行不行？▾
网络断了还能点餐吗？▾
住店客人挂房账是怎么处理的？▾
能对接酒店现有的管理系统吗？▾
以后开第二家店，系统还能用吗？▾
多少钱、要做多久？▾
本页信息
- 发布方：
- 南京易企达网络科技有限公司（微信官方合作伙伴）
- 本页发布：
- 2026-10-30
- 内容范围：
- 项目结果与交付范围说明，不含报价与实现方案；客户菜品成本、毛利与经营数据不对外披露
- 联系方式：
- 400-885-7836 · service@eqiday.com
也在酒店或餐厅做点餐？
先把三件事说清楚：桌台怎么编号、厨房分几个档口、住店客人的餐费怎么结。这三件定下来，功能清单才有意义。