7.8
以下是本次会议内容的整理、总结，以及后续需要推进的事项。
一、会议主要内容概述
本次会议主要围绕 Reference Data 模块的开发进展、Demo、数据迁移、Maker-Checker 工作流、Audit Log、测试覆盖率和后续 PO Demo 准备 展开。团队成员分别展示了不同 Reference Data 子模块的实现情况，并讨论了后续需要统一的设计和交付标准。‣
二、各模块 Demo 内容总结
Reference Data 通用能力
会议一开始明确了当前 Reference Data 模块需要支持的三个核心能力：
Draft 状态
• 用户新增或修改数据后，可以先保存为 Draft。
• Draft 不会立即进入主表，也不会直接被 Checker 审批。
• Maker 可以继续编辑 Draft，确认后再提交。
Audit Log
• 每次创建、修改、提交、审批、拒绝等操作都需要记录。
• Audit Log 中需要保存操作人、操作时间、动作类型、表名、记录 ID 等信息。
• 变更内容使用 JSONB 结构保存，只记录发生变化的字段，并包含 before / after 值。
与生产 Reference Data Master Table 同步
• 新系统需要能加载生产环境中的 Reference Data 主数据。
• 当前优先使用 Singapore 版本数据，如果找不到，再 fallback 到 Global 版本数据。‣
参数 / 国家 / Fee 等模块 Demo
团队展示了 Draft、Submit、Approve、History、Audit Log 等完整流程：
• 新增数据后先进入 Draft。
• Draft 可以反复编辑。
• 提交后进入 Pending。
• Checker 可以查看 Pending 数据并审批。
• 审批后才会进入主表。
• History / Audit Log 中可以查看每次变更的字段。
• 对于新增记录，Audit Log 会显示所有字段为新增。
• 对于修改记录，只显示实际发生变化的字段。
同时也确认了当前实现与生产数据结构的兼容性，尤其是 key1 / key2 / data1 / data2 等字段模式。‣
Booking Location 模块 Demo
Michael 展示了 Booking Location 模块的进展：
• 为了从 Persona / 生产库中找到对应的 Master Table，开发了一个自动化查询脚本。
• 脚本可以对多个 schema 和表进行 fuzzy search，并输出 Excel 结果，帮助识别最可能的源表。
• Booking Location 模块已经实现：
• 新增
• 修改
• Draft
• Pending
• Approve
• Audit Log
• 分页
• 搜索
• 排序
• 查看详情
当前还有一些问题和待完成项：
• Charge Tag / Customer Onboarding 相关的数据同步还未完成。
• 部分从生产导入的数据会因为 Currency 尚未审批而无法审批，需要进一步处理数据初始化或校验逻辑。
• Bunker Detail、Bank Holiday 等模块的数据同步仍在进行中。‣
Map Definition / Entry 模块 Demo
Ethan 展示了 Map Definition 模块的完整 Maker-Checker 流程：
• Maker 新增数据后保存为 Draft。
• Draft 可以继续编辑。
• 提交后进入 Pending。
• Checker 可以查看详情、Approve 或 Reject。
• Audit Log 会记录：
• 创建 Draft
• 更新 Draft
• Submit
• Approve
• Reject
• 每条 Audit Log 中只记录变化字段。
• 对于批量新增 Entry 的场景，系统会生成多条 Pending 记录，Checker 可以逐条审批或拒绝。
同时 Ethan 也展示了与旧系统表结构的兼容性分析报告，确认新表基本覆盖旧表字段，并说明部分字段存在命名或结构差异，后续迁移时需要转换。‣
测试覆盖率与 PR 检查
会议中还展示了测试覆盖率检查脚本：
• Backend 使用 JaCoCo。
• Frontend 使用 Playwright。
• 目标覆盖率为 80%。
• 脚本可以根据 Git diff 自动识别变更模块，并执行对应测试。
• 如果覆盖率低于 80%，应阻止 PR 或 Push。
• 后续需要将该机制标准化并应用到所有模块。‣
三、会议中的关键结论
Maker-Checker 流程必须统一
当前不同模块的 UI 和流程存在差异，例如有的模块展示 Draft / Pending / Rejected / Audit Log / Query Lookup，有的模块不完全一致。
会议明确要求：
• 所有 Reference Data 模块都要有一致的用户体验。
• 至少 Draft、Pending、Rejected、Audit Log 这些核心流程需要统一。
• 如果某些 tab 对某个模块不适用，可以讨论，但整体体验要尽量一致。
• Maker 和 Checker 角色需要与 User Profile 模块打通。‣
Audit Log UI 需要统一
Audit Log 不只是数据库记录，还需要在 UI 中可查看。
建议：
• 各模块都要有一致的 Audit Log 展示方式。
• 不一定展示所有字段，但核心字段要统一。
• 最好能清晰展示“哪些字段被修改了”，以及 before / after 值。
• JSONB 字段不适合直接给用户看，需要通过 UI 解析成人可读内容。‣
数据迁移优先迁移 Master Table
对于从旧系统迁移数据，会议中确认了当前优先级：
• 目前只需要迁移生产环境当前的 Master Data。
• 也就是主要迁移 TXRM / Master Table。
• 暂时不需要迁移旧系统的 History / Audit Log。
• 如果未来业务方明确要求查看旧系统历史记录，再考虑支持旧 Audit Log 的解析和展示。‣
新系统不会替代旧系统，而是并行运行
会议中澄清了系统上线后的定位：
• 当前 Reference Data 新系统的首要目标是支持 Bank Guarantee。
• 新系统不是为了完全替代现有生产系统。
• 上线后会与旧系统并行运行。
• 旧系统仍然保留，历史审计数据如果需要可以回旧系统查询。‣
下周需要准备 PO Demo
会议中多次提到，下周需要面向 PO 展示当前已完成的 Reference Data 模块。
PO Demo 的重点应包括：
• 已完成模块的完整流程。
• Maker-Checker 一致体验。
• Draft / Pending / Approve / Reject。
• Audit Log 展示。
• 使用真实或接近真实的生产数据，而不是随便构造的测试数据。
• 清理明显的测试数据，让 Demo 更贴近业务场景。 
四、后续需要做的事情
A. 流程和 UI 统一
统一 Maker-Checker 工作流
• 覆盖所有 Reference Data 模块。
• 标准流程应包括：Draft → Submit → Pending → Approve / Reject → Master。
• Rejected 后的处理方式也需要统一。
统一模块 Tab / 页面结构
• 建议统一包含：
• Draft
• Pending
• Rejected
• Audit Log
• Query / Lookup，如果适用
• 不适用的模块需要明确例外规则。
把流程建模到 Event Modeling Board
• 用于团队内部和后续业务方沟通。
• 避免不同人对 Maker-Checker 流程理解不一致。 
B. Audit Log 和 History 设计
统一 Audit Log 数据结构
• 使用 JSONB 保存变更字段。
• 只记录实际变化字段。
• 每个字段包含 before / after。
统一 Audit Log UI 展示
• 不直接展示原始 JSON。
• 展示人可读的字段变化。
• 各模块字段展示逻辑保持一致。
确认 Draft / Pending 数据存放方式
• 当前倾向存放在 History / Pending 表中。
• 但还需要团队进一步确认：
• Draft 是否放在 History 表；
• Audit Log 是否可同时承担部分历史记录功能；
• UI box 和 processing box 之间的职责边界。 
C. 数据同步和迁移
优先迁移 Singapore 数据
• 如果 Singapore schema 中找不到，再使用 Global schema。
• 这是当前确认的查找优先级。
只迁移当前 Master Data
• 暂不迁移旧系统 Audit / History。
• 除非未来 PO 或业务方明确要求。
继续完成各模块数据同步
• Booking Location：继续完成 Charge Tag / Customer Onboarding 相关同步。
• Bunker Detail、Bank Holiday：继续推进数据同步。
• 其他 Reference Data 模块也需要逐步加载真实数据。
处理导入数据校验问题
• 例如 Currency 尚未审批导致 Booking Location 无法审批的问题，需要设计初始化或 bypass 方案。 
D. User Profile / 权限
统一 Maker 和 Checker 角色
• 所有模块需要基于统一的 User Profile 权限。
• Maker 负责 Draft 和 Submit。
• Checker 负责 Approve / Reject。
对齐本地和 QA 环境的 User Profile 实现
• 本地环境使用本地数据库配置。
• QA / 生产类似环境可能集成 CSM module。
• 需要让本地数据配置尽可能接近测试环境。
获取 Functional Access / Data Access 数据
• 需要从 Global Security Schema 或 Persona 提供的数据中获取。
• 如果当前 zip 文件中没有数据，需要联系 Persona 获取。 
E. 测试和交付质量
测试覆盖率统一达到 80%
• Backend：JaCoCo。
• Frontend：Playwright。
• 覆盖率检查应纳入 PR 流程。
统一测试框架
• 前端和后端测试框架要标准化。
• 避免每个模块使用不同方案。
PR 检查脚本继续完善
• 自动识别变更模块。
• 自动运行对应测试。
• 覆盖率不达标时阻止合并。 
F. 部署和环境
准备下周可演示环境
• 当前还在等待环境资源。
• 需要尽快跟进环境可用性。
采用 trunk-based branching strategy
• 主干保持稳定。
• 准备发布时从主干切 release branch。
• 下周 Demo 前需要确保代码稳定。 
G. 开发环境 / VPN 问题
整理 VPN / Zscaler 问题清单
• 连接 VPN 时：
• 哪些系统可以访问；
• 哪些工具不能用，例如 GitHub、VS Code Extension、Copilot 等。
• 不连接 VPN 时：
• 哪些外部工具可以用；
• 哪些公司内部系统不能访问。
形成清晰列表后同步给 John
• 方便并行推动 IT / Support 解决。 
五、重点待办清单
六、简短结论
本次会议的核心结论是：Reference Data 模块功能方向已经基本明确，接下来重点不是继续各自做各自的功能，而是要统一流程、统一 UI、统一权限、加载真实数据，并为下周 PO Demo 做准备。
当前最关键的交付点是：
Maker-Checker 流程一致化；
Audit Log 展示一致化；
Master Data 迁移策略明确；
各模块用真实数据准备 Demo；
测试覆盖率和部署环境尽快稳定。
7.8
以下是本次会议内容的整理、总结，以及后续需要推进的事项。
一、会议主要内容概述
本次会议主要围绕 Reference Data 模块的开发进展、Demo、数据迁移、Maker-Checker 工作流、Audit Log、测试覆盖率和后续 PO Demo 准备 展开。团队成员分别展示了不同 Reference Data 子模块的实现情况，并讨论了后续需要统一的设计和交付标准。‣
二、各模块 Demo 内容总结
Reference Data 通用能力
会议一开始明确了当前 Reference Data 模块需要支持的三个核心能力：
Draft 状态
• 用户新增或修改数据后，可以先保存为 Draft。
• Draft 不会立即进入主表，也不会直接被 Checker 审批。
• Maker 可以继续编辑 Draft，确认后再提交。
Audit Log
• 每次创建、修改、提交、审批、拒绝等操作都需要记录。
• Audit Log 中需要保存操作人、操作时间、动作类型、表名、记录 ID 等信息。
• 变更内容使用 JSONB 结构保存，只记录发生变化的字段，并包含 before / after 值。
与生产 Reference Data Master Table 同步
• 新系统需要能加载生产环境中的 Reference Data 主数据。
• 当前优先使用 Singapore 版本数据，如果找不到，再 fallback 到 Global 版本数据。‣
参数 / 国家 / Fee 等模块 Demo
团队展示了 Draft、Submit、Approve、History、Audit Log 等完整流程：
• 新增数据后先进入 Draft。
• Draft 可以反复编辑。
• 提交后进入 Pending。
• Checker 可以查看 Pending 数据并审批。
• 审批后才会进入主表。
• History / Audit Log 中可以查看每次变更的字段。
• 对于新增记录，Audit Log 会显示所有字段为新增。
• 对于修改记录，只显示实际发生变化的字段。
同时也确认了当前实现与生产数据结构的兼容性，尤其是 key1 / key2 / data1 / data2 等字段模式。‣
Booking Location 模块 Demo
Michael 展示了 Booking Location 模块的进展：
• 为了从 Persona / 生产库中找到对应的 Master Table，开发了一个自动化查询脚本。
• 脚本可以对多个 schema 和表进行 fuzzy search，并输出 Excel 结果，帮助识别最可能的源表。
• Booking Location 模块已经实现：
• 新增
• 修改
• Draft
• Pending
• Approve
• Audit Log
• 分页
• 搜索
• 排序
• 查看详情
当前还有一些问题和待完成项：
• Charge Tag / Customer Onboarding 相关的数据同步还未完成。
• 部分从生产导入的数据会因为 Currency 尚未审批而无法审批，需要进一步处理数据初始化或校验逻辑。
• Bunker Detail、Bank Holiday 等模块的数据同步仍在进行中。‣
Map Definition / Entry 模块 Demo
Ethan 展示了 Map Definition 模块的完整 Maker-Checker 流程：
• Maker 新增数据后保存为 Draft。
• Draft 可以继续编辑。
• 提交后进入 Pending。
• Checker 可以查看详情、Approve 或 Reject。
• Audit Log 会记录：
• 创建 Draft
• 更新 Draft
• Submit
• Approve
• Reject
• 每条 Audit Log 中只记录变化字段。
• 对于批量新增 Entry 的场景，系统会生成多条 Pending 记录，Checker 可以逐条审批或拒绝。
同时 Ethan 也展示了与旧系统表结构的兼容性分析报告，确认新表基本覆盖旧表字段，并说明部分字段存在命名或结构差异，后续迁移时需要转换。‣
测试覆盖率与 PR 检查
会议中还展示了测试覆盖率检查脚本：
• Backend 使用 JaCoCo。
• Frontend 使用 Playwright。
• 目标覆盖率为 80%。
• 脚本可以根据 Git diff 自动识别变更模块，并执行对应测试。
• 如果覆盖率低于 80%，应阻止 PR 或 Push。
• 后续需要将该机制标准化并应用到所有模块。‣
三、会议中的关键结论
Maker-Checker 流程必须统一
当前不同模块的 UI 和流程存在差异，例如有的模块展示 Draft / Pending / Rejected / Audit Log / Query Lookup，有的模块不完全一致。
会议明确要求：
• 所有 Reference Data 模块都要有一致的用户体验。
• 至少 Draft、Pending、Rejected、Audit Log 这些核心流程需要统一。
• 如果某些 tab 对某个模块不适用，可以讨论，但整体体验要尽量一致。
• Maker 和 Checker 角色需要与 User Profile 模块打通。‣
Audit Log UI 需要统一
Audit Log 不只是数据库记录，还需要在 UI 中可查看。
建议：
• 各模块都要有一致的 Audit Log 展示方式。
• 不一定展示所有字段，但核心字段要统一。
• 最好能清晰展示“哪些字段被修改了”，以及 before / after 值。
• JSONB 字段不适合直接给用户看，需要通过 UI 解析成人可读内容。‣
数据迁移优先迁移 Master Table
对于从旧系统迁移数据，会议中确认了当前优先级：
• 目前只需要迁移生产环境当前的 Master Data。
• 也就是主要迁移 TXRM / Master Table。
• 暂时不需要迁移旧系统的 History / Audit Log。
• 如果未来业务方明确要求查看旧系统历史记录，再考虑支持旧 Audit Log 的解析和展示。‣
新系统不会替代旧系统，而是并行运行
会议中澄清了系统上线后的定位：
• 当前 Reference Data 新系统的首要目标是支持 Bank Guarantee。
• 新系统不是为了完全替代现有生产系统。
• 上线后会与旧系统并行运行。
• 旧系统仍然保留，历史审计数据如果需要可以回旧系统查询。‣
下周需要准备 PO Demo
会议中多次提到，下周需要面向 PO 展示当前已完成的 Reference Data 模块。
PO Demo 的重点应包括：
• 已完成模块的完整流程。
• Maker-Checker 一致体验。
• Draft / Pending / Approve / Reject。
• Audit Log 展示。
• 使用真实或接近真实的生产数据，而不是随便构造的测试数据。
• 清理明显的测试数据，让 Demo 更贴近业务场景。 
四、后续需要做的事情
A. 流程和 UI 统一
统一 Maker-Checker 工作流
• 覆盖所有 Reference Data 模块。
• 标准流程应包括：Draft → Submit → Pending → Approve / Reject → Master。
• Rejected 后的处理方式也需要统一。
统一模块 Tab / 页面结构
• 建议统一包含：
• Draft
• Pending
• Rejected
• Audit Log
• Query / Lookup，如果适用
• 不适用的模块需要明确例外规则。
把流程建模到 Event Modeling Board
• 用于团队内部和后续业务方沟通。
• 避免不同人对 Maker-Checker 流程理解不一致。 
B. Audit Log 和 History 设计
统一 Audit Log 数据结构
• 使用 JSONB 保存变更字段。
• 只记录实际变化字段。
• 每个字段包含 before / after。
统一 Audit Log UI 展示
• 不直接展示原始 JSON。
• 展示人可读的字段变化。
• 各模块字段展示逻辑保持一致。
确认 Draft / Pending 数据存放方式
• 当前倾向存放在 History / Pending 表中。
• 但还需要团队进一步确认：
• Draft 是否放在 History 表；
• Audit Log 是否可同时承担部分历史记录功能；
• UI box 和 processing box 之间的职责边界。 
C. 数据同步和迁移
优先迁移 Singapore 数据
• 如果 Singapore schema 中找不到，再使用 Global schema。
• 这是当前确认的查找优先级。
只迁移当前 Master Data
• 暂不迁移旧系统 Audit / History。
• 除非未来 PO 或业务方明确要求。
继续完成各模块数据同步
• Booking Location：继续完成 Charge Tag / Customer Onboarding 相关同步。
• Bunker Detail、Bank Holiday：继续推进数据同步。
• 其他 Reference Data 模块也需要逐步加载真实数据。
处理导入数据校验问题
• 例如 Currency 尚未审批导致 Booking Location 无法审批的问题，需要设计初始化或 bypass 方案。 
D. User Profile / 权限
统一 Maker 和 Checker 角色
• 所有模块需要基于统一的 User Profile 权限。
• Maker 负责 Draft 和 Submit。
• Checker 负责 Approve / Reject。
对齐本地和 QA 环境的 User Profile 实现
• 本地环境使用本地数据库配置。
• QA / 生产类似环境可能集成 CSM module。
• 需要让本地数据配置尽可能接近测试环境。
获取 Functional Access / Data Access 数据
• 需要从 Global Security Schema 或 Persona 提供的数据中获取。
• 如果当前 zip 文件中没有数据，需要联系 Persona 获取。 
E. 测试和交付质量
测试覆盖率统一达到 80%
• Backend：JaCoCo。
• Frontend：Playwright。
• 覆盖率检查应纳入 PR 流程。
统一测试框架
• 前端和后端测试框架要标准化。
• 避免每个模块使用不同方案。
PR 检查脚本继续完善
• 自动识别变更模块。
• 自动运行对应测试。
• 覆盖率不达标时阻止合并。 
F. 部署和环境
准备下周可演示环境
• 当前还在等待环境资源。
• 需要尽快跟进环境可用性。
采用 trunk-based branching strategy
• 主干保持稳定。
• 准备发布时从主干切 release branch。
• 下周 Demo 前需要确保代码稳定。 
G. 开发环境 / VPN 问题
整理 VPN / Zscaler 问题清单
• 连接 VPN 时：
• 哪些系统可以访问；
• 哪些工具不能用，例如 GitHub、VS Code Extension、Copilot 等。
• 不连接 VPN 时：
• 哪些外部工具可以用；
• 哪些公司内部系统不能访问。
形成清晰列表后同步给 John
• 方便并行推动 IT / Support 解决。 
五、重点待办清单
六、简短结论
本次会议的核心结论是：Reference Data 模块功能方向已经基本明确，接下来重点不是继续各自做各自的功能，而是要统一流程、统一 UI、统一权限、加载真实数据，并为下周 PO Demo 做准备。
当前最关键的交付点是：
Maker-Checker 流程一致化；
Audit Log 展示一致化；
Master Data 迁移策略明确；
各模块用真实数据准备 Demo；
测试覆盖率和部署环境尽快稳定。