om_account_asset: Assets are created each time a Vendor Bill goes through the process Confirm/Reset to Draft/Confirm
Closed this issue · 7 comments
Bug Description
If you add an Asset Type to a product and then Confirm a Vendor Bill the system is designed to create an asset for you. If the Vendor Bill is then "Reset to Draft" and then Confirmed, another asset will be created. This is especially an issue if the user has enabled the Asset Type option "Auto-Confirm Assets" because the assets will be created in Running state and the cron job will post the depreciation lines as designed.
I've only tested this on v14 but reviewing the code there's no reason to suspect that the issue won't exist in all versions.
Steps to Reproduce
- Install the Purchase module.
- Create an Asset Type (either enable/disable the option "Auto-Confirm Assets".)
- Create a Product in the Purchase module with the Asset Type set on the Accounting tab.
- Create and confirm a Purchase Order for the product.
- Create a Vendor Bill from the Purchase Order and Confirm it. An Asset will be created as designed (it will be in Running state if Auto-Confirm Assets was enabled in the Asset Type definition.)
- On the Vendor Bill, click Reset to Draft.
- Confirm the Vendor Bill again. Another Asset will be created (again, it will be in Running state if Auto-Confirm Assets was enabled in the Asset Type definition.)
In om_account_asset/models/account_move.py
we can override move_id's button_draft method to look for assets created by the move and then unlink them (see code below). But the asset.unlink method will only allow an asset to be deleted if the asset is in 'draft' state. It's possible that some or all of the assets created by the move are not in 'draft' state.
My question is: what should the business logic be? As written below, if any of the assets created by the invoice or bill have a state != 'draft', the following would result:
- none of the assets would be deleted (even the ones that are in 'draft' state),
- a UserError is raised such that the invoice or bill would not actually be changed to the draft state.
It would then be up to the user to address the situation as best they can. I'm not sure this is the best solution though. Other business logic options are:
- Instead of trying to unlink the assets, we merely inform the user that there exists assets that were created by the move that they just deleted.
- We delete any assets that are in 'draft' state and inform the user that there were other assets that could not be handled.
- We disallow setting an invoice/bill back to draft (I'm not a fan of this option).
Thoughts? Thank you,
Ken
om_account_asset/models/account_move.py
def button_draft(self):
# we want to do the native button_draft function steps first to give it a chance to error-out before our steps
res = super(AccountMove, self).button_draft()
for move in self:
if move.state == 'draft':
# the invoice was successfully set to draft state, therefore delete assets created by this move
move_assets = self.env["account.asset.asset"].search([("invoice_id", "=", move.id)])
move_assets.unlink()
return True
Thanks for reporting the issues, we will look at the issues and will get back to you.
How about keeping the assets as inactive instead of deleting them ? Upon checking v11, seems instead of deleting, records are set to active False.
def button_draft(self):
res = super(AccountMove, self).button_draft()
for move in self:
if move.state == 'draft':
self.env['account.asset.asset'].search(
[('invoice_id', 'in', self.ids)]).write({'active': False})
return res
Your thoughts ? @kwoychesko
I think setting active to False is a better idea than deleting the asset--great idea! We could even add a message to the chatter about why.
Unfortunately we still have the problem of duplicate assets being created if any of the assets were already approved.
one more enhancement is added related to this, validation error will be shown now upon resetting the invoice when there is a asset in non drafted state.
See: a7531b7
Looks great! Thanks!