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.

Sign up for GitHub

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

Jump to bottom

Migration to version 17.0 #3298

Open
36 of 47 tasks
OCA-git-bot opened this issue Nov 7, 2023 · 32 comments
Open
36 of 47 tasks

Migration to version 17.0 #3298

OCA-git-bot opened this issue Nov 7, 2023 · 32 comments
Labels
help wanted no stale Use this label to prevent the automated stale action from closing this PR/Issue. work in progress
Milestone
17.0

Comments

@OCA-git-bot
Copy link
Contributor

OCA-git-bot commented Nov 7, 2023 •
edited
Loading

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
@OCA-git-bot OCA-git-bot added help wanted no stale Use this label to prevent the automated stale action from closing this PR/Issue. work in progress labels Nov 7, 2023
@OCA-git-bot OCA-git-bot added this to the 17.0 milestone Nov 7, 2023
@peluko00
Copy link
Contributor

peluko00 commented Nov 20, 2023 •
edited
Loading

I'm going to migrate:

payment_redsys: #3511
l10n_es_partner_mercantil: #3319

This was referenced Nov 20, 2023
Closed
Merged
@javierobcn javierobcn mentioned this issue Nov 27, 2023
Merged
@javierobcn
Copy link
Contributor

Working in l10n_es_partner #3325

@pedrobaeza pedrobaeza pinned this issue Jan 17, 2024
@pedrobaeza pedrobaeza mentioned this issue Jan 17, 2024
Closed
@ramiadavid
Copy link
Contributor

working on l10n_es_aeat #3387

@Tisho99

This comment was marked as outdated.

Sign in to view
@HaraldPanten
Copy link
Contributor

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
Copy link
Contributor

working on l10n_es_aeat_mod347 #3489

@ramiadavid
Copy link
Contributor

working on l10n_es_vat_book #3491

@pedrobaeza
Copy link
Member

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

@HaraldPanten
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

HaraldPanten commented Mar 27, 2024 •
edited
Loading

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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.

@pedrobaeza pedrobaeza mentioned this issue Mar 28, 2024
Closed
@HaraldPanten
Copy link
Contributor

Trabajando en l10n_es_dua

@peluko00 peluko00 mentioned this issue Apr 4, 2024
Merged
@ramiadavid
Copy link
Contributor

@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
Copy link
Member

etobella commented Apr 8, 2024

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

Trabajando en l10n_es_aeat_mod115 y l10n_es_aeat_mod123

@ramiadavid
Copy link
Contributor

Working on l10n_es_facturae #3529

@peluko00
Copy link
Contributor

Migrating:

@peluko00 peluko00 mentioned this issue Apr 23, 2024
Merged
@HaraldPanten
Copy link
Contributor

Trabajando en l10n_es_account_banking_sepa_fsdd . En breve abrimos PR

@HaraldPanten
Copy link
Contributor

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

@miquelalzanillas
Copy link
Contributor

miquelalzanillas commented Apr 25, 2024 •
edited
Loading

Trabajando en l10n_es_aeat_partner_check (#3564)

@mpascuall
Copy link
Contributor

mpascuall commented May 6, 2024 •
edited
Loading

I'm migrating:

@HaraldPanten
Copy link
Contributor

Trabajando en l10n_es_vat_prorate

@HaraldPanten
Copy link
Contributor

Trabajando en l10n_es_aeat_mod303_vat_prorate

@EstebanBlanc

This comment was marked as off-topic.

Sign in to view
@ioans73
Copy link
Member

ioans73 commented Jul 10, 2024

l10n_es_intrastat_report #3663

@mfargnoli
Copy link
Contributor

mfargnoli commented Jul 14, 2024 •
edited
Loading

Soy nuevo por aqui.

Estoy trabajando en l10n_es_igic (#3679)

@manuelregidor
Copy link
Contributor

manuelregidor commented Jul 25, 2024 •
edited
Loading

Trabajando en l10n_es_facturae_face (#3683). Pendiente de dependencia (OCA/edi-framework#60)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted no stale Use this label to prevent the automated stale action from closing this PR/Issue. work in progress
Projects
None yet
Milestone
17.0
Development

No branches or pull requests