并非如此。你现有的实体架构正是 NetSuite 为之而生的架构：每家门店公司成为 OneWorld 中的一个子公司，保留自己的账套，集团视图建立在其之上，而不是建立在一张表格里。本年度数据可以干净地迁移；以前年度通常留存在 Xero 里供审计查阅，而不必重建。

真正的问题是时点安排：在年末切换（最干净）还是年中切换（更快）。这正是需求调研阶段会在你做出任何承诺之前梳理清楚的事项之一。

营业不能停，实施也就不能要求它停。系统搭建与现有体系并行：切换日起，新业务干净地记入 NetSuite，历史期间则在旧系统里自然跑到结账。没有人会一边做周六的营业，一边迁移周六的账。

推进节奏通常跟随集团架构：先在少数门店试点，验证 POS 日记账和结算匹配，再分批推广到其余实体。需求调研阶段会在动工之前把这个顺序规划好。

坦白说：不能，而且你也不应该希望它来做。香港酒店餐饮业的薪酬计算围绕《雇佣条例》的 713 平均每日工资展开，小费和服务费要滚入每名员工过去 12 个月的平均数，而新的 468 规则自 2026 年 1 月起把更多临时工纳入法定保障。这些应该交给专为此而建的薪酬系统。

NetSuite 的职责在下一步：薪酬按门店、按实体计入人工成本，这样决定一家店是否可行的那个数字，才真正包含了养这家店的人力开销。

可以，而且这是一条常见路径。OneWorld 支持在现有实例中添加子公司，门店公司与控股公司共用同一租户，合并报表覆盖整个集团。真正的工作量在餐饮层：POS 日记账、支付方式清算账户，以及企业级实施从未涉及的公司间内部分摊流程。

需要注意的是现有系统的搭建质量。科目表清晰、维度设置合理，扩展就很顺畅；如果当初只是通用型上线，可能需要先做整改。我们会在需求调研阶段评估现有实例。

为多门店集团妥善配置一套 NetSuite，无论是许可还是实施工作量，都是一笔实打实的投入，我们不会假装它便宜。需求调研阶段会在你承诺之前把工作范围和金额界定清楚，不会出现无底洞式的账单。

评估时应对照现有做法的成本：财务团队每周耗在结算对账上的时间、二十家公司手工拼装账目带来的审计溢价，以及那些因为没人看得到真实损益而多开了太久的门店。

这几乎完全取决于实体数量和业务复杂度。两三家门店、一个银行账户、以刷卡和现金为主：坦白说，这个阶段 NetSuite 可能确实超出需要，我们也会如实相告。香港没有小型公司审计豁免，但三个实体的审计季靠 Xero 还能应付。

一旦超过八到十个实体，加上中央厨房向门店分摊成本、六种支付方式按不同周期结算、还要按《公司条例》第 379 条编制集团合并报表，这笔账就反过来了。现有做法的成本——财务总监的时间加上表格里看不见的问题——通常已经比表面上高得多。

自 2025 年 1 月 1 日起，酒店和宾馆须就住宿费征收 3%，并在每个季度结束后 14 天内向税务局提交报表。责任落在经营者身上，且申报数字每个季度都必须与扣除豁免类别后的住宿收入核对一致。这是一项时间很紧的新增例行申报，一年四次。

NetSuite 不负责提交报表；那是你的团队或税务顾问的工作。它提供的是那个数字：按物业区分、从餐饮及其他收费中剥离出来的住宿收入，而且账簿期间一经锁定，就不可能在报表提交后被悄悄改动。

可以，而且你可以继续使用现有 POS。NetSuite 不会取代前台的 Simphony、Infrasys 或 Eats365，而是接收它们产生的数据。标准做法是每家门店每日一笔销售日记账：按品类的总销售额、按支付方式进入清算账户的营业款、作废与折扣单独成行。至于数据如何传输——API 或定时文件——取决于具体的 POS。

关键在于日记账必须按总额入账、支付方式逐一拆分。这是下游结算匹配得以运转的前提，也是通用型集成最容易做错的地方。

平台按自己的时间表，把扣除佣金、退款和调整后的净额打给你。如果直接把到账金额记作收入，销售额就被低估，而佣金——你最大、变动最快的成本之一——则消失在一笔无人复核的轧差分录里。KeeTa 的标准外卖佣金曾高达 28%；这样的成本值得在损益表里单独占一行。

在 NetSuite 中，每个平台在每家门店都有独立的清算账户。POS 日结按总额入账，结算款与之核销，佣金作为可见成本入账，任何未匹配的款项都会留在明面上，有人能看到、有人去追。