Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FW][FIX] stock_account,purchase_stock: compensate return of fifo product #162685

Conversation

fw-bot
Copy link
Contributor

@fw-bot fw-bot commented Apr 19, 2024

The value of the returned product may be different from the one
initially received. In such case, the stock accounting may be broken.

To reproduce the issue:
(Need account_accountant)

  1. Create an auto-FIFO product category
  2. Create a storable product
  3. Confirm a PO with 1 @ 10
  4. Receive it
  5. Confirm a PO with 4 @ 25
  6. Receive 1 with backorder
  7. Return it
  8. On the backorder, receive 4
  9. Bill

Error: Looking at the AML of the stock-in account, some lines are
not reconciled and there is a $15 difference between the totald debit
and the total credit.

Step 7, when returning the product, we actually return the one at
$10. Step 8, we then receive 4 products at $25 (hence the difference
of $15). So, back to step 7, when returning the product, we should
also compensate the stock-in account (with the expense one) in case
of a difference.

Let's look at another case: after step 7, the user "returns the
return". In such case, the value of the new receipt is based on the
returned one (see [1]), i.e.: the value of the newly received
product will be $10. In such case, we also need to (1) compensate
the stock-in account and (2) prevent the pdiff process to generate a
pdiff of $15 (otherwise, we would add a value to the received
product, which would go against the logic of [1]).

This commit does not address the behaviour difference between the
two above use cases (-> depending on how the user receives again the
returned product, its value is not the same). This would probably
need a deeper analysis a change, on master.

Note: a third use case does not work either: (step 1-4), PO 1 @ 25,
receive, bill, return, refund.

[1]
https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40
Initially added by 200aac5

OWP-3698324

Forward-Port-Of: #162368

The value of the returned product may be different from the one
initially received. In such case, the stock accounting may be broken.

To reproduce the issue:
(Need account_accountant)
1. Create an auto-FIFO product category
2. Create a storable product
3. Confirm a PO with 1 @ 10
4. Receive it
5. Confirm a PO with 4 @ 25
6. Receive 1 with backorder
7. Return it
8. On the backorder, receive 4
9. Bill

Error: Looking at the AML of the stock-in account, some lines are
not reconciled and there is a $15 difference between the totald debit
and the total credit.

Step 7, when returning the product, we actually return the one at
$10. Step 8, we then receive 4 products at $25 (hence the difference
of $15). So, back to step 7, when returning the product, we should
also compensate the stock-in account (with the expense one) in case
of a difference.

Let's look at another case: after step 7, the user "returns the
return". In such case, the value of the new receipt is based on the
returned one (see [1]), i.e.: the value of the newly received
product will be $10. In such case, we also need to (1) compensate
the stock-in account and (2) prevent the pdiff process to generate a
pdiff of $15 (otherwise, we would add a value to the received
product, which would go against the logic of [1]).

This commit does not address the behaviour difference between the
two above use cases (-> depending on how the user receives again the
returned product, its value is not the same). This would probably
need a deeper analysis a change, on master.

Note: a third use case does not work either: (step 1-4), PO 1 @ 25,
receive, bill, return, refund.

[1]
https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40
Initially added by 200aac5

OWP-3698324

X-original-commit: 55658e7
@robodoo
Copy link
Contributor

robodoo commented Apr 19, 2024

Pull request status dashboard.

@fw-bot
Copy link
Contributor Author

fw-bot commented Apr 19, 2024

This PR targets saas-16.4 and is part of the forward-port chain. Further PRs will be created up to master.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

@robodoo robodoo added the forwardport This PR was created by @fw-bot label Apr 19, 2024
@C3POdoo C3POdoo added the OE the report is linked to a support ticket (opw-...) label Apr 19, 2024
@fw-bot
Copy link
Contributor Author

fw-bot commented Apr 19, 2024

@adwid @Whenrow the next pull request (#162697) is in conflict. You can merge the chain up to here by saying

@fw-bot r+

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

@adwid
Copy link
Contributor

adwid commented Apr 22, 2024

robodoo r+

robodoo pushed a commit that referenced this pull request Apr 22, 2024
The value of the returned product may be different from the one
initially received. In such case, the stock accounting may be broken.

To reproduce the issue:
(Need account_accountant)
1. Create an auto-FIFO product category
2. Create a storable product
3. Confirm a PO with 1 @ 10
4. Receive it
5. Confirm a PO with 4 @ 25
6. Receive 1 with backorder
7. Return it
8. On the backorder, receive 4
9. Bill

Error: Looking at the AML of the stock-in account, some lines are
not reconciled and there is a $15 difference between the totald debit
and the total credit.

Step 7, when returning the product, we actually return the one at
$10. Step 8, we then receive 4 products at $25 (hence the difference
of $15). So, back to step 7, when returning the product, we should
also compensate the stock-in account (with the expense one) in case
of a difference.

Let's look at another case: after step 7, the user "returns the
return". In such case, the value of the new receipt is based on the
returned one (see [1]), i.e.: the value of the newly received
product will be $10. In such case, we also need to (1) compensate
the stock-in account and (2) prevent the pdiff process to generate a
pdiff of $15 (otherwise, we would add a value to the received
product, which would go against the logic of [1]).

This commit does not address the behaviour difference between the
two above use cases (-> depending on how the user receives again the
returned product, its value is not the same). This would probably
need a deeper analysis a change, on master.

Note: a third use case does not work either: (step 1-4), PO 1 @ 25,
receive, bill, return, refund.

[1]
https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40
Initially added by 200aac5

OWP-3698324

closes #162685

X-original-commit: 55658e7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
@robodoo robodoo closed this Apr 22, 2024
@fw-bot fw-bot deleted the saas-16.4-16.0-OPW-3698324-purchase_stock_fifo_return_and_valo-awt-HWmV-fw branch May 6, 2024 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
forwardport This PR was created by @fw-bot OE the report is linked to a support ticket (opw-...)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants