WuYongJie/CaiWuXiTong
1
0
Fork 0
Code Issues Pull Requests 2 Packages Projects Releases Wiki Activity

店铺维度报表销量改取业绩明细的订单实付/实收金额 #363

Merged
DoDo merged 1 commits from feature/dodo-store-report-sales-paid into main 2026-10-17 00:19:10 +08:00
Conversation 0 Commits 1 Files Changed 12 +477 -27
DoDo commented 2026-10-17 00:18:18 +08:00
Collaborator
Copy Link

任务占用与边界

  • 任务名称：店铺维度报表销量改取业绩明细的「订单实付/实收金额」
  • 实际开发者：dodo（Codex 执行）
  • 目标结果：店铺维度报表的销量（期间销量、1–12 月销量）改为业绩明细的订单实付/实收金额，按「店铺名称 + 发生时间」汇总后与店铺主体生效/失效时间关联
  • 预计修改路径：modules/EcommerceFinance/Repositories/StoreReportRepository.php、modules/EcommerceFinance/Services/StoreReportMirrorSynchronizer.php、app/Console/Commands/SyncStoreReportMirror.php、app/Console/Commands/SyncStoreReceiptOrderMatches.php、config/business_navigation.php、config/business_data.php、新增迁移与命令
  • 将写入的公共契约：新镜像表 store_report_paid_sales_rows、新数据集键 store-report.paid-sales、store_report_import_states.source_fingerprint 列、新命令 business-mirror:sync-store-report-paid-sales
  • 仅复用、明确不修改：店铺主体期间（StoreReportPeriodBuilder、ops_fys_shop_info）、平台账单日汇总（store_report_daily_rows）、业绩明细表本身（store_receipt_order_match_rows 只读）
  • 明确不修改的范围：主体维度经营报表的收入口径（仍读账单日汇总）、业绩明细页面本身

实际改动

  1. 新增镜像表 store_report_paid_sales_rows（迁移 2026_10_16_234000_create_store_report_paid_sales_rows.php）：业绩明细按「店铺名称 + 发生日期」预汇总一行（订单实付合计、订单数）；同时给 store_report_import_states 增加 source_fingerprint 列。
  2. StoreReportRepository：销量（period_sales、sales_01..12）改读该汇总表，仍按店铺名匹配期间、按发生日期落在 [生效时间, 失效时间] 内；收入（rolling_12m_income、income_01..12，主体维度经营报表使用）保持读平台账单日汇总，两个口径分开统计。
  3. StoreReportMirrorSynchronizer::syncPaidSales()：用「行数 + 最近写入时间 + 订单实付合计」指纹判断业绩明细是否变化，变化才全量重建（约 57 万行 → 约 1.4 万行），未变化沿用当前版本；版本切换成功后才清理上一版。
  4. 新命令 business-mirror:sync-store-report-paid-sales（--force 可强制重建），并把它并入 business-mirror:sync-store-report 的输出；store-receipt:order-match:sync 成功后自动刷新一次（失败只提示，不影响业绩明细写入）。
  5. 页面说明与「店铺维度报表逻辑配置」规则文本同步（新增 R9 销量口径）。

数据核对（生产镜像，2026-08 账期）

  • 业绩明细 8 月共 422 个店铺、订单实付合计 44,963,438.93（与业绩明细页面「订单实付金额合计」一致）；
  • 按 ops_fys_shop_info.erpShopName 匹配店铺名：422 个店铺中 414 个匹配成功，未匹配 8 个（合计 2.03 万元，其中 2 个真实店铺「拼多多-索菲亚实木家具旗舰店（作废）」「京喜-序木家居京喜自营工厂店」，其余为无实付金额的「支付宝-*」账户行）；
  • 7 月同为 428 个店铺、10 个未匹配。

验证

  • StoreReportRepositoryTest、StoreReportRepositoryFilterTest、StoreReportMirrorSyncTest：23 个用例、110 个断言全部通过（含销量取订单实付、收入取账单汇总的区分用例、汇总表指纹重建/跳过用例、数据集未就绪时报错用例）。
  • PrototypePageTest、ManagementCrudTest、PagesTest、UpstreamBusinessInformationTest：与未改动 origin/main 基线一致（同样 3 个既有失败：抖音账户账单文案、库存报表回退、导出 buffer 提示），本改动未引入新失败。
  • 全量 Unit 套件 620 个用例：3 个失败与基线完全一致（LocalStaticAssetsTest、AccountLedgerRemarkMapTest、BusinessDataPlacementTest，均为既有环境/断言漂移）。

数据库与配置影响

  • 涉及共享镜像建表与新增列：store_report_paid_sales_rows、store_report_import_states.source_fingerprint（迁移均为存在性判断，可重复执行）。
  • 首次需执行 business-mirror:sync-store-report-paid-sales 生成销量汇总版本；业绩明细没有某个月份时，该月销量为 0 并按既有「无业绩月份列默认隐藏」规则隐藏。
  • 不涉及金额写入、权限变更；不修改业绩明细与账单原始数据。

需要留意的协调项

  • origin/feature/limeng-stock-quote-entry（未合并）同时修改了 app/Console/Commands/SyncStoreReceiptOrderMatches.php 与 config/business_navigation.php，其中包含把业绩明细 store_name 从「线上真实店铺」改回账单店铺名的改动。若该分支先合并，业绩明细的店铺名口径会变化，销量按 erpShopName 的匹配率需重新核对。
## 任务占用与边界 - 任务名称：店铺维度报表销量改取业绩明细的「订单实付/实收金额」 - 实际开发者：dodo（Codex 执行） - 目标结果：店铺维度报表的销量（期间销量、1–12 月销量）改为业绩明细的订单实付/实收金额，按「店铺名称 + 发生时间」汇总后与店铺主体生效/失效时间关联 - 预计修改路径：`modules/EcommerceFinance/Repositories/StoreReportRepository.php`、`modules/EcommerceFinance/Services/StoreReportMirrorSynchronizer.php`、`app/Console/Commands/SyncStoreReportMirror.php`、`app/Console/Commands/SyncStoreReceiptOrderMatches.php`、`config/business_navigation.php`、`config/business_data.php`、新增迁移与命令 - 将写入的公共契约：新镜像表 `store_report_paid_sales_rows`、新数据集键 `store-report.paid-sales`、`store_report_import_states.source_fingerprint` 列、新命令 `business-mirror:sync-store-report-paid-sales` - 仅复用、明确不修改：店铺主体期间（`StoreReportPeriodBuilder`、`ops_fys_shop_info`）、平台账单日汇总（`store_report_daily_rows`）、业绩明细表本身（`store_receipt_order_match_rows` 只读） - 明确不修改的范围：主体维度经营报表的收入口径（仍读账单日汇总）、业绩明细页面本身 ## 实际改动 1. **新增镜像表 `store_report_paid_sales_rows`**（迁移 `2026_10_16_234000_create_store_report_paid_sales_rows.php`）：业绩明细按「店铺名称 + 发生日期」预汇总一行（订单实付合计、订单数）；同时给 `store_report_import_states` 增加 `source_fingerprint` 列。 2. **`StoreReportRepository`**：销量（`period_sales`、`sales_01..12`）改读该汇总表，仍按店铺名匹配期间、按发生日期落在 `[生效时间, 失效时间]` 内；收入（`rolling_12m_income`、`income_01..12`，主体维度经营报表使用）保持读平台账单日汇总，两个口径分开统计。 3. **`StoreReportMirrorSynchronizer::syncPaidSales()`**：用「行数 + 最近写入时间 + 订单实付合计」指纹判断业绩明细是否变化，变化才全量重建（约 57 万行 → 约 1.4 万行），未变化沿用当前版本；版本切换成功后才清理上一版。 4. **新命令 `business-mirror:sync-store-report-paid-sales`**（`--force` 可强制重建），并把它并入 `business-mirror:sync-store-report` 的输出；`store-receipt:order-match:sync` 成功后自动刷新一次（失败只提示，不影响业绩明细写入）。 5. 页面说明与「店铺维度报表逻辑配置」规则文本同步（新增 R9 销量口径）。 ## 数据核对（生产镜像，2026-08 账期） - 业绩明细 8 月共 422 个店铺、订单实付合计 **44,963,438.93**（与业绩明细页面「订单实付金额合计」一致）； - 按 `ops_fys_shop_info.erpShopName` 匹配店铺名：422 个店铺中 **414 个匹配成功**，未匹配 8 个（合计 2.03 万元，其中 2 个真实店铺「拼多多-索菲亚实木家具旗舰店（作废）」「京喜-序木家居京喜自营工厂店」，其余为无实付金额的「支付宝-*」账户行）； - 7 月同为 428 个店铺、10 个未匹配。 ## 验证 - `StoreReportRepositoryTest`、`StoreReportRepositoryFilterTest`、`StoreReportMirrorSyncTest`：**23 个用例、110 个断言全部通过**（含销量取订单实付、收入取账单汇总的区分用例、汇总表指纹重建/跳过用例、数据集未就绪时报错用例）。 - `PrototypePageTest`、`ManagementCrudTest`、`PagesTest`、`UpstreamBusinessInformationTest`：与未改动 `origin/main` 基线一致（同样 3 个既有失败：抖音账户账单文案、库存报表回退、导出 buffer 提示），本改动未引入新失败。 - 全量 Unit 套件 620 个用例：3 个失败与基线完全一致（LocalStaticAssetsTest、AccountLedgerRemarkMapTest、BusinessDataPlacementTest，均为既有环境/断言漂移）。 ## 数据库与配置影响 - 涉及共享镜像建表与新增列：`store_report_paid_sales_rows`、`store_report_import_states.source_fingerprint`（迁移均为存在性判断，可重复执行）。 - 首次需执行 `business-mirror:sync-store-report-paid-sales` 生成销量汇总版本；业绩明细没有某个月份时，该月销量为 0 并按既有「无业绩月份列默认隐藏」规则隐藏。 - 不涉及金额写入、权限变更；不修改业绩明细与账单原始数据。 ## 需要留意的协调项 - `origin/feature/limeng-stock-quote-entry`（未合并）同时修改了 `app/Console/Commands/SyncStoreReceiptOrderMatches.php` 与 `config/business_navigation.php`，其中包含把业绩明细 `store_name` 从「线上真实店铺」改回账单店铺名的改动。若该分支先合并，业绩明细的店铺名口径会变化，销量按 `erpShopName` 的匹配率需重新核对。
DoDo added 1 commit 2026-10-17 00:18:18 +08:00 
店铺维度报表（店铺管理 → 店铺维度报表）的销量原来按平台账单收入汇总，改为按
业绩明细（店铺收款匹配订单明细）的「订单实付/实收金额」汇总：

