Odoo hr.attendance考勤上报提示签退时间早于签到时间

问题背景 #

通过XML-RPC向Odoo hr.attendance模型上报员工签到（check_in）、签退（check_out）事件，上报时间均为UTC时间，示例上报数据如下：

ID: 75 Scan Type: check_in   Scan Time: 2022-06-22 14:14:57
ID: 75 Scan Type: check_out  Scan Time: 2022-06-22 22:55:12

第一条check_in记录上报后系统显示正常，对应本地时间为当日上午7:14，符合时区换算预期。上报对应check_out事件时，接口返回错误：

[faultCode] => 2
[faultString] => "Check Out" time cannot be earlier than "Check In" time.

从上报参数看，check_out的UTC时间比check_in晚约8小时，不存在时间先后逻辑矛盾。

核心产生原因 #

• 时区转换逻辑重复执行
  上报的时间为不带时区标识的naive时间字符串时，Odoo会根据接口调用上下文的用户时区配置，自动将传入时间做一次转UTC的偏移处理后存入数据库。如果传入的本身已经是UTC时间，这步转换会导致数据库中存储的check_in时间比实际值偏移数个小时，一旦偏移后的check_in时间晚于传入的check_out时间，就会触发报错。前端显示时会再做一次反向时区转换，刚好能显示出看似正确的本地时间，迷惑性较强。
• 签到记录字段未正确传入
  上报check_in时如果字段名拼写错误、参数层级不对，导致check_in字段值没有被Odoo识别，系统会自动取接口调用时刻的服务器UTC时间作为check_in值存入数据库。如果这个自动填充的时间晚于后续上报的check_out时间，就会触发校验错误。
• 签退匹配到错误的考勤记录
  上报check_out时如果直接调用create方法新建记录，没有指定关联的未签退考勤ID，或者传入的employee_id和签到时不一致，系统会自动匹配该员工（甚至其他员工）历史遗留的未签退考勤记录做时间校验，如果那条记录的check_in时间晚于当前传入的check_out时间，就会报错。
• 时间参数序列化异常
  XML-RPC传输过程中如果时间格式不符合要求，比如日期、时分秒位错位、解析失败，会导致Odoo拿到的check_out时间比实际值早，触发校验。

排查与解决步骤 #

• 核查数据库存储的真实签到时间
  直接查询hr_attendance表中对应用户的最新未签退记录，查看check_in字段存储的UTC时间实际值：
  • 如果存储值和上报的check_in时间不一致，优先排查时区转换问题：所有上报的时间参数统一带UTC时区标识，格式为YYYY-MM-DD HH:MM:SS+00:00，避免Odoo对已有的UTC时间重复做偏移转换；也可以在XML-RPC调用的上下文参数中显式指定时区为UTC，强制时区处理逻辑走UTC标准。
  • 如果存储值和上报的check_in时间完全不符，接近调用签到接口的服务器时间，说明check_in字段没有被正确传入，检查参数字段名拼写、参数格式，确保check_in字段能被Odoo ORM正确识别。
• 调整签退上报逻辑
  不要直接调用create方法生成签退记录，上报check_out前先通过接口查询指定员工最新一条check_in非空、check_out为空的考勤记录ID，调用write方法针对这条特定记录更新check_out字段值，从根源上避免匹配到错误的历史记录。如果查询时发现存在历史脏数据（比如之前测试生成的、时间异常的未签退记录），先清理脏数据再上报。
• 校验传参格式
  上报前打印序列化后的完整请求参数，确认时间字段值没有出现位错、格式错误，确保传入的时间字符串符合Odoo的datetime字段格式要求。
• 快速验证方法
  开启Odoo开发者模式，在后台考勤菜单中找到对应员工的那条签到记录，手动填入要上报的check_out时间，如果手动保存也报相同错误，直接查看这条记录的check_in字段真实存储值，就能快速定位异常点。

内容的提问来源于stack exchange，提问作者Aric Fedida