付费预约如果只停留在“客户下了单、日历里有个事件”，交付团队还是得手工再建任务、再抄需求、再补起止时间。真正有价值的，是付款成功后项目任务能自己长出来，而且内容别丢。
这篇文章主要参考了以下企业版源码入口：
enterprise/website_appointment_sale_project/models/sale_order_line.pyenterprise/website_appointment_sale_project/views/project_views.xml
一、这篇功能真正解决什么问题
website_appointment_sale_project 解决的是预约销售和项目执行脱节的问题。官网预约往往发生在前台，项目任务却由后端交付团队负责；如果中间没有可靠桥接，客户在预约页填的所有信息都会在交付时重新录一次。
二、核心链路怎么走
1. sale order line 负责把预约信息打包进任务值
_timesheet_create_task_prepare_values() 先调用上游逻辑，再检查当前销售行是否带有 calendar_event_id 与 calendar_booking_ids。一旦命中，它就把预约相关信息追加进 task values，而不是另外走一套任务创建流程。
2. 人员、资源与问卷答案会分别落到不同任务字段
如果预约按用户排班，源码会把选中的 staff 写进 user_ids；如果按资源排班，则把资源名映射成 project.tags。同时，预约表单里的问题与答案会被格式化成 HTML description。这说明官方不是简单“传一个备注”，而是把不同业务对象有意识地拆到合适字段里。
3. 付款确认后，预约对象正式转成可执行任务
_action_confirm() 中会先解归档 calendar_event_id，再调用 _make_event_from_paid_booking()，随后继续确认销售流程。任务创建后的 _timesheet_create_task() 还会把预约参与人订阅到任务消息里，让沟通链自然接上。
三、新手最容易踩的坑
- 以为任务只会带一个预约标题。实际上问卷答案、开始时间、截止时间、工时、参与人都可以落过去。
- 以为资源型预约和员工型预约一样处理。源码明确把两种模式拆开：一个写
user_ids，一个写tag_ids。 - 以为支付前就该生成正式事件和任务。模块故意把关键动作放在确认/支付成功之后。
四、实战落地时最该盯的点
- 预约问卷设计要尽量结构化，因为这些答案会直接进入任务描述，影响交付团队第一眼理解。
- 资源型预约最好先统一资源命名，否则 tag 会出现重复或难以搜索的脏数据。
- 若客户需要跟踪任务进度，要确认 attendee 订阅流程是否符合你的通知策略。
五、结论
预约转项目任务真正值钱的，不是省去一次点击，而是把排班对象、资源、问卷答案、时间边界和沟通对象完整搬过来。这样前台预约才不是一个孤立销售动作，而是真正接上后端交付链。
DISCUSSION
评论区