营收 / 出品分析打法（5月固化）

三类分析 + 对应脚本

用户诉求	脚本	产出
N月营收分析（无预制表时）	`build_analysis.py <目录> <YYYY-MM>`	营收分析xlsx(13 sheets) + `_analysis_summary.json`
各部门收入起伏根因（MoM）	`dept_deepdive.py <本月目录> <上月目录>`	`_deepdive_<部门>.json`（总览/二级分类/班次/SKU涨跌含分类验真）
菜单/出品卖最差	`menu_onsale_ranking.py <月度目录>`	各部门在架SKU升序榜

_analysis_summary.json 的 employees 字段 = 12(13)人 (部门业绩/班次业绩/部门×班次业绩) 三元组，直接写 V2 cols 19/20/21。

🔴 必守口径（5月踩坑总结）

统一分类器重算两月：做 MoM 对比时，4月也要用同一分类器重算，不要拿4月预制xlsx对比5月自算（分类器漂移会造出假象，如"西湖咖啡-21%"实为持平）。dept_deepdive.py 已对两月用同一分类器。
幽灵汇总行：POS「订单明细」末尾有一行 订单来源/订单号/营业日期全='--' 的汇总行，金额=所有真实行之和，会让订单级字段翻倍2x。必须 if str(订单号).strip()=='--': continue（build_analysis 已修）。
dish级 vs 订单级：部门收入用「菜品明细」逐菜累加 菜品收入（元）（dish级）；订单级列受联台重复污染，勿用。
酒头/畅饮票=精酿：1-10酒头3小时畅饮票 等"酒头/畅饮"SKU 是扎啤生啤，归精酿（非调酒）。
部门×班次交叉：营收xlsx不自带，需 build_analysis 用菜品名匹配（≈95%）+ 按部门合计比例校正。滨江厨房团队(刘/叶/尹)班次=0、中班=0、前厅部门=0。
菜单"在架"口径：菜品库导出无「售卖状态」字段（在售/下架混在一起）。用"当月有售(≥1件)"作在架代理 → 下架季节菜自动排除。代价：漏掉"在架但真没人点"的极少数款。要100%精确需用户重导菜品库勾「售卖状态=售卖中」。
- 5月实测：西湖菜品库100款厨房菜→仅45在售；滨江138→45。菜单严重冗余，大量下架菜没从系统清理。

🟢 质量要求：跑完必做对抗式复核

每次营收分析跑完，用 Workflow 起多个 agent 独立重算 + 对抗验证（部门POS/班次/团购/交叉/环比各一路）。5月正是靠这个抓出 2 个真bug（幽灵行翻倍、酒头误归）。验真手法：每个涨跌SKU比对 cat_apr vs cat_may，一致=真实业务变化，不一致=重归类伪变动需剔除（cat='-' 表示该月无此SKU=新上/下架，属真实，非伪变动）。

输出去向

营收分析 13 sheets：总览/部门收入/团购→部门归口/班次营收/部门x班次/品类(一级,二级)/每日营收×2/支付方式/12员工业绩/深度分析/改进建议/部门起伏根因
出品分析：可加 sheet「西湖/滨江餐食卖最差(在架)」「出品优化建议(该砍清单)」
报告 md：大梦N月各部门营收起伏深度报告.md、大梦N月_菜单精简与出品优化建议.md

已知业务结论（5月，供下月对比基线）

双店本质夜间酒馆：晚班占 81-85%，20-23点占 57-61% 营收。
西湖=精酿+调酒双驱动酒吧店；滨江=精酿单极社区店。
白班餐食弱：西湖周末/节假日强(3.3x工作日)、滨江平(1.9x)、工作日白天日均仅¥160-190。
会员质量：西湖健康(会员客单>非会员)；滨江会员"次卡化"(纯咖啡会员单17%→33%，客单跌破非会员)。
断货可恢复≈¥13.9k/月（健力士黑啤两店同步断供最易救）。

🆕 伪菜品库法（6月起·解决新品归类）

问题：菜品库是某个月导出的静态快照，次月新上的 SKU（尤其精酿新酒款）不在库中 → 落到 dept_by_name 关键词兜底 → 归类不可靠。手敲关键词还有宽词误伤风险（"菜"/"面"/"饭"）。

取 菜品名称 → 菜品大类/菜品小类，同名多类时取出现次数最多的那组，输出成 菜品编码（SPUID） | 菜品名称 | 基础分类 三列即可被 load_menu() 读取。

注意：

同名多类是正常现象（如"深烘拿铁"既有 咖啡/经典 也有 经典咖啡），取众数即可，6月滨江有 11 个这类 SKU。
大类值会随店而异：滨江有 肉肉肉/无咖无醇/瓶罐精酿，西湖有 软饮/brunch轻食简餐/纯饮，dept_of_category() 里两店分支已覆盖。
美团团购套餐 类 SKU 在 POS 侧菜品收入为 0（核销记 0、钱在平台侧归口），is_teamgou_shell() 会跳过，不会重复。

🔍 团购/收银重复性审查（每月建议做一次）

老板会问"班次业绩是不是把团购和收银的重复算了"。审查三步：

支付方式汇总（店内订单明细→支付明细 sheet）：确认支付方式列表里没有"美团团购券"之类的平台支付方式。6月滨江只有微信/支付宝/会员卡/代金券/现金。
壳单实付：含 美团团购套餐 大类 SKU 的订单，其全渠道「顾客实付」应为 0（6月实测 3 笔全 0）→ 只算了平台一边 ✓
代金券：POS 侧计入顾客实付，平台归口时 teamgou_dept_split() 返回 None 明确跳过 → 只算了收银一边 ✓

易误判：会有一批订单「菜品收入=0 但有实付」（6月滨江 86 笔 5,455.60）——那是 「会员卡-卡余额消费」（储值卡买单，POS 记全额优惠、钱走卡余额），与团购无关。5月同样机制（21,667/207笔），环比可比，不要当成 bug。

5.9 KiB Raw Permalink Blame History Unescape Escape