Concordo. Aggiungo che non si può giustificare la scelta dicendo che “si sarebbero persi posti di lavoro”. La tecnologia cancella posti di lavoro, pensiamo ai magazzini oramai automatizzati, é inevitabile. La Politica deve gestire questo processo, non può pensare di bloccarlo.
Non dico di abolirli gli RT; se in un punto vendita non viene usato un PC con gestionale allora è ovvio che la soluzione è l’RT. La cosa che mi fa venire l’ulcera è precludere, quasi per principio (ma forse più per malafede), lo sviluppo di scenari di gestione aziendale più al passo con i tempi, più efficienti. Il mondo del lavoro dovrebbe essere per principio flessibile e non ci dovremmo tanto scandalizzare se certe prestazioni diventano di colpo non più richieste. Poi, la grande bugia che si sente dire è :Non c’è lavoro ! Come ?? Siamo circondati da tanti di quei disastri e cose da aggiustare che pur impiegando tutta la popolazione non riusciremmo a venirne a capo. Forse sarebbe più corretto dire non ci sono investimenti. Il lavoro non manca mai, sono i grandi mostri (grandi aziende) che determinano la mancanza d’impiego e il disagio sociale. E gli stati, i legislatori ? Ai loro comandi, piegati ai loro interessi.
Il lavoro c’è, va solo finanziato.
Il falso problema che ho visto evidenziare anche in altre sedi, che vorrebbe meno sicuro e più soggetto a manomissioni un PC rispetto ad un RT è facilmente risolvibile implementando per esempio archivi criptati.
Poi siamo sicuri che oggi non ci sia nessuno in grado di manomettere un RT ? 
Infine, per quanto riguarda invece la privacy lo sanno anche i bimbi che quando si scelgono i providers bisogna fare attenzione; e comunque in materia esistono delle leggi e le violazioni sono perseguibili anche penalmente.
Io sono convinto di una cosa :Ancora, specialmente in Italia, non si è capito di che portata è la rivoluzione digitale; ma atteggiamenti come quello che l’istituzione ha assunto in merito alla trasmissione degli scontrini, mi inducono a credere che viviamo un periodo molto ma molto buio.
Porca vacca !
1 Mi Piace
La Politica ! La politica deve trovare (finanziare) il lavoro invece di buttarli i soldi e complicare la vita ai cittadini più deboli.
Non so quale sia la strada migliore, ma di sicuro in Italia ci sono tante realtà differenti.
chi usa solo la cassa senza un PC
chi usa il PC con la cassa
chi usa solo il PC perché ha deciso di far solo fatture.
chi non usa né cassa, né PC, ma fa ricevute su carta prestampata (cosa che sparisce con l’obbligo del RT)
I dati possono essere conservati sul PC della vendita, su un server aziendale o su una soluzione in Cloud.
E poi cambia a seconda del tipo del quantitativo di lavoro che l’azienda svolge. Se si fanno 10 / 15 ricevute al giorno è gestibile usare l’applicazione web. Se ne fai 200/300 al giorno non è il caso.
Non dimentichiamoci che i controlli maggiori vengono fatti sui negozianti al dettaglio.
Senza un RT, i dati vengono inserti in un PC o in un DB che non è detto questi vengano inoltrati dopo la vendita oppure che vengano modificati e poi inoltrati.
Cosa differente con un RT dove quello che stampi viene inoltrato.
E’ vero che probabilmente un RT può essere alterato (quello che l’uomo crea lo può anche modificare) ma è anche vero che in caso di controllo non superi la cosa indenne. Se alteri invece dati in un software interno prima di inviare l’informazione, nessuno lo sa.
In alternativa, si può pensare di fare solo fatture. che tra l’altro rendono più facile la gestione dei rientri/errori
Forse qualche speranza di fare un software e lasciare gli RT c’è … l’Ade con Assosoftware si stanno attivando…
https://www.agendadigitale.eu/documenti/soluzioni-software-per-i-corrispettivi-telematici-quali-vantaggi/
Ciao Sara87, ti ringrazio per il tuo link che mi da un grande conforto. Visto, non lo dico solo io…una soluzione software sarebbe ancora più sicura di quella hardware. Se io fossi l’AE farei così (in linea di massima) Metterei a disposizione (anche dietro il pagamento di un piccolo canone) una dll da referenziare nel codice di un gestionale. Questa dll esporrebbe un formato di scontrino, una funzione di emissione scontrino, una funzione di trasmissione scontrini. Prima di essere utilizzata questa dll andrebbe configurata con una stampantina (50€) visibile solo da questa dll (nessuno potrebbe stampare su di essa) per la stampa cartacea dello scontrino. Ma farei di più : distribuirei anche un App per telefonini che chiamerei "I miei scontrini’ ad uso di chi acquista, che tramite blutooth o via wireless, o via chissacchè, fosse in grado di registrare uno scontrino sempre emesso da questa dll. Ciò per evitare proprio la stampa del cartaceo.
…ho dimenticato di dire che gli scontrini da trasmettere verrebbero salvati sempre dalla dll rilasciata dall’AE, sul pc in un archivio criptato.
la vedo dura fare una cosa del genere.
e comunque stai immaginando al costo mensile/annuale di x, qualcosa di più complicato che non spendere 500 euro per una cassa RT.
Attualmente il sistema dell’agenzia prevede che l’informazione vada al RT e l’RT che ha un certificato all’interno si preoccupa di fare la spedizione. se non la fa subito la fa il giorno dopo.
Mandando un XML firmato, con i parametri del registratore fiscale, in modo da garantire la corretta attribuzione.
Potenzialmente potresti avere 1 stampante condivisa per 2 postazioni.
Quello che proponi te è avere per ogni stampante da 50 euro, un computer con una dll che scrive su un HD pubblico salvo che quella DLL non la installi su un server dedicato protetto da password e dati totalmente criptati con responsabilità di chi gestisce la struttura aziendale.
questo fa si che oltre ai 50 euro della stampante hai il costo di un PC/server.
Ma la parte più soggetta a problematica, penso sia l’impossibilità di garantire che il dato comunicato sia uguale a quello effettivamente gestito.
Vi espongo la cosa.
Attualmente lo scontrino è obbligatorio quindi in teoria tutti i clienti ne avranno uno, a maggior ragione con la lotteria degli scontrini.
Il sistema attuale prevede che il negoziante invia il dato al RT, che stampa il documento commerciale e quello stesso documento viene inviato. Non c’è possibilità che il dato consegnato al cliente e quello comunicato all’agenzia delle entrate sia differente (salvo che non apri in qualche modo l’RT e modifichi la memoria fiscale).
Per usarlo, basta un qualsiasi PC o smartphone, con un gestionale in grado di comunicare con la cassa, oppure il negoziante che digita a mano lo scontrino.
Quindi, una volta attivata, zero stress.
Usando una libreria si è obbligati ad avere sempre un PC (quindi niente solo cassa)
inoltre il programma invia i dati alla DLL (nel server/pc ) che comunica direttamente e solo una stampante termica (una stampante termica ha un id hardware ma non dovrebbe avere matricola univoca )
La connessione però avviene a livello software da chi farà il collegamento, a meno che l’agenzia delle entrate non sviluppi una DLL in grado di comunicare con tutte le stampanti (la vedo dura).
Questo significa che il dato può essere intercettato e modificato.
In pratica potrei mandare alla DLL uno scontrino da 100 euro e poi stamparne uno da 150.
La DLL ovviamente va configurata, ma come garantisci che la DLL installata su quel PC è di quell’azienda e non è qualcuno che ha imputato una partita iva differente?
Anche se la DLL in qualche modo fosse resa remota e non fosse fisicamente installata su un pc locale del negoziante, comunque lei ritorna un dato in chiaro (proprietario o XON/XOF) da inoltrare al registratore e quel dato è facilmente intercettabile.
A mio parere, anche se può sembrare un’ottima soluzione, non coprirebbe l’immutabilità richiesta da ADE e richiederebbe molto più lavoro.
Praticamente sposterebbe il costo che il negoziante deve pagare di 400<->800 euro del RT verso la software house che deve organizzare il tutto. al negoziante finale non cambierebbe nulla.
probabilmente potrebbe funzionare in parte per quelle struttura che usano un gestionale installato fisicamente nel pc locale ma per modifica del gestionale avranno comunque dei costi.
Ma soluzioni totalmente web che girano su browser, non credo riescano a gestire la cosa.
Ovviamente o solo una mia piccola opinione.
Specie se consideriamo che in caso di scontrini manuali (cassa o internet non disponibile), non c’è alcun controllo di sorta e quanto detto sopra non ha valore. In quel caso non serve nemmeno una DLL perché basterebbe preparare a fine giornata un XML firmato in stile fatture con i dati scontrini.
Ma questo è un metodo che l’agenzia delle entrate a riportato come temporaneo o solo per emergenze.
Il problema è che qualsiasi software (che sia una dll o altro) che gira sul PC dell’esercente è manipolabile. Il motivo dell’obbligo del RT è che si tratta di un dispositivo hardware la cui memoria, almeno in teoria, non può essere manipolata dall’utente.
L’unica soluzione possibile che vedo io è che l’AdE metta a disposizione una API corrispondente all’attuale inserimento manuale via web. I dati della ricevuta andrebbero inviati immediatamente all’AdE e quindi non più modificabili.
Ovviamente questo non risolve il problema della stampa dello scontrino. L’esercente potrebbe fare una stampa farlocca senza mai veramente inviare i dati all’AdE. Ma questo problema c’è già adesso con la procedura web che, da quello che ho capito, verrà mantenuta anche dopo il periodo transitorio.
L’idea della APP è buona, ma io la farei con due funzioni diverse:
- Per gli scontrini con il codice fiscale (per la lotteria), permette di scaricarli direttamente dai sistemi dell’AdE e visualizzarli.
- Per gli scontrini senza codice fiscale, permette di verificarne la validità (però dovrebbero avere tutti il codice QR affinché sia agevole da usare).
Signori se si potesse emettere un documento commercialie (ex “scontrino fiscale”) via API con un gestionale tutto il mercato dei misuratori fiscali andrebbe a decadere facendo perdere migliaia di posti di lavoro.
Ovvio che in un “modo perfetto” sarebbe la soluzione ottimale, ma non si può fare; non per motivi tecnici ma per motivi, diciamo, politici ed economici
Buonasera, anche io gestisco e creo un gestionale per la mia attività personale e sono qui proprio perché volevo capire come integrare lo scontrino elettronico in esso, senza la necessità di acquistare un RT.
Con questo strumento (gestionale) e il tipo di lavoro che faccio (servizi) ho la possibilità di eseguire in tempo reale la sottrazione dei costi meno i ricavi e sapere le mie effettive risorse economiche a disposizione. Velocizzando anche l’uscita della fattura collegata al servizio per il quale è entrata la persona.
Con l’ingresso di alcune api io non sarei costretto ad acquistare il registratore telematico, ed a inserire nel mio negozio uno strumento a mio avviso inutile.
Al momento con un semplice computer (che esegue infinite volte più operazioni e migliora la gestione della mia attività) posso e potrei effettuare la stessa cosa che effettuo con un RT.
Sì ridurrebbero, come è stato detto sopra, l’ingresso di tecnologia già obsoleta, e si inizierebbe a sviluppare la possibilità di stampare ed emettere scontrino con un semplice tablet e stampante termica.
L’affitto di un gestionale del genere si aggirerebbe intorno ai 20/30 euro mensili con un miglioramento dell’azienda in se.
Al contrario sarò costretto ogni sera ad effettuare doppie operazioni per tenere traccia dei miei ingressi. Insomma? Fa male a chi produce ancora RT che possono essere sostituiti da Tablet già prodotti? Mi dispiace ma qui si inquina(producendo hardware che può essere sostituito da un buon software( come produrre una calcolatrice quando TUTTI abbiamo smartphone che fa la stessa cosa)) e si resta fermi al primo registratore di cassa.
Per chi dice che sarebbe facile fare uno scontrino da 100 anziché da 150 rispondo che sarebbe altrettanto possibile con un qrcode verificare (da parte di chi ha ricevuto lo scontrino) la veridicità della transazione dello scontrino a fine serata, semplicemente seguendo un link.
Edit:
Per quanto riguarda invece la fatturazione elettronica esistono delle API?
il problema non è impedire che tu faccia uno scontrino e poi ne dai un altro, ma impedire che lo scontrino che dai in mano al cliente sia diverso da quanto tu comunichi all’agenzia delle entrate.
Di certo non puoi pensare che il controllo avvenga da parte dell’utente finale (l’unico che sa), e che per ogni scontrino ricevuto vada a riportare sul sito internet un ipotetico codice per verificare se il dato imputato sul documento commerciale corrisponda a quanto tu hai dichiarato all’agenzia delle entrate.
Questo controllo per la fattura è semplice perché questa viene data all’agenzia delle entrate e l’agenzia delle entrate la consegna al cliente.
A parte che 30 euro mese di un gestionale mi sembra esageratamente basso, proporzionalmente sarebbe come comprare della fiorentina al ristorante a 15 euro al kg.
Per quanto riguarda i costi degli RT…
Un registratore RT economico della olivetti collegabile direttamente al PC e che quindi ricevere gli scontrini direttamente dal gestionale, costa sui 350 ivati
Lo stato mette a disposizione un contributo del 50% (max 250 euro) per l’acquisto di un nuovo registratore di cassa. quindi vuol dire che un registratore di cassa ti costa 175 euro ivati.
Vuoi dirmi che spendere 350 euro ivati, di cui una detrai l’iva, e 175 ti tornano indietro come bonus dallo stato è una spesa esagerata per una attività commerciale ? saranno si e no 100/150 di costo effettivo.
considerando comunque poi, che al cliente poi devi dare in mano un pezzo di carta,
e mediamente un rotolino di carta ha un costo medio per ricevuta inferiore alla carta stampata
1 Mi Piace
Giusto per capire esiste quindi un registratore telematico che posso collegare al PC e quindi al mio gestionale con delle api che mi permettano di emettere scontrino da mio PC?
Il discorso che faccio io è:
La tecnologia che viene utilizzata, a mio avviso è possibile bypassarla con un buon software e senza la necessità di introdurre un nuovo strumento che come ho detto è già obsoleto e potrebbe essere sostituito da una semplice stampante termica e tablet. Abbattendo così di molto sia i costi che gli sprechi.
praticamente il 90% dei registratori telematici hanno una connessione USB o ethernet o BT che tramite un linguaggio più o meno standard (XON/XOFF, Sarema language, proprietario, ecc…) permettono di inviare i dati dal gestionale al RT.
del resto un RT è una stampante termica con la sola differenza che ha una memoria fiscale e non modificabile.
Ci sono programmi che costano un centinaio di euro che fanno da interprete per le varie casse.
quindi installandolo sul PC, non devi far altro che creare un file TXT con i dati dello scontrino (data, numero, descrizioni, importo pagato e modalità di pagamento) al salvataggio dello scontrino.
quello che vuole l’agenzia è che , quello stampato(consegnato al cliente) non possa essere alterato rispetto a quanto comunicato.
il RT lo fa.
Dal PC invii il dato al RT, l’RT lo stampa e lo salva sulla sua memoria fiscale, a fine giornata l’RT recupera i dati dalla sua memoria e li invia autonomamente all’agenzia delle entrate.
Quindi quello che stampi è effettivamente quello che invii
Se usassi un’API.
il gestionale manda in stampa alla stampante termica.
a fine giornata il gestionale manda via gli scontrini presente nel gestionale, tramite API.
Nel frattempo, prima di procedere, potresti modificare lo scontrino a livello di DB, quindi quello che invii è diverso da quanto stampato.
Oppure.
genero lo scontrino sul gestionale con un importo di 100 euro
mando lo scontrino all’agenzia delle entrate
modifico lo scontrino aggiungendo l’articolo mancante
stampo lo scontrino.
IN pratica non hai un modo per garantire che la stampante termica stampi quello che ha inviato all’agenzia.
Un programma non è qualcosa che “sigilli”, specie ora che si fa tutto tramite WEB.
e puoi comunque cancellare le tracce agevolmente.
Viceversa un RT ha un sigillo /piombatura che inibisce eventuali modifiche meccaniche.
Probabilmente si può modificare pure quella ma è molto più complesso e probabilmente evidente.
Sinceramente non vedo molte soluzioni se non che sia l’agenzia delle entrate a stampare… ma allora dovresti avere una stampate termica costantemente collegata ad internet, registrata presso l’agenzia delle entrate in modo che la identifichi in maniera univoca.
ma a questo punto fai prima a comprare un RT.
l’alternativa è abbandonare lo scontrino e farlo solo digitale.
l’agenzia delle entrate dovrebbe creare un’APP per cellulari o portale di accesso web ( ed obbligare tutti ad averla installata in caso di controllo della finanza per dimostrare che ti hanno fatto lo scontrino.), dove radunare tutti gli scontrini tramite codice fiscale. In questo modo potresti controllare l’invio diretto da gestionale ad agenzia delle entrate.
Questo però comporterebbe predisporre una piattaforma più grande di quella delle fatture.
Non funzionerebbe in carenza o mancanza di internet.
Mentre un RT puoi usarlo tranquillamente in locale e a fine giornata, mettere in hotspot il pc (o la cassa se ha connessione wifi) e far inoltrate quei 100kb di scontrini.
tra l’altro con i costi nazionali… un progetto simile costerebbe milioni di euro che poi verrebbero comunque prelevati tramite le tasse.
Quindi probabilmente è più semplice (sia economicamente che strutturalmente) usare roba “datata” che costa 150 <->400 euro una tantum + 80 euro al cambio memoria ogni XX anni
Noi abbiamo sviluppato un API (Web Service REST) per l’emissione del Documento Commerciale on-line, cioè il documento che si può creare alla seguente pagina: https://ivaservizi.agenziaentrate.gov.it/ser/documenticommercialionline
L’API fornisce in risposta il Numero progressivo univoco assegnato dall’AdE e il file PDF generato dal portale Fatture&Corrispettivi.
L’API permette di cercare i documenti commerciali precedentemente emessi, anche tramite il portale, e di scaricarne i relativi PDF.
Con analoghe API di nostra produzione è possibile interfacciarsi anche con la soluzione transitoria, così come con l’area Fatture emesse e ricevute.
1 Mi Piace
Stavo facendo la stessa cosa anche io, solo però ad uso interno e semplificato (l’operatore avrà solo un set molto limitato di funzionalità nell’applicativo).
Ho già identificato le chiamate da fare, gestione cookie ecc.
Volevo chiedere come ti sei comportato per fare i test: hai creato i documenti commerciali e poi li hai annullati? Non ho visto la possibilità di creare dei documenti di prova.
Nel mio caso il software andrà a sostituire le ricevute fiscali (in media emessa 1 a settimana).
Si, ho annullato i documenti emessi in fase di test. Per chi fosse interessato, forniamo l’accesso a quota fissa alla nostra API, in cloud o con codice sorgente disponibile per l’installazione sui propri sistemi.
Nel mio caso ho già fatto tutto, mi mancava solo testare.
Spero che non cambino spesso le chiamate per fare i documenti, visto che non sono ufficiali.
1 Mi Piace
Ciao, come vi trovo?
Siamo molto interessati all’argomento e cercavamo da tempo qualcuno che sviluppasse
questa connessione.
Potete contattarmi via mail a marco.marsala@live.it o tramite messaggio privato. Abbiamo a disposizione una demo.