[14.0][FIX] l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2606

TheMule71 · 2022-01-21T16:04:40Z

Fixes #2544
Forward port of #2545

SimoRubi

Puoi modificare il messaggio del commit inglese?
Il co-authored poi non è corretto perché non riconosce il mio utente, infatti il risultato è

ma dovrebbe essere invece:

(da da4dd91)

Guardando il codice, il porting di #2545 mi pare corretto.

Vedo che ci sono anche altre modifiche rispetto a #2545, idealmente sarebbero da fare in una PR separata ma può essere accettabile averle anche solo in un commit separato come hai fatto, puoi però aprire una issue per tenerne traccia? Può essere che siano da riportare anche nelle altre versioni supportate

SimoRubi · 2022-01-28T11:45:07Z

l10n_it_fatturapa_out/models/account.py

@@ -81,6 +89,9 @@ def preventive_checks(self):
                    )
                )

+            if not invoice.partner_id.city:


Sto guardando le specifiche in https://www.agenziaentrate.gov.it/portale/web/guest/specifiche-tecniche-versione-1.7 perché il link nel README a https://www.fatturapa.gov.it/export/fatturazione/it/normativa/f-2.htm risponde 404.
Da quel che ho capito (penso che qui tu stia risolvendo #2563 (comment)), il nodo obbligatorio è Comune, ed è obbligatorio ogni volta che compare nel XML.

Il template però prende il campo city non solo del partner della fattura:

l10n-italy/l10n_it_fatturapa_out/data/invoice_it_template.xml

Lines 464 to 466 in f114377

<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">

<t t-set="partner_id" t-value="partner_id" />

</t>

ma anche del partner della company:

l10n-italy/l10n_it_fatturapa_out/data/invoice_it_template.xml

Lines 331 to 333 in f114377

<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">

<t t-set="partner_id" t-value="company_id.partner_id" />

</t>

e altri, tipo:

l10n-italy/l10n_it_fatturapa_out/data/invoice_it_template.xml

Lines 338 to 343 in f114377

<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">

<t

t-set="partner_id"

t-value="company_id.fatturapa_stabile_organizzazione"

/>

</t>

quindi se vogliamo fare controlli preventivi per non far fallire la generazione del XML, ci sarebbe da controllare il campo city di tutti i partner coinvolti, che ne pensi?

SimoRubi · 2022-01-28T11:50:24Z

l10n_it_fatturapa_out/models/account.py

@@ -55,6 +55,14 @@ def preventive_checks(self):
                    % invoice.name
                )

+            if not invoice.fiscal_document_type_id:


Sto guardando le specifiche in https://www.agenziaentrate.gov.it/portale/web/guest/specifiche-tecniche-versione-1.7 perché il link nel README a https://www.fatturapa.gov.it/export/fatturazione/it/normativa/f-2.htm risponde 404.
Per il nodo TipoDocumento vedo che c'è anche un vincolo di lunghezza a 4 caratteri mentre in

l10n-italy/l10n_it_fiscal_document_type/models/fiscal_document_type.py

Line 8 in fd80fdc

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

il campo è al massimo lungo 5, sai mica come mai?
Visto che con queste modifiche viene aggiunto un controllo dedicato a questo campo, forse sarebbe anche da controllare che la lunghezza sia corretta, che ne pensi?

Direi che va modificato dall'altra parte, in l10n_it_fiscal_document_type. Io il controllo lo potrei mettere, ma se la size diventa 4 di là non serve.

Direi che va modificato dall'altra parte, in l10n_it_fiscal_document_type. Io il controllo lo potrei mettere, ma se la size diventa 4 di là non serve.

Potrebbe essere che esistano dei document type che possono avere lunghezza 5, ma quelli che si possono inserire in una FE devono invece avere lunghezza 4? Anzi, per la FE vedo nel XSD può avere solo certi valori TD01, ..., TD27

Direi che va modificato dall'altra parte, in l10n_it_fiscal_document_type. Io il controllo lo potrei mettere, ma se la size diventa 4 di là non serve.

Potrebbe essere che esistano dei document type che possono avere lunghezza 5, ma quelli che si possono inserire in una FE devono invece avere lunghezza 4? Anzi, per la FE vedo nel XSD può avere solo certi valori TD01, ..., TD27

Dovrebbe essere un campo che serve solo a fatturapa, c'è una tabella che sono i valori dell'XML: https://github.com/OCA/l10n-italy/blob/fd80fdc7d4aeef613e7aa193674cd62cf0bd4f7b/l10n_it_fiscal_document_type/data/fiscal.document.type.csv

Non ho idea del perché sia size=5

Se stiamo controllando i dati della fattura in modo che poi la generazione del XML non esploda, allora andrebbe controllato che il codice del fiscal_document_type_id rientri tra quelli consentiti nel XSD del XML.

Controllare che almeno sia valorizzato il campo fiscal_document_type_id è comunque un miglioramento rispetto al codice esistente perché il nodo TipoDocumento è obbligatorio, quindi per me può andare bene anche così.

SimoRubi · 2022-01-28T11:52:08Z

l10n_it_fatturapa_out/tests/test_fatturapa_xml_validation.py

+        invoice = invoice_form.save()
+        with self.assertRaises(UserError) as ue:
+            self.run_wizard(invoice.id)
+        self.assertIn(invoice.name, ue.exception.args[0])


Puoi chiarire quale dev'essere l'errore sollevato qui e negli assert successivi?
Devono essere errori per i nuovi check sul campo city o fiscal_document, o forse si vuole verificare che salti uno dei check già esistenti?

Adesso faccio il controllo anche sul testo del messaggio (che è autoesplicativo). Dovrebbe cambiare con la localizzazione ma i test in github credo possiamo assumere siano in inglese.

SimoRubi · 2022-01-28T11:56:44Z

l10n_it_fatturapa_out/tests/test_fatturapa_xml_validation.py

+        )
+        invoice = invoice_form.save()
+        with self.assertRaises(UserError) as ue:
+            self.run_wizard(invoice.id)


La fattura non dovrebbe essere confermata prima di generare il file XML?
Strano che il wizard di export permetta di esportare fatture non confermate

Ho aggiunto anche quel controllo.

TheMule71 · 2022-01-28T14:12:09Z

Può essere che siano da riportare anche nelle altre versioni supportate

Nella 12.0 la stessa funzione non è usata.

l10n-italy/l10n_it_fatturapa_out/models/account.py

Lines 51 to 53 in dec31f7

    
           def preventive_checks(self): 
        
               # hook for preventive checks. Override and raise exception, in case 
        
               return

TheMule71 · 2022-01-28T15:38:20Z

Puoi modificare il messaggio del commit inglese?
Il co-authored poi non è corretto perché non riconosce il mio utente,

Fatto e fatto. Per la cronaca, devi lasciare una riga vuota prima del Co-authored-by:.

SimoRubi

Grazie della PR!
Ho fatto revisione del codice, ho messo qualche appunto ma secondo me nel complesso va bene

SimoRubi · 2022-02-09T14:16:00Z

l10n_it_fatturapa_out/models/account.py

+            ):
+                raise UserError(
+                    _(
+                        "Invoice %s city in our company's Stabile Organizzazione must be set",


Suggested change

"Invoice %s city in our company's Stabile Organizzazione must be set",

"Invoice %s city in our company's Stable Organization must be set",

SimoRubi · 2022-02-09T14:17:19Z

l10n_it_fatturapa_out/models/account.py

@@ -81,6 +89,9 @@ def preventive_checks(self):
                    )
                )

+            if not invoice.partner_id.city:


SimoRubi · 2022-02-09T14:24:56Z

l10n_it_fatturapa_out/models/account.py

@@ -55,6 +55,14 @@ def preventive_checks(self):
                    % invoice.name
                )

+            if not invoice.fiscal_document_type_id:


Se stiamo controllando i dati della fattura in modo che poi la generazione del XML non esploda, allora andrebbe controllato che il codice del fiscal_document_type_id rientri tra quelli consentiti nel XSD del XML.

Controllare che almeno sia valorizzato il campo fiscal_document_type_id è comunque un miglioramento rispetto al codice esistente perché il nodo TipoDocumento è obbligatorio, quindi per me può andare bene anche così.

SimoRubi · 2022-02-09T14:26:29Z

l10n_it_fatturapa_out/tests/test_fatturapa_xml_validation.py

+        )
+        invoice = invoice_form.save()
+        with self.assertRaises(UserError) as ue:
+            self.run_wizard(invoice.id)


SimoRubi · 2022-02-09T14:32:18Z

l10n_it_fatturapa_out/tests/test_fatturapa_xml_validation.py

+            "city in our company's Stabile Organizzazione must be set",
+            ue.exception.args[0],
+        )
+        invoice.company_id.fatturapa_stabile_organizzazione.city = city


Si potrebbe aggiungere anche un'esportazione che finalmente va a buon fine (giusto per dare soddisfazione alla CI 😄) una volta che abbiamo fatto tutte le configurazioni corrette

Beh per quello ci sono gli altri test, che lo fanno ripetutamente. Tuttavia, ha senso, una volta fatti i controlli per le fatture sbagliate in partenza (non confermate o passive), verificare che stiamo partendo da una fattura corretta, per poi modificare una cosa alla volta e vedere se preventive_check() fa il suo lavoro, punto per punto.

SimoRubi · 2022-02-09T14:32:32Z

l10n_it_fatturapa_out/tests/test_fatturapa_xml_validation.py

+        invoice = invoice_form.save()
+        with self.assertRaises(UserError) as ue:
+            self.run_wizard(invoice.id)
+        self.assertIn(invoice.name, ue.exception.args[0])


SimoRubi · 2022-02-09T14:42:05Z

Vedo che ci sono anche altre modifiche rispetto a #2545, idealmente sarebbero da fare in una PR separata ma può essere accettabile averle anche solo in un commit separato come hai fatto, puoi però aprire una issue per tenerne traccia? Può essere che siano da riportare anche nelle altre versioni supportate

Nella 12.0 la stessa funzione non è usata.

l10n-italy/l10n_it_fatturapa_out/models/account.py

Lines 51 to 53 in dec31f7

def preventive_checks(self):

# hook for preventive checks. Override and raise exception, in case

return

Per aggiungere gli altri controlli mancanti dovrebbero in teoria esserci delle issue dedicate che nessuno ha ancora back-portato; non ho capito però se puoi aprire la issue per tenerne traccia.

TheMule71 · 2022-02-10T13:11:35Z

@SimoRubi

Se stiamo controllando i dati della fattura in modo che poi la generazione del XML non esploda, allora andrebbe controllato che il codice del fiscal_document_type_id rientri tra quelli consentiti nel XSD del XML.

Quoto a mano perché non riesco a fare Reply al commento. Allora, sì e no. Se avessimo una lista fissa di valori, sarei d'accordo. Ma ci siamo presi la briga di creare un modello, anzi, in intero modulo, che rende i tipi dinamici e modificabili runtime (immagino ci sia un motivo dietro, anche se francamente mi è oscuro, ma non è questa PR il posto per discuterne). Fatta quella scelta, non trovo corretto cablare poi un elenco fisso qui, tenendo conto che comunque, un XML sbagliato non lo generiamo (xmlschema fa la verifica di conformità). La preventive_check() non deve rifare tutti i controlli dello schema, ma magari beccare i casi più comuni che possono prendere di sorpresa l'utente e suggerigli cosa fare.

Tra parentesi, andare a prendere i valori dalla tabella comunque non risolve il problema, visto che il campo è compute, la logica è nel modulo l10n_it_fiscal_document_type, e per inserire in valore errato l'utente deve creare un riga nella stessa tabella (e il valore qui lo troverei e il check passerebbe). Se un utente si prende la briga di inserire un nuovo codice di tipo documento, che è una cosa abbastanza a basso livello, non deve soprendersi se si becca un errore a basso livello.

In più, l'elenco dei tipi può cambiare (anzi, storicamente è già cambiato). Abbiamo già da aggiornare l'xsd dello schema più la tabella del modulo l10n_it_fiscal_document_type, non aggiungerei un altro punto che dobbiamo tener aggiornato.

TheMule71 · 2022-02-10T14:24:08Z

Vedo che ci sono anche altre modifiche rispetto a #2545, idealmente sarebbero da fare in una PR separata ma può essere accettabile averle anche solo in un commit separato come hai fatto, puoi però aprire una issue per tenerne traccia? Può essere che siano da riportare anche nelle altre versioni supportate

Nella 12.0 la stessa funzione non è usata.

l10n-italy/l10n_it_fatturapa_out/models/account.py

Lines 51 to 53 in dec31f7

def preventive_checks(self):

# hook for preventive checks. Override and raise exception, in case

return

