feat: 统一后端分页查询与前端服务层适配
后端新增通用分页模块，为报销单、员工、预算、agent 资产等 端点统一接入分页参数和游标查询，优化 repository 层分页实 现，前端服务层适配分页响应结构，完善预算图表和全局样式， 优化侧边栏和企业选择器组件，引入 Element Plus 插件注册。
This commit is contained in:
caoxiaozhu
@@ -850,6 +850,327 @@
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
|
||||
/* 竞品分析表格样式 */
|
||||
.comp-table-wrapper {
|
||||
width: 100%;
|
||||
overflow-x: auto;
|
||||
margin: 24px 0;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: var(--radius);
|
||||
box-shadow: var(--shadow-soft);
|
||||
background: var(--surface);
|
||||
}
|
||||
|
||||
.comp-table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
text-align: left;
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
.comp-table th,
|
||||
.comp-table td {
|
||||
padding: 14px 16px;
|
||||
border-bottom: 1px solid var(--line);
|
||||
vertical-align: top;
|
||||
line-height: 1.68;
|
||||
}
|
||||
|
||||
.comp-table th {
|
||||
background: var(--surface-strong);
|
||||
color: var(--teal-deep);
|
||||
font-weight: 900;
|
||||
font-size: 13.5px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
.comp-table tr:last-child td {
|
||||
border-bottom: none;
|
||||
}
|
||||
|
||||
.comp-table tr:hover td {
|
||||
background: var(--surface-soft);
|
||||
}
|
||||
|
||||
.comp-highlight {
|
||||
background: var(--teal-soft);
|
||||
font-weight: 850;
|
||||
color: var(--teal-deep);
|
||||
}
|
||||
|
||||
.comp-table td ul {
|
||||
margin: 0;
|
||||
padding-left: 18px;
|
||||
}
|
||||
|
||||
.comp-table td li {
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
|
||||
/* 痛点方案卡片微动效与特色样式 */
|
||||
.card {
|
||||
transition: transform 0.22s cubic-bezier(0.16, 1, 0.3, 1), box-shadow 0.22s ease, border-color 0.22s ease;
|
||||
}
|
||||
|
||||
.card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: var(--shadow-soft);
|
||||
border-color: var(--teal);
|
||||
}
|
||||
|
||||
.twin-sandbox-card {
|
||||
grid-column: span 2;
|
||||
background: linear-gradient(135deg, var(--surface) 60%, var(--teal-soft) 100%);
|
||||
border: 1px solid var(--line-strong);
|
||||
}
|
||||
|
||||
.twin-sandbox-badge {
|
||||
display: inline-block;
|
||||
padding: 2px 8px;
|
||||
background: var(--teal-deep);
|
||||
color: #fff;
|
||||
font-size: 11px;
|
||||
border-radius: 99px;
|
||||
margin-bottom: 8px;
|
||||
font-weight: 850;
|
||||
}
|
||||
|
||||
@media (max-width: 1024px) {
|
||||
.twin-sandbox-card {
|
||||
grid-column: span 1;
|
||||
}
|
||||
}
|
||||
|
||||
/* 仿真沙盘交互组件样式 */
|
||||
.twin-simulator-box {
|
||||
margin-top: 20px;
|
||||
padding: 18px;
|
||||
border: 1px solid var(--line-strong);
|
||||
border-radius: var(--radius);
|
||||
background: rgba(15, 118, 110, 0.03);
|
||||
backdrop-filter: blur(10px);
|
||||
}
|
||||
|
||||
.twin-sim-title {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
font-size: 13px;
|
||||
font-weight: 900;
|
||||
color: var(--teal-deep);
|
||||
margin-bottom: 14px;
|
||||
border-bottom: 1px dashed var(--line);
|
||||
padding-bottom: 8px;
|
||||
}
|
||||
|
||||
.sim-dot {
|
||||
width: 8px;
|
||||
height: 8px;
|
||||
background: var(--teal);
|
||||
border-radius: 50%;
|
||||
animation: pulse 1.8s infinite;
|
||||
}
|
||||
|
||||
@keyframes pulse {
|
||||
0% { transform: scale(0.95); box-shadow: 0 0 0 0 rgba(15, 118, 110, 0.5); }
|
||||
70% { transform: scale(1); box-shadow: 0 0 0 6px rgba(15, 118, 110, 0); }
|
||||
100% { transform: scale(0.95); box-shadow: 0 0 0 0 rgba(15, 118, 110, 0); }
|
||||
}
|
||||
|
||||
.twin-sim-layout {
|
||||
display: grid;
|
||||
grid-template-columns: minmax(0, 1.15fr) minmax(0, 0.85fr);
|
||||
gap: 18px;
|
||||
}
|
||||
|
||||
.twin-sim-ctrl {
|
||||
display: grid;
|
||||
gap: 12px;
|
||||
align-content: start;
|
||||
}
|
||||
|
||||
.ctrl-group {
|
||||
display: grid;
|
||||
gap: 6px;
|
||||
}
|
||||
|
||||
.ctrl-group label {
|
||||
font-size: 12px;
|
||||
font-weight: 850;
|
||||
color: var(--ink-soft);
|
||||
}
|
||||
|
||||
.ctrl-group select {
|
||||
width: 100%;
|
||||
height: 34px;
|
||||
padding: 0 8px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 6px;
|
||||
background: var(--surface);
|
||||
color: var(--ink);
|
||||
font-size: 12.5px;
|
||||
font-family: var(--font);
|
||||
outline: none;
|
||||
}
|
||||
|
||||
.ctrl-group select:focus {
|
||||
border-color: var(--teal);
|
||||
}
|
||||
|
||||
.highlight-val {
|
||||
color: var(--teal-deep);
|
||||
font-weight: 900;
|
||||
font-family: var(--mono);
|
||||
}
|
||||
|
||||
.ctrl-group input[type="range"] {
|
||||
-webkit-appearance: none;
|
||||
width: 100%;
|
||||
height: 6px;
|
||||
border-radius: 3px;
|
||||
background: var(--line);
|
||||
outline: none;
|
||||
}
|
||||
|
||||
.ctrl-group input[type="range"]::-webkit-slider-thumb {
|
||||
-webkit-appearance: none;
|
||||
appearance: none;
|
||||
width: 16px;
|
||||
height: 16px;
|
||||
border-radius: 50%;
|
||||
background: var(--teal);
|
||||
cursor: pointer;
|
||||
border: 2px solid var(--surface);
|
||||
box-shadow: 0 2px 6px rgba(15,118,110,0.3);
|
||||
transition: transform 0.1s ease;
|
||||
}
|
||||
|
||||
.ctrl-group input[type="range"]::-webkit-slider-thumb:hover {
|
||||
transform: scale(1.15);
|
||||
}
|
||||
|
||||
.range-labels {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
font-size: 10px;
|
||||
color: var(--muted);
|
||||
margin-top: 2px;
|
||||
font-family: var(--mono);
|
||||
}
|
||||
|
||||
#run-sim-btn {
|
||||
width: 100%;
|
||||
height: 36px;
|
||||
background: var(--teal-deep);
|
||||
color: #fff;
|
||||
border: none;
|
||||
border-radius: 6px;
|
||||
font-size: 13px;
|
||||
font-weight: 900;
|
||||
cursor: pointer;
|
||||
box-shadow: 0 4px 12px rgba(16, 47, 43, 0.2);
|
||||
transition: all 0.2s ease;
|
||||
}
|
||||
|
||||
#run-sim-btn:hover {
|
||||
background: var(--teal);
|
||||
transform: translateY(-1px);
|
||||
box-shadow: 0 6px 16px rgba(15, 118, 110, 0.3);
|
||||
}
|
||||
|
||||
#run-sim-btn:active {
|
||||
transform: translateY(0);
|
||||
}
|
||||
|
||||
.twin-sim-display {
|
||||
position: relative;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 6px;
|
||||
background: var(--surface);
|
||||
padding: 12px;
|
||||
display: grid;
|
||||
align-content: space-between;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.sim-scanner {
|
||||
position: absolute;
|
||||
top: -100%;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
height: 12px;
|
||||
background: linear-gradient(180deg, rgba(15, 118, 110, 0.2) 0%, transparent 100%);
|
||||
pointer-events: none;
|
||||
z-index: 2;
|
||||
}
|
||||
|
||||
.sim-scanner.scanning {
|
||||
animation: scan 1.2s ease-in-out;
|
||||
}
|
||||
|
||||
@keyframes scan {
|
||||
0% { top: -10px; }
|
||||
100% { top: 100%; }
|
||||
}
|
||||
|
||||
.metric-group {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, minmax(0, 1fr));
|
||||
gap: 10px;
|
||||
z-index: 1;
|
||||
}
|
||||
|
||||
.sim-metric {
|
||||
padding: 8px;
|
||||
border: 1px solid var(--surface-strong);
|
||||
border-radius: 6px;
|
||||
background: var(--surface-soft);
|
||||
display: grid;
|
||||
gap: 4px;
|
||||
}
|
||||
|
||||
.sim-metric .m-label {
|
||||
font-size: 11px;
|
||||
color: var(--muted);
|
||||
}
|
||||
|
||||
.sim-metric .m-value {
|
||||
font-family: var(--mono);
|
||||
font-size: 16px;
|
||||
font-weight: 900;
|
||||
line-height: 1.1;
|
||||
}
|
||||
|
||||
.sim-metric .m-value.teal { color: var(--teal); }
|
||||
.sim-metric .m-value.orange { color: var(--amber); }
|
||||
.sim-metric .m-value.red { color: var(--red); }
|
||||
.sim-metric .m-value.blue { color: var(--blue); }
|
||||
|
||||
.sim-report-badge {
|
||||
margin-top: 10px;
|
||||
padding: 4px;
|
||||
border-radius: 4px;
|
||||
background: var(--surface-strong);
|
||||
color: var(--teal-deep);
|
||||
font-size: 10.5px;
|
||||
font-weight: 850;
|
||||
text-align: center;
|
||||
transition: all 0.3s ease;
|
||||
z-index: 1;
|
||||
}
|
||||
|
||||
.sim-report-badge.success {
|
||||
background: var(--teal-soft);
|
||||
color: var(--teal-deep);
|
||||
border: 1px solid rgba(15, 118, 110, 0.2);
|
||||
}
|
||||
|
||||
@media (max-width: 580px) {
|
||||
.twin-sim-layout {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 1500px) {
|
||||
.page {
|
||||
grid-template-columns: 236px minmax(0, 1fr);
|
||||
@@ -971,6 +1292,8 @@
|
||||
<a href="#why"><span class="dot"></span>为什么要做</a>
|
||||
<a href="#future"><span class="dot"></span>未来地位</a>
|
||||
<a href="#blue"><span class="dot"></span>蓝海空间</a>
|
||||
<a href="#competitor-analysis"><span class="dot"></span>竞品对比</a>
|
||||
<a href="#painpoints-solution"><span class="dot"></span>痛点解决</a>
|
||||
<a href="#goal"><span class="dot"></span>开发目的</a>
|
||||
<a href="#algorithms"><span class="dot"></span>核心算法</a>
|
||||
<a href="#modules"><span class="dot"></span>项目模块</a>
|
||||
@@ -1037,28 +1360,19 @@
|
||||
<h2>为什么要做智能费控平台</h2>
|
||||
<p class="section-desc">
|
||||
智能费控不是把报销审批电子化，而是把企业每一笔支出变成可理解、可预测、可解释的经营信号。
|
||||
当 AI、RAG、智能体、异常检测和预算联动进入财务流程后，费用平台会从“流程系统”升级为“经营控制系统”。
|
||||
当前，在金税四期深化、数电发票单轨制全面普及的政策背景下，传统的“后置流程型”费控已被逼入死胡同，企业必须构建全链路智能费控平台。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="deep-copy">
|
||||
<p>
|
||||
第一，费用是企业经营动作最密集、最贴近一线的数据入口。销售拜访客户会产生差旅和招待，
|
||||
项目交付会产生交通、住宿、外包和办公支出，培训、采购、通信、会务也都以费用形式落地。
|
||||
如果企业只在报销完成后做核销，就只能看到“钱已经花了”；如果在申请、预算占用、票据上传、
|
||||
审批和归档全过程做智能分析，就能提前看到“这笔钱为什么要花、是否该花、花完后对预算和风险有什么影响”。
|
||||
第一，<strong>数电票时代倒逼全链路数字化</strong>。随着全国数电发票的单轨制落地，发票的真伪验重、多系统抵扣、合规归档以及全生命周期的追踪已无法通过传统人工肉眼或零散的OCR识别来解决。系统必须具备在发票导入瞬间进行结构化解析、关联交易比对、业务事由交叉匹配的自动化能力，实现“开票即采集、采集即验真、入账即归档”。
|
||||
</p>
|
||||
<p>
|
||||
第二，财务工作的重心正在从人工处理转向分析、预测和决策支持。Gartner 2025 年财务 AI 调研显示，
|
||||
财务组织最常见的 AI 用例已经包括知识管理、应付流程自动化、错误与异常检测；McKinsey 的 CFO 调研也显示，
|
||||
绝大多数受访者期待 AI 减少人工分析负担、生成洞察。这意味着费控平台必须具备自动识别、自动解释和自动沉淀的能力，
|
||||
否则它会停留在“录单工具”，无法进入未来财务的核心工作台。
|
||||
第二，<strong>企业从“事后核销”向“事前控制”的主动性跨越</strong>。传统ERP与报销系统核心是“记账与流程审批”，当员工提交报销单时，费用早已产生。智能费控利用 RAG 知识检索、预算实时联动，在费用申请阶段甚至消费发生的瞬间（如因公商旅预订）就进行预算额度校验与制度约束，使费控前置到决策端。
|
||||
</p>
|
||||
<p>
|
||||
第三，费用风险越来越隐蔽。传统审批能挡住“缺附件”“超标准”这类显性问题，
|
||||
但很难发现拆单、跨部门合谋、异常频次、预算节奏异常、同组偏离、长期材料质量差等隐性问题。
|
||||
ACFE 的职业舞弊报告将虚构或夸大业务费用列为典型报销舞弊形态；随着 AI 生成票据、深度伪造和自动化攻击出现，
|
||||
企业更需要一个能把票据、人员、部门、历史行为、预算和制度放在一起分析的平台。
|
||||
第三，<strong>费用舞弊与异常的隐性化、复杂化</strong>。根据 ACFE 2024 年《全球职业舞弊与滥用报告》显示，全球企业中约有 15% 的舞弊案件与费用报销直接相关，且平均潜伏期长达 18 个月。传统的强硬制度配置只能拦截“超标准”、“无附件”等显性异常，但对于拆单报销、异地多点异常消费、同组偏离度过高、长期合作供应商异常开票等隐性风控，需要基于大数据画像和语义关系的图谱检测。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
@@ -1122,74 +1436,66 @@
|
||||
<div class="section-kicker">02 / COMPANY POSITION</div>
|
||||
<h2>费控在未来公司的地位</h2>
|
||||
<p class="section-desc">
|
||||
未来公司的费控，会从“报销审批入口”变成“经营支出操作系统”。
|
||||
未来公司的费控，会从“报销审批工具”变成“企业费用智能操作系统”（Expense OS）。
|
||||
它一端连接员工和部门的真实业务动作，另一端连接预算、现金流、成本、风险、制度和管理决策。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="deep-copy">
|
||||
<p>
|
||||
从组织分工看，CFO 的角色正在从财务记录者变成业务伙伴和技术治理者。
|
||||
Deloitte 的未来财务洞察持续强调，财务团队会把更多时间投入分析、预测和决策支持；
|
||||
Deloitte APAC CFO 2025 调研也显示，接近一半 CFO 认为生成式 AI 会在两年内显著改变行业、组织和财务职能。
|
||||
这意味着费控不应再被放在“报销系统”这个狭窄位置，而应该成为 CFO 获取一线经营信号的前置雷达。
|
||||
从<strong>组织分工与决策支持</strong>来看，CFO 的角色正加速从“合规记录者”转变为“战略业务伙伴（HR/IT/业务协同的中心）”。Deloitte 2025 年未来财务展望报告指出，财务部门未来的工作精力将有 70% 倾斜于数据分析和未来预测。智能费控则是这一变革的第一步——通过把一线经营活动（如差旅、招待、项目交付）产生的每一笔资金流动转化为语义数据，为 CFO 的“战略驾驶舱”提供实时的一手信号。
|
||||
</p>
|
||||
<p>
|
||||
从业务管理看，预算不再只是年初编制和月底复盘。未来预算需要跟每一次费用申请实时联动：
|
||||
当前预算池还有多少、审批后使用率是多少、是否触达预警线、该部门同类费用是否异常、是否影响项目毛利和现金节奏。
|
||||
因此费控会成为部门经理、项目负责人和财务 BP 共同使用的经营协同平台。
|
||||
从<strong>预算与资源控制</strong>来看，未来的预算管控不再是“年初编预算，月底对账单”的静态割裂状态。智能费控通过建立动态预算池与资金控制链，使预算能够在秒级发生响应。这保证了业务部门在项目推进过程中，能实时感知每一笔花费对项目整体毛利空间、部门现金流余量的动态影响，促使人人关注经营效果。
|
||||
</p>
|
||||
<p>
|
||||
从风险控制看，未来公司的费用风险不是单张票据能解释清楚的，而是多源数据的组合问题。
|
||||
一张票据可能合规，但一个人三个月内的频次、金额、地点、客户、同行人和预算占比可能异常。
|
||||
智能费控要把这些信号拉成一张网，让管理者在支付之前就看到风险轮廓。
|
||||
从<strong>业务运营与体验</strong>来看，智能费控是消除部门隔阂、降低一线行政摩擦的“润滑剂”。当平台实现高度数字化与免报销消费结算时，员工不再需要贴票垫资，管理者不再需要在审批页面盲目点“同意”，财务不再需要枯燥审单，整个公司的运营效率将得到数量级提升。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="split">
|
||||
<div>
|
||||
<ul class="bullets">
|
||||
<li><strong>经营仪表盘：</strong>部门费用、项目消耗、预算占比、执行率、风险热区可以被实时汇总。</li>
|
||||
<li><strong>预算守门员：</strong>费用申请不再只看“能不能报”，而要看“是否符合预算节奏”。</li>
|
||||
<li><strong>内控前置层：</strong>票据、地点、人员、金额、制度条款和历史行为被联动审核。</li>
|
||||
<li><strong>AI 财务工作台：</strong>财务人员可以通过自然语言查询制度、解释风险、生成审批建议和费用报告。</li>
|
||||
<li><strong>规则与知识工厂：</strong>制度解释、规则生成、风险复盘和人工反馈进入可持续优化闭环。</li>
|
||||
<li><strong>管理决策入口：</strong>管理者可以询问“哪个部门预算风险最高”“哪些费用正在吞噬毛利”。</li>
|
||||
<li><strong>经营支出中枢 (Expense OS)：</strong> 将多系统的零散流程、差旅出行、第三方消费直接通过本体层收归统一。</li>
|
||||
<li><strong>预算守护雷达：</strong> 在业务动作发生时实现“秒级预算占用与测算”，而不是事后核销时的“超支警告”。</li>
|
||||
<li><strong>合规内控防火墙：</strong> 结合发票验真、合同信息、行程轨迹和行为偏差等多模态数据对风险自动拦截。</li>
|
||||
<li><strong>战略决策沙盘：</strong> 支持 CFO 和高管直接询问“各项目利润健康度”、“政策变动预算消耗预测”等深度命题。</li>
|
||||
<li><strong>自进化规则工厂：</strong> 依据历史人工审批意见和申诉结果，系统能自动推荐规则优化方案，实现制度灰度升级。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div>
|
||||
<div class="flow-diagram" aria-label="费控未来地位流程图">
|
||||
<div class="flow-row" style="--cols: 3">
|
||||
<div class="flow-node">
|
||||
<div class="flow-node-title">业务动作</div>
|
||||
<div class="flow-node-text">出差、采购、招待、培训、项目交付</div>
|
||||
<div class="flow-node-title">业务场景</div>
|
||||
<div class="flow-node-text">差旅、招待、采购、项目外包、会务支出</div>
|
||||
</div>
|
||||
<div class="flow-node dark">
|
||||
<div class="flow-node-title">智能费控平台</div>
|
||||
<div class="flow-node-text">预算、单据、制度、票据、风险、智能体</div>
|
||||
<div class="flow-node-title">费用智能操作系统</div>
|
||||
<div class="flow-node-text">本体语义 · 实时预算 · 智能体 · 仿真沙盘</div>
|
||||
</div>
|
||||
<div class="flow-node">
|
||||
<div class="flow-node-title">财务结果</div>
|
||||
<div class="flow-node-text">成本、现金、核销、支付、账务沉淀</div>
|
||||
<div class="flow-node-title">经营结果</div>
|
||||
<div class="flow-node-text">成本优化、合规账套、税务风险减免、现金流稳健</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="flow-row" style="--cols: 3">
|
||||
<div class="flow-node blue">
|
||||
<div class="flow-node-title">组织与预算</div>
|
||||
<div class="flow-node-text">部门、项目、成本中心、预算池</div>
|
||||
<div class="flow-node-title">CFO 战略看板</div>
|
||||
<div class="flow-node-text">业财融合数据、动态毛利预警、资金利用率</div>
|
||||
</div>
|
||||
<div class="flow-node amber">
|
||||
<div class="flow-node-title">数据与画像</div>
|
||||
<div class="flow-node-text">费用画像、行为画像、同组基准</div>
|
||||
<div class="flow-node-title">数字孪生仿真</div>
|
||||
<div class="flow-node-text">制度变动测算、预算优化预测、行为偏差度</div>
|
||||
</div>
|
||||
<div class="flow-node blue">
|
||||
<div class="flow-node-title">管理决策</div>
|
||||
<div class="flow-node-text">预警、报告、经营洞察、规则优化</div>
|
||||
<div class="flow-node-title">协同平台</div>
|
||||
<div class="flow-node-text">免贴票、即时审批、智能助手交互</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="diagram-caption">
|
||||
费控位于经营动作和财务结果之间，未来承担预算守门、规则解释、风险识别、数据画像和管理洞察的中枢角色。
|
||||
智能费控平台向上承接公司战略与预算规则，向下沉入业务一线动作，最终演化为企业支出的全局操作系统。
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -1200,45 +1506,203 @@
|
||||
<div class="section-kicker">03 / BLUE OCEAN</div>
|
||||
<h2>智能分析费控平台的蓝海</h2>
|
||||
<p class="section-desc">
|
||||
传统 ERP、OA、报销系统和财务共享平台已经覆盖了流程，但对“语义理解、自动洞察、隐性风险识别、
|
||||
预算占比解释、部门费用经营分析”的覆盖仍然不足。蓝海空间正来自这个空白：
|
||||
市场正在从单点报销工具转向 AI 驱动的差旅、费用、发票、预算和风险一体化平台。
|
||||
传统的报销系统、OA 工作流和财务共享软件已是一片红海，产品竞争停留在表单设计与流程配置层面。而真正能为企业带来颠覆性价值的“智能费控蓝海”，则存在于从流程处理到智能化决策预测的跃迁中。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="deep-copy">
|
||||
<p>
|
||||
Grand View Research 2025 年报告预计，全球差旅与费用管理软件市场到 2030 年将达到 106.9 亿美元，
|
||||
2024 至 2030 年复合增速为 16.9%。更重要的是，它特别提到 AI 可用于审批与支付自动化、
|
||||
员工差旅历史和支出模式分析、OCR 票据字段识别以及基于自然语言的交互。
|
||||
这说明市场真正的增长点不只是“报销线上化”，而是“费用智能化”。
|
||||
根据全球著名调研机构 Grand View Research 2025 发布的市场预测报告，全球差旅与费用管理（T&E）软件市场规模在 2030 年将达到 <strong>106.9 亿美元</strong>，2024 至 2030 年的复合年增长率（CAGR）高达 <strong>16.9%</strong>。报告中特别强调，市场增长的核心引擎已不再是单纯的“线上化审批”，而是引入 AI Agent 进行决策自动化、基于 OCR/LLM 的隐性欺诈检测、以及基于企业历史支出行为的可持续 ESG 碳足迹追踪。这表明，“费用智能化与经营沙盘仿真”是蕴含巨大商业溢价的崭新蓝海。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="grid cols-3">
|
||||
<article class="card">
|
||||
<strong>非结构化数据智能化</strong>
|
||||
<p>票据、制度 PDF、Excel 规则、审批意见、用户自然语言都能进入同一个语义管道。</p>
|
||||
<strong>1. 认知与决策型 AI Agent</strong>
|
||||
<p>从“机械填表和固定规则校验”跨越到“能基于上下文自主决策、异常判定、并提供人机协同解释”的财务数字员工。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<strong>部门费用经营化</strong>
|
||||
<p>费用从“报销明细”升级为“部门预算执行、费用结构、异常趋势、经营压力”的管理对象。</p>
|
||||
<strong>2. 财务数字孪生与政策仿真</strong>
|
||||
<p>基于公司历史发票、人员组织、预算规则建立仿真模型，模拟差旅标准或预算政策调整后，对企业资金流与利润的实际影响。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<strong>风险识别前置化</strong>
|
||||
<p>拆单、超预算、重复票据、地点不一致、附件缺失、异常频次都可以更早被发现。</p>
|
||||
<strong>3. 多源异构数据语义对齐</strong>
|
||||
<p>打破各子系统（CRM、ERP、OA、商旅聚合商）接口壁垒，利用 Semantic Ontology 本体语义层实现业务数据的天然降维对齐。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<strong>财务智能体运营化</strong>
|
||||
<p>后台数字员工不再等待人点击，而是按周期巡检数据、生成报告和沉淀优化候选。</p>
|
||||
<strong>4. 行为偏离与隐性欺诈识别</strong>
|
||||
<p>基于知识图谱与图机器学习技术，识别跨期拆单、虚假报销、同组偏离异常、跨部门关联交易等人工难以察觉的系统性风险。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<strong>规则治理产品化</strong>
|
||||
<p>自然语言规则、风险规则、Excel 规则和制度知识可以逐步变成可测试、可版本化资产。</p>
|
||||
<strong>5. 自进化规则治理闭环</strong>
|
||||
<p>支持自然语言输入制度，由 LLM 自动翻译成系统执行规则，并通过人工申诉与退回反馈，在后台自动完成规则库的校准 and 修正。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<strong>财务知识即时化</strong>
|
||||
<p>RAG 与知识库让制度解释从人工翻文档，转为“问一句，返回依据和建议”。</p>
|
||||
<strong>6. 绿色财务与 ESG 碳足迹</strong>
|
||||
<p>在费控和商旅端自动提取交通工具、酒店的排放系数，帮助企业在进行费用管控的同时，同步测算并生成企业 ESG 碳足迹报告。</p>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="section" id="competitor-analysis">
|
||||
<div class="section-head">
|
||||
<div class="section-kicker">03.1 / COMPETITORS</div>
|
||||
<h2>主流费控系统竞品分析</h2>
|
||||
<p class="section-desc">
|
||||
要实现上述蓝海构想，必须客观分析当前市场上主流的费控软件。各大软件定位明确，但普遍在“智能化决策”、“跨系统语义融合”及“政策仿真”方面存在显著痛点。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="comp-table-wrapper">
|
||||
<table class="comp-table">
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="width: 14%">竞品名称</th>
|
||||
<th style="width: 25%">核心定位与主要优势</th>
|
||||
<th style="width: 28%">核心痛点与局限性</th>
|
||||
<th style="width: 33%">X-Financial 的创新解决与差异化</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>SAP Concur</strong></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>全球化费控天花板，支持多币种、多税制、全球财税合规。</li>
|
||||
<li>商旅生态极其成熟，能够与 SAP ERP 体系深度咬合。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>本土化体验被国内用户诟病（如数电发票处理缓慢）。</li>
|
||||
<li>系统界面臃肿，配置与二次开发极为繁琐。</li>
|
||||
<li>实施周期漫长，运维与实施费用极其高昂。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td class="comp-highlight">
|
||||
<ul>
|
||||
<li>原生适配数电发票单轨制，具备开箱即用的 AI 智能验真归档。</li>
|
||||
<li>基于本地化轻量级大模型架构，大幅降低实施门槛和部署成本。</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>分贝通</strong></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>以商旅消费支付为切入点，打造“商旅+支付+费控”模式。</li>
|
||||
<li>倡导“无需报销”体验，员工体验极佳。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>强依赖平台内置的消费商城生态，在面对大量零星线下费用、外包采购时灵活性不足。</li>
|
||||
<li>对于复杂的多级跨账簿预算、动态共享额度的精细化管控能力相对偏弱。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td class="comp-highlight">
|
||||
<ul>
|
||||
<li>提供基于本体层屏蔽异构商城壁垒的通用解析能力，线下报销补件与线上免报销消费实现语义对齐。</li>
|
||||
<li>支持复杂层级的预算池（部门/项目/成本中心）秒级动态关联管控。</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>合思 (易快报)</strong></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>一站式业财收支管理，国内市占率居前。</li>
|
||||
<li>生态系统对接广泛，能与国内主流 ERP 无缝打通，配置灵活。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>系统逻辑依然以“传统工作流表单”为主，交互较为传统，缺乏智能助理的深度参与。</li>
|
||||
<li>缺乏中长周期的员工行为偏差分析、规则误报自适应纠偏机制。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td class="comp-highlight">
|
||||
<ul>
|
||||
<li>前台 User Agent 支持自然语言直接进行报销提问、草稿生成、异常核对与智能交互。</li>
|
||||
<li>通过共享本体与规则中心，让财务人员可以用自然语言配置和灰度升级风控规则。</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>每刻报销</strong></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>专注于大中型企业的智能财务共享，规则引擎非常强大。</li>
|
||||
<li>AI 智能审单能力强，支持复杂的集团化多层级架构。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>系统的学习曲线陡峭，对业务人员和普通员工的交互不够平滑。</li>
|
||||
<li>侧重于既定流程的合规审计，对于预算和费控政策调整带来的前瞻性影响缺乏模拟仿真能力。</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td class="comp-highlight">
|
||||
<ul>
|
||||
<li>前台大模型辅助，降低普通用户填单学习曲线。</li>
|
||||
<li><strong>核心差异化：首创“财务数字孪生与仿真沙盘”</strong>，在系统级测试和决策前对费控变动进行量化分析预测。</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="section" id="painpoints-solution">
|
||||
<div class="section-head">
|
||||
<div class="section-kicker">03.2 / SOLUTIONS</div>
|
||||
<h2>X-Financial 痛点解决方案</h2>
|
||||
<p class="section-desc">
|
||||
针对以上竞品普遍面临的系统孤岛、缺乏智能决策、政策调整靠经验等痛点，X-Financial 提出了以 **“AI + 数字化 + 财务数字孪生”** 为核心的下一代费控解决方案。
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="grid cols-2">
|
||||
<article class="card accent-teal">
|
||||
<strong>一、 解决多系统孤岛：Semantic Ontology 本体语义层</strong>
|
||||
<p>
|
||||
传统软件通过 API 强行硬编码对接 CRM、ERP 和商旅系统，一旦系统升级，接口极易断裂，导致业财数据“语义断层”。
|
||||
</p>
|
||||
<p style="margin-top: 8px; font-size: 13px;">
|
||||
<strong>X-Financial 方案：</strong> 我们设计了包含 8 个关键因子的本体语义协议（domain, scenario, intent 等）。无论是口语化描述、页面动作还是三方消费接口，都先被解析为统一的“本体状态”，再分发至下层服务。这实现了跨系统的语义级天然对齐，让数据真正融为一体。
|
||||
</p>
|
||||
</article>
|
||||
|
||||
<article class="card accent-blue">
|
||||
<strong>二、 解决财务假智能：User Agent & Hermes 双智能体闭环</strong>
|
||||
<p>
|
||||
市面软件仅使用 OCR 识别将文字填入表单，人工审核工作量并没有显著降低，也无法识别隐性舞弊。
|
||||
</p>
|
||||
<p style="margin-top: 8px; font-size: 13px;">
|
||||
<strong>X-Financial 方案：</strong> 我们构建了双 Agent 循环。前台 <strong>User Agent</strong> 帮员工和财务进行友好交互，自动查漏补正，解释退回原因；后台 <strong>Hermes 数字员工</strong> 定时在数据底座扫描，分析员工近90/180天的费用画像和行为画像，依据同组偏差算法自动判定隐性风险，出具报告。
|
||||
</p>
|
||||
</article>
|
||||
|
||||
<article class="card accent-amber">
|
||||
<strong>三、 解决规则配置难：LLM 驱动的规则与知识工厂</strong>
|
||||
<p>
|
||||
传统系统的规则引擎配置需要 IT 人员编写繁杂的条件表达式，难以响应公司制度的频繁变动。
|
||||
</p>
|
||||
<p style="margin-top: 8px; font-size: 13px;">
|
||||
<strong>X-Financial 方案：</strong> 支持财务直接上传自然语言描述的制度文档。系统通过大模型将文本转化为可测试、可执行的规则库资产；当发生审批争议或误报时，支持财务通过“反馈池”对规则 and 知识库进行一键校正，进入自进化闭环。
|
||||
</p>
|
||||
</article>
|
||||
|
||||
<article class="card twin-sandbox-card">
|
||||
<span class="twin-sandbox-badge">首创蓝海技术</span>
|
||||
<strong>四、 解决政策盲目调整：财务数字孪生与仿真沙盘（Financial Digital Twin）</strong>
|
||||
<p>
|
||||
很多企业在遇到经营波动时，会盲目调低差旅标准（如酒店降低20%），这容易导致员工满意度下降、灰色报销增多或合规偏离率升高，甚至因行政摩擦上升造成更大的隐性成本。目前市场没有任何一款软件能评估规则调整带来的实际后果。
|
||||
</p>
|
||||
<p style="margin-top: 8px; font-size: 13.5px;">
|
||||
<strong>X-Financial 方案：</strong> 我们通过融合组织架构树、员工费用画像、预算控制规则与历史发票数据库，为企业构建了一个“财务数字孪生体”。当管理层想要修改政策（如“下调销售部酒店标准 15%”）时，可在系统<strong>仿真沙盘（Simulation Sandbox）</strong>中运行模拟。沙盘会模拟历史真实或合成出的数万个出差场景进行回归测算，量化预测此次政策调整对“未来费用降幅（预估降低11%）”、“员工合规偏离率（预估提升8%）”、“预计审批流程摩擦时间（预估提升12%）”的多维影响，为企业提供真正科学的决策辅助。
|
||||
</p>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
@@ -1811,6 +2275,8 @@ budget_control =
|
||||
<a href="#why"><span class="dot"></span>为什么要做</a>
|
||||
<a href="#future"><span class="dot"></span>未来地位</a>
|
||||
<a href="#blue"><span class="dot"></span>蓝海空间</a>
|
||||
<a href="#competitor-analysis"><span class="dot"></span>竞品对比</a>
|
||||
<a href="#painpoints-solution"><span class="dot"></span>痛点解决</a>
|
||||
<a href="#goal"><span class="dot"></span>开发目的</a>
|
||||
<a href="#algorithms"><span class="dot"></span>算法能力</a>
|
||||
<a href="#modules"><span class="dot"></span>模块清单</a>
|
||||
|
||||
238
document/development/receipt-folder/CONCEPT.md
Normal file
238
document/development/receipt-folder/CONCEPT.md
Normal file
@@ -0,0 +1,238 @@
|
||||
# 票据夹功能概念文档
|
||||
|
||||
更新时间：2026-05-29
|
||||
|
||||
## 功能一句话
|
||||
|
||||
票据夹用于归集用户已上传并经过 OCR 识别的原始票据文件，避免票据已识别但忘记关联报销单后无法找回。
|
||||
|
||||
## 背景与问题
|
||||
|
||||
当前系统有两条票据路径：
|
||||
|
||||
- 报销明细附件路径：票据上传到某个草稿费用明细后，会存入 `expense_claims` 附件目录，并写入附件元数据。
|
||||
- 独立 OCR 识别路径：报销对话里先上传票据识别时，`/ocr/recognize` 只返回识别结果，源文件使用临时目录，识别结束后会清理。
|
||||
|
||||
这会导致一个业务缺口：用户可能已经上传票据并完成 OCR，但还没有把票据关联到报销草稿。只要用户关闭会话、切走页面或忘记继续操作，原始票据就没有一个稳定入口可追溯。
|
||||
|
||||
票据夹要补齐这个缺口：凡是系统对用户上传文件做过 OCR 并持久化源文件，就应进入票据夹列表；后续用户可以查看、修正票据信息、删除无效票据，或一键把未关联票据带入报销对话。
|
||||
|
||||
## 目标与非目标
|
||||
|
||||
目标：
|
||||
|
||||
- 在左侧侧边栏的“单据中心”下面新增“票据夹”入口。
|
||||
- 建立票据源文件持久化能力，OCR 后保留原始文件、预览文件和识别元数据。
|
||||
- 提供票据夹列表，复用单据中心的紧凑列表视觉语言。
|
||||
- 支持“未关联票据 / 已关联票据”两个状态切换。
|
||||
- 支持票据详情：基本票据信息可编辑、原始文件可预览、底部返回列表和删除票据。
|
||||
- 支持“一键关联票据”：选择未关联票据，选择未提交草稿或新建报销单，再跳转到报销对话继续填写和关联。
|
||||
|
||||
非目标：
|
||||
|
||||
- 本轮不引入 `document_assets` 等数据库结构变更；先用文件资产和元数据 JSON 完成产品闭环。
|
||||
- 本轮不替换现有报销明细附件接口。
|
||||
- 本轮不把票据夹做成财务共享的全公司档案库；默认只展示当前登录用户自己的票据。
|
||||
- 本轮不在列表页直接完成报销单提交，提交仍回到现有对话核对流程。
|
||||
|
||||
## 用户与场景
|
||||
|
||||
涉及角色：
|
||||
|
||||
- 普通员工：上传票据后稍后再归集到草稿。
|
||||
- 经理或财务用户：在自己名下上传票据时同样需要留存和追溯。
|
||||
|
||||
典型场景：
|
||||
|
||||
1. 用户在个人工作台上传 3 张票据，OCR 成功后暂时没有保存草稿。
|
||||
2. 用户第二天打开票据夹，看到这 3 张票据仍在“未关联票据”。
|
||||
3. 用户进入详情，修正票据类型、金额或日期。
|
||||
4. 用户点击“一键关联票据”，多选未关联票据。
|
||||
5. 用户选择已有草稿，或选择新建报销单。
|
||||
6. 系统打开报销对话，把票据源文件和 OCR 信息带入现有核对流程。
|
||||
|
||||
## 功能能力
|
||||
|
||||
### 票据持久化
|
||||
|
||||
- OCR 入口接收文件后，在识别完成阶段保存源文件。
|
||||
- 保存位置建议为 `storage/receipt_folder/<owner_key>/<receipt_id>/`。
|
||||
- 每个票据目录包含：
|
||||
- 原始文件：`source.<ext>`
|
||||
- 预览文件：`preview.<ext>`，可为空
|
||||
- 元数据：`meta.json`
|
||||
- 元数据记录：
|
||||
- `id`
|
||||
- `owner_key`
|
||||
- `file_name`
|
||||
- `media_type`
|
||||
- `size_bytes`
|
||||
- `uploaded_at`
|
||||
- `status`: `unlinked` / `linked`
|
||||
- `linked_claim_id`
|
||||
- `linked_claim_no`
|
||||
- `linked_item_id`
|
||||
- `linked_at`
|
||||
- OCR 引擎、模型、文本、摘要、置信度、票据类型、场景、结构化字段、提示信息
|
||||
|
||||
### 列表
|
||||
|
||||
- 页签：
|
||||
- 未关联票据
|
||||
- 已关联票据
|
||||
- 表格字段建议：
|
||||
- 票据文件
|
||||
- 识别类型
|
||||
- 费用场景
|
||||
- 金额
|
||||
- 票据日期
|
||||
- OCR 置信度
|
||||
- 关联状态
|
||||
- 上传时间
|
||||
- 交互：
|
||||
- 搜索文件名、摘要、字段值、关联单号
|
||||
- 按状态切换
|
||||
- 点击行进入详情
|
||||
- 未关联页显示“一键关联票据”
|
||||
|
||||
### 详情
|
||||
|
||||
- 基本票据信息：
|
||||
- 文件名只读
|
||||
- 票据类型可编辑
|
||||
- 费用场景可编辑
|
||||
- 票据日期可编辑
|
||||
- 金额可编辑
|
||||
- 商户 / 出发地 / 到达地 / 票据号码等 OCR 字段可编辑
|
||||
- 原始文件展示：
|
||||
- 图片直接预览
|
||||
- PDF 用浏览器内嵌预览
|
||||
- 不可预览类型提供下载入口
|
||||
- 底部动作：
|
||||
- 返回列表
|
||||
- 删除票据
|
||||
|
||||
### 一键关联票据
|
||||
|
||||
流程：
|
||||
|
||||
1. 打开关联弹窗，展示未关联票据多选列表。
|
||||
2. 下一步展示当前用户未提交草稿报销单，也提供“新建报销单”选项。
|
||||
3. 确认后打开现有报销对话。
|
||||
4. 如果选择已有草稿：
|
||||
- 对话以 `link_to_existing_draft` 语义继续。
|
||||
- 携带 `draft_claim_id` 和票据文件。
|
||||
5. 如果选择新建报销单：
|
||||
- 对话以 `create_new_claim_from_documents` 语义继续。
|
||||
- 携带票据文件和 OCR 元数据。
|
||||
|
||||
## 方案设计
|
||||
|
||||
### 后端
|
||||
|
||||
新增模块：
|
||||
|
||||
- `schemas/receipt_folder.py`
|
||||
- `services/receipt_folder.py`
|
||||
- `api/v1/endpoints/receipt_folder.py`
|
||||
|
||||
接口建议：
|
||||
|
||||
- `GET /api/v1/receipt-folder?status=unlinked|linked|all`
|
||||
- `GET /api/v1/receipt-folder/{receipt_id}`
|
||||
- `PATCH /api/v1/receipt-folder/{receipt_id}`
|
||||
- `DELETE /api/v1/receipt-folder/{receipt_id}`
|
||||
- `GET /api/v1/receipt-folder/{receipt_id}/preview`
|
||||
- `GET /api/v1/receipt-folder/{receipt_id}/source`
|
||||
|
||||
OCR 改造：
|
||||
|
||||
- `/api/v1/ocr/recognize` 保持现有响应结构兼容。
|
||||
- 在识别后调用票据夹服务保存源文件和识别结果。
|
||||
- 给每个返回的 OCR 文档补充可选 `receipt_id`、`receipt_preview_url`、`receipt_source_url` 字段。
|
||||
|
||||
### 前端
|
||||
|
||||
新增模块：
|
||||
|
||||
- `services/receiptFolder.js`
|
||||
- `views/ReceiptFolderView.vue`
|
||||
- `assets/styles/views/receipt-folder-view.css`
|
||||
|
||||
导航改造：
|
||||
|
||||
- `useNavigation.js` 新增 `receiptFolder`，放在 `documents` 后面。
|
||||
- `accessControl.js` 将 `receiptFolder` 作为默认可见视图。
|
||||
- `router/index.js` 自动生成 `/app/receiptFolder` 路由。
|
||||
- `AppShellRouteView.vue` 渲染新页面，并允许页面触发 `openSmartEntry`。
|
||||
|
||||
对话衔接：
|
||||
|
||||
- 票据夹确认关联时，前端从 `source` 接口取回 Blob，构造 `File` 对象传给 `openSmartEntry`。
|
||||
- 同时把已编辑 OCR 元数据转为 `initialReceiptDocuments` 或直接通过 `prompt` / `extraContext` 进入对话。
|
||||
- 本轮优先用现有 `initial-files` 和 `initial-prompt` 打开对话，确保用户可以继续核对和保存。
|
||||
|
||||
## 算法与公式
|
||||
|
||||
当前功能不涉及显式数学公式。
|
||||
|
||||
列表排序使用上传时间倒序：
|
||||
|
||||
$$
|
||||
sortKey(receipt) = uploadedAt(receipt)
|
||||
$$
|
||||
|
||||
状态归类：
|
||||
|
||||
$$
|
||||
status(receipt) =
|
||||
\begin{cases}
|
||||
linked, & linkedClaimId \neq \emptyset \\
|
||||
unlinked, & linkedClaimId = \emptyset
|
||||
\end{cases}
|
||||
$$
|
||||
|
||||
## 测试方案
|
||||
|
||||
后端：
|
||||
|
||||
- OCR 识别后会保存源文件和 `meta.json`。
|
||||
- 列表只返回当前用户票据。
|
||||
- `status=unlinked` 只返回未关联票据。
|
||||
- 详情可读取 OCR 字段。
|
||||
- PATCH 后字段持久化。
|
||||
- 预览接口能返回图片或 PDF。
|
||||
- DELETE 只删除票据夹根目录下的目标票据。
|
||||
|
||||
前端：
|
||||
|
||||
- 导航中“票据夹”位于“单据中心”下面。
|
||||
- 列表空态、加载态、错误态可用。
|
||||
- 未关联和已关联两个页签计数正确。
|
||||
- 点击行进入详情。
|
||||
- 详情可保存字段、返回列表、删除票据。
|
||||
- 一键关联弹窗能完成票据选择和草稿选择。
|
||||
|
||||
集成：
|
||||
|
||||
- 上传票据触发 OCR 后，票据出现在票据夹。
|
||||
- 从票据夹选择未关联票据，可打开报销对话。
|
||||
- 选择已有草稿时，对话带入草稿单号。
|
||||
- 选择新建报销单时，对话提示基于票据新建。
|
||||
|
||||
## 指标与验收
|
||||
|
||||
- OCR 成功返回后，票据夹列表能查到对应源文件。
|
||||
- 票据源文件和预览文件在重启后仍可访问。
|
||||
- 未关联票据和已关联票据状态切换正确。
|
||||
- 票据详情字段修改后刷新仍保留。
|
||||
- 删除票据后列表不再显示，预览接口返回 404。
|
||||
- 侧边栏位置符合要求：票据夹在单据中心下面。
|
||||
- 单个新增核心前端和后端模块不超过 800 行。
|
||||
|
||||
## 风险与开放问题
|
||||
|
||||
- 当前报销草稿流主要持久化 OCR 文本和文件名，真实文件复制到报销明细附件目录仍需要进一步打通。
|
||||
- 本轮采用文件元数据而非数据库，适合先完成闭环；后续若需要审计、权限、跨用户协作和全文检索，应升级到资产表。
|
||||
- 已关联状态如何自动回写，需要在后续把票据夹 ID 与报销明细 `invoice_id` 建立更强绑定。
|
||||
- 多票据关联时，如果用户中途取消对话，本轮仍保留为未关联，避免误标。
|
||||
78
document/development/receipt-folder/TODO.md
Normal file
78
document/development/receipt-folder/TODO.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# 票据夹功能 TODO
|
||||
|
||||
更新时间：2026-05-29
|
||||
|
||||
## 阶段一：调研与契约
|
||||
|
||||
- [x] 梳理现有单据中心导航、列表样式和详情入口。[CONCEPT: 方案设计]
|
||||
证据：已确认 `DocumentsCenterView.vue`、`useNavigation.js`、`AppShellRouteView.vue` 是前端入口。
|
||||
|
||||
- [x] 梳理现有 OCR 和报销附件存储链路。[CONCEPT: 背景与问题]
|
||||
证据：已确认 `/ocr/recognize` 只临时识别；报销明细附件由 `expense_claim_attachment_*` 写入 `expense_claims` 存储。
|
||||
|
||||
- [x] 确定本轮不做数据库结构变更，先用票据文件资产和元数据 JSON 完成闭环。[CONCEPT: 目标与非目标]
|
||||
证据：避免新增迁移，降低本轮开发风险。
|
||||
|
||||
## 阶段二：文档
|
||||
|
||||
- [x] 创建 `document/development/receipt-folder/CONCEPT.md`。[CONCEPT: 全文]
|
||||
证据：本文档已落地。
|
||||
|
||||
- [x] 创建 `document/development/receipt-folder/TODO.md`。[CONCEPT: 测试方案]
|
||||
证据：本文档已落地。
|
||||
|
||||
## 阶段三：后端票据资产层
|
||||
|
||||
- [ ] 新增 `schemas/receipt_folder.py`，定义列表项、详情、字段更新和删除响应。[CONCEPT: 后端]
|
||||
|
||||
- [ ] 新增 `services/receipt_folder.py`，负责源文件保存、元数据读写、预览解析、列表过滤和安全路径校验。[CONCEPT: 票据持久化]
|
||||
|
||||
- [ ] 新增 `api/v1/endpoints/receipt_folder.py`，暴露列表、详情、更新、删除、预览和源文件接口。[CONCEPT: 后端]
|
||||
|
||||
- [ ] 在 `api/v1/router.py` 注册票据夹接口。[CONCEPT: 后端]
|
||||
|
||||
- [ ] 改造 `/ocr/recognize`，OCR 后保存源文件并把 `receipt_id` 等可选字段带回前端。[CONCEPT: OCR 改造]
|
||||
|
||||
## 阶段四：前端票据夹页面
|
||||
|
||||
- [ ] 新增 `services/receiptFolder.js`，封装票据夹接口和 Blob 文件读取。[CONCEPT: 前端]
|
||||
|
||||
- [ ] 新增 `ReceiptFolderView.vue`，实现列表、状态页签、搜索、一键关联入口和详情切换。[CONCEPT: 列表]
|
||||
|
||||
- [ ] 新增 `receipt-folder-view.css`，复用单据中心紧凑企业级视觉，避免继续拉大现有 `DocumentsCenterView.vue`。[CONCEPT: 列表]
|
||||
|
||||
- [ ] 在 `useNavigation.js` 增加 `receiptFolder`，并放在 `documents` 后面。[CONCEPT: 前端]
|
||||
|
||||
- [ ] 在 `accessControl.js` 增加默认可见权限和默认路由顺序。[CONCEPT: 前端]
|
||||
|
||||
- [ ] 在 `AppShellRouteView.vue` 渲染票据夹页面，并让页面可打开报销对话。[CONCEPT: 一键关联票据]
|
||||
|
||||
## 阶段五：一键关联流程
|
||||
|
||||
- [ ] 实现未关联票据多选弹窗第一步。[CONCEPT: 一键关联票据]
|
||||
|
||||
- [ ] 实现未提交草稿选择和“新建报销单”选择第二步。[CONCEPT: 一键关联票据]
|
||||
|
||||
- [ ] 从票据源文件接口取回 Blob 并构造 `File` 对象传给报销对话。[CONCEPT: 对话衔接]
|
||||
|
||||
- [ ] 选择已有草稿时，打开对话并带入草稿单号和关联提示。[CONCEPT: 一键关联票据]
|
||||
|
||||
- [ ] 选择新建报销单时，打开对话并带入基于票据新建的提示。[CONCEPT: 一键关联票据]
|
||||
|
||||
## 阶段六：测试与验证
|
||||
|
||||
- [ ] 补充后端票据夹服务和接口测试，超时时间控制在 60s 内。[CONCEPT: 测试方案]
|
||||
|
||||
- [ ] 补充前端导航和票据夹视图模型测试。[CONCEPT: 测试方案]
|
||||
|
||||
- [ ] 运行前端构建或定向测试。[CONCEPT: 指标与验收]
|
||||
|
||||
- [ ] 在 Docker `x-financial-main` 的 `/app` 内运行后端定向测试。[CONCEPT: 测试方案]
|
||||
|
||||
- [ ] 手动核对侧边栏位置、列表密度、详情预览和关联弹窗。[CONCEPT: 指标与验收]
|
||||
|
||||
## 阶段七：收口
|
||||
|
||||
- [ ] 回看 `CONCEPT.md` 验收标准，确认已实现项均有证据。[CONCEPT: 指标与验收]
|
||||
|
||||
- [ ] 更新本 TODO 的完成状态和验证记录。[CONCEPT: 测试方案]
|
||||
Reference in New Issue
Block a user