[14.0][ADD] l10n_it_fatturapa_out: edit invoice sent SDI

[Borruso]

Risolve #2731 per la 14

--
Confermo di aver firmato il CLA https://odoo-community.org/page/cla e di aver letto le linee guida su https://odoo-community.org/page/contributing

[marcelofrare]

Ritengo controproducente per tutti consentire modifiche di questo tipo.
Ad esempio sono riuscito a cambiare il Cliente nella fattura e riconfermala mantenendo l'xml inalterato.
Se dobbiamo coprire questa funzionalità, farei un wizard con il singolo campo da modificare, dove siamo certi che non risulta presente sul xml e non crea problemi alla fattura, senza dover portare in bozza il documento.

[MarcoCalcagni]

Ciao Marcelo, il primo punto c'è un gruppo che è abilitato al cambio.
per la modifica del cliente indago il tool controlla la Piva .
per il terzo punto è stata discussa e scelta questa modalità nel venerdi .

[MarcoCalcagni]

Ritengo controproducente per tutti consentire modifiche di questo tipo. Ad esempio sono riuscito a cambiare il Cliente nella fattura e riconfermala mantenendo l'xml inalterato. Se dobbiamo coprire questa funzionalità, farei un wizard con il singolo campo da modificare, dove siamo certi che non risulta presente sul xml e non crea problemi alla fattura, senza dover portare in bozza il documento.

ho provato il cambio cliente . il controllo funziona mi ha bloccato . il sistema controlla la Piva se cambi partner con stessa piva ti è concesso.

se puoi descrivi meglio @marcelofrare
FYI @stevech091

[TheMule71]

Per i test che falliscono, probabilmente l'oggetto request è vuoto / non inizializzato. Probabilmente vale lo stesso per operazioni automatiche, tutto ciò che non segue un'azione da parte dell'utente.

Nota: il motivo di tale controllo è che l'auto post della fattura va fatto solo per le write() chiamate da JS direttamente, per es. col pulsante di Save (per la 16.0 vedremo).

Esiste la possibilità che delle write() vengano chiamate da python (da altri moduli) per es. in button_draft(), che romperebbe la logica del codice qui.

[francescapenso]

funziona. L'utente deve avere particolare attenzione per le autofatture ai cambi "iva",ma non dipende dal modulo è una nota di accortezza

[marcelofrare]

Confermo che ora funziona come previsto.

[francescapenso]

qualche news?

[tafaRU]

Le modifiche apportate mi sembrano nel complesso buone.
Oltre ai commenti/suggerimenti che trovi nella mia review sarei per implementare alcuni test automatici che coprano la nuova funzionalità.

Grazie!

[eLBati]

/ocabot rebase

[OCA-git-bot]

Congratulations, PR rebased to 14.0.

[mrcast]

buon pomeriggio a tutti,
stavo testando la PR, ma non mi è chiaro una passaggio:

• fattura validata e file XML generato, devo riportarla a bozza per poter fare le modifiche
  Al riporta a draft la fattura
  ATTESO
  viene riportata a bozza la fattura anche se c'è XML
  OSSERVATO
  Invoice INV/2023/06/00xx has XML and can't be reset to draft. Delete the XML before.

C'è qualche passaggio che va fatto su qualche vista e che mi sfugge?
grazie!

[Borruso]

C'è qualche passaggio che va fatto su qualche vista e che mi sfugge? grazie!

C'è un gruppo apposito per portarlo in draft. Edit Invoice Sent SDI

[mrcast]

C'è qualche passaggio che va fatto su qualche vista e che mi sfugge? grazie!

C'è un gruppo apposito per portarlo in draft. Edit Invoice Sent SDI

grazie mille @Borruso

[mrcast]

Test funzionale, ok per me

[SirTakobi]

C'è qualche passaggio che va fatto su qualche vista e che mi sfugge? grazie!

C'è un gruppo apposito per portarlo in draft. Edit Invoice Sent SDI

Si potrebbe documentare nel README o menzionare nel messaggio di errore, cosa ne pensi?
Altrimenti l'utente come fa a sapere che c'è questa possibilità?

