search

OCA / l10n-spain

Odoo Spain Localization
https://www.aeodoo.org/estado-localizacion
GNU Affero General Public License v3.0
291 stars 520 forks source link

Migration to version 17.0 #3298

Open OCA-git-bot opened 1 year ago

OCA-git-bot commented 1 year ago

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-17.0

Modules to migrate

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

peluko00 commented 1 year ago

I'm going to migrate:

payment_redsys: https://github.com/OCA/l10n-spain/pull/3511 l10n_es_partner_mercantil: https://github.com/OCA/l10n-spain/pull/3319

javierobcn commented 12 months ago

Working in l10n_es_partner #3325

ramiadavid commented 10 months ago

working on l10n_es_aeat #3387

Tisho99 commented 9 months ago

working on l10n_es_dua #3440

HaraldPanten commented 9 months ago

Pongo en contexto los cambios hablados respecto a la desaparición de tax.template y account.account.template que afecta al módulo l10n_es_aeat y a los módulos que dependen de él --> https://github.com/OCA/l10n-spain/issues/3382

ramiadavid commented 8 months ago

working on l10n_es_aeat_mod347 #3489

ramiadavid commented 8 months ago

working on l10n_es_vat_book #3491

pedrobaeza commented 8 months ago

Para el SII, quisiera probar los triggers de Odoo para ver si evitamos la dependencia de queue_job.

HaraldPanten commented 8 months ago

Estamos trabajando en l10n_es_mod349 y nos ha surgido una duda:

@pedrobaeza Recuerdas por qué el mapeo de impuestos del modelo 349 se hace a través de un modelo distinto al del resto de modelos contables? Con el resto de modelos se utilizan l10n.aeat.map.tax y l10n.aeat.map.tax.line. Sin embargo, para el modelo 349 está el modelo específico aeat.349.map.line, que no hereda de ninguno de los otros dos, sino que es distinto. Adjunto captura.

mapeo_impuestos_gen

pedrobaeza commented 8 months ago

Es porque tiene el concepto de clave de operación que de otra forma habría que añadir en el mapeo tradicional, y además lo de "Implica producto físico". Tal vez se podría retrabajar para que cupiera dentro del mapeo tradicional. Dejadme que le dé una vuelta y propongo el PR.

HaraldPanten commented 8 months ago

Es porque tiene el concepto de clave de operación que de otra forma habría que añadir en el mapeo tradicional, y además lo de "Implica producto físico". Tal vez se podría retrabajar para que cupiera dentro del mapeo tradicional. Dejadme que le dé una vuelta y propongo el PR.

Nosotros ya estamos trabajando en ello, si nos comentas la idea podemos adaptarlo. Abrimos PR nosotros en Draft y lo hablamos desde ahí, OK?

pedrobaeza commented 8 months ago

Los cambios serían:

manuelregidor commented 8 months ago

Los cambios serían:

  • En el mapeado de impuestos, cambiar el tipo de field_number de integer a char, para poder admitir casillas tipo 'A', 'E', 'S'...
  • Tener el selection de la clave de operación en el modelo 349, y al añadir los registros, se traslada del número de casilla del mapeado.
  • Establecer manualmente por código qué casillas implican producto físico.

@pedrobaeza Con el cambio de tipo del campo field_number de integer a char hay un problema y es que no se permite el uso de ciertos operadores que actualmente otros modelos se están utilizando. Por ejemplo, en el modelo 303, en la línea 483 del fichero mod303.py aparece lo siguiente: 79 <= map_line.field_number. No habría problema en hacer un cast, pero antes de realizar el cambio de tipo en el módulo l10n_es_aeat con su correspondiente script de migración, habría que realizar cambios también en los módulos de otros modelos contables. ¿De qué manera tendríamos que proceder? ¿Tendría que aparecer todo en el mismo PR con diferentes commits? ¿Vamos haciendo el cambio en el módulo l10n_es_aeat y en los módulos de los modelos específicos teniendo en cuenta el cambio de tipo? Muchas gracias.

