[FIX] stock_account: a zero unit_cost is not a unit cost - #5951
Open
cuongnmtm wants to merge 3 commits into
Open
[FIX] stock_account: a zero unit_cost is not a unit cost#5951cuongnmtm wants to merge 3 commits into
cuongnmtm wants to merge 3 commits into
Conversation
17.0 writes `unit_cost = 0` -- not NULL -- on a valuation layer that adjusts the total value of the stock on hand without a per-unit price: a bill correction, a landed cost, a manual revaluation. The adjustment itself stays in `value`. The zero means "no per-unit price applies", not "this costs nothing". `product_value()` tests `unit_cost IS NOT NULL` to decide whether a layer already knows its unit cost, so those layers take the first branch and are inserted with `value = 0`. The second branch, which would have derived the cost, only looks at `unit_cost IS NULL` and never sees them. Where such a layer is the most recent move-less one for a product, `_get_last_product_value()` returns it and the product's cost becomes 0. That is worse than an obviously wrong cost: a zero reads as a product that has never been costed, it passes review, and every subsequent delivery is priced at nothing. The first branch now takes only a non-zero `unit_cost`, and the second matches `COALESCE(unit_cost, 0) = 0` so it derives the rest. The `quantity = 0` restriction goes with it, because a revaluation booked together with a quantity change carries a total value just the same. The derivation is also guarded to a positive result. Where the accumulated history is itself inconsistent -- 17.0 databases can carry wildly negative revaluation totals -- the division yields a negative "cost", and inserting no row leaves `standard_price` untouched rather than negative. The derived cost has been checked on an upgraded 17.0 database against both the cost 17.0 recorded separately for the product and the COGS 17.0 posted for its deliveries, which agree. Adds a product whose layers reproduce the shape, asserting the cost comes out at 30 (4 bought at 20, plus a 40 revaluation) rather than 0.
OCA-git-bot
added
mod:openupgrade_scripts
hbrunn
requested changes
Aug 28, 2026
Comment on lines
+102
to
+103
| # 17.0 writes unit_cost 0 -- not NULL -- for this kind of adjustment, and the ORM | ||
| # offers no way to ask for that shape, so the layer is inserted directly. |
Member
There was a problem hiding this comment.
if there's no way to create this kind of record via Odoo functions, how are they relevant?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.