Daily updates from Odoo
Friday, December 13, 2024
5 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where bank statement imports were not accurately capturing debited charges. Now, the system correctly includes these charges in the imported transaction amounts, ensuring more precise financial reporting. This improves the reliability of bank statement data within the Enterprise system.
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
This update resolves a stability issue in the consolidated balance report. Previously, an empty totals list could cause a crash. The fix ensures that the report only attempts to modify data when totals are present, preventing errors and improving reliability.
Original PR description
**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722
This update resolves an issue where the system incorrectly attempted to raise an error message when a bank account lacked a client code. The fix corrects a coding error that was passing multiple arguments to the `append` function, ensuring proper error handling and preventing the system from crashing.
Original PR description
An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n_jp_zengin/models/account_batch_payment.py#L77 Sentry-6128197646
This update fixes a bug where shift times were incorrectly displayed in the Gantt view for employees with multiple shifts. The change streamlines the calculation process by directly using the `_work_intervals_batch` method, ensuring accurate shift hour assignments. This prevents shifts from being shown with incorrect start and end times.
Original PR description
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default…
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what is miscalculation - When click on cell 9-10 the calculated hours <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table> so that slot timining will be 8 - 12 - When click on cell 11-12 <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table> So that the slot timining will be 13-12 which should not be possible Fix: - We previously relied on the ```_adjust_to_calendar``` method to calculate the resource's working hours. However since the working hour intervals are already computed using ```_work_intervals_batch```, we are removing the method call to reduce code duplication. Calculate the working hours using ```_work_intervals_batch``` and return the appropriate work intervals based on the resource's working calendar. task-3916687 Forward-Port-Of: odoo/enterprise#64961
This update allows users in Uruguay to create invoices with 100% discount lines, resolving a previous validation error with the tax authority (DGI). The changes include adapting the XML format to correctly handle zero-value lines and avoiding currency calculation errors when dealing with foreign currencies.
Original PR description
Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI . > ERROR: CODE 31: Error: El contenido…
Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI . > ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'. In order to make it work we need to adapt the module to accept this kind of lines that actually represent an "Entrega Gratuita" (Indicator 5 in Uruguay) - We check if the line is a 100% discount, if it is then we marked as Entrega Gratuita when we are creating XML (Indicator 5) - Now that we can have lines and also invoices with total value 0.0 we need to adapt our XML because if value 0.0 then some tags were not added to the final XML - it was interpreted as False and the result was and invalid XML becasue we were missing a mandatory tag. Now we can tags that have 0.0 value to the final XML. - Now that we can have lines 0.0 total amount, and also invoices 0.0 total amount, if we are using foreign currency then we need to avoid error computing the currency rate (division by zero). Now we detect this cases and use the date rate. Also, the rate is only been computed when actually we are going to use it. LATAM 1296 / ADHOC Ticket 83295