企业官网建设流程全解析

1. 这不是“随便建个表”——采购信息记录的本质是业务流的数字镜像

“采购信息记录相关表”，光看标题，很多人第一反应是：不就是数据库里建几张表嘛？加几个字段，设下主键外键，填点数据进去，完事。我刚入行那会儿也这么想，直到被财务部拉着开了三次跨部门协调会，就因为一张《采购订单明细表》里“预计到货日期”的字段类型从DATE改成DATETIME，导致下游ERP系统自动对账模块连续三天跑出278条异常差异——而问题根源，根本不在技术实现，而在我们压根没搞清这张表到底在映射什么。

采购信息记录，从来不是孤立的数据容器。它是一条业务流的数字镜像：从需求部门提报采购申请，到采购专员比价谈判、生成订单，再到供应商发货、物流跟踪、仓库收货、质检入库，最后到财务付款结算。每一个环节的动作、状态、责任人、时间戳、附件凭证，都在这张表（或这一组表）里留下不可篡改的痕迹。它既是操作日志，也是责任凭证，更是审计线索。你建的不是表，是业务规则的强制执行器。比如，“采购申请单号”必须全局唯一且带年份前缀（如CG2024-001），这不是为了好看，而是为了满足内控审计对“可追溯性”的硬性要求；“供应商ID”必须关联主数据表且校验有效性，否则采购员手输一个不存在的供应商名，后续合同、付款、绩效评估全盘失真。

关键词里虽然空着，但实际场景中，这类表必然绕不开几个核心实体：采购申请单、采购订单、收货单、入库单、发票、供应商、物料主数据、采购员、审批人。它们之间不是简单的1对多关系，而是嵌套的、带状态机的、有时效约束的网状结构。比如一张采购订单，可以对应多张收货单（分批到货），每张收货单又关联多张入库单（不同库位），而每张入库单又可能触发多张质检报告。如果只用一张宽表硬塞所有字段，不出三个月，表结构就会臃肿到连SQL查询都得写三页JOIN，更别说做数据分析了。所以，“相关表”这三个字，本质是在提醒你：必须做范式化设计，把高内聚、低耦合的业务概念拆解成独立实体，再用关联表精准表达它们之间的动态关系。

我见过太多项目栽在这一步。最典型的是某制造企业，为赶工期，直接用Excel模板导出数据，然后用脚本“一键导入”到一张名为purchase_all_in_one的表里。结果半年后，法务部要查某批次原材料的完整采购链路，技术团队花了两天时间，从37万行数据里手工筛选、拼接、去重，才勉强还原出一条路径。而如果当初按标准模型建了purchase_request、purchase_order、goods_receipt、inventory_transaction四张表，并用order_id和receipt_id做外键关联，一个带JOIN的SELECT语句，1.2秒就能返回结果。这背后差的不是技术，是建模时对业务本质的理解深度。所以，别急着打开数据库管理工具，先拿出白纸，画出你公司真实的采购流程图，标出每个节点产生的关键数据项、谁负责录入、何时生效、是否可修改、修改后如何影响上下游——这张图，才是你建表的真正蓝图。

2. 七张核心表的实战建模逻辑：为什么字段名不能“望文生义”

很多新手建表，习惯直接照搬业务单据上的字段名：比如采购申请单上有“申请人”，就建个applicant_name；有“申请日期”，就建apply_date。看似直白，实则埋雷。我曾接手一个遗留系统，purchase_order表里有个字段叫total_amount，类型是DECIMAL(10,2)。上线三年，财务一直抱怨对账总差几毛钱。排查发现，这个字段存的不是订单总金额，而是“含税金额减去预付款后的应付余额”，而开发文档里根本没写清楚。后来才知道，当初建表时，业务方口头说“就存个最终要付的钱”，程序员理解成了“订单总价”，没人追问“最终”是哪个环节的最终、“要付”是付给谁、是否含运费和关税。这种“望文生义”的命名，是数据混乱的温床。