- 新增镜像表 store_report_paid_sales_rows：业绩明细按「店铺名称 + 发生时间」
  预汇总，页面按发生日期与主体生效/失效时间关联，拆分到对应主体期间；
- StoreReportRepository 的销量（period_sales / sales_NN）改读该汇总表，
  收入（rolling_12m_income / income_NN，主体维度经营报表用）仍读平台账单日汇总，
  两个口径分开统计、互不覆盖；
- StoreReportMirrorSynchronizer 增加 syncPaidSales()：用「行数 + 最近写入时间 +
  订单实付合计」指纹判断业绩明细是否变化，变化才全量重建，未变化沿用当前版本；
- 新增命令 business-mirror:sync-store-report-paid-sales（含 --force），并在
  store-receipt:order-match:sync 成功后自动刷新一次。

验证：StoreReportRepositoryTest / StoreReportRepositoryFilterTest /
StoreReportMirrorSyncTest 共 23 个用例、110 个断言通过。
DoDo merged commit 82c79dadc3 into main 2026-10-17 00:19:10 +08:00
DoDo deleted branch feature/dodo-store-report-sales-paid 2026-10-17 00:19:11 +08:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aaron chenxi DoDo jj404877757 limeng qiuxiang renshen shanshi sumu wangshu yueyang yutu zhoushengchen WuYongJie
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: WuYongJie/CaiWuXiTong#363
No description provided.
Delete Branch "feature/dodo-store-report-sales-paid"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?