[19.0][MIG] l10n_es_aeat_sii_oca - #4956
Conversation
81840f9 to
8243950
Compare
|
/ocabot migration l10n_es_aeat_sii_oca |
f2e4526 to
31055e4
Compare
ArantxaSudon
left a comment
There was a problem hiding this comment.
Revisión Funcional
Activando en la compañía el SII y rellenando las claves de las posiciones fiscales, se rellenan correctamente en las facturas y se envían al SII
@moduon MT-14051
Shide
left a comment
There was a problem hiding this comment.
Revisión de código.
Super buen trabajo.
Solo unas cuantas dudas y otras sugerencias no bloqueantes
These were not working since odoo/odoo@5b61898a, so this fixes this. Translation: l10n-spain-12.0/l10n-spain-12.0-l10n_es_aeat_sii Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-12-0/l10n-spain-12-0-l10n_es_aeat_sii/
Translation: l10n-spain-12.0/l10n-spain-12.0-l10n_es_aeat_sii Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-12-0/l10n-spain-12-0-l10n_es_aeat_sii/
Previous method was comparing 2 strings for equality, but coming from dictionaries, the generated strings may be different, as the order is not guaranteed in <= Python 3.5. We can use Python dictionary comparison instead for accurated results. The method name has also been changed for reflecting the real semantics of it. TT25025
Since odoo/odoo#34044, VAT not subject for goods was not included in any SII taxes map, which provokes that any vendor bill of this type is not correctly sent.
If there's an accounting date, taxes amounts in company currency are not properly computed. The method has been refactored as well for using the modern `_convert` method.
You can have default invoice type expressed in the context key `default_type`, so we have to check that as well.
…rteCompensacionREAGYP
This refactoring is made for reducing code and do it even more readable, but esentially for a later improvement that will come for grouping taxes with same percentage.
If not merged, we may rebase the limit of 6 maximum blocks of this type. This can happen when using several types of VAT taxes (goods/services) in the same invoice, or not deductible VAT with different analytic accounts. TT25683
Don't assign a fixed refund specific type for avoiding problems in refunds of simplified invoices
…s de proveedor - Añadido aeat.sii.map.lines para NotIncludedInTotal - facturas emitidas irpf
- Don't process again everything, but do it inline on existing methods - Make tests resilient
- Redo the tax computation for efficiency and reliability - Add test suite for checking obtained JSON for different tax configurations - SII description computation reworked for new computed writable - Added migration scripts
For avoiding collapse on Odoo Apps Store.
On taxes with no amount ("IVA soportado exento" for example), the key `amount` is not
filled, provoking a problem sending it to SII.
We avoid it initializing full expected dictionary structure on first occurrence.
This commit also contains a little fix for avoiding the crash of `merge_dict` method
not having "TipoImpositivo" key in the dictionaries.
After not doing breakdown, a problem has been discovered if there are 2 taxes of the same percentage, like 21% services and 21% goods. For solving it, we move the `_merge_tax_dict` auxiliar method to the mixin, and using it for the out taxes dictionary generation. It includes an extra JSON file for tests for exercizing the problem.
If a line with the ISP tax comes before one with non ISP tax, the dictionary is sent with S2 instead of S3. That's because the switch to S3 was only performed in one place, assuming that the ISP tax will come second. Now it's checked in both places. This includes a little refactor for better readability.
If not, the error is reraised, and the SII sending in batch is aborted, so the rest of the invoices are not ever send meanwhile. Looking for the roots of this code, it was introduced when extracting the SII mixin: OCA@4e2dee2 but not related to it, and the comment of the justification doesn't seem correct. This raise was previously captured by the second existing try, that was provoking another problem and removed in OCA#4807. As now the dict may not exist, we adapt the exception save to that condition. TT61482
En este PR se añaden las siguientes mejoras:
* Si la factura está en error, al enviarla de nuevo se crea como envío
inmediato.
* Esto sobretodo es para evitar que lleguemos al límite de tiempo si
la corrección se realiza más tarde y tenemos retardo de días.
* El check de error ahora es readonly.
* Esto solo debería ser modificado desde el código.
* Muestreo en el dashboard de los diarios si existen facturas con error
con enlace directo.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: l10n-spain-18.0/l10n-spain-18.0-l10n_es_aeat_sii_oca Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-18-0/l10n-spain-18-0-l10n_es_aeat_sii_oca/
…Inversion values When a supplier invoice has multiple tax lines with the same tax rate (TipoImpositivo) but some are investment goods (BienInversion=S) and others are not, they should NOT be merged into a single SII entry. This fixes the bug where all tax lines were incorrectly marked as investment goods when the first tax line had BienInversion=S. MT-14523 @moduon
31055e4 to
b7b21f7
Compare
|
Hola @OCA/local-spain-maintainers ! ¿Necesitáis algo más para proceder al merge de este PR? Muchas gracias! Saludos |
|
@rafaelbn Si podéis conseguir alguna review más de otros contribuidores, de otras empresas, eso ayudará seguro 💪. |
marcosSaucedoQubiq
left a comment
There was a problem hiding this comment.
He probado los cambios incluidos en la migración realizando validaciones funcionales sobre los principales flujos del módulo. LGTM. ✅
pedrobaeza
left a comment
There was a problem hiding this comment.
Hay un cambio de un string sin la correspondiente traducción, pero la hacemos ya en Weblate, y luego todo el tema de la causa de exención es algo que viene vinculado al impuesto, y podemos entonces desgajarlo de producto y posición fiscal, pero eso lo hago en un PR posterior. Vamos a fusionar.
Gracias por el trabajo, y toda la conversión de dominios, que ha tenido que dar guerra.
/ocabot merge nobump
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at 8f8f38a. Thanks a lot for contributing to OCA. ❤️ |
MT-14051 @moduon