-
-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[17.0][MIG] l10n_es_aeat_mod349: Migration to version 17.0 #3503
[17.0][MIG] l10n_es_aeat_mod349: Migration to version 17.0 #3503
Conversation
…c module for aeat models, 347 module was portedto v6.0 and adds new module to print AEAT model 349.
…ueñas mejoras generales (vistas, traducciones, código) y corrección pequeño bug por un olvido en la adaptación de la v5 a la v6
* Only use the first four digits of fiscal year's code to determine fiscal year's number and also give a decent message to the user if it's not a number instead of simply crashing. * Hacer opcional el campo Operation Key en las facturas, permitiendo que esté en blanco. * Ser un poco menos rigurosos con que el año esté en el código del año fiscal. Atención: deberíamos añadir un campo con este valor en lugar de hacer este hack.
* FIX: Corregimos una serie de errores que había en las rectificaciones a la hora de obtener las declaraciones originales, si había alguna que cumplía los requisitos pero sin pertenecer a un modelo. Quizás se solucionara mejor con un on_delete='cascade'. * RFR: Cambio de licencia de GPL3 a AGPL3 en el resto de módulos de localización española, con el consentimiento de todos los autores expresado vía lista de correo del equipo de localización openerp-spain@googlegroups.com
* Only use the first four digits of fiscal year's code to determine fiscal year's number and also give a decent message to the user if it's not a number instead of simply crashing. * Resolve a problem with python isinstance which considers 'False' is an integer and which makes OpenERP create operation_key field as integer instead of char. * Convert a return None to return False, because the XML-RPC protocol doesn't support returning None.
…or: global name 'pooler' is not defined" al iniciar el calculo.
… sólo uno y arrelgar un bug en la generación del modelo cuando el partner tiene el campo title lleno.
…y H que son respectivamente Entregas intracomunitarias con exención de tasas y Entregas intracomunitarias con exención de tasas por un representante fiscal oficial fueron publicadas el 26/11/2011 en el boe. Se puede ver el artículo en: http://planartus.blogspot.es/1309888740/
…ron marcados como no instalables mientras no se compruebe que funcionan o migren, para poder usarlos o probarlos se debería poner el atributo installable de los ficheros __openerp__.py de cada módulo a True
…n os import de objetos de OpenERP, el namespace openerp, refactorizado a PEP-8 y adaptacion vistas a formato 7
…n_es_aeat. * Traducciones. * Vista del wizard BOE * Vistas de facturas mejoradas * Icono * Asignar una clave a las facturas ya existentes.
…49 y l10n_es_payment_order
…turas rectificativas a declarar.
…e o2m [FIX] l10n_es_aeat_mod349: Añadida restricción que impide eliminar facturas que aparezcan en registros de detalle
* IMP: Fiscal position onchange in new API + speed imp + refactoring * FIX: l10n_es_aeat_mod349: Remove check of names There's no need of a check about the name validity, because l10n_es_aeat already transform all the exported strings to valid ASCII characters (though unidecode), so I remove it entirely this check. * FIX: Use first period year in export Relying in fiscal year code for getting the fiscal year is not safe, because you can use that code for defining your journal sequences (for example, with the module account_auto_fy_sequence). We can't use also the year of the fiscal year, because you can have split fiscal years (i. e. like the academic courses). What we uses then is the year of the first period of the declaration, as there's no legal possibility of having mixed periods from different years.
…er calcular el 349 en períodos distintos de los fiscales
class ResCompany(models.Model): | ||
_inherit = "res.company" | ||
|
||
def _get_tax_ids_from_xmlids(self, tax_templates): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sí, esto debe estar en el mapeado de la línea 349 como lo está en el mapeado regular para los otros modelos:
l10n-spain/l10n_es_aeat/models/l10n_es_aeat_map_tax_line.py
Lines 56 to 64 in af67194
def get_taxes_for_company(self, company): | |
"""Obtain the taxes corresponding to this line according the given company.""" | |
self.ensure_one() | |
tax_ids = set() | |
for tax_xmlid in self.tax_xmlid_ids: | |
tax_id = company._get_tax_id_from_xmlid(tax_xmlid.name) | |
if tax_id: | |
tax_ids.add(tax_id) | |
return self.env["account.tax"].browse(list(tax_ids)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@manuelregidor Creo que no se han tenido en cuenta los commits mencionados en la conversación, puedes añadirlos?
Por otra parte, en las facturas de cliente es visible la columna l10n_es_aeat_349_operation_key . Es necesario?
@HaraldPanten Los commits adicionales no se han tenido todavía en cuenta. Con respecto a la visibilidad de la columna l10n_es_aeat_349_operation_key, hay cambios en el commit #3540, que todavía no se ha añadido. |
Parece que las GitHub actions no están arrancando en todo OCA. Pero https://www.githubstatus.com/ no reporta ningún fallo. |
a548794
to
424ca7c
Compare
424ca7c
to
f33e8be
Compare
@HaraldPanten @pedrobaeza @ValentinVinagre Ya están incluidos los 3 PRs que quedaban pendientes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revisión funcional OK.
Probado que los errores añadidos aquí #3331 también sean visibles en la nueva versión.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ocabot merge nobump
This PR looks fantastic, let's merge it! |
Congratulations, your PR was merged at 32f3906. Thanks a lot for contributing to OCA. ❤️ |
…ubl_cii Related to OCA#3503 The peppol_eas field exists only if account_edi_ubl_cii is installed, if we don't have this module installed (because we don't have it in the scaffolding) the test should not fail.
No description provided.