"[""The 'http://crd.gov.pl/wzor/2025/06/25/13775/:Nazwa' element is invalid - The value ' ' is invalid according to its datatype 'http://crd.gov.pl/wzor/2025/06/25/13775/:TZnakowy512' - line-feed (#xA) or tab (#x9) characters, leading or trailing spaces and sequences of one or more spaces (#x20) are not allowed in 'xs:token'.""]"
W analizowanym przypadku przyczyną był mechanizm formularza faktury. W systemie istniało pole „reprezentant”, które w praktyce odpowiada najczęściej za odbiorcę faktury (czyli podmiot inny niż nabywca). Pole to nie zostało świadomie wykorzystane, jednak pozostał w nim pusty rekord.
I to właśnie ten szczegół uruchomił całą sekwencję zdarzeń.
Program generujący plik XML zinterpretował istnienie tego pola jako informację, że należy utworzyć dodatkowy podmiot w strukturze faktury. W efekcie powstał element:
Podmiot1 – sprzedawca
Podmiot2 – nabywca
Podmiot3 – dodatkowy podmiot (np. odbiorca)
Problem polegał na tym, że dla Podmiot3 nie było rzeczywistych danych. System wygenerował więc strukturę z oznaczeniem braku identyfikatora (BrakID), ale jednocześnie pozostawił pole Nazwa jako technicznie „wypełnione” — zawierające pojedynczą spację.
Z punktu widzenia użytkownika wyglądało to jak brak danych. Z punktu widzenia KSeF był to już błąd formalny.
Schemat XML stosowany w KSeF wykorzystuje typ xs:token, który nie dopuszcza:spacji na początku i końcu,
pustych wartości zawierających znaki białe,
znaków specjalnych typu tabulator czy nowa linia.
W efekcie pojawił się komunikat o nieprawidłowej wartości w polu Nazwa, mimo że użytkownik faktycznie nie wprowadzał tam żadnych danych.
W istocie więc nie mieliśmy do czynienia z „trzecią stroną transakcji”, lecz z artefaktem systemowym — pustym wpisem, który został zinterpretowany jako pełnoprawny podmiot.
Rozwiązanie w takiej sytuacji jest proste, ale wymaga właściwego zrozumienia problemu. Należy:usunąć pusty rekord z pola „reprezentant” (odbiorca),
albo całkowicie wyłączyć generowanie dodatkowego podmiotu, jeśli nie jest on wykorzystywany.
Na poziomie XML oznacza to po prostu brak elementu Podmiot3.
To drobne niedopatrzenie dobrze pokazuje szerszy problem pracy z KSeF: system nie „domyśla się intencji użytkownika”, lecz bezwzględnie interpretuje strukturę danych. Każdy element, nawet pusty, może zostać uznany za znaczący — i w konsekwencji doprowadzić do odrzucenia dokumentu.
W praktyce oznacza to konieczność większej dyscypliny w zarządzaniu danymi źródłowymi oraz świadomości, jak formularz przekłada się na strukturę XML.
I to właśnie ten szczegół uruchomił całą sekwencję zdarzeń.
Program generujący plik XML zinterpretował istnienie tego pola jako informację, że należy utworzyć dodatkowy podmiot w strukturze faktury. W efekcie powstał element:
Podmiot1 – sprzedawca
Podmiot2 – nabywca
Podmiot3 – dodatkowy podmiot (np. odbiorca)
Problem polegał na tym, że dla Podmiot3 nie było rzeczywistych danych. System wygenerował więc strukturę z oznaczeniem braku identyfikatora (BrakID), ale jednocześnie pozostawił pole Nazwa jako technicznie „wypełnione” — zawierające pojedynczą spację.
Z punktu widzenia użytkownika wyglądało to jak brak danych. Z punktu widzenia KSeF był to już błąd formalny.
Schemat XML stosowany w KSeF wykorzystuje typ xs:token, który nie dopuszcza:spacji na początku i końcu,
pustych wartości zawierających znaki białe,
znaków specjalnych typu tabulator czy nowa linia.
W efekcie pojawił się komunikat o nieprawidłowej wartości w polu Nazwa, mimo że użytkownik faktycznie nie wprowadzał tam żadnych danych.
W istocie więc nie mieliśmy do czynienia z „trzecią stroną transakcji”, lecz z artefaktem systemowym — pustym wpisem, który został zinterpretowany jako pełnoprawny podmiot.
Rozwiązanie w takiej sytuacji jest proste, ale wymaga właściwego zrozumienia problemu. Należy:usunąć pusty rekord z pola „reprezentant” (odbiorca),
albo całkowicie wyłączyć generowanie dodatkowego podmiotu, jeśli nie jest on wykorzystywany.
Na poziomie XML oznacza to po prostu brak elementu Podmiot3.
To drobne niedopatrzenie dobrze pokazuje szerszy problem pracy z KSeF: system nie „domyśla się intencji użytkownika”, lecz bezwzględnie interpretuje strukturę danych. Każdy element, nawet pusty, może zostać uznany za znaczący — i w konsekwencji doprowadzić do odrzucenia dokumentu.
W praktyce oznacza to konieczność większej dyscypliny w zarządzaniu danymi źródłowymi oraz świadomości, jak formularz przekłada się na strukturę XML.
0 komentarzy:
Prześlij komentarz