公文归档方案
公文的正文、附件与审批意见，从拟稿那天起就留在业务系统里。办公室走完审批、领导完成签发、印章盖下的那一刻，这套记录其实已经齐了 —— 缺的只是按档案的标准把它接住。
系统在公文办结的节点自动接件，按归档标准完成版式转化、信息包封装与四性检测，再自动著录发文机关、发文字号与成文日期；电子公文单独成套保存，纸质件数字化后并入同一案卷。
公文办结，档已就位
公文档案不是事后收上来的，而是随发文与收文两条流程一路形成的。公文办结那一刻，该有的材料其实已经齐了；系统要做的，是按档案的标准把它们接住。
关键在「预归档」这一步 —— 公文在办结的瞬间就进入了待归档队列，而不是等到年底集中移交时再回头翻找。
多源接入，一档归集
公文的正文、附件与审批意见散落在办公系统、电子签章与历史系统里，各有各的台账。方案要做的是打通这些系统，把一件公文在流转中产生的材料按件汇聚、转版式、封包，再送入档案系统。
办公与流程系统
- OA 办公系统
- 公文流转与审批
- 内网邮件与通知
签章与用印
- 电子签章系统
- 套红与用印记录
- 电子印章有效性
线下与历史件
- 纸质公文数字化
- 历史存量公文
- 扫描件与照片
方案要解决的核心问题，是把「收公文」从人工催办变成系统自动完成 —— 公文本来就已经在业务系统里，缺的只是按档案标准接住它的那条线。
五层架构，各司其职
自下而上依次是基础层、数据层、服务层与应用层，最上层通过 PC 工作台与移动端交付到人。中间的服务层把版式转化、识别抽取与检测能力收拢成统一接口，应用端按需调用。
公文归档 · 总体架构
电子公文以 OFD 或 PDF 版式文件为归档格式，正文、附件、审批意见与签章信息一并纳入归档信息包，确保归档件与流转件内容一致、可长期读取。
归档信息包按标准要求组织目录结构与元数据，检测通过后方可入库；纸质公文经数字化后与电子公文统一编目，两类载体在平台上一并管理。
五层里最值得说的是中间那层 —— 版式转化、识别抽取与四性检测收拢在服务层做成统一接口，能力升级时不必回头改业务功能。
办结触发，五步归档
公文办结到正式入库，中间隔着版式转化、信息包封装与四性检测这几道关。系统把这五步串成一条自动链路，每一步的中间结果都留在案卷里，出了问题能一步步往回查。
五步里最关键的是四性检测 —— 它是电子公文能不能只保存电子版的那道分水岭，所以放在正式入库之前当闸门，而不是入库之后再补检。
自动分类，自动著录
公文的元数据本来就在流转过程里 —— 发文字号、成文日期、发文机关与密级，业务系统都记着。系统把这些字段自动采集过来填进著录项，再按规则判定分类与保管期限。
这几件事合起来解决的是一个老问题 —— 著录项里最花时间的部分，其实早就在系统里了，缺的只是把它接过来。
单套归档，合规有据
公文归档绕不开三个问题：电子件能不能单独存档、电子签章归档后还有没有效、数据十年后还读不读得出来。这三件事分别由版式格式、信息包结构与检测规则兜底。
这四件事的次序不能颠倒 —— 先转成版式、再按包封装、然后过检测，最后才谈得上单套制；任何一步跳过，电子公文都还得依赖纸质件兜底。
机器先核，人来判断
AI 能力不是单独一块模块，而是嵌在接件、转化、著录与检测这些高频动作里。机器把重复的识别、比对与校验做掉，人把精力留给需要判断的部分。
这些能力有一个共同点 —— 都不单独占一个菜单，而是长在接件、著录、检测这些原本就要做的动作里。
查得到，也要拿得出
公文归档之后最常被问到三类问题：某一件公文在哪、某个事由下有哪些文、某份文件能不能外借。系统把这几条路径都铺好，查到即可看原文，能不能看则由权限说了算。
公文档案最怕的不是查不到，是查得到却不全 —— 材料齐不齐由系统说了算，比由人说了算可靠。
办公不停，归档不断
公文归档最终要落到三件事上：公文不必再打印出来重新扫描，归档件不必再逐份手工著录，日后查用既找得到也拿得出。
从「年底集中收一次公文」到公文办完就自动到位 —— 改变的其实是公文从哪来、往哪存、由谁核的整套秩序。
让公文，办完即归档
告诉我们单位在用的办公与电子签章系统、公文年均办件量与档案门类划分，轩恩将提供公文归档方案与系统演示，也可按需出具归档信息包结构与检测项清单。
