构建用于管理供应商价目表与合同的 Web 应用

应用要解决的问题（以及为谁服务）

大多数供应商定价与合同的混乱看起来都差不多：价目表散落在邮件里的电子表格中，“final_FINAL” 的 PDF 存在共享盘里，但没人确定哪些条款是当前有效的。结果是可预见的——订单使用过期价格、与供应商出现可避免的争议、以及错过续约通知。

需要解决的业务问题

一个好的 Web 应用应该集中管理 供应商价目表 和 合同 的事实来源，并使变更可端到端追溯。它应减少：

• 在电子表格、ERP 与收件箱之间的手工复制
• 因版本过期导致的定价错误
• 错过续约与通知期
• 寻找最新签署文件或修订所花费的时间

应用面向的人群

按每周接触定价与条款的人来设计系统：

• 采购：导入价目表、协商更新、跟踪生效日期
• 财务/应付：验证发票价格、核对货币、单位、税费
• 法务/合规：存储签署协议、修订与必需条款
• 审批人（管理层）：审查并批准价格/条款变更
• 管理员：管理用户、角色、供应商主数据、模板

衡量成功的指标

尽早选几个可衡量目标：

• 发布价格更新所需时间（例如从 2 天降到 2 小时）
• 导入错误率 与 每次上传需要的手工更正次数
• 续约提醒命中率（例如：在通知截止前发送提醒的合同占比）
• 价格差异率（发票/采购订单因价格有效性引起的不匹配）

什么叫“完成”：首版 vs 后续

首版目标是实现供应商记录集中、价目表导入与校验、合同存档并记录关键日期、基础审批、搜索与审计轨迹。

后续迭代可加入更深的 ERP 集成、条款库、自动发票匹配、多实体组织支持与高级报表面板。

需求与工作流映射

在画界面或表格之前，先把从供应商发送价目表到有人按该价下单的真实流程画出来。这能防止把系统做成通用的“文档仓库”，而实际上需要一个受控的定价系统。

绘制当前工作流（现状）

先与采购、财务和法务一起走一遍真实示例，记录每一步的移交与产出物：

• 接收价目表（邮件、门户、电子表格、EDI）→ 记录接收日期与来源
• 审核与谈判 → 记录问题、还价与达成的变更
• 批准价格与条款 → 识别决策点与需签字的角色
• 签署并存档合同文件 → 将条款与生效的价目表关联
• 执行与续约 → 监控到期、价格变更与例外情况

一个简单的泳道图（供应商 → 采购 → 法务 → 财务 → 运营）通常就足够了。

识别关键决策与角色（谁能做什么）

列出会改变业务结果的决策并分配明确责任：

• 谁能批准新的价目表 vs. 合同修订？
• 谁能编辑定价字段（货币、单位、MOQ、交期），谁只能提出变更请求？
• 谁能查看敏感合同条款（付款条款、责任条款），谁应受限？

同时记录按门槛不同的审批规则（例如，>5% 上涨需财务审批），以便后续编码这些规则。

定义必须输出的内容（用户需要做什么）

把应用在第一天必须回答的具体问题写下来：

• “供应商 Y 的商品 X 今天的当前价格是多少？”
• “哪些合同将在未来 60/90 天到期，谁负责续约？”
• “有哪些例外：仍被使用的过期价格、缺失 MOQ、货币不匹配？”

这些输出应驱动数据字段、搜索与报表，而不是反过来。

提前记录痛点与边缘情况

采购数据很混乱。明确记录常见例外：

• 部分更新（供应商只更新了 20 个 SKU，而非完整目录）
• 多种货币与外汇假设
• MOQ、包装单位（每件 vs 箱）与四舍五入问题
• 生效日期重叠或追溯更正

把这类清单作为导入与审批的验收标准，确保系统支持现实操作而不是强迫绕行。

高层架构与模块划分

用于供应商价目表与合同的好架构不在于花哨的模式，而在于降低协同成本并为增长保留扩展点。

构建思路：先简单，逐步演进

对于大多数团队（1–6 名工程师），最佳起点是 模块化单体：一个可部署的应用，内部有清晰分离的模块与边界。这样能加快开发、简化调试并减少运维复杂度。

只有在有明确理由时才拆分服务——例如导入负载很大需独立扩展、多个团队并行开发或需严格隔离。常见路径是：模块化单体 → 将 导入/处理 与 文档 工作负载拆到后台工作器 → 根据需要将高流量领域拆成服务。

如果你想快速做出可交付的原型（页面、工作流与基于角色的访问）而不投入漫长的构建周期，一些低代码/生成平台（例如 Koder.ai）可以基于结构化对话规范生成 React + Go + PostgreSQL 的基础骨架，然后快速在导入、审批与审计轨迹上迭代。对于采购团队，这通常意味着能更早与真实用户验证工作流——在你过度构建之前。

核心模块（最小集合）

围绕几个稳定领域设计应用：

• Suppliers（供应商）：供应商档案、联系人、标识、状态
• Catalog（商品/物料）：内部物料主数据与供应商物料编码映射
• Price Lists（价目表）：表头（供应商、生效期）与行项（价格、单位、货币），以及导入历史
• Contracts（合同）：合同记录、关联供应商、覆盖的商品/类别、关键日期与相关文档
• Approvals & Governance（审批与治理）：审查步骤、签字、评论与决策历史
• Reporting（报表）：搜索、导出、采购/定价视图与运营快照

让每个模块负责自己的规则与数据访问。即便是单体应用，也要在代码里通过包、命名与清晰的模块接口强制边界。

提前规划集成点（即便首版不立刻实现）

集成会改变数据流，应保留明确的扩展点：

• SSO（SAML/OIDC） 用于认证与用户供应
• ERP/财务系统 用于供应商 ID、物料主数据与推送已批准价格
• 邮件/日历 用于续约提醒与审批通知
• 电子签名（可选）用于最终确定修订与新协议

非功能需求（上线前设定目标）

提前定义可量化的期望：

• 性能：常用搜索 < 2 秒；导入异步处理并显示进度
• 可用性：明确的上线目标与计划维护窗口
• 备份与恢复：自动备份、恢复演练与保留策略符合组织要求
• 审计性：导入、审批与合同变更的不可变事件历史，能追溯到用户与时间戳

数据模型：实体、关系与版本管理

干净的数据模型能让采购应用值得信赖。当用户问“3 月 3 日哪个价格有效？”或“那次采购由哪个合同约束？”时，数据库应无歧义地回答。

核心实体（最少集合）

从小而明确的记录集开始：

• Supplier（供应商）：供应商账户（名称、供应商编码、状态、默认货币、付款条款）
• Contact（联系人）：供应商人员（每供应商多条）
• Item/SKU（商品/物料）：采购对象（编码、描述、类别、计量单位）
• PriceList（价目表）：供应商提供的价表或协商价表（名称、生效日期、货币、文件来源、状态）
• PriceLine（价目行）：价表内的行项（商品、单价、折扣/最小起订量、税标记）
• Contract（合同）：商业协议（合同编号、供应商、开始/结束日期、续约设置、状态）
• Term（条款）：可结构化查询/汇报的条款（交期、保修、交付、服务等级）

将关系建模来保持连接性

按采购实际工作方式建模关联：

• Supplier → Contracts：一个供应商可有多份合同
• Supplier → PriceLists：一个供应商会有多个历时价表
• Contract → PriceLists（可选但有用）：将合同与其约束的价目表关联
• Item/SKU → PriceLines：同一商品可出现在不同供应商、货币与生效期的多条价目行

如果支持多发货地点或业务单元，考虑加入 Scope（适用范围） 概念（例如公司/站点/区域），并与合同与价目表关联。

版本管理：不要覆盖历史

避免在原记录上直接编辑。相反：

