search

OCA / l10n-italy

Odoo Italian localization
https://www.odoo-italia.org
GNU Affero General Public License v3.0
147 stars 303 forks source link

[RFC] Reverse charge: gestione nuovi codici TD16, TD17, TD18 e TD19 - Semplificazione modulo #1937

Closed eLBati closed 2 years ago

eLBati commented 3 years ago

Versioni coinvolte

Specifiche

Grazie all’introduzione delle nuove specifiche tecniche il processo conosce una sensibile semplificazione degli adempimenti. Il soggetto passivo che riceve una fattura elettronica senza evidenza dell’imposta, contenente un codice “natura” relativo all’inversione contabile (N6) potrà, infatti, a sua volta generare un documento elettronico contraddistinto da una delle nuove codifiche “tipo documento”. In caso di acquisto in reverse charge interno, l’integrazione dell’imposta potrà avvenire grazie alla creazione di un file XML con codice TD16 (“integrazione fattura reverse charge interno”) e inserimento dei dati del fornitore nella sezione “cedente prestatore” e di quelli del cliente – tenuto all’integrazione – nella sezione “cessionario committente”.

In nuovi codici consentono altresì di procedere, per via elettronica, anche agli adempimenti relativi al revese charge “esterno”. Sono state introdotte infatti le seguenti codifiche:

Posto che mediante l’adozione della procedura elettronica di reverse charge “esterno” i dati dell’operazione vengono comunicati al sistema di interscambio, tale modalità dovrebbe consentire l’esonero, limitatamente a tali operazioni, dalla presentazione dell’esterometro.

Implementazione

Il modulo l10n_it_reverse_charge non dvorebbe richiedere modifiche in questo senso; andrà solo configurato impostando Tipo partner = Altro e Partner autofattura = My company. Per semplicità si potrebbero anche inibire le altre opzioni.

Da valutare: in base a queste specifiche il metodo "Integrazione IVA", attualmente non implementato dal modulo, risulterebbe superfluo, in quanto, volendo comunicare a SDI gli XML relativi all'integrazione, l'oggetto autofattura attualmente generato dal modulo è quello che meglio si presta.

Per gestire correttamente la generazione di tali XML, potrà essere creato un modulo l10n_it_fatturapa_out_rc, dipendente da l10n_it_fatturapa_out e l10n_it_reverse_charge, che si occuperà di impostare, in caso di autofatture RC, il fornitore originale (recuperato dalla fattura originale presente nel campo Fattura acquisto in RC) e impostarlo come cedente/prestatore nell'XML. Inoltre dovrà essere impostato il corretto "tipo documento fiscale"; un'ipotesi è di associare il tipo documento al "tipo di reverse charge" (che a sua volta è associato alla posizione fiscale)

eLBati commented 3 years ago

https://github.com/OCA/l10n-italy/pull/2002

stevech091 commented 3 years ago

@eLBati nelle versione coinvolte andrebbero indicate anche la 10.0 e la 8.0. Puoi farlo. Grazie

eLBati commented 3 years ago

@stevech091 aggiunte assumendo che ci sia quindi qualcuno che se prenderà carico

stevech091 commented 3 years ago

certo come al solito farei lo sviluppo poi il backporter.

sergiocorato commented 3 years ago

Aggiungo altre specifiche relative allo stesso problema:

eLBati commented 2 years ago

Avendo fatto merge di https://github.com/OCA/l10n-italy/pull/2559 , vi risulta ci sia ancora qualcosa da fare su questo?

eLBati commented 2 years ago

A parte questo https://github.com/OCA/l10n-italy/issues/2552 per la 12

sergiocorato commented 2 years ago

A parte questo #2552 per la 12

Ho caricato la #2666 per la 12

TheMule71 commented 2 years ago

Avendo fatto merge di #2559 , vi risulta ci sia ancora qualcosa da fare su questo?

In effetti, sì. Ho avuto varie discussioni, e guardato quello che fanno altri gestionali, ovviamente esistono diverse interpretazioni, tuttavia, quella a cui sono giunto io, per quello che conta, è la seguente. Premetto che io ho fatto la PR per nascondere gli XML delle integrazioni (per es. TD17) che rimbalzano dallo SdI, con l'idea che non vanno importati.

Al riguardo ho fatto in questi giorni un 180°.

