法律纠纷与案件台账：立案、开庭、结案都有节点

纠纷一登记就建档，诉讼与仲裁分别跟踪；开庭、举证、上诉期限进关键日期表并提前提醒；律师费与诉讼费按案件归集，结案后归档裁判文书并出统计。这篇讲法务案件台账怎么用 AI 构建器搭起来。

法务台账真正的难点：不是"记下来"，而是"节点不丢"

企业里的纠纷信息通常是这样活着的：一封业务部门转来的邮件，一段和外部律师的微信沟通，一个存在共享盘里的判决书扫描件，还有承办人脑子里记着的"下个月十二号开庭"。平时看不出问题，一旦老板在周会上问"我们现在有几起官司、最坏可能赔多少、下个月有哪些关键期限"，往往要拉三个人对半天，还未必对得上。

对法务岗来说，风险不在"有没有记录"，而在三个具体的地方：

关键日期靠人记。举证期限、答辩期、开庭时间、上诉期、申请执行期限，这些节点错过一次通常不可补救。靠日历提醒是单点的——人休假、换岗、离职，提醒就断了。
成本算不清。律师费、诉讼费、保全费、鉴定费、差旅，分散在报销单和律所账单里。单个案件花了多少，年底要复盘时只能翻凭证。
同类纠纷反复发生。哪种类型的纠纷最多、集中在哪个客户或哪个业务环节、我方作为原告和作为被告的比例各是多少，没有结构化数据就出不了这张图，也就谈不上源头治理。

案件台账要解决的正是这三件事：节点有人管、成本归得清、复盘有数据。它不是把纸质台账搬到线上，而是把"一起纠纷"从一条文字记录，变成一条能挂子表、能跑提醒、能出统计的主记录。

第一步：把"一起纠纷"定义成一条主记录

落地时最容易跑偏的动作，是一上手就设计字段。更稳的顺序是先回答一个问题：这个系统里"一条记录"代表什么？

在案件台账里，一条主记录代表一起独立的纠纷，而不是一次开庭、一份文书或者一笔费用。这几种东西都会随着案件推进不断新增，所以要拆成子表挂在主记录下面。这个判断一旦定错（比如把每次开庭做成一条主记录），后面统计涉诉金额、统计案件数量都会重复计数。

主记录上要有的是那些"一辈子基本不变"的信息：

内部编号 + 正式案号。案件往往先内部立项、后收到法院或仲裁机构的受理通知。所以编号要两个字段：内部编号在登记时生成，正式案号留空，受理后补填。只留一个字段，实际用起来一定别扭。
案件类型：诉讼、仲裁、执行、非诉协商、劳动仲裁等。这类选项集中放在数据字典里维护（数据字典就是全公司共用的下拉选项清单，改一处全局生效），不要直接在表单里写死。
我方角色：原告、被告、第三人、申请人、被申请人。
对方主体：自然人还是企业不确定，建议用平台的引用引擎关联到已有的客户、供应商档案（引用引擎就是"下拉时直接取别的模块里已存在的数据"），避免同一个人在三张表里被录成三种写法。
涉案金额、币种、受理机构、承办人、协办律师。
当前状态：登记待立案 → 已立案 → 审理中 → 已判决/已裁决 → 执行中 → 已结案 → 已归档。状态也用字典管，固定几态，别让每个人自己造词。
结果字段：胜诉、部分支持、败诉、调解、撤诉。判决书出来前可以留空，出来后回填。

主记录的价值在于：它是全公司唯一的"案件清单"。有了这一条，后面所有的提醒、费用、统计才有挂靠点。

底表怎么拆：一张主表，四张子表

真正让法务台账好用的是子表。拆法上有几个关键决定：

关键日期表（最重要的一张）。一个案件不止一个日期。开庭、举证截止、答辩、上诉期届满、申请执行期限、鉴定结论出具日——这些事件性质完全不同，不能塞成主表上的几个固定字段（案件一变类型就不够用）。做成子表，一行一个日期，字段包括：日期类型（走字典）、具体日期、提醒提前天数、是否已完成、完成时间、备注。这样"提前几天提醒"是按日期类型分别设的，上诉期和开庭本来就不该用同一个提前量。

