menu di navigazione del network

Come e' possibile lavorare cosi' MALE?


(Romolo Manfredini) #21

Personalmente ho trovato imap semplice perchè avevo già delle classi per leggere caselle IMAP realizzate in progetti precedenti…
Con GMAIL e le API di google avrei dovuto riscrivere qualche riga di codice.

Per l’invio o la ricezione di un solo soggetto fiscale, trovo che accreditare un canale sia eccessivo… (diverso se di soggetti fiscali da gestire ne hai qualche migliaio)


(Silvio Sosio) #22

be’ certo, se lo hai già fatto è anche meglio.
L’unico aspetto negativo dell’usare la pec è che ogni fattura che mandi sei sommerso da altre email… la conferma di spedizione, la conferma di ricezione, la conferma che oggi è lunedì, la conferma che hai ricevuto la conferma… meno male che non è carta. Qualcuno dovrebbe calcolare l’impatto ambientale del consumo di energia di tutto questo giro di email.


(Romolo Manfredini) #23

Non è molto diverso con altri metodi, alla fine la ricevuta e l’esito ce li hai anche con SDICOOP e SDIFTP…


(Lorenzo) #24

Io non capisco perche’ il resto del mondo utilizza chiamate REST autenticate per qualsiasi cosa, invece qua si sono dati 3/4 modi di fare le cose (webservice, pec, ftp, sito ade) uno piu’ improbabile dell’altro.

Utilizzare il ftp o webservice non e’ una cosa normale per un servizio che nasce nel 2019, ed una delle cose che piu’ mi spaventa e’ che questa inadeguatezza non venga percepita dai programmatori presenti qua. QUESTO e’ il vero peccato. Un paese rimasto indietro di anni anche nell’informatica e’ il top dell’assurdo!


(Vladan Bato) #25

Oggi voglio essere polemico. Perché usare SOAP invece di REST? Perché SOAP è uno standard. REST no. Cito da wikipedia:

Unlike SOAP-based Web services, there is no “official” standard for RESTful Web APIs. This is because REST is an architectural style, while SOAP is a protocol. REST is not a standard in itself, but RESTful implementations make use of standards, such as HTTP, URI, JSON, and XML. Many developers also describe their APIs as being RESTful, even though these APIs actually don’t fulfill all of the architectural constraints described above (especially the uniform interface constraint).


(AndreaV) #26

Non sono d’accordo con quando affermi… le cose ‘moderne’ non per forza vanno meglio di quelle vecchie. Ci sono cose vecchie che vanno ancora benissimo, magari con qualche adeguamento… basta guardare il TCP/IP che ha qualche annetto…

Poi onestamente se una nazione si deve dare una procedura, credo che sia sensato darsela su degli standard, anche se questi non sono ultra moderni.


(Romolo Manfredini) #27

Onestamente preferisco SOAP, ma anche FTP su ssh ha un senso per chi scambia qualche decina di migliaia di fatture alla volta (ed infatti ho scelto quello).
Poi il problema non è lo standard scelto ma quanto fai funzionare quello che hai implementato.
Ho visto fantastiche applicazioni modernissime piantarsi, od essere hackerabili più di applicazioni vecchie scritte con cervello. (il software delle sonde vojager è un bell’esempio dato che gira su 70kb memoria dal 1977 ma se cerchi bene anche quello della contabilità del DOD USA non scherza… cerca MOCAS su internet per capire di cosa sto parlando)
Comunque, per rimanere in topic, quello che non va in questo sistema non dipende dal protocollo di interscambio ma da quello che avviene all’interno del SDI stesso.
Quello che mi spaventa è che ci siano tanti programmatori che non riescono a capire le cause dei problemi nei sistemi e che confondano nuovo con funzionante.
Personalmente non avrei avuto problemi ad usare uno qualsiasi dei tre protocolli proposti e neanche chiamate REST, ho fatto una valutazione di traffico e ne ho scelto uno, adesso vorrei che funzionasse.


(Davide How) #28

Lorenzo ti posso dare ragione su quasi tutto: il livello della documentazione, la mancanza di tool open-source e messi a disposizione del popolo (quelli che ho visto erano delle versioni… alfa), l’assenza di frammenti di codice di esempio per i vari linguaggi. E pure a me la roba dell’ftp mi è sembrata parecchio anomala… non ho presente altri casi in cui se io ti devo mandare dei dati, tu mi chiedi l’ftp; nell’universo la normalità sono i ws (soap o più frequentemente REST).

Però non c’è bisogno di fare polemica su tutto: XML/SOAP sono standard solidi, espressivi e documentati. Sono supportati da tutti i linguaggi, e il loro ciclo di vita sarà lunghissimo.
XML è un formato con vari strumenti per il versionamento, il parsing, la validazione e la visualizzazione: un ecosistema di tool probabilmente superiori a JSON, indispensabili nella manipolazione di dati complessi.


(Romolo Manfredini) #29

Di esempi con FTP o cartelle di scambio dati te ne potrei portare a iosa ancora in produzione soprattutto in tutti quei casi dove esistono processi asincroni e/o i due sistemi che devono comunicare sono isolati fra loro ed usano un server SFTP come contenitore di scambio.
Nella mia esperienza lavorativa li ho visti dalle applicazioni industriali a quelle militari passando per alcune applicazioni del sistema interbancario.
La logica è: il sistema A fa il suo lavoro e lascia al sistema B la decisione di quando fare il suo e viceversa, senza doversi preoccupare di dover informare ogni volta il sistema B che potrebbe in quel momento non rispondere (e che quindi andrebbe ricontattato in seguito) che c’è del lavoro da fare.
Quando B ha finito comunica ad A il risultato.
Sono due processi in poll su A e B che determinano la frequenza di elaborazione e fintanto che la casella di interscambio è disponibile ad A e B un blocco di A o di B non causa problemi al sistema.
(al massimo si allungano delle code).
Se ci pensi bene per un applicazione come la fatturazione elettronica può funzionare perfettamente:

  1. L’intermediario prende le fatture dai clienti e le aggrega per SDI mettendole in una cartella.
  2. SDI controlla in poll (con le sue tempistiche) se ci sono fatture e se le porta in pancia e le elabora sempre con le sue tempistiche
  3. SDI prende i risultati e le fatture per l’intermediario le aggrega e le trasferisce via SFTP (a questo punto per SDI il lavoro è finito)
  4. L’intermediario prende i risultati e se li elabora quando vuole.

Nessuno dei punti sopra è bloccante purchè il nodo SFTP sia raggiungibile ed inoltre consente l’invio massivo di fatture e risultati da parte di entrambi i soggetti. Inoltre è facilmente difendibile da DDOS ed accessi indesiderati (due regole di firewall e due certificati sul server SFTP sono più che sufficienti).
E’ moderno ? Probabilmente no…
E’ funzionale ? Probabilmente in molti casi si…
Garantisce risposte realtime ? No… come molti altri sistemi, (es posta elettronica od altri)
Sono necessarie risposte realtime ? A mio giudizio no, del resto lo stesso sistema SDI si da delle SLA dell’ordine di 5gg (che attualmente non rispetta).


(Davide How) #30

Grazie per la spiegazione :laughing: ma credo che il senso della riflessione di @lorenzo.sp fosse di un’altro tipo… o forse intendeva proprio questo :wink:


(Romolo Manfredini) #31

Scusa ma @lorenzo.sp sosteneva che tutti e tre i sistemi fossero inadeguati…
Io invece sostengo che questa inadeguatezza proprio non la vedo…
Con la PEC mando una fattura senza grossi problemi anche se sono il piccolo negoziante (altrettanto posso fare con la app che probabilmente userà REST)
Con SOAP mando le fatture man mano che si producono su un sistema mid range.
Con FTP processo grossi batch di fatture alla volta…
Inadeguato è pensare che ci sia un unico modo di fare le cose e che moderno sia l’unico modo di fare.

PS: Oggi è morto Mario Gerla grazie al quale, insieme a Leonard Kleinrock, stiamo lavorando su un vecchio protocollo ancora perfettamente funzionante.


(Lorenzo) #32

Gente, scusate, io non dico che il SOAP/XML non siano adeguati.
Dico solo che se non sono molto friendly e che con delle api rest non ci saremmo persi niente ma avremmo semplicemente avuto vita molto piu’ facile, visto che gia’ il resto e’ tutto un casino.
Ok, anche se comunque e’ una scelta che io, personalmente, non avrei mai fatto, non significa che abbia ragione per forza, mi sarebbe piaciuta piu’ documentazione ed esempi in ogni caso, ancor di piu’ per uno standard che oggettivamente oggi e’ poco usato in progetti comuni

