Il linguaggio di programmazione Delphi
 

Delphi 7 - XML - fattura elettronica

... 9 Giu 2017 19:35
Ho una applicazione di gestione aziendale fatta con D7 e con database Mysql.
Vorrei creare il ******* XML secondo le specifiche dalla fattura elettronicaPA
delle Agenzia delle entrate.
Pensavo di poter crere il ******* XML come un Textfile.
per capirci:

procedure TForm1.Button1Click(Sender: TObject);
var
F:textfile;
begin
AssignFile(F, 'h:\prova1.xml');
Rewrite(F);
WriteLn(F, '<?xml versione="1.0" encoding="UTF-8" ?>');
WriteLn(F, '<nodo1>');
WriteLn(F, '<riga1>');
WriteLn(F, '</nodo1>');
CloseFile(F);
end;

Nella palette componenti di D7 c'è un XMLDocument di cui
ho trovato una piccola demo ma non so se usare quello
o qualcos'altro o scrivere direttamente il ******* come sopra.

non so quale strada seguire
c'è qualcuno che ha già fatto il ******* XML per la fattura elettronicaPA
con Delphi?

grazie,
Eugenio.
Alberto Salvati 10 Giu 2017 10:57
Usare "altro" per creare un xml è una perdita di tempo.
Crea una istanza XmlDocument da codice, gli aggiungi nodi tag etc e buonanotte.

Non so cosa cambia, ma nota che per la RICEZIONE delle fatture devi seguire
tutto un iter burocratico ( e tecnico...)..
Quindi, qualora non lo avessi già fatto, ti suggerisco di acquisire una visione
di insieme di tutto il giro che va ben OLTRE l'invio di un ******* xml...



A.
... 10 Giu 2017 14:09
On Sat, 10 Jun 2017 01:57:53 -0700 (PDT), Alberto Salvati <zzzato@gmail.com>
wrote:

>Usare "altro" per creare un xml è una perdita di tempo.
>Crea una istanza XmlDocument da codice, gli aggiungi nodi tag etc e buonanotte.
>
>Non so cosa cambia,

un Textfile o un XmlDocument sembrano due strade percorribili entrambe.

> ma nota che per la RICEZIONE delle fatture devi seguire tutto un iter
burocratico ( e tecnico...)..

Finora avendo pochi clienti interessati alla fatturaPA
ho delegato ad altri la soluzione di tutto il problema
ma ora sembra che vogliano rendere obbligatorio
la fattura elettronica anche fra privati e la cosa
mi preoccupa non poco.
Ora sto facendo qualche prova di controllo di ******* XML
degli esempi forniti dalla Agenzia delle entrate.
Potrei fermarmi anche soltanto alla creazione del ******* per poi spedire il
cliente dal commercialista con
una chiavetta USB.
Il problema della firma e della conservazione del ******* non potrei risolverlo
io comunque e nemmeno
la verifica delle ricevute e dei pagamenti .

>Quindi, qualora non lo avessi già fatto, ti suggerisco di acquisire una
visione di insieme di tutto il giro che va ben OLTRE l'invio di un *******
xml...

Lo sto facendo anche se mi spaventa un pò...
>
>
>
>A.
Eugenio.
alessandrob 11 Giu 2017 09:46
Ho realizzato il ******* XML un paio (o forse tre) anni fa, utilizzando delphi.

Utilizzare strutture già pronte (XMLDocument) o fare tutto "a mano" secondo me
cambia poco.

Il problema non è il ******* XML in se stesso, bensì il suo contenuto e la
gestione dell'invio al sistema SDI che si occupa della gestione delle fatture
elettroniche.

Prima di tutto ti devi documentare dei contenuti che devono essere inseriti nel
******* XML e di quali modifiche dovrai apportare al tuo programma per gestire i
dati aggiuntivi necessari.

Verifica anche quali casistiche sono proprie dei tuoi clienti finali.

Per l'invio del ******* io ho scelto di appoggiarmi ad un fornitore esterno, che
mi da la possibilità di non dovermi occupare di tutte le problematiche
relative.
In pratica, upload del ******* XML e invio: si occupano loro di firmare
digitalmente e gestire tutto le risposte/errori dal sistema SDI, che poi mi
scarico o verifico dal portale che hanno realizzato
Ovviamente ha un costo, che rigiro al cliente finale.

Il tutto necessità di un bel po' di attenzione, non è un impegno b*****e.

