一间房、一份合同、一笔租金，为什么总是对不上
物业和园区的租赁管理，问题很少出在"算不清账"，而是出在"账不在一个地方"。
招商那边有一张房源表，标注哪些房间空着、哪些已租；财务那边有一张应收表，记录谁该交多少租金；前台或楼栋管理员手里还有一份微信聊天记录，写着某家租户说"这个月只用了半个月""空调坏了要扣钱"。这三份东西各自都在更新，但没有一份是完整的——于是每个月都要花时间把三份摊在一起对账，对完还不敢保证下一次能对上。
具体到日常，常见的现象有这么几个：
- 房源状态靠人记。某间房退租了，房源表上忘记改回"空置"，招商带客户看了三次才发现早就能租了；或者反过来，一间房已经签了意向，房源表还挂着"空置"，同一间房被重复承诺。
- 合同和房间脱钩。合同是一份 PDF，存在某个人的电脑里；房间号是手写在合同抬头上的。想查"3 号楼 201 现在租给谁、租到什么时候、租金多少"，得先找到那份文件。
- 租金收缴全看人盯。到期日靠财务在日历上看，忘了提醒就逾期，逾期的又不好意思催，一拖两个月。催了以后对方说"上个月你们说要维修，我们扣了几天"，于是又变成扯皮。
- 退租没有闭环。租户搬走了，钥匙交了，但水电费没结、押金没退、房源没释放、门禁卡没注销，四件事分属四个人，任何一件漏掉都留下后遗症。
- 说不清历史。这间房过去三年换过几个租户、租金是什么走势、每次退租时扣了多少钱，翻不出来。招商谈新客户时手里没有底价依据。
这些问题的共同点是：同一个业务对象（房间、租户、合同、账单）的信息散在多个载体上，缺少一个把它们串起来的地方。 用 Inkwell AI 构建器搭一个物业租赁与租户台账模块，本质上就是把串起来这件事做成系统——不是买一套大而全的物业 ERP，而是先把自己现在真实的四张皮合成一条线。
第一步：先想清楚要建哪几张底表
AI 构建器搭模块的方式是"描述需求 → 生成数据模型与页面"，所以落地的第一步不是画页面，而是把数据想清楚。物业租赁的场景，最小可用的一套底表是四张：房源、租户、合同、应收账单。四张表之间的引用关系，就是这个模块的骨架。
1. 房源表（房间级，不是楼栋级）
房源表的颗粒度建议直接做到"房间/单元"，一条记录代表一个可独立出租的空间。常见字段：
- 房源编号、所属项目（小区/园区/写字楼）、楼栋、楼层、房号
- 建筑面积、使用面积、户型或规格（可选）
- 房源状态：空置 / 已预定 / 已出租 / 装修中 / 不可租
- 挂牌租金（单价或月总额）、押金规则
- 附属信息：是否带家具、是否含物业费、可否分割出租
- 备注与附件（例如户型图照片）
关键点：状态字段必须能由业务动作驱动，而不是纯手改。 在 AI 构建器里，房源状态可以挂在合同的状态流转上——合同生效则房源自动置为"已出租"，合同终止则回到"空置"。这一步用平台的数据流规则（条件触发时自动改另一张表的值）就能做，不需要写代码。
2. 租户表（客户档案）
租户不是"联系人"，是一家签约主体。记录：
- 租户名称、统一社会信用代码或证件号、租户类型（企业/个人）
- 联系人、联系电话、备用联系方式
- 注册地址、实际经营业态（餐饮/办公/仓储等，便于判断业态限制）
- 合作起始日、信用备注（历史逾期、纠纷记录）
- 附件：营业执照、身份证明
为什么租户要独立成表而不是写在合同里： 同一家租户可能租两个房间、可能续租三次、可能在退租一年后再回来。独立建档以后，"这家租户在我们这儿的全部历史"一查就有。这里用平台的引用引擎（跨模块关联字段）把合同里的租户字段指向租户表，选的时候就下拉选人，不用重新打字。
3. 合同表（模块的核心）
合同是连接房源和租户的那根轴，字段要能承载从签约到退租的全过程：
- 合同编号、合同类型（新签/续租/变更）
- 关联房源（引用房源表）、关联租户（引用租户表）
- 起租日、到期日、免租期（可为空）
- 租金标准：月租金、递增规则（例如每年递增的比例或固定金额）
- 押金金额、付款周期（月付/季付/半年付/年付）、提前多少天付款
- 物业费、水电费承担方式
- 合同状态：草稿 / 待审批 / 生效 / 即将到期 / 已到期 / 已终止
- 附件：合同扫描件、补充协议
合同状态建议走审批流。 新签或者变更租金这类动作，需要有人复核。平台的工作流引擎可以把"合同草稿 → 主管审批 → 生效"做成一条可配置的审批链，审批通过后再由数据流规则把房源状态一起改掉，避免"合同生效了房源还挂着空置"。
4. 应收账单表（钱的流水）
账单不要直接从合同推，而是一期一条记录，这样才能逐期核销：
- 账单编号、关联合同、关联租户
- 费用类型：租金 / 物业费 / 水电费 / 押金 / 违约金 / 其他
- 账期（例如某年某月）、应收金额、已收金额、未收金额
- 到期日、状态：待收 / 部分收回 / 已收 / 逾期 / 已减免
- 收款方式、收款日期、收款凭证（附件）
有了这张表，收缴率、逾期名单、某间房一年收了多少钱，都是查询和统计的事，不用再拼表。
四张表之外，通常还会配两张小表：费用登记表（水电燃气抄表与分摊，物业场景的通用做法可以参考站内的 能源抄表与用量分摊）和退租结算单（退租时把未结账单、押金扣减、维修扣款一次算清）。这两张可以先不做，等第一版跑顺了再补。## 第二步：页面怎么配，才有人愿意天天用
底表建好，接下来是让不同角色各看各的。物业租赁场景里一般有三类使用者：招商（关心空置和带看）、管理员（关心合同和日常事务）、财务（关心应收和逾期）。同一个模块，给三类人看三个侧重。
房源看板：一眼看到空置
第一个要做的页面是房源列表，并且按状态做筛选标签：空置 / 已出租 / 即将到期。列表里带出"当前租户""合同到期日"两个字段——这两个字段来自合同表的引用，是列表的关联展示，不用在房源表里重复录入。
房源详情页建议做成上下结构：上半是房源本身的信息和照片；下半是"该房源的合同历史"，把历次合同按时间倒序列出来，包括终止的。招商带客户看房之前，扫一眼这个房间的历史租金和租期长度，谈判就有底。
合同台账：三个视图解决三个问题
合同列表按状态分组后，就能覆盖日常三件事：
- 草稿/待审批：谁在等谁签字，一目了然。审批走工作流，审批人收到通知后直接在页面上通过或驳回。
- 生效中：这是主力视图。列表展示合同编号、租户、房源、起租日、到期日、月租金。按到期日升序排，就自动变成一张"最近要续的合同"清单。
- 已终止：留档查询用，也是纠纷时的证据。
合同详情页把关联账单嵌进来，做成子表：这份合同一共产生了几期账单、每期收了多少、还差多少。这是租户来问"我还欠你们多少"时唯一需要打开的那个页面。
到期提醒：让系统替你盯日历
租期和租金到期是最容易掉链子的地方，而它恰好是最适合自动化的部分。在平台上，这类提醒有两条成熟做法，站内的 合同到期提醒怎么设置 讲过通用思路，落到租赁场景具体是这样：
- 租金到期前提醒：定时任务每天扫描应收账单表，把"到期日距今 3~7 天且状态为待收"的记录挑出来，用站内信或消息模板通知对应负责人。平台的通知模块支持站内信、邮件、短信几种通道，具体开哪些看你们平时用哪个。
- 合同到期前提醒：定时任务扫描合同表里"到期日在 60 天内且状态为生效中"的记录，通知招商负责人跟进续租。这个提前量按行业惯例给，写字楼通常提前 2~3 个月，园区厂房可能更早。
- 逾期升级：账单逾期超过一定天数，除了通知还自动把状态改成"逾期"，并把租户标签打上逾期标记。后续的催收动作（发函、停服务）就能按这个标记筛选。
定时任务在平台上就是 Cron 配置加执行记录，跑过什么、成功没有都能查，不用怀疑"到底提醒了没"。相关用法见 工作流与定时任务。
收款与核销：把流水变成凭证
财务最在意的是"钱的进账记录能不能对上账单"。收款动作建议做成一个独立页面：选账单 → 填金额 → 填收款方式与日期 → 上传凭证（银行流水截图或收据照片）。平台的文件模块负责附件存储，凭证跟着账单走，以后查某期账单直接点附件看原件。
如果出现分次付款，账单表的"已收金额"累加，"状态"自动从"待收"变成"部分收回"，全部收齐后变"已收"。这种状态联动同样可以用数据流规则做掉。
退租结算：四条闭环动作一次做完
退租是这个模块里唯一"一个动作牵连四张表"的环节，所以最好做成一张结算单页面，把该做的事列成清单：
- 列出该合同下所有未结账单（未收金额合计）
- 填写水电燃气末次读数和金额
- 填写维修扣款、清洁扣款等扣减项
- 计算押金退还金额 = 押金 − 未结账单 − 扣减项
- 提交审批（退押金要有人复核）
- 审批通过后，合同状态置"已终止"，房源状态自动回"空置"，租户档案上留一条"已退租"记录
第 6 步能做到自动，是这个模块相对"Excel 台账 + 微信催收"最大的价值：房间不会因为某个人的疏忽而长期空置在账面上。
第三步：移动端怎么配合
租赁管理不是坐在办公室里的工作。带看、验房、现场抄表、退租查房都在现场发生，这些动作如果必须回办公室补录，数据就会晚一天、缺一块。平台的移动端伴同机制可以在模块发布时同步生成手机端页面，不用另做一套。手机端在这个场景里最值得配的四个入口：
- 房源速查：按项目/楼栋筛，看房源状态和当前租户，带看时边走边看，不必打印一张房源表。
- 现场拍照补录：验房、交接、维修前后拍照片，直接挂到对应房源或结算单的附件上。照片本身比文字描述更能避免退租时"这墙原来就有裂缝"的争执。
- 抄表录入：水电读数现场填，不用回来转录，也不会出现抄在纸上丢了的纸条。
- 审批与提醒：合同审批、退押金审批在手机上处理，到期提醒推到手机上，避免"通知发在电脑上没人看"。
移动端的使用方式与工作台的配置，可参考 移动端使用指南。需要注意的是，手机端适合"采集与审批"，不适合做批量编辑和报表——列表批量调整依然建议在电脑上做。
上线前要查的六件事
模块搭完不等于能上线。租赁场景有几个地方特别容易在真实使用中翻车，发布前建议逐条过一遍：
- 房源有没有重复编号。房间编号是全局唯一的主键，如果历史台账里"3-201"和"3栋201"都存在，导入后就会出现两条同房记录。用统一的编码规则（楼栋-楼层-房号）清洗一遍再导入，平台侧可以按 Excel 直接建模块，参见 用 Excel 一步建模块。
- 下拉选项口径统一了吗。合同状态、费用类型、付款周期这些枚举值，务必集中到数据字典里管理，别让一个页面写"月付"、另一个写"按月"。数据字典 解决的就是这个统一口径的问题，改一处全站生效。
- 金额字段的单位与精度。租金、押金、扣款都是钱，统一到"元、两位小数"，别混着"分"用。金额字段建议用货币类型，避免计算时出现浮点误差。
- 权限配到位了吗。财务能看应收金额但不该改合同条款；招商能看房源状态但不该看到客户信用备注；管理层全看。这类区分靠角色与权限体系配置，参考 角色与权限配置。退押金、减免违约金这两类动作，建议额外加审批，而不是只靠权限挡住。
- 定时任务的时间点选对了吗。租金提醒如果设在凌晨跑，通知发出去等于石沉大海。建议设在上班后半小时，让提醒当天就能被处理。同时留意任务执行记录，确认首次运行是成功的。
- 发布预检过了吗。平台在模块发布前有预检环节，会把页面、接口、移动端同步的问题先扫一遍；发布时还能同步挂载菜单，避免"模块建好了却找不到入口"。流程见 模块的测试与发布。
另外补一件容易被忽略的：先跑一个完整周期再全量上线。挑两三间房、两三个租户，把"签约 → 生成账单 → 收款 → 到期提醒 → 退租结算"全流程走一遍，跑通了再导入全量数据。这一轮会暴露 90% 的字段缺口。
这套模块的适用边界
说清楚"不适合什么"，比只讲"适合什么"更有用：
- 它管合同与应收，不做会计记账。租赁模块能算出应收、已收、逾期，也能出收缴率报表，但它不是法定账簿，凭证入账、科目、税务处理仍交给财务系统。应收账单与财务口径之间的衔接，可以看 应收应付的台账做法 那篇的思路。
- 它不含智能定价与招商分析。系统能给你历史租金数据，但"这间房该不该涨租、涨多少"是人的判断。别指望模块替你定价。
- 它不替代门禁与能耗硬件。门禁卡注销、电表自动读数需要硬件对接，属于集成范畴；模块里做的是"登记与台账"，硬件联动需要单独评估。
- 房间数很少、租户极稳定的场景，收益有限。如果只有两三间房、租户十年没变过，纸质合同也够用，把精力放在别处更划算。
- 复杂的分段计租、阶梯电价、返点条款，需要先把规则拆成明确字段再建模型；规则本身没算清楚的，搬进系统只会更快地算出错数。
跑顺之后，往哪儿延伸
第一版把"房源—合同—账单"这条主线跑通以后，通常会有三个自然的延伸方向，都可以在同一个模块里加页面和底表完成，不用另起炉灶：
一是把维修纳入同一条链。 租户报修、师傅上门、完工验收、费用归属（谁出钱、能不能从押金扣），这些和退租结算直接相关。站内的 物业报修：从业主报障到师傅完工的一条链 讲的就是这条链怎么建，两个模块通过房源编号关联起来即可。
二是把合同预警做细。 押金退还期限、租金递增节点、续租优先权截止日，这些日期都是"忘了就吃亏"的关键日，可以参照合同台账加预警的通用做法，做成多级预警清单。
三是做经营分析。 空置率按项目/楼栋的变化趋势、平均租金水平、租户留存时长、应收逾期账龄分布——这些指标在底表规范之后都是自然产出的统计，不需要额外建模。管理层看到的应该是一块看板，而不是十二张明细表。
一句话总结
物业租赁与租户台账这个模块，落地路径不是"上一套系统"，而是把散在房源表、合同文件、微信记录里的四类数据（房间、租户、合同、账单）合成一套有引用关系的底表，再让状态流转和到期提醒自动跑起来。用 AI 构建器做这件事，起点是把你现在的台账拍照或贴进对话框描述清楚，一步步补齐字段和页面；两三天能出一个可试用的版本，先跑通一间房，再铺到全部房源。
如果你手边正好有一份现成的房源表和合同清单，最快的验证方式是用 Excel 把它导进来，看看生成的模块是不是你想要的形状——不合适就继续用自然语言改，改到合适为止。