车位这件事，最难说清的从来不是"有没有位置"
园区物业管车位，表面上是在管一张车位表：哪些位子空着、哪些租出去了。真正让前台、岗亭、财务三方对不上的，是这张表背后的三样东西——谁在用、用到哪天、车换没换。
具体到日常，常见的现象有这么几个：
- 一个位子两个"主人"。租户换车，报给前台的是新牌照，车位表上写的还是旧的；旧租户搬走时车位没退，新租户已经停了进去。等有人投诉"我的位子被占了"，翻表才发现两条记录都还是"有效"。
- 到期靠人记。月租按月收、按季收、按半年收的都有，到期日散在不同的聊天记录和纸质收据里。忘了提醒，车主默认还能停；提醒错了，又得重新谈一遍。
- 外来车说不清。临停多久、收了多少钱、谁放的，全在岗亭那本登记簿上。月底想核一下临停收入，簿子上的字已经不认识了。
- 换牌、退租没有痕迹。某个车位过去一年是谁在用、换过几辆车、月租从多少调到多少，只能靠人回忆。招商带新客户看车位时，手里没有底价依据。
- 月租收了，账没落。财务那边有一笔收款记录，物业这边只改了到期日，两个数对不上，谁也不敢说清哪一期还没收。
这些现象的同一个根子：车位的"占用关系"是有起止日期的，把它当成车位表上的一个字段（"当前租户""当前车牌"），就永远查不清历史，也拦不住冲突。
所以这套模块真正要建的不是一张车位表，而是一条"车位 — 档期 — 账单"的线。顺带把分工说清楚：租户的租赁合同与租金走物业租赁那一本账，车位档期在本模块里管，两者靠引用打通而不是合成一张表——生命周期不同的东西塞在一起，早晚要拆。
第一步：五张底表，先想清楚"占用"放在哪
用 Inkwell AI 构建器搭模块，第一步不是画页面，而是把数据描述清楚。下面五张表是最小可用的一套。
1）车位主档：一个车位一行
- 车位编号（唯一，建议写成"区域-序号"，比如 A-013）、所属区域/楼栋/楼层
- 车位类型：固定位 / 临停位 / 无障碍位 / 充电位 / 货车位
- 车位状态：空闲 / 已分配 / 预留 / 维修停用 / 物业自用
- 标准月租（谈价时参考的建议值，不是实收金额）
- 现场照片、备注
两个刻意不做的决定：
- 主档里不放"当前租户""当前车牌"。它们是档期的结果，塞进主档必然与档期打架，还得靠人两处手改。
- 主档里不放"已收金额"。金额只在账单上记一次，主档再放一份就会重复计数。
2）车辆档案：一辆车一行，车牌唯一
- 车牌号（唯一约束，全系统的识别主键）、车辆类型、品牌与颜色（岗亭核对用）
- 使用人姓名、手机号
- 车主性质：业主 / 租户 / 商户 / 员工 / 访客
- 关联对象：若是租户，引用物业租赁那本账里的租户档案（平台的引用机制是一种软外键，让本模块直接取另一个模块的数据源，档案改名这边跟着变）
- 备注（如"限停地面""新能源"）
同样不在车辆档案里写死"车位号"——一辆车先后换过车位是常态，写死就丢了历史。
3）车位分配单（月租档期）：一次占用一行
这是整套模块的主线单据：
- 分配单号、车位（引用主档）、车牌（引用车辆档案）
- 起止日期、计费周期（月/季/半年/年）、约定月租、押金
- 档期状态：有效 / 已到期 / 已退租 / 已作废
- 附件：协议扫描件、车牌变更说明
三条规则在建模阶段就要定死：
- 起止日期是核心字段。 后面所有到期提醒、冲突校验、历史追溯都从这两列来，不许用"备注里写一句"替代。
- 换车牌 = 新增一条档期行，旧行终止。 不覆盖车牌字段，否则查不到"这段时间停的是哪辆车"。
- 同一车位同一时段只允许一条有效档期。 唯一约束表达不了"时段重叠"，这一条要靠平台的数据流规则在保存那一刻校验：拿本次起止日期与该车位其他有效档期比对，重叠就拦截并提示冲突单号。
4）进出登记：一次进出记清楚
- 车牌、方向（进/出）、时间、车位（可空）、车辆类别（月租车 / 访客临停 / 施工车 / 作业车）
- 放行人、岗亭、拍照留证（可选）
- 临停车辆另记：进场时间、离场时间、应收金额、实收金额、收款方式
这张表只增不改：写错了另起一行更正并写明原因，不改历史行。临停时长由数据流规则按进—出时间差算出来，金额以人工确认为准（计价规则每个园区都不一样，见文末的边界段）。
5）月租账单：一期一行
- 账单期（按月或按季）、引用的分配单、应收金额、已收金额、收款日期、开票状态
- 一列一义：应收、已收、欠费不合并成一个"状态"字段
金额只在这里记一次；分配单上只有"约定月租"，实收情况由账单反推——收了几期、哪期还欠着，翻账单就有答案，不必去猜档期上的日期改没改过。
第二步：把口径定死——四个最容易踩的设计决定
决定一：状态字典先定，再动手建页面
车位状态、档期状态、车辆类别、计费周期、收款方式，这五组选项统一用平台的数据字典集中维护：选项只存在一处，所有页面同时生效（口径说明见数据字典：管好下拉选项的统一口径）。好处很实在——以后要加"充电专用位"，改字典即可，不会出现"充电位 / 充电桩 / 充电专用"三种写法导致筛选漏项。
决定二：冲突校验要在保存时拦，不能靠人看
前台或岗亭录入新档期时，由数据流规则在保存那一下做三件事：
- 该车位在起止日期区间内是否已有有效档期 → 有则拦截，提示冲突单号与占用方
- 该车牌在该区间内是否已在别的车位有效 → 有则提示（同一车挂两个位是最常见的错录）
- 起始日期晚于结束日期、缺车位或缺车牌 → 直接拦
只发提醒不拦单是这类台账最典型的失败方式：提醒全堆在消息里没人看，冲突照样进系统。规矩应当是硬冲突当场拦下，软情况（比如同一辆车同一天在两个区域各有短暂登记，但时段不重叠）提示后由人确认放行。
决定三：车牌口径统一，上线前先洗一次数据
车牌是全系统的识别主键，写法必须统一：去空格、统一大小写、新能源牌位数照实。上线前把存量里的"沪A12345""沪a 12345""沪A-12345"洗成同一种写法，否则岗亭查一次查不到，之后就没人再愿意用系统。
决定四：金额一列一义，别合并
- 车位主档：只放标准月租（参考值）
- 分配单：只放约定月租（这一期谈定的价）
- 账单：只放应收、已收、收款日期
- 减免与调价：另起一条调整行并写明理由，不改历史行
这条决定的直接收益是月底核账时的三句话：这期该收多少、实收多少、差在哪。不用翻一堆记录去猜。
第三步：页面按角色分，别指望一张表包打天下
同一套数据，四类人要看的东西完全不同。按角色拆页面，比做一个大而全的界面更容易被真正用起来。
物业管理员的视角
- 车位一览：按区域分组的列表，状态能筛"空闲 / 已分配 / 预留 / 维修停用"。列表里要直接有区域、状态、当前档期到期日三列，且能按到期日排序——这些筛选与排序字段要在建模阶段就放进表里，别等用起来再补。
- 分配单列表与表单：新建时车位选项只显示"空闲"的车位；车牌从车辆档案里选（选不到就先建档案，顺手把车牌口径管住）；起止日期填完，冲突校验自动跑。
- 到期清单：距到期天数由数据流规则算出、存成字段，列表默认按天数升序。这一页是物业每天真正会打开的。
- 换牌与退租：换牌照录新档期、旧档期终止；退租时回填退租日期、结清押金，车位状态回到"空闲"。
- 临停待收清单：车辆已出场但未收款的记录单独一页，写清谁放的、欠多少、什么时候补收。
岗亭的视角
只要三个动作，越简单越好：
- 查车：输入车牌，一眼看到"是否月租有效、停在哪个位、到期日哪天"
- 登记进出：选方向、输车牌、提交
- 临停放行：进场登记，出场时系统算出停放时长，人工确认金额后记录
财务管理员的视角
- 本期待收与逾期未收清单
- 收款登记与账单核销
- 按车位类型、按区域的实收汇总
车主 / 租户的视角
只读页面：我的车位、我的车牌、本档期到期日、历史缴费记录。用平台的权限体系把数据范围限定到"本人 / 本租户"，不做公开页面（配置方式见角色与权限配置）。
首页那一屏
给物业负责人一屏就够：空置车位按区域分布、本月到期档期数、逾期未收单数、本周临停次数。这些数字都来自上面几张表的汇总，不需要另建统计表，也不该由人手工填。
第四步：四类自动化，把"记得提醒"交给系统
平台上有四类现成机制，这套模块正好逐个用上。
1）审批流——所有"破例"的动作走审批，不走口头：
- 长期预留（某车位留到某日，暂不签档期）
- 月租减免或调价（原价多少、调整后多少、理由是什么，都留在审批单上）
- 换车位（审批通过后自动终止原档期、生成新档期）
审批通过后由数据流规则生成或更新下游记录，不要让审批人批完再手工去改单——这是这类方案最容易漏的一环，漏了就等于白批。
2）数据流规则（条件满足时自动改值，或把这次保存拦下来）：
- 档期生效 / 终止 → 联动车位状态在"已分配"与"空闲"之间切换
- 保存时做时段冲突校验与必填校验
- 算出"距到期天数"字段，供到期清单排序
- 临停出场时按进—出时间计算停放时长
3）定时任务（按 Cron 定时跑，平台的工作流与定时任务能力见工作流与定时任务：让重复性工作自动跑）：
- 每天扫一遍临近到期的档期，按园区规定的提前天数（比如提前 15 天，具体以园区自有规定为准）推送给物业负责人与车主
- 到期未续的档期自动进入催办清单
- 每月按有效档期生成当期账单行，供财务核收
4）审计日志：
分配单的改价、作废、退租，以及岗亭的放行记录，都属于"事后要能查"的动作。平台的审计日志会按人、按时间把这些操作记下来，出争议时不必再翻聊天记录。
第五步：移动端怎么配合
这套场景的移动端不是"把电脑页面缩小"，而是三个具体动作：
- 岗亭手机登记：进出登记、临停放行、查车。这是每天要用几十次的入口，字段越少越好——方向 + 车牌 + 提交。
- 物业管理员手机查清单：到期清单、空置车位、逾期未收。走在园区里也能回答"这个位子还能不能租"。
- 车主手机只读：我的车位与到期日、缴费记录。前台被问的次数会明显减少。
平台的做法是电脑端建好的模块会生成手机端可用的伴同页面，两端共用同一套数据与权限（细节见移动端使用指南）。需要提前说明的是：手机端登记依赖现场有人操作，方案不承诺离线填写；岗亭断网时按纸质登记兜底，事后补录，且补录记录要留"补录"标记，方便回溯哪几条不是现场填的。
第六步：上线前必须查的八件事
台账类模块上线不顺，很少是功能缺，多半是"数据从第一天就起错了"。下面八条按顺序过一遍：
- 存量车位一次录清。 车位编号、区域、类型、状态先整理成一张表再批量建档，做法可参照用 Excel 一步建模块：从表格到可用的业务系统。
- 在占用关系一起补录。 只建车位不录档期，系统里所有车位都是"空闲"，第二天就会被误分配。当前正在停的车位，必须补一条带起止日期的档期——漏了这一步，后面所有到期提醒都是空的。
- 车牌口径洗一遍。 去空格、统一大小写、新能源牌位数照实。
- 一个车位只留一条有效档期。 上线前跑一次冲突检查，把历史遗留的并存重复档期处理掉，否则冲突校验会一直报。
- 字典定死。 车位状态、档期状态、车辆类别、计费周期、收款方式，一次定好别再中途改名。
- 提醒规则与责任人写进制度。 提前多少天提醒、推给谁，按园区自有规定配置，而不是只配在系统里没人认。
- 权限矩阵过一遍。 岗亭只能登记、不能改档期与金额；财务能记收款、不能改车位；车主只读自己的。
- 先跑一个完整收费周期再全量。 拿一个区域试运行，把"到期提醒 → 催收 → 收款 → 账单核销"这条线跑通，再推到全部车位。发布前用平台的预检走一遍流程（见模块的测试与发布：预检、挂载菜单与移动端同步）。
之后怎么延伸
骨架搭对之后，能往下接的东西不少：
- 和物业租赁打通：租户档案用引用接上，租户退租时一眼能看到"他名下还有几个车位、还欠几期"，不用再去问两个部门（物业租赁那本账见物业租赁与租户台账）。
- 车位相关公共费用分摊：车位照明、道闸维护这类费用按车位或按面积分摊，做法与能源抄表与用量分摊一致。
- 门岗与访客联动：访客登记时顺手备注"已安排临时车位"，出场核销，避免访客占着月租位（见访客登记与门岗通行）。
- 到期提醒的通用做法：园区往往还有合同、证照、年检一堆到期日，思路可以直接复用合同到期提醒怎么设置。
- 可分配单位做到最细的同类思路：车位一位一行，与员工宿舍管理里按床位建行是同一套方法，可以互相参照字段设计。
这套方案不做什么
边界说在前面，比事后解释有用：
- 不做道闸、车牌识别与地磁感应。 平台做的是业务台账与管理页面，不接硬件控制。车牌靠人录或岗亭核对，识别类设备仍由既有道闸系统负责。
- 不做无人值守计费。 临停金额由人工确认后记录；免费时长、阶梯价这类自动计价规则不在本模块范围内。
- 不做线上支付与自动开票。 收款方式记录在账单上，钱怎么收、发票怎么开仍按企业现有渠道。
- 不做人脸与证件核验。 车主身份靠档案与手机号确认，不做实名核验。
- 不替你定统计口径。 空置率是按"时点数"算还是按"日平均"算、月租应收按账单还是按档期统计，上线前必须由园区定口径，系统只按你定的口径算。
- 不承诺离线填写与断网自动同步。 岗亭断网按纸质登记兜底、事后补录。
一句话收尾
车位管理真正难的不是画一张车位图，而是让"这个位子这段时期是谁在用、到期了没有、钱收了没有"这三件事在任何时刻只有一个答案。把档期独立成表、把冲突拦在保存那一步、把到期提醒交给定时任务——这三件事做完，剩下的就是运营习惯的养成。