印章收发与结算管理系统
ORANGEZH / 交付案例

印章收发与结算管理系统

刻章任务收发、证明文件结构化解析与批量结算的小而全定制交付:状态机流转、金额强制一致与可配置考核阈值。

项目概览

项目背景

企业在设立环节需要刻制公章。管理刻章服务主体的机构长期面对这样的日常:刻章任务靠人工分派,证明与发票靠人工核对,结算按周期手工汇总对账,时效超期没人考核,过程缺少统一留痕,内部的白名单审批还在走纸质单据。链条不算长,但每一环都靠人盯,出了错也很难追溯。

这类业务不适合套用标准化产品,也不需要庞大的平台:流程边界清楚、角色固定,缺的是一套把收发、核对、结算串起来、并且每个动作都留下记录的定制系统。这套印章收发与结算管理系统的定位正是”小而全”——环节不多,但每一环都要能用、能查。

客户当时的状态

刻章任务由上游生产系统生成并分配到各持牌刻章企业,管理方负责后续的收发与结算。改造前这些环节分散在不同人的表格里:证明上写了什么,要人眼对着核;发票金额对不对得上结算单,往往到付款前才发现;漏结要翻历史记录了才能发现;超期只有事后统计,没有事前提示。系统的取舍也因此很克制:先把任务下发到结算完成这条主链在线上走通,其余能力分批跟进。

文件核对,我们为什么不猜

刻章证明是固定版式的 PDF,数电票带有随票生成的数据文件。系统的做法是文件结构化解析与自动核对:读取证明 PDF 的文字层,按模板规则提取印章明细与时间节点,回填任务详情并与录入要求自动比对;发票直读数据文件,PDF 原件按行规则解析,再做金额大小写互验、发票明细与购方税号对照结算数据勾稽,不一致就醒目提示人工复核。

关键在于对不确定的东西一律不猜。扫描件没有文字层,异常文件版式漂移,规则解析失败时系统做软失败处理:提示解析未完成、引导人工填写,绝不猜测字段值入库。取舍很直白——多一次人工录入,最多慢一步;把猜出来的内容写进核对与结算依据,错了很难回头。

主链路上的几条硬规则

刻章任务沿状态机流转:待上传、待交付、已交付三档,管理方清点实体章后手动确认交付,发现证明有问题可以打回重传,每次流转都留痕。结算按周期与刻章企业汇总,逐条下发结算单;发票金额必须与结算金额一致才允许提交,不一致进不了结算,只能走打回。漏结的任务可在后续周期补结,作废有单独入口。

时效考核以下发到证明内交付时间的耗时为口径,预警与超时两档阈值做成数据字典配置项,业务人员可随时调整,不必改代码;报表按预警、正常、超时分色呈现,仅面向管理方,线下奖惩机制刻意留在系统外。白名单审批改为线上填写加审批留痕,但它与刻章、结算两条主业务相互独立——台账规则不该牵动主业务逻辑。

角色边界与账号安全

系统按管理员、管理方、刻章企业三类角色划分功能与数据范围:刻章企业账号登录后只能看到本公司名下的任务、结算与发票。前端登录后按角色下发菜单并据此生成动态路由,越权访问在路由层拦截,接口侧再做一次角色校验,不把前端隐藏当安全边界。

账号安全单独做了一轮加固迭代:口令以 BCrypt 散列存储,不保存明文;前后端执行同一套强密码规则,对长度与字符类别都有校验;登录页不展示、也不预填任何账号信息。前端是 PC 端单页应用,面向实际办公终端做了浏览器兼容构建。

交付状态与边界

本项目已完成开发与测试环境部署演练,生产上线与运行数据未披露。上游任务与企业同步接口按插入式入库设计,只承接数据、不改动上游的分配结果,实际联通依赖上游对接条件。打款等资金动作在系统外完成,系统承担的是结算单生成、核对与清单导出。

项目信息

客户

某区级政务相关管理机构

行业

行政事务与公共服务

项目周期

未披露

技术栈

