出库时的 stock.move.line 是如何确定的
用通俗但不失源码细节的方式，讲清楚 Odoo 出库时 stock.move.line 的生成逻辑：从 stock.move、stock.quant、移除策略到 lot/serial 拆行。
CATEGORY FOCUS
Odoo 开发
聚合 Odoo 开发基础、源码理解、ORM、模型、视图、安全与扩展实践。
311 篇文章
3117 累计阅读
当前排序：专题优先
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
Odoo Fiscal Year Lock 为什么不只是“月末关账”：global/tax/sale/purchase/hard lock 与 lock exception 的层级讲透
很多人把 Odoo 的锁定日期理解成一个总开关，但官方源码其实做了分层：global、tax、sale、purchase、hard lock，再加上可审计的 lock exception。本文把这套设计讲清楚。
Odoo 现金制税为什么不是“付款后才补一笔税”：cash basis tax、partial reconcile 和税务转移账户到底怎么串起来
很多人把 Odoo 的 cash basis tax 理解成“发票不认税、收款时补一张税凭证”，但源码里的设计远比这更精细：它围绕 partial reconcile、付款比例、税务转移账户和多币种汇率共同运作。本文把这条链讲透。
员工离职时，Odoo 为什么不只是“归档一下”：Departure、合同结束、用户账号其实是三条边界
很多团队把离职理解成把员工设成 archive。Odoo 源码却把 departure reason、departure date、contract end、related user archive 分开处理，因为这几个动作在业务上并不等价。
Odoo 发票和付款到底是怎样真正匹配上的：partial reconcile、full reconcile、matching_number 和 payment_state 细节讲透
很多人知道发票和付款会“核销”，但不知道 Odoo 底层到底靠什么对象把两者连起来。本文从 account.partial.reconcile、account.full.reconcile、matching_number 到 payment_state 的回算逻辑，把匹配细节讲透。
Odoo 员工为什么不是“一人一合同一条线”：看懂 hr.version 才看懂员工生命周期
许多用户以为员工档案只是一行记录加一份合同。Odoo 新版 HR 源码其实把员工变化拆成版本时间线，合同只是其中一层，这让调岗、调薪、换排班、未来生效变更都更好处理。
为什么 Odoo 不会在候选人一进流程就创建员工：Applicant 到 Employee 的真正边界
很多人以为招聘流程里把候选人推进几步，系统就应该自动变成员工。Odoo 的源码却把 Applicant 和 Employee 分得很开，这不是多此一举，而是在保护招聘、主数据和权限边界。