真正的建模，必须回归业务语义的精确性。以下是我经手过数十个项目后，总结出的七张采购核心表及其关键字段设计逻辑，每一条都来自真实踩坑：

2.1purchase_request（采购申请单表）——需求源头的“不可篡改锚点”

• pr_id（主键）：格式为PR-YYYYMMDD-XXXXX，前缀+日期+5位流水号。不用UUID，因为业务人员要手动录入、核对，UUID太长易错；不用纯数字自增ID，因为无法体现业务含义和时间维度。
• requester_id（申请人ID）：必须是员工主数据表的外键，而非requester_name。名字会改（离职、更名），ID不会变。我见过因存名字导致离职员工的采购申请被误判为“无效单据”而自动作废的事故。
• department_code（所属部门编码）：关联组织架构表，不是部门名称。名称模糊（如“研发一部”和“研发一部（深圳）”），编码唯一（如RD-SZ-001）。
• status（状态）：枚举值'draft','submitted','approved','rejected','cancelled'。必须有状态变更日志表配套，否则无法审计“谁在什么时候把单子驳回了”。

提示：此表严禁存任何金额字段！采购申请只是需求意向，价格、税率、币种均未确定。所有金额字段必须放在后续的采购订单表中。

2.2purchase_order（采购订单表）——法律效力的“数字契约”

• po_id（主键）：格式PO-YYYY-XXXXX，年份+5位流水。与申请单号pr_id通过pr_id字段关联，但允许一对多（一个申请可拆分成多个订单）。
• supplier_id（供应商ID）：强外键约束，必须存在且有效。我曾因未加此约束，导致采购员误选了一个已停用的供应商，订单发出去才发现对方已注销，损失定金。
• currency_code（币种代码）：CHAR(3)，如'CNY'、'USD'。必须与exchange_rate（汇率）字段成对出现，且exchange_rate需记录生效日期，因为汇率是动态的。
• tax_rate（税率）：DECIMAL(5,4)，存0.13表示13%。不是百分比字符串，否则计算时需额外转换，极易出错。

2.3po_line_item（采购订单行项目表）——物料颗粒度的“最小责任单元”

这是最容易被忽视却最关键的一张表。一张订单可能有100个物料，但每个物料的交期、单价、单位、税码都可能不同。

• line_id（主键）：自增ID。
• po_id（外键）：关联订单。
• material_id（物料ID）：必须关联物料主数据表，确保规格、单位、分类准确。曾有项目因存物料名称，导致同一物料（如“螺丝M4×10”）因描述微小差异（“M4*10”、“M4-10”）被当成不同物料，库存统计严重失真。
• quantity（订购数量）：DECIMAL(18,6)。精度必须足够，化工、制药行业常需小数点后4位。
• unit_price（单价）：DECIMAL(18,6)。与currency_code同表，避免跨表查询汇率。

2.4goods_receipt（收货单表）——实物交接的“法律证据”

• gr_id（主键）：GR-YYYYMMDD-XXXXX。
• po_id+line_id（复合外键）：必须精确到行项目，因为收货可以分批、部分。不能只关联po_id，否则无法知道这批货对应订单里的哪一行。
• received_quantity（实收数量）：DECIMAL(18,6)。与po_line_item.quantity对比，自动生成差异标记（如'short','over','ok'）。
• receipt_date（收货日期）：DATETIME，精确到秒。因为涉及仓储时效考核，分钟级差异都可能影响KPI。

2.5inventory_transaction（库存事务表）——账实一致的“黄金账本”

所有出入库动作，无论采购、生产领料、销售出库，都记在此表。它是财务存货核算的唯一依据。

• it_id（主键）：自增。
• transaction_type（事务类型）：枚举'purchase_in','production_out','sales_out','adjustment'。采购入库必须是'purchase_in'，且source_id指向gr_id。
• material_id+warehouse_id（物料+库位）：联合唯一索引，确保同一物料在同一库位的库存变动可追溯。
• quantity_change（数量变动）：DECIMAL(18,6)，正数为入库，负数为出库。这是核心，所有库存余额=SUM(quantity_change)。

