fatturaelettronicaphp / fatturaelettronica Goto Github PK

Ciao mi capita di ricevere da SDI delle fatture con BolloVirtuale settato a SI, ma ImportoBollo non valorizzato / mancante.

Esempio:

  <DatiBollo>
      <BolloVirtuale>SI</BolloVirtuale>
    </DatiBollo>

Se provo ad aprire tali fatture con $digitalDocument = FatturaElettronicaPhp\FatturaElettronica\DigitalDocument::parseFrom($file); ricevo errore:

  Fatal error: Uncaught TypeError: FatturaElettronicaPhp\FatturaElettronica\Utilities\SimpleXmlExtended::sanitizeFloat(): Argument #1 ($amount) must be of type float, null given

Causato proprio dalla mancanza dell'elemento "ImportoBollo". Ma guardando la doc tecnica, in effetti, tale campo non è obbligatorio.

Ciao, da specifiche tecniche, anche il campo PrezzoTotale ammettere fino a 8 decimali. Ho notato invece che durante la generazione di un xml viene troncata a 2 decimali.
Credo possa essere un problema per chi emette fatture ad esempio sui prezzi benzina dove è utile avere un numero maggiore di decimali.

Un esempio su una fattura che ho creato:

quantità (5.6) X prezzo unitario (2.3174356) = prezzo totale (12.97763936)

mentre nell'XML mi viene approssimato a 12.98

nel dettaglio:

Note sulla Versione V.2021
Con la nuova versione, a pieno regime dal 01/01/2021, il numero dei decimali accettabili passa da 2 ad 8, ciò in analogia con i nodi , , e .

recuperata da: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/ScontoMaggiorazione/Importo

la variabile $lineNumberReference nella classe ShippingLabel dovrebbe essere un array in quanto da specifiche tecniche il campo

  2.1.2.1   <RiferimentoNumeroLinea>

ha molteplicità 0.N

Ciao scusa se apro una "issue" ma non sapevo come scriverti. Ti chiedo se è già in cantiere l'aggiornamento con le regole tecniche 2.3 destinate alle PA e fatture verso estero, in base al documento di AdE "Regole tecniche v.2.3 del 15/05/2023, relative alla gestione delle fatture di cui all’art. 3, comma 1, d.lgs. 148/2018"

Ho provato a leggerlo ma non ho capito molto, a parte il fatto che i nomi dei files dovranno iniziare con UB oppure II al posto del tradizionare codice nazione (IT,...)

Hai qualche certezza tu? grazie

CIao ho un problema di validazione in caso di PEC con "trattino" presente.

Ad esempio l'email "[email protected]" mi da errore di validazione:

PECDestinatario': '[email protected]' is not a valid value of the atomic type '{http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2}EmailType'

Se tolgo il "-" l'errore svanisce... ma ovviamente non sarebbe l'email giusta del cliente

Salve, in primis volevo fare i complimenti per l'ottimo lavoro per questo utilissimo pacchetto per gestire la fatturazione elettronica. Volevo però segnalare un problema pressoché costante nel fare il parsing delle fatture provenienti da Enel Energia S.p.a (sì, esatto, solo da questo Cedente/Prestatore). Viene generata sempre una eccezione InvalidXmlFile dalla classe DigitalDocumentParser.php. Ma con qualsiasi tool online riesco a leggere tranquillamente il P7M, anche aprendo l'originale in vim non vedo problemi si struttura XML. Allego screen e file P7M di esempio che genera questo errore (per questioni di privacy, ho modificato alcuni dati presenti in fattura mettendoli palesementi finti). Saluti, Danilo.
IT06655971007_12345.xml.zip

Ciao ho provato a validare un xml, con:

 var_dump($eDocument->isValid());

ma ricevo warning:

  Warning: DOMDocument::schemaValidateSource(): Invalid Schema in C:\wamp64\www\fatturaelettronicaphp\vendor\fatturaelettronicaphp\fattura-elettronica\src\Validator\DigitalDocumentValidator.php on line 43