Per la fatturazione elettronica tra privati, per quanto ho verificato fino a
questo punto, la gestione è molto simile: dovrebbe cambiare soltanto il
destinatario del documento, che per la pubblica amministrazione è un codice di
ufficio, per i privati la casella pec.
(Cambia anche un codice nel ******* XML, ma questo è b*****e)
Alberto Salvati 12 Giu 2017 08:57
> un Textfile o un XmlDocument sembrano due strade percorribili entrambe.

Non ha molto senso fare domande ad altri per poi darsi da se delle risposte.
Ribadisco che la strada corretta, secondo me, passa da xmldocument.
Poi vedi tu.


> ma ora sembra che vogliano rendere obbligatorio
> la fattura elettronica anche fra privati e la cosa
> mi preoccupa non poco.


Togli il "sembra".
Per adesso è una possibilità da valutare, visto che agenzia delle entrate DICE
(adesso ma domani chi lo sa...??), che se usi la fatturazione elettronica hai
dei vantaggi (meno controlli, semplificazione per clienti in nazioni black
list...).
Ma entro pochi anni credo diventerà un obbligo.


> Potrei fermarmi anche soltanto alla creazione del ******* > per poi spedire il
cliente dal commercialista con
> una chiavetta USB.

E' una possibilità, ma tieni conto che è un pò scomoda per l'utente finale.


> Il problema della firma e della conservazione del ******* > non potrei
risolverlo io comunque e nemmeno
> la verifica delle ricevute e dei pagamenti .

Da un punto di vista tecnico, inviare fatture e ricevere i feedback non è cosa
tanto complessa.
La conservazione è un ******* sia sul piano tecnico che su quello normativo.


La butto li...
Integrare nel tuo software un collegamento ad un servizio già esistente?
A parte l'ovvio (ma non per tutti) vantaggio di non dover inventare la ruota,
eviteresti a monte eventali rogne, scaricandole sul fornitore del servizio,
quale esso sia.

A.
... 12 Giu 2017 13:36
On Sun, 11 Jun 2017 23:57:24 -0700 (PDT), Alberto Salvati <zzzato@gmail.com>
wrote:

>> un Textfile o un XmlDocument sembrano due strade percorribili entrambe.
>
>Non ha molto senso fare domande ad altri per poi darsi da se delle risposte.

Ok scusa.

>Ribadisco che la strada corretta, secondo me, passa da xmldocument.
>Poi vedi tu.
>
Ok.

>
>> ma ora sembra che vogliano rendere obbligatorio
>> la fattura elettronica anche fra privati e la cosa
>> mi preoccupa non poco.
>
>
>Togli il "sembra".
>Per adesso è una possibilità da valutare, visto che agenzia delle entrate
DICE (adesso ma domani chi lo sa...??), che se usi la fatturazione elettronica
hai dei vantaggi (meno controlli, semplificazione per clienti in nazioni black
list...).
>Ma entro pochi anni credo diventerà un obbligo.

si, credo anche io.

>
>> Potrei fermarmi anche soltanto alla creazione del ******* >> per poi spedire
il cliente dal commercialista con
>> una chiavetta USB.
>
>E' una possibilità, ma tieni conto che è un pò scomoda per l'utente finale.

Potrebbe inviare per posta il ******* XML al commercialista
invece che all'agenzia delle entrate.
Per gli utenti è comunq ue una complicazione oltre che un costo.

>
>> Il problema della firma e della conservazione del ******* >> non potrei
risolverlo io comunque e nemmeno
>> la verifica delle ricevute e dei pagamenti .
>
>Da un punto di vista tecnico, inviare fatture e ricevere i feedback non è cosa
tanto complessa.
>La conservazione è un ******* sia sul piano tecnico che su quello normativo.
>
>
>La butto li...
>Integrare nel tuo software un collegamento ad un servizio già esistente?

Io ho visto che alcuni offrono la possibilità di inviare loro le fatture
in formato PDF e loro poi le convertono in XML
https://www.fatturapa.com/fatturapa-pdf.cshtml
In effetti sembrano costi molto bassi.


>A parte l'ovvio (ma non per tutti) vantaggio di non dover inventare la ruota,
eviteresti a monte eventali rogne, scaricandole sul fornitore del servizio,
quale esso sia.

E' quello che ho fatto finora ma anche i dati delle fatture e dei corrispettivi
e delle denunce iva periodiche ed annuali andranno inviati in formato XML
alla agenzia delle entrate
A questo punto tutto un intero gestionale viene coinvolto,
dalla contabilità ordinaria o semplificata alla gestione vendite.
Io sto pensando di fare anche questi oltre alla fatturaPA.


>
>A.

