52 lines
5.4 KiB
Markdown
52 lines
5.4 KiB
Markdown
# 项目协作与记忆
|
||
|
||
本文件记录用户已确认的需求和有来源的项目事实。业务数据与运行配置可能变化，后续任务应核对当前源码、运行环境及数据库。
|
||
|
||
## 项目入口
|
||
|
||
- 当前目录为 Java 后端，采用 Maven 多模块，服务入口为 `yudao-server`。
|
||
- PC 管理端位于相邻的 `Friendship-and-chat-pc`。会员列表入口为 `src/views/member/user/index.vue`，会员详情为 `src/views/member/user/detail/index.vue`。
|
||
- 当前 H5 源码位于相邻的 `Friendship-and-chat-uniapp`。福利中心为 `src/pages/wechat-tabbar/index.vue`，我的团队为 `src/pages/wechat/pages/inviter/index.vue`。
|
||
- 分销业务主要位于 `yudao-module-mall/yudao-module-trade-biz`。会员管理通过 `trade-api` 复用分销查询。
|
||
- 数据库连接与实际启用的 profile 从项目配置和运行进程核对。H5 的开发 API 地址可能使用隧道，需确认其最终服务。
|
||
|
||
## 已确认的分销口径
|
||
|
||
- `member_user.id` 是内部会员编号，`user_code` 是 App 展示 ID。关联和贡献查询使用内部编号。
|
||
- `trade_brokerage_record.user_id` 是佣金收益人，`source_user_id` 是产生佣金的来源会员，`source_user_level` 保存当时的推广层级。
|
||
- 管理端“分销收益”累计已结算的有效推广佣金和会员佣金。提现操作保留累计收益金额，待结算金额单独展示。
|
||
- “为当前会员贡献”按该来源会员本人给详情根会员产生的佣金计算。多层展开时 `contributionUserId` 固定为详情根会员编号。
|
||
- 累计收益统一复用 `BrokerageIncomeSql` 的有效佣金条件。当前条件包含类型 1、2，正金额，以及标题和说明中的提现文本过滤。
|
||
- 状态 0 为待结算，1 为已结算，2 为已取消。历史数据曾使用不同的业务类型映射，核账时同时检查金额方向、标题、说明和时间。
|
||
- `trade_brokerage_user.brokerage_price` 是独立维护的可用佣金余额，`frozen_price` 是冻结余额。余额与累计收益分别核账。
|
||
- `trade_brokerage_record.total_price` 是构建流水时读取的余额快照，应结合实际写入顺序核对其时点。
|
||
- 后台累计金额使用 `Long`，单位为分。前端需支持超出 JavaScript 安全整数后返回的字符串金额，使用 `brokeragePriceToYuan` 精确显示。
|
||
|
||
## 团队与页面行为
|
||
|
||
- 一级关系来自 `trade_brokerage_user.bind_user_id`，二级为一级会员的直属下级。
|
||
- 后台关系树每个分支每次加载 20 人，接口的 `total` 表示该分支完整人数。已加载节点数随展开及“加载更多”变化。
|
||
- H5 团队汇总、H5 团队分页和后台关系树应分别核对。资料缺失处理、昵称搜索、排序和分页可能影响当前展示的列表。
|
||
- 会员列表的分销收益金额可点击，进入对应会员的 `?tab=brokerage` 详情页。详情使用 `onActivated` 处理缓存页再次进入。
|
||
- 金额区间筛选在数据库分页前完成，列表和导出共用 `MemberUserMapper.buildUserQuery`。
|
||
- 新查询复用现有租户组件，并核对实际开关。相关子查询使用 `(SELECT COALESCE(SUM(...), 0) FROM ...)` 结构，已有测试验证该结构可被租户插件正确处理。
|
||
|
||
## 协作与验证
|
||
|
||
- 数据库操作遵循用户当次授权。本次用户 300 的金额与团队排查采用只读事务。
|
||
- 从配置读取连接凭据时避免在输出、文档和记忆中保存密码或令牌。
|
||
- 工作区经常存在并行任务，编辑前查看当前差异并保留其他任务的修改。
|
||
- Maven 验证可使用 `-Dflatten.skip=true`，避免构建过程改写项目 POM。
|
||
- 现有回归入口包括 `BrokerageIncomeQueryTest`、`MemberUserMapperTest`、`MemberUserBrokerageControllerTest`，以及 PC 端的 `tests/member-user-brokerage.test.cjs` 和 `tests/brokerage-record-list.test.cjs`。
|
||
- 测试、构建、页面核验及部署分别记录实际结果。数据库历史余额的来源需要对应流水、迁移记录或备份证据。
|
||
|
||
## 2026-11-11 用户 300 的只读对账快照
|
||
|
||
- 运行 `dev` 数据库中，会员内部编号 300，展示 ID 999827。H5 福利中心实际展示同一展示 ID。
|
||
- 可用佣金为 20841 分，冻结为 0。现存佣金流水含已删除记录一起核查后，只有一笔 3510 分的已结算会员佣金，流水编号 15，来源会员 465，创建于 2026-11-02 18:39:32。提现表无该会员记录。
|
||
- 流水 15 的 `total_price` 为 17331 分，结合转换器及先写流水后更新余额的顺序，表示这笔佣金写入前的余额。17331 + 3510 = 20841，历史底数的原始入账流水尚未在当前库中找到。
|
||
- 会员资料创建于 2026-11-01，`tenant_id=0`。分销余额及绑定关系创建于 2025-09-30，`tenant_id=1`。本次运行配置关闭租户隔离，历史数据归属及导入过程需要单独核实。
|
||
- 该会员一级 43 人、二级 13 人，全部会员资料有效。后台初次加载一级 20 人，加载完整后为 43 人。13 个二级会员均挂在一级会员 374 下，该一级节点按后台 ID 倒序位于第 30 位，需要加载更多后展开。
|
||
- H5 福利中心“累计收益”当时绑定提现合计 `withdrawPrice`。团队页的金额当时直接显示分值为元，单数字段读取 `orderCount`，接口实际返回 `brokerageOrderCount`。团队行金额查询当时仅统计该下级自身的已结算订单佣金。
|
||
- 上述为带日期的排查事实，后续修复与数据变化以当前实现及重新核账为准。
|