con validazione "false"

se faccio un var_dump di:

 $errors = $eDocument->validate()->errors();

visualizzo:

  '{http' => string '/www.w3.org/2001/XMLSchema}element', attribute 'ref': The QName value '{http://www.w3.org/2000/09/xmldsig#}Signature' does not resolve to a(n) element declaration.

Ciao, innanzitutto complimenti per il lavoro, davvero ben fatto!
Unica cosa, mi chiedevo se fosse possibile inserire nella doc la creazione di una fattura con la vostra libreria e magari se possibile aggiungere alle varie classi qualche commento che faccia capire che ripercussioni ha quella classe sulla fattura.

Grazie mille e ottimo lavoro!

Ho la necessita' di inserire 2 allegati all'interno dell'XML

Attualmente la classe mi genera un XML cosi:

Quando invece dovrebbe essere cosi:

Il codice che utilizzo per inserire gli allegati e' questo:

foreach ($listaAllegati as $a) {
    $attachemnt = new FatturaElettronicaPhp\FatturaElettronica\Attachment();
    $attachemnt->setName($a["NomeAttachment"]);
    $attachemnt->setDescription($a["NomeAttachment"]);
    $attachemnt->setAttachment($a["Attachment"]);
    $gD->addAttachment($attachemnt);
 }

Sbaglio qualcosa io nell'utilizzo della classe?
Io credo che il problema sia nella Classe AttachmentWriter in quanto la riga

$xml = $this->xml->addChild('Allegati');

penso debba essere spostata all'interno del ciclo in modo da creare sempre un nuovo nodo

Vi incollo le specifiche dal sito dell'agenzia dell'entrate

Se inserisco la data iscrizione Albo con:

 $supplier->setRegisterDate("2020-01-01");

viene aggiunto anche orario e fuso e ricevo errore:

DataIscrizioneAlbo'' => string ''2020-01-01T08:04:27.000+00:00' is not a valid value of the atomic type 'xs:date'.

Salve non so se è un bug o meno,
ma credo che:

class Representative extends Billable implements ArrayableInterface, RepresentativeInterface

debba essere:

class Representative extends BillablePerson implements ArrayableInterface, RepresentativeInterface

infatti se provo a scrivere:

   $rappresentanteFiscale = new FatturaElettronicaPhp\FatturaElettronica\Representative();
   $rappresentanteFiscale->setTitle("Mister");

ricevo errore su setTitle.

Mentre la stessa logica usata per:

   $intermediario = new FatturaElettronicaPhp\FatturaElettronica\Intermediary();
   $intermediario->setTitle("Mister");

funziona correttamente e infatti la class Intermediary estende BillablePerson

Ciao ho finito di migrare il mio vecchio script di generazione xml, con il tuo ma inviando il file all' SDI (nello specifico parlo del servizio aruba) ricevo come notifica di scarto:

   File non conforme al formato : schemaLocation value = 'http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2' must have even number of URI's. riga: 2 - colonna: 295

Hai qualche idea?

Visto che avrei intenzione di utilizzare la libreria ad uso personale, vorrei, se fosse possibile, eliminare tutto ciò che riguarda le statistiche ed analisi di google.
Ma dato che non sono un esperto di programmazione, non so cosa eliminare, per fare in modo che la libreria rimanga funzionale, anche solo la parte di lettura (che poi è quella che mi interessa).

Your validation code throw an exception when PEC domains contain the dash char: "-".
That is still a valid email address and indeed in Italy all the PEC belonging to "ordine avvocati" have this format "[email protected]" "[email protected]" etc.

premettendo che non sono un esperto, vorrei chiedere a cosa è dovuto il seguente errore, quando eseguo composer test.
[Symfony\Component\Console\Exception\CommandNotFoundException] Command "test" is not defined.
Il programma viene eseguito in ambiente bitnami LAMP (equivalente di xampp).
Se qualcuno mi puo dire dove l'errore che faccio lo ringrazio.

