宿舍这件事，难的从来不是"分房"，是"人对不上床"
有宿舍的企业，行政手上几乎都有一张反复改的 Excel：楼栋、房间、床位、住的人。这张表看似管住了，实际每个月都要为下面这些事耗上半天：
- 谁在住，说不准。 离职的人名字还挂在 305-2，新来的实习生被临时塞进 401-1，两边的表谁也没更新，等到消防检查问"这一间住了几个人"，答不上来。
- 空床是黑箱。 招工旺季要一次安排十来个人，宿管只能挨个房间敲门看，或者凭印象说"好像还有三张"，结果不是让人等，就是把两个人排到同一张床。
- 换房不留痕。 某人从 3 楼换到 2 楼，表上直接把房间号一改，原来住哪、什么时候搬的、当时那间还剩什么，全丢了。押金、水电、钥匙都对不上账。
- 水电费收得心里没底。 房间抄表一个月一次，摊到人头上怎么算各家有各家的说法：住一个人的房间和住四个人的房间一样摊，人不认；按床位摊，空床那份又没人愿意出。凑到最后往往是宿管自己贴，或者干脆不收。
- 退宿没有闭环。 人走了，钥匙和门卡还在外面，房间没检查、床垫坏了没人知道、押金退不退凭印象。
- 报修和检查全在嘴上。 灯不亮、空调不制冷，微信里喊一声，修没修、谁修的、修了几次，一个月后没人说得清；安全隐患检查（大功率电器、私拉电线、消防通道堆物）发现了当场清掉，下次检查还是同样的问题。
- 外来人员短暂入住最难管。 施工队、外协、短期实习生住两周就走，为了这几个人另开一张表，走了也没人记，最后房间变成"谁都能住"。
这些问题的共同点很一致：描述"住"这件事的数据没有被结构化地存下来，人、床位、费用三件事就永远对不上。下面的写法，就是用几张表和几个页面把"床位—住的人—期间的账"这条链固定下来，让每一笔安排都有据可查、走得掉也查得回。
数据怎么建：三层档案，加上四类事实记录
先给人话解释一个词：床位是这张网里最小的可分配单位。不是"房间"，也不是"人"。一间房住四人，就是四条床位记录；上下铺也拆成两条，编号写成 305-1、305-2 这样，现场能对上，系统里也能定位。把这个粒度定下来，后面所有问题都变得简单。
第一层：楼栋—房间—床位，三级档案
这三张表只描述"有什么地方可以住"，不描述"谁在住"：
- 楼栋：宿舍楼名称、地址、管理员、是否有独立卫浴/热水/空调这类基础条件。
- 房间：所属楼栋、房号、户型（几人间）、面积、月租金或折旧分摊口径（若涉及向员工收费）、房间状态（可住／维修中／作停用）。
- 床位：所属房间、床位编号（如 305-2）、床位类型（单人床／上下铺上／上下铺下）、当前状态（空闲／已入住／预留／维修停用）。
三个设计要点，越早定越省事：
- 床位状态走数据字典集中维护，不要在表单里手打"空着""没人"。选项一旦有同义写法，筛选就永远筛不干净——想查"还有几张空床"会查出七八种状态。数据字典的用法见数据字典：管好下拉选项的统一口径。
- 房间不存"当前住几人"这类汇总字段。 在住人数由床位状态和入住记录算出来。存一份手填的汇总，就等于给自己留了一个必然会错的数据。
- 房间号与床位编号以现场为准，别按系统习惯重编。宿管和入住人说的话、门上的编号、系统里的编号要一致，否则每次核对都在翻译。
第二层：入住记录——一行代表"一个人一次入住"
这是整个模块的核心主表，也是最容易建错的一张。推荐的做法是：一次入住一条记录，换房就新增一条，退宿只回填这一条的结束信息，绝不覆盖原来那行。
核心字段：
- 入住人（从员工档案里选，不手打姓名；外协或短期人员另建一份人员来源字段区分）
- 床位（引用上面的床位档案）
- 所属部门、联系电话（部门用于分摊和审批，电话用于通知）
- 入住日期、预计退宿日期（预计日期是后面自动提醒的依据，很多人只在纸质单上写"住到月底"，系统里不填，提醒功能就废了）
- 入住类型（新员工／实习生／外协施工／短期借住）
- 实际退宿日期、退宿原因（离职／换房／外租到期／个人申请／其他）
- 状态（待审批／在住／已退宿／已取消）
- 住宿费标准与是否收费（有些企业免费，有些按月收，口径要能落成字段）
为什么坚持"新增一行而不是改一行"？ 因为住宿历史本身有管理价值：某人一年内换了三次房，说明床位紧张或者安排不合理；某间房半年住过五拨外协，检查时要知道这间房到底接触过哪些人。这些信息在"直接改房间号"的模式下全部消失。
这套做法背后有两条硬约束，建议在建模时就用上：
- 同一床位同一时点只能有一条在住记录。 用唯一约束或数据流规则在保存时拦截，防止两个人被排到同一张床——这是宿舍管理里最常发生、也最难当场发现的错。
- 床位状态跟着入住记录走。 入住保存成功后床位置为已入住，退宿保存后自动回到空闲。靠人手工去改两处，一定会出现"床空着但系统显示有人"。
第三层：抄表与分摊——房间层记读数，人头上记明细
水电费算不清，九成是因为读数和分摊挤在同一张表里。正确的拆法是把两件事分开：
- 抄表记录：一房一期一行。字段包括房间、费用类型（水／电／燃气）、上期读数、本期读数、本期用量、抄表日期、抄表人、异常说明、现场照片。用量由两个读数算出来，不要让人手填。
- 分摊单：一房一期一行，记总用量、总金额、分摊方式、参与分摊人数、生成日期、状态（草稿／已确认／已通知）。
- 分摊明细：一人一行，挂在分摊单下。记人、床位、分摊用量、分摊金额、实收状态。
关键决定有三个，都在上手前想清楚：
- 房间层记读数，人头上记明细，主表不存"每人多少钱"。 人数会变（月中有人退宿、有人入住），把人均金额写死在主表，人一变就得重算重填。
- 空床位是否参与分摊，先定规则再上线。 常见三种：全部由在住人分摊（人均高但省事）、空床由公司承担（员工只摊自己的）、按房间固定人均（不随人数变化）。三种都合理，可怕的是不同月份用不同口径。
- 月中入住与退宿怎么算，写成一页说明。 按整月算、按天折算、还是次月起算，是个业务约定，不是技术问题。定不下来，分摊单永远有人拒付。
第四层：费用、报修与检查，四类事实记录各管一段
- 费用记录：住宿费、押金、水电费分三类记，一行一笔、只增不改。押金收取与退还各起一行，退还行注明对应哪一笔押金。主表（入住记录）里不要再存"累计已缴金额"，那是汇总字段，一改就错，一错就查不出为什么错。
- 报修单：房间或床位、故障类型（水电／门窗／家具／网络／其他）、报修人、报修时间、处理人、完工时间、维修结果、照片。重复报修是常态（同一台空调修三次），所以每修一次一条记录，别在原单上反复改描述。
- 检查记录：检查日期、检查人、检查项、发现问题、整改要求、整改完成日期。做成周期性的检查表（月度卫生检查、季度安全检查），「哪些房间本月还没查」就变成一个可筛的清单。
- 钥匙与门卡发放记录：卡号、发放人、发放日期、归还日期、归还状态。宿管最容易卡住的位置就是这里，退宿时"卡还在他身上"必须有据可依。
页面怎么用：五类人，五个入口
数据建好之后，真正决定这个模块能不能用下去的，是每个角色打开系统时看到的那一屏。宿舍管理涉及的人不多，但每种人的诉求差别很大，按角色分页面比做一个"大而全"的管理界面有效得多。
入口一：宿管——床位看板与待办
宿管每天进系统的第一屏不该是一张长表格，而是"现在的情况"：
- 按楼栋分组的床位视图，一行一间房，房内每张床标出状态：空闲、已入住、预留、维修停用。筛"空闲"就直接得到可安排的床位，不用挨个敲门问。
- 待办清单：今天要办入住的、本周预计退宿的、超期未退的、钥匙门卡未归还的、本月还没抄表的房间。
- 一键进入办理：从空闲床位点进去就是入住办理表单，房间、床位、编号自动带出，只剩入住人和日期要填。宿管最烦的是重复输入，把带出的字段做足，录入意愿就上来了。
入口二：入住人——我的宿舍
员工（和外协人员）看到的是自己那一屏，内容很少但每条都要准：住的哪间哪张床、室友是谁、入住日期、本期水电分摊金额与是否已缴、我的报修记录与处理进度。报修入口放在这一屏最显眼的位置，别藏在三级菜单里——这条路径决定了他会不会用系统，还是继续在微信里喊。
入口三：部门负责人/审批人——入住与退宿审批
新员工入住、外协人员借住、免住宿费申请，这三类建议走审批。审批流的作用不是增加流程，而是把"谁批的、什么时候批的"留下来。外协人员进场这一环尤其需要——宿舍住进来的是非本公司人员，责任要有人认。审批流的搭法可以直接用平台的工作流能力，请假、报销这类单据和宿舍入住单是同一种结构，配法见审批流落地。
退宿涉及押金退还的，也走一次审批，金额和结论都由审批记录承载，不需要宿管记在笔记本上。
入口四：财务/行政——分摊单与费用台账
每月最重的工作在这两屏：
- 分摊单工作页：选期间、按规则生成，页面上并排显示总用量、总金额、参与人数、人均金额，以及和上月、去年同期的对比。哪个房间人数变了、哪个房间用量跳了，在这里能看出来。生成后可以逐条复核、手工调整（例如某房水表故障期间按上期估算），确认后通知到人并导出。
- 费用台账页：住宿费、押金、水电费的应收与实收，按部门、按期间筛。押金"谁交的、退给谁了、还有多少没退"一筛就清楚。导出成 Excel 是必备动作——财务的核算流程不会因为上了系统就改，能导出、能对上，别人才愿意用这套东西。
入口五：后勤负责人——入住率与问题清单
管理层要的不是明细，是四五个能回答问题的数：床位总数、在住人数、空床数与空置月份、按楼栋的入住率、本月报修量与平均完工天数、本月检查发现的问题数与整改完成数。看板做两三个图就够，指标口径写清楚，别做一排没人看的曲线。
自动化：把"要人记"的活交给规则
这类后勤模块的价值，很大一部分不在录入，而在该提醒的事不用人记。平台里能直接用的有四类机制，不需要额外写程序。
1）数据流规则：保存时校验
下面这几条建议在建模时就配上，它们能把最常见的错挡在录入环节：
- 保存入住记录时校验床位状态，非空闲则拦截并提示当前在住人。
- 退宿时校验钥匙与门卡是否已归还，未归还的不允许直接把状态改成已退宿（或允许改但标记为"待收回"进入待办）。
- 抄表记录保存时校验本期读数不得小于上期读数；小于时要求填写换表或订正说明。
- 分摊明细合计必须等于分摊单总额，不等则不允许确认。
这几条都是"人对不齐就会出错"的地方，交给规则在保存那一刻核对，比月底对账省事得多。数据流规则的触发条件和动作可以按业务改，不用动页面。
2）定时任务：周期动作自动跑
- 抄表提醒：每月固定日提醒宿管录各房间读数，未录的在待办里挂着。
- 退宿到期提醒：预计退宿日前若干天提醒宿管与入住人，超期未退的进入超期清单。
- 周期检查任务：按月度卫生检查、季度安全检查自动生成待检查清单，谁查、查了几间，进度可见。
- 汇总推送：月初把上月入住与退宿变动、空床数、未收回钥匙清单推给后勤负责人。
定时任务怎么配、执行记录在哪看，参考工作流与定时任务：让重复性工作自动跑。
3）审批流：三处需要留痕的地方
入住（尤其外协人员）、免收费申请、押金退还。其余日常动作不必都上审批——审批一多，宿管就会绕开系统直接用微信沟通。
4）通知：只推该知道的
分摊单生成后逐个通知到入住人；退宿提醒通知到本人与其部门；报修完工通知报修人。站内通知配合移动端，比在群里 @ 一遍更可查。
移动端怎么配合：现场办理与随手报修
宿舍管理的矛盾在于：数据要在现场产生，记账却在办公室。宿管带着人看房、发钥匙、查房间，用的是手机；回到办公室再补录，错误和遗漏就是在这段时间差里产生的。
平台上 PC 端建好的业务模块会同步出现在移动端工作台，用的是同一套数据和同一套权限，不需要另做一套手机页面（同步机制与入口见移动端使用指南）。这个模块里，手机上真正需要顺手的是四个动作：
- 现场办入住：选楼栋、房间，点空闲床位，录制入住人（可搜索员工姓名），提交。字段带出得越全，现场越愿意直接用手机办，而不是回办公室补。
- 随手报修：入住人在自己那一屏填一句问题、拍一张照片，提交即可。图片留证的价值在于争议时说得清——床垫原来就破、空调原来就响，有照片就不是"谁弄坏的"。
- 现场检查与整改：检查人员按检查清单逐项勾选，发现问题当场拍照、填整改要求，整改完成后再补一条完成记录。这样"上个月发现的问题这个月还没改"在清单里是可见的。
- 抄表录读数：只填本期读数，用量与金额自动出来，异常时补一句说明。
两点要说清楚，避免上线后发现落差：
- 手机端按房间号和床位编号检索，需要时可直接打开该房间对应的表单；如果现场希望做到"扫一下门上的码就到这间房"，目前的实现方式是把房间编号作为检索入口，具体的硬件与识别类能力需与实施方确认，不在本次方案范围内（见文末边界）。
- 宿舍楼下信号差是常态。 该方案按在线录入设计，请在现场确认网络可用，或保留纸质记录后回办公室补录的兜底做法；离线填写与自动回传不作为本方案的承诺能力。
上线前查什么：七件事
这类模块上线失败，几乎都不是功能问题，而是基础数据没对齐、口径没谈定。上线前按这份清单过一遍：
- 床位清单与现场逐间对一遍。 房间号、床位数、上下铺区分、哪些房间停用（当仓库、待维修），全部以现场为准。这一步偷懒，后面每个月都在纠错，而且入住人会觉得系统不准。
- 在住人员必须期初导入，一床一人。 上线当天的在住状态是整套数据的起点。先把 Excel 表整理成"床位编号 + 姓名 + 入住日期"三列，再照着填进系统；表格怎么起步建模块，参考用 Excel 一步建模块。
- 分摊口径和财务当面对一次。 三个问题必须当场定：空床位那份谁承担、月中入住退宿怎么折算、公共区域水电（走廊照明、热水循环）怎么摊。这三件事不定下来，分摊单一发出去就会有人来问，宿管很快就不敢发了。
- 单价与计费周期落成可维护的数据。 电价、水价、周期起止规则做成可改的记录，不要写死在计算里。价格调整时改一处即可，不必改模块。
- 权限按岗位配好。 宿管能办入住退宿、能录读数；财务能看全量与费用、不能改原始读数；部门负责人看本部门住宿人员；入住人只能看自己的记录。证件号、联系电话这类字段要单独收紧。粒度如何控制见角色与权限配置。
- 所有订正都要留痕。 读数被谁改过、入住记录被谁改过、押金退了多少，必须可查。平台的审计日志会记录敏感操作，上线前确认订正动作走审批或至少留日志，别让账改过之后说不清。
- 历史欠费不要迁移。 上线前的旧账按存量处理，系统只从上线月起算。把历史欠费一条条搬进新系统，工作量巨大，还会把旧账的错误带进新账。上线后先在测试环境把一条完整流程走通（安排入住 → 抄表 → 生成分摊 → 退宿 → 退还押金），确认无误再发到正式环境，具体做法见模块的测试与发布。
之后怎么延伸：从一张床位账长成后勤台账
这个模块做完，最值得补的往往不是更多报表，而是把它和已有台账接起来：
- 接人事异动。 员工离职时自动生成退宿待办，入职时自动带出"是否需要安排宿舍"。宿舍和人事是同一件事的两头，接通之后，宿管不用每周去问 HR 谁走了。人事一侧的建法参考员工档案与人事异动。
- 接能源抄表。 如果厂区和宿舍共用一个总表，宿舍房间的用量可以作为厂区能源账的一个分摊对象，两边口径要统一。但要注意分工：厂区的水电汽计量与分摊是另一套账，见能源抄表与用量分摊，宿舍这套只解决"房间里几个人、每人多少"。
- 接外来人员管理。 外协施工队住宿舍，通常也要进厂区，入住名单和访客通行可以互相引用，减少重复登记，见访客登记与门岗通行。
- 接报修与维修。 宿舍的水电报修如果和物业维修是同一批师傅，可以把两张单合并成一张派工单；如果师傅不同、结算也不同，就分开建、互相引用，避免把两套成本混在一起，参考物业报修。
不做什么：这份方案的边界
说清楚不做什么，比罗列能做什么更有用。以下内容不在本方案范围：
- 不做门禁与硬件的联动：门锁、闸机、水电表远程采集、空调控制都不在本方案内。系统只负责人、床位、费用与记录。
- 不做人脸、指纹等生物识别核验，也不做人脸门禁的对接。
- 不做在线收款通道：系统记录应收、实收与凭证号，实际收款仍在企业现有的收付渠道完成。
- 不承诺降本与"零纠纷"类结果：这套做法能保证的是"谁住哪张床查得到、费用怎么算得出、卡还没还看得见"，不是费用一定会下降。
- 不替代现场管理判断：谁该住进来、按什么标准分配（职级、工龄、距离），是企业的制度问题，系统只把制度执行的结果记录下来。
适合上这套模块的情况很具体：自有或租赁宿舍几十间以上、同时在住几十人以上、招工旺季存在集中入住、或者向员工收取住宿费与水电费、或者需要对外协与短期人员做人员管控。如果只有一两间房、住三五个人，一张维护良好的表格反而更快——那也是一种诚实的选择。