2.6invoice（发票表）——财务结算的“法定凭证”

• invoice_id（主键）：INV-YYYYMMDD-XXXXX。
• po_id（外键）：一张发票可对应多张订单，但必须明确关联。曾有项目因未关联，导致财务无法匹配付款与订单，重复付款。
• invoice_date（开票日期）：DATE。与payment_due_date（付款到期日）共同决定账期，如“月结30天”，则payment_due_date = invoice_date + INTERVAL 30 DAY。
• tax_amount（税额）：DECIMAL(18,2)。必须与po_line_item.tax_rate和unit_price计算逻辑严格一致，否则税务稽查通不过。

2.7supplier_master（供应商主数据表）——信任关系的“数字档案”

• supplier_id（主键）：SUP-XXXXXX，6位编码。
• legal_name（法定名称）：与营业执照完全一致，用于合同、发票。
• bank_account（银行账号）：加密存储。我坚持用AES-256加密，而非明文或简单哈希，因为这是支付安全的底线。
• status（状态）：'active','inactive','blacklisted'。inactive不等于删除，历史订单仍需关联，只是新订单不可选。

这七张表不是教科书模板，而是我在制造业、零售业、IT服务商三个完全不同行业的项目中，反复验证、迭代出的最小可行集合。它们之间通过外键形成闭环，任何一个环节的数据变更，都能通过JOIN链条向上追溯源头、向下影响结果。建表不是终点，而是让业务流在数字世界里开始自主运转的第一步。

3. 字段设计的“魔鬼细节”：那些让DBA半夜打电话的隐性陷阱

建好表结构，只是万里长征第一步。真正让系统稳定运行、让业务人员用得顺手的，是那些藏在字段定义背后的“魔鬼细节”。这些细节，往往在需求评审会上没人提，在技术方案里一笔带过，却能在上线后引发连锁故障。我整理了五个最常被忽略、但后果最严重的字段设计陷阱，每个都附上真实案例和解决方案。

3.1 “日期”字段：DATE、DATETIME、TIMESTAMP，选错一个，审计全崩

采购场景里，时间戳无处不在：申请提交时间、订单创建时间、收货时间、发票开具时间、付款时间。但很多人不假思索全用DATETIME。问题来了：DATETIME存储的是“字面时间”，不带时区；TIMESTAMP存储的是“UTC时间戳”，读取时自动转为当前会话时区。在跨国采购中，这会导致灾难。

真实案例：某跨境电商，总部在上海（UTC+8），供应商在德国（UTC+1）。采购员在上海时间下午3点（15:00）创建订单，系统存为DATETIME '2024-05-20 15:00:00'。德国供应商登录系统查看，看到的还是15:00，但实际是他们的上午8点。当供应商按“本地时间8点”发货，物流单显示发货时间为2024-05-20 08:00:00，系统却把它当作上海时间08:00，比订单创建时间还早7小时，触发了“异常提前发货”预警，客服被打爆。

解决方案：

• 所有记录“事件发生时间”的字段（如created_at,received_at,invoice_date），统一使用TIMESTAMP。
• 在应用层，用户输入时间时，必须明确指定时区（如选择“上海”、“法兰克福”），前端传给后端时带上时区信息（如2024-05-20T15:00:00+08:00），后端解析后存为UTC时间戳。
• 查询展示时，根据当前用户时区动态转换。这样，上海人看到的是15:00（上海），德国人看到的是08:00（法兰克福），但数据库里存的都是同一个UTC时间点，审计时毫无歧义。

3.2 “金额”字段：DECIMAL的精度陷阱，0.01元误差能毁掉整张报表

财务对账，毫厘必争。DECIMAL(M,D)的M（总位数）和D（小数位数）怎么定？很多人拍脑袋：DECIMAL(10,2)够用了。错。DECIMAL(10,2)最大能存99999999.99，约1亿，但采购订单金额动辄上千万，且涉及多币种换算、税费分摊，中间计算过程需要更高精度。