Salve il fornitore Enel Energia S.p.A. utilizza un formato leggermente diverso nella creazione delle fatture p7m che è impossibile da leggere tramite il parsing php.
Anche tramite il vostro script il problema rimane.
Avete modo di provare delle fatture Enel Energia S.p.A. ? Per questioni di privacy non posso postare qui un file di esempio...

Hi,
in the src/Parser/XmlUtilities.php file I had to modify the extractValueFromXmlElement method because some invoices returned this error:
A non well formed numeric value encountered in

I leave you an excerpt of the invoice to make you understand the problem.
... <PrezzoUnitario>2.70000 </PrezzoUnitario><PrezzoTotale>2.70 </PrezzoTotale> ...

as you can see the problem lies in the spaces next to the numbers

i have resolved with:

if ($convertToString) { return trim($value[0]->__toString()); }
you could also think of doing it only for the figures, but in my opinion it makes no sense that no field starts and ends with white spaces

La procedura di parsing del blocco DatiDDT non tiene conto della possibile molteplicità del campo RiferimentoNumeroLinea, pertanto viene preso in considerazione solo il primo riscontro.

Di seguito la funzione in questione:

protected function extractShippingLabelInformationsFrom($order): ShippingLabel
    {
        $instance = new ShippingLabel();

        $value = $this->extractValueFromXmlElement($order, 'RiferimentoNumeroLinea');
        $instance->setLineNumberReference($value);

        $value = $this->extractValueFromXmlElement($order, 'NumeroDDT');
        $instance->setDocumentNumber($value);

        $value = $this->extractValueFromXmlElement($order, 'DataDDT');
        $instance->setDocumentDate($value);

        return $instance;
    }

Possibile blocco DatiDDT:

...
</DatiDDT>
<DatiDDT>
        <NumeroDDT>123456</NumeroDDT>
        <DataDDT>2023-04-21</DataDDT>
        <RiferimentoNumeroLinea>10</RiferimentoNumeroLinea>
        <RiferimentoNumeroLinea>11</RiferimentoNumeroLinea>
        <RiferimentoNumeroLinea>12</RiferimentoNumeroLinea>
        <RiferimentoNumeroLinea>13</RiferimentoNumeroLinea>
 </DatiDDT>

Comportamento desiderato:
La funzione ShippingLabel@getLineNumberReferences restituisce un'array di 4 elementi ([10, 11, 12, 13]).

Attuale comportamento:
La funzione ShippingLabel@getLineNumberReferences restituisce un'array di 1 elemento ([10]).

Versione in uso: 2.6.11

Grazie in anticipo.

Il caso riguarda alcune particolari fatture elettroniche, come quella del SERVIZIO ELETTRICO NAZIONALE.
In queste fatture nel <DettaglioLinee>...</DettaglioLinee> non è presente il tag <Quantita>....</Quantita>, probabilmente perchè il <PrezzoUnitario>2.11000000</PrezzoUnitario> corrisponde sempre al <PrezzoTotale>2.11000000</PrezzoTotale>.
Il tag <Quantita>....</Quantita> però viene automaticamente aggiunto in fase di estrazione del file fattura.xml dal file fattura.xml.p7m come <Quantita>0.00000000</Quantita>.
Ne consegue che una verifica del file restituisce l'errore
2.2.1.11 <PrezzoTotale> non calcolato secondo le regole definite nelle specifiche tecniche
per ogni linea contenuta in fattura, poichè appunto il prezzo unitario viene moltiplicato per 0.00000000, non corrispondendo più al prezzo totale.

Es.:
$xml = 'fattura.xml.p7m';
$eDocument = DigitalDocument::parseFrom($xml);
$eDocument->write('fattura.xml');

Anzitutto, ottimo package!

Non trovo un modo per aggiungere nodi multipli di DatiRitenuta, è possibile?

Vedo solo i setDeduction* nel DigitalDocumentInstance che vanno poi a generare un unico nodo.

Ciao ti chiedo se esiste già una funzione per aprire un file xml (o p7m ovviamente) e trasformare l'istanza in una stringa XML.