Ciao,
Eugenio.
... 12 Giu 2017 13:45
On Sun, 11 Jun 2017 00:46:28 -0700 (PDT), alessandrob
<alessandro.bobbo@gmail.com> wrote:

>Ho realizzato il ******* XML un paio (o forse tre) anni fa, utilizzando delphi.
>
>Utilizzare strutture già pronte (XMLDocument) o fare tutto "a mano" secondo me
cambia poco.

ok.

>
>Il problema non è il ******* XML in se stesso, bensì il suo contenuto e la
gestione dell'invio al sistema SDI che si occupa della gestione delle fatture
elettroniche.
>
>Prima di tutto ti devi documentare dei contenuti che devono essere inseriti nel
******* XML e di quali modifiche dovrai apportare al tuo programma per gestire i
dati aggiuntivi necessari.

Lo sto facendo, ho provato a controllare un ******* esempio dopo averlo nominato
nel modo giusto.
A parte alcuni errori contenuti nel ******* fatturaPA esempio (calcoli errati!)
corretti quelli il ******* ha passato il controllo.
Ora si tratta di crearne uno come quello usando la documentazione.
Credo di aver trovato tutto quello che mi serve per farlo.

>
>Verifica anche quali casistiche sono proprie dei tuoi clienti finali.
>
>Per l'invio del ******* io ho scelto di appoggiarmi ad un fornitore esterno,

potresti dirmi quale?
se vuoi farlo in privato : eugenio.belli55@outlook.com

> che mi da la possibilità di non dovermi occupare di tutte le problematiche
relative.
>In pratica, upload del ******* XML e invio: si occupano loro di firmare
digitalmente e gestire tutto le risposte/errori dal sistema SDI, che poi mi
scarico o verifico dal portale che hanno realizzato
>Ovviamente ha un costo, che rigiro al cliente finale.

...quanto?
>
>Il tutto necessità di un bel po' di attenzione, non è un impegno b*****e.
>
>Per la fatturazione elettronica tra privati, per quanto ho verificato fino a
questo punto, la gestione è molto simile: dovrebbe cambiare soltanto il
destinatario del documento, che per la pubblica amministrazione è un codice di
ufficio, per i privati la casella pec.
>(Cambia anche un codice nel ******* XML, ma questo è b*****e)

Si ho visto, però stanno mettendo in moto una cosa gigantesca.

Ciao,
Eugenio.
Alberto Salvati 12 Giu 2017 15:09
> Potrebbe inviare per posta il ******* XML al commercialista
> invece che all'agenzia delle entrate.

Poi il commercialista deve:
1) aprire la mail
2) scaricare il ******* xml
3) inviarlo

Per poche fatture FORSE lo farebbe, per molte ci credo poco.
Per non parlare di quanto potrebbe farsi pagare per questo lavoro extra.


> E' quello che ho fatto finora ma anche i dati delle fatture e dei
> corrispettivi
> e delle denunce iva periodiche ed annuali andranno inviati in formato XML
> alla agenzia delle entrate
> A questo punto tutto un intero gestionale viene coinvolto,
> dalla contabilità ordinaria o semplificata alla gestione vendite.
> Io sto pensando di fare anche questi oltre alla fatturaPA.

Io direi un passo alla volta :-D

A.
... 12 Giu 2017 16:17
On Mon, 12 Jun 2017 06:09:23 -0700 (PDT), Alberto Salvati <zzzato@gmail.com>
wrote:


>Io direi un passo alla volta :-D

Si ma, verso dove?
Che intenzioni ha la Sogei?
Non sarà che un bel giorno troveremo un bel gestionale on line
sui server dell'agenzia delle entrate che consentirà di registrare
le fatture di acquisto e i corrispettivi, emettere fatture di vendita
e stamparsi la dichiarazione dei redditi senza dover inviare
e controllare nessun ******* di nessun tipo?

Così andiamo tutti al mare a mostrar le ******* chiare?

:-)
Eugenio.
Alberto Salvati 12 Giu 2017 17:01
> Non sarà che un bel giorno troveremo un bel gestionale on line
> sui server dell'agenzia delle entrate che consentirà di registrare
> le fatture di acquisto e i corrispettivi, emettere fatture di vendita
> e stamparsi la dichiarazione dei redditi senza dover inviare
> e controllare nessun ******* di nessun tipo?

Un gestionale include ANCHE quelle funzionalità, non SOLO quelle
funzionalità.
Per non parlare degli ERP...
Poi, sarebbe un atto di camorra eccessivo anche per lo stato italiano....
Insomma, non credo che si arrivi a questo..
Tu ti immagini un Italcementi che molla Sap..?


A.
... 12 Giu 2017 18:54
On Mon, 12 Jun 2017 08:01:26 -0700 (PDT), Alberto Salvati <zzzato@gmail.com>
wrote:

>> Non sarà che un bel giorno troveremo un bel gestionale on line
>> sui server dell'agenzia delle entrate che consentirà di registrare
>> le fatture di acquisto e i corrispettivi, emettere fatture di vendita
>> e stamparsi la dichiarazione dei redditi senza dover inviare
>> e controllare nessun ******* di nessun tipo?
>
>Un gestionale include ANCHE quelle funzionalità, non SOLO quelle
funzionalità.
>Per non parlare degli ERP...
>Poi, sarebbe un atto di camorra eccessivo anche per lo stato italiano....
>Insomma, non credo che si arrivi a questo..

Spero di no, ma la strada che sta seguendo ora la Sogei non la capisco.

>Tu ti immagini un Italcementi che molla Sap..?

Mmm... si forse ho esagerato.


Eugenio.
Daniele 13 Giu 2017 13:28
Ciao,

> Spero di no, ma la strada che sta seguendo ora la Sogei non la capisco.
E' la strada che porta alla semplificazione in*****ata.
Tutti gli incentivi che hanno usato per passare, tutti, alla fatturazione
elettronica sono ampliamente superati dalle ingenti sanzioni se si sbaglia
qualcosa.
Tieni presente che per "se sbagli qualcosa" include anche errori di
trasmissione, invio tardivo dei documenti anche per cause dovuti a terzi
ecc...
Per ora vediamo cosa succede con l'invio trimestrale dell'iva (che significa
triplicare i costi di gestione del commercialista per quel lavoro, dato che
da un conteggio ora se ne fanno quattro).
Come sempre il fine e' (potrebbe) essere nobile, ma come viene conseguito e'
tutt'altro che nobile.
Mi ricordo quando, circa quattro anni fa, ho dovuto creare un ******* xml da
inviare al ministero della sanita'.
Un delirio, prima non andava bene la data, poi avevano cambiato il
separatore .... poi dopo qualche settimana tutto ok!

Speriamo in bene !!

Ciao

Daniele
... 13 Giu 2017 17:53
On Tue, 13 Jun 2017 13:28:12 +0200, "Daniele" <io@io.it> wrote:

>Ciao,
>
>> Spero di no, ma la strada che sta seguendo ora la Sogei non la capisco.
>E' la strada che porta alla semplificazione in*****ata.
>Tutti gli incentivi che hanno usato per passare, tutti, alla fatturazione
>elettronica sono ampliamente superati dalle ingenti sanzioni se si sbaglia
>qualcosa.

Nel ******* dello spesometro (di cui ho fatto tutte le versioni) è previsto
anche il nome della software house che ha realizzato il programma .
E' un dato che per fortuna è opzionale ma il dover mettere
la mia identità su dei documenti fiscali di cui non posso avere alcuna
certezza di completezza e verità non mi fa stare tranquillo per niente.
Se si verifica un controllo fiscale gli utenti se ne lavano le mani dicendo
che loro hanno solo premuto dei bottoni, il resto l'ha fatto il programma.

>Tieni presente che per "se sbagli qualcosa" include anche errori di
>trasmissione, invio tardivo dei documenti anche per cause dovuti a terzi
>ecc...

Infatti fino ad ora mi sono appoggiato agli studi commerciali
ma ora sembrano proprio loro a chiedere aiuto.

>Per ora vediamo cosa succede con l'invio trimestrale dell'iva (che significa
>triplicare i costi di gestione del commercialista per quel lavoro, dato che
>da un conteggio ora se ne fanno quattro).

Ho iniziato da questo, penso che avrò a breve un ******* da controllare.

>Come sempre il fine e' (potrebbe) essere nobile, ma come viene conseguito e'
>tutt'altro che nobile.
>Mi ricordo quando, circa quattro anni fa, ho dovuto creare un ******* xml da
>inviare al ministero della sanita'.
>Un delirio, prima non andava bene la data, poi avevano cambiato il
>separatore .... poi dopo qualche settimana tutto ok!

Io non si capisco nè gli obiettivi nè gli strumenti che stanno utilizzando.
Mi sembra il solito gioco all'italiana,
fare per qualcuno e poi disfare per qualcun altro.

>
>Speriamo in bene !!
>
>Ciao
>
>Daniele

Ciao,
Eugenio.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione Delphi | Tutti i gruppi | it.comp.lang.delphi | Notizie e discussioni delphi | Delphi Mobile | Servizio di consultazione news.