核心用法
organisation-documents 是会计领域的入口级中枢技能，负责处理所有进件文档（邮件附件、手动上传、批量导入）。其唯一正确的调用方式是执行统一命令 python3 scripts/main.py <dossier_inbox> <racine_clients>，随后读取生成的 _report.json 向会计师汇报。
技能采用三阶段流水线：① 银行对账单优先——以账户持有人作为确定客户身份，自动构建 clients.json；② 发票分类——比对购销双方与客户库（精确匹配→模糊相似度≥0.82），单向匹配则归档至 invoices/in/ 或 out/，无匹配则进入待识别队列；③ 其他文档——无法识别类型的归入 _non-attribue/。全程通过 scripts/extract.py 调用 pdftotext -layout 提取字段，禁止任何人工目测或即兴 Python 重写。
客户识别规则严格分层：银行对账单标题持有人（确定性）→ 邮件/域名/SIREN 映射 → 模糊商号匹配（≥0.82 且仅单方匹配）。无任何可靠信号时，文档进入 _a-identifier/ 并生成 onboarding 问题，待会计师确认后更新 clients.json 并重新分类。
显著优点
- 零猜测设计：字段提取、客户归属、文件名生成完全由脚本执行，消除人工分类导致的
invoice_id错误（如历史案例中出现的"N"、"des"、"um-rix"等无效值） - 确定性去重：SHA-256 哈希比对，避免重复处理同一文档
- 渐进式客户学习：从银行对账单自动推断客户身份，通过会计师确认完善映射，实现后续自动归因
- 结构化输出：生成
clients.json（客户主数据）、_index.json（去重索引）、_report.json（处理报告），支撑下游rapprochement-bancairereconciliation 流程 - 严格隔离：数据不出 LXD 容器，10 年强制保留，无删除机制
潜在缺点与局限性
- 外部依赖硬性要求：需
poppler-utils提供pdftotext，缺失时技能完全阻塞，不得降级处理 - 模糊匹配阈值固定：0.82 的相似度门槛可能对复杂商号（缩写、变体）过于严苛，导致过度进入人工队列
- 单点故障风险：
_report.json解析失败或脚本崩溃时，无降级路径，必须人工介入修复 - onboarding 延迟：新供应商首单需人工确认，批量导入场景下可能产生大量待识别文档
- 文件名长度限制：14 字符交易对手截断可能影响可读性
适合人群
- 中小会计师事务所寻求自动化进件处理的会计师
- 需要标准化发票-对账-催款流程的企业财务部门
- 注重数据 lineage 与审计追踪的合规导向用户
常规风险
- 脚本版本漂移：禁止在调用中内嵌临时 Python 逻辑，否则导致与
extract.py行为不一致 - 客户误判链式反应：若会计师 onboarding 回答错误，后续所有同发件人文档将错误归类
- 提取失败堆积：
pdftotext无法解析的扫描件或加密 PDF 进入_incomplet/，需人工处理但未主动告警 - 下游技能依赖：
rapprochement-bancaire依赖本技能输出的文件名规范，手工干预分类将破坏 reconciliation 准确性