智能报销系统统一产品需求文档
一份文档统一描述智能报销业务系统、独立 Dify 发票审核 Workflow、员工报销助手 Chatflow 与报销分析助手；四者共享受控业务数据，但权限、凭证、会话和职责严格隔离。
1. 发布快照
已联调
发票全生命周期
上传、OCR、L1–L3预审、入单、L1–L4终审、占用与付款归档。
独立 Workflow
PaddleOCR
Dify 负责文件解析和结构化提取，后端负责确定性审核。
双 Agent
助手与分析
员工助手负责问答，报销分析助手负责权限范围内的只读分析。
Demo 模式
访客管理员
独立共享演示身份，可测试完整业务功能，不复用真实 admin。
本版核心变化：发票审核 Workflow 与最新已发布编排对齐：接收
user_id、invoice_files、audit_payload_json 和 report_id 四项输入，经 PaddleOCR-VL 与多模态字段整理后执行输入结构校验及 L1–L3；L4 使用同一制度知识库分别检索分类额度与例外材料，合并证据后由确定性代码完成制度、额度、例外与预算校验，最终仅输出严格 result_json。| 能力 | 当前状态 | 员工可见结果 | 关键边界 |
|---|---|---|---|
| 发票夹 | 服务端可用 | 最近加入、状态、预审结论、预览、重试、删除、入单 | 不再以浏览器 localStorage 作为正式数据源 |
| 发票识别 | PaddleOCR 已接入 | 发票号、日期、购销方、金额、税额、税率、费用信息 | 识别不等于审批；低质量结果进入待修改/重试 |
| L1–L4 | 后端确定性规则 | 分层结论、风险等级、修正建议和最终流转状态 | 大模型不得改变金额、重复、预算和状态结论 |
| 员工报销助手 | V10 Chatflow 已发布 | 制度问答、交互式类型澄清、附件排查、状态解释和人工分流 | 技术/制度双知识库隔离；不调用、不占用、也不修改发票审核结果 |
| 报销分析助手 | 只读分析 | 趋势、预算、风险、合规和管理建议 | 不能审批、付款、推送 OA 或修改配置 |
| 税务验真/OA/付款 | 接口边界 | Demo 展示流程和状态 | 生产仍需企业外部服务和幂等补偿 |
2. 产品定位、目标与范围
2.1 产品目标
- 员工在上传发票时尽早发现字段、金额和重复风险，减少报销单退回。
- 报销单提交时使用数据库最新事实完成 L1–L4终审，防止并发重复报销和过期预算结论。
- 财务人员获得可追溯的审核依据、占用记录、预算版本和分析视图。
- 将问答型 Agent、分析型 Agent 与确定性审核系统解耦，避免 AI 越权。
2.2 角色
| 角色 | 主要能力 | 数据范围 | 限制 |
|---|---|---|---|
| 员工 | 上传发票、维护发票夹、新建和查询本人报销、使用员工助手 | 本人发票与报销 | 不可审批，不可查看他人敏感信息 |
| 部门负责人 | 审核本部门单据、查看本部门预算 | 本人及授权部门 | 不可修改税务与全局预算规则 |
| 财务经理 | 人工复核、查验、规则与预算分析、使用报销分析助手 | 授权公司/部门范围 | 关键写操作仍走业务接口和审计 |
| 系统管理员 | 用户、部门、权限、配置和运行维护 | 管理员授权范围 | 不能绕过审核状态机直接制造付款结论 |
| 访客管理员 | 体验 Demo 内完整管理员业务功能 | 共享演示身份和演示数据 | 不是生产匿名管理员；不复用真实 admin 凭证 |
2.3 非目标
本版不把大模型作为审批人，不承诺完成真实税务验真、企业 OA、银企付款或生产级匿名开放；不允许在浏览器保存 Dify 长期密钥。
3. 统一架构与四类能力边界
业务系统
智能报销系统
身份、发票夹、报销单、审批、预算、规则、状态机、审计和 API。
最终业务事实源Dify Workflow
发票审核工作流
PaddleOCR 文档解析、字段整理、结果解释和运行流水。
不维护业务状态Dify Chatflow V10
员工报销助手
技术/制度分流、可点击类型澄清、填报帮助、状态解释和人工分流。
独立会话与双知识库只读分析
报销分析助手
趋势、预算、风险、合规和经营分析。
只读授权数据强制隔离：发票 Workflow、员工助手和报销分析助手分别使用独立 API Key、应用地址、会话和配置。报销分析助手只读取授权、脱敏的数据快照，四者不得通过 Prompt 绕过后端规则和权限。
3.1 数据流
浏览器上传附件与业务输入
后端 API校验身份、附件归属和哈希
Dify/PaddleOCR一次识别并返回 invoices
确定性规则L1–L4与占用事务
MySQL发票、报销、预算和审计事实
员工/财务看到可解释结果并按权限处理
3.2 Dify 发票审核 Workflow 实际快照
下图记录当前已发布发票审核工作流的实际编排：四项输入依次进入 PaddleOCR-VL、多模态票据字段整理、输入与身份结构校验以及 L1–L3；随后由“制度分类与额度检索”和“制度例外与材料检索”查询同一个制度知识库，合并两路证据后进入 L4 确定性终审，再完成确定性结果聚合、只读解释、结构化封装和严格 JSON 输出。宽图可横向滚动，点击可查看原始分辨率。
result_json，生产业务事实仍以后端数据库与确定性审核规则为准。边界提示：快照中的大模型节点只整理 OCR 字段与解释确定性结果；金额税额、历史重复、发票占用、预算和最终状态不得由模型改写。
4. 发票上传预审—报销单终审主流程
4.1 阶段一：上传发票
1. 保存附件PDF/JPG/PNG，绑定当前用户
2. SHA256同用户同文件直接复用
3. PaddleOCR文档解析与票面提取
4. 字段规范化日期、号码、金额、税额
5. L1/L2完整性与金额税额
6. L3预检历史有效单据与占用
7. 类别初筛可推荐，不做正式预算结论
8. 保存发票夹通过、待修改、重复或重试
4.2 阶段二：提交报销单
1. 选择发票仅“已审核待入单”
2. 不重复 OCR按 invoiceAssetId 取可信字段
3. L1复核主表、引用、附件和日期
4. L2复核发票合计与报销总额
5. L3终检单内、历史和并发占用
6. L4终审当前预算、类别和规则
7. 事务提交写占用、审核结果和状态
8. 部门/人工正常审批或财务复核
报销单内直接上传：新附件必须先完成阶段一；预审通过后自动加入当前报销单。未通过或 Dify 不可用时保留在发票夹，但不得形成未经预审的报销发票。
当前 Demo 入口口径：“我的发票”发票夹当前只承接常规电子发票。收据、地铁定额票等非常规票据在“新建报销”中通过“手动添加票据”补录并上传附件；Dify Workflow 已包含非常规票据识别与规则回归，但尚未形成与常规电子发票完全相同的发票夹直通体验。
5. 发票夹与 PaddleOCR 识别
常规电子发票上传
- 顶部“上传电子发票”按钮与识别区共用隐藏文件输入。
- 支持鼠标点击、键盘 Enter/Space、拖拽上传。
- 支持 JPG、PNG、PDF；附件先保存，再异步执行识别。
发票夹操作
- 查询当前用户的服务端常规电子发票记录。
- 支持预览、重试和未入流程记录删除。
- 已占用或已报销记录不可删除；原附件按审计策略保留。
非常规票据：收据、地铁票、纸质小票等当前不进入“我的发票”直通列表，而是在新建报销页手工添加。审核规则按
document_type 采用不同必填矩阵；缺少标准发票要素时不得伪造字段，应保留 OCR 证据并转人工复核。5.1 规范化票面字段
| 字段 | 来源 | 处理 | 入单保护 |
|---|---|---|---|
| invoiceNo | PaddleOCR | 去空格、连字符并转大写，保留原展示值 | 锁定，后端以资产记录为准 |
| invoiceDate | PaddleOCR | 中文年月日等格式转 YYYY-MM-DD | 锁定并检查未来日期 |
| sellerName / buyerName | PaddleOCR | 空白归一化，不确定时保持空 | 锁定 |
| amount / tax / total | PaddleOCR + 后端 | 数值化、两位小数、一致性校验 | 锁定，不接受客户端覆盖 |
| taxRate / invoiceType | PaddleOCR | 标准化；铁路客票执行 9%拆分校验 | 锁定 |
| costCenter / description | 模型建议 + 用户业务输入 | 允许确认和修改 | 唯一允许调整的业务字段 |
5.2 发票夹状态
识别中已审核待入单待修改疑似重复识别失败待重试已占用已报销
6. L1–L4 确定性审核规格
| 层级 | 上传阶段 | 提交阶段 | 失败动作 | 规则责任方 |
|---|---|---|---|---|
| L1 完整性 | 按 document_type 使用必填矩阵：常规发票校验票号、日期、金额、税额、附件；允许无日期的地铁定额票必须校验发票代码、发票号码和地铁开票印章 | 增加报销事由、部门、员工、费用分类和发票引用；收据等非标准凭证保留附件并进入人工复核 | 待修改或人工复核 | 后端确定性代码 + OCR 证据 |
| L2 金额税额 | 不含税金额、税额、价税合计；铁路票 9%拆分 | 再次核对全部发票价税合计与报销总额，容差 0.01元 | 待修改 | 后端确定性代码 |
| L3 重复发票 | 按票号和 SHA256 查询历史有效状态 | 单内重复、历史重复及事务级唯一占用 | 阻断提交或人工复核 | 数据库事实与唯一约束 |
| L4 制度预算 | 同一制度库双检索：分类额度 + 例外材料；两路证据先合并 | 代码节点按机器校验字段、提交瞬间部门、费用类别、身份、期间、有效规则和预算版本终审 | 检索不足不放行；预警进入部门审批；超额/缺预算转人工 | 知识库证据 + 后端确定性规则与活动预算版本 |
6.1 L4 阈值
低于 90%
正常
进入部门审批。
90%–100%
预算预警
带风险提示进入部门审批并提示财务。
超过 100%或缺预算
严重风险
不得套用默认预算，转财务人工复核。
模型禁区：大模型可以把确定性结果翻译为简洁员工提示，但不得修改
passed、status、riskLevel、金额、重复证据、预算结论或审批状态。7. L3 重复报销与并发占用
7.1 判定键
no:<规范化发票号>：去空格、连字符并转大写。hash:<SHA256>：合法的 64位小写十六进制附件摘要。- 任一键命中即可判为历史占用；同一报销单内还需检查重复票号和重复附件。
7.2 有效占用状态
待部门审批人工复核待查验部门审批通过已推送OAOA审批中审批通过已生成付款单付款中已付款
| 场景 | 处理 | 原因 |
|---|---|---|
| 只存在发票夹 | 不视为已报销 | 尚未形成有效报销占用 |
| 草稿或待修改 | 不占用；若由有效状态退回则释放 | 允许员工修正或重新提交 |
| 同一报销单重复提交 | 幂等，不将自己判为重复 | 按 report_id 排除自身 |
| 两个用户并发提交同一发票 | 唯一键保证最多一个成功 | 不能依赖先查后写的时间窗口 |
| 跨员工命中 | 仅提示“已被其他有效报销单占用” | 不泄露他人员工、部门和单号 |
| 已付款 | 永久占用 | 形成不可重复报销的最终事实 |
8. 发票与报销状态机
8.1 发票状态流
识别中附件已保存
已审核待入单L1–L3通过
已占用有效报销提交
已报销付款完成，永久占用
待修改/疑似重复修正或人工复核
识别失败待重试文件保留，可重跑
8.2 报销状态与占用动作
| 报销状态/动作 | 发票占用 | 发票夹状态 |
|---|---|---|
| 草稿、待修改 | 不占用或释放已有占用 | 恢复“已审核待入单” |
| 提交且 L1–L3通过 | 同一事务写入 invoice_claims | 已占用 |
| 待部门审批至付款中 | 持续占用并同步 report_status | 已占用 |
| 撤回、驳回到可修改 | 删除当前报销单占用 | 已审核待入单 |
| 已付款 | 永久保留占用 | 已报销 |
9. 员工智能报销助手 Chatflow
员工助手是已发布并嵌入 Demo 的独立 Dify Advanced Chat 应用，面向员工提供制度解释、操作帮助、本人进度指引和技术故障分流。它不是发票审核 Workflow，也不是最终审核器。
可以做
- 回答费用是否可报、金额上限、附件、票据和字段要求。
- 对餐费、交通、采购、发票及其他模糊问题显示可点击选项，并基于选择继续检索。
- 先按技术知识指导附件排查；完成排查仍失败时转 IT。
- 解释员工本人报销进度的查询路径和确定性退回原因。
不能做
- 不能审批、占用、释放或报销发票。
- 不能替代 L1–L4、预算、税务验真和付款状态机。
- 不能查看其他员工敏感数据，也不能伪造本人进度。
- 不能将制度问题交给技术知识库，或将技术故障交给财务人员。
9.1 身份、路由与知识隔离
- 后端根据登录身份生成可信、稳定、不可由前端伪造的
user_id；身份缺失或异常时直接转 IT，不继续回答。 - 业务路由明确区分
progress、technical_not_done、technical_escalate、technical、clarify和制度问答等路径。 - 技术检索节点只绑定系统技术知识库；制度检索节点只绑定报销制度知识库，禁止跨库补写和混用证据。
- 长期平台凭证只保存在服务端；浏览器只接收受控 WebApp 地址和压缩编码后的可信输入。
- 知识库发布、废止和版本变更可追溯；超时、空答或服务异常时明确提示不可用，不以静态答案冒充真实 Agent 输出。
9.2 员工报销助手 Chatflow 实际快照
下图为本次发布的 V10 Chatflow 全量编排：从可信身份、意图识别和业务路由，进入本人进度指引、技术知识检索与附件排查，或进入 9 组 Human Input 类型选择，再汇合到制度知识检索、回答生成、质检和必要重写。宽图可横向滚动，点击可查看原始分辨率。
边界提示：员工助手可以解释制度、指引操作和分流问题，但不能触发或修改 L1–L4 结论，也不能占用、释放或报销发票。图中 Human Input 仅收集员工明确选择，不作为审批或合规结论。
9.3 交互式分流与继续执行
可信输入登录身份映射为 user_id
确定性路由进度 / 技术 / 模糊 / 制度
Human Input缺信息时显示按钮
确定性转词按钮 ID 映射检索词
专属知识库技术与制度严格隔离
质检输出证据门禁与必要重写
| 路径 | 触发条件 | 节点行为 | 最终去向 |
|---|---|---|---|
| 本人进度 | “我的报销到哪里了”“目前什么进度” | 不检索制度，不猜测状态；提示进入“我的报销”按报销单查询 | 本人报销进度查询指引 |
| 一般技术问题 | 登录、页面、附件、提交等系统故障 | 标准化技术 Query → 技术知识库 → 技术证据门禁 → 证据充足性判断 | 有证据则回答；无证据进入排查或人工 |
| 附件上传失败 | 上传不了、传不上去、附件失败等表达 | 先检索技术知识；仍不能定位时给出格式、20 MB、刷新重登、网络和避免重复提交等文字排查 | “已完成仍失败”转 IT；“尚未完成”要求先排查；超时给出重新进入提示 |
| 模糊制度问题 | 只说餐费、交通费、采购、发票或“这个能不能报” | 按 clarification_kind 进入场景化按钮；选择后由 Code 节点生成确定性检索词 | 继续进入制度知识库，不在按钮节点无提示结束 |
| 明确制度问题 | 费用类型、身份和问题目标足够明确 | 生成明确问题检索词，经变量聚合器进入制度问答主链 | 制度回答、质检、必要重写和最终输出 |
9.4 Human Input 选项矩阵
| 表单 | 员工可点击选项 | 按钮数 | 后续处理 |
|---|---|---|---|
| 餐费场景 | 差旅伙食补贴、日常业务餐费、业务招待费 | 3 | 生成对应制度检索词 |
| 交通费用 | 差旅交通、市内交通补贴、出租车/网约车、高铁/动车、飞机 | 5 | 生成对应票据或补贴检索词 |
| 采购费用 | 办公用品、低值易耗品、采购服务、专项设备 | 4 | 生成采购制度检索词 |
| 发票与票据 | 发票抬头、有效性/红冲、明细与佐证、历史发票、重复报销、其他票据问题 | 6 | 前 5 项检索；“其他”要求补充完整问题 |
| 费用或票据范围 | 差旅、餐费、采购、日常运营、员工福利、发票、报销流程、其他 | 8 | 进入二级表单或补充信息 |
| 差旅费用 | 住宿费、伙食补贴、交通费 | 3 | 住宿/餐费检索；交通进入交通二级表单 |
| 日常运营 | 通讯费、快递费、培训费、市场推广费 | 4 | 生成对应制度检索词 |
| 员工福利 | 婴儿奶粉福利、健身运动福利、员工体检、公司团建 | 4 | 生成对应福利制度检索词 |
| 流程与资金 | 员工借款、借款核销、审批要求、预算控制 | 4 | 生成对应流程制度检索词 |
| 附件排查完成状态 | 已完成上述排查仍失败、尚未完成上述排查 | 2 | 分别转 IT 或要求先完成排查 |
交互约束：9 个制度澄清表单共有 41 个按钮，其中 31 个具体选项确定性映射为制度检索词；范围选择、二级跳转、“其他”和超时不制造宽泛答案。全部 10 个 Human Input 的 WebApp 投递方式使用合法且唯一的 UUID，并配置 1 天超时分支。
9.5 知识证据与回答质量
技术回答链
技术 Query 标准化 → 系统技术知识库 → 技术证据门禁 → 证据充足性判断 → 技术回答或附件排查/IT。知识不足时不得使用制度知识补写技术结论。
制度回答链
明确问题或按钮映射 → 变量聚合 → 确定性完整度检查 → 报销制度知识库 → 智能回答 → 制度质检与必要重写 → 输出。不得生成知识片段未支持的金额、资格或材料要求。
10. 报销分析助手
报销分析助手面向管理员、财务经理、部门经理和访客管理员，对当前授权范围内的报销、预算、风险、公司制度和有效税务规则进行只读分析。内部继续使用 analysis-agent 标识以保持接口兼容。
| 能力 | 输入 | 输出 | 约束 |
|---|---|---|---|
| 趋势分析 | 期间、部门、费用类别 | 金额趋势、结构变化和异常提示 | 数据必须来自统一快照 |
| 预算分析 | 活动预算版本、实际占用 | 期间预算、实际、剩余、执行率 | 缺预算不得补默认金额 |
| 风险与合规 | L1–L4结果、规则命中 | 风险原因、影响和建议 | 只能解释，不能改变原结论 |
| 管理建议 | 聚合指标与制度依据 | 可执行建议和引用来源 | 不能执行审批、付款和配置修改 |
10.1 千问接入与事实保护
- 后端通过独立
ANALYSIS_MODEL_*配置直连千问兼容接口，不复用 Dify 发票 Workflow、员工助手或其他模块凭证。 - 仅向模型发送按角色过滤后的聚合、脱敏证据快照，不发送密码、令牌、附件、完整发票或员工联系方式。
- 模型只生成结论、原因、风险、建议和
claimRefs；金额、笔数、比例、排名、预算和制度事实由后端确定性计算。 - 正文数字和引用必须逐项回查证据。首次校验失败最多重写一次，仍失败则隐藏模型答案并降级为规则分析。
- 模型不得联网搜索，也不得执行审批、预算修改、OA、付款或数据库写入。
10.2 权限、降级与审计
管理员和财务经理查看全局，部门经理由后端强制限定本部门，普通员工无入口；访客管理员只访问共享 Demo 数据并受请求频率限制。回答记录会话、筛选条件、快照编号、规则/预算版本、模型与 Prompt 版本、回答提供方、修订和校验结果。千问未配置、超时、限流、余额或格式异常时，系统明确显示“规则分析模式”。
11. Agent 与发票 Workflow 边界
发票审核 Workflow
输入：可信 user_id、invoice_files、后端审核事实 audit_payload_json 与可选 report_id。
输出：严格字符串字段 result_json；其中包含结构化发票、L1–L4、风险、人工复核标记、审计轨迹与员工提示。
严格隔离
⇄
⇄
员工助手/分析 Agent
输入：授权业务问题、知识片段或只读数据快照。
输出：问答、解释或分析；不产生发票业务状态。
| 项目 | 发票 Workflow | 员工助手 | 报销分析助手 |
|---|---|---|---|
| 应用类型 | Workflow | Chatflow | 只读分析 Agent |
| 主要触发 | 上传发票 | 员工发起对话 | 授权用户发起分析 |
| 长期会话 | 无业务会话 | 按用户维护 | 按授权分析会话维护 |
| 业务写入 | 由后端接收结果后写入 | 禁止 | 禁止 |
| 确定性判断 | 后端覆盖 L1–L3并在提交时完成 L1–L4 | 只解释 | 只解释和分析 |
| 凭证 | 独立 DIFY_INVOICE_AUDIT_* | 独立助手配置 | 独立分析配置/工具权限 |
12. 业务模块需求
工作台
展示累计报销、状态分布、最近报销，以及按年月生成的金额、通过率、风险和费用结构驾驶舱。
我的发票
常规电子发票的服务端发票夹，提供 OCR、L1–L3 状态、预览、重试、删除和入单。
新建报销
从发票夹导入常规电子发票；收据、地铁票等非常规票据手工补录并上传附件，随后提交审核。
我的报销
按状态、类型、年月和关键词查询；草稿/待修改可维护，其余状态可查看进度和历史。
待审批
展示待处理单据及预算占用，支持查看、审批并进入后续财务复核或外部流程演示。
分析报告
按年份、月份和部门查看趋势、预算、风险和合规；规则版本、预算版本与税务规则追溯集中在该页面展示。
部门管理
维护组织部门、负责人和成员。用户、角色、菜单/API 权限属于后端与生产治理能力，当前 Demo 未提供独立管理菜单。
个人中心
展示本人身份、部门、联系方式和脱敏账户信息，支持受控修改个人联系字段。
智能入口
右下角员工助手面向制度与操作问答；分析页提供报销分析助手，二者与发票 Workflow 分应用、分凭证、分职责。
12.1 当前 Demo 功能实景截图
以下截图均由当前本地 Demo（2026-08-18，访客管理员身份）实际页面生成，用于校验 PRD 与可见功能一致；点击图片可查看原始分辨率。
user_id。13. API 与输入输出契约
13.1 发票夹接口
| 方法与路径 | 用途 | 关键规则 |
|---|---|---|
GET /api/invoice-assets | 查询当前用户发票夹 | 仅返回本人记录，按创建时间倒序 |
POST /api/invoice-assets/precheck | 保存附件并执行 OCR、L1–L3 | 校验附件归属与哈希；同用户同哈希复用 |
POST /api/invoice-assets/:id/retry | 重试失败、待修改或疑似重复记录 | 其他状态返回冲突 |
DELETE /api/invoice-assets/:id | 删除未进入报销流程的记录 | 已关联、已占用或已报销禁止删除 |
13.2 报销发票对象
{
"invoiceAssetId": 123,
"invoiceNo": "...",
"invoiceDate": "YYYY-MM-DD",
"sellerName": "...",
"buyerName": "...",
"amount": 44.34,
"tax": 2.66,
"costCenter": "餐饮费",
"description": "业务说明"
}
存在 invoiceAssetId 时，后端忽略客户端提交的票号、日期、购销方、金额、税额和附件字段，以数据库资产记录重新组装；只保留允许修改的费用分类与说明。
13.3 Dify 发票 Workflow
| 配置/字段 | 说明 |
|---|---|
DIFY_INVOICE_AUDIT_API_BASE | 独立 API 基址，默认使用 Dify API；不写入前端 |
DIFY_INVOICE_AUDIT_API_KEY | 独立 Workflow 密钥，仅服务端保存 |
DIFY_INVOICE_AUDIT_TIMEOUT_MS | 工作流超时，最低 1000毫秒，默认 120000毫秒 |
user_id | 必填；由后端登录上下文生成，禁止客户端伪造 |
invoice_files | 必填数组；图片映射为 image，PDF 等映射为 document |
audit_payload_json | 后端生成的确定性审核事实 JSON；不得由模型自行补造金额、重复或预算事实 |
report_id | 可选报销单标识；用于排除自身、串联审计，不作为发票唯一键 |
result_json | 最终输出节点唯一业务字段，必须是可解析 JSON 字符串 |
result_json.invoices | 必须为数组；缺失、非数组或 JSON 不可解析时整个识别视为失败 |
dify_workflow_run_id | 保存运行流水用于审计，不作为业务主键 |
13.4 报销分析助手接口
| 方法与路径/配置 | 用途 | 关键规则 |
|---|---|---|
GET /api/analysis-agent/status | 读取模型和降级状态 | 只返回是否配置、提供方、模型、最近状态和 Demo 限流，不返回密钥 |
POST /api/analysis-agent/sessions | 创建授权分析会话 | 沿用内部 analysis-agent 标识 |
POST /api/analysis-agent/sessions/:id/messages | 执行取数、分析与校验 | 返回 answerProvider、modelUsed、snapshotId、fallbackReason、validatedClaims |
ANALYSIS_MODEL_* | 千问独立服务端配置 | 默认 qwen-plus；密钥不进入 HTML 或浏览器 |
POST /api/analysis/chat | 旧版兼容接口 | 返回 Deprecation/Sunset/Link 头，一个版本周期后移除 |
14. 数据模型摘要
| 表 | 用途 | 关键字段/约束 |
|---|---|---|
invoice_assets | 服务端发票夹和上传预审审计 | owner_user_id、file_hash、票面字段、status、ocr_json、precheck_json、运行 ID；owner+hash 唯一 |
invoice_claims | L3最终占用 | claim_key 主键、report_id、invoice_asset_id、claimed_by_user_id、report_status |
expense_invoices | 报销单发票快照 | 新增 invoice_asset_id；保留票面、附件、分类和识别信息 |
expense_reports | 报销主表与状态机 | 员工、部门、事由、日期、金额、状态和创建人 |
ai_review_results | 报销提交阶段 L1–L4审核轨迹 | 规则、结论、风险、原因、建议和版本 |
department_budgets | 部门与期间预算 | 活动版本、期间预算、实际、剩余和执行率 |
tax_policy_rules | 有效税务与制度依据 | 规则 ID、来源、生效日期、废止状态和版本 |
dim_users / roles / permissions | 身份、角色与权限 | 生产用户与 guest_visitor 分离 |
14.1 双审计轨迹
- 上传预审：原始 OCR、规范化字段、L1–L3、重复证据、运行 ID、审核版本和员工提示。
- 提交终审：报销快照、L1–L4、占用事务、预算版本、规则命中、状态和审核历史。
15. 权限、安全与 Demo 访客
- 所有发票夹接口依赖服务端登录身份；附件路径必须属于当前用户且解析后仍位于附件根目录内。
- 附件入库前后校验 SHA256，防止元数据与实际文件不一致。
- Dify API Key、工作流标识、长期访问令牌不进入 HTML、浏览器、本地存储或普通业务日志。
- 发票资产导入必须验证 owner_user_id；核心票面字段由服务端回填。
- 跨员工重复只返回抽象占用提示，不返回他人身份、部门或报销单号。
15.1 访客管理员 Demo
访客登录由服务端签发独立
guest_visitor 管理员演示身份，具有 Demo 内完整业务权限并读取服务端数据。所有访客共享这一身份及演示数据，因此访客的新增、修改和删除会影响其他访客；生产环境不得照搬匿名管理员设计。16. 异常与降级
| 异常 | 系统行为 | 用户提示 | 是否可入单 |
|---|---|---|---|
| Dify 未配置/超时/失败 | 文件保留，状态改为识别失败待重试，记录受限错误 | “发票已保存，但识别失败，可稍后重试” | 否 |
| Workflow 缺少 invoices | 按无效结构化输出处理 | 识别失败，可重试 | 否 |
| OCR 字段缺失或金额异常 | L1/L2失败，进入待修改 | 展示确定性缺失项或差异 | 否 |
| 疑似重复 | L3失败，保留重复证据 | 请勿重复报销；误报联系财务 | 否 |
| 并发唯一键冲突 | 当前事务失败并清理已写入键 | 已被其他有效报销单占用 | 否 |
| 预算缺失或超过 100% | 不套用默认值，进入人工复核 | 展示预算缺失/超额和版本 | 可提交到人工复核 |
| 报销分析模型不可用 | 隐藏未校验模型答案并使用确定性分析 | 明确显示“规则分析模式” | 不影响确定性业务 API |
17. 埋点、日志与审计
| 事件/日志 | 关键属性 | 用途 |
|---|---|---|
| invoice_upload_start/result | 文件类型、大小、是否复用、耗时、结果状态 | 监控上传与 OCR 转化 |
| invoice_precheck_result | asset_id、L1–L3、风险、审核版本 | 分析失败原因与重试率 |
| invoice_asset_retry/delete/import | 状态、操作人、来源页面 | 审计发票夹操作 |
| expense_submit | 报销单、发票数、总额、预算版本 | 提交漏斗和业务量 |
| ai_review_result | L1–L4、状态、风险、原因码 | 审核准确性和人工复核率 |
| invoice_claim_result | 键类型、幂等/冲突、报销状态 | 重复报销和并发监控 |
| assistant_message | 意图、知识版本、是否回答、转人工 | 员工助手质量 |
| analysis_agent_answer | 筛选、数据时间、版本、校验结果 | 财务分析可追溯 |
18. 测试与验收标准
| 验收场景 | 预期结果 |
|---|---|
| 上传真实 PDF/JPG/PNG | 只调用一次 OCR，保存规范化字段、运行 ID和 L1–L3结果 |
| 同用户重复上传同一 SHA256 | 返回既有发票资产，不重复 OCR |
| 从发票夹导入报销单 | 不调用 Dify；带 invoiceAssetId，核心字段前后端均不可篡改 |
| 报销单内直接上传 | 先完成发票预审，通过后自动加入当前报销单 |
| Dify 故障 | 文件保留为识别失败待重试，不能形成未经预审的报销发票 |
| 当前单内部重复 | 票号或附件重复均被 L3阻断 |
| 有效历史单据重复 | 审批中、复核中、已通过或已付款均阻断；草稿/待修改不误报 |
| 两个报销单并发提交同一发票 | 最多一个成功，失败方得到占用提示 |
| 撤回或驳回 | 占用释放，发票恢复可入单；已付款不释放 |
| 预算执行率 90%–100% | 带预警进入部门审批 |
| 预算超过 100%或未配置 | 转人工复核，不使用默认预算 |
| “差旅费中的餐费报销上限是多少” | 问题已明确时直接检索差旅伙食补贴制度；不得回答“无单次及月度金额上限”等无证据结论 |
| 只问“餐费报销上限是多少” | 显示差旅伙食补贴、日常业务餐费、业务招待费 3 个按钮；选择后继续制度检索 |
| 只问“这个可以报销吗” | 先显示费用或票据范围，再进入相应二级表单；“其他”要求补充费用类型、场景、身份和问题目标 |
| 附件无法上传且尚未排查 | 先展示文字排查和两个按钮；选择“尚未完成”后要求逐项排查，不直接转人工 |
| 附件完成排查仍失败 | 转 IT 支持并提示准备操作时间、报错截图、文件信息和报销单号；不得转财务 |
| 询问“我的报销目前到哪里了” | 返回本人进度查询指引，不将进度问题误送制度知识库 |
| Human Input 超时 | 给出可执行的重新进入提示，不生成默认选择或宽泛制度答案 |
| Agent 解释审核结果 | 不得改变 passed、status、金额、重复证据或预算结论 |
| 访客管理员登录 | 使用独立共享演示身份，可访问 Demo 管理功能，不复用真实 admin |
18.1 当前自动化覆盖
precheck.test.js、invoice-assets-route.test.js、invoice-audit-store.test.js、dify-invoice-audit-client.test.js 与访客权限测试覆盖金额税额、日期、失败重试、字段防篡改、重复占用、并发竞争、预算边界和访客管理员，后端完整回归为 143 项。L1–L4 Workflow 专用回归另覆盖 15 个主节点、四项输入、同一知识库双检索、证据合并、严格 result_json、身份缺失防误判、检索失败关闭、地铁定额发票与出租车票。V10 Chatflow 离线回归覆盖技术/制度分库、费用澄清按钮、附件排查按钮和 Human Input delivery UUID 唯一性。
19. Demo 与生产边界
| 能力 | 当前 Demo | 生产增强 |
|---|---|---|
| 常规电子发票夹与 OCR | Dify 新密钥已由后端接入 | 对象存储私有化、病毒扫描、生命周期、OCR SLA和监控 |
| 非常规票据 | 新建报销页手工补录；Workflow 已有识别与规则回归 | 收据、地铁票、出租车票等统一进入发票夹直通流程，并建立分票种准确率与人工兜底指标 |
| L1–L4与占用 | 单知识库双检索 + 确定性规则 | 规则发布审批、迁移演练、数据库高可用和压测 |
| 税务验真 | 流程演示 | 接入合规税务查验服务，保存外部流水和证据 |
| OA与付款 | 状态演示 | 企业 OA/ERP/银企 API、幂等、重试、补偿和对账 |
| 规则/预算/权限配置 | 数据与分析页可见，无独立配置菜单 | 补齐规则发布、预算编制、用户角色、审批流和数据权限的管理控制台 |
| 访客管理员 | 共享 Demo 身份 | 生产关闭匿名管理员，接 SSO、最小权限与集中审计 |
| 员工助手 | V10 Chatflow 已发布 | 双知识库发布监控、Human Input 完成率、知识质检、限流与 IT/财务人工服务 SLA |
| 报销分析 | 千问增强/规则降级 | 数据快照治理、指标语义层、模型调用监控、回归评测和回答质检 |
20. 与主流竞品的差异分析
本节基于 2026-08-18 各厂商官网公开能力，对比对象为 合思费控、分贝通、汇联易和 SAP Concur 解决方案。该分析用于产品规划，不等同于采购验收或对竞品当前全部版本的实测结论。
| 对比维度 | 本版本 V1.13 | 主流竞品公开能力 | 差异判断 |
|---|---|---|---|
| 产品覆盖范围 | 聚焦员工报销、发票审核、部门审批、合规分析和双助手 | 合思、分贝通、汇联易普遍覆盖申请、商旅/消费、企业支付、报销、对账、核算和档案；SAP Concur 还覆盖全球差旅、Invoice/AP 与伙伴生态 | 明显不足 当前是报销审核型产品，不是完整企业支出平台 |
| 事前与事中费控 | 预算主要在提交和分析阶段校验 | 合思、分贝通、汇联易强调申请前置、消费标准预设和事中预算控制 | 不足 需补申请、预占、企业支付和消费订单联动 |
| 票据覆盖与验真 | 常规电子发票已直通；非常规票据规则已有，但 UI 仍手工补录；税务验真为接口边界 | 国内竞品普遍宣传多票种采集、OCR、查重、验真和电子档案 | 不足 主要短板是票种直通率、真实验真和档案闭环 |
| 智能审核方式 | OCR/大模型负责识别与解释，金额、重复、预算和状态由后端确定性规则及数据库约束裁决 | 竞品普遍提供规则引擎、AI 审核、异常模型或人工审计服务 | 差异优势 责任边界、失败关闭和审计可解释性更明确，适合高风险场景验证 |
| 重复报销控制 | 票号 + SHA256 + 历史有效状态 + 事务级唯一占用，支持并发冲突和撤回释放 | 竞品公开描述多为发票查重、异常校验或防重复付款 | 优势 当前 PRD 对并发占用、隐私提示和状态释放定义更细 |
| 制度与预算证据 | L4 对同一制度知识库执行分类额度与例外材料双检索，证据合并后由确定性代码终审；缺证据不默认放行 | 竞品多采用可配置制度、预算和规则引擎，成熟度更高但公开资料通常不披露模型与规则的裁决边界 | 各有侧重 本版证据链透明，竞品在规则管理产品化和企业实施上领先 |
| 员工问答与交互澄清 | 技术/制度双知识库隔离，模糊问题用按钮补齐上下文，附件故障先排查再转 IT | 部分竞品提供智能坐席、审批 Agent 或管控 Agent，但交互式知识分流细节公开较少 | 差异优势 员工问题分类、知识隔离和人工转接规则清晰 |
| 分析与管理洞察 | 确定性指标 + 千问只读解释；校验失败降级为规则分析 | 竞品提供预算执行、支出结构、风险、成本节约和经营分析 | 部分持平 本版事实保护较强，但指标语义层、行业模板和跨系统数据仍不足 |
| 全球化与生态 | 当前主要面向国内单组织 Demo，无移动端、商旅供应链和成熟连接器市场 | SAP Concur 提供全球差旅、费用、Invoice/AP、移动端及伙伴生态；国内竞品也扩展海外商旅与支付 | 明显不足 不宜在现阶段以全球费用平台作为直接定位 |
| 集成与交付成熟度 | 税务、OA、ERP、付款仍以接口边界或演示状态为主 | 主流竞品已有大量企业实施、支付/银行、ERP、商旅和档案连接能力 | 不足 下一阶段应优先补真实接口、可观测性和实施工具 |
20.1 当前更好的地方
确定性优先
模型不裁决业务事实
OCR、模型、知识库和后端职责分层，金额、重复、预算、状态不会被生成式回答覆盖。
证据可追溯
L1–L4 与双审计轨迹
上传预审和提交终审分开记录，制度证据、规则版本、占用事务与员工提示可回查。
并发防重
不只做查询式查重
唯一占用、幂等、自身排除、撤回释放和跨员工隐私提示形成更完整的重复报销控制。
知识隔离
技术与制度不混答
员工助手使用双知识库与确定性分流，附件故障先排查、完成后再转 IT。
安全接入
长期密钥仅在后端
Workflow、员工助手和分析助手分应用、分凭证、分会话，浏览器不持有审核密钥。
可降级
失败不静默放行
知识不足、模型异常和输出不合法时关闭自动放行或回退规则分析，避免伪造确定性结论。
20.2 有待改进的地方与优先级
| 优先级 | 改进项 | 目标结果 | 建议验收指标 |
|---|---|---|---|
| P0 | 非常规票据统一直通、真实税务验真、OA/ERP/付款接口 | 从“规则可识别”升级为“端到端可处理”，补齐主业务闭环 | 分票种字段准确率、直通率、验真成功率、接口幂等与补偿成功率 |
| P0 | 规则、预算、用户角色与审批流管理控制台 | 将当前后端数据和分析展示变成可发布、可审批、可回滚的配置产品 | 规则发布审计、预算版本覆盖率、权限越权测试、审批配置回归 |
| P1 | 事前申请、预算预占、商旅/企业支付与消费订单匹配 | 由事后报销审核扩展到事前、事中支出管理 | 企业支付占比、员工垫资比例、预算超额拦截率、订单自动匹配率 |
| P1 | 电子会计档案、自动凭证、对账与审计导出 | 形成财务后链路和监管证据闭环 | 自动制证率、归档完整率、对账差异率、审计导出耗时 |
| P2 | 移动端、多币种、多语言、海外税制和连接器生态 | 满足集团化、全球化和多系统实施需求 | 移动端覆盖率、币种/国家覆盖、连接器数量、实施周期 |