Skip to content
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

Merged
merged 115 commits into from
May 15, 2024

Conversation

manuelregidor
Copy link
Contributor

No description provided.

Omar (pexego) and others added 30 commits March 27, 2024 10:12
…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.
…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
l10n_es_aeat_mod349/models/account_move.py Outdated Show resolved Hide resolved
l10n_es_aeat_mod349/models/account_move.py Show resolved Hide resolved
l10n_es_aeat_mod349/models/account_tax.py Outdated Show resolved Hide resolved
class ResCompany(models.Model):
_inherit = "res.company"

def _get_tax_ids_from_xmlids(self, tax_templates):
Copy link
Member

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:

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))

l10n_es_aeat_mod349/security/ir.model.access.csv Outdated Show resolved Hide resolved
@HaraldPanten HaraldPanten self-requested a review April 26, 2024 09:48
Copy link
Contributor

@HaraldPanten HaraldPanten left a 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?

@manuelregidor
Copy link
Contributor Author

@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.

@HaraldPanten
Copy link
Contributor

@manuelregidor

Podemos ir añadiendo, entonces:

#3331 (ya se fusionó)
#3540 (ya se fusionó)

Y quedamos a la espera de #3544 (que también deberemos añadir). A este creo que no le queda mucho, solo que los tests parece que están un poco perezosos, esta mañana...

Gracias.

@pedrobaeza
Copy link
Member

Parece que las GitHub actions no están arrancando en todo OCA. Pero https://www.githubstatus.com/ no reporta ningún fallo.

@manuelregidor
Copy link
Contributor Author

@HaraldPanten @pedrobaeza @ValentinVinagre Ya están incluidos los 3 PRs que quedaban pendientes

Copy link
Contributor

@HaraldPanten HaraldPanten left a 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.

@pedrobaeza

Copy link
Member

@pedrobaeza pedrobaeza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

This PR looks fantastic, let's merge it!
Prepared branch 17.0-ocabot-merge-pr-3503-by-pedrobaeza-bump-nobump, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 28554bc into OCA:17.0 May 15, 2024
7 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 32f3906. Thanks a lot for contributing to OCA. ❤️

@HaraldPanten HaraldPanten deleted the 17.0-mig-l10n_es_aeat_mod349 branch May 15, 2024 11:54
victoralmau added a commit to Tecnativa/l10n-spain that referenced this pull request Oct 3, 2024
…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.
victoralmau added a commit to Tecnativa/l10n-spain that referenced this pull request Oct 4, 2024
victoralmau added a commit to Tecnativa/l10n-spain that referenced this pull request Oct 4, 2024
victoralmau added a commit to Tecnativa/l10n-spain that referenced this pull request Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.