[Borruso]

Si potrebbe documentare nel README o menzionare nel messaggio di errore, cosa ne pensi? Altrimenti l'utente come fa a sapere che c'è questa possibilità?

hai ragione bisogna aggiornare il readme

[newneo47]

Funziona

[eLBati]

/ocabot merge minor

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 14.0-ocabot-merge-pr-2966-by-eLBati-bump-minor, awaiting test results.

[OCA-git-bot]

@eLBati your merge command was aborted due to failed check(s), which you can inspect on this commit of 14.0-ocabot-merge-pr-2966-by-eLBati-bump-minor.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

[eLBati]

/ocabot rebase

[OCA-git-bot]

Congratulations, PR rebased to 14.0.

[tafaRU]

/ocabot rebase

[OCA-git-bot]

Congratulations, PR rebased to 14.0.

[tafaRU]

@Borruso i test falliscono. Puoi verificare?

[danall59]

Gent.mo @Borruso,
questa PR è molto interessante ma purtroppo non può essere mergiata in quanto genera 2 errori sui Test.
Come stato accennato oggi nella riunione del venerdì mattina, sarebbe utile un tuo ultimo sforzo per risolvere il problema.
Grazie

[Borruso]

Non so perché da quell'errore ho cercato di fare rebase ma non ha funzionato
Come se il partner non abbia la città impostata e si incazza

[francesco-ooops]

/ocabot rebase

[OCA-git-bot]

Congratulations, PR rebased to 14.0.

[aleuffre]

Ho indagato l'errore sui test, e ho capito da dove viene il problema. Faccio un riassunto:

1. Il modulo l10n_it_fatturapa_import_zip fa dei test importando fatture da uno zip. La fattura incriminata all'interno dello zip è la IT06363391001_00009.xml
2. La fattura in questione è verso "Foreign Customer", riporto la parte rilevante

        <CessionarioCommittente>
            <DatiAnagrafici>
                <IdFiscaleIVA>
                    <IdPaese>AE</IdPaese>
                    <IdCodice>99999999999</IdCodice>
                </IdFiscaleIVA>
                <Anagrafica>
                    <Denominazione>Foreign Customer</Denominazione>
                </Anagrafica>
            </DatiAnagrafici>
            <Sede>
                <Indirizzo>29-17 Al Thanya St</Indirizzo>
                <CAP>00000</CAP>
                <Comune>Dubai</Comune>
                <Provincia>EE</Provincia>
                <Nazione>AE</Nazione>
            </Sede>
        </CessionarioCommittente>

3. La funzione getPartnerBase dovrebbe cercare il contatto associato alla fattura. Lo cerca in base alla VAT (99999999999), non lo trova, e lo crea da zero, senza la città.
4. Esiste un contatto nei dati di Demo di l10n_it_fatturapa "Foreign Customer" senza VAT. Dato che getPartnerBase cerca solo tramite VAT, non lo trova.
5. Quando questa fattura viene importata, vengono calcolate delle compute, e si arriva infine alla write di AccountMove in l10n_it_fatturapa_out introdotta da questa PR, dove si vuole creare l'XML della fattura.
6. La fattura di questo nuovo contatto "Foreign Customer" appena creato (che è diverso da quello presente nei dati di Demo) non ha la città impostata. La creazione della fattura fallisce in questo punto perché partner_id.city contiene False, mentre la funzione encode_for_export si aspetta una stringa.

La modifica semplice semplice per far passare i test sarebbe stata quella di modificare il template della fattura XML con

<Comune t-esc="encode_for_export(partner_id.city or '', 60)" />

l'ho provata, e arriva in fondo alla generazione dell'XML, salvo poi sollevare svariati errori sulla validazione di questo XML, di cui quello di avere il Comune vuoto è solo uno.

Errore Completo

  File "/opt/odoo/auto/addons/l10n_it_fatturapa_out/wizard/efattura.py", line 264, in to_xml
    raise UserError("\n".join(str(e) for e in errors))
