站内已经有两篇 Documents + Sign 相关文章，一篇偏 project 路由，一篇偏 reference_doc 与 no_document 防重复。这一篇刻意换焦点：专门讲签署模板如何决定工作区落点、标签规则以及签完之后文档如何交回 Documents。核心源码在 enterprise/documents_sign/models/sign_request.py。
一、签署请求一创建，workspace 语义就已经开始生效
SignRequest.create() 不是单纯落一条 sign.request。它会读取 template_id.document_ids.attachment_id，检查模板文档已经在 Documents 里对应到哪些 document，并尝试为新请求设置 reference_doc。
这个动作的商业含义很大：签署请求从创建时就被拉回 Documents 世界，而不是等签完再说。也就是说，模板本身所在的工作区、文档挂载关系和引用对象，会决定这次签署在文档管理侧的归属。
二、template 不是只决定字段位置，还决定 folder/tag 继承
这篇要特别强调模板治理。源码里的 _get_document_tags() 直接返回 template_id.documents_tag_ids，_get_document_folder() 直接返回 template_id.folder_id。这说明签署模板除了规定签署字段，还在决定：
- 完成后的文档默认回到哪个 workspace / folder；
- 文档自动继承哪些标签；
- 后续检索、权限与自动化规则会落在什么范围里。
很多团队把签署模板当成 UI 模板，其实在 Documents 语义里，它更像一份“归档策略模板”。
三、finalization 的难点不是生成 PDF，而是 handoff 不要出错
_generate_completed_documents() 和 _send_completed_documents() 这两个方法要放一起看。源码显式用了 with_context(no_document=False) 与 with_context(no_document=True)，避免同一份完成文档在“已经被 Documents 引用”的情况下再次生成重复 document，导致唯一键冲突。
这就是标题里的 finalization handoff：签署完成后，问题不是“能否导出 PDF”，而是“这份 PDF 到底由谁接管，接管一次还是两次”。如果 handoff 重复，文档库就会出现双份或引用紊乱；如果 handoff 丢失，签署结果又会游离在 Documents 工作区之外。
四、reference_doc 是把签署和工作区绑在一起的中轴
当模板附件已经对应到 Documents 文档，并且这些文档在同一个 folder 时，源码会把 reference_doc 指向对应 folder。这个设计很聪明：它没有强迫每次签署都重新决定归档位置，而是优先沿用模板所处的文档语义。
对企业来说，这能保证合同模板、政策模板、审批模板在各自工作区里自然闭环，不需要每次签完手工挪目录。
五、签署人权限也是 handoff 的一部分
SignRequestItem._sign() 在签署后会给 signer 和 requester 对完成文档补 view access。很多人容易忽略这一点：完成交接不只是文件入库，还包括“谁应该立刻有权限看成品”。
如果你只管文件生成，不管访问补权，业务侧会觉得“明明签完了，为什么相关人看不到”。
六、实战注意事项
1. 模板 folder 先治理，再谈自动归档
模板随手放、folder 不清晰，后面的自动 handoff 只会把混乱放大。
2. 标签不要贪多
documents_tag_ids 是归档规则的一部分，不是给 UI 加彩色贴纸。标签体系混乱，后面检索和自动化都会崩。
3. 重复文档问题先查 no_document / reference_doc
很多“为什么多出一份已签文件”，根源就在这里。
七、结论
Odoo 企业版 Documents + Sign 真正强的地方，不是签完能生成文件，而是它让模板在创建时就决定工作区语义、标签语义和完成后的交接方式。把这条 handoff 看明白，你才会知道为什么企业版文档签署不是一个简单电子签附件功能。
主要源码锚点：
enterprise/documents_sign/models/sign_request.py
DISCUSSION
评论区