Ho configurato giusto ieri un'istanza completemente vuota (no demo) da zero. Il giro (non completo) che fa è:

Nel riepiloghi iva mi trovo correttamente una voce in 22% vendite (AF in uscita) e una in 22% acquisti (AF rientrata).

Al momento, fatta così, manca un pezzo, il risconoscimento automatico della AF in ingresso come tale, aggiustanto i conti (la riga non va messa come costo per acquisto prodotti, ma nel transitorio AF, simmetricamente a come fa AF emessa, che non usa il conto ricavi dei prodotti). Per semplificare si potrebbe pre-creare la AF in ingresso (con le entry tutte giuste) e invece di importare una fattura dall'XML ricevuto, collegarlo a quella preesistente.

Tutto ciò nasce da: image presente per i vari tipi di integrazioni qui: https://www.agenziaentrate.gov.it/portale/documents/20143/451259/Guida_compilazione-FE_2021_07_07.pdf/e6fcdd04-a7bd-e6f2-ced4-cac04403a768

dove viene ribadito, N volte, non tanto che ci devono essere due entry nei registri vendite e acquisti, ma che il documento integrativo (ossia il TD17 nell'es. sopra) va registrato due volte, senza se e senza ma. Ovviamente aggiungere l'IVA alla fattura orginaria (creare una entry nel registro acquisti), registrare il TD17 in uscita (creare una entry nel registro vendite) e ignorare il TD17 in ingresso, è equivalemente alla fine, le registrazioni sono due e nel posto giusto, ma non è al 100% conforme a quanto esplicitamente richiesto (doppia registrazione del documento integrativo).

Ne approfitto per aggiungere altre considerazione riguardo all'approccio generale. Il modulo rc, portato dalla 12, è ancorato alle vecchie logiche (crea reg. contabili al post della fattura). Non sarebbe male, almeno come tentativo esplorativo, spostare la logica alla creazione della fattura, in bozza (o al save in subordine, se più comodo). Ossia nel momento in cui creo la fattura in bozza e imposto il fornitore intra UE con pos. fiscale che implica RC, mi viene creata la coppia di AF (integrazioni TD17) corrispondente, ovviamente in bozza. In un mondo ideale, non modificabili, sono i cambiamenti fatti nella fattura originale che si propagano alla due AF.

L'enorme vantaggio di tutto ciò è che mi permetterebbe di avere un'anteprima di quello che verrà fatto quando posterò la fattura, cosa che al momento non esiste e costringe ad incrociare le dita sperando che la AF generata automaticame sia corretta (e la procedura per correggere è sofistica).

Ovviamente quest'ultima parte è un refactoring pesante, per questo lo definisco esplorativo, potrebbe esistere solo in ottica del porting alla 16, un po' come io ho implementato fatturapa_in con xmlschema e fatturapa_out con qweb sulla 12, ma in ottica 14.

stevech091 commented 2 years ago

@TheMule71 mi sta sfuggendo qualcosa sul giro. Tu dici che il reverse si "chiude" al rientro della seconda fattura (ossia quella ricevuta dalla SDI) ma secondo le impostazioni che attualmente abbiamo si dovrebbe chiudere già all'emissione dell'autofattura stessa a prescindere da quale tipologia di Reverse stai applicando.

Mi sta sfuggendo qualcosa?

TheMule71 commented 2 years ago

Come ho scritto, credo che al momento l'idea è che l'iva a credito viene aggiunta alla fattura originaria. In questo modo, il TD17 (non amo chiamarla AF in realtà, è un documento integrativo che non è una fattura, sebbene usi l'XML di fatturapa), va a chiudere con l'IVA a debito. Va da sè che così il TD17 di ritorno va ignorato.

Io sto proponendo di cambiare la configurazione, in modo da non alterare la fattura originaria (che essendo una fattura vera e propria trovo preferibile registrare as is, ossia come l'ha emessa il fornitore, con zero iva), e di aprire e chiudere coi due TD17, in modo da registrarli due volte, come richiesto.

eLBati commented 2 years ago

Io sto proponendo di cambiare la configurazione, in modo da non alterare la fattura originaria (che essendo una fattura vera e propria trovo preferibile registrare as is, ossia come l'ha emessa il fornitore, con zero iva), e di aprire e chiudere coi due TD17, in modo da registrarli due volte, come richiesto.

E hai già valutato cosa comporterebbe nei moduli questo cambiamento?

francescapenso commented 2 years ago

Per quel che vale il mio commercialista e altri due che ho sentito sostengono che con autofattura la ft orginale fornitore non va toccata aggiungendo iva ma va aperto e chiuso con due td17/18 (registrazione con doppio protocollo vendita e acquisti) seguendo la logica proposta da @TheMule71

TheMule71 commented 2 years ago

@eLBati Al momento, quello che manca l'ho scritto sopra. O si mette del codice in fatturapa_in, che riconosca il TD17 (o chi per esso), e in fase di Importa fattura crei l'omologo del TD17 originario (che ovviamente è facile da recuperare, il file è lo stesso), oppure, il modulo RC va modificato per creare due AF/TD17, uno vendite da trasmettere allo SdI, l'altro acquisti, a cui collegare l'XML che arriva dallo SdI.

L'operazione è la stessa, creare una AF/TD17 acquisti in modo corretto, da vedere quando farlo. Io, siccome il giro potrebbe aver senso vederlo completo senza coinvolgere lo SdI, metterei il codice in l10n_it_reverse_charge, e creerei le due registrazioni della AF/TD17 subito. Anche perché così assolvi istantaneamente all'obbligo di registrarla due volte.

Se vogliamo mantenere il comportamente precedente, io elimineri il tipo RC "integrazione" (vecchio stile) e creerei il nuovo tipo, "integrazione via SdI (TD1X)", con il comportamento descritto. Al post (per ora) si crea AF in uscita, che va esportata e inviata allo SdI, e AF in ingresso, alla quale collegare l'XML dello SdI quando arriva. Per chiarezza si userebbero i registri AFV (tipo vendita) e AFA (tipo acquisti).

sergiocorato commented 2 years ago

@TheMule71 concordo, questa mi pare la strada più semplice:

il modulo RC va modificato per creare due AF/TD17, uno vendite da trasmettere allo SdI, l'altro acquisti, a cui collegare l'XML che arriva dallo SdI. In pratica si registrerebbe la fattura del fornitore intra senza integrarla con l'IVA e si creerebbero direttamente le due AF ivate.

francescapenso commented 2 years ago

Al di la di un refactoring completo a mio avviso una soluzione "rapida" per ottenere il giro completo come descritto da @TheMule71 e @sergiocorato va fatta perché è operativa dal 1.1 e si risparmia esterometro

marco-marchiori commented 2 years ago

Allora a mio parere state infinitamente complicando la questione (già complicata di per sé). Prima di tutto va compresa la logica di quello che dice Agenzia Entrate che ha una base sul funzionamento dell'IVA definito anche da regole europee. Non basta prendersi un pezzettino di faq o guida o sentire l'amico commercialista per progettare un modulo che poi dovrebbero usare tutti.

--Premessa importante-- A mio parere il modulo RC e derivati non è soddisfacente e andrebbe totalmente rifatto, ma a partire dalla logica e dai casi d'uso.

--Fatta questa premessa ↑ La meccanica del RC è

Quello che si è (discutibilmente) deciso è ricorrere all'autofatturazione. Ed il contributo (di Takobi in questo caso) è stato quello di generare i TD a partire dall'AF.

Da questo punto di vista fare nuove registrazioni perché lo SDI mi recapita un documento che non ha alcun significato mi pare una follia.

Quindi

Ma trovo inaccettabile progettare moduli telefonando all'amico commercialista (che non sa come funziona odoo) o prendendo brandelli di risposte ministeriali.

eLBati commented 2 years ago

@TheMule71 concordo, questa mi pare la strada più semplice:

il modulo RC va modificato per creare due AF/TD17, uno vendite da trasmettere allo SdI, l'altro acquisti, a cui collegare l'XML che arriva dallo SdI. In pratica si registrerebbe la fattura del fornitore intra senza integrarla con l'IVA e si creerebbero direttamente le due AF ivate.

E utilizzando quindi un'imposta a 0 nella fattura passiva originale.

OK per me

a cui collegare l'XML che arriva dallo SdI

Questo quindi il sistema potrebbe farlo in automatico

TheMule71 commented 2 years ago

Questo quindi il sistema potrebbe farlo in automatico

Esatto. Potrebbe essere persino completamente trasparente all'utente. Già nascondiamo gli XML, si possono collegare cosi non risultano nemmeno da registrare.

marco-marchiori commented 2 years ago

dove viene ribadito, N volte, non tanto che ci devono essere due entry nei registri vendite e acquisti, ma che il documento integrativo (ossia il TD17 nell'es. sopra) va registrato due volte, senza se e senza ma.

Dove è scritto questo?

sergiocorato commented 2 years ago

Questo quindi il sistema potrebbe farlo in automatico

Esatto. Potrebbe essere persino completamente trasparente all'utente. Già nascondiamo gli XML, si possono collegare cosi non risultano nemmeno da registrare.

Ottimo, diventa anche più chiaro del sistema attuale, in quanto la fattura del fornitore resta intonsa.

marco-marchiori commented 2 years ago

il risconoscimento automatico della AF in ingresso come tale, aggiustanto i conti Cos'è l'AF in ingresso? L'AF è un documento che emetto io, che ingresso è?

marco-marchiori commented 2 years ago

Cerco di dare un ultimo contributo, anche se ribadisco che non mi sembra un modo adeguato ad affrontare il problema. Che in effetti non viene ben delineato. Io distinguerei due aspetti: 1) Il funzionamento di odoo, in effetti l'attuale procedura è pesante ed alla fine rappresenta l'iva acquisti nella fattura di acquisto, obbliga all'autofattura etc etc 2) il fatto che lo SDI mi rimanda il documento di integrazione (TD17, ad esempio) rappresentantomelo come fattura di acquisto

Allora del punto (1), che è evidente io ora non ho tempo di soffermarmi, bisogna studiare adeguatamente la questione. Certamente si può migliorare la contabilizzazione di questi documenti, tenere "pulito" il fornitore (come dice l'ignoto ed imperscrutabile collega) etc... Del punto (2) invece mi pare che una soluzione veloce, se proprio si vuole, sia associare l'XML che mi arriva alla fattura passiva del fornitore così com'è, in questo modo si associa il documento elettronico in uscita ad una ft di vendita e quello in entrata ad una ft di acquisto.

Può essere che sia divertente, ma ribadisco che affrontare le questioni senza descrivere ed analizzare adeguatamente i casi d'uso porta ad enormi costi una volta che si devono gestire i moduli sul campo.

TheMule71 commented 2 years ago

Prima di tutto va compresa la logica di quello che dice Agenzia Entrate che ha una base sul funzionamento dell'IVA definito anche da regole europee.

Come scritto sopra le registrazione IVA non cambierebbero. Ne avresti una in vendite e una in acquisti. Quello di cui stiamo discutendo qui è dove (in quali account.move) metterle.

Il comportamento attuale è:

  1. l'iva acquisti viene aggiunta alla account.move(1) la fattura originaria del fornitore intra UE (che però nella sua non ha messo VAT).
    1. l'iva vendite viene aggiunta alla account.move(2), l'autofattura che viene trasmessa come integrazione TD17 allo Sdi - si tratta di un documento anomalo in Odoo, una move di tipo out, in cui il partner sono io azienda. In fase di stampa, PDF e XML, vanno alterati i dati del C/P che altrimenti sarei io;
    2. dallo SdI arriva iun XML che va ignorato, e il documento integrativo viene registrato una sola volta (al punto 2)

Il comportamento proposto è:

  1. la account.move(1) è identica alla fattura emessa dal fornitore intra UE (tutto corrisponde al documento originale, imponibile, importo totale ecc)
  2. la account.move(2) viene creata identica all'attuale, con l'iva vendite - viene trasmessa allo SdI come adesso;
  3. viene creata la account.move(3), perfettamente a specchio della account.move(2), con l'iva acquisti
  4. all'arrivo dell'XML dallo SdI, questo viene collegato alla account.move(3), chiudendo il cerchio e realizzando la doppia registrazione del documento integrativo.

Io ci trovo vari vantaggi, oltre a recepire le indicazione AdE e uniformarsi al comportamento dello SdI. La riconciliazione sarebbe roba tra account.move(2) e account.move(3), e anche se fosse necessario necessario passare tramite pagamenti simulati, tutto sarebbe più semplice e chiaro perché avviene nello stesso istante e in modo perfettamente simmetrico.

Come ho scritto nel mio intervento originario, le registrazioni iva (le account.move.line()) sarebbero identiche. Solo i loro papà (account.move()) cambierebbero.

marco-marchiori commented 2 years ago

Cerco di spiegare. Non è che questa proposta non abbia dei vantaggi ma bisogna capire se:

A mio parere ci possono essere soluzioni ancora migliori ma vanno ben descritti i problemi. In questo caso abbiamo un apparente passo avanti dato dalla specularità di due registrazioni, ma non mi sembra comunque la cosa più efficiente. Ci sono dei vantaggi ma, vista così velocemente, mi pare di vedere almeno un punto debole.

Se c'è un problema bisogna prendersi il tempo necessario per studiarlo e discuterlo senza avere già una soluzione ricamata su un'urgenza.

Altrimenti ricadiamo nelle limitazioni e nelle farraginosità che già abbiamo nella soluzione attuale.

TheMule71 commented 2 years ago

Dove è scritto questo?

Ci sono i riferimenti nel post originale.

Cos'è l'AF in ingresso? L'AF è un documento che emetto io, che ingresso è?

Per "AF in ingresso" intendo la registrazione del documento integrativo nel registro acquisti. Per "AF in uscita" intendo la registrazione del documento integrativo nel registro vendite.

Deformazione professionale: da programmatore, io ragiono in termini di flussi. Il documento integrativo rimane uno, che emetto io. Sono le registrazioni che sono due. In termini di flussi: uno è l'XML, due sono le trasmissioni del medesimo, in uscita e in ingresso appunto. Non ho molta scelta qui: io devo trasmettere. E non decido io cosa ricevo. Che esista un flusso di ritorno è un dato di fatto.

Un altro dato di fatto è come altri gestionali implementino le stesse cose. Come sviluppatori, non si può semplicemente ignorare l'esistente. Gli utenti hanno certe aspettative. Possiamo dissertare all'infinito se in ogni possibile applicazione informatica la prima voce in alto del menu debba per forza essere 'File', ma rimane uno standard di fatto, e violarlo comporterebbe confusione da parte degli utenti.

Come scritto nel post originale, non mi sono limitato a fare il cut&paste di un pezzetto della "GUIDA ALLA COMPILAZIONE DELLE FATTURE ELETTRONICHE E DELL’ESTEROMETRO" dell'AdE (per altro, mi pare la cosa più ovvia come sviluppatore di sw che produce XML di fatture elettroniche far riferimento in primis a quel documento, così come alle specifiche tecniche dello SdI). O a sentire per telefono un amico.

Ho anche analizzato quello che altri gestionali fanno (più di uno). Farò un es., quello più divertente che ho trovato (gestionale su AIX con interfaccia a caratteri - probabilmente in grado ancora di funzionare con emulatione terminale via modem) correttamente manutenuto e adeguato alle norme attuali. https://adelsystems.it/documenti/Ni210016.pdf Tutto il documento è interessante, ma basta leggere il primo paragrafo delle osservazioni finali per capire che giro fa.

marco-marchiori commented 2 years ago

Ci sono i riferimenti nel post originale. Siccome nel documento che mi metti non lo trovo scritto, ti ho chiesto, magari sono distratto io.

marco-marchiori commented 2 years ago

Il punto è molto semplice. Se la community è fatta di soli programmatori che quando hanno un problema non informatico chiamano il cugino o lo risolvono individualmente, ok basta dirlo. Se invece anche i funzionali possono contribuire, allora le cose si devono fare con delle chiare analisi dei casi d'uso (che scritte in italiano o in inglese possono essere comprese dai funzionali) e prendendosi il tempo necessario, senza preconcetti. E quando si "fa fare" al sistema una cosa si ha ben chiaro il perché la deve fare. Con questo magari la tua soluzione è la migliore del mondo... mi dici che la fa anche microsoft! A livello di metodo ho bisogno di sapere però qual è per capire se vale la pena perdere tempo.

marco-marchiori commented 2 years ago

Il mio punto di vista, per come vedo la localizzazione adesso, è che, anche se ci sono molte funzionalità buone, tutti i problemi che ci sono derivano da cattiva analisi.

TheMule71 commented 2 years ago

Ci sono i riferimenti nel post originale. Siccome nel documento che mi metti non lo trovo scritto, ti ho chiesto, magari sono distratto io.

Perdonami, io apro il documento e faccio cerca della frase e la trovo. Comunque, la trovi in fondo alla sezione relativa al TD17, a pag. 11. La stessa dicitura è presente, relativa al TD18, a pag 13 (sempre l'ultimo paragrafo), e a pag. 15, relativa al TD19.

sergiocorato commented 2 years ago

Il mio punto di vista, per come vedo la localizzazione adesso, è che, anche se ci sono molte funzionalità buone, tutti i problemi che ci sono derivano da cattiva analisi.

@marco-marchiori Se vuoi fare una proposta alternativa, fai pure, non mi è chiara quale sia al momento. Se devi ragionarci sopra e adesso non hai tempo, dirai la tua quando ci avrai ragionato, oppure potrai aprire una issue se nel frattempo l'ipotetica PR fosse già stata mergiata (ma in genere ci vuole un po').

marco-marchiori commented 2 years ago

Quello che dico io è che si deve discutere apertamente chiarendo bene le cose prima di fare codice.

Edit: avevo fatto Edit al posto di Reply. Ripristinato.

TheMule71 commented 2 years ago

Se la community è fatta di soli programmatori che quando hanno un problema non informatico chiamano il cugino o lo risolvono individualmente, ok basta dirlo.

No, è fatta da programmatori che quanto hanno dubbi aprono delle issue marcate [RFC]. Oppure, aggiungono dubbi e proposte a RFC esistenti, come ho fatto io. RFC sta per Request for comment e letteramente è lo spazio per chiedere agli altri di commentare.

Se invece anche i funzionali possono contribuire, allora le cose si devono fare con delle chiare analisi dei casi d'uso (che scritte in italiano o in inglese possono essere comprese dai funzionali) e prendendosi il tempo necessario, senza preconcetti.

No. È esattamente il contrario. Sono i funzionali che dovrebbero fare le analisi. E sono loro che le devono scrivere in modo che i programmatori le possano comprendere.

Ma quando viene riportato un bug, il programmatore va anche, se necessario, ad approfondire e posta in una issue RFC per chiedere agli altri di commentare su quello che ha trovato e sulla soluzione proposta se ne ha una.

E quando si "fa fare" al sistema una cosa si ha ben chiaro il perché la deve fare.

Ti potrei rispondere, da programmatore, per risolvere quello che viene riportato come un bug.

Con questo magari la tua soluzione è la migliore del mondo... mi dici che la fa anche microsoft!

Che sia la migliore del mondo è irrilevante. Basta che sia meglio di prima. Si apre una PR per migliorare il software. Se dovessimo mergiare solo PR che rendono il software il migliore del mondo non avremmo nulla da fare. :)

A livello di metodo ho bisogno di sapere però qual è per capire se vale la pena perdere tempo.

Il perchè l'ho scritto in testa... a me basta un utente, uno solo, che si lamenti di un comportamento, e faccio una valutazione. Se la lamentela è infondata, l'utente va educato. Se è fondata, va approfondita. Se l'utente dice "io voglio fare le fatture elettroniche come dice la Guida dell'AdE", e come fanno gli altri gestionali, per me l'onere della prova passa a noi: o ci adeguiamo, o diamo una forte giustificazione del perché noi facciamo diversamente.

Questo è il caso in cui mi sono imbattuto.

marco-marchiori commented 2 years ago

No. È esattamente il contrario. Sono i funzionali che dovrebbero fare le analisi. E sono loro che le devono scrivere in modo che i programmatori le possano comprendere.

Bene sono pressoché d'accordo. Nel senso che non pretendo come funzionale di avere il monopolio dell'analisi. Ma se la fai tu devo aver modo (e tempo) di discuterla, e fare controproposte, non sentirmi dire "l'ha detto il mio amico commercialista". Altrimenti io ti potrei dire che non devi usare while ma for perché ho telefonato al mio amico programmatore. Perché? Boh. Come ho spiegato non si tratta di un bug: bisogna aver presente e seguire il problema che l'agenzia ha e vuole risolvere con queste "istruzioni" (che non sono norme), e dove vuole arrivare.

TheMule71 commented 2 years ago

Per come la vedo io, stiamo gestendo un programma. Il programma ha un output. Ad un utente quell'output non piace. A giustificazione, fa vedere la Guida dell'AdE per compilare la fattura el. (non è "problema" quello dell'AdE. É una guida alla compilazione.) Da ulteriore analisi, pare che altri software facciano quanto richiesto dall'utente, diversamente da noi.

Ho riportato alla comunità la cosa affinché commentasse e ho descritto eventualmente un modo per risolvere. Manco ho fatto la PR.

marco-marchiori commented 2 years ago

Ma io mica ti sto accusando di chissà cosa, pongo un problema di metodo. Ho detto semplicemente che se ci sono delle regole di buon senso per la community queste devono includere anche chi "dovrebbe" essere ascoltato in quanto funzionale (salvo urgenze e fretta) Ora in questi anni abbiamo avuto un sacco di input da utenti (o pretesi tali): arrotondamenti, date di registrazione, totali fattura, bilancio a sezioni contrapposte etc etc Se come dici stiamo gestendo un programma per cui delle ingenuità iniziali ricadono poi su tutti, allora dev'esserci un minimo di ragionamento (sono ancora incaxxato nero per quella cosa che è stata messa sui gruppi di conto rendendoli inutilizzabili). Altrimenti (non ti sto accusando di questo) un domani potrei dire che un utente interpreta così, il suo commercialista è d'accordo e questa dev'essere la soluzione per tutti. Non siamo una sola azienda.

Nel caso specifico non vedo rischi immediati di sanzioni per questo problema (salvo il solito terrorismo), quindi vale la pena discuterne.

TheMule71 commented 2 years ago

pongo un problema di metodo.

Quello che non vedo è proprio il problema di metodo. Se il metodo deve essere discutere prima di implementare, è esattamente quello che è successo e sta succedendo... e non vedo che c'entri tirare in ballo quello che è successo in passato.

Ammesso (e non concesso) che di solito succeda diversamente, perché tirare in ballo problemi di metodo proprio in quella rara occasione in cui il metodo viene seguito correttamente?

OpenCode commented 2 years ago

Per favore ritorniamo nei ranghi del problema in quanto funzione di un software e non il modo di discuterlo e affrontarlo. Per queste discussioni abbiamo altri momenti e altri canali. Usiamo gli strumenti giusti per il motivo giusto, per favore.

TheMule71 commented 2 years ago

E utilizzando quindi un'imposta a 0 nella fattura passiva originale.

Esatto.

Se vedi il flusso descritto prima, nella posizione fiscale del fornitore l'imposta del prodotto (es. 22% acquisti) viene cambiata in RC22%, che ha valore 0 (nonostante il nome). Tramite le impostazioni del tipo RC, nella AF viene messa a 22% vendite. L'avevo pensata cosi (ma è cosa di configurazione questa, quindi ognuno fa come gli pare), per due motivi.

Lo scopo di tutto ciò è attribuire al prodotto l'aliquota italiana. Mi pare più naturale usare lo standard Odoo, come campo del modello (eventualmente popolato da default). L'imposta è quella "naturale", che verrebbe usata as is se il prodotto fosse comprato da fornitore italiano. In questo la configurazione è standard.

Se abbiamo prodotti con aliquote diverse? Es. prodotto22 al 22% e prodotto10 al 10%? Mi piacerebbe che la cosa fosse automatica il più possibile.

Ecco che creo delle imposte con aliquota a zero, ma separate. RC22%, RC10% e imposto la mappa nella posizione fiscale (almeno quello è quello che mi sono inventato). Se inseriti in una fattura passiva con fornitore con quella pos. fiscale, automaticamente vengono tradotti in un'imposta con aliquota zero, ma si tiene traccia dell'originale.

Nelle mappa del tipo RC, avrò che RC22% viene ovviamente mappata su 22% vendite e RC10% in 10% vendite, e la AF automaticamente avrà le aliquote giuste in base all'imposta originale presente sul prodotto. L'utente non deve toccare nulla.

Quindi 1) attribuzione naturale dell'imposta del prodotto (chi lo fa non sa nulla di RC) 2) traduzione automatica nella corrispondente iva vendite nell'AF

Non credo di aver inventato nulla di nuovo, è solo per chiarire come è fatto il flusso esemplificativo.

marco-marchiori commented 2 years ago

Per favore ritorniamo nei ranghi del problema in quanto funzione di un software e non il modo di discuterlo e affrontarlo.

Fantastico: se uno vuole discutere l'altro dice che si deve trattare altrove come discutere. Mi pare che sia un modo (inelegante) per dire che non vi interessa quello che dico. Fate quello che volete. Non date poi la colpa ad odoo se le localizzazioni non vanno.

sergiocorato commented 2 years ago

Per favore ritorniamo nei ranghi del problema in quanto funzione di un software e non il modo di discuterlo e affrontarlo.

Fantastico: se uno vuole discutere l'altro dice che si deve trattare altrove come discutere. Mi pare che sia un modo (inelegante) per dire che non vi interessa quello che dico. Fate quello che volete. Non date poi la colpa ad odoo se le localizzazioni non vanno.

@OpenCode si riferiva al fatto che la discussione non è attinente a questa RFC.

Frasi del tipo Ma io mica ti sto accusando di chissà cosa, pongo un problema di metodo. sono chiaramente una critica al modo di lavoro della Community.

marco-marchiori commented 2 years ago

Riporto qui il commento di @TheMule71 ricevuto in discord che non vedo qui.

Quello che dico io è che si deve discutere apertamente chiarendo bene le cose prima di fare codice.

E mi spieghi con quale logica postare in una issue marcata RFC non conta come "discutere apertamete chiarendo bene le cose"?

Allora, fermo restando che non ho certo criticato la RFC ma ho semplicemente fatto i miei commenti all'interno, fra l'altro concordando su alcune cose che dici:

1- La RFC è aperta su un modulo marginale (quello che serve per i TD16..19 2- Da questo vi siete guardati un po' di materiale agenzia entrate e vi siete consultati 3- Alla fine proponete (e anche su questo nel merito concordo, almeno in parte) di cambiare più in generale il funzionamento del modulo reverse_charge (documenti, procedure, scrittura), che non è l'oggetto della RFC, che diventa "refactoring del reverse charge". 4- Ora, a fronte di alcuni vantaggi della soluzione proposta, che potrebbe andare bene, mi sembra che ci siano anche alcuni problemi, che normalmente io non riesco ad affrontare in un'ora 5- Ma anche sul piano strettamente informatico-procedurale (senza parlare di fisco) mi pare bisogna confrontare la soluzione AS IS con quella TO BE, sicuramente ad esempio un vantaggio della tua proposta è che avremmo tre scritture invece che quattro.

Quindi non è che ti ho detto tutto il male possibile, solo che ci sono alcune complicazioni e ho chiesto una certa cautela nelle letture, interpretazioni e nelle conclusioni, visto che poi ci dobbiamo lavorare tutti. Con questo, fermo restando che tutti possono sbagliare, rimane la mia difficoltà nel discutere della mia materia con personaggi ignoti, fantomatici clienti/utenti, sentito dire quindi, come ripeto per me che ho cercato di contribuire, a questo punto è meglio non coinvolgere il funzionale che farlo in questa maniera.

marco-marchiori commented 2 years ago

Frasi del tipo Ma io mica ti sto accusando di chissà cosa, pongo un problema di metodo. sono chiaramente una critica al modo di lavoro della Community.

Non si può criticare? Cos'è una chiesa la Community? Se in un thread secondo me non si sta seguendo il metodo (la strada giusta) lo dico. Volete espellermi? Volete scrivere "radiato dalla community"?

eLBati commented 2 years ago

@TheMule71 Aggiungo che il meccanismo basata sulla "autofattura passiva aggiuntiva" sarebbe già previsto dal modulo:

https://github.com/OCA/l10n-italy/blob/c810de890922ffd5d161e6a843c075f363f2a422/l10n_it_reverse_charge/models/account_rc_type.py#L50

Quindi penso si possa sfruttare.

@marco-marchiori Più che altro mi sembra che non ci capiamo su cosa proponi di fare o come proponi di procedere. Per questo concordo con @OpenCode sul cercare di chiarirci in altri canali magari a voce.

marco-marchiori commented 2 years ago

@marco-marchiori Più che altro mi sembra che non ci capiamo su cosa proponi di fare o come proponi di procedere. Per questo concordo con @OpenCode sul cercare di chiarirci in altri canali magari a voce.

come ho detto non sono ad una prima lettura convinto che sia la soluzione migliore, non è che posso fare controproposte in tempo reale (specialmente se devo giocare a ping pong su ogni cosa, e non è una critica)