[17.0][MIG] l10n_es_aeat_mod303: Migration to version 17.0

[pedrobaeza]

Depends on:

• [ ] https://github.com/OCA/l10n-spain/pull/3387

• Standard procedure.

• Converted tax map lines to new format.

• Converted views to new readonly/required/invisible syntax.

• Adapted tests.

@Tecnativa TT48475

[pedrobaeza]

/ocabot migration l10n_es_aeat_mod303

[pedrobaeza]

/ocabot merge nobump

Voy ahora a hacer el 111

[OCA-git-bot]

This PR looks fantastic, let's merge it! Prepared branch 17.0-ocabot-merge-pr-3486-by-pedrobaeza-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 3065350c6f7dca09ead52b914d5f63fe0050143b. Thanks a lot for contributing to OCA. ❤️

[ramiadavid]

@pedrobaeza el archivo l10n.es.aeat.map.tax.line.tax.csv y l10n.es.aeat.map.tax.line.account.csv no sería mas lógico ponerlos en el modulo l10n_es_aeat?

Otros modelos como el 347 también los usa y habría que crearlos de nuevo, haciendo que se dupliquen si los dos módulos están instalados...

[pedrobaeza]

Es algo que he pensado, pero he descartado finalmente por las siguiente razones:

• Exigiría mantener un sitio "central" de esos registros, y si hay alguna actualización de impuestos, tener que tocar en dos módulos (l10n_es_aeat y el módulo de la declaración que cambie).
• Las referencias a los XML-IDs serían mucho más largas, teniendo que construirse como l10n_es.xxxxx, siendo menos legibles y ocupando más.
• Al final, no es ningún overhead añadir de estos registros, y así se da más libertad, incluso de tenerlos repetidos y actuar manualmente. Imagina el caso de que alguien "adelanta" en una BD estos XML-IDs, y luego se incorporan oficialmente en el módulo. En caso de tenerlo centralizado con un constraint unique, habría que borrar previamente el hecho a mano para después actualizar el módulo. En el código ya puse "sets" para evitar duplicidades.