真实案例：某汽车零部件厂，采购一批钢材，订单总金额12,345,678.90 CNY，汇率1 USD = 7.2156 CNY，需换算成美元支付。若用DECIMAL(10,2)存美元金额，计算12345678.90 / 7.2156 ≈ 1,711,123.45678...，四舍五入存为1711123.46。但财务系统用更高精度计算，得到1711123.457，两者差0.003美元。单笔看着微不足道，但全年百万级订单累积下来，对账差异高达数万美元，审计时被质疑系统可靠性。

解决方案：

• 所有金额字段，统一用DECIMAL(18,6)。18位总长，6位小数，足够覆盖全球任何货币（比特币最小单位是Satoshi，1 BTC=10^8 Satoshi，即小数点后8位，6位已绰绰有余）。
• 运算过程全程保持高精度：数据库计算、应用层计算，都用DECIMAL类型，禁止转成FLOAT或DOUBLE，后者有二进制浮点误差。
• 最终展示时，按业务规则四舍五入：如人民币显示2位，美元显示2位，但底层存储和计算永远用6位。

3.3 “状态”字段：枚举值的生命周期管理，别让“已取消”变成“已完结”

状态字段（status）是采购表的灵魂，但它极易失控。常见错误是定义一堆枚举值，如'draft','submitted','approved','rejected','cancelled','completed','closed'，却不定义状态流转规则。结果业务员能把“已拒绝”的单子，手动改成“已完成”，系统还认为合法。

真实案例：某医药公司，采购申请单状态有'pending_review','approved','rejected','expired'。某次系统升级，开发漏掉了expired状态的校验逻辑。结果一个已过期（expired）的申请单，被采购员误操作点成了approved，系统自动生成了订单，供应商发货后才发现该申请早已失效，产生纠纷。

解决方案：

• 状态值必须用数据库ENUM类型或CHECK约束，禁止自由文本。
• 状态流转必须由业务规则引擎控制，而非前端按钮。点击“批准”按钮，后端调用approve_pr(pr_id)存储过程，该过程内部检查：当前状态必须是'pending_review'，且申请人未撤回，且审批人有权限……全部通过才更新状态。
• 增加status_history表，记录每次状态变更的from_status,to_status,operator_id,change_time,reason（原因备注）。审计时，这条链就是铁证。

3.4 “文本”字段：VARCHAR长度的“安全边际”，超长截断是慢性自杀

VARCHAR(255)是程序员的“万能胶”，但采购单据里，供应商地址、物料描述、合同条款，动辄上千字符。用VARCHAR(255)，轻则数据被无声截断，重则引发业务逻辑错误。

真实案例：某电子厂，purchase_order表的delivery_address字段是VARCHAR(255)。某次向越南工厂下单，地址是“Lot 123, Industrial Park A, Ho Chi Minh City, Vietnam”。这个地址有62个字符，没问题。但供应商回复的物流单地址是“Lot 123, Industrial Park A, Ho Chi Minh City, Vietnam - Warehouse #B3, Floor 2, Rack 15”。超长了！系统截断后存入'Lot 123, Industrial Park A, Ho Chi Minh City, Vietnam - Warehouse #B3, Flo...'，物流商按截断地址送货，找不到仓库，货物滞留港口一周。

解决方案：

• 地址、描述、备注类字段，一律用TEXT类型。现代数据库对TEXT的性能优化已非常成熟，不必担心。
• 前端做实时字数校验：用户输入时，实时显示剩余字数，超限时禁用提交按钮，并给出明确提示（如“地址最多2000字，请精简”）。
• 数据库层加CHECK约束：CHECK (CHAR_LENGTH(delivery_address) <= 2000)，双重保险。

3.5 “外键”字段：级联删除的“潘多拉魔盒”，删一张单，崩整个库

