# 全局经营概览：从异常数字到当日经营盘面

2026-09-29 · 用户反馈驱动的原型设计修订。只调整全局概览及其合成来源，不改变确认/取消/资金规则，不代表生产数据或完整经营BI。

## 页面职责

回答“这个配送日，要服务谁，货准备好没有，工作集中在哪”。原来的深色8项异常不能回答经营问题，因此取消其视觉中心地位。保留暖纸和深墨语言，让明暗区分业务意群，不让数字大小代替信息价值。

1. **客户与履约（深色主区）**：已确认与未确认并列；人数是概括，客户、单数、送达时刻/截止才是构成。加急同步标在具体客户行，不必滑到页尾才能发现。
2. **当日备货（浅色并列区）**：猪肉到店状态、预计/实际接收、数量、质量依据；到店与放行不是同一件事。缺来源显示待核实，不显示未到或零公斤。
3. **配送时段（第二行主要区）**：每个明确时刻的单数和客户，条长是相对该日最大时段的订单数，不是容量利用率。未确认不摊入任何时段。
4. **小区落点（第二行辅助区）**：已确认订单覆盖小区及人数/单数，展开可查安排。按订单地址快照，不使用可能已经改变的默认地址。
5. **优先调度（窄条）**：加急对象和具体送达时刻；合成加急来自明确调度标记，不从收费金额或提前量猜测，不代表批准了收费政策。

其他跨日资金、渠道和数据异常折叠在末尾，展开列出全部原对象；不删除问题，但不把它们当作今日履约人数。只读概览不会触发确认、扣款、退款或配送。

## 统计口径与来源

| 信息 | 口径 / 来源 | 缺失或冲突 |
| --- | --- | --- |
| 配送日 | 页面日期选择，默认演示时钟的北京时间日期 | 切换只读视图，不推进时钟或到期任务 |
| 确认履约 | 当日accepted安排且对应订单open；客户ID去重，另显示单数 | 不等于实际已送达；未接交付证明前不报真实完成人数 |
| 尚未确认 | 当日pending安排且对应订单open；客户去重 | 与已确认组可共享客户，页面说明不应两数相加当总人数 |
| 小区 | 当日已确认订单trade.community稳定ID及地址快照 | 缺快照单独注明，不以姓名/地址字符串推断 |
| 时段 | 明确expectedTime或该安排已保存的送达字段 | 无合法HH:mm进入“时间待核实”，不擅自平均分配 |
| 猪肉到店 | 接收记录arrival.date/category与已接收事实 | 没有带日期记录不等于没有到货；质量从关联物料状态单独读 |
| 加急 | 明确expedited=true的已确认安排 | 缺标记单列待核实，不能当普通单；不是配送费依据 |
| 缺来源 | 缺日期、订单越界/缺失、重复有效确认范围 | 排除受影响安排并显示缺口，不双计或越权反查 |

所有查询先应用当前授权范围，详情链接回同一记录。businessStep改变确认/订单事实后，盘面重新计算，不维护第二套可写计数。

## 合成资料与旧记录

在design-source.py中追加5组当日订单/确认及1份当日猪肉接收/物料样例，明确synthetic。复用已有客户身份；没有独立的Dashboard数字表。初始场景含3位已确认客户/4单、2位尚未确认客户/2单，两组客户重叠；3个小区、17:00与17:30各1单、18:00有2单、1单明确调度加急。猪肉样例预计07:30、实际07:26接收80kg，物料已放行。

这些只是设计场景，不是商户真实经营数字。catalog重新生成后，新会话读取新增样例；旧localStorage不自动注入或覆盖新事实，用户可备份后明确重置。旧资料缺新字段时保留待核实表达。

## 验证与不足

verify-overview.mjs覆盖8组投影反例：人数去重、时段/加急、日期隔离、区域限制、缺元数据、重复有效授权、确认后的动态变化、到货来源。浏览器检查全部范围、城北缺到货来源、次日空态与390px无横向溢出；桌面与手机截图均为隔离会话合成数据。

本轮还没有实际送达人数、运力容量/超载判断、跨店备货汇总和高数据量分页。不能把条形图读成负荷率，也不能把确认人数读成已配送完成。旧合成样例量小；下一轮规模压力需要补长名单截断、按时段展开及聚合钻取，不用当前小样本证明全天大屏已完善。

设计维护：主会话。业务规则仍来自架构事实源；没有提交、推送、清空用户记录或连接真实经营服务。