结论先行
很多团队说“电子发票进来后 OCR 一下建 vendor bill 就好”，但企业版真正实现的是一条带文件夹、文档类型、识别状态和会计生命周期的长链。它的目标不是更快建单，而是让收票、识别、入账、归档四件事不会互相踩边界。
第一层：入口或表面动作
第一层在 Documents。documents_account.account_journal 会为不同 journal type 建立/同步专属文件夹设置；documents_document 还会处理像 UBL/XML 中嵌 PDF 这样的情况，确保一个“收到的文件”先被正确归入财务文档语境。这里的意思是：会计票据进入系统时，第一身份是 document，不是 account.move。
第二层：真正的业务护栏
第二层是识别。account_invoice_extract 里的 invoice 模型围绕 extract_state、可数字化状态、自动发送条件等字段组织 OCR 流程。系统会区分哪些发票能自动送识别、哪些需要人工校正、哪些在过账后把修正结果反哺 OCR 服务。识别引擎处理的是“从文档提取结构化字段”，而不是替代会计对象本身。
第三层：状态落点与边界
第三层才是会计生命周期。无论是 Documents 侧的“Create Vendor Bill”动作，还是 OCR 抽出的字段回填，最终都要落到 account.move 的 draft / posted 语义里。你一旦回草稿、重做、或者多公司共享财务文件夹，权限与状态边界都必须回到会计模型来收口，而不能让 documents/OCR 直接宣布“这票已经算完了”。
为什么这套设计更稳
为什么这里还能把 Peppol 带进来？因为 documents_account_peppol 说明企业版已经把“接收电子票据网络/代理状态”也纳入这条管线。Peppol 不是单独一套账务系统，而是文档入口的一种来源。它进入后仍然要走文档归类、字段抽取、会计建单、后续归档这几段。来源不同，护栏不变。
实战启示
从框架角度看，这条链特别值得借鉴：外部来源（邮箱、上传、Peppol）先进入 Documents 这一入口层；识别服务（OCR）只提供字段建议；真正的业务真相仍以 account.move 生命周期为准。谁先到、谁识别得快，都不能跳过状态机。这种分层，才是企业系统里“接外部票据”最稳的姿势。
DISCUSSION
评论区