三个真实透视案例：销售月报、考勤汇总、库存预警

前五篇讲的是「怎么拖」，这一篇讲「怎么想」。同样一套透视表技术，套进三个真实业务场景，你看的不是步骤，而是需求翻译成布局的过程。每个案例按「需求→数据→布局→口径」走一遍。

三个案例 deliberately 覆盖三种数据形态：销售明细是标准一维流水，考勤是一人多行的复合记录，库存是随时间累积的方向性流水。处理思路的差异，正体现在数据形态的差异上。

案例一：销售月报

需求：每月初给销售总监一份报表，看各区域、各产品的销售额、环比、占比，能按销售员筛选。

接需求时最该做的一件事，是问清楚报表最终被谁看、看了要做什么决策。总监要的是「谁该被谈话」还是「哪个产品该追货」，布局重心完全不同。这一步省下的十分钟，抵得过后面两小时返工。

数据：订单明细表（智能表维护），字段：订单日期、区域、省份、产品类别、产品名称、销售员、数量、金额、状态（已完成/退货）。

布局：

口径确认（关键）：金额是否含税、退货单算负值还是剔除、跨月订单按发货日还是下单日——三件事不问清楚，报表一定返工。状态字段拖到筛选区，默认只选「已完成」，退货另出一版。

交付要点：占比列用「行汇总的百分比」回答「该产品全年节奏」，环比列用「差异」回答增量。两张切片器让总监自己探索，固定布局保证格式统一。

交付后的迭代：这份月报跑了两个月后，总监通常会追问两件事——「能不能看同比」和「达成率」。同比把列区的「月」组合改成「年」即可；达成率需要源数据加一列目标值（按销售员或按区域），透视表里金额和目标并排，再加一个计算字段算差异。需求会长，但只要底表是一维结构，每次扩展都是加字段而不是重建——结构红利远大于技巧红利。

案例二：考勤汇总

需求：每月从打卡机导出记录，统计每人应出勤、实出勤、迟到/早退次数、满勤标记。

数据：打卡导出表，字段：工号、姓名、部门、打卡时间（文本或日期时间格式）、日期。注意打卡数据一人一天多行（上下班两次），这是与普通明细最大的区别。

导出数据的质量直接决定工作量：有的打卡机一次导出只给文本时间（如「09:12:35」），有的还混着补卡记录、周末加班记录。建表前先花半小时看一遍原始数据——哪些列永远为空、哪些值格式不统一——这些观察会决定清洗策略，也会写进说明表成为团队知识。

布局思路：先清洗再做表，顺序不能反。

1. 清洗：打卡时间转成真正的日期+时间序列值（格式陷阱一篇）；一人一天的多条记录用辅助列标记「第几次打卡」。
2. 打标签：这是考勤报表的核心动作。上班打卡晚于规定时段标「迟到」，下班早于规定时段标「早退」，辅助列一个 IF 搞定：

=IF(C2>TIME(9,5,0),"迟到","正常")

1. 透视表 A（按人汇总）：行放工号、姓名、部门；值放「标签列」的计数，迟到几次、早退几次、正常几次一目了然。
2. 透视表 B（按天监控）：行放日期（组合到「日」），值放人数非重复计数或异常计数，看全公司每天的异常趋势。

口径确认：迟到以公司规定时段为准（如 9:05 后算迟到），节假日和补卡怎么算——规则要在辅助列公式里写死，并写在说明表。

经验：考勤报表 80% 的工作量在清洗和打标签，透视表只是最后五分钟。别指望拖字段解决一切，先想清楚「每条记录该带什么标签」。

还有一个实战细节：月初做上月报表时，跨月数据（如 8 月 31 日晚班打到 9 月 1 日凌晨）按哪个自然月归属，要在辅助列里用日期字段判断，而不是用 TODAY 或手工切分。口径写死在公式里，月末加班就不会因为「这个月又算错了」重演。

案例三：库存预警

需求：进销存台账每周更新，自动标出「低于安全库存」的物料，给采购做决策依据。

数据：出入库流水表，字段：日期、物料编码、物料名称、类型（入库/出库）、数量、仓库。

布局思路：

1. 透视表 A（库存快照）：行放物料编码、名称、仓库；值放入库数量合计、出库数量合计。加计算字段「库存=入库-出库」。
2. 计算字段配置：字段、项目和集→计算字段→名称「当前库存」，公式 =入库数量-出库数量。
3. 预警标记：计算字段只能算数，不能写字。本想加计算字段写 IF 判断，但计算字段的 IF 引用的是汇总值不是行值，这里换思路：把透视结果通过条件格式标红更稳。

正确做法：透视表做好后，选中「当前库存」列→「开始→条件格式→突出显示单元格规则→小于」，右侧引用安全库存参数单元格，低于即标红。这是透视表 + 条件格式的组合技，比在计算字段里写判断可靠（条件格式一篇会细讲规则写法）。

条件格式要注意一点：规则里的参数引用必须是绝对引用，如 =$H$3，写成相对引用会导致每行比较不同的单元格。规则建好后，在「管理规则」里确认「应用于」区域覆盖整列库存值。

口径确认：安全库存每家物料不同，要建参数表；在途库存算不算现有库存；负库存是否允许出现（数据错误信号）。

参数表的结构建议三列：物料编码、安全库存、补货倍数。每周更新台账时核对一次参数表是否需要调整——安全库存本身也是会过期的数据，销量翻倍的老物料还守着半年前的阈值，预警就失去意义。

经验：库存类报表的难点是「状态随时间累积」，透视表天然适合（最新流水刷新即最新库存），但只保留结果不保留历史，需要历史快照就每周另存一份副本归档。

延伸：给采购看懂的结果列。采购关心的是「该订多少」，而不是「现有多少」。在透视表旁加一列建议采购量：

=IF(当前库存<安全库存,安全库存*1.5-当前库存,0)

数值乘以 1.5 是经验安全余量，按公司实际补货政策调整。这类衍生列直接写在交付表上、不进透视表，分析在透视表里、建议在旁边，职责清晰。

三个案例的共同模式

回头看，三个案例走的是同一条流水线：清洗 → 打标签 → 选维度 → 定口径 → 配交互。技术只占三成，剩下的全是业务理解。这也解释了为什么有人透视表玩得溜却做不出领导要的报表——差的从来不是技术。

五步流水线在三个案例里的具体落点：

同一张表换一行看，就是另一个业务——这就是方法论的复利：学会翻译需求，比学会一百个操作更保值。

想跟踪自己处理过的模板与口径笔记，用 Obsidian 知识管理实战 建一个「报表案例库」，把每个案例的「口径确认清单」沉淀下来；复杂场景也可以让 Claude Code 完全指南 里的 AI 帮你把口头需求整理成「维度/指标/口径」三列清单，再动手做表。而如果你打算把这些项目经验写进履历，程序员简历与谈薪指南 里关于「用数据量化成果」的写法同样适用于行政和运营岗位。

本章由 WorkBuddy 原创整理，函数行为以 Microsoft Excel 官方文档为准。