Per aggiungere gli altri controlli mancanti dovrebbero in teoria esserci delle issue dedicate che nessuno ha ancora back-portato; non ho capito però se puoi aprire la issue per tenerne traccia.

Non mi sono spiegato bene. La 12.0 non si basa sulla preventive_check() per i controlli. Non è che non ci sono, sono altrove, per es:

l10n-italy/l10n_it_fatturapa_out/wizard/wizard_export_fatturapa.py

Lines 267 to 269 in dbb00ab

    
           if not company.city: 
        
               raise UserError( 
        
                   _('Company %s, City is not set.') % company.display_name)

Ora, sulla 14 ci sono tutti i controlli fatti dalla 12? Sulla 12 ci sono tutti i controlli fatti dalla 14? Non lo so. Il codice della 12 è quello di pyxb ed è stato completamente rimpiazzato nella 14. Ho aperto #2652.

SimoRubi · 2022-02-10T14:46:23Z

La preventive_check() non deve rifare tutti i controlli dello schema, ma magari beccare i casi più comuni che possono prendere di sorpresa l'utente e suggerigli cosa fare.

ah ok pensavo che lo scopo di preventive_checks fosse non far fallire il file XML, in modo che l'utente non visualizzasse gli errori del XML che gli possono risultare illeggibili ma messaggi umanamente comprensibili; se invece lo scopo è beccare solo gli errori più comuni allora sì concordo che il controllo di esistenza dovrebbe essere il caso giusto da controllare.

TheMule71 · 2022-02-10T15:48:28Z

La preventive_check() non deve rifare tutti i controlli dello schema, ma magari beccare i casi più comuni che possono prendere di sorpresa l'utente e suggerigli cosa fare.

ah ok pensavo che lo scopo di preventive_checks fosse non far fallire il file XML, in modo che l'utente non visualizzasse gli errori del XML che gli possono risultare illeggibili ma messaggi umanamente comprensibili; se invece lo scopo è beccare solo gli errori più comuni allora sì concordo che il controllo di esistenza dovrebbe essere il caso giusto da controllare.

Ovviamente "più comuni" è completamente arbitrario: di sicuro, andrebbero implementati i controlli SdI che esulano dallo Schema, come prima cosa, per evitare di generare qualcosa che lo SdI rifiuterà. Poi sicuramente beccare le cose ovvie (es. manca la città). Però "tradurre" in python tutto lo Schema mi sembra controproducente.

Comunque, anche se fosse, come suggeriresti di fare il controllo in questo caso? Contro un elenco fisso di valori, non mi sembra il caso. In realtà a me sfugge il senso di avere una tabella editabile di possibili valori per un campo come fiscal_document_type_id, se poi TipoDocumentoType nello Schema è un enumerate. Quello che intendo è che

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)

dovrebbe essere una Select con i possibili valori presi dall'xsd (tra l'altro, la cosa xmlschema la può fare).

In tal caso, il controllo sull'esistenza sarebbe al 100% sufficiente.

TheMule71 · 2022-02-10T16:25:15Z

Aggiungo:

import xmlschema

_xml_schema_1_2_1 = "Schema_del_file_xml_FatturaPA_versione_1.2.1.xsd"
_old_xsd_specs = "xmldsig-core-schema.xsd"

validator = xmlschema.XMLSchema(
    _xml_schema_1_2_1,
    locations={"http://www.w3.org/2000/09/xmldsig#": _old_xsd_specs},
)   

print(validator.types['TipoDocumentoType'].enumeration)

['TD01', 'TD02', 'TD03', 'TD04', 'TD05', 'TD06', 'TD16', 'TD17', 'TD18', 'TD19', 'TD20', 'TD21', 'TD22', 'TD23', 'TD24', 'TD25', 'TD26', 'TD27']

Si potrebbe quindi inizializzare la lista dei valori possibili per

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)

partendo da quello (dopo averlo trasformato in Select() ovviamente)

SimoRubi · 2022-02-11T11:14:10Z

Comunque, anche se fosse, come suggeriresti di fare il controllo in questo caso?

Pensavo di riportare l'elenco di codici in una variabile statica del modulo l10n_it_fatturapa_out però come hai scritto in #2606 (comment) sarebbe un altro punto da manutenere; la soluzione ottimale sarebbe estrarli dal XML come hai scritto in #2606 (comment).

A quel punto però l'elenco estratto si deve aggiornare insieme al XML, quindi si potrebbe fare uno di:

