11 月批次里，和报表相关的更新有 8 条：
新增房态变更表、新增挂账预收款区间发生余额表、集团付款科目汇总报表、协议公司消费汇总加等级、宾客列表导出加车牌、房态页面统计口径可勾选、房型统计配置、预订时间分布按渠道筛选。
八条里，六条是「加」——加表、加字段、加筛选项。两条是「减」或「可选」——统计口径可勾选、整列为 0 的支付方式不显示。
加法容易，减法难
加一个字段，只需要一个理由；删一个字段，需要说服所有用过它的人。
所以报表只会越来越长。三年下来，一张表从 8 列变成 25 列，谁也不敢删。
这就是报表的通病：字段只增不减，最后变成一张没人看得完的表。
这批更新里两个「做减法」的设计
| 设计 | 减了什么 |
|---|---|
| 集团付款科目汇总：整列为 0 的支付方式不显示 | 减掉了「所有店都没用这个支付方式」的空列 |
| 支付方式按名称去重 | 减掉了「同一个支付方式出现两行」的重复 |
| 房态统计口径可勾选（默认只勾两项） | 减掉了默认显示的噪音字段 |
这三条都很小，但方向是对的：默认少显示，需要时再打开。
第一条最值得学。一张集团报表如果有 15 种支付方式，其中 6 种所有门店都是 0，那这 6 列就是纯噪音。隐藏之后，剩下的 9 列读起来快得多。
数据颗粒度的三个层次
第一层：汇总数
「本月房费收入 86 万」。回答「是多少」。
第二层：分组数
「按渠道分：携程 32 万、美团 24 万……」。回答「从哪来」。
第三层：明细
「每一笔订单的金额、日期、房型」。回答「具体是哪一笔」。
三个层次解决三种问题，混在一起用就会乱。
这次的「房态变更表」是第三层（全量明细），「挂账预收款余额表」是第二层（按公司分组），「不可售房数」是第一层（一个数）。
三个层次都补齐了，才叫「数据完整」。但日常看的时候，只看第一层和第二层，第三层用来查问题。
一个判断报表好不好用的标准
好报表
打开就能回答一个具体问题。看完知道该做什么。
坏报表
打开看到一堆数，不知道从哪看起。看完还是不知道要做什么。
判断标准很简单：这张表是为了回答哪个问题而存在的。
如果答不出来，这张表就不该存在。
门店侧该怎么用这批新报表
| 报表 | 回答的问题 | 频率 |
|---|---|---|
| 房态变更表 | 这间房的房态为什么不对 | 出问题时查 |
| 挂账预收款余额表 | 谁还欠我多少 | 每月 |
| 集团付款科目汇总 | 集团整体的钱从哪进来 | 每月 |
| 协议公司消费汇总（含等级） | 哪些协议客户值得维护 | 每季 |
| 预订时间分布（按渠道） | 什么时候该调价 | 每季 |
| 不可售房数 | 今天真正能卖几间房 | 每天 |
六张表，六种频率。不是所有报表都要天天看——这是最常见的误用。
一个提醒
新报表上线第一个月，不要急着下结论。
房态变更表要积累数据才能看出模式；挂账预收款余额表明确说了 11 月 3 日之前的数据无法统计；协议公司消费汇总要跑满一个季度才有意义。
第一个月看的是「有没有异常」，不是「趋势」。
最后一句
报表的数量不是能力的体现。能回答问题的报表，一张就够；回答不了问题的，一百张也没用。
这批更新加了六张表，但真正需要每天都打开的，只有一个数——今天能卖几间房。