外键的ON DELETE CASCADE（级联删除）听起来很省事：删掉采购申请单，自动删掉关联的订单、收货单……但现实是，采购申请单可能已被归档，而对应的发票已付款，财务账本已结账。此时级联删除，等于直接抹掉已结算的财务凭证，后果不堪设想。

真实案例：某SaaS服务商，purchase_request表的pr_id是purchase_order.pr_id的外键，设置了ON DELETE CASCADE。某次运维清理测试数据，误删了一张ID为PR-20230101-00001的测试申请单。系统自动级联删除了其下的3张订单、12张收货单、8张入库单、5张发票。更糟的是，其中一张发票已付款，财务系统里这笔付款记录还在，但对应的发票数据没了，导致“付款无据可查”，财务总监当场拍桌。

解决方案：

• 外键一律设置ON DELETE RESTRICT（限制删除）。这是最安全的默认行为。当尝试删除被引用的记录时，数据库直接报错，强制人工介入。
• 提供“软删除”机制：给核心表加is_deleted TINYINT(1) DEFAULT 0和deleted_at DATETIME NULL字段。删除操作只是更新这两个字段，数据物理保留，确保审计和追溯。
• 定期归档冷数据：对超过3年的历史采购数据，迁移到归档库，主库只保留热数据，既保证性能，又规避误操作风险。

这些细节，没有一条是“高大上”的新技术，全是扎扎实实的工程实践。它们不写在PPT里，却决定了系统是坚如磐石，还是摇摇欲坠。记住，数据库设计不是炫技，而是为业务筑一道沉默的堤坝。

4. 数据一致性保障：从“能跑通”到“永不翻车”的四层防御体系

建好了表，设好了字段，系统跑起来了，业务人员说“挺好用”。这时候，很多团队就以为大功告成了。错。采购数据的价值，不在于“能录入”，而在于“绝对可信”。一次错误的收货数量、一笔错配的发票、一个失效的供应商ID，都可能引发供应链中断、财务损失、审计风险。我见过太多系统，表面风平浪静，底层数据早已千疮百孔。要让采购信息记录真正成为业务的“数字基石”，必须构建一套四层防御体系，层层设防，缺一不可。

4.1 第一层：数据库原生约束——你的第一道、也是最强的防线

这是成本最低、效果最直接的防线。别指望应用层代码能100%兜住所有错误，人总会犯错，代码总有Bug。数据库的约束，是冷酷无情的守门人。

• 主键（PRIMARY KEY）：每张表必须有，且必须是业务有意义的组合键或代理键。purchase_order.po_id必须是主键，确保订单号唯一。我坚持用业务编码（如PO-2024-00001）而非自增ID，因为业务人员沟通时，永远说“PO-2024-00001”，不说“ID=123456”。
• 非空约束（NOT NULL）：哪些字段绝对不能为空？po_line_item.material_id、goods_receipt.received_quantity、invoice.invoice_date。这些是业务逻辑的基石，缺失即无效。宁可让录入失败，也不能让脏数据入库。
• 唯一约束（UNIQUE）：supplier_master.tax_id（税号）必须唯一，这是国家税务监管的硬性要求。purchase_request.pr_id必须唯一，避免重复申请。
• 检查约束（CHECK）：po_line_item.quantity > 0，invoice.invoice_date <= CURDATE()（发票日期不能是未来），purchase_order.status IN ('draft','confirmed','shipped','delivered','cancelled')。这些规则，数据库执行起来比应用层快100倍，且无法绕过。
• 外键约束（FOREIGN KEY）：po_line_item.material_id必须存在于material_master表中，goods_receipt.po_id必须存在于purchase_order表中。这是保证数据关联性的生命线。务必开启ON UPDATE CASCADE（级联更新），当物料主数据的material_id变更时（极少发生，但需支持），自动更新所有关联订单行，避免数据断裂。

提示：所有约束必须在建表时一次性定义，不要等上线后再补。补约束需要锁表，业务高峰期无法操作。

4.2 第二层：应用层业务规则引擎——处理复杂逻辑的“智能大脑”

数据库约束解决“是什么”，应用层规则引擎解决“为什么”和“怎么办”。它处理那些无法用简单SQL表达的复杂业务逻辑。

• 状态机引擎：采购单的状态流转不是简单的UPDATE SET status='approved'。它必须是一个受控的流程。引擎接收approve_order(po_id, approver_id)请求，内部执行：
  1. 检查po_id是否存在且状态为'submitted'；
  2. 检查approver_id是否有该采购品类的审批权限；
  3. 检查订单总金额是否在审批人额度内；
  4. 检查关联的供应商是否在合格名录内且状态为'active'；
  5. 全部通过，才更新状态，并触发下游动作（如发送邮件通知供应商、生成待收货任务）。
• 金额校验引擎：收到一张发票，引擎自动执行：
  1. 根据invoice.po_id找到对应订单；
  2. 计算订单行项目的含税总金额；
  3. 与发票invoice_amount比对，允许±0.01元误差（四舍五入导致）；
  4. 若差异超限，自动标记为'pending_verification'，并通知财务复核，绝不自动入库。
• 供应商准入校验：采购员新建订单时，选择供应商，引擎实时调用风控接口，检查该供应商近3个月的交货准时率、质量合格率、诉讼记录。若低于阈值，弹窗警告：“该供应商近3月准时率仅72%，低于85%标准，是否继续？”——把风控前置到录入环节。

这套引擎的核心，是把散落在各处的if-else逻辑，集中、可配置、可审计地管理起来。规则变更，只需修改配置，无需发布新代码。

4.3 第三层：定时数据质量巡检——主动出击的“数字警察”

再严密的防御，也可能有漏网之鱼。数据在长期运行中，会因人为误操作、系统Bug、外部数据导入错误而滋生“坏数据”。必须有主动的、自动化的巡检机制。

我部署了一套每日凌晨执行的巡检脚本，覆盖关键指标：

这些脚本的结果，汇总成一份PDF日报，每天早上8点自动邮件发送给采购总监、IT负责人、财务负责人。数据质量不是“有没有问题”，而是“问题是否被及时发现和处理”。巡检不是找茬，而是建立信任。

4.4 第四层：全量数据审计日志——事后追责的“黑匣子”

当问题真的发生，比如财务发现一笔付款找不到对应发票，或者审计要求提供某张订单的完整操作记录，这时，没有审计日志，就是死局。

• 日志表设计：audit_log表，字段包括log_id,table_name（如'purchase_order'）,record_id（如'PO-2024-00001'）,operation（'INSERT','UPDATE','DELETE'）,old_values（JSON，更新前旧值）,new_values（JSON，更新后新值）,operator_id,ip_address,user_agent,log_time。
• 触发器实现：在每张核心表上，创建AFTER INSERT/UPDATE/DELETE触发器，自动将变更写入audit_log。触发器必须高效，避免拖慢主业务。我采用异步写入（如写入消息队列，由后台服务消费），确保主事务不受影响。
• 日志保留策略：核心表（订单、收货、发票）日志永久保留；辅助表（如审批流、附件）日志保留5年。所有日志加密存储，访问需单独授权。

有一次，某采购员被举报违规操作，领导要求查证。我们打开审计日志，精确到秒地还原了：2024-05-15 14:22:33，该员工将一张状态为'pending_review'的订单，通过后台接口直接更新为'confirmed'，绕过了审批流程。日志里清晰记录了操作IP、设备指纹、甚至他当时浏览器的User-Agent。证据确凿，问题当天解决。审计日志不是为了监控人，而是为了保护人——保护清白者，惩戒违规者，让每一次操作都可追溯、可担责。

这四层防御，不是锦上添花，而是采购系统生存的必需品。它们共同作用，让“采购信息记录相关表”从一个简单的数据容器，升华为一个值得信赖的业务中枢。没有这四层，再漂亮的界面、再快的响应，都是沙上之塔。

5. 实战避坑指南：那些只有老鸟才懂的“经验性”陷阱