Non penso di aver trovato nulla spulciando la documentazione.

Il mio obiettivo è quello di aprire una file di fattura elettronica e lasciare all'utente la possibilità diu visualizzarlo applicandogli un foglio di stile a scelta tra quello ufficiale dell' AdE oppure uno personalizzato più leggibile.

Attualmente utilizzo varie funzioni trovate online ma sto uniformando il tutto per usare solo la tua libreria...

In pratica dopo aver trasformato il file in una stringa, faccio così:

$XML = new DOMDocument();
$XML->loadXML( $fileToView ); //<---------------- $fileToView è il contenuto del file convertito in stringa
$xslt = new XSLTProcessor();
$XSL = new DOMDocument();
if ( $type == "sdi" ) { //<------ scelta del formato di visualizzazione
	if ( $formatoTrasmissione == "FPR12" ) {
		$XSL->load( ROOTURL . 'stylesheets_xml_fe/sdi/' . 'fatturaordinaria.xsl' );
	} else {
		$XSL->load( ROOTURL . 'stylesheets_xml_fe/sdi/' . 'fatturapa.xsl' );
	}
} else {
	// custom
	$XSL->load( ROOTURL . 'stylesheets_xml_fe/custom/' . 'custom.xsl' );
}

$xslt->importStylesheet( $XSL );
print $xslt->transformToXML( $XML );

Ti chiedo quindi se hai una funzione che trasforma l'instanza di un file aperto, in: $fileToView (cioè una stringa).

Grazie mille

Se metto:

  $datiPagamentoDettagli->setEarlyPaymentDiscount(10.00);

ricevo errore validazione:

  'ScontoPagamentoAnticipato'' => string '[facet 'pattern'] The value '10' is not accepted by the pattern '[\-]?[0-9]{1,11}\.[0-9]{2}'.

sembra che lo script rimuova i decimali che sono necessari.... infatti se mettessi 10.01 la validazione è ok.

Il problema è presente anche in: CapitaleSociale .... non ho ancora verificato eventuali altri campi per ora

Sembra abbiate dimenticato di parsare il campo RiferimentoAmministrazione sulle linee beni/servizi.

$value = $this->extractValueFromXmlElement($xml, 'RiferimentoAmministrazione');
$instance->setAdministrativeContact($value);

src/Parser/Body/LinesParser.php

Ciao chiedo se esiste un modo per mostrare all'utente finale dei messaggi personalizzati (quindi in italiano, comunque personalizzabili...) in caso di errore nella validazione di un dato.

Faccio un esempio:

Se provo a inserire un C.F. volutamente errato (1 carattere in più) nell'intermediario:

    ...
    $intermediario->setFiscalCode("AAABBB86C20G123FF");
$eDocument->setIntermediary($intermediario);

e faccio validazione, ricevo:

  'CodiceFiscale'' => string '[facet 'pattern'] The value 'AAABBB86C20G123FF' is not accepted by the pattern '[A-Z0-9]{11,16}'.

In primo luogo sarebbe utile sapere di quale codice fiscale stiamo parlando (ce ne sono diversi all'interno dell'xml). in questo caso sarebbe dell'intermediario <1.5.1.2>.

E trovare il modo per avere un messaggio personalizzato, se possibile. Molti utenti finali noto che non capiscono il significato del messaggio.

Hai qualche idea? Grazie mille

Ciao ho il seguente campo

  2.1.8.1   <NumeroDDT>

compilato così:

  20/2021/G

ma ricevo errore:

  Fatal error: Uncaught TypeError: FatturaElettronicaPhp\FatturaElettronica\Utilities\SimpleXmlExtended::sanitizeText(): Argument #1 ($text) must be of type string, null given, called in C:\wamp64\www\test\vendor\fatturaelettronicaphp\fattura-elettronica\src\Writer\Body\GeneralDataWriter.php on line 208

Installando il pacchetto con composer utilizzando PHP 7.4.9 ricevo questo errore una volta utilizzato il comando: $digitalDocument = DigitalDocument::parseFrom($xml);

