[14.0] Sezionale Anno Precedente e liquidazione IVA

[francescapenso]

Sezionale Acquisti Anno Precedente. --regola-- posso far concorrere alla liquidazione del 2021 le fatture

• di operazioni effettuate nel 2021
• che erano in mio possesso nel 2021 SE voglio registrare (annotare) alcune di queste fatture più tardi, prima della presentazione della dichiarazione IVA, allora le devo mettere in un "apposito sezionale". --soluzione-- Creerò un sezionale "iva acquisti anno " in cui metterò tutte quelle fatture che avevano i presupposti per andare nella dichiarazione dell'anno precedente rispetto a quando sto materialmente facendo la registrazione

Domanda: Come faccio a far ricadere tale registro nella liquidazione iva dicembre 2021 e non in quella gennaio 2022 ?

La soluzione a mio avviso deve essere quella di implementare quanto suggerito da Marco Colombo (poi ogni cliente deciderà se usarlo o meno) qui
https://github.com/OCA/l10n-italy/pull/2208

[francescapenso]

@TheMule71

[eLBati]

Il discorso è analogo a https://github.com/OCA/l10n-italy/issues/1183 ?

[TheMule71]

Il discorso è analogo a #1183 ?

Yes. L'attuale implementazione per come la vedo io, forza l'eventuale perdita di un dato (data registrazione) se si decide di registrare usando la data fattura. Ossia si impone .date = .invoice_date in uno dei due casi, perdendo il valore originario.

Io terrei .date e .invoice_date separate. Poi possiamo discutere se la strada migliore è un campo data in più, oppure un boolean che determina se usare .date o .invoice_date ai fini della compilazione dei registri iva. Il campo .date_vat_settlement rende l'implementazione più semplice, perché si guarda solo quella per ciascuna riga, oltre a permettere all'utente la massima flessibilità. Ma se vogliamo togliere questa flessibilità, basta nascondere il campo e renderlo tecnico, o metterlo readonly e poi inizializzarla con uno degli altri due valori, a seconda della preferenza (l'effetto è lo stesso dell'attuale controllo).

Col boolean devi valutare (move.invoice_date if move.vat_use_invoice_date else move.date) per ogni fattura. Non che sia un problema, per carità.

Al di là di perdersi un dato in modo definitivo, le mie perplessità sono anche sull'idea che il campo move.date serva esclusivamente per l'IVA, e che quindi possiamo disporne liberamente per modificare il comportamento della stampa registri/liquidazione IVA e sul creare una move con .date antecedente alla data dell'oggetto da cui deriva (l'XML ricevuto dallo SdI).