费用表。一行一笔支出：费用类型（律师费、诉讼费、保全费、鉴定费、差旅）、金额、发生日期、对方、关联付款单、发票附件。费用记录只增不改，录错了另起一行做更正（负数冲抵或备注更正原因），不要直接改历史数字——否则案件成本永远对不上财务账。

进展与文书表。一次开庭、一次调解沟通、一份裁决书送达，都是一行：发生日期、类型、内容摘要、承办人、附件。裁判文书扫描件、送达回证、往来函件通过平台的文件模块上传挂在记录上，随时可下载。同样只增不改。

关联台账表。为了把案件放回业务上下文，建议留出关联字段：关联合同编号（指向合同台账）、关联客户/供应商、关联项目、关联订单。这样"这个客户第几次被起诉"这类问题才查得出来。合同这边的到期与关键日期管理，可以先用现成的做法，见合同台账与到期预警与合同到期提醒怎么设置。

四张子表有一个共同约束：都是"只增不改"的记录表。法务记录的价值在于可追溯——谁在什么时候改了什么，和内容本身一样重要。

页面按角色分：同一条数据，四种看法

案件数据是敏感的，页面不能只做一个"案件列表"给所有人。合理的做法是按角色分视角，用权限控制各自能看到什么（权限按角色、部门配置，具体做法见角色与权限配置）。

法务专员视角：我的待办。 打开就是"我承办的案件 + 本月关键日期"。列表按最近到期日排序，超期的用颜色标出来。详情页是主战场：上半部分是基本信息与状态，下半部分四张子表分页签——关键日期、费用、进展文书、关联事项。

法务负责人视角：全公司视图。 需要的不是明细，而是分布：按案件类型分组的在办数量、按涉案金额分档的分布、按我方角色（原告/被告）的比例、本月新增与结案数。再配一张"临近节点清单"，把未来三十天内到期的关键日期集中列出来，谁承办、还剩几天一目了然。

财务视角：费用归集。 一张按案件汇总的费用表：已发生律师费、已付诉讼费、待付金额。对外付款申请从这一页发起，和报销流程接上。

管理层视角：涉诉概况。 只关心三件事：在办案件数、涉诉总金额、重大案件（按金额阈值筛）进展。这一页适合做成首页上的小组件，不用进台账。

页面设计上有一个容易被忽略的细节：状态不要靠人手动切换而不留痕。每次状态变化应当自动记录变更时间与操作人，诉讼改判、撤诉、执行中止这类"回退"也要能记录，否则时间线是断的。

自动化四类：让系统替人盯节点

台账只有"能查"是不够的，它的核心价值在"会提醒"。用平台的四类自动化能力把节点管起来：

一、审批流。 法务场景里几个典型流程值得上线成审批：

立案申请：业务部门提报纠纷线索 → 法务审核是否需要正式立案 → 决定是否外聘律所。
外聘律师与费用预算：超出一定金额的委托走上级审批（阈值按企业自有标准定）。
和解与调解方案：涉及金额减免的方案必须留审批记录，避免"私下承诺"。
费用支付申请：与财务付款流程衔接。

审批流的定义与节点配置在工作流可视化编辑器里有完整说明。

二、数据流规则。 数据流规则就是"满足条件就自动改数据"的规则（条件触发、字段自动赋值），不需要写代码。适合这里的场景：

状态改为"已立案"时，自动回填立案日期。
状态改为"已结案"时，自动回填结案日期，并把本案所有未完成的关键日期标记为"已失效"。
费用子表新增一行时，把该行金额累加回主记录的"已发生成本"。
判决结果回填后，按"胜诉/部分支持/败诉"自动打上统计标签。

