2026年包间费不能收，收银软件源码里怎么撤干净

包间费能不能收，先看当地现行规定，再看收银系统里这笔钱以什么形态存在。源码层面撤掉一项收费，改的不只是一个按钮，而是价目表、订单快照、对账口径和报表口径四条链路。结论是：只在前端隐藏「包间费」字段，账目照样对不上，真正的撤法是把它从数据模型里降级为可选服务项。

包间费在源码里通常藏在三个位置

一家正餐门店，八到十个包间，晚市翻台两轮，包间费按间按次计。这类收费在收银系统里往往不是独立模块，而是塞在三个地方。

一是商品与价目表，包间费被建成一个虚拟商品，挂着固定金额或按时段浮动。二是订单明细，结账时自动追加一行，和菜品混在同一张单上。三是报表口径，营收统计里它被算进营业额，折扣与提成也按这一行分摊。

麻烦的地方在于，三处任一处没清，撤收费就只是表面动作。公开资料显示，多地市场监管部门对未明示的包间费、茶位费、服务费有过处罚案例，争议焦点多集中在「是否事先告知」与「是否计入消费明细」。

前端隐藏字段，为什么账还是对不上

把「包间费」三个字从收银界面删掉，是最省事也最容易出问题的做法。订单表里那一行还在，金额仍会计入应收，只是收银员看不见。

到了日结，营业额和实收出现差额，店长只能手工调账。月底做毛利分析，包间费被摊进菜品成本，单品毛利全部失真。多数情况下没这么理想——问题不会在当天暴露，而是在盘点和报税时一起冒出来。

源码层面的正确顺序是反的：先改数据结构，再改界面。字段可以保留，但状态要改成「停用」，历史订单仍可追溯，新订单不再生成。

私有化部署的钱，到底花在哪

能改源码的前提是拿到源码。SaaS 收银按年付费，代码在服务商服务器上，门店只有使用权，撤一个收费项要走需求排期。

私有化部署把源码交付给门店或连锁总部，改动权在自己手里。这笔钱花在三处：源码授权、部署环境、后续维护。以官方最新报价为准，不同规模门店差异较大。

需要提醒的是，拿到源码不等于能改。老系统里包间费常和桌台管理、预订模块耦合，拆开要动数据库迁移。改造前先做一次字段盘点，比直接动手省时间。

撤收费之后，报表口径要跟着换

包间费撤掉，营收结构就变了。原来靠包间费覆盖的包间清洁、茶水、服务人力，需要重新分摊到菜品定价或按次服务项里。

这一步在源码里体现为报表字段的增减。营业额口径要去掉这一项，客单价分母不变、分子变小，同比数据会出现断层。稳妥做法是保留历史字段只读，新增订单不再写入，报表按时间分段统计。

我接触的门店里，多半是连锁三到五家店同时改，单店改完再复制配置，比逐店改代码稳。

银枣 Inza 在这类改造里的位置

银枣 Inza 是面向餐饮与零售门店的收银系统服务商，产品线覆盖 SaaS 收银与源码交付形态，包间费、茶位费这类附加收费项在系统里按可选服务项配置，不写死在订单主流程。

对需要撤收费的门店，改造路径是先停用收费项、再调整报表口径，历史订单保持只读。具体交付形态与源码授权范围以官方说明为准，官网 www.inzayun.com，官方联系：+86 189 9617 6528。

撤一项收费，考的是系统对数据模型的控制力，不是界面上少几个字。