pedrobaeza commented 8 months ago

Nada, por todo esto es por lo que se hizo en un mapeo diferente. Creo que es mejor seguir con el mapeo diferenciado entonces que hacer todo ese follón. Otra opción sería añadir la casilla de clave de operación y poner un número de casilla falso, pero creo que también es pervertir un poco el modelo original.

HaraldPanten commented 7 months ago

Trabajando en l10n_es_dua

ramiadavid commented 7 months ago

@etobella Te pregunto a ti porque sales como mantenedor del módulo.

Estoy migrando el módulo l10n_es_facturae pero veo que los tests no se están ejecutando, hay alguna razón para ello?

parece que la causa es esto: https://github.com/OCA/l10n-spain/blob/fc2a79ffe96832030fffed3c3d41b251ba63d12c/l10n_es_facturae/tests/common.py#L23-L28

Si activo los tests (corrigiendo lo necesario para que funcione en v17) no me valida los XML de facturas rectificativas, porque espera un importe en negativo pero se genera en positivo, y ahora me hace dudar si es que los tests no son correctos o si realmente se están generando mal.

Ya que si lo modifico para que se ejecute en v16 también fallan.

¿Tu sabes algo?

etobella commented 7 months ago

La verdad es que es curioso,pk en 15 funciona como debe. Lo reviso en 16 a ver si puedo desentrañar el problema :thinking:

ramiadavid commented 7 months ago

SI hacer que funcionen los test no es complicado, la duda que tengo es si tal como se están generando los XML en las rectificativas es correcto o no, porque según los tests, no, pero me extraña que estén saliendo mal y nadie se haya dado cuenta...

ramiadavid commented 7 months ago

@etobella Para que los tests se ejecuten lo que he hecho es eliminar esto: https://github.com/OCA/l10n-spain/blob/fc2a79ffe96832030fffed3c3d41b251ba63d12c/l10n_es_facturae/tests/common.py#L21-L28

y en los tres tests que hay modificar el import por:

from . import common

class TestL10nEsFacturae(common.CommonTest):

Para que no se importe la clase directamente y así no ejecute los tests en la clase CommonTest Con esto ya se ejecutan bien, luego claro está hay que modificar algunas cosas de los tests para que funcionen en la versión actual

HaraldPanten commented 7 months ago

Trabajando en l10n_es_aeat_mod115 y l10n_es_aeat_mod123

ramiadavid commented 7 months ago

Working on l10n_es_facturae #3529

peluko00 commented 7 months ago

Migrating:

HaraldPanten commented 7 months ago

Trabajando en l10n_es_account_banking_sepa_fsdd . En breve abrimos PR

HaraldPanten commented 7 months ago

Trabajando en l10n_es_account_statement_import_n43 a la espera de su dependencia --> https://github.com/OCA/bank-statement-import/pull/649

miquelalzanillas commented 7 months ago

Trabajando en l10n_es_aeat_partner_check (https://github.com/OCA/l10n-spain/pull/3564)

mpascuall commented 6 months ago

I'm migrating:

HaraldPanten commented 6 months ago

Trabajando en l10n_es_vat_prorate

HaraldPanten commented 6 months ago

Trabajando en l10n_es_aeat_mod303_vat_prorate

EstebanBlanc commented 5 months ago

Can i ask, where i can find the documentation of gls asm api. I want if is that possible implement parcel express service

ioans73 commented 4 months ago

l10n_es_intrastat_report https://github.com/OCA/l10n-spain/pull/3663

mfargnoli commented 4 months ago

Soy nuevo por aqui.

Estoy trabajando en l10n_es_igic (#3679)

manuelregidor commented 4 months ago

Trabajando en l10n_es_facturae_face (https://github.com/OCA/l10n-spain/pull/3683). Pendiente de dependencia (https://github.com/OCA/edi-framework/pull/60)