IMP spostare l'xsd dello schema di fatturapa in un modulo più generale (ad es. l10n_it_account)

[TheMule71]

Issue nata da questa discussione:

#2606 (comment)

Riassumo brevemente. Ci sono dei moduli (fuori da fatturapa) che codificano modelli con campi che vengono usati poi come valori nella generazione dell'XML. Ad es.:
l10n_it_fiscal_document_type
l10n_it_fiscal_payment_term
l10n_it_rea
(e potenzialmente altri)

Questi moduli caricano tabelle di istanze, coi codici predefiniti. Tuttavia, non impongono particolari controlli sui valori, consentendo all'utente di inserire valori non validi per lo SdI. Per capirci:

l10n-italy/l10n_it_fiscal_document_type/models/fiscal_document_type.py

Line 8 in 4fdb84b

code = fields.Char(string="Code", size=5, required=True)

è il codice da mettere nell'XML e non serve ad altro, ma rimane un campo libero (di 5 caratteri), e se vuole l'utente ci può mettere "pippo".

Spostando l'xsd in un modulo superiore, permetterebbe a questi moduli, volendo, di fare veriche e segnalare valori non validi (da scegliere se come errore, impedendo all'utente di proseguire, o come avvertimento e basta).

Consentirebbe anche di sviluppare test che verifichino che le tabelle caricate da questi moduli contangano valori validi e che non ne manchino.

Ho esplorato il modo (documentato) di estrarre i valori possibili di un tipo direttamente da xsd, e anche un modo (meno documentato) per estrarre le voci descrittive corrispondenti. Ciò ci permetterebbe di generare i dati precaricati con una funzione partendo da quelli validi dell'xsd, con tanto di label (ufficiali) (vd. #2606 (comment))

[TheMule71]

Per fiscal_document_type, si può implementare un controllo a livello di test e va resa non modificabile la tabella:

• 12.0 [IMP] spostare l'xsd dello schema di fatturapa in un modulo più generale (ad es. l10n_it_account) #3531
• 12.0 (controllo test)
• 14.0 [14.0] [IMP] move FPA Schema xsd to l10n_it_account #2820
• 14.0

[SirTakobi]

Per fiscal_document_type, si può implementare un controllo a livello di test e va resa non modificabile la tabella:

• 12.0 [12.0] l10n_it_fiscal_document_type non deve essere possibile creare o modificare i tipi #2819
• 12.0 (controllo test)
• 14.0 [14.0] [IMP] move FPA Schema xsd to l10n_it_account #2820
• 14.0

Le modifiche nella PR #2819 non hanno nulla in comune con quelle fatte in #2820 quindi non credo sia corretto considerarle entrambe un'implementazione di questa problematica.

Separerei quindi le problematiche in:

• questa per tracciare quanto fatto in [14.0] [IMP] move FPA Schema xsd to l10n_it_account #2820
• Non deve essere possibile creare o modificare i tipi di documento fiscale #3532 per tracciare la non modificabilità dei tipi di documento fiscale

[primes2h]

Per fiscal_document_type, si può implementare un controllo a livello di test e va resa non modificabile la tabella:

• 12.0 [12.0] l10n_it_fiscal_document_type non deve essere possibile creare o modificare i tipi #2819
• 12.0 (controllo test)
• 14.0 [14.0] [IMP] move FPA Schema xsd to l10n_it_account #2820
• 14.0

Le modifiche nella PR #2819 non hanno nulla in comune con quelle fatte in #2820 quindi non credo sia corretto considerarle entrambe un'implementazione di questa problematica.

Concordo.

Separerei quindi le problematiche in:

* questa per tracciare quanto fatto in [[14.0] [IMP] move FPA Schema xsd to l10n_it_account #2820](https://github.com/OCA/l10n-italy/pull/2820)

Ho aggiunto la PR corretta per la 12.0 #2654 (comment)

* [Non deve essere possibile creare o modificare i tipi di documento fiscale #3532](https://github.com/OCA/l10n-italy/issues/3532) per tracciare la non modificabilità dei tipi di documento fiscale

Ho aggiunto i riferimenti alle varie PR chiuse in precedenza, in modo da mantenere la cronologia delle operazioni.

[francesco-ooops]

@primes2h per 14/16 c'è qualcosa da fare relativo a questa issue?

[primes2h]

@primes2h per 14/16 c'è qualcosa da fare relativo a questa issue?

La migrazione alla 16.0 mi pare sia iniziata dopo il merge della PR per la 14.0, quindi la 16.0 in teoria dovrebbe essere ok.

Però la problematica di #3532 è parte di questa issue, come indicato in fondo alla descrizione #3532 (comment).

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.