Migration to version 17.0

[OCA-git-bot]

Todo

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

Modules to migrate

• l10n_es_account_asset - By @manuelregidor - [17.0][MIG] l10n_es_account_asset: Migration to 17.0 #3542
• l10n_es_account_banking_sepa_fsdd - By @manuelregidor - [17.0][MIG] l10n_es_account _banking_sepa_fsdd: Migration to 17.0 #3566
• l10n_es_account_statement_import_n43 - By @manuelregidor - [17.0][MIG] l10n_es_account_statement_import_n43: migration to 17.0 #3576
• l10n_es_aeat - By @ramiadavid / @pedrobaeza - [17.0][MIG] l10n_es_aeat: Migration to 17.0  #3387
• l10n_es_aeat_mod111 - By @pedrobaeza - [17.0][MIG] l10n_es_aeat_mod111: Migration to version 17.0 #3488
• l10n_es_aeat_mod115 - By @Tisho99 - [17.0][MIG] l10n_es_aeat_mod115: Migration to 17.0 #3541
• l10n_es_aeat_mod123 - By @manuelregidor - [17.0][MIG] l10n_es_aeat_mod123: Migration to version 17.0 #3519
• l10n_es_aeat_mod190
• l10n_es_aeat_mod216
• l10n_es_aeat_mod296
• l10n_es_aeat_mod303 - By @pedrobaeza - [17.0][MIG] l10n_es_aeat_mod303: Migration to version 17.0 #3486
• l10n_es_aeat_mod303_oss
• l10n_es_aeat_mod303_vat_prorate
• l10n_es_aeat_mod347 - By @ramiadavid - [17.0][MIG] l10n_es_aeat_mod347: Migration to version 17.0 #3489
• l10n_es_aeat_mod349 - By @manuelregidor - [17.0][MIG] l10n_es_aeat_mod349: Migration to version 17.0 #3503
• l10n_es_aeat_mod390 - By @pedrobaeza - [17.0][MIG] l10n_es_aeat_mod390: Migration to version 17.0 #3490
• l10n_es_aeat_partner_check - By @miquelalzanillas - [17.0][MIG] l10n_es_aeat_partner_check: Migration to 17.0 #3564
• l10n_es_aeat_sii_oca - By @manuelregidor - [WIP][17.0][MIG] l10n_es_aeat_sii_oca, migration to 17.0 #3504
• l10n_es_aeat_sii_oss
• l10n_es_atc - By @mpascuall - [17.0][MIG] l10n_es_atc: Migration to 17.0 #3578
• l10n_es_dua - By @Tisho99 - [17.0][MIG] l10n_es_dua: Migration to 17.0 #3440 Se incluye en core a partir de V17
• l10n_es_dua_sii
• l10n_es_facturae - By @ramiadavid - [17.0][MIG] l10n_es_facturae: Migration to 17.0 #3529
• l10n_es_facturae_face
• l10n_es_igic
• l10n_es_intrastat_report
• l10n_es_irnr
• l10n_es_irnr_sii
• l10n_es_mis_report - By @mpascuall - [17.0][MIG] l10n_es_mis_report: Migration to 17.0 #3570
• l10n_es_partner - By @javierobcn - [17.0][MIG] l10n_es_partner: Migration to 17.0 #3325
• l10n_es_partner_mercantil - By @peluko00 - [17.0][MIG] l10n_es_partner_mercantil : Migration to 17.0  #3319
• l10n_es_payment_order_confirming_aef
• l10n_es_pos - By @peluko00 - [17.0][MIG] l10n_es_pos: Migration to 17.0  #3548
• l10n_es_pos_sii
• l10n_es_ticketbai
• l10n_es_ticketbai_api
• l10n_es_ticketbai_api_batuz
• l10n_es_ticketbai_batuz
• l10n_es_toponyms - By @pedrobaeza - [17.0][MIG] l10n_es_toponyms: Migration to version 17.0 #3458
• l10n_es_vat_book - By @ramiadavid - [17.0][MIG] l10n_es_vat_book: Migration to version 17.0 #3491
• l10n_es_vat_prorate - By @manuelregidor - [17.0][MIG] l10n_es_vat_prorate: Migration to 17.0 #3583
• payment_redsys - By @peluko00 - [17.0][MIG] payment_redsys: Migration to 17.0  #3511

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

[peluko00]

I'm going to migrate:

payment_redsys: #3511
l10n_es_partner_mercantil: #3319

[javierobcn]

Working in l10n_es_partner #3325

[ramiadavid]

working on l10n_es_aeat #3387

[HaraldPanten]

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 --> #3382

[ramiadavid]

working on l10n_es_aeat_mod347 #3489

[ramiadavid]

working on l10n_es_vat_book #3491

[pedrobaeza]

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

[HaraldPanten]

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.

[pedrobaeza]

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]

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]

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.

[manuelregidor]

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]

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]

Trabajando en l10n_es_dua

[ramiadavid]

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

l10n-spain/l10n_es_facturae/tests/common.py

Lines 23 to 28 in fc2a79f

	# We want to avoid testing on the CommonTest class
	if (
	self.test_class == "CommonTest"
	and self.__module__ == "odoo.addons.l10n_es_facturae.tests.common"
	):
	self.test_tags -= {"at_install"}

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]

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

[ramiadavid]

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]

@etobella
Para que los tests se ejecuten lo que he hecho es eliminar esto:

l10n-spain/l10n_es_facturae/tests/common.py

Lines 21 to 28 in fc2a79f

	def __init__(self, *args, **kwargs):
	super().__init__(*args, **kwargs)
	# We want to avoid testing on the CommonTest class
	if (
	self.test_class == "CommonTest"
	and self.__module__ == "odoo.addons.l10n_es_facturae.tests.common"
	):
	self.test_tags -= {"at_install"}

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]

Trabajando en l10n_es_aeat_mod115 y l10n_es_aeat_mod123

[ramiadavid]

Working on l10n_es_facturae #3529

[peluko00]

Migrating:

• [l10n_es_pos] [17.0][MIG] l10n_es_pos: Migration to 17.0  #3548

[HaraldPanten]

Trabajando en l10n_es_account_banking_sepa_fsdd . En breve abrimos PR

[HaraldPanten]

Trabajando en l10n_es_account_statement_import_n43 a la espera de su dependencia --> OCA/bank-statement-import#649

[miquelalzanillas]

Trabajando en l10n_es_aeat_partner_check (#3564)

[mpascuall]

I'm migrating:

• [l10n_es_mis_report] [17.0][MIG] l10n_es_mis_report: Migration to 17.0 #3570
  -[l10n_es_atc][17.0][MIG] l10n_es_atc: Migration to 17.0 #3578

[HaraldPanten]

Trabajando en l10n_es_vat_prorate

[HaraldPanten]

Trabajando en l10n_es_aeat_mod303_vat_prorate