Przewodnik · Walidacja XML / kodowanie

FA(3): lokalna walidacja przechodzi, ale API KSeF nadal odrzuca XML

To techniczny wariant rozjazdu między lokalną walidacją i zachowaniem API KSeF.

Typ

Przewodnik

Warstwa

Walidacja XML / kodowanie

Skutek

Ostrzeżenie

Typowy komunikat GoKSeF

Plik wygląda poprawnie, XSD przechodzi, semantyka lokalna nie pokazuje blokerów, a API KSeF nadal odrzuca dokument lub zwraca technicznie niejasną odpowiedź.

Najczęściej problem leży w różnicy między tym, co sprawdza lokalny walidator, a tym, co realnie widzi i interpretuje warstwa API po stronie KSeF.

Jak to poprawić

  1. 1 Porównaj bajtową wersję pliku wysyłanego do API z plikiem walidowanym lokalnie.
  2. 2 Sprawdź kodowanie, prolog, białe znaki, encje i sposób serializacji XML przez bibliotekę integracyjną.
  3. 3 Zweryfikuj, czy po drodze nie są modyfikowane nazwy przestrzeni, kolejność elementów albo zawartość pól tekstowych.
  4. 4 Zestaw lokalny raport walidacyjny z pełną odpowiedzią API KSeF, a nie tylko z komunikatem pokazanym w ERP.
  5. 5 Jeżeli trzeba, wygeneruj minimalny przypadek reprodukcyjny i porównaj go z oficjalnymi przykładami FA(3).

Sprawdź przed ponowną walidacją

  • Walidowany lokalnie plik jest identyczny z plikiem wysyłanym do API.
  • Warstwa serializacji nie modyfikuje XML po drodze.
  • Masz pełną odpowiedź API, a nie tylko skrót z ERP.

FAQ

Czy to jest to samo co zwykły błąd 450?
Nie zawsze. 450 może być skutkiem, ale tu diagnoza skupia się na różnicy między lokalnym plikiem i rzeczywistym requestem do API.
Kiedy ten artykuł jest najbardziej przydatny?
Przede wszystkim wtedy, gdy problem analizują integratorzy, developerzy albo osoby pracujące na technicznych logach wysyłki.

Powiązane artykuły

Sprawdź poprawiony plik

Po poprawieniu danych źródłowych wygeneruj XML ponownie i sprawdź nowy plik w GoKSeF.