È possibile che sia così. Oppure che al momento, ad ogni altro modulo che vada a guardare move.date vada bene che venga anticipata (ossia va di pari in passo con l'IVA).

[francescapenso]

e quindi?

[francescapenso]

@eLBati cosa dici?

[eLBati]

Non so, io registro, e faccio registrare a tutti i clienti, usando la data di ricezione. La liquidazione IVA si basa su tale data e non ho ambiguità. Quindi non posso essere d'aiuto su questo.

[marco-marchiori]

Cerco di rispondere brevemente ed in modo asettico. La funzione del "sezionale" nell'impostazione dell'AE è quella di farvi confluire documenti (finora) non inclusi nei normali registri per considerarli nella dichiarazione.

--a sistema esistente-- Aprirò un sezionale tipo quello descritto sopra e registrerò (pensando al 2022) le operazioni di acquisto mancanti in data 2021. Quelle operazioni dovranno confluire nella mia dichiarazione IVA 2022 per il 2021.

--per il progetto che vedo-- Si dovrà definire una nuova data definendo a cosa serve. Se serve solo all'IVA dovrebbe conseguire che quella data indicherà la dichiarazione IVA in cui si vorrà far confluire i documenti.

Va poi chiarito cos'è la data di registrazione. Venendo alle mie opinioni sospetto che (se ho ben capito) sacrificare la data di registrazione a favore di una "data iva" non sia esattamente un affare.

[TheMule71]

Le mie domande sono:

1. esistono casi in cui, per l'IVA, non va bene la data fattura, quella scritta nell'XML DatiGeneraliDocumentoType/Data, ossia quella del documento come l'ha scritta il fornitore? Come la capisco io, quella in fattura dovrebbe risultare come la data di esecuzione della prestazione, e dovrebbe essere quella giusta per l'IVA; in Odoo è il campo .invoice_date della account.move?

2. esistono casi, al di fuori dell'IVA, in cui importa la data di registrazione, intesa come quella vera in cui l'operatore esegue la conferma della fattura, ad es. dopo averla importata dallo SdI? in Odoo, il campo è .date di account.move.

I registri e le liquidazioni (a quel che mi risulta) usano .date per selezionare le fatture relative ad un periodo. In effetti, .date viene usata per tutto, credo.

Se la risposta per la 1. è "no", un campo data aggiuntivo non serve. Basta un flag per dire quale delle due date considerare.

Se la risposta per la 2 è "no", e sarà sempre no per il futuro, possiamo continuare ad usare la .date e basta come adesso.

I miei dubbi sono:

1. esistono casi in cui l'operatore potrebbe voler inserire una data diversa sia dalla data documento / esecuzione prestazione impostata dal fornitore e sia da quella in cui esegue l'operazione? (per me no, ma chiedo)

2. è possibile che a fronte di due fatture, ricevute (con data certificata dallo SdI) in data B e C con B < C, con la prima registrata con data di arrivo (quandi sempre B), la seconda con data fattura, A, con A < B < C ci possa essere qualche contestazione?

Es.

• fattura F1, datata 28/2/2022, arrivata il 5/3/2022, registrata con .date = 5/3/2022, e .invoice_date = 28/2/2022;
• fattura F2, datata 26/2/2022, arrivata il 7/3/2022, registrata con .date = 26/2/2022 e .invoice_date = 26/2/2022.

Questo è quanto permette di fare il sistema attuale, la prima è stata registrata usando la data di oggi (data in cui l'operatore fa l'operazione), la seconda usando la data fattura. Per esplicitare i miei dubbi:

1. ha senso che l'operatore possa desiderare di registrare la F2 con una data diversa sia da 26/2 sia da 7/3? oppure quelle sono le due scelte possibili;
2. è possibile che qualcuno possa trovare da ridire sul fatto che la F2 risulta essere registrata il 26/2, ossia prima di essere stata ricevuta e prima della F1, pur essendo ricevuta dopo? (chiedo, non sto dicendo che il problema c'è)
3. la data 7/3 della F2, che in odoo è andata "persa" (nel senso che non è in un campo della account.move) può servire a qualcosa?
4. potrebbe l'operatore voler registrare la F2 con .date = 28/2/2022 (intesa come "fine del periodo precedente"), ma preservando sia 26/2 che 7/3?

[marco-marchiori]

1. sì: tutti i casi in cui i presupposti per la detraibilità non ci sono alla data del documento (ad esempio non ho la disponibilità di un doucumento in quella data)
2. sì ma la tua definizione di data contabile è a mio parere imprecisa, l'utilizzo della data contabile per l'IVA non è pre-scritto ma come dico, è una soluzione ragionevole per la maggior parte dei casi

esistono casi in cui l'operatore potrebbe voler inserire una data diversa sia dalla data documento / esecuzione prestazione impostata dal fornitore e sia da quella in cui esegue l'operazione? (per me no, ma chiedo)

non sono casi predeterminabili: il contabile decide la data (capisco che questo contrasti con tante recenti promesse di robotizzare o automatizzare il povero contabile ma questo si può fare solo definendo lo spazio di tutte le possibili registrazioni)

è possibile che a fronte di due fatture, ricevute (con data certificata dallo SdI) in data B e C con B < C, con la prima registrata con data di arrivo (quandi sempre B), la seconda con data fattura, A, con A < B < C ci possa essere qualche contestazione?

se non ci sono altri problemi è possibile e non ci sono contestazioni (ovviamente non vale per il fine anno)

per il resto

1. c'è chi le registrerebbe il 28/2 per ordinamento/progressività (peraltro abolita per le FF)
2. è possibile, visto che c'è sempre qualcuno che ha qualcosa da ridire :-) ma non c'è nulla da ridire, è una deroga al criterio rigido del possesso ammessa dalla legge
3. rileva a fine anno, non in generale in corso d'anno, ovviamente ci sarà qualcuno che registra in base a ricezione (vedi @eLBati )
4. registrare in data 28/2 ha senso, vedi sopra, mentre "preservare" (intendi memorizzare in qualche modo)... io non lo farei

Diciamo che ogni documento ha un termine da cui ed un termine entro il quale va registrato, negli ultimi anni l'Agenzia si è inventata limiti e criteri stretti ma non è che la (modalità di) registrazione di un documento riesce ad influire sull'altro.

[TheMule71]

Quello che sto cercando di determinare, nel contesto più ampio possibile, quindi non solo in termini di registri IVA, quali sono le date genericamente associabili ad una fattura (passiva in questo caso).

Alcune semplicemente non le decidiamo noi, per es., la data documento (la decide il fornitore), la data di conferma avvenuta trasmissione / ricezione (sono date decise dallo SdI). Altre le possiamo aggiungere noi, come la data di registrazione e (se preferisci distinguerle) la data di avvenuta registrazione (il momento quando l'operatore fa l'operazione).

Queste date possono essere salvate nel database, in campi della nostra account.move. Questi campi - ovviamente - servono per le elaborazione future. Se una data non servirà mai (se non per essere consultata in casi particolari una volta l'anno), è inutile salvarla, specie se la si può ritrovare (magari aprendo l'XML, per dire). Questo anche per evitare la proliferazioni di campi inutili.

Siccome io non so quali sono le possibili operazioni future, ho sempre un dubbio quando un dato viene cancellato o sovrascritto con un valore, soprattutto quando questo valore è già presente in un altro campo (è una cosa inutile, il dato ce l'ho già).

Essendo che una data, per definizione direi, rappresenta anche una sequenza monotonica, ho sempre un dubbio quanto tale sequenza viene alterata. Per una deformazione professionale che vado male a spiegare, mi viene l'orticaria quando una data viene portata indietro, specie in sistemi transazionali (molto meno quando viene portata in avanti). Un'analogia non informatica che forse vagamente rende l'idea è quella di certe medicine, che ti dicono se non ti ricordi se l'hai presa o no, molto meglio non prenderla piuttosto che prenderla due volte. Portare l'orologio avanti potrebbe farti saltare la medicina, portarlo indietro fartela prendere due volte. In informatica portare una data indietro tende a fare più danni che portarla avanti.

Ecco, il codice attuale fa entrambe le cose.

Copia il valore di .invoice_date su .date. Il valore di .invoice_date è sempre indietro nel tempo, e precedente ad eventi determinati con certezza al di fuori dal nostro sistema (puntualizzazione necessaria perché rende impossibile ricreare una storia rendendola quantomeno coerente).

Questo per spiegare l'origine dei miei dubbi.

Diciamo che ogni documento ha un termine da cui ed un termine entro il quale va registrato,

questa è la chiave.

Se non ho capito male, stai dicendo che il termine di partenza è la data documento (scelta dal fornitore e presente dell'XML) e un termine che, dico per dire, potrebbe essere il giorno 15 del mese successivo alla data del documento. Quando il documento è stato effettivamente trasmesso, o ricevuto dallo SdI non conta.

Mi pare anche di aver capito che la data contabile è a discrezione dell'operatore, e non deve coincidere necessariamente con una data di un evento reale. Non è pertanto "robotizzabile". Una delle cose è cui serve è per la liquidazione IVA.

A questo punto ti chiedo: l'operatore può avere più motivi per scegliere una certa data piuttosto che un'altra? altri motivi oltre alla liquidazione IVA per dire? che possa avere la necessità di più date, per scopi diversi?

Te lo chiedo perché ho visto gestionali con data documento, data registrazione, data competenza iva, data competenza bilancio, tutte potenzialmente diverse e a discrezione dell'operatore (a parte data documento ovviamente).

[marco-marchiori]

Essendo che una data, per definizione direi, rappresenta anche una sequenza monotonica, ho sempre un dubbio quanto tale sequenza viene alterata. Per una deformazione professionale che vado male a spiegare, mi viene l'orticaria quando una data viene portata indietro,

Anch'io condivido un certo disagio a dover riprendere in poche parole dei concetti basilari delle teorie contabili che peraltro sono diverse e tendono a confondersi con la disciplina fiscale. In estrema sintesi da quest'altro punto di vista la data è semplicemente un valore che metto in una registrazione per poterla raggruppare. Se parliamo di "competenza" (per me superfluo/inesistente in campo IVA e comunque problematico) spesso la rilevazione per competenza si fa facendo delle pre-datazioni; alla fine anche l'agenzia delle Entrate, inventandosi il concetto di effettuazione ti obbliga a pre-datare dei documenti...

Mi pare anche di aver capito che la data contabile è a discrezione dell'operatore... A questo punto ti chiedo: l'operatore può avere più motivi per scegliere una certa data piuttosto che un'altra?

Si non è detto che non si possa meccanizzare tutto (né che l'immissione della data debba essere sempre "artigianale"), semplicemente se si vuole farlo si deve tener conto di tutti i casi e non credo sia facile. Molto semplicemente i motivi saranno quindi:

• il tipo di operazione
• quando avviene
• i termini di registrazione stabiliti da norme in senso lato

Una risposta il più precisa possibile alla domanda è: il più delle volte l'utente sceglierà la data idonea a far confluire gli importi in una certa liquidazione, e poi ci saranno dei casi in cui non potrà (non ha fatto in tempo, gli è sfuggita...) o non vorrà farlo (difficile prevedere tutto, ci sono ancora molte procedure interne o anche consuetudini), e ovviamente questo cambia sostanzialmente fra operazioni passive, di cui credo stiamo parlando, ed operazioni attive.

Te lo chiedo perché ho visto gestionali con data documento, data registrazione, data competenza iva, data competenza bilancio,

Certamente ad un certo punto si è diffusa questa consuetudine. Fermo restando che tutta questa dovizia di dati mi pare risponda (come spesso accade) a politiche commerciali (guarda quante date che ci ho io!) ci si può chiedere poi chi riesce davvero a mantenere una coerenza ed una controllabilità di tutti questi dati, dove poi se ci aggiungiamo la "data ricezione" potremmo inguaiarci in alcuni casi con l'amministrazione finanziaria. Si tratta di fare una sintesi:

• da che parte vanno le norme (quelle fiscali sono una parte)
• da che parte va odoo?

(ora devo interrompere, spero di non aver divagato troppo)

[francescapenso]

Io confesso che sto perdendo il filo del discorso e anche la soluzione del problema o della domanda che facevo io. Ho trovato questo https://www.melieassociati.it/fatture-di-fine-anno-la-detrazione-iva-3/

Io mi trovo nella situazione cosi descritta: fattura ricevuta a dicembre 2021 e registrata con data contabile 2022. In quale liquidazione iva periodica deve "ricadere" questo registro?

Nel testo citato si dice: Nel caso in cui una fattura, recapitata nel 2021, non venga, invece, registrata in tale anno, affinché sia possibile portare in detrazione l’IVA, l’annotazione dovrà essere effettuata entro il termine previsto per la dichiarazione IVA, ovvero entro il 30 aprile 2022 (che quest’anno cade di sabato, quindi il 2 maggio 2022), in apposito sezionale – o comunque con una tecnica che consenta di distinguerla dalle fatture “correnti”. L’IVA dovrà concorrere al modello IVA 2022 riferimento 2021, e non essere invece considerata nella liquidazione periodica del 2022, nella quale viene effettuata la registrazione.

Questo significa che non deve cadere nella liquidazione iva di gennaio, corretto? Come faccio a gestire questa cosa in ODOO?

La regola generale prevede quindi che la fattura ricevuta ed annotata entro il giorno 15 del mese successivo può essere considerata nella liquidazione del mese precedente, se l’operazione è stata effettuata in tale mese, ma l’ultima parte dell’art. 1 comma 1, del D.P.R. 23 marzo 1998, n. 100, stabilisce un’eccezione di fondamentale importanza: la disposizione non vale per i documenti di acquisto relativi ad operazioni effettuate nell’anno precedente.

Come faccio con odoo a far ricadere questo sezionale nella liquidazione dicembre 2021?

[marco-marchiori]

Come faccio con odoo a far ricadere questo sezionale nella liquidazione dicembre 2021?

A sistema esistente, come ho già più volte detto, datando la registrazione ("data contabile") dicembre 2021.

[francescapenso]

E per il futuro cosa possiamo inventarci per gestire questo modo che, a quanto capisco, è legittimo? Ovvero registrare nell'anno successivo? Ho capito correttamente che la teoria dice che puoi: -ricevere nel 2021 -registrare nel 2022 -far ricadere nella liquidazione iva dicembre 2021?

Il ven 11 mar 2022, 12:15 marco marchiori @.***> ha scritto:

Come faccio con odoo a far ricadere questo sezionale nella liquidazione dicembre 2021? A sistema esistente, come ho già più volte detto, datando la registrazione ("data contabile") dicembre 2021.

— Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-italy/issues/2655#issuecomment-1065017633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYDTJYYXPJVWXVLROPU7XTU7MTOXANCNFSM5OE33PJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[tafaRU]

Riapri pure nel caso il problema dovesse riproporsi.