很多人一提 Peppol，就默认“电子发票到了，系统立刻建一张 vendor bill”。但企业版 documents_account_peppol 做的恰恰是给企业多一个先收文档、后决定怎么入账的缓冲层。
核心源码非常集中：
enterprise/documents_account_peppol/models/account_edi_proxy_user.pyenterprise/documents_account_peppol/models/res_company.pyenterprise/documents_account_peppol/models/res_config_settings.py
虽然模块不大，但它切中的正是实施里最容易被忽略的治理问题。
一、企业真正纠结的不是“能不能收 Peppol”，而是“收进来先去哪”
res.company 上新增了三个关键字段：
peppol_reception_modedocuments_account_peppol_folder_iddocuments_account_peppol_tag_ids
这说明企业版把“接收电子发票”拆成两个层次：
- 接入层：Peppol 网络把发票附件送达 Odoo；
- 落点层：收到以后，是直接建 bill，还是先变成 Documents 文档。
很多组织并不希望所有收到的电子单据立刻进入会计账务，因为还可能涉及：
- 共享服务中心先做归档；
- AP 团队先做校验与补证；
- 不同国家 / 法人有不同入账窗口；
- 某些 Peppol 文档先要按内部分类或审批流处理。
二、documents 模式到底做了什么
在 _peppol_import_invoice() 里，若 company_id.peppol_reception_mode == 'documents'，系统不会走默认的“直接导入发票”主链，而是：
- 创建
documents.document； - 把收到的
attachment_id直接挂到文档； - 把文档放进指定 folder；
- 用
Command.set()一次性落入公司级预设 tag； - 在文档上记一条消息：已成功收到该 Peppol document，并带上 UUID。
最后返回值只有 {'uuid': uuid}。这很关键：它表达的是网络接收已确认，而不是“账务处理已完成”。
三、为什么 folder + tag 不是小装饰
实施时最容易低估 folder_id 和 tag_ids 的价值，觉得“后面人工拖一拖也行”。其实它们就是治理接口。
folder 解决的是归属
同样一张电子发票，先进入哪一个工作篮，决定了谁有权限先看、谁负责下一步。
tag 解决的是路由
标签不是为了好看，而是为了后续自动化筛选：
- 哪些属于 Peppol 收票；
- 哪些需要 OCR / 补字段；
- 哪些要进入 AP 审核或地区化流程。
如果没有这一步，Documents 只是“电子发票的另一个垃圾桶”；有了这一步，它才是前置工作台。
四、最容易误解的地方
1. “Documents 模式就是比直接建 bill 慢一步”
不完全对。它不是无意义地慢，而是把网络接收成功和会计确认入账故意拆开。对多实体、强内控企业，这一步非常有价值。
2. “收到 UUID 就代表供应商发票已经在账上”
不对。这里 UUID 只证明 Peppol 文档已经被 Odoo 接住并登记，不代表 vendor bill 已经生成。
3. “只有会计团队才关心这个模块”
也不对。这个模块同时涉及 Documents 权限模型、文件夹治理、标签规则、EDI 接收落点，是典型的平台 / 合规层议题，所以归到“框架”更合适。
五、实战建议
- 若企业已有 AP 共享中心，优先评估
documents模式，不要默认所有电子票据直落账。 - 设计 folder 时先按法人或流程职责划分，不要只建一个“大一统收票箱”。
- tag 体系要和后续自动化或审批规则一起设计，否则标签会很快沦为摆设。
- 对业务方明确说明：Peppol 接收成功 ≠ 账务已确认；两者是不同阶段。
六、结论
documents_account_peppol 虽然代码很短，但它回答的是一个很重的问题：电子发票进入系统后，应该先成为账单，还是先成为受治理的文档资产。 企业版给出的答案不是唯一流程，而是可配置的接收边界。
DISCUSSION
评论区