• 价目表版本化：每次导入创建新的 PriceList 版本（或在同一家族 ID 下新建 PriceList 记录）。保留历史版本为只读。
• 合同修订：将每次修订存为新的版本并记录生效日期。所谓“当前”合同视图即为最新批准的版本。

这样可以轻松回答审计问题：重构出何时批准了什么、发生了哪些更改。

参考数据与唯一性规则

把参考数据放到专门表里以避免杂乱的自由文本：

• 货币、计量单位、税码、（若跨国）国际贸易术语（Incoterms）

强制标识符唯一以防止隐性重复：

• 供应商编码 在系统内唯一
• 商品编码 唯一（或按目录/来源唯一）
• 合同编号 按供应商或全局唯一——选定后统一强制执行

价目表导入：模板、校验与错误处理

价目表通常以从未为机器设计的电子表格形式抵达。顺畅的导入体验是用户会选择使用系统而不是继续邮件 Excel 的关键。目标是：上传时容错，保存时严格。

支持格式与可下载模板

首版支持 CSV 与 XLSX。CSV 便于 ERP 与 BI 导出；XLSX 是供应商常用格式。

提供 可下载模板 来反映你的数据模型，降低猜测成本，模板应包含：

• 第一行为 精确列名
• 一个示例行显示有效值（货币、单位、日期）
• 可选的说明页（用于 XLSX）解释每列含义

为模板做版本管理（例如 Template v1、v2），以便演化而不破坏既有流程。

映射规则：必填列 vs 可选列

在上传界面明确映射规则：

常见做法：

• 必填列：供应商标识、商品/SKU、价格、货币、计量单位、生效开始日期
• 可选列：生效结束日期、最小起订量、交期、包装、国际贸易术语、备注
• 默认值（按供应商或上传）：货币、单位、起始日期默认为“今天”、结束日期为空

如允许自定义列，则把它们作为元数据单独存储，避免污染核心价格表结构。

防止错误数据的校验规则

在提交保存前运行校验：

• 数值格式：拒绝非数字价格单元；规范千位分隔符；价格必须非负
• 货币代码：使用 ISO 4217 校验（如 USD、EUR）
• 日期范围：必须有起始日期；结束日期需晚于起始日期；若规则要求排他性，则阻止同一商品重叠生效期
• 重复行：检测相同键（例如 supplier + SKU + start date + currency + unit）。决定是把重复视为错误还是“以最后一条为准”（默认错误更安全）

同时做行级校验（该行错误）和文件级校验（此上传与现有记录冲突）。

错误处理：预览、行级反馈与重上传

良好导入体验应为：上传 → 预览 → 修正 → 确认。

在预览界面：

• 显示表格并高亮出错单元格，给出清晰信息（例如 “无效货币代码：US$”）
• 允许用户下载带有额外“error”列的 错误报告（CSV）
• 提供保留上次映射设置的 修正并重传 流程

避免“因一行错误而整文件失败”的体验。应让用户选择：仅导入有效行 或 全部修正后阻止导入，视治理要求而定。

存储原始上传以便可追溯

为审计与重处理存储：

• 原始文件（精确字节），带校验和与上传者信息
• 解析后的行与校验结果（含错误）
• 导入配置（模板版本、列映射、默认值）

这能构建可辩护的痕迹（“我们何时导入了什么？”），并在校验规则变更时支持重处理。

合同记录：条款、文档与修订

合同记录应不仅仅是文件柜。它需要足够的结构化数据来驱动续约、审批和报表，同时保留签署文件便于查找。

核心合同条款（结构化字段）

从能回答采购日常问题的字段开始：

• 合同开始与结束日期
• 续约类型（自动续约、固定期限、永久）与续约长度
• 通知期（例如“在结束日前 60 天”）与需通知的责任方
• 付款条款（Net 30/45/60、早付折扣）与开票规则
• 合同负责人、供应商联系人与内部干系人

对于会被筛选、分组或告警的内容尽量标准化；将自由文本留给边缘情况。

文档、附件与保留策略

把文档作为一等公民并与合同关联：

• 签署协议（PDF）
• 修订/附件
• 工作说明书、费率表、保险证明、合规文件

为每个文件存储元数据：文档类型、生效日期、版本、上传者与保密级别。如组织有保留要求，加入“保留至”与“法律保全”字段以防删除并支持审计。

修订与条款追踪

修订不应覆盖历史。将修订建模为带日期的变更：延长期限（新结束日期）、调整商业条款或增加/减少范围。

尽量把关键条款结构化以便告警与汇报：例如是否允许因便利终止（Y/N）、指数化公式、服务违约金、责任上限与独家性等。

一份合同覆盖多供应商或站点

如果集中采购但跨站点运营，支持一份合同链接多个站点/业务单元，并允许站点级别覆盖（例如账单地址、交付条款）。同样允许一份合同覆盖母公司与子公司，同时保留清晰的“被合同约束方”以满足合规性要求。

审批工作流与治理

审批是让价目表与合同具有可辩护性的关键环节。清晰的工作流能减少“谁批准了这个？”的争论，并把供应商提交到可用合规数据的路径标准化。

状态流（保持显式）

为价目表与合同记录使用简单、可见的生命周期：

Draft → Review → Approved → Active → Expired/Terminated

• Draft（草稿）：提交者可编辑；不可用于采购。
• Review（评审）：锁定编辑（除通过变更请求）；评审者验证完整性与政策符合性。
• Approved（批准）：记录决定；按日期规则可被激活。
• Active（生效）：可用于下单；更改需新版本与审批。
• Expired/Terminated（已过期/终止）：只读；保留用于报表与审计。

角色与职责

在应用中定义责任，而不是靠部落记忆：

• 提交者（采购/供应商经理）：上传价目表、起草合同条款、回应评审意见
• 评审者（品类/财务）：核查定价、单位、货币与商业一致性
• 审批人（预算负责人）：对商业影响做出最终决定
• 法务：作为必需的评审/审批角色审阅合同语言、文档与修订
• 管理员：配置门槛、路由规则与权限——默认不参与业务审批

价格变动规则（防止无声成本上升）

添加基于策略的检查，自动触发额外审批：

• 门槛审批：例如任一行上涨 >5% 或总类目影响超 10,000 美元，路由至更高一级审批
• 按类目路由：战略类目（如 IT、物流）可能永远需要法务 + 预算负责人审批
• 例外处理：允许覆盖仅附带强制理由与附件

审计就绪的决策：评论、理由与证据

每次批准或拒绝应记录：

• 决定（批准/拒绝/请求变更）
• 理由代码 + 自由文本说明
• 时间戳、执行者与受影响的修订
• 关联证据（邮件 PDF、供应商信件、会议记录）

升级、超时与责任追踪

设定服务级别期望以避免审批滞留：

• 在 24/48 小时自动提醒
• 超时后升级到备用审批人
• 通过“我的待审批”队列与逾期报表提升可见性

治理最好内嵌在工作流中，而不是事后强制执行。

用户体验：界面、搜索与报表

采购应用的成败取决于人们能多快回答简单问题：“当前价格是什么？”，“哪个合同管控该项目？”，“与上季度相比发生了什么变化？”把 UI 围绕这些工作流设计，而不是数据库表。

快速查找：搜索与筛选

顶部导航提供两个主要入口：

• 供应商搜索（名称、税号/供应商编码、状态、类别）
• 商品搜索（SKU/零件号、描述、制造商、单位）

在结果页使用与工作匹配的合同筛选：生效日期、合同状态（Draft/Active/Expired）、业务单元、货币与“有未决审批”。保持筛选可见并以标签芯片形式显示，避免非技术用户迷失。

首批要设计的关键界面

供应商概览应为枢纽：展示活跃合同、最新价目表、未决争议/备注与“最近活动”面板。

