招投标这件事，麻烦的从来不是"投不投"，而是"记不住"
很多企业的招投标管理，实际是靠三样东西撑着的：项目经理手机里的微信聊天记录、商务专员桌上的一份 Excel、财务账上的几笔转账。单看每一处都能查到一点信息，合起来却拼不出一个完整的项目。
于是出现了几种很典型的场景：
- 一个季度交了七八笔投标保证金，到了要催退的时候，没人说得清哪几笔已经退回、哪几笔还挂在招标代理或交易中心的账上；
- 开标前一天才发现标书还没买、法人授权书已经过期、投标文件还没走用印审批；
- 中标了，合同签下来，执行时才发现投标时答应的工期、质保、让利条款，和合同里写的不完全一致，当初的承诺记在谁的本子上没人知道；
- 同一个客户第三次来招标，前两次为什么没中，谁都说"好像是价格问题"，没有可查的原因记录。
这些问题的共同点不是"没有系统"，而是没有一个把"一次投标机会"当作一整条线来记的地方。招投标台账要解决的，就是让每一个项目从报名到结果、每一笔钱从缴出到退回，都能被追到人和日期。
第一件事：把主表定在"投标机会"上，而不是"投标动作"上
建表最容易踩的坑，是把"发标书""交保证金""开标"这些动作当成记录对象，做出一张流水表。流水表能记事，但统计不了——你没法从里面算出"今年投了 30 个项目、中了几个"。
正确的切入点是：一次投标机会就是主表的一行。这一行代表一条完整的生命周期：报名、获取招标文件、缴保证金、递标、开标、出结果、归档。主表挂住的是这个项目本身，所有动作都是挂在它下面的记录。
这里有一个必须提前想清楚的设计决定：标段要不要拆子表。
一个招标项目常常分几个包（标段），不同包的报价、保证金金额、甚至中标结果都可能不一样。如果只做主表一个"保证金金额""投标报价"字段，两个包就只能记一个数，或者拆成两条主表记录——前者丢信息，后者会让"投了几个项目"的统计翻倍。
所以：主表 = 一个招标项目，标段子表 = 项目下的每个包，一包一行。报价、包内保证金、包内结果记在标段子表上；项目级的信息（招标方、招标编号、招标代理、报名截止）留在主表。
这条规则还有一层用意：统计投标数量时按主表算，统计标的金额时按标段算，两个口径不会互相污染。
第二件事：保证金绝不能只放一个金额字段
保证金是招投标里最容易出钱的地方，也是最不适合用"一个字段"表达的地方。
原因很实在：
- 一笔保证金常常分批退回——先退大部分，剩下的按扣罚规则留一部分，过一段再退；
- 收退对象可能是招标方、招标代理，也可能是公共资源交易中心，钱到底在谁手上，要看缴纳方填的是谁；
- 财务要的是"发生额加总"，而不是"当前还剩多少"。
因此保证金要单独一张保证金流水表：一次缴纳一行，一次退回一行，只增不改。退回不是去改缴纳那一行的状态和日期，而是新增一行负数或"退回"方向的记录。这样任何时点的在途金额都可以由流水推导出来，未来出现争议也能看到"先缴、后部分退、再退还剩余"的完整过程。
主表上可以有一个"在途保证金"的汇总展示，但它是从流水算出来的，不是手工填的。手工填的汇总数字，三个月后一定和流水打架。
顺带一个容易混的决定：保证金和标书费、代理服务费要分表。保证金是往来款，原则上要退；标书费、图纸费、代理服务费是费用，不退。混在一张表里，"还有多少钱在别人手上"这个数就永远算不准，年度费用统计也会被往来款稀释。
第三件事：状态用字典定死，关键日期拆成多个字段
招投标的状态名称在不同企业叫法差别很大，但在一个企业内部必须统一。做法是把状态全部放进数据字典集中维护，例如：待报名、已报名、已购标书、已缴保证金、已递标、已开标、已中标、未中标、废标、已归档。字段引用字典选项，不许自由输入。
这样做的好处不在录入时，而在半年后：按状态筛"已递标未开标"能一条不漏，按原因统计"未中标"能分组出图。如果状态是自由文本，"已递标""已投标""标书已交"三种写法会把报表撕成三份。字典的统一维护方式可以参照数据字典：管好下拉选项的统一口径，同一套选项在 PC 与手机端共用。
第二个决定：关键日期不是"一个截止日期"，而是一组日期。至少包括：报名截止、招标文件获取截止、答疑提问截止、保证金到账截止、开标时间。每个日期都有自己的提前提醒量，混成一个字段，提醒就只能挑一个算。
第三个决定：编号要留两个。内部立项编号由企业自己编，可以用来串内部费用与审批；招标编号是招标方或交易平台给的，规则不由你定，有时要到开标后才拿到全称。两者合一个字段，迟早会出现"编号被覆盖，历史对不上"的情况。
第四件事：结果与原因要结构化，中标要能转出去
投标结果不能只记"中标/未中标"四个字。未中标原因建议做成字典分类，例如：报价偏高、资质不符、技术分偏低、业绩不足、响应文件不符合要求（废标）、招标取消。原因一分类，才能回答"我们到底输在哪"，也才能在同一个客户下次招标前提醒相关人。
中标这个状态还需要一个出口：转合同台账。注意这里不是把中标信息复制成一份合同，而是保留两边的关联——投标时的承诺（工期、报价、质保、付款条件）留在招投标记录里，合同的实际条款记在合同台账上，两者用项目编号关联，执行到有争议时可以回头对。合同后的日期跟踪与到期预警做法，见合同台账与到期预警：关键日期不再靠人记。
最后一件事是附件。招标公告、招标文件、答疑澄清、投标文件、开标一览表、中标通知书，逐份登记并挂到对应项目上，文件本身走平台的文件上传与存储能力。贴在微信群里最大的问题是：换个人接手，找不到那一版。
页面怎么组织：一个角色看一个视角
同一份数据，五个人关心五件不同的事。页面设计的目标不是做一个"什么都有"的表，而是让每个人打开就看到自己该处理的那几条。
投标专员 / 项目经理视角：项目一览 + 项目详情
一览页按状态分组呈现，最上面是"近期要动的"：报名即将截止、保证金未缴、开标在本周的。列表只放能定位一行的字段——项目名称、招标方、开标时间、状态、负责人，不要在列表里铺二十列。
点进详情页，上面是项目主信息（含两个编号、招标方、代理、负责人、当前状态），下面用页签挂子表：标段、保证金流水、费用、附件、节点记录。这样一屏之内既有结论（这个项目现在处在哪一步），也有证据（每笔钱、每份文件、每次状态变化）。
财务视角：保证金台账与在途清单
财务不需要看项目故事，需要看钱。核心两页：
- 保证金台账：按缴纳方向列出所有未结清流水，可以按招标方、按代理机构、按项目筛选；页脚给合计，用于和银行流水对账；
- 待退清单：已开标但保证金尚未退回的项目，按开标时间倒序，一眼看出哪些拖得久。超期天数阈值按企业自己的催收习惯设，系统只负责把超过阈值的那几条标出来，不替你定多少天算逾期。
商务负责人 / 管理层视角：统计看板
看板回答三个问题：投了多少、中了多少、钱压了多少。按区域、按行业、按招标方分组统计投标数与中标数，未中标按原因分组，在途保证金总额单列一个数字。统计口径固定按主表算项目数、按标段算子项数，这一点在页面说明里写清楚，避免对外汇报时两个数对不上。
资质与用印协同视角
投标能否参加，常常卡在企业资质与人员证书的有效期上。这部分数据通常有各自的台账（人员资质见员工培训与资质证书：记录、到期与复训提醒，用章见用章与证照借用：谁借的、盖什么、何时还都留痕），招投标页面上不必重建，只做一件事：在项目详情里能看到关联资质是否在有效期内，投标文件用印走既有的用印审批。两本账各管各的，靠关联而不是靠合表，是这里最重要的取舍。
四类自动化：让"该提醒的人"被提醒到
台账只是记录，真正省下心力的是自动跑的那几件事。平台提供的工作流、定时任务、数据流规则和审计日志，恰好覆盖招投标里最需要自动化的四类动作。
第一类：关键日期提醒（定时任务）
用定时任务按日扫描主表上的各组关键日期，在报名截止、招标文件获取截止、保证金到账截止、开标时间前分别按设定的提前量发出提醒，收件人是项目负责人 + 备份人。提前量不写成固定值，按企业习惯在任务里配（例如开标前 3 天、保证金到账前 5 天）。同一项目多次提醒要有去重，避免一天进来七八条同样内容。定时任务的配置方式见工作流与定时任务：让重复性工作自动跑。
第二类：状态推进与联动（数据流规则）
数据流规则做的是"条件满足就自动做一件事"。招投标里典型的有三条：
- 状态改为"已开标"且结果为空 → 自动给负责人发一条待办，要求补填结果；
- 保证金流水累计退回金额达到应缴金额 → 自动把该项目的保证金状态置为"已退清"，不用财务再手工点一次；
- 状态改为"未中标"且未填原因 → 自动锁定归档动作，先补原因才能归档。
这类规则的价值在于把"流程要求"变成"系统约束"，而不是靠人记。需要注意边界：规则只做状态与字段的自动更新和通知，不替人做业务判断。
第三类：审批留痕（工作流）
三类申请值得走审批：投标立项（投不投、谁负责、预计投入）、保证金付款申请（金额、收款方、账户）、投标报价与让利（涉及价格底线）。审批流里保留每一节点的处理人和意见，事后追责或复盘时，能回答"这个价格是谁批的"。审批退回要有意见必填，不允许空退。审批流如何搭，见审批流落地：请假、报销与通用申请怎么在线化——招投标的审批形态和通用审批一致，区别只在表单字段。
第四类：敏感操作留痕（审计日志）
招投标数据里有两类信息很敏感：报价与保证金金额、以及投标文件的版本。对这两类数据的修改、状态回退、附件删除，应全部落在操作审计日志里，可按人、按时间、按项目导出。日志的意义不在于追责，而在于当出现"数字怎么变了"的疑问时，能给出确定答案。审计日志的查看与导出见AI 监控与审计日志：看清平台里发生了什么。
权限上还有一个必须做的动作：报价、让利、保证金金额这类字段，对不参与投标决策的角色应做字段级可见性控制，而不是靠"别点开"。角色与授权方式见角色与权限配置：从内置角色到自定义授权。
移动端怎么配合：不是把 PC 表压缩成小屏
手机端在这套台账里只承担三件事，其余都留在电脑上。
第一件：现场能查。 开标当天、答疑会上，需要临时核对信息——这个包的报价、谁是被授权代表、保证金到账了没、招标代理联系人是谁。手机端提供的应是"按项目一屏看完"的详情视图，而不是让用户在窄屏上横向滚动看大表。
第二件：现场能记。 开标结束后，把开标一览表拍照上传、把本轮报价与结果当场录进去、状态推到"已开标"。这件事如果等回办公室再做，隔一天就有细节记不清。照片走附件上传，和 PC 端存的是同一份文件。
第三件：随时能批。 保证金付款申请、投标报价与让利审批，多数时候等不到人回办公桌。手机端审批卡片上应直接显示关键字段（金额、收款方、项目、当前报价），避免审批人点开附件才知道批的是什么。
要注意的是，手机端不承担批量录入和复杂筛选。一次导入历史项目、按月核对保证金流水这类工作，仍然在电脑端做。同一模块的手机会话与 PC 保持一致，发布前需要确认移动端页面已同步，做法见移动端使用指南：工作台、模块页与手机上的 AI 构建。
上线前必须过的六项检查
台账类系统最容易失败的地方，不是功能不够，而是"上线那天的数据是空的"或者"状态字典没定死"。按下面顺序过一遍，能避掉大部分返工。
一、状态字典先定死，再建表。 把企业实际使用的状态名全部列出来，去重、合并同义项，确认"从报名到归档"的完整路径与每步责任人。字典改一次，历史数据的分组就变一次，所以这一步宁慢勿快。字典维护方式见数据字典：管好下拉选项的统一口径。
二、历史数据只导有用的部分。 不建议把五年的投标记录逐条补录——成本高、错漏多、也没人查。合理范围是：近一到两年的项目 + 所有保证金未结清的历史项目（这一项最重要，因为钱还在外面）。历史项目可以用 Excel 直接导入，见用 Excel 一步建模块：从表格到可用的业务系统。
三、唯一约束要设。 招标编号 + 标段号在标段子表上设唯一校验，防止同一个包被两个人各建一次，导致投标数与保证金重复统计。
四、权限按角色过一遍。 至少分成四类：能看到全部金额的（财务、商务负责人）、能看到自己项目的、只能看进度不能看报价的、只能看附件不能改数据的。用真实账号逐一登录验证，而不是看配置清单。
五、提醒提前量与超期阈值由企业定。 系统提供配置项，不内置"法定"或"行业标准"数值——开标前提醒几天、保证金超多少天算待催，各家企业习惯不同，写死在系统里反而会被绕过。
六、发布前跑预检，并确认移动端同步。 模块发布前做一次预检，检查字段、必填、权限与手机端页面是否就绪，进入正式环境后再用一个真实项目走通一遍全流程（报名→缴费→递标→开标→补结果→归档），才算上线完成。这一步见模块的测试与发布：预检、挂载菜单与移动端同步。
之后可以怎么延伸
台账跑顺之后，通常有三条延伸路径，都是加"关联"而不是重做系统。
第一条：往钱的方向延伸。 保证金本质是往来款，在途与退回可以和应收应付台账打通，形成"企业还有多少钱在别人手上"的统一视图。这部分的建法与口径，见应收应付：老板最关心的一本账，业务台账怎么建。
第二条：往后端执行延伸。 中标之后是项目执行：进度、材料、分包、结算。招投标记录在这里的角色是"承诺出处"——合同工期为什么是这个数，回到投标答问里能找到依据。执行侧的做法见项目台账：进度、投入与里程碑一本账。
第三条：往复盘延伸。 积累一年以上数据后，可以按招标方、按区域、按标段类型看中标率与报价区间，作为下一次是否投标、报价定在什么区间的参考。这类统计只能作为参考，不构成对结果的预测——中不中标还取决于资质、业绩、评审偏好等系统之外的因素。
这套台账不做什么
把边界说明白，比把能力说满更有用。下面这些不在本方案范围内：
- 不做招标文件的自动解析与评分预测。 平台不替代人读标书、判断评委偏好；
- 不做电子投标的 CA 证书、加密上传、电子签章等环节。 这些环节依赖招标方指定的交易平台与专用硬件，不在本台账内处理；
- 不做与招标网站、公共资源交易平台的数据自动抓取。 项目信息仍需人工录入或批量导入；
- 不做保证金利息与扣罚金额的自动核算。 退多少、扣多少以招标方与代理机构的书面通知为准，系统只记录实际收退金额与依据文件；
- 不替代法务与招标代理对合规性、废标风险的判断。 系统能做的是把节点、文件、审批留痕，让判断有依据；
- 不承诺投标结果。 台账解决的是"记不住、追不回、对不上"，不是"提高中标率"。
一句话记法：主表管项目，子表管标段，钱走流水只增不改，日期分组提醒，结果原因归档，中标转合同关联不合并。