PDF/A-3b è sempre una fattura elettronica?

No. PDF/A-3b è un profilo PDF di archiviazione. Le fatture elettroniche Factur-X e ZUGFeRD usano PDF/A-3b come wrapper per XML EN 16931 incorporato.

Quale endpoint crea PDF/A-3b?

Usate POST /api/v1/pdf/render con settings.profile per PDF/A-3b ordinario. Usate POST /api/v1/e-invoice/render quando l'output deve essere una fattura elettronica Factur-X o ZUGFeRD.

Posso allegare file arbitrari tramite questa pagina?

Non assumete supporto per allegati arbitrari salvo quando la documentazione pubblica dell'API elenca quel processo. Questa pagina si concentra su PDF/A-3b documentato ed e-invoice.

Come verifico l'output PDF/A?

Usate /validator/ o la vostra pipeline con motori di riferimento. Per e-invoice, validate sia il livello PDF/A sia il livello XML incorporato.

Compliance e archiviazione

API PDF/A-3b per archiviazione ed e-invoice

Genera output PDF/A-3b con gPdf e chiarisce quando PDF/A-3b è solo un profilo di archiviazione e quando è un wrapper e-invoice.

API PRINCIPALE JSON Render

ENDPOINT /api/v1/pdf/render

SISTEMI backend di conformità / sistema finance / archivio legale / processo di audit

Provare nel Playground Leggere la documentazione

Lavoro da svolgere

Generare documenti PDF/A-3b per processi di archiviazione e scegliere l'endpoint e-invoice quando PDF/A-3b deve trasportare XML EN 16931 incorporato Factur-X o ZUGFeRD.

Quando usare questa API

Vi serve un profilo di archiviazione PDF/A-3b per un documento renderizzato.
Dovete spiegare il confine tra PDF/A ordinario e packaging e-invoice.
Il vostro processo di conformità valida i PDF generati con veraPDF o un altro motore di riferimento.
Vi serve una pagina pubblica per indirizzare l'intento di ricerca PDF/A-3b all'endpoint corretto.

Cosa non sostituisce

Vi servono processi con allegati arbitrari non documentati nell'API pubblica.
Vi servono fatture elettroniche Factur-X o ZUGFeRD tramite JSON Render. Usate E-Invoice Render.
Vi serve una API validator. La superficie validator pubblica attuale è la pagina /validator/.

Quale endpoint chiamare

PRIMARIO

/api/v1/pdf/render

JSON Render è il percorso predefinito per questo flusso.

SECONDARIO 1

/api/v1/e-invoice/render

Usalo quando il flusso richiede l'API collegata, un contratto di template o una verifica delle capacità.

Request minimo

POST /api/v1/pdf/render - richiesta di output PDF/A-3b per un documento renderizzato.

{
  "settings": {
    "profile": "pdfa-3b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive copy",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Cosa gestisce gPdf

Selezione del profilo PDF/A tramite impostazioni JSON Render.
Packaging e-invoice PDF/A-3b quando usate POST /api/v1/e-invoice/render.
Output PDF renderizzabile adatto alla verifica con motori di riferimento esterni.
Separazione chiara tra profilo di archiviazione e processo legale e-invoice.

Cosa controlla il tuo sistema

La policy di conservazione e il motivo per cui PDF/A-3b è richiesto.
Qualsiasi dato di business, semantica XML e criterio esterno di accettazione per la conformità.
Evidenze di verifica, record di audit e archiviazione a lungo termine dopo il rendering.

Checklist di produzione

Scegliete JSON Render per output PDF/A-3b ordinario.
Scegliete E-Invoice Render quando è richiesto XML EN 16931 incorporato.
Validate l'output PDF/A con /validator/ o con il vostro processo veraPDF.
Registrate il profilo richiesto e il request ID insieme al documento archiviato.
Evitate di dichiarare supporto per allegati arbitrari salvo quando la documentazione pubblica lo elenca.

Limiti della promessa

PDF/A-3b è un profilo di archiviazione; il packaging e-invoice è un processo più specifico costruito sopra di esso.
Non implicate che ogni processo con file incorporati arbitrari sia supportato.
La rotta e-invoice è richiesta per pacchetti Factur-X e ZUGFeRD PDF/A-3b.

PDF/A-3b è il wrapper, non l’intero processo

PDF/A-3b è un profilo PDF per l’archiviazione. È rilevante perché può fungere da wrapper per fatture elettroniche ibride, ma il profilo da solo non rende un documento una fattura elettronica legale. Un documento ordinario archiviato può usare PDF/A-3b senza XML fattura incorporato.

Per Factur-X e ZUGFeRD, usate POST /api/v1/e-invoice/render. Quell’endpoint è responsabile dei metadati specifici e-invoice e del collegamento al file associato.

Scegliete l’endpoint in base all’intento

Usate JSON Render quando l’obiettivo è “renderizzare questo documento come PDF/A-3b”. Usate E-Invoice Render quando l’obiettivo è “confezionare questa fattura come Factur-X o ZUGFeRD con XML CII EN 16931”. La distinzione mantiene chiaro il codice ed evita che lavori ordinari di archiviazione portino con sé assunzioni e-invoice per errore.

Validate con strumenti esterni

PDF/A dovrebbe essere verificato con un motore di riferimento, non con una dichiarazione marketing. Usate il validator pubblico o la vostra pipeline di verifica e archiviate il report con le evidenze di audit.

FAQ

PDF/A-3b è sempre una fattura elettronica?: No. PDF/A-3b è un profilo PDF di archiviazione. Le fatture elettroniche Factur-X e ZUGFeRD usano PDF/A-3b come wrapper per XML EN 16931 incorporato.
Quale endpoint crea PDF/A-3b?: Usate POST /api/v1/pdf/render con settings.profile per PDF/A-3b ordinario. Usate POST /api/v1/e-invoice/render quando l'output deve essere una fattura elettronica Factur-X o ZUGFeRD.
Posso allegare file arbitrari tramite questa pagina?: Non assumete supporto per allegati arbitrari salvo quando la documentazione pubblica dell'API elenca quel processo. Questa pagina si concentra su PDF/A-3b documentato ed e-invoice.
Come verifico l'output PDF/A?: Usate /validator/ o la vostra pipeline con motori di riferimento. Per e-invoice, validate sia il livello PDF/A sia il livello XML incorporato.