# 07-07 报价系统需求评审与实体设计 - 会议记录 ## 基本信息 - 会议主题：报价系统 1.3.0 需求评审与实体设计讨论 - 音频文件：`07-07 报价系统需求评审与实体设计.mp3` - 字幕文件：`07-07 报价系统需求评审与实体设计.srt` - 音频时长：约 39 分 04 秒 - 字幕说明：字幕只有“发言人 1 / 2 / 3”，没有真实姓名。部分词语识别不准，本文按上下文修正为可读记录。 - 会议背景：项目 8 月要交付，时间较紧。会议主要逐条检查评论里的需求问题，并讨论报价系统的数据结构和功能取舍。 ## 一句话结论 本次先不写代码。先把报价系统的核心对象、字段、公式、数据关系、旧数据迁移规则写清楚，再评审设计。功能上删掉或隐藏一批用途不清的内容，重点保留报价项、报价单、汇率、工时、固定成本、系数、分成、合同下载等真正需要的部分。 ## 主要结论 1. 业务日志不做。系统日志只在出问题时给超级管理员查，报价相关的过程已有报价历程，不需要再做业务日志菜单。 2. 税项按钮隐藏。当前税项不参与计算，只做前端隐藏，防止误操作。 3. 系统费用也纳入分成结构。默认日本 0、南京 100，后续如需调整，可改成别的比例。 4. 汇率只有一个全局值，手动录入即可。暂不做自动抓取，也不做“按周/按月模式”。 5. 汇率取人民币兑日元，例子中提到当前约 23.83，按两位小数存。 6. 价格计算顺序为：先按工时、固定成本、系数等算出人民币价格，再乘汇率得到日元价格。最终取整沿用原规则。 7. 报价生成时要记录当时使用的汇率。后台后续改汇率，不影响已生成报价。若报价被退回后重新编辑或重新报价，则按当时最新汇率重新算。 8. 报价详情里要显示当次使用的汇率，便于销售解释不同月份报价为何不同。导出给客户的文件不需要展示汇率。 9. 每个报价项都应有公式，系统使用费也可以按工时和摊销逻辑进入公式。 10. CG / 制作单相关管理功能不做成报价系统里的独立功能。报价系统只需要能提供报价项和公式的输出接口。 11. 外部系统或 AI 要读取报价项、公式时，需要有权限校验。谁能调、凭什么调，要设计清楚。 12. 合同下载可以作为功能存在，但目前合同模板、合同字段、附件、输出格式都不明确，所以只能先保留位置，不能完整做。 13. 后台 UI 只要能用就不改。只有结构变更影响维护项时，才需要调整页面。 14. 核心对象先定为报价项和报价单。工时是报价项的属性，不是单独的核心对象。 15. 先出设计文档，再过设计。发言人 2 会改 PRD，把不做或隐藏的内容去掉。 ## 按时间整理 ### 00:00 - 01:08 开场与问题清单 - 会议一开始确认本次需求较急，8 月份要交付。 - 现有系统或机器已经放置了几个月，需要重新梳理当前状态。 - 发言人 1 打开需求评论，说明一共有十个左右的问题要过。 - 先从日志菜单开始看。 ### 01:08 - 04:28 业务日志 讨论内容： - 需求里写了“日志详情”，但没有写清楚详情里具体要展示什么。 - 当前已有系统日志。系统日志用于系统出问题时排查，只有超级管理员可见。 - 需求里另提到“业务日志”，大致指报价相关的操作记录，可能想给所有管理员看。 - 讨论时反复问了几个问题： - 谁会看业务日志？ - 看了之后要做什么？ - 管理员是否能看懂？ - 报价历程里是否已经有改价、审批等记录？ - 结论是业务日志没有明确用途。 - 后台实际使用者较少，可能只有改价的人、审批的人、CD 支付相关人员等，但这些人也不会专门去看业务日志。 - 如果只是查报错，应看系统日志，不应另做业务日志。 - 如果老板想看日方是否处理过，报价历程已经能看到。 结论： - 业务日志不做。 - 系统日志保留，但只在出问题时查。 - 报价相关的过程继续放在报价历程里。 ### 04:28 - 05:04 税项按钮 讨论内容： - 以前系统有税项相关按钮。 - 现在税项已经不参与计算，但后台按钮还在。 - 这个按钮留着容易误操作。 结论： - 税项按钮前端隐藏即可。 - 不需要改复杂逻辑，因为税项当前已经不参与计算。 ### 05:04 - 07:21 分成比例与系统费用 讨论内容： - 原来已有分成比例。 - 旧逻辑中部分模块参与分成，系统费用原本不在可修改项里。 - 会上提到此前有人说系统费用也要参与分成，也有人说老板后来讲不参与。 - 发言人 1 的处理想法是：把系统费用也放进分成结构里，但默认日本 0、南京 100。以后如果要变成例如 10 / 90，再改配置即可。 - 这个处理不会改变现有功能，只是把原本固定的逻辑暴露成可配置项。 结论： - 系统费用进入分成结构。 - 默认日本 0、南京 100。 - 后续如业务要求变化，可直接调整比例。 ### 07:21 - 09:54 汇率的计算位置、来源与精度 讨论内容： - 价格先按工时、固定成本、系数等规则计算，再乘汇率。 - 汇率是一个全局值，不会有多个汇率。 - 汇率不需要系统自动抓取。一个月改一次，人工打开日方认可的汇率来源，手动录入即可。 - 如以后想自动处理，可以单独做脚本或定时服务，定期写入汇率表，但这不是报价系统当前要做的功能。 - 汇率使用人民币兑日元。 - 会上举例当前人民币兑日元约为 23.83。 - 汇率保留两位小数。 - 最终价格的取整规则沿用旧规则，发言人 1 后续会把原规则整理到文档里。 结论： - 汇率是全局配置。 - 手动录入，暂不自动抓取。 - 使用人民币兑日元，保留两位小数。 - 最终取整沿用旧规则。 ### 09:54 - 11:20 旧数据迁移 讨论内容： - 旧的系数迁移不是产品功能，是技术处理。 - 因为新结构变化，旧数据需要转换。 - 这个事情不适合人工逐条处理，容易错。 - 应写数据迁移脚本。 - 脚本设计需要写清楚： - 原数据是什么； - 经过什么公式或算法； - 输出什么新数据； - 哪些字段来自旧逻辑； - 哪些字段是新结构需要补出来的。 结论： - 旧数据迁移用脚本处理。 - 迁移规则要作为技术设计的一部分写清楚。 ### 11:20 - 14:16 报价项字段、固定成本、系数与批量录入 讨论内容： - 价格项不是单纯一个固定价格。 - 固定成本、系数、工时都要分开设计。 - 每个报价项都可以有自己的固定成本和系数。 - 例子： - CG 项的固定成本可能是 100； - 开发项的固定成本可能是 220。 - 每一项都支持单独调整，但从操作上看，逐条录入会很麻烦。 - 因此需要有批量录入或批量修改的方法，例如同一类报价项先统一设成某个固定成本。 - 这个批量方法不一定要做成界面功能，可以是脚本、后台处理方法或其他内部工具。 结论： - 技术结构上固定成本、系数、工时要分开。 - 操作上要考虑批量设置方法。 - 批量设置不一定做成前台功能。 ### 14:16 - 16:06 汇率模式与系统职责 讨论内容： - 需求里出现了“汇率模式”，例如按周或按月。 - 会上认为不需要“汇率模式”这个概念。 - 系统只需要一个全局汇率。 - 汇率怎么来，不属于报价系统要处理的事。报价系统只接收汇率这个输入，并用于计算。 - 如果担心忘记每月录入，可以用脚本或定时服务补充，但这不是报价系统的主功能。 结论： - 删除“汇率模式”概念。 - 报价系统只保存和使用汇率，不负责抓取汇率。 ### 16:06 - 21:15 汇率快照、历史报价与重新编辑 讨论内容： - 问题：一个报价单四个月前创建，但一直没完成。后来汇率变了，是用旧汇率还是新汇率？ - 讨论后明确：报价按“生成或重新报价那一刻”的汇率计算。 - 如果第一次报价是在 1 月，用 1 月汇率；6 月重新报价，用 6 月汇率。即使报价项没变，价格也可能不同。 - 汇率表需要有 ID 和时间。 - 报价生成时保存当时使用的汇率 ID 或汇率值。 - 后台之后改汇率，不应影响已经保存的报价。 - 发言人 1 说明当前逻辑是在进入报价计算器、加载报价项时就已经计算并保存价格。 - 如果报价被退回并重新编辑，再进入计算器重新生成，则使用当下最新汇率。 结论： - 每次报价生成时使用当时最新汇率。 - 报价单保存当次使用的汇率。 - 历史报价不受后续汇率修改影响。 - 重新报价或被退回后重新编辑，应重新按当时汇率计算。 ### 21:15 - 22:41 汇率显示位置 讨论内容： - 当前前台没有显示汇率的地方。 - 销售可能需要知道两次报价为什么价格不同。 - 客户不需要知道汇率。 - 导出给客户的文件不需要展示汇率。 - 报价详情里需要找位置显示当次使用的汇率，给销售查看。 结论： - 报价详情显示汇率。 - 导出文件不显示汇率。 - 显示目的不是给客户看，而是给销售解释价格变化。 ### 22:41 - 24:08 工时与所有价格项 讨论内容： - 发言人 1 问是否所有价格都按工时来。 - 发言人 2 认为原则上所有价格都应能对应到工时和公式。 - 如果发现某个价格项不是按工时或公式来的，需要找马明杰确认原因。 - 可能有疑问的是系统使用费。 - 讨论后认为系统使用费也可以按公式计算，因为系统开发本身也消耗工时，只是费用如何摊到项目或月份上更复杂。 结论： - 每一个报价项都应有公式。 - 系统使用费也纳入公式体系。 - 系统费用的摊销逻辑可以另写清楚。 ### 24:08 - 27:34 CG / 制作单相关功能 讨论内容： - 字幕中此处出现“CT / CD / CG 管理”等识别差异，会议语义是制作单或制作管理相关功能。 - 发言人 1 提到新增管理项和后续下载、制作单等内容。 - 发言人 2 明确认为报价系统不需要做独立的制作管理功能。 - 报价系统只需要提供： - 所有报价项； - 每个报价项对应的公式； - 可供外部读取的输出接口。 - 后续如果排期、SOP 或 AI 需要这些数据，可以通过接口读取。 - 不需要在报价系统里做一个重的“制作单管理”页面。 - 如果外部系统或 AI 调用接口，需要考虑权限校验： - 谁能调用； - 为什么能调用； - 管理员如何授权； - 内部系统和外部系统调用都需要校验。 结论： - CG / 制作单管理不做成报价系统功能。 - 报价系统提供输出接口即可。 - 接口要设计权限校验。 ### 27:34 - 28:23 下载管理与合同下载 讨论内容： - CG 下载、制作单下载等不做。 - 合同下载不同，可能需要保留。 - 但当前合同模板没有提供。 - 发言人 1 问合同下载是只放一个模板，还是把项目信息预填进去。 - 发言人 2 判断，如果做合同功能，应当预填，否则意义不大。 - 由于模板和字段都没明确，目前合同需求不清楚。 结论： - CG 下载、制作单下载不做。 - 合同下载待确认。 - 未拿到合同模板前，不做完整合同下载逻辑。 ### 28:23 - 30:17 UI 是否要改 讨论内容： - 发言人 1 提到原 UI 问题。 - 会议判断：如果现有页面能用，就不改。 - 后台原来没有严格参照 UI，但后台使用者少，主要是内部人员或秦总，不需要为了好看重做。 - 只有维护项因结构变化必须调整时，才改对应页面。 - 前台页面可以另行考虑，但后台不做无必要的视觉调整。 结论： - 后台 UI 能用就不改。 - 结构变化影响的维护项可以改。 - 不为“好看”单独改后台。 ### 30:17 - 33:51 合同功能细节 讨论内容： - 合同需要确认是谁和谁签。 - 会上判断合同是“我们”和 Reno 之间的合同，不是客户和我们签。 - 合同与项目有关，因为不同项目金额不同。 - 合同至少会涉及： - 甲方、乙方； - 项目名称； - 合同金额； - 报价单或报价明细是否作为附件。 - 具体报价金额是写进合同正文，还是作为附件，还不知道。 - 当前能确定的是合同跟项目有关，应当有 project id。 - 合同问题需要再问邢总，因为没有模板时无法判断字段和格式。 - 如果将来拿到模板，需要考虑： - 模板以什么形式存储； - 模板是否会更新； - Word 模板能否直接放； - 占位符如何替换； - 项目信息、报价金额等如何写入； - 是否有附件； - 最终下载格式是 PDF、Word，还是其他文件。 - 文件格式大概率只会在 Word、PDF、Excel 里，不需要考虑太多类型。 结论： - 合同功能可以先保留位置，但不能完整开发。 - 合同一定跟项目有关。 - 需要合同模板和字段说明后，才能定具体生成方式。 - 前端入口可先不开放。 ### 33:51 - 35:02 本次开发顺序 讨论内容： - 发言人 1 总结本次主要是工时、汇率和结构调整，其他很多菜单或功能都不做。 - 发言人 2 强调：先不要写代码，也不要先改代码。 - 需要先明确技术设计： - 核心对象是什么； - 每个对象有哪些字段； - 对象之间是什么关系； - 哪些功能要删； - 哪些功能只是隐藏； - 哪些属于后续模板或接口问题。 结论： - 先出设计，再写代码。 - 本次把报价系统作为后续开发方式的练习：先写清楚设计，再动手。 ### 35:02 - 38:57 实体对象设计 讨论内容： - 发言人 2 追问核心实体对象到底是什么。 - 发言人 1 一开始说“工时”是对象。 - 发言人 2 和发言人 3 认为工时不是核心对象，而是报价项的属性。 - 一种设计思路： - 报价项是一张表； - 报价项里有名称、工时、系数、固定成本等字段； - 多个报价项组成报价单； - 报价项之间可能有上下级关系，可以用 parent id 表示。 - 发言人 3 提醒，不一定要把现有结构全部推翻。可以保留现有字段，再增加一张结构表或规则表，用来生成原来的价格字段。 - 当前最重要的是先识别清楚对象和关系，不一定立刻到数据库表设计。 - 发言人 2 最后明确：核心对象就是报价项和报价单。用户、账户等属于周边内容，不是本次价格结构的重点。 结论： - 核心对象：报价项、报价单。 - 工时是报价项属性，不是单独核心对象。 - 报价项可包含名称、工时、系数、固定成本等。 - 报价项可有父子关系。 - 多个报价项组成报价单。 - 可以保留旧字段，再用新结构生成旧字段，避免一次性大改。 ### 38:50 - 39:04 会后安排 - 发言人 1 先出设计。 - 设计完成后大家再过一遍。 - 发言人 2 会改 PRD，把不做、隐藏、待确认的内容改掉。 - 发言人 3 把自己记录的内容发出来。 ## 其他信息 - SOP 1.2.2 版本因为秋雨不在，还没有上线。 - 前面的手册，发言人 2 说会在当天写完。 - 这些内容不是本次报价系统设计的主线，但会影响后续文档和流程说明。 ## 待确认事项 1. 合同模板：需要拿到正式模板。 2. 合同字段：要确认合同正文里需要填哪些项目信息、报价金额、甲乙方信息。 3. 合同附件：要确认报价单或报价明细是否作为附件。 4. 合同输出格式：确认下载 Word、PDF，还是两者都要。 5. 合同模板存储方式：确认模板如何保存、更新、替换占位符。 6. 汇率来源：虽然系统不自动抓取，但需要明确人工录入时参考哪个日方认可来源。 7. 最终取整规则：发言人 1 需要把旧取整规则整理到文档。 8. 旧数据迁移公式：需要写清原数据、转换规则和输出字段。 9. 批量设置方法：固定成本、系数等是否通过脚本、后台方法或一次性处理完成。 10. 制作单数据读取方：如果后续由 AI、SOP 或排期工具读取报价项和公式，需要明确调用权限。 ## 会后要做的事 | 事项 | 负责人 | 说明 | | --- | --- | --- | | 输出技术设计 | 发言人 1 | 先写核心对象、字段、关系、公式、迁移规则，再评审。 | | 整理取整规则 | 发言人 1 | 把旧系统最终价格取整逻辑整理到文档。 | | 改 PRD | 发言人 2 | 删除或隐藏业务日志、税项按钮、制作单管理、下载管理等不做内容。 | | 确认合同模板 | 发言人 2 / 邢总 / 相关业务方 | 需要问清合同模板、字段、附件、输出格式。 | | 发会议记录 | 发言人 3 | 把会议中的个人记录发出来。 | | 设计评审 | 三位参会人 | 发言人 1 的设计写完后再过一遍。 | ## 功能处理清单 | 功能或问题 | 本次处理 | | --- | --- | | 业务日志 | 不做。 | | 系统日志 | 保留，只用于问题排查。 | | 报价历程 | 保留，继续承载改价、审批等过程记录。 | | 税项按钮 | 前端隐藏。 | | 系统费用分成 | 纳入分成结构，默认日本 0、南京 100。 | | 汇率模式 | 不做，不区分按周或按月模式。 | | 汇率录入 | 全局一个值，手动录入。 | | 汇率自动抓取 | 不做在报价系统里；以后可单独脚本处理。 | | 汇率显示 | 报价详情显示，导出文件不显示。 | | 旧数据迁移 | 写脚本处理。 | | 批量设置固定成本和系数 | 需要方法，不一定做页面。 | | CG / 制作单管理 | 不做成报价系统功能。 | | 报价项和公式输出接口 | 要做或预留，用于外部读取。 | | 接口权限校验 | 要设计。 | | 合同下载 | 可保留位置，待模板和字段确认。 | | 后台 UI 重做 | 不做。 | | 维护项 UI | 如结构变化影响使用，则调整。 | ## 报价计算与数据规则草稿 ### 汇率 - 系统中只有一个当前全局汇率。 - 汇率按人民币兑日元记录。 - 汇率保留两位小数。 - 汇率表应记录 ID、汇率值、录入时间。 - 报价生成时取当时最新汇率。 - 报价保存时记录当次使用的汇率 ID 或汇率值。 - 历史报价不因后台汇率修改而变化。 - 重新报价时按当时最新汇率重新计算。 ### 报价项 - 报价项是核心对象。 - 报价项字段可包含： - 名称； - 工时； - 固定成本； - 系数； - 分成比例； - 父级报价项 ID； - 公式； - 其他需要保留的旧字段。 - 工时、固定成本、系数是报价项属性，不是单独核心对象。 - 报价项之间可有上下级关系。 ### 报价单 - 报价单由多个报价项组成。 - 报价单保存生成时的价格、汇率、报价项信息。 - 报价单详情需要能查看当次使用的汇率。 - 给客户的导出文件不展示汇率。 ### 分成 - 系统费用也作为可配置分成项。 - 默认日本 0、南京 100。 - 后续可按实际要求改比例。 ### 迁移 - 旧数据迁移不手工逐条改。 - 迁移脚本需要写清楚旧字段如何变成新字段。 - 对旧价格字段，可考虑保留旧结构，再用新规则表生成，降低一次性大改带来的风险。