estrarli al volo una sola volta prima della generazione delle fatture e farli utilizzare a preventive_checks
salvarli da qualche parte a livello di codice (variabile statica o altro) e aggiornarlo insieme al modulo con qualcosa tipo https://github.com/odoo/odoo/blob/82dc0cb7b91ae59beae7e1c865b670afc5958b31/addons/l10n_generic_coa/demo/account_invoice_demo.xml#L104-L109

Secondo me non vale la pena complicarsi la vita per avere così poco guadagno in termini di prestazioni e seguirei la prima strada.

Comunque farei il tutto in un'altra PR di miglioramento per riuscire portare a merge questa FIX.

EDIT:

Si potrebbe quindi inizializzare la lista dei valori possibili per

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)

partendo da quello (dopo averlo trasformato in Select() ovviamente)

Secondo me l'estrazione è da fare in l10n_it_fatturapa_out perché i valori estratti dal XML servono solo al controllo in preventive_checks, non modificherei l10n_it_fiscal_document_type.

TheMule71 · 2022-02-11T13:18:53Z

Secondo me l'estrazione è da fare in l10n_it_fatturapa_out perché i valori estratti dal XML servono solo al controllo in preventive_checks, non modificherei l10n_it_fiscal_document_type.

Ma secondo te ha senso avere un campo di testo "libero" quando sappiamo a priori l'elenco dei valori possibili?

L'xsd della fatturapa possiamo metterlo dove vogliamo, non è codice specifico , anche in l10n_it_account, se ci è comodo.

Aggiungo che si tratta di una questione più generale, non riguarda solo <TipoDocumento>. La stessa cosa succede anche per <ModalitaPagamento>, ad es., anche qui abbiamo un set di valori e un modulo che li gestisce (l10n_it_fiscal_payment_term) che potrebbe beneficiare dal prendere la lista dall'xsd, o controllarne i valori.

Per dire avere un test, in questi moduli, che controlla la tabella inserita rispetto ai valori accettabili per l'xsd, segnalando se i data caricano valori non accettabili, o di contro, NON caricano valori previsti per dimenticanza, non mi dispiacerebbe per nulla. Avremmo comunque più posti da aggiornare ma almeno un test ci dice cosa ci siamo dimenticati.

Cosi come almeno avere la possibilità segnalare all'utente che sta inserendo un nuovo codice che tale valore non è previsto dall'xsd caricato a sistema e che l'esportazione di un XML fallirebbe. Poi possiamo anche decidere di lasciare il campo come Char e lasciare la libertà all'utente, ma almeno un warning ci vorrebbe. Anche perché potrebbe indurre l'utente a cercare un aggiornamento con magari il nuovo xsd più aggiornato.

Vale anche per l10n_it_rea e altri che non cito.

Anche nell'ottica che la fatturazione elettronica è obbligatoria per praticamente tutti dal 2022, almeno segnalare all'utente che si sta ficcando in un vicolo cieco sarebbe carino. O che deve aggiornare il suo xsd.

Più ci penso e più mi piace l'idea di caricarlo in l10n_it_account, e rendere gli altri moduli dipendenti da quello (lo sono quasi tutti, direttamente o indirettamente, ma ho notato che l10n_it_rea non lo è).

TheMule71 · 2022-02-11T13:22:22Z

