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][IMP] l10n_es_igic: Added pre-migration script #3867

Open
wants to merge 1 commit into
base: 17.0
Choose a base branch
from

Conversation

Christian-RB
Copy link
Contributor

Script para corregir los impuestos y cuentas, échadle un ojo @etobella @pedrobaeza, lo he probado múltiples veces con una máquina de pruebas y parece funcionar correctamente.

@pedrobaeza pedrobaeza added this to the 17.0 milestone Dec 24, 2024
}


def rename_taxes_xmlids(env, company_id):
Copy link
Member

Choose a reason for hiding this comment

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

La variable contiene un recordset, no un id, por lo que no debe llevar el sufijo _id.

Suggested change
def rename_taxes_xmlids(env, company_id):
def rename_taxes_xmlids(env, company):

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hecho

taxes_to_merge |= tax_id
tax_to_merge_into = env.ref(f"account.{company_id.id}_{taxes[1]}", False)
if len(taxes_to_merge) > 0 and tax_to_merge_into:
openupgrade_merge_records.merge_records(
Copy link
Member

Choose a reason for hiding this comment

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

Antes de hacer esto, hay que fusionar las account.tax.repartition.line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Siguiendo la documentación he optado por mantener el one2many en el impuesto target, evitando así duplicados. He cambiado un poco la lógica, antes fusionaba los impuestos anteriores con uno de los nuevos, ahora fusiono los anteriores con su similar anterior

Copy link
Member

Choose a reason for hiding this comment

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

Ya, pero es que aquí no vale, porque puede haber facturas que tengan enlazadas esas repartition line en el many2one correspondiente, y entonces necesitas que ahora refieran a la repartition line correspondiente del impuesto fusionado. Fíjate que el campo tax_line_id de account.move.line es un campo calculado que depende de tax_repartition_line_id.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Vale ya te entendí, lo reviso

Copy link
Contributor Author

Choose a reason for hiding this comment

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

He añadido lo que comentabas, cambiado las tuplas por arrays para asegurar la iteración correcta y para comparar las repartition_lines he usado (repartition_type,document_type,account_id)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Además he cambiado la forma de ejecutarse a SQL para evitar las restricciones de edición de las facturas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants