[18.0][FIX] l10n_it_edi_related_document: sync with standard fields

[TheMule71]

Alcuni moduli potrebbero assegnare i campi standard

    l10n_it_origin_document_type
    l10n_it_origin_document_name
    l10n_it_origin_document_date
    l10n_it_cig
    l10n_it_cup

e con l'approccio attuale verrebbero semplicemente ignorati.

[TheMule71]

PR per discutere della soluzione. Al momento questo blocca #5030, che prova a fare una fattura ed esportarla usando il metodo normale di odoo.

Questa PR supporta il caso in cui un modulo, programmaticamente, aggiunga l'ordine alla fattura come documento collegato, usando i campi standard - senza dipendere da questo modulo e senza usarne il modello apposito.

Invece di ignorare il documento, se ne crea (o aggiorna) uno se necessario.

Da discutere cosa usare come chiave di ricerca... e cosa fare se uno cambia nome al documento... al momento si lascia in giro il vecchio nome e si crea un nuovo documento.

[monen17]

PR per discutere della soluzione. Al momento questo blocca #5030, che prova a fare una fattura ed esportarla usando il metodo normale di odoo.

Questa PR supporta il caso in cui un modulo, programmaticamente, aggiunga l'ordine alla fattura come documento collegato, usando i campi standard - senza dipendere da questo modulo e senza usarne il modello apposito.

Invece di ignorare il documento, se ne crea (o aggiorna) uno se necessario.

Da discutere cosa usare come chiave di ricerca... e cosa fare se uno cambia nome al documento... al momento si lascia in giro il vecchio nome e si crea un nuovo documento.

Ok, il problema in pratica è che il modulo l10n_it_edi_related_document ignora completamente i campi del core e addirittura non li fa arrivare al template della FE, così se uno li ha valorizzati e ha installato questo modulo, poi non si ritrova il nodo corrispondente (tipo DatiOrdineAcquisto) nella FE.
Insomma, dovrebbe comportarsi un po' meglio rispetto al codice del core 🤗

Per risolvere vorresti che questo modulo l10n_it_edi_related_document mantenesse un documento collegato sincronizzato con i campi del core dichiarati in fattura.
Come idea per me va bene 👍

Aggiungerei però la gestione anche della modifica inversa: quando l'utente aggiorna i campi di questo documento speciale, vengono sincronizzati i campi nella fattura.
Magari si potrebbero aggiungere i metodi compute e inverse ai campi della fattura per far sì che si sincronizzino con i campi del documento collegato? Potrebbero semplificare la sincronizzazione ed evitarci l'override di create e write.

Va anche gestito il caso in cui esiste già una fattura con i campi valorizzati, e poi viene installato questo modulo: in questo caso servirebbe una migrazione che crea il nuovo documento collegato.

Per identificare questo documento collegato speciale si potrebbe creare un Many2one che dalla fattura punta al documento (sarebbe comunque uno dei related_document_ids).

[TheMule71]

Aggiungerei però la gestione anche della modifica inversa: quando l'utente aggiorna i campi di questo documento speciale, vengono sincronizzati i campi nella fattura. Magari si potrebbero aggiungere i metodi compute e inverse ai campi della fattura per far sì che si sincronizzino con i campi del documento collegato? Potrebbero semplificare la sincronizzazione ed evitarci l'override di create e write.

Considera che con il nostro modulo installato quei campi dovrebbero essere completamente invisibili, e inacessibili.

Il dubbio al massimo è se un modolo terze parti dovesse leggere quei campi aspettandosi qualcosa.

Va anche gestito il caso in cui esiste già una fattura con i campi valorizzati, e poi viene installato questo modulo: in questo caso servirebbe una migrazione che crea il nuovo documento collegato.

Per identificare questo documento collegato speciale si potrebbe creare un Many2one che dalla fattura punta al documento (sarebbe comunque uno dei related_document_ids).

Questa potrebbe essere una buona idea (comunque).

[monen17]

Aggiungerei però la gestione anche della modifica inversa: quando l'utente aggiorna i campi di questo documento speciale, vengono sincronizzati i campi nella fattura. Magari si potrebbero aggiungere i metodi compute e inverse ai campi della fattura per far sì che si sincronizzino con i campi del documento collegato? Potrebbero semplificare la sincronizzazione ed evitarci l'override di create e write.

Considera che con il nostro modulo installato quei campi dovrebbero essere completamente invisibili, e inacessibili.

Il dubbio al massimo è se un modolo terze parti dovesse leggere quei campi aspettandosi qualcosa.

Oppure quando l10n_it_edi_related_document viene disinstallato: io mi aspetterei che i dati del documento collegato speciale siano nei campi corrispondenti della fattura.
A me dà l'impressione che se teniamo i campi sincronizzati in entrambi i sensi il sistema sia più solido, ma magari è solo una mia impressione 🤷

[TheMule71]

Aggiungerei però la gestione anche della modifica inversa: quando l'utente aggiorna i campi di questo documento speciale, vengono sincronizzati i campi nella fattura. Magari si potrebbero aggiungere i metodi compute e inverse ai campi della fattura per far sì che si sincronizzino con i campi del documento collegato? Potrebbero semplificare la sincronizzazione ed evitarci l'override di create e write.

Considera che con il nostro modulo installato quei campi dovrebbero essere completamente invisibili, e inacessibili.
Il dubbio al massimo è se un modolo terze parti dovesse leggere quei campi aspettandosi qualcosa.

Oppure quando l10n_it_edi_related_document viene disinstallato: io mi aspetterei che i dati del documento collegato speciale siano nei campi corrispondenti della fattura. A me dà l'impressione che se teniamo i campi sincronizzati in entrambi i sensi il sistema sia più solido, ma magari è solo una mia impressione 🤷

Ottimo, proviamo così.

[micheledic]

@OCA/local-italy-developers si può mergiare ?

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[sergiocorato]

/ocabot merge minor

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 18.0-ocabot-merge-pr-5046-by-sergiocorato-bump-minor, awaiting test results.

[OCA-git-bot]

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