Gruppi IVA

[alessandrocamilli]

Versioni coinvolte:

• 10.0 10.0 fatturapa in: search by VAT and CF #1674 (risolta per fine supporto)
• 11.0 11.0 fatturapa in: search by VAT and CF #1675
• 12.0 12.0 fatturapa in: search by VAT and CF #1676 [12.0] [FIX] l10n_it_fatturapa_in - Gruppi IVA #3100
• 14.0 [IMP] l10n_it_fatturapa_in: Update logic to import e-invoice xml #3513
• 16.0 [FIX] l10n_it_fatturapa_in - Gruppi IVA #3810

Passi per riprodurre:
Occorre gestire il caso di gruppi IVA. Ovvero più partner che hanno la stessa partita iva con codici fiscali diversi.

Comportamento osservato:
L'import delle fatture in ingresso per questa tipologia di partner, non è in grado di assegnare correttamente il partner di competenza.

Comportamento atteso:
Per questa tipologia di partner, oltre alla partita iva, occorre trovare la corrispondenza per codice fiscale

Video/Screenshot (opzionale):

[eLBati]

Per la struttura capogruppo-partecipanti si potrebbe usare partner_affiliate

[sergiocorato]

Bello partner_affiliate, di per sè però non sarebbe necessario, essendo che sarebbe sufficiente ricercare per partita iva e se si trova più di un riscontro ricercare per codice fiscale (non c'è un blocco sull'unicità della partita iva, e se si mette - come minimo - si controlla per IVA e codice fiscale)

[alessandrocamilli]

l'idea è quella di

• Aggiungere un flag all'interno del partner:
  gruppo_iva - boolean
• Se il flag è a True, il codice fiscale è obbligatorio
• In fase di import della fattura elettronica, l'associazione del partner deve tenere conto della partita iva e del codice fiscale

[gigidn]

i partner vanno tenuti separati poiche' nella stra-grande maggioranza dei casi son aziende diverse, andarsi a complicare la vita gestendo la relazione a che pro???
Le PIVA "doppie" son legate all'iva di gruppo che per le passive non ha importanza imho, e' solo altro partner da caricare facendo attenzione ad usare doppia chiave PIVA e CF.
@sergiocorato la ricerca per occorrenze potrebbe portare a risultati errati, faccio un esempio:

1. In anagrafica ho Cliente X con PI A e CF B
2. Mi arriva fattura di Cliente Y con PI A e CF C

Se si applica la logica dell'occorrenza la fattura sarebbe attributi al cliente X e non al cliente Y

Il CF quindi andrebbe controllato anche in presenza di occorrenza 1, la anagrafica va resa univoca per PI e CF con il CF che entra in gioco se valorizzato in fattura.

Spero di esser stato chiaro.

[sergiocorato]

@gigidn l'utilizzo del modulo partner_affiliate non lo ritengo infatti necessario, di per sè è sufficiente inserire P.IVA e C.F. correttamente.

Ok per ricercare sempre contemporaneamente per entrambi i campi, se valorizzati, tenendo conto che si sta parlando di fatture ricevute (fornitori) e quindi può presentarsi il caso in cui il fornitore parte del gruppo d'impresa non sia presente in anagrafica.

[SilvioGregorini]

@eLBati @sergiocorato @gigidn @alessandrocamilli
se per voi è ok, proporrei questa modifica nel metodo getPartnerBase di wizard.import.fatturapa:

        partners = partner_model
        if vat:
            partners = partner_model.search([
                ('vat', '=', vat),
            ])
+           if len(partners) > 1:
+               partners = partners.filtered(lambda p: p.fiscalcode == cf)
+           if len(partners) > 1:
+               partners = partners.mapped('commercial_partner_id')
        if not partners and cf:
            partners = partner_model.search([
                ('fiscalcode', '=', cf),
            ])
        if len(partners) > 1:

In questo modo non c'è nemmeno bisogno di modificare il successivo controllo relativo a commercial_partner_id.

[mrcast]

