Saturday, March 23, 2024
4 changes
1 change
Resolved issues and error corrections
This fix allows Brazilian Pix QR codes to be generated even when no payment amount is set. It supports offline point-of-sale use cases where the final amount may not be available when the QR code is created.
Original PR description
Since this commit we support the QR code without amount To be used in the POS when the POS is offline. Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
Corrects planning demo records so their start and end dates are always in the right order. This prevents demo data from failing validation on certain calendar days, making setup and testing more reliable.
Original PR description
In the demo data, we have two records with expressions like ```py start_date = datetime.today() - relativedelta(weeks=2, weekday=4) end_date = datetime.today() - relativedelta(weeks=2, weekday=5) ``` On 2024-03-23 (Saturday), these expressions give the values ```py start_date = datetime.date(2024, 3, 15) end_date = datetime.date(2024, 3, 9) ``` which makes a constraint checking `start_date < end_date` fail. In order to make the computation correct, the solution is to compute end_date like start_date and add an extra day, like in ```py start_date = datetime.today() - relativedelta(weeks=2, weekday=4) end_date = start_date + relativedelta(days=1) ```
2 changes
Resolved issues and error corrections
This fix corrects how withholding taxes are calculated on Colombian electronic invoices. Previously, the system used an inaccurate workaround that could cause invoices to be rejected by tax authorities. The update improves the calculation method to directly compute the VAT amount subject to withholding, ensuring accurate tax reporting and reducing document rejection issues.
Original PR description
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%.…
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected. ### Solution There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. opw-3744872 Forward-Port-Of: odoo/enterprise#58894 Forward-Port-Of: odoo/enterprise#58377
This fix corrects an error in shipping cost calculations when using weight multiplied by volume as the pricing variable. Previously, shipping costs were incorrectly inflating with the square of order quantities because both weight and volume were being multiplied by quantity separately before being multiplied together. The fix ensures accurate pricing by introducing the weight*volume variable at the correct point in the calculation process.
Original PR description
Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step. This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation. In order not to break anything in stable, the new variable is added as a kwarg to the useful methods. OPW-3802315 Forward-Port-Of: odoo/odoo#158899 Forward-Port-Of: odoo/odoo#158767