合同视图应回答“我们可以在哪些条款下采购、截至何时？”展示关键条款（国际贸易术语、付款条款）、附件与修订时间线。

价目表对比是用户会花大量时间的地方。并排显示 当前 vs 之前：

• 生效日期（含“未来”价格）
• 按项的差异（绝对值与百分比）
• 新增/移除项目高亮显示

报表与导出

报表应可操作而非仅供展示：例如“60 天内到期”、“最大涨价项”、“有多个活跃价格的商品”。提供一键导出到 CSV（给财务）和 PDF（用于分享/审批），并保证导出的筛选与页面一致。

保持简洁与自解释

使用清晰标签（“生效日期”，而非“有效开始”），在复杂字段旁放置内联帮助（单位、货币），并在空状态提供下一步提示（“导入价目表以开始跟踪变更”）。在 /help 提供简短的入门清单可以减少培训时间。

安全、权限与审计轨迹

安全应在工作流设计阶段就考虑，而不是后补。目标很简单：人们只看到并能修改他们负责的内容，且每次重要变更都可追溯。

角色与权限（最小权限）

从小而明确的角色模型开始，并把权限映射到动作（而不仅是页面）：

• Viewer：对已批准价目表与生效合同的只读访问
• Editor：创建草稿、上传文档、准备导入、修复校验错误
• Approver：批准/拒绝草稿、锁定生效日期、签署修订
• Admin：管理用户、角色、参考数据与系统设置

所有端点在服务器端强制执行权限（仅 UI 控制是不够的）。若组织复杂，增加按作用域的规则（按供应商/业务单元/地区）。

敏感数据处理

提前决定哪些数据需额外保护：

• 合同文件（PDF/扫描件）：静态加密、限制下载，并可选地加入水印
• 银行详情：存放在受更严格限制的区域；仅财务小范围可见
• 定价可见性：考虑对毛利或特殊价格做屏蔽，支持“内部视图”与“供应商视图”的切换

审计轨迹：谁改了什么以及如何改的

对关键实体（合同、条款、价格项、审批）记录不可变审计日志：谁、变更前/后内容、何时、来源（UI/导入/API）。记录导入文件名与行号以便追溯与纠错。

认证与会话基础

选择一种主认证方式：

• SSO（SAML/OIDC） 适合企业用户；小团队可用 密码 + MFA

添加合理的会话控制：短生命周期访问令牌、Secure Cookies、非活动超时，并在敏感操作（如导出定价）要求重新认证。

合规基础（务实而不过度承诺）

做到实用控制：最小权限、集中日志、定期备份与恢复演练。把审计日志视为业务记录——限制删除并定义保留策略。

定价规则：生效日期、货币与单位

定价很少只是“一串数字”。应用需要明确规则，让采购、应付与供应商对“今天这个商品的价格是多少”达成一致。

生效日期（起/止、未来价格、重叠）

把价格当成有时间界限的记录，存储 起始日期 与可选 结束日期。允许未来生效的行（例如下季度涨价），并明确“无限期”的含义（通常表示直到被替换）。

对重叠要有明确处理策略：

• 默认在导入时 拒绝重叠（便于治理）
• 若需允许（如促销价格），须声明优先级并记录理由与审批

一个实用规则是：在任意时间点，对于同一供应商-商品-货币-单位，只有一个基础价格；其他必须标记为覆盖。

定义“当前价格”

当存在多个候选价格时，定义优先级，例如：

1. 合同覆盖价格（若合同生效且商品在覆盖范围内）
2. 已批准的覆盖（促销/例外）在其生效期内
3. 标准供应商价目表在其生效期内
4. 兜底或“无价格”状态（需人工处理）

若流程有优先供应商，加入 供应商优先级 字段，仅在多供应商存在同商品时使用。

多币种策略

选择存储方式：

• 每条价格记录存储当时的汇率（便于审计；能复现历史决策）
• 实时汇率换算（用于仪表盘；仍应保存原始货币）