Errore:
Fatal error: Uncaught Error: Interface 'Stringable' not found in .....
Error: Interface 'Stringable' not found in .... src\Enums\Enum.php

Modificando manualmente

 abstract class Enum implements Stringable, JsonSerializable

in:

 abstract class Enum implements JsonSerializable

Il problema sembra risolto

Buongiorno non riesco a lettere una fattura semplificata contentente più righe beniServizi.

Utilizzando il metodo getSimplifiedLine(); ricevo solo la prima riga.... ho provato a usare getSimplifiedLines(); ma tale metodo invece non esiste. C'è un modo per recuperare tutte le righe?

Come da PR inviata: #39 (grazie @KristianLentino99) l'idea è di introdurre la possibilità di inviare le fatture elettroniche tramite una libreria PHP ai vari intermediari.

In questa Issue vorremmo definire le modalità in cui tale feature potrebbe essere implementata.

A. Integrata direttamente nel pacchetto

Introdurre la soluzione come da PR #39 , con l'aggiunta di un'interfaccia generica al posto della classe astratta.

In questa soluzione, che risulterebbe la più facile da implementare, ci sarebbe la problematica di aggiunta di varie dipendenze possibilmente non necessarie e la necessità di rilasciare una nuova versione ad ogni nuovo driver pubblicato o ad ogni modifica di driver esistenti.

Inoltre risulterebbe impossibile inviare fatture non prodotte dal pacchetto stesso, a meno di non caricarle tramite la libreria stessa per poi inviarle.

B. Pacchetto separato, con vari driver

In questo scenario, si creerebbe un nuovo pacchetto sotto la stessa organizzazione (fatturaelettronicaphp/fatturaelettronica-sender o una cosa così) che si occupa di inviare fatture elettroniche allo SDI. Tali fatture potranno essere inviate direttamente come file xml o passando attraverso la libreria "core".
Anche qui però i driver sarebbero tutti accorpati in un pacchetto unico.

C. Pacchetto separato, e pacchetti separati per vari driver.

Questa è la soluzione che preferisco, dove si creerebbe un pacchetto "base" per l'invio astratto, e poi un pacchetto per ogni driver, così ognuno può scegliere solo il suo driver e avere il minor numero di dipendenze possibile (ie: fatturaelettronicaphp-sender-aruba, fatturaelettronicaphp-sender-shellrent, etc)

Pingo @KristianLentino99 e @tobispace per ulteriori opinioni al riguardo

Esempio di Interfaccia:

<?php 

namespace FatturaElettronicaPhp\Sender;

interface DigitalDocumentSender 
{
       /** @throws CannotSendDigitalDocumentException **/
       public function send(\SimpleXmlElement $xml): void;
}

Salve non so se sia una buona idea ma la propongo.
Spesso e volentieri ci sono campi "date" facoltativi (esempio su OtherData).
Si potrebbe fare che chiamando il metodo, ad esempio:

$valore =  $otherData->getDate()->format("Y-m-d");

nel caso il campo sia vuoto (null), il metodo format() restituisca null? Perchè attualmente si ha sempre:

Fatal error: Uncaught Error: Call to a member function format() on null

Questo per evitare ogni volta di verificare che un campo "date" sia effettivamente compilato prima di chiamare la funzione format().

Grazie mille

Sembra non essere gestito il campo:

2.1.9.1.4   <NumeroLicenzaGuida>

C'è un typo error ed annotazioni (poco importa) in GeneralDataWriter.php:

Questo:

  /* Dati convenzioni */
    foreach ($this->body->getContracts() as $dataContract) {
        $this->addExternalDocument($dataContract, $generalData->addChild('DatiContratti'));
    }

    /* Dati contratti */
    foreach ($this->body->getConventions() as $dataContract) {
        $this->addExternalDocument($dataContract, $generalData->addChild('DatiConvenzione'));
    }

    /* Dati contratti */
    foreach ($this->body->getReceipts() as $dataContract) {
        $this->addExternalDocument($dataContract, $generalData->addChild('DatiRicezione'));
    }