Buongiorno a tutti,

cerco di spiegare l'esigenze Capogruppo da un altro punto di vista, cercando anche di portare alla luce alcuni casi d'uso.
Esempio
CapoGruppo, Affiliata1, Affiliata2
CapoGruppo ha PIVA_GRUPPO e CF
Affiliata1 ha una propria PIVA e CF
Affiliata1 ha una propria PIVA e CF

Io azienda ACME SRL posso dover emettere fattura nei confronti di Affiliata1 con suoi dati (usando quindi la PIVA e CF dell'affiliata) oppure fatturare all'Affiliata1 utilizzando PIVA_GRUPPO
Inoltre sempre io ACME SRL devo sapere chi sono le affiliate di un certo GRUPPO e sapere ad esempio quando ho fatturato sul GRUPPO complessivamente e sulle singole affiliate

Quindi il fatto di scrivere la PIVA_GRUPPO nel campo partita iva della affiliata mi fa perdere l'informazione della partita iva dell'affiliata
Se l'affiliata è una ditta individuale, inoltre, PIVA e CF sono diversi, quindi non posso neanche risalire a PIVA dal CF

Infine, il fatto di ripetere la PIVA_GRUPPO nel campo PIVA non lo vedo positivamente, diversi clienti ci hanno chiesto in passato e danno per scontato che il campo PIVA faccia un controllo di univocità, questo per identificare in modo certo l'anagrafica di una partner ed evitare doppioni

cosa ne pensate?
grazie,
Mario

[mrcast]

Aggiungo a integrazione del messaggio precedente, che il modulo https://github.com/OCA/partner-contact/tree/12.0/partner_group, può essere una buona base per assolvere alla relazione tra capogruppo e affiliata

[sergiocorato]

Grazie @mrcast , quindi la casistica è un pelino più complessa di una p.iva che si ripete in diversi partner con cf diverso...

Quindi:

1. fattura emessa verso Affiliata1 con PIVA_GRUPPO contiene P.IVA GRUPPO e CF affiliata,
2. fattura emessa verso Affiliata1 con PIVA affiliata, contiene PIVA affiliata e CF affiliata.

La discriminante alla fine è quindi il CF? Attualmente, se ricevo fattura 2. va corretta, se ricevo fattura 1. va erroneamente in un'altro partner.

Potrebbe essere sufficiente la logica del modulo partner_group, nel caso sarebbe quindi da inserire la ricerca per il CF in via prioritaria se presente e poi per PIVA, quindi se l'azienda ha una PIVA diversa, verificare se fa parte di un gruppo con quella PIVA, in caso contrario andrebbe creato (qualcosa del genere).

[mrcast]

@sergiocorato : sì mi sembra che possa andare bene

[SilvioGregorini]

@mrcast @alessandrocamilli @sergiocorato @eLBati @gigidn

Scusate se riesumo questa discussione, ma alla fine si era raggiunta una quadra sul come debbano essere gestite le fatture in ingresso per i Gruppi IVA?

[sergiocorato]

Al momento ho la casistica della fatturazione in uscita (ho fatto un semplice modulo che estende il modulo partner_group aggiungendo la possibilità di scegliere nell'affiliata se la fatturazione va verso la capogruppo, cosa fattibile anche manualmente).
I dettagli sopra non sono sufficienti?

[SilvioGregorini]

@sergiocorato più che altro, non mi è ben chiaro il da farsi. Quale dovrebbe essere l'iter specifico da "tradurre" in codice?

[TheMule71]

Aggiornata: direi che si applica a 14.0 e 16.0 (post migrazione)

[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.

[francesco-ooops]

@OCA/local-italy-maintainers è corretta che questa venga chiusa in stale o è una funzionalità necessaria nelle versioni successive?

[francesco-ooops]

@SirAionTech dunque questa è da riaprire giusto?

[SirAionTech]

@SirAionTech dunque questa è da riaprire giusto?

Direi di sì, tanto più che non era stata chiusa perché risolta ma perché marcita