Java 17 / Spring Boot 3 / MyBatis-Plus / Sa-Token / Flyway / MySQL / Apache PDFBox / Knife4j / SpringDoc / Vue 2 / Element UI / ECharts / Vite

服务类型

印章收发与结算管理系统

CHALLENGES

需要共同解决的关键问题

01

上游每日推送刻章任务,只能插入式入库,不改动上游分配结果

02

管理员、管理方、刻章企业三类角色职责交叉,数据范围需要隔离

03

刻章证明与发票需自动核对,扫描件与异常文件不能误判

04

发票金额必须与结算金额强制一致,漏结还要能在后续周期补结

05

时效考核阈值尚未定稿,必须做成可配置且不干扰业务主流程

核心功能

小而全交付里做实的细节

任务状态机流转

刻章任务沿待上传、待交付、已交付三档流转,管理方清点后确认交付,发现问题可打回重传,每次流转都留痕。

证明解析与回填

固定模板证明 PDF 按文字层规则解析,自动提取印章明细与时间节点回填任务;异常文件软失败转人工填写,不做猜测性判定。

结算与发票校验

按结算周期与刻章企业汇总已交付任务,逐条下发结算单;发票金额与结算金额强制一致方可提交,支持补结、打回与作废。

考核阈值可配置

以任务下发到证明内交付时间的耗时为考核口径,预警与超时两档阈值以数据字典配置,可随时调整,报表分色呈现。

角色与口令安全

管理员、管理方、刻章企业三类角色隔离功能与数据范围,口令以 BCrypt 散列存储,前后端执行同规则强密码校验。

白名单审批台账

白名单事项线上填写、管理员审批,审批人与结论全程留痕,驳回必填意见,历史可查,与刻章结算业务互不联动。

PROJECT MATERIALS

项目图纸与资料

以下内容来自项目原始资料,保留准确的业务关系与技术含义,并通过统一画框呈现。点击图片可查看高清细节。

01

印章收发与结算管理系统 · 系统能力地图

印章收发与结算管理系统 · 系统能力地图(按公开口径整理,不含客户名称与部署信息)

原图
02

印章收发与结算管理系统 · 应用技术架构

印章收发与结算管理系统 · 应用技术架构(按公开口径整理,不含客户名称与部署信息)

原图
03

印章收发与结算管理系统 · 服务交付流程

印章收发与结算管理系统 · 服务交付流程(按公开口径整理,不含客户名称与部署信息)

原图
04

印章收发与结算管理系统 · 部署架构

印章收发与结算管理系统 · 部署架构(按公开口径整理,不含客户名称与部署信息)

原图
PROJECT MATERIAL

项目资料

ARCHITECTURE

分层技术架构

架构归纳为五层:PC 管理端与同步接口构成入口;接入与权限层负责令牌认证、密钥鉴权与数据范围控制;业务层承载任务与证明、结算与发票、时效考核、白名单台账;平台能力层提供数据字典、附件与待办通知;数据层以 MySQL 存储业务数据,模式以版本化迁移脚本演进。部署拓扑与库表细节不公开。

FLOW 01

入口层

PC Web 管理端 上游同步接口 接口文档

覆盖人工操作与系统对接两类接入场景

FLOW 02

接入与权限层

令牌认证 角色与菜单权限 接口密钥鉴权 数据范围控制

统一身份校验并限定各角色可见的数据范围

FLOW 03

业务服务层

刻章任务与证明 结算与发票 时效考核 白名单台账

组织收发、结算、考核主线为可追溯链路

FLOW 04

平台能力层

数据字典 附件存储 待办通知 版本化数据库迁移

通用能力复用,业务代码专注业务规则

FLOW 05

数据层

MySQL 业务库 本地附件目录 统计汇总视图

业务数据与附件分治,模式变更留档可追溯

项目成果

数据驱动,用真实成果说话

3

任务状态机:待上传·待交付·已交付

3

角色:管理员·管理方·刻章企业,数据范围隔离

4个功能域

刻章业务·结算管理·台账与考核·系统管理

先圈定第一期能交付的边界

从需求评审留档、数据模式设计到解析核对规则与部署演练,一起确定最小可交付范围与明确不做的部分。