Saturday, October 19, 2024
1 change · master
Miscellaneous changes
- We used the wrong variable to compute the total of withholding taxes. - The subtotal must not include the local amounts. - According to the SAT, the local vat amounts/rate must be rounded to 2 decimals. - Make the GI be computed as a big invoice instead of being an aggregator of CFDI This is more accurate regarding the purpose of the global invoice. Also, it allows to manage the local taxes on it without copy pasting the whole code in both the invoice itself and the aggregator for the
Original PR description
- We used the wrong variable to compute the total of withholding taxes. - The subtotal must not include the local amounts. - According to the SAT, the local vat amounts/rate must be rounded to 2…
- We used the wrong variable to compute the total of withholding taxes. - The subtotal must not include the local amounts. - According to the SAT, the local vat amounts/rate must be rounded to 2 decimals. - Make the GI be computed as a big invoice instead of being an aggregator of CFDI This is more accurate regarding the purpose of the global invoice. Also, it allows to manage the local taxes on it without copy pasting the whole code in both the invoice itself and the aggregator for the global invoice. That way, we also fix a rounding issue when '_round_base_line_tax_details' is called on each invoice separately and not on the whole global invoice. By design, this case is fixed by this commit. - No multi-currency allowed in the global invoice Currently, the GI allows mixing multiple invoice having foreign currencies but we take the first encountered currency as reference. In this case, the whole GI is wrong. Also, it's not well defined how the global invoice is supposed to work in the global invoice and how the rate should be handled in that case. For those reasons, we prevent the user from creating a global invoice if any of the aggregated invoice has a foreign currency. - Improve the dispatching of negative lines. The scope of each aggregated document in the global invoice is well defined now. Each document tries to dispatch its negative lines on the current document first. Then, each refund tries to dispatch its remaining negative lines with the target document refunded by the refund. This way, we no longer needs to define prior documents when dispatching the negative lines. Before this commit, if you fail to dispatch the negative lines on the "prior document" being the refunded document, it should fail. - Fix the dispatching of negative lines when using round globally. The method '_round_base_lines_tax_details' must be called after the dispatching of negative lines. Suppose a line has a delta due to round globally with price included taxes. Then this line is refunded completely by a line without a delta. The current delta is lost and probably should go to another line. task-id: 4261885 Forward-Port-Of: odoo/enterprise#72097