This repository has been archived by the owner on Feb 26, 2024. It is now read-only.
Bug fixing and code enhancement for 'finalize_invoice_move_lines' function #3
Conversation
This file contains 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
I propose two changements in the method 'finalize_invoice_move_lines': 1) Reinserting the method in its own inheritance path: calling the parent class function (which could modify the value of the variable 'move_lines') and then using the old value of 'move_lines' could cause errors due to data inconsistency; 2) Enhancing the check for what account move line (referencing to the tax) we have to divert: current version works well only for 'out_invoice' account moves (which have correctly the tax amount value on the 'credit' column) not for 'out_refund' account moves (which differently have the tax amount value on the 'debit' column). Actually, trying to validate an 'out_invoice' account move, linked to an 'e_invoice' journal, resolves in an unhandled exception (trying to create an object 'account.move.line' without the required field 'account_id').
Increased code reliability for 'finalize_invoice_move_lines' function. This resolves the following problem: When comparing float number data is possible that the condition 'a == b' doesn't give the attended result, probably due to the underlaying way the programming language and the OS manage float types. Actually it happened to us trying to validate an invoice with amoun_tax = 366.15; In that case, the condition 366.15 == 366.15 returned False.
|
Thank you for your PR, your code is under testing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
I propose the following changes in the method 'finalize_invoice_move_lines':
Reinserting the method in its own inheritance path: calling the parent class function (which could modify the value of the variable 'move_lines') and then using the old value of 'move_lines' could cause errors due to data inconsistency;
Enhancing the check for what account move line (referencing to the tax) we have to divert: current version works well only for 'out_invoice' account moves (which have correctly the tax amount value on the 'credit' column) not for 'out_refund' account moves (which differently have the tax amount value on the 'debit' column). Actually, trying to validate an 'out_invoice' account move, linked to an 'e_invoice' journal, resolves in an unmanaged exception (trying to create an object 'account.move.line' without the required field 'account_id').
Changing the way we compare float numbers. When comparing float number data is possible that the condition 'a == b' doesn't give the attended result, probably due to the underlaying way the programming language and the OS manage float types. Actually it happened to us trying to validate an invoice with amoun_tax = 366.15; In that case, the condition 366.15 == 366.15 returned False.