理论讲完了，现在来点干货——那些不会写在教科书里，但每个做过采购系统的人，都踩过、或至少听说过的真实坑。这些坑，往往源于对业务理解的偏差、对技术边界的误判，或是对人性的低估。分享出来，不是为了吓唬人，而是帮你绕开弯路，少走几年冤枉路。

5.1 坑：把“采购员”当一个角色，而不是一个“组织单元”

很多系统设计，purchase_order.created_by字段直接存采购员的user_id。看起来很合理。但现实是，采购工作高度依赖协作。一张大订单，可能由A采购员发起，B采购员比价，C采购员谈判，D采购员跟单。如果只记一个created_by，就丢失了完整的责任链。更糟的是，当A离职，他的user_id失效，所有他创建的订单，created_by字段就变成了一个无效ID，查询报错，报表统计失真。

我的解法：

• 引入procurement_team（采购组）概念。每张订单，关联一个采购组ID（如'RD_Materials_Team'），该组有组长、成员、职责分工。
• purchase_order表里，存team_id，而非user_id。
• 同时，建order_activity_log表，记录每一次关键操作：'initiated_by','quoted_by','negotiated_by','received_by'，每个操作都关联具体user_id和时间。
• 这样，既能按采购组统计业绩，又能精确追溯每个环节的责任人。采购组是稳定的，人是流动的，系统设计要拥抱变化。

5.2 坑：认为“附件上传”只是个功能，忽略了它的合规性

采购单据的附件——合同扫描件、质检报告、物流单、发票PDF——不是可有可无的补充，而是法律效力的核心组成部分。很多系统把附件存在服务器文件夹里，数据库只存个路径。结果呢？服务器磁盘满了，附件批量丢失；迁移服务器，路径变了，所有附件打不开；更严重的是，PDF附件里可能包含敏感信息（供应商银行账号、产品配方），明文存储，安全风险巨大。

我的解法：

• 附件必须存入对象存储（如MinIO、阿里云OSS），数据库只存bucket_name、object_key、file_hash（SHA256）、file_size、content_type。
• 所有附件上传，强制OCR识别（用Tesseract或商业API），提取文字内容，存入attachment_ocr_text字段。这样，审计时可以直接全文搜索“保密协议”、“独家供应”等关键词。
• PDF附件，强制添加数字水印：在每一页右下角，用半透明字体叠加“[公司名] - [订单号] - [生成时间]”。水印内容不可编辑、不可删除，是防伪的铁证。
• 附件访问，必须鉴权：用户请求下载附件时，后端生成一个有时效（如1小时）、带签名的临时URL，而不是直接暴露OSS的公开链接。杜绝未授权访问。

5.3 坑：追求“零代码配置”，结果配置比代码还难维护

低代码平台很火，采购系统也常被要求“采购经理自己配置字段、流程”。理想很丰满，现实很骨感。我见过一个项目，采购总监兴致勃勃地在后台拖拽，配置了一个“三级审批流”：部门经理→采购总监→财务总监。结果上线后，他发现：

• 无法设置“财务总监审批时，必须看到发票扫描件”；
• 无法定义“若部门经理24小时未审批，自动转给其上级”；
• 更无法处理“某类高价物料，需额外增加法务审核环节”。

最后，所有这些需求，还是得找开发写代码。而那个“零代码”配置界面，因为过于复杂，采购总监自己都弄不明白，反而成了新的学习成本和故障源。

我的解法：

• 核心业务逻辑（状态流转、金额校验、供应商准入）必须代码化、版本化，用Git管理，Code Review，CI/CD发布。这是系统的“心脏”，不容妥协。
• 可配置项，只开放真正安全、高频、低风险的：如审批流的“审批人列表”（从员工主数据中选择）、邮件模板的“收件人变量”（{approver_email}）、报表的“默认筛选条件”（status='delivered'）。
• 所有配置变更，必须记录在config_audit_log表中，谁改的、改了什么、何时改的，一目了然。配置不是魔法，它也是代码，需要同等对待。

5.4