三、定时任务。 这是"关键日期不丢"的兜底。每天定时扫一遍关键日期表，把"距到期日 ≤ 提前天数且未完成"的记录挑出来，推送提醒。规则细节是：提前量按日期类型分别设（例如开庭提前 7 天、上诉期提前 5 天，具体天数按企业自有标准定），并且到期当天再推一次。另外每月初跑一次汇总：上月新增案件、结案案件、费用发生额，生成给负责人的月度清单。定时任务的配置方式见工作流与定时任务。

四、消息通知。 提醒要送到人。站内信加邮件是稳妥组合，重要节点（开庭、上诉期）可以再走短信。提醒对象不只承办人，要同时抄送负责人——人休假时链条不能断。

这四类自动化的分工可以记成一句话：审批管"谁批准"，数据流管"自动填"，定时任务管"到点提醒"，通知管"送到人"。所有自动化动作在平台的审计日志里留痕，出问题能倒查，见 AI 监控与审计日志。

移动端：开庭当天才是真正用得上手机的时候

法务人员的场景有一半在外：去法院立案、开庭、去仲裁机构提交材料、见外部律师。这些时刻坐在电脑前是不现实的，所以移动端不是"顺手加一个"，而是这条链路上的一环。

手机端要用得上的四件事：

看今天的节点。工作台上直接显示"今日开庭 / 本周举证截止"，点进去是案件详情。
现场记录。开庭结束后在走廊里录一条进展：日期、内容摘要、下一步动作。累计成本自动刷新。
上传文书。立案回执、送达回证、判决书当场拍照上传，挂到对应案件的文书子表上。回到办公室不用再找文件。
审批与提醒。负责人在手机上批准和解方案、批费用预算；关键日期提醒以消息形式推到手机。

移动端页面的做法是：平台在发布 PC 页面时会同步生成移动端页面，字段与流程一致，按手机屏幕重排布局。具体同步机制与移动端工作台的组织方式，见移动端使用指南。

上线前查这八项

台账看起来简单，上线前值得逐条过一遍，避免用起来才发现缺口：

四张字典先定。案件类型、案件状态、我方角色、费用类型，先在数据字典里建好再开始建表，别在表单里写死选项（数据字典的维护方式见数据字典）。
关键日期必填项清单。由法务负责人定：哪几类日期一旦本案适用就必须填。这条不用技术判断，是管理约定。
编号规则。内部编号生成规则（前缀+年份+流水）与正式案号字段分开，别混用。
权限边界。案件默认不公开：普通人只看自己提报的案件，法务看本部门，负责人看全公司。测试时用两个不同角色各登录一次验证。
提醒链路验证。拿三起真实案件录进去，把提前量临时改成 1 天，确认提醒确实到人、确实只推一次。
附件与文件规范。裁判文书扫描件体积大，约定格式与命名（案件编号+文书名+日期），文件存储走平台文件模块。
存量案件导入。手上正在办的案件用 Excel 一次导入（做法见用 Excel 一步建模块），先导主表再导子表，避免顺序错导致关联对不上。
发布前预检。上线前跑一遍平台预检，确认页面权限、移动端同步、菜单挂载都正常（流程见模块的测试与发布）。

还有一条经验：先在草稿数据上试运行两周，确认提醒没有误报、状态流转没有卡点，再把历史案件全量导入。这类台账一旦上线就是全公司的唯一口径，改起来成本比一开始多花两天高得多。

之后怎么延伸

台账跑顺之后，通常会长出三个方向：

往前接源头。案件关联到客户、合同、订单之后，可以反查"哪类客户、哪个业务环节的纠纷最多"，把治理动作往前推到合同条款和交付验收环节。
往后接执行与收款。胜诉进入执行阶段，可以把执行进度和应收账款催收打通，避免"赢了官司拿不到钱"没人跟。
沉淀处置口径。结案后写一段复盘结论（一类纠纷一段），积累成内部案例库。同类纠纷再来时，先看历史怎么处置、结果如何，新人不必从零摸索。这一层可以先做成结案记录的必填项，不必单建模块。

如果同时还在管合同和供应商，几个台账之间的关联字段（合同编号、供应商编号）尽量保持一致，后面才能做交叉统计。