[WIP][17.0][MIG] l10n_es_aeat_sii_oca: Migration to v17 #3737
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Se ha modificado el texto de algunas claves de registro para adaptarlos a las actualmente publicadas por la AEAT - Se han añadido las claves de registro correspondientes al primer semestre de 2017 para facturas emitidas y recibidas - Se han eliminado dos claves de registro eliminadas por la AEAT en la versión 0.7 - Se ha cambiado el valor de la variable SII_VERSION a '1.0' - Se han modificado en los parámetros del sistema las URL de los WSDL de SII conforme a los publicados por la AEAT. Son funcionales tanto en entorno de pruebas como de producción. La versión 0.7 es admitida hasta el día 30 de Junio sólo para el entorno de pruebas (en producción debe ser la 1.0), a partir del día 1 de Julio la versión debe ser la 1.0 para ambos entornos. - Se ha eliminado el parámetro del sistema 'l10n_es_aeat_sii.version' ya que no tiene sentido en configuración. La versión está hardcodeada en account_invoice.py y no debe poder ser configurable por el usuario. - Se ha contemplado un nueva opción para el campo <TipoNoExenta> que la AEAT añadió en la versión 0.7, la opción (S3) que debe utilizarse cuando la factura tiene una parte sujeta sin inversión de sujeto pasivo y otra sujeta con inversión de sujeto pasivo. - Se ha añadido control (provisionalmente) en los envíos para evitar que por error un usuario envíe una factura del primer semestre al entorno de producción, comprobándolo por el período de la factura. El formato que ahora se genera no está adaptado para facturas del primer semestre ya que es algo distinto (hay campos que deben tener un valor fijo por defecto, como la descripción que debe ser "Registro del primer semestre" o la CuotaDeducible que debe ser 0). Auque he realziado pruebas de envío contra la de pruebas con clave de registro del primer semestre y no me ha dado error, no se si en producción pasará igual o si, aún no dando el error, la factura estará mal comunicada (no tiene la clave correcta o los valores por defecto exigidos). Por eso de momento (he añadido un TODO) se evita que se envíen si no se está contra el entorno de pruebas. Cuando se adapte el formato de envío y dedidamos cómo abordar el tema de la comunicación de las facturas del primer semestre (wizard o similar) lo podemos quitar o modificar según veamos. - Mejorada lógica de comprobación para en envío de facturas - Corrección de domain para atributo invisible de botones de anulación en formularios de facturas [FIX] l10n_es_aeat_sii: Cálculo descripción SII para factura automático para todo [IMP] l10n_es_aeat_sii: Control de cambio de fecha de factura de proveedor y revisión de traducciones [FIX] l10n_es_aeat_sii: Corrección de fecha programada con metodo en conector 'fixed' La hora a la que se programan los envíos no respetaba el TZ del usuario
* UI adjustments * Field in refund wizard
* Solo se comprueba que tenga VAT en el caso de regimen nacional * En caso de extracomunitarias pero con código de pais ES solo acepta IDType=07 * Mandar 'NO_DISPONIBLE' en caso de que no haya VAT
* Tener en cuenta el caso regimen nacional y partner no Español * Si el país no esta establecido, tener el cuenta los dígitos del VAT * Si no tiene ni pais ni vat devolver vacio
[FIX] l10n_es_aeat_sii: en caso de que no haya descripción no deja guardar
* Cambiado hardcodeado de nombres de posición fiscal a configurable por posición fiscal * Traducciones
* Se redondea la base imponible en el caso de las exentas de clientes * Nunca se cambian a signo negativo los importes si la factira no es rectificativa * [Información del NIF en exportaciones a Canarias
* Filtro de no enviados SII que sólo incluya 2017 * Los trabajos no realizados se eliminan en lugar de pasarlos a estado "Hecho" al reenviar, cancelar, etc. * Permiso de lectura a queue.job para los gestores de la AEAT. * Regla de seguridad para que los gestores de la AEAT sólo vean los trabajos del SII. * Los trabajos se encolan como admin para evitar errores al validar por gente sin permisos del conector. Desafortunadamente, no se puede mantener el usuario original en el trabajo. [IMP] l10n_es_aeat_sii: Share queue.job view for both types of invoices [FIX] l10n_es_aeat_sii: Add jobs with sudo for avoiding permission errors [FIX] l10n_es_aeat_sii: Permissions problem No more need for connector or AEAT permissions [IMP] l10n_es_aeat_sii: Track content sent + better layout for return
[IMP] l10n_es_aeat_sii: Change tax computation to invoice level Odoo v9 already knows which tax generates each invoice tax line, so we get with this: * Avoid to make roundings that are not accurate. * If there are manual changes in supplier invoices taxes, now we will be able to notify them and prevent not matching errors. * Less difficult algorithms for getting tax amount totals.
…ialmente Correcto'
Writing on one cursor some invoice values and on error in another, makes the process to hang due to a lock. Deferring the write to the end and accumulating values prevents this lock. Closes OCA#594
* Se corrige la compañía con la que se crean los trabajos del conector * Se corrige la creación del trabajo de cancelación sii
…ories Refactorización de la obtención del código de país y gestión correcta de los territorios de ultramar franceses.
Envío correcto para el caso de facturas de bienes o ISP emitidas a clientes extranjeros con sucursal permanente en España.
As grouped taxes are unfolded on invoice tax footer, we need to map on SII children taxes (only one of them though), not parent ones
Se añade la posibilidad de indicar las dos caves de registro adicionales.
… sujetos recibidas
…stro contable para el SII (OCA#621) Según la conversación mantenida aquí https://groups.google.com/forum/#!searchin/openerp-spain/sii%7Csort:relevance/openerp-spain/ZM2GlTBI5qw/iOF-FF4YBQAJ , la fecha de registro contable para el SII de las facturas recibidas debe ser la fecha en que se registra la factura en el sistema informático, con independencia de la fecha que se establezca al asiento contable de la misma. Hasta ahora por defecto se establece esta fecha como la fecha del momento del envío (esto es correcto) pero se vuelve a obtener la fecha del momento del envío también para las modificaciones y cancelaciones posteriores, y esto es incorrecto ya que es necesario almacenar la fecha en que se comunica la factura por primera vez para no altararla si hay modificaciones o anulaciones posteriores. Se crea en este PR un campo para almacenar la fecha en que se registra la factura correctamente en el SII por primera vez y se utiliza este dato en los siguientes envíos de la factura al SII. Con esto se independiza completamente la fecha de registro en el SII de la fecha del asiento contable y se asegura además que nunca se comunicará fuera de plazo (8 días ahora, 4 días después) independientemente de la fecha contable que le demos al asiento. Los contables sólo deberán tener en cuenta que deben enviar las facturas que quieran deducirse en un mes antes del día 16 del mes siguiente. He añadido además una migración para establecer el valor del nuevo campo de fecha de registro en el SII a partir del dato 'FechaRegContable' ya comunicado y que se almacena en el último envío al SII de cada factura.
…s enabled In partners, the check is only visible if the company has SII enabled. Before this, the check was done looking to the partner company, but you can leave this field empty (specially in a multi-company environment), and then the result is not correct. Looking to the user company gives us the proper result.
manuelregidor
force-pushed
the
17.0-mig-l10n_es_aeat_sii_oca
branch
from
ef7a702
to
7455920
Compare
|
@pedrobaeza commits añadidos |
|
Incluye por favor #3759, y a ver si esta semana lo puedo revisar ya para fusionarlo. |
manuelregidor
force-pushed
the
17.0-mig-l10n_es_aeat_sii_oca
branch
from
7455920
to
6511e98
Compare
|
@pedrobaeza commit #3759 añadido |
manuelregidor
force-pushed
the
17.0-mig-l10n_es_aeat_sii_oca
branch
from
6511e98
to
69e97db
Compare
Jesarregui
approved these changes
Oct 22, 2024
HaraldPanten
requested changes
Oct 23, 2024
manuelregidor
force-pushed
the
17.0-mig-l10n_es_aeat_sii_oca
branch
2 times, most recently
from
3e5d9c8
to
82c6319
Compare
manuelregidor
force-pushed
the
17.0-mig-l10n_es_aeat_sii_oca
branch
from
82c6319
to
2467f8e
Compare
Jesarregui
approved these changes
Nov 6, 2024
|
@pedrobaeza @etobella @acysos Ya se puede revisar. |
|
@pedrobaeza Necesitaríamos una validación técnica de terceros. ¿Le podéis echar un ojo? Así podemos dejarlo cerrado, o ir trabajando en los cambios sugeridos en caso de que los haya. Gracias! |
|
@etobella tu revisión será también más que bienvenida aquí, ya que tú eres el "trigger master" 😝 |
etobella
reviewed
Nov 21, 2024
| """This post-init-hook will update all existing invoices""" | ||
| env = api.Environment(cr, SUPERUSER_ID, {}) | ||
| # env = api.Environment(cr, SUPERUSER_ID, {}) |
| from odoo import fields, models | ||
|
|
||
|
|
||
| class IrCronTrigger(models.Model): |
|
@etobella Muchas gracias. Le echo un vistazo en cuanto pueda. |
| ) | ||
| invoices_without_triggers = account_moves - invoices_with_triggers | ||
| not_send_without_errors = invoices_without_triggers.filtered( | ||
| lambda a: a.aeat_state == "not_sent" and not a.sii_send_failed |
There was a problem hiding this comment.
@manuelregidor si no me equivoco, el nuevo campo es aeat_send_failed
| not_send_without_errors = invoices_without_triggers.filtered( | ||
| lambda a: a.aeat_state == "not_sent" and not a.sii_send_failed | ||
| ) | ||
| with_errors = invoices_without_triggers.filtered(lambda a: a.sii_send_failed) |
There was a problem hiding this comment.
@manuelregidor idem, aeat_send_failed
|
Tener en cuenta que el método manual sin triggers (anteriormente era el funcionamiento sin queue) se eliminará, también en este refactoring/migración. |
|
¿Podéis añadir los cambios de #3824 antes de la migración? Gracias. |
manuelregidor
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supersedes: #3504
Se ha aprovechado la migración para eliminar la dependencia hacia el módulo queue_job. Ahora, los envíos se envían a través de triggers, una opción base de Odoo.
También se han incluido las funcionalidades del módulo l10n_es_dua_sii (https://github.com/OCA/l10n-spain/tree/16.0/l10n_es_dua_sii), que en v17 ya no será necesario por haber pasado la gestión del DUA al módulo l10n-es.
En este PR queda pendiente por añadir lo siguiente:
Quedará pendiente crear un nuevo campo sii_start_date en res.company, que serviría para que la función _compute_sii_enabled de sii.mixin lo tenga en cuenta para dar valor al campo sii_enabled.
T-5833