[17.0][MIG] l10n_es_atc_mod420: Migration to 17.0

[Christian-RB]

No description provided.

[Christian-RB]

No consigo replicar el error en los tests cuando los ejecuto en local, pareciera que el código en

l10n-spain/l10n_es_igic/models/template_es_canary.py

Lines 34 to 54 in 661ede8

	@template("es_common", "account.tax")
	def _get_es_common_force_account_tax(self):
	tax_data = self._parse_csv("es_common", "account.tax", module="l10n_es")
	self._deref_account_tags("es_full", tax_data)
	return tax_data
	@template("es_common", "account.tax.group")
	def _get_es_common_force_account_tax_group(self):
	return self._parse_csv("es_common", "account.tax.group", module="l10n_es")
	@template("es_common", "account.group")
	def _get_es_common_force_account_group(self):
	return self._parse_csv("es_common", "account.group", module="l10n_es")
	@template("es_common", "account.account")
	def _get_es_common_force_account_account(self):
	return self._parse_csv("es_common", "account.account", module="l10n_es")
	@template("es_common", "account.fiscal.position")
	def _get_es_common_force_account_fiscal_position(self):
	return self._parse_csv("es_common", "account.fiscal.position", module="l10n_es")

No se está ejecutando y está recogiendo los account.tax vacíos de https://github.com/odoo/odoo/blob/17.0/addons/l10n_es_edi_facturae/data/template/account.tax-es_common.csv dando así el error de ERROR: null value in column "name" violates not-null constraint.

Cualquier ayuda es bienvenida

[pedrobaeza]

Christian, me he copiado la consulta SQL de insert y limpiado para ver qué ocurre, y a partir de cierto punto, se añaden un montón de impuestos "falsos" que no tienen los datos adecuados:

Algo está haciendo que se añadan incorrectamente a la hora de crear un plan contable. Para replicarlo en local, tendrías que instalarte poco a poco cada módulo, hasta que te dé el error, y entonces será ese módulo el que lo provoca. ¿Puede que el REAV?

[AinohaBH]

En cuanto a la funcionalidad, todo está correcto: las casillas del modelo mapean adecuadamente los impuestos y, en la comparativa, cada casilla refleja los impuestos correspondientes.
Sin embargo, hay aspectos que resultan poco intuitivos. Por ejemplo, al revisar el "mapeo de impuestos" de los modelos, aparecen los ID de los impuestos en lugar de sus nombres, lo que dificulta la identificación. Para realizar la comparativa y verificar que todo estuviera correcto, tuve que exportar el ID externo junto con la descripción del impuesto. Además, aunque aparecieran los nombres de los impuestos, no serían de gran ayuda, ya que tanto los impuestos de IVA como los de IGIC suelen tener nombres que no facilitan su identificación (adjunto un ejemplo). En cambio, la descripción resulta mucho más útil como identificador.
Quiero señalar que este problema no es exclusivo de este modelo, sino que es un inconveniente generalizado en todos los modelos de España, tanto en IVA e IGIC como también los nombres de lo impuestos de ambos.

[Christian-RB]

Después de mucho rebuscar parece que el test presente en https://github.com/OCA/l10n-spain/blob/17.0/l10n_es_aeat/tests/test_l10n_es_aeat_report.py está bloqueando la actualización del modelo account.chart.template no permitiendo extenderlo con el código en https://github.com/OCA/l10n-spain/blob/17.0/l10n_es_igic/models/template_es_canary.py. Si lo comento para que no se ejecute funciona correctamente.
A primera vista intuyo que tiene algo que ver con cls.loader.backup_registry() pero sigo trabajando en ello.

[Christian-RB]

Finalmente parece que esto está listo para fusionar. Ya que el error no tenía que ver con la funcionalidad en sí, tenemos clientes utilizando este modelo y el que está en #3870 desde principio de año. Te agradecería un último esfuerzo @pedrobaeza para cerrar este tema. Gracias de antemano

[pedrobaeza]

/ocabot migration l10n_es_atc_mod420

[pedrobaeza]

Por qué definir el widget y las options para cada campo en lugar de poner el campo directamente como Monetary y que haga todo automáticamente?

[Christian-RB]

Buena pregunta, en principio se hizo siguiendo como ejemplo otros modelos

l10n-spain/l10n_es_aeat_mod303/views/mod303_view.xml

Lines 200 to 222 in 7818a06

	<field
	name="regularizacion_anual"
	widget="monetary"
	readonly="period_type not in ('4T', '12') or state == 'done'"
	options="{'currency_field': 'currency_id'}"
	/>
	<field
	name="casilla_77"
	widget="monetary"
	options="{'currency_field': 'currency_id'}"
	/>
	<field
	name="casilla_69"
	widget="monetary"
	options="{'currency_field': 'currency_id'}"
	/>
	<field
	name="previous_result"
	widget="monetary"
	readonly="statement_type != 'C' or state == 'done'"
	required="statement_type == 'C'"
	options="{'currency_field': 'currency_id'}"
	/>

, desconozco si hay algún motivo más profundo para haber elegido esta opción

[pedrobaeza]

Pues ninguno fuera del histórico, que antes no existía el campo Monetary y se hizo así inicialmente. Creo que es un buen momento para "modernizar".

[carlos-lopez-tecnativa]

Please add the security rule for multi-company support. Currently, the records are visible across all companies.

[carlos-lopez-tecnativa]

@Christian-RB

[carlos-lopez-tecnativa]

La casilla 23 y 24 no existen dentro del mapeo de impuestos, por lo que esto no se esta calculando bien este valor. Se deberían tomar de los campos que existen en el modelo.

Adicional, este valor se resta en lugar de sumar

Suggested change

	@api.depends("tax_line_ids", "tax_line_ids.amount")
	def _compute_total_devengado(self):
	casillas_devengado = (3, 6, 9, 12, 15, 18, 20, 22, 24)
	for report in self:
	tax_lines = report.tax_line_ids.filtered(
	lambda x: x.field_number in casillas_devengado
	)
	report.total_devengado = sum(tax_lines.mapped("amount"))
	@api.depends("tax_line_ids", "tax_line_ids.amount", "casilla_23", "casilla_24")
	def _compute_total_devengado(self):
	casillas_devengado = (3, 6, 9, 12, 15, 18, 20, 22)
	for report in self:
	tax_lines = report.tax_line_ids.filtered(
	lambda x: x.field_number in casillas_devengado
	)
	report.total_devengado = sum(tax_lines.mapped("amount"))
	if not float_is_zero(report.casilla_23, precision_digits=2):
	report.total_devengado -= report.casilla_24