南京易企达为南京小曼谷酒店交付点餐系统：顾客扫桌码点餐、加菜不换单，后厨按档口分单出票，服务员手机开台改桌，住店客人餐饮账挂到房账，退房一并结清。
只列可核查的交付事实：项目定位、交付形态、覆盖范围、技术选型与归属口径。
每一项都是客户实际在用的功能，不是模块清单。
每张桌子一个二维码，扫码进来桌号自动带上，顾客不用自己挑桌。换桌、并桌、拆单由服务员在手机端操作，改完顾客端立刻跟着变。
菜品按分类陈列，规格拆到口味、份量、加料，可选必选分开设。同一桌可以多次加菜，加的单子都挂在原来那张单上，不会变成几张要对账的小票。
一张单按菜品所属档口自动拆开，凉菜、热菜、主食、酒水各打各的票。哪个档口做什么清清楚楚，不用一个人对着整张单喊。
支持微信支付、现金、房账挂账与协议单位挂账。住店客人的餐饮金额进房账但单独留明细，退房时客房与餐饮分开列，不会糊成一笔。
会员等级、储值、优惠券、满减与折扣规则在后台配置，下单时自动算。包间最低消费、服务费按规则挂上去，不靠收银临场心算。
菜品销量、下单时段、桌台翻台、渠道来源按天看。哪道菜点得多、哪个时段忙，第二天的备货和排班才有依据。
先看入口与业务域，再看技术选型；只写结构与取舍，不写客户内部数据。
不是功能罗列，是当初的判断。
点完直接落单、直接出票。省掉「服务员记下来 → 跑到后厨报菜 → 后厨再记一遍」这一圈，错菜漏菜大半出在这一圈里。
一道菜沽清，顾客端立刻点不了，服务员端同步提示。比让客人点完再回来说「这个没有了」体面得多，也少了一次退单。
顾客可以自己扫码付款，也可以签房号。收银台的压力分散到桌上，退房高峰时前台不必同时处理房费和餐费两套账。
哪道菜点得多、哪道菜点了又退、哪个时段翻台快，报表里都有。菜单调整和备货从「凭经验」变成「看数据」。
同样的需求，不同做法代价不同；这里写清楚为什么这样选。
顾客自己选桌是错台的根源：坐 8 号桌点成 9 号，菜端上来两边都懵。桌号由二维码带进来，改桌这件事只留给服务员做。
整张单打到每个厨房，凉菜师傅得从一堆热菜里挑自己的，忙时最容易漏。按档口拆单后，每个师傅只看到自己要做的，票也短。
餐饮直接并进房费，客人问「这顿饭多少钱」就答不上来。明细留一份、金额进房账，退房时一张单看清两笔账。
判断标准写在这里，避免双方预期错位。
问答与页面结构化数据同源，答案口径两站一致。
系统同时支持服务员代客下单：服务员用手机端开台点菜，跟扫码点出来的单进同一个池子。纸质菜单可以照旧发，只是下单动作换到了手机上。不想强制扫码的店，也可以只在包间和宴会桌启用扫码。
可以。出餐端支持出餐屏与小票打印机两种形态，按档口配置：热菜走一台打印机、凉菜走另一台，酒水可以直接不进后厨，吧台自己出。
顾客扫码点餐依赖网络，断网时下单会失败并明确提示；服务员端在同一个局域网内可以继续开台下单，恢复后自动同步。建议后厨打印机走有线，避免 Wi-Fi 抖动导致漏票。
结账时选择房账挂账，输入房号与客人姓名核对，餐饮金额记入该房间的账务，同时保留这张餐饮单的明细。退房时客房费与餐饮费分项列出，可以合并结也可以分开结。
能对接的前提是对方开放接口，常见的是同步房态、房价与在住客人信息，让挂房账不用手工核对。如果对方是封闭系统，可以退一步做手工房号校验，业务照样跑得通。
支持多门店、多餐厅结构：门店各自管桌台与菜品，总部统一看报表、统一维护菜品库。价格与优惠可以按门店差异化配置。
本页不含报价。费用主要取决于桌台数量、厨房档口数量、是否对接酒店管理系统，以及要不要打通会员与储值。通常分两期：先上点餐与出餐主线，再补会员、报表与对接。