Nota a latere. L'xsd prevede delle annotation con documentation per i vari valori di un enumeration. Peccato che xmlschema scarti quell'informazioni, per cui non possiamo estrarre (banalmente, per carità, possiamo sempre usare lxml e parserizzarci l'xsd noi) anche le label.

SimoRubi · 2022-02-11T13:33:34Z

Secondo me l'estrazione è da fare in l10n_it_fatturapa_out perché i valori estratti dal XML servono solo al controllo in preventive_checks, non modificherei l10n_it_fiscal_document_type.

Ma secondo te ha senso avere un campo di testo "libero" quando sappiamo a priori l'elenco dei valori possibili?

Sì perché attualmente non c'è un elenco di valori possibili per il codice del tipo documento: i tipi di documento possono essere creati con qualsiasi codice di 5 caratteri.
Esiste invece un elenco di valori che possono essere inclusi nella fattura elettronica.
Per non cambiare il comportamento attuale quindi estrarrei e controllerei il codice solo al momento della generazione della fattura elettronica, in preventive_checks.

Non so poi a livello funzionale se effettivamente avrebbero senso dei tipi documento con altri codici, ma sicuramente qualche DB con dei valori sbagliati c'è e secondo me non è necessario andare a segnalare o ripulire quei record.

Comunque farei il tutto in un'altra PR di miglioramento per riuscire portare a merge questa FIX.

TheMule71 · 2022-02-11T13:53:57Z

Contro nota. Ho controllato e l'autore dei xmlschema ha aggiunto un modo per accederci: sissaschool/xmlschema#255

però disponibile dalla v1.7

Update:
con un po' di fantasia e di immaginazione:

import xmlschema

_xml_schema_1_2_1 = "Schema_del_file_xml_FatturaPA_versione_1.2.1.xsd"
_old_xsd_specs = "xmldsig-core-schema.xsd"

validator = xmlschema.XMLSchema(
    _xml_schema_1_2_1,
    locations={"http://www.w3.org/2000/09/xmldsig#": _old_xsd_specs},
)

TipoDocumentoType = validator.types['TipoDocumentoType']
enum = TipoDocumentoType.get_facet('{http://www.w3.org/2001/XMLSchema}enumeration')

for e in enum:
    print(e.get('value'))
    print(e[:][0][:][0].text)

TD01
Fattura
TD02
Acconto / anticipo su fattura
TD03
Acconto / anticipo su parcella
TD04
Nota di credito
TD05
Nota di debito
TD06
Parcella
TD16
Integrazione fattura reverse charge interno
TD17
Integrazione/autofattura per acquisto servizi dall'estero
TD18
Integrazione per acquisto di beni intracomunitari
TD19
Integrazione/autofattura per acquisto di beni ex art.17 c.2 DPR 633/72
TD20
Autofattura per regolarizzazione e integrazione delle fatture (ex art.6 c.8 e 9-bis d.lgs.471/97 o art.46 c.5 D.L. 331/93
TD21
Autofattura per splafonamento
TD22
Estrazione benida Deposito IVA
TD23
Estrazione beni da Deposito IVA con versamento dell'IVA
TD24
Fattura differita di cui all'art.21, comma 4, terzo periodo lett. a) DPR 633/72
TD25
Fattura differita di cui all'art.21, comma 4, terzo periodo lett. b) DPR 633/72
TD26
Cessione di beni ammortizzabili e per passaggi interni (ex art.36 DPR 633/72)
TD27
Fattura per autoconsumo o per cessioni gratuite senza rivalsa

"Si può fare!"

TheMule71 · 2022-02-11T14:31:17Z

Comunque farei il tutto in un'altra PR di miglioramento per riuscire portare a merge questa FIX.

Ho creato #2654

TheMule71 · 2022-08-30T11:38:36Z

La PR non è cambiata, semplice rimozione di un conflitto dovuto ad un merge recente.

francesco-ooops · 2023-12-27T10:38:57Z

@TheMule71 puoi fare rebase?

SirAionTech

Riguardando questa PR a due anni di distanza mi pare sia andata un po' fuori strada:

se è il forward porting di [10.0] l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2545, allora ci dovrebbero essere i cherry-pick dei suoi commit, modificati giusto per farli funzionare nella nuova versione, invece c'è un solo commit (9189774) con tutto dentro
ci sono tante modifiche ai preventive_checks che non hanno a che fare con la issue l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2544 linkata in descrizione: servirebbe almeno una issue dedicata per descrivere qual è il problema che si sta risolvendo.
Secondo me sarebbe anche meglio se le modifiche fossero in un'altra PR, così entrambe le PR sarebbero più atomiche, facilmente revisionabili e quindi mergiabili

github-actions · 2024-10-13T12:33:52Z

There hasn't been any activity on this pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

Add a configuration parameter in company setting to limit the number of invoices while creating an XML. Fixes OCA#2544 Forward port of OCA#2545 Co-authored-by: SimoRubi <[email protected]>

Add various checks to preventive_checks()

TheMule71 mentioned this pull request Jan 21, 2022

l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2544

Open

4 tasks

TheMule71 requested a review from SimoRubi January 21, 2022 18:54

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 4f56b09 to 529885a Compare January 28, 2022 10:23

TheMule71 mentioned this pull request Jan 28, 2022

[14.0][IMP] supporto per la conversione degli importi in EUR per fatture in valuta estera #2563

Merged

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 529885a to d5dc5e1 Compare January 28, 2022 10:48

SimoRubi suggested changes Jan 28, 2022

View reviewed changes

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch 4 times, most recently from 3e9ae1e to 4e8ed56 Compare January 28, 2022 15:37

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 4e8ed56 to 03153d5 Compare January 28, 2022 15:55

TheMule71 requested a review from SimoRubi January 28, 2022 17:04

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 03153d5 to 6720e27 Compare February 4, 2022 15:27

SimoRubi approved these changes Feb 9, 2022

View reviewed changes

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 6720e27 to 3042cbc Compare February 10, 2022 13:52

TheMule71 mentioned this pull request Feb 11, 2022

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

Closed

TheMule71 requested a review from SimoRubi February 11, 2022 14:32

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 3042cbc to 07a7bf2 Compare April 8, 2022 15:01

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch 2 times, most recently from 8876fac to 550bdd8 Compare April 22, 2022 07:45

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 550bdd8 to 4876d52 Compare May 6, 2022 10:52

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 4876d52 to 4443546 Compare August 30, 2022 11:37

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 4443546 to 12e7b8c Compare October 25, 2022 09:20

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 12e7b8c to 12c6132 Compare March 1, 2024 09:04

francesco-ooops mentioned this pull request Jun 13, 2024

[FIX] l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #3800

Merged

SirAionTech requested changes Jun 13, 2024

View reviewed changes

github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Oct 13, 2024

SirAionTech added the needs fixing Has conflicts or is failing mandatory CI checks label Oct 14, 2024

github-actions bot removed the stale PR/Issue without recent activity, it'll be soon closed automatically. label Oct 20, 2024

TheMule71 and others added 2 commits October 21, 2024 15:43

[FIX] l10n_it_fatturapa_out: max number of invoices for FatturaPA

5a35be1

Add a configuration parameter in company setting to limit the number of invoices while creating an XML. Fixes OCA#2544 Forward port of OCA#2545 Co-authored-by: SimoRubi <[email protected]>

[FIX] l10n_it_fatturapa_out: add check on invoice

cee1c1f

Add various checks to preventive_checks()

TheMule71 force-pushed the 14.0-fix-l10n_it_fatturapa_out_2544 branch from 12c6132 to cee1c1f Compare October 21, 2024 13:43

SirAionTech added the is porting This pull request is porting a change from another version label Nov 8, 2024

	<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">
	<t t-set="partner_id" t-value="partner_id" />
	</t>

	<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">
	<t t-set="partner_id" t-value="company_id.partner_id" />
	</t>

	<t t-call="l10n_it_fatturapa_out.account_invoice_it_FatturaPA_sede">
	<t
	t-set="partner_id"
	t-value="company_id.fatturapa_stabile_organizzazione"
	/>
	</t>

	"Invoice %s city in our company's Stabile Organizzazione must be set",
	"Invoice %s city in our company's Stable Organization must be set",

[14.0][FIX] l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2606

Are you sure you want to change the base?

[14.0][FIX] l10n_it_fatturapa_out: Configurazione in azienda per numero massimo fatture per fattura elettronica #2606

Conversation

TheMule71 commented Jan 21, 2022

SimoRubi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheMule71 Jan 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheMule71 commented Jan 28, 2022

TheMule71 commented Jan 28, 2022

SimoRubi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SimoRubi commented Feb 9, 2022

TheMule71 commented Feb 10, 2022

TheMule71 commented Feb 10, 2022 • edited Loading

SimoRubi commented Feb 10, 2022

TheMule71 commented Feb 10, 2022

TheMule71 commented Feb 10, 2022

SimoRubi commented Feb 11, 2022 • edited Loading

TheMule71 commented Feb 11, 2022

TheMule71 commented Feb 11, 2022

SimoRubi commented Feb 11, 2022

TheMule71 commented Feb 11, 2022

TheMule71 commented Feb 11, 2022

TheMule71 commented Aug 30, 2022

francesco-ooops commented Dec 27, 2023

SirAionTech left a comment

Choose a reason for hiding this comment

github-actions bot commented Oct 13, 2024

TheMule71 Jan 28, 2022 •

edited

Loading

TheMule71 commented Feb 10, 2022 •

edited

Loading

SimoRubi commented Feb 11, 2022 •

edited

Loading