为什么食堂这笔账总也算不平
食堂这件事，几乎每家公司都在做，但很少有人把它当成一套"账"来管。行政把饭安排好、员工有饭吃，就算完成任务；真正要出数的时候——月底跟承包商结账、季末算伙食补贴、年底做成本分摊——才发现手上没有任何一条能拿来对账的记录。
现场通常长这样：
- 报数靠估。 食堂按"今天大概一百八十人"备餐，备少了挨骂、备多了倒掉。月底财务问这个月到底多少人吃了、该怎么跟承包方结账，答案还是那个"大概"。餐饮门店有自己的一套订货逻辑（餐饮连锁门店订货与配送），但企业食堂的麻烦不一样：它的"客人"是自家员工，名单在人事那里，饭钱却要在行政和财务之间结。
- 补贴发不对人。 公司规定一线员工每餐有补贴、办公室人员按不同档、出差期间不补。名单躺在某个人电脑上的 Excel 里，员工入离职、调岗、外派一变动就漏改。到月底发钱时开始吵：这个人为什么没有、那个人为什么多了。
- 对不上账。 食堂承包方送来一张月度结算单，写着"共计多少餐次、金额多少"。行政只能核对总数是否合理，没法回答"是哪一天、哪个部门、哪些人吃的"。真要对，就得翻纸质登记本一页页数。
这三个现象背后其实是同一件事：就餐被当成"月底做的一张表"，而不是"一人一次一条记录 + 一套算得清的规则"。前者只能靠回忆和人情扛，人一换就断；后者才能复核、才能解释、才能被追问。要落地也就两块——把人和标准做成基础数据，把每一次就餐做成一条记录。
第一步：把"吃了几次"记成一人一行
用 Inkwell AI 构建器做这类模块，第一步不是画页面，而是把底表拆对。底表拆错，后面所有报表都是错的。
设计决定一：餐次登记表，一人一餐一行。
这张表是全部数据的源头，字段大致是：就餐日期、餐次（早/午/晚/夜宵，选项走数据字典）、就餐人（引用员工档案）、所属部门、就餐方式（堂食/打包/加班餐/客餐）、是否计入补贴、实际就餐时间、录入时间、备注。
几个细节必须在建模时就定死：
- 唯一约束放在"人员 × 日期 × 餐次"上。 同一个人同一餐只能有一条记录，重复提交在保存时直接被拦。这一条比任何提醒都管用——补贴算多算少，根子多半是重复登记。
- 部门存快照，不做实时关联。 员工八月调岗，七月的记录仍归七月所在部门；否则一调岗，上个月的成本被重新分配，两个月都解释不通。
- 客餐与加班餐单独标记。 客餐是招待成本，不进个人补贴；加班餐应当由加班单带出来，不该由人凭印象补。混在一个"就餐记录"里不分类，补贴就等于拍脑袋。
- 实际发生时间与录入时间分成两个字段。 食堂现场忙不过来，事后补录是现实，不必假装它能杜绝；但两个时间都如实填写，报表里一眼能看出哪些是补的。补录不加权、不美化，只留痕。
设计决定二：补贴标准不进员工字段，进"标准版本表"。
最常见的错做法，是在员工档案上直接写一个"每餐补贴 12 元"。为什么不能这么干？因为标准会变、人员类别会变、而且变的时间点必须可追溯。
正确做法是拆成两张：一张补贴标准表，按「人员类别 × 餐次」定单价，并带生效起止日期；员工档案里只挂"这个人属于哪个人员类别"。这样三月把标准从 A 调到 B，二月的账照旧能按旧标准复算出来，审计问"去年十二月为什么是这个数"，系统能答。
设计决定三：主表不存月度合计。
月度汇总（多少人、多少餐次、多少补贴）一律由明细算出来，不落到某个可编辑的字段里。字段一旦存了合计，明细改了它不会跟着改，从此所有报表都不可信。这是台账类模块的通则，也是这套东西能不能长期用下去的分水岭。
设计决定四：食堂供餐侧的数和员工就餐侧的数分开记。
- 供餐侧：每天每餐次的计划人数与实到人数（食堂报），以及承包商按约定单价出的月度结算单。
- 就餐侧：一人一餐一行的个人记录。
两边对不上是常态——有人登记了没来吃、有人来了没登记、临时加人、剩餐倒掉。关键不是消灭差异，而是让差异显性：日对账表按「日期 × 餐次 × 部门」比登记数与实际领用数，差额非零时必须填原因（漏登记/临时加人/剩餐）才能递交。填原因才能关闭，比事后被财务翻出来强。
设计决定五：金额只在一个地方算总额。
食堂模块里算的是"应享补贴明细"和"结算依据清单"，不是"发了多少钱"。实际发放走薪资侧（薪资核算与发放），同一笔钱只在结算单据上记一次金额，食堂模块不另存"已发合计"，否则两边各有一份钱，对账时永远差一个数。
第二步：页面怎么摆，各角色看什么
同一个数据库，页面按"角色 + 动作"摆，系统才会被真的用起来；按数据表摆，就只有建它的人会用。
食堂报餐页（食堂管理员/前台）。 打开就是今天的三餐，默认拉出应就餐名单（按在册人员 × 班次生成），登记时点选或批量标记即可，临时加人一人一条补录。这个页面一天要用三次，所以第一屏必须是"今天的名单 + 已登记数/未登记数"，而不是一排菜单。中午十一点半打开就能知道该备多少，这比月底补表有用得多。
部门确认页（部门负责人/HR）。 看本月本部门的餐次与补贴明细，逐人可展开，异常行高亮：同一人一天三餐全在、长期未就餐却仍有补贴、跨月补录过多。负责人确认后，该部门该月锁定，后续更正走作废重开，不动历史。
结算与对账页（行政/财务）。 按月汇总餐次与人头，与承包商结算单逐行对照；差异填原因；审批通过后生成"结算依据清单"交给财务付款。这里要守住一条口径：清单只当结算依据，付款单据在财务侧，食堂模块不再记一次金额。
员工自助页（手机为主）。 本人本月就餐次数与应享补贴逐次可看；发现漏登记，可以直接提交一条"漏登记申请"，由食堂或部门确认后补行。这一条的真正价值不是给员工方便，而是把"月底来吵"提前成"当天就补齐"。
口径维护页。 餐次、就餐方式、人员类别、补贴标准版本集中在这几处维护，谁改的、什么时候改的都可查。标准一改就影响所有人的钱，所以只有指定角色能进这个页面，其余人只读。
三个字段层面的细节，建议一开始就定好：
- 账号与人员的对应关系。 它决定员工在手机端能看到谁的就餐记录，也决定部门负责人看到的范围。这件事靠角色权限控制，不要在页面上做手脚。
- 记录只增不改。 登记错了不覆盖原行，而是作废并另起一行，这样"什么时候把谁的记录改成了什么"永远查得到。
- 列表页的筛选与排序字段。 部门、日期、餐次、是否计入补贴——这几个字段要在建模时放到列表上，等用起来再补会同时动到页面和报表。
第三步：把重复的判断交给规则
这类台账的日常动作高度重复，凡是"每次都要人判断一下"的地方，都应该交给规则引擎与定时任务，人只处理真有分歧的部分。
保存时先拦，不要先收下再提醒。 不合规的数据一旦进库，后面所有汇总都被污染，而提醒通常没人看。会在保存环节拦截的几类：
- 登记人不在在册/在职名单（已离职、未入职）；
- 同一人同一日期同一餐次重复登记；
- 计入补贴，但该人员类别在该日期没有对应的补贴标准；
- 跨月补录超出允许期限（期限由企业自定，不给默认值）；
- 部门日对账差额非零但未填差异原因。
第 3 条尤其值得做：标准调整往往有几个月"空档"，靠人记必然漏，交给规则就是一次配置。
只把必须人判断的事做成审批。 日常餐次登记不走审批——食堂一天登记三次，每次等签字就没人用了。走审批的应该只有三类：月度结算单、补贴标准调整、批量补录。审批结果直接回写单据状态，不用签完字再回系统补录一遍（审批流怎么配，见审批流落地）。
定时任务管"提醒"和"草稿"，不管"改数"。 每日固定时间给未登记餐次的部门推提醒；月末自动生成月度汇总草稿，只做汇总不做金额调整，交行政复核；标准版本临近到期提前提醒。定时任务负责把该做的事摆到人面前，不替人做决定，这条边界守住，后面才不会出现"数字自己变了"的信任崩塌。
加班餐从加班单带出来，不要两条线各记一次。 加班申请与审批在线上的，加班餐记录由加班单触发生成；这样"加了班没饭吃"和"吃了饭没加班"两种异常都能被系统发现。
第四步：移动端把动作交回现场
用 Inkwell 构建器做的模块，PC 上搭好的页面会成套出现在手机端（见移动端使用指南），不需要另做一套 App。落到食堂场景，手机上最该有的是三个动作：
- 食堂/前台批量标记当天就餐。 站在打饭窗口就能点，不用回办公室凭记忆补。这是整套系统数据质量的关键一步——记录离现场越近，越接近真实。
- 员工查本人记录、提漏登记申请。 员工对自己的钱最敏感，是整套数据最好的校对力量。
- 部门负责人月度确认。 手机上看完就能确认，不必等回到座位。
需要明确的是边界：手机端不承诺离线填写与恢复网络后自动回传这类能力。食堂地下层没信号是常事，那就纸质登记、当日补录，并把"实际就餐时间"和"录入时间"如实分开填——补录不可耻，假装没补才不可控。
上线前必须定清楚的六件事
这套东西不难做，难在口径定不下来。下面六条如果在上线前没定清楚，系统一跑起来就会变成"又多一个填表的地方"。
- 补贴规则谁享、怎么算。 按餐次补还是按出勤天数补、出差与休假期间怎么处理、外派与外借人员归谁承担。这属于企业自己的制度安排，系统只负责按维护好的规则算，不内置任何法定数值；需要依据属地或行业规定的部分，以企业制度与属地主管部门要求为准。
- 人员类别与在册名单从哪来。 建议直接引用员工档案与部门组织，不要另建一份名单（员工档案与人事异动）。名单一旦有了两个版本，就一定会不同步。
- 餐次的时间划分。 几点到几点算午餐，跨时段加班餐怎么归集。划分不清，同一餐会被记两次，补贴就超发。
- 差异容忍与审批分档。 登记数与实际领用数差多少必须填原因、多少需要审批。这是企业自定的阈值，系统不预设默认值，需在交付阶段形成配置依据再填。
- 结算周期与对方单据。 承包商多久结一次、结算单谁录入、谁复核、以哪一方的数为准。这条定了，跟供餐方的争议会少一大半。
- 历史数据要不要追。 建议只补当月与期初未结的部分，不追溯全部历史；存量名单与餐次数据用 Excel 直接导入模块，不必手工敲（见用 Excel 一步建模块）。
上线前还建议做一遍模块预检：把菜单挂好、PC 与手机端都实际点一遍、权限按角色验一遍再发布（见模块的测试与发布）。餐次字典与人员类别这类选项，都在数据字典里统一维护，别让每个页面各建一套。
跑起来之后，可以往哪里延伸
- 和考勤排班打通。 出勤即带出应就餐，班次变化自动调整名单，能省掉大半补录（考勤与排班）。
- 和食材采购、供应商对账连起来。 就餐人数是食材需求的基础，采购侧的请购、入库与对账在采购管理那条线上；两边用同一份人数，备餐量和采购量才有共同依据。
- 和后厨食安记录互链。 留样、消毒、晨检那套记录管的是"吃得安不安全"（后厨食安记录），本文这套管的是"吃了多少、谁该补多少"。两套东西管理对象不同，不必合并成一张表，但可以互相引用：某天就餐人数异常的日子，正好是查留样记录的日子。
- 和薪资、成本分摊对接。 补贴明细按部门汇总后交给薪资侧核算（薪资核算与发放），部门成本与宿舍水电分摊可以并到同一张部门费用视图里看（员工宿舍管理）。
- 和访客、会议用餐联动。 客餐、会议餐在审批通过后自动生成餐次记录，不必由食堂口头通知再补。
这套东西不做什么
边界讲清楚，后面才不会有"你们不是说能吗"的扯皮。
- 不接食堂硬件。 刷卡机、闸机、称重设备、刷脸终端都不在本模块范围内，也不做人脸识别与工牌核验。餐次登记靠点选、批量标记或 Excel 导入。
- 不做算法类的事。 自动排菜、营养分析、就餐人数预测、动态定价都不在交付空间内。
- 不内置法定标准。 补贴标准、税前扣除口径、属地性规定一律不写死在系统里，由企业维护并按需更新；拿不准的部分以属地主管部门要求为准。
- 不承诺幅度结果。 不会有"省多少人工""降多少成本"的数字。能保证的是三件可验证的事：查得到——谁在哪天吃了哪一餐、谁登记的；追得回——记录被谁在什么时候更正过；对得上——登记数、领用数、结算数三处能互相解释，差额有原因、有确认人。
- 不替财务记账。 结算依据清单只是付款的依据，真正的付款与入账在财务侧完成，同一笔钱不在这里再记一次。
一句话收口：食堂这门事，把"一人一次一餐"记清楚，剩下的汇总、补贴、对账都是它算出来的结果；反过来，只要源头还是估的，后面怎么努力都只是把估算做得更精致。