Vyhľadanie kódu chyby alebo dôvodu
- V sandboxe
Jednoducho povedané
Vráti položku katalógu pre ID pravidla, kód chyby kanála alebo francúzsky kód dôvodu (ID a aliasy).
apiKeyAuthorizationBearer <token>Kľúč posielajte ako token typu Bearer: Authorization: Bearer <your-api-key>. Stav služby je jediné volanie, ktoré nevyžaduje kľúč.
code*stringPoložka.
application/json- response
id*stringaliases?array<string>routes*array<string>severity*string"error""warning""info""business"meaning*stringowner*string"us""erp""business""buyer""client""route"fix*stringpartner_message?string|curl -X GET "https://example.com/catalogue/BR-CO-16" \ -H "Authorization: Bearer <your-api-key>"{ "severity": "error", "owner": "us", "routes": [ "ALL" ], "partner_message": "We could not read this invoice from your export. We are correcting our mapping; if a field is missing in the ERP we will tell you which one.", "fix": "Read the JSON path in the error and correct the client mapping.", "meaning": "The invoice JSON does not match the canonical model: a missing or unknown field, a wrong type or code, or a route rule on structure.", "id": "EI-SCHEMA"}Podanie hotového dokumentu UBL alebo CII (priame odovzdanie) POST
Pre ERP, ktoré už zapisujú UBL alebo CII, alebo FA(3) pre kanál KSeF. Nič sa nemapuje: služba spustí oficiálne validátory kanála (pre FA(3): XSD plus pravidlá súboru a dátumu KSeF) a odošle súbor nezmenený. PDF Factur-X alebo ZUGFeRD prejde tým istým koncovým bodom ako application/pdf. XML sa číta s vypnutými entitami, DTD a prístupom do siete, a súbor s DOCTYPE sa odmietne (EI-XML-DTD) skôr, než ho prečíta ktorýkoľvek validátor, rovnako ako súbor, ktorý nie je správne utvorený (EI-XML-SYNTAX) alebo nie je faktúrou, ktorú kanál pozná (EI-XML-TYPE). Od 0.18.4 je ten istý súbor poslaný znova pre klienta a kanál už držanou faktúrou (duplicate_of), ako pri POST /invoices; nič nové sa neodošle.
Stav služby GET
Ďalšia