许多团队两者兼顾：保留供应商的原始货币价格，同时存一份“截至某日”的换算值供报表使用。

四舍五入与单位换算

定义单位标准化（例如 each vs case vs kg）并对换算系数做版本管理。统一四舍五入规则（货币小数位、最小价格增量），并明确在哪一环节四舍五入发生：在单位换算后、在汇率换算后或在最终行总计上。

续约、提醒与运营面板

续约是合同价值保住或流失的关键点：错过通知期、默认自动续约或临时谈判通常导致不利条款。你的应用应把续约视为可管理的过程，带有明确日期、负责人与可见的操作队列。

续约时间线与提醒

将续约建模为与合同（或特定修订）绑定的一组里程碑：

• 结束日期（到期）
• 通知期截止日（取消/重新谈判的最后日期）
• 续约窗口开始（何时应启动寻源）

围绕这些里程碑构建提醒。实用默认为在关键截止日前 90/60/30 天的提醒（通常通知期最关键），并在到期当日再发一次提醒。

通知渠道与投递

初版建议两类渠道：

• 应用内通知 用于日常工作队列
• 电子邮件 用于时间敏感提醒

可选支持导出 ICS 日历文件（按合同或按用户），让负责人订阅 Outlook/Google Calendar。

把提醒做成可操作：包含合同名、供应商、精确截止日与深度链接。

归属与升级

提醒应发送给：

• 合同负责人（主）
• 品类负责人（若不同则为次要）
• 备用负责人（用于覆盖）

加入升级规则：若主负责人 X 天内未确认，则通知备用或经理。记录“已确认”时间戳以免提醒成为噪音。

推动工作的运营面板

面板应简单、可筛选并基于角色：

• 即将到期的合同（按 30/60/90 天分组，含通知期截止）
• 逾期的续约任务（未确认或已过里程碑）
• 待审批的价目表（按时长、负责人、供应商）

每个控件应链接到带搜索与导出的聚焦列表，使面板成为行动起点而非只是报告。

MVP 计划、测试与上线清单

一个针对供应商价目表与合同的 MVP 应证明一件事：团队能安全加载定价、快速找到相关合同，并信任审批与审计记录。

MVP 范围（必须有）

从一个薄而端到端的工作流开始，而不是很多孤立功能：

• 供应商 + 商品主数据基础：供应商、商品/服务、单位、货币
• 价目表导入：一到两个模板（CSV/XLSX），预览、字段映射（如需）、校验与错误报告
• 合同记录：关键条款（开始/结束、通知期、续约类型）、附件，并可链接到供应商与相关价目表版本
• 审批：简单工作流（Draft → Review → Approved），基于角色权限并记录审计日志
• 搜索 + 报表：全局搜索（供应商、SKU、合同 ID），以及一份“当前已批准价格”导出

若想用小团队快速推进，可考虑用 Koder.ai 生成初始产品骨架（React 前端、Go 后端、PostgreSQL），并在规划阶段与采购/法务干系人迭代验证流程（导入 → 审批 → 审计 → 续约提醒），验证后导出源码进行加固与扩展。

测试计划（现实中会坏的点）

把测试重心放在错误成本高的地方：

• 导入校验测试：缺失必填列、无效货币/单位、重复行、日期重叠、负价格、混合小数点
• 权限测试：谁能导入、批准、在批准后编辑、查看敏感附件
• 工作流测试：编辑后需重新审批、拒绝必须有评论、每次状态变更产生审计条目

上线与部署

使用带有脱敏生产样本的 预发布环境（staging）。上线前需执行清单：启用备份、排练迁移脚本与制定 回滚计划（版本化 DB 迁移 + 部署回退）。

上线后监控导入失败、搜索慢查询与审批瓶颈。

上线后迭代

开展 2–4 周的反馈循环与采购和财务：汇总导入高频错误、合同缺失字段与界面慢点。下一步候选：ERP 集成、供应商门户上传、节约与合规分析。

建议内部阅读：/pricing 和 /blog。