p.s. @Romolo_Manfredini grazie per i riferimenti storici e non, me li guardero’ che sono interessanti


(Romolo Manfredini) #33

Gli unici esempi di pseudocodice che sono stati forniti riguardano la sezione dei controlli, ma partono dal principio che la fattura sia leggibile, invece vediamo che passano fatture in formati assurdi, dal base64 ai p7m bommati o non, agli xml (anche questi bommati o no). Magari imporre delle regole quantomeno sul formato di file o documentare i formati di file ammessi avrebbe aiutato gli sviluppatori a prevedere in anticipo le varie eccezioni…

Percui riguardo alla documentazione concordo perfettamente, e ti dico di più, vorrei degli strumenti di monitoraggio del canale non solo lato mio, ma anche SDI.
Allo stato attuale non ho nulla di inoppugnabile per capire se la colpa dei mancati funzionamenti sia mia o di SDI.


(Diego Scaravaggi) #34

sì non c’e’ un vero strumento di misurazione, ma intanto (come scritto nel forum) ognuno può controllare le proprie notifiche di ricezione e verificare se: TentativiInvio 1 /TentativiInvio

Già il fatto di non avere mai più di un tentativo è sinonimo del fatto che il proprio sistema in ascolto è pronto.

Poi in effetti, si vede anche che durante il giorno non è che i criceti si ammazzano sulla ruota…
… pochi solleciti… a volte non viene chiamata una ricezione per ore anche a fronte di 100 fatture in attesa…


(Romolo Manfredini) #35

Su qualche centinaio di migliaia di fatture non ne una sola che ha tentativiinvio >1…
Secondo me non danno da mangiare abbastanza ai criceti… (oppure gliene danno troppo e gli viene l’abbiocco, tant’è che lavorano meglio di notte) :rofl::rofl::rofl::rofl:


(Davidthegray) #36

Purtroppo la demenza di base sta nel sistema fiscale italiano. Dubito che esistano altri sistemi con centomila eccezioni per casse previdenziali, professionisti che emettono notule parziali e ai quali devi versare cose ridicole come la ritenuta d’acconto (del resto sono ben rappresentati in parlamento), che abbiano un sistema IVA pensato da qualche malato di mente con reverse charge, dichiarazioni d’intento, esenzioni per mille motivi ed elencate con chiarissime annotazioni tipo “art. 8 comma 2c”, il furto dei bolli sulle fatture esenti, dichiarazioni conai, e le millemila idiozie che rendono la fattura italiana una tragica barzelletta. Chi ha pensato di renderla elettronica senza rendere decente la base normativa sottostante andrebbe rinchiuso a marcire in galera per qualche decennio.


(Diego Scaravaggi) #37

Pur essendo “primi” in Europa non siamo I più complicati del mondo

Mi viene in mente u servizio trasmesso in TV in cui un ns connazionale imprenditore si era trasferito in Nord Europa:
"Mi sembrava di avere i SuperPoteri, di essere venuto da Crypton, in pochi giorni facevo cose che In Italia sarebbero passati mesi, poi ho allestito un sistema di contabilità che per noi Italiani era semplificato ma agli occhi dei collaboratori locali sembrava un programma della NASA "


(Daniele) #38

l’invio degli scontrini telematici, altro problema da risolvere entro luglio, avviene tramite REST.

probabilmente l’agenzia si diverte a cambiare piattaforma


(Lorenzo) #39

Lo scontrino telematico se non ho capito male viene inviato direttamente dalle varie stampanti fiscali


(Diego Scaravaggi) #40

le stampanti fiscali sono device passivi che sono pilotati da un software di cassa,
ora in molti casi il software di cassa è svincolato dal software di contabilità
in altri casi alcuni sistemi integrano scontrino e fattura immediata.

Ma questo penso che lo avete scoperto anche voi se fate degli acquisti in una nota catena commerciale di vendita TV Elettrodomestici, una volta facevi lo scontrino e poi andavi in accoglienza a farti fare la fattura, oggi emettono dalla cassa.

Altri invece hanno ancora i due sistemi separati.