odoo.exceptions.UserError: failed validating '' with XsdPatternFacets(['[\\p{IsBasicLatin}\\p{IsLatin-1Supplement}]{1,60}']):

Reason: value doesn't match any pattern of ['[\\p{IsBasicLatin}\\p{IsLatin-1Supplement}]{1,60}']

Schema component:

  <xs:pattern xmlns:xs="http://www.w3.org/2001/XMLSchema" value="[\p{IsBasicLatin}\p{IsLatin-1Supplement}]{1,60}" />

Instance type: <class 'lxml.etree._Element'>

Instance (line 105):

  <Indirizzo xmlns:ns1="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2"/>

Path: /ns1:FatturaElettronica/FatturaElettronicaHeader/CessionarioCommittente/Sede/Indirizzo

failed validating '' with XsdPatternFacets(['[\\p{IsBasicLatin}\\p{IsLatin-1Supplement}]{1,60}']):

Reason: value doesn't match any pattern of ['[\\p{IsBasicLatin}\\p{IsLatin-1Supplement}]{1,60}']

Schema component:

  <xs:pattern xmlns:xs="http://www.w3.org/2001/XMLSchema" value="[\p{IsBasicLatin}\p{IsLatin-1Supplement}]{1,60}" />

Instance type: <class 'lxml.etree._Element'>

Instance (line 110):

  <Comune xmlns:ns1="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2"/>

Path: /ns1:FatturaElettronica/FatturaElettronicaHeader/CessionarioCommittente/Sede/Comune

failed validating <Element DatiBeniServizi at 0x7fd3f89be400> with XsdGroup(model='sequence', occurs=[1, 1]):

Reason: The content of element 'DatiBeniServizi' is not complete. Tag 'DettaglioLinee' expected.

Schema component:

  <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="DatiBeniServiziType">
    <xs:annotation>
      <xs:documentation>Blocco relativo ai dati di Beni Servizi della Fattura    Elettronica</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="DettaglioLinee" type="DettaglioLineeType" maxOccurs="unbounded" />
      <xs:element name="DatiRiepilogo" type="DatiRiepilogoType" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>

Instance type: <class 'lxml.etree._Element'>

Instance (line 202):

  <DatiBeniServizi xmlns:ns1="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2">
                  
                  
                  
              
          
          
              
              
          
          
                  
          
              
          
          
              </DatiBeniServizi>

Path: /ns1:FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi

Tuttavia, direi che ci siano delle cose da aggiustare in altri moduli che non dipendono necessariamente da questa PR (ma che questa PR ha fatto accidentalmente venire fuori?) ma non ne so abbastanza di quale dovrebbe teoricamente essere il flusso per proporre una soluzione sensata (Va inibita la generazione dell'XML nella write in base ad alcune condizioni? O va inserito skip_check_xml nel contesto di l10n_it_import_zip?).

[aleuffre]

Dopo aver indagato ulteriormente, credo che il problema sia in questa funzione

l10n-italy/l10n_it_fatturapa_import_zip/wizards/wizard_import_fatturapa.py

Lines 28 to 35 in 546c2d6

	def _get_invoice_partner_id(self, fatt):
	if self._is_import_attachment_out():
	partner_id = self.getPartnerBase(
	fatt.FatturaElettronicaHeader.CessionarioCommittente.DatiAnagrafici
	)
	else:
	partner_id = super()._get_invoice_partner_id(fatt)
	return partner_id

_get_invoice_partner_id usa getCedPrest che usa getPartnerBase, ma poi compila gli altri campi dell'indirizzo. Invece getPartnerBase di per sé non lo fa.

Bisognerebbe usare getCedPrest passando come argomento il nodo CessionarioCommittente, o, più corretto, fare un piccolo refactor della funzione getCedPrest (un rename e poco altro?) perché diventi generica. Non si dovrebbe usare direttamente getPartnerBase.

Anche avendo la città e tutto il resto dell'indirizzo compilato, rimane l'ultimo problema di validazione della fattura nell'errore indicato, legati a DatiBeniServizi

EDIT: Confermo, con la seguente modifica

    def _get_invoice_partner_id(self, fatt):
        if self._is_import_attachment_out():
            partner_id = self.getCedPrest(
                fatt.FatturaElettronicaHeader.CessionarioCommittente
            )
        else:
            partner_id = super()._get_invoice_partner_id(fatt)
        return partner_id

rimane solo l'ultimo errore di validazione fattura.

Errore rimasto

odoo.exceptions.UserError: failed validating <Element DatiBeniServizi at 0x7f3fbfb87c40> with XsdGroup(model='sequence', occurs=[1, 1]):

Reason: The content of element 'DatiBeniServizi' is not complete. Tag 'DettaglioLinee' expected.

Schema component:

  <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="DatiBeniServiziType">
    <xs:annotation>
      <xs:documentation>Blocco relativo ai dati di Beni Servizi della Fattura    Elettronica</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="DettaglioLinee" type="DettaglioLineeType" maxOccurs="unbounded" />
      <xs:element name="DatiRiepilogo" type="DatiRiepilogoType" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>

Instance type: <class 'lxml.etree._Element'>

Instance (line 202):

  <DatiBeniServizi xmlns:ns1="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2">
                  
                  
                  
              
          
          
              
              
          
          
                  
          
              
          
          
              </DatiBeniServizi>

Path: /ns1:FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi

[aleuffre]

L'ultimo errore di validazione è dovuto a questo:

l10n-italy/l10n_it_fatturapa_in/wizard/wizard_import_fatturapa.py

Lines 1199 to 1226 in 546c2d6

	invoice = self.env["account.move"].create(invoice_data)
	credit_account = self.get_credit_account()
	invoice_lines = []
	# 2.2.1
	invoice_lines.extend(
	self.set_invoice_line_ids(
	FatturaBody,
	credit_account.id,
	partner,
	found_withholding_taxes,
	invoice,
	)
	)
	# 2.1.1.7
	invoice_lines.extend(
	self.set_welfares_fund(
	FatturaBody, credit_account.id, invoice, found_withholding_taxes
	)
	)
	# 2.1.1.10
	invoice_lines.extend(self.set_efatt_rounding(FatturaBody, invoice))
	invoice.with_context(check_move_validity=False).update(
	{"invoice_line_ids": [(6, 0, invoice_lines)]}
	)

Riga 1199, la fattura viene creata senza righe. Riga 1226, la fattura viene aggiornata con le righe giuste (e poi ancora, riga 1230, la fattura viene aggiornata di nuovo.)

Tuttavia, il test fallisce già alla riga 1199. In altre parole, l'XML viene prodotto troppo presto, prima che la fattura sia stata propriamente creata in tutte le sue parti, con i dati finali corretti. Se non si fosse rotta la validazione XML, immagino si sarebbero rotti i controlli inseriti da questa stessa PR.

Il test test_import_zip fallisce sulla prima fattura importata di tipo out_invoice, che è anche la prima di cui cerca di creare il file XML.

[francesco-ooops]

@SirTakobi @eLBati @TheMule71 qualche suggerimento in merito a questo?

[francesco-ooops]

@SirAionTech chiaramente cercavo te :)

[SirAionTech]

qualche suggerimento in merito a questo?

Riassumo, basandomi esclusivamente sull'analisi fatta dal buon @aleuffre

Il modulo import_zip crea una fattura da una FE, però la crea facendo esattamente gli stessi passi di fatturapa_in quindi la crea solo con la testata, poi aggiunge le righe, poi magari fa anche altre cose.. Insomma la crea per passi.

Questo non va bene a questa PR perché appena la fattura viene creata, dice che non matcha con la FE collegata.

Suggerimenti:

• Modificare fatturapa_in per creare la fattura tutta in un colpo.
• Modificare fatturapa_in per collegare la FE alla fattura solo alla fine, quando le modifiche in questa PR non solleveranno eccezioni.
• Modificare import_zip e includere nel contesto skip_check_xml finché la fattura out è in fase di creazione.

[github-actions]

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.