dovrebbe essere:

  /* Dati contratto */
    foreach ($this->body->getContracts() as $dataContract) {
        $this->addExternalDocument($dataContract, $generalData->addChild('DatiContratto'));
    }

    /* Dati convenzione */
    foreach ($this->body->getConventions() as $dataConvention) {
        $this->addExternalDocument($dataConvention, $generalData->addChild('DatiConvenzione'));
    }

    /* Dati ricezione */
    foreach ($this->body->getReceipts() as $dataReceipt) {
        $this->addExternalDocument($dataReceipt, $generalData->addChild('DatiRicezione'));
    }

Nel file PaymentDetails.php sono presenti i metodi:

getTerms()

setTerms($terms)

ma credo siano dei refusi in quanto il metodo setTerms() è correttamente utilizzato in PaymentInfo.php. Ho provato comunque ad utilizzarlo con la classe PaymentDetails (per vedere che risultato dava) ma di fatto non scrive nulla nel file xml

Ciao se provo ad indicare il numero civico e/o la provincia in:

DatiTrasporto -> IndirizzoResa

ho errore validazione:

  NumeroCivico: This element is not expected
  Provincia: This element is not expected

con:

 $datiTrasporto = new FatturaElettronicaPhp\FatturaElettronica\Shipment();
 ....
 $datiTrasportoIndirizzoResa = new FatturaElettronicaPhp\FatturaElettronica\Address();
 $datiTrasportoIndirizzoResa->setStreetNumber(1);
 $datiTrasportoIndirizzoResa->setState("PR");
 ...
 $datiTrasporto->setReturnAddress($datiTrasportoIndirizzoResa);

Eppure da specifiche tecniche questi 2 campi sono presenti

@Skullbock Salve, possibile che il metodo getBankName() della classe PaymentDetails ritorni sempre null? Anche se nella fattura il campo risulta valorizzato?

Complimenti per la libreria.
Ho notato che nei dati stringa il cui formato ammesso è xs:normalizedString, le lettere accentate vengono sostituite da un ?.
In realtà tutti i caratteri isBasicLatin sono ammessi.

in \FatturaElettronicaPhp\FatturaElettronica\Parser\Body\ShipmentInformationsParser

in row 66 add this

if ($value !== null && count($value) > 0) {
          $value = array_shift($value);

because the extract return an array

Ciao ti scrivo perchè nel gestionale abbiamo un nuovo fornitore che ci sta inviando delle fatture XML (transitate correttamente dal sistema ARUBA) ma che hanno un problema nel campo allegati... infatti è presente solo il tag

<Attachment/>

senza la relativa apertura tag. Di fatto quindi è indicata la presenza di un allegato con il suo campo nome... ma nulla riguardo il contenuto!

Non so perchè Aruba non abbia scartato il file sinceramente.... ho provato a caricare il file su qualche sito di verifica xml ed in effetti tutti me lo rifiutano.

Siccome non posso postarlo qui per problemi di privacy dati sensibili.. potresti lasciarmi la tua email così che tu possa verificare se si tratti effettivamente di un errore di compilazione da parte del fornitore?

Ad ogni modo faccio presente il problema anche ad Aruba...

Grazie

EDIT: ho dato in pasto il file anche a DIKE, al contrario DIKE mi dice che il file è ok nonostante l'incongruenza del tag "orfano"

Ho modificato il metodo wrhite() nel seguente file: DigitalDocumentWriter.php in modo da restituire un file XML con indentazione a capo per facilitare la leggibilità se può essere utile.

Magari ci sono altre strade, io ho usato questa:

   public function write($filePath): bool
{
    if (stripos($filePath, '.xml') === false) {
        $filePath = $filePath . '/' . $this->document->generatedFilename();
    }
	
	$dom = dom_import_simplexml($this->generate()->xml())->ownerDocument;
	$dom->preserveWhiteSpace = false;
	$dom->formatOutput = true;
	return $dom->save($filePath);
}