Thursday, October 24, 2024
4 changes · 17.0
Enhancements to existing features
This update improves how users in Argentina are informed about AFIP error 10016 during invoice validation. Instead of a generic error message, users now receive specific guidance based on the actual cause—whether it's a date issue, numbering mismatch, or date range requirements. This helps users quickly resolve validation problems without contacting support.
Original PR description
This pr is created to help de user to know the origin of the afip error 10016. The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The…
This pr is created to help de user to know the origin of the afip error 10016.
The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client.
1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-1': 'The invoice date cannot be after the last invoice validated in AFIP.'
2) If the last afip invoice number is higher than the current invoice number being validated in Odoo, then the message shown to the user is '10016-2': 'There may have been a mismatch in the numbering of this type of document between Odoo and AFIP.'
3) If any other reason cause the error '10016' then the message shown to the user is:
* Please note that if you are trying to validate an invoice with a date other than today, you must verify if it falls within the date range according to the AFIP concept or document type:
a) If it is Product: N+5 or N-5 with N being today's date.
b) If it is Services or Products and services: N+10 or N-10 with N being today's date.
c) If it is a MiPyme Invoice: N-5 0 N+1 with N being today's date. For Debit Note or Credit Note only N-5"
Task Adhoc side: 37771
Task latam side: 1194
This pr replaces https://github.com/odoo/enterprise/pull/65675Resolved issues and error corrections
This update fixes an issue where tax groups weren't correctly reflecting the company associated with a sales order or invoice in Chile. By adding the move company to the context, the system now accurately retrieves the appropriate tax groups, ensuring correct reporting and compliance with Chilean tax regulations. This complements a previous fix and improves data accuracy.
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096
This update resolves an issue where users were blocked from synchronizing their online accounts due to a persistent error status. The solution resets the fetching status automatically when transactions are retrieved or through a new button in the online account list view, ensuring smoother synchronization and uninterrupted access to updated financial data.
Original PR description
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788
This update fixes an issue where Purchase Orders and Sales Orders generated between companies didn't consistently use the expected arrival or commitment dates. Now, the system will accurately reflect the specified delivery dates when creating counterpart orders in the other company, improving order scheduling and fulfillment accuracy.
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72586