先看这里:业务负责人确认清单
这些点最容易导致“系统没错,但业务口径错了”。建议业务负责人逐条确认。
一、外卖日报更新流程
每天 08:00 执行,从四个平台下载 14 份报表,清洗合并后上传飞书多维表。
业务目标
替代影刀日报链路,实现“下载报表 -> 验空 -> 分发 -> 清洗合并 -> 刷新 Excel -> 飞书同步 -> 清理源文件”。
日期规则
结束日期为昨天,开始日期为昨天往前 4 天,共连续 5 天。也可通过 WAIMAI_START / WAIMAI_END 临时覆盖。
完整性门槛
数据下载包 必须刚好 14 份已验证非空报表;不齐、多出、空表、HTML 登录页都会失败停止。
执行脚本
pipeline\run_daily_pipeline.ps1
| 平台 | 报表 | 关键业务规则 |
|---|---|---|
| 饿了么 / 淘宝闪购 | 门店下载、订单下载、商品下载、评价下载、商家成长 | 进入数据下载/报表下载;设置 5 天日期;全选字段;下载管理中取文件;空表最多重试 3 次。 |
| 京东到家 / 京东秒送 | 门店、订单、商品、订单评价 | 门店/订单/商品需要生成后去下载列表二次点击下载;订单评价走旧版评价管理,选择订单评价,导出后直接下载。 |
| 美团外卖 | 门店、订单、商品、评价 | 设置日期、全选字段、下载数据;弹窗点击前往下载;下载列表刷新到“下载”后取文件。 |
| 小匠人 / 渠道成本分析 | 渠道成本分析 | 确认左侧为 6.14 渠道成本分析,设置同一日期范围,直接导出。 |
飞书同步逻辑
- 刷新
外卖数据日更表(日).xlsx。 - 调用
upload_excel_new.py。 - 按
唯一键新增/更新。 - 当前日报配置
cover=false,正常日更不删除历史记录。
成功后清理
- 飞书上传成功后,清空本次分发进日数据存档处的源文件。
- Chrome 成功时关闭;失败时保留浏览器用于人工排查。
- 日志写入
out\pipeline_时间戳。
需要业务确认的日报口径
- 5 天日期范围是否始终适用于所有报表。
- 14 份报表是否是硬门槛,缺一份是否必须整流程失败。
- 飞书日报按唯一键新增/更新,不删除历史旧记录,这是否符合数据治理要求。
- 成功上传后删除日数据存档处本次源文件,是否满足审计留痕要求。
二、门店营业状态检查流程
一天多次检查三大平台门店营业状态,发现异常门店后截图并写入飞书。
业务目标
发现门店未按预期营业、休息、暂停、下线等状态,形成飞书异常记录,方便运营追踪。
执行脚本
pipeline\run_store_status_check.ps1run_store_status_check.mjs
输出位置
out\store_status\run_时间戳\summary.json 和异常截图。
飞书脚本
upload_shop_status.py
| 平台 | 读取方式 | 当前正常判定 |
|---|---|---|
| 美团 | 进入门店管理,状态筛选置为全部并查询,解析门店列表。 | 营业中、正常营业 |
| 京东 | 进入门店设置列表,读取表格营业状态,自动翻页。 | 营业中、正常营业 |
| 饿了么 | 打开门店切换器,从门店列表解析门店名称和状态。 | 营业中、正常营业;脚本当前也把饿了么 已打烊 视为正常状态。 |
需要业务确认的营业状态口径
- 美团、京东只有
营业中/正常营业视为正常,是否足够。 - 饿了么
已打烊当前视为正常,是否应按检查时段区分。 - 是否需要飞书记录全量门店状态,还是只记录异常门店。
- 检查时点 10:40、15:00、17:00、21:20 是否覆盖业务需要。
三、菜品异常检查流程
每天两次检查商品“已下架”和“已售罄”,记录异常菜品、截图并上传飞书。
业务目标
替代影刀商品异常检查,发现各平台门店中不该下架或售罄的菜品,形成飞书问题记录。
执行脚本
pipeline\run_product_abnormal_check.ps1run_product_abnormal_check.mjs
配置来源
product_abnormal_config.json 维护平台 URL、登录前缀和门店清单。
飞书脚本
upload_bad_product.py
| 平台 | 检查范围 | 关键细节 |
|---|---|---|
| 美团 | 当前可发现的美团门店;配置门店与页面门店交集。 | 切店后校验当前门店名;菜品名优先读取商品卡片 title / input value,避免把“单点不送”等标签当菜名。 |
| 京东 | 全部门店。 | 进入商家商品管理,抓取已下架商品;京东当前不逐店切换。 |
| 饿了么 | 配置中的 18 家门店。 | 必须先从连锁总账号切到具体门店,再进入 商品管理 -> 商品列表;不能停在菜单模板或连锁商品库。 |
记录内容
- 平台:美团 / 京东 / 饿了么。
- 门店名称。
- 检查时间。
- 问题概述:菜品名 + 下架/售罄。
- 问题类型:商品上下架异常。
- 异常截图。
验证结果口径
- 每个平台生成
summary.json。 - 记录每个门店的下架数、售罄数和上传结果。
- 任一门店检查失败或上传失败,平台状态为
partial_failed。 - 成功后 Chrome 自动关闭;失败时保留现场。
需要业务确认的菜品异常口径
- 所有
已下架、已售罄是否都算异常。 - 是否需要白名单:例如季节性菜品、临时停售、只套餐售卖、门店主动售罄。
- 同一菜品上午、下午重复异常是否要重复写入,还是只保留最新状态。
- 京东当前是全部门店口径,不逐店拆分,是否可接受。
- 美团门店数以页面实际可发现门店为准,缺失门店是否需要单独告警。
四、三套流程共用规则
这些是跨流程的稳定性、风控、日志和人工介入规则。
out 目录,不再堆桌面截图。| 流程 | 定时任务 | 主命令 | 成功标志 |
|---|---|---|---|
| 外卖日报更新 | 每天 08:00 | powershell -File .\pipeline\run_daily_pipeline.ps1 | 14 份报表齐全,workbook 刷新成功,飞书上传成功,临时源文件清理完成。 |
| 营业状态检查 | 10:40、15:00、17:00、21:20 | powershell -File .\pipeline\run_store_status_check.ps1 | 三平台门店状态读取成功,异常门店截图和飞书写入成功。 |
| 菜品异常检查 | 10:32、17:01 | powershell -File .\pipeline\run_product_abnormal_check.ps1 | 三平台商品异常读取成功,异常菜品截图和飞书写入成功。 |