Ta strona oczekuje jeszcze na weryfikację przez rodzimego użytkownika języka.
Brakujące pola obowiązkowe w fakturze FA(3) — które elementy są wymagane i jak czytać „Missing child element(s)”
Jak wygląda ten błąd?
Element '{...}Faktura': Missing child element(s). Expected is ( {...}Podmiot2 ).Walidator mówi: w wskazanym elemencie brakuje wymaganego dziecka — a w nawiasie po Expected is podaje, czego dokładnie. To najczęstszy typ błędu w plikach FA(3), zwykle po prostu niewypełnione pole w programie księgowym.
Główne bloki wymagane w FA(3)
Na najwyższym poziomie faktura FA(3) wymaga kolejno:
| Element | Co zawiera |
|---|---|
Naglowek |
metadane formularza (kod, wariant, data wytworzenia) |
Podmiot1 |
sprzedawca — NIP, nazwa, adres |
Podmiot2 |
nabywca — dane identyfikacyjne i adres |
Fa |
właściwe dane faktury — waluta, daty, numer, pozycje, kwoty |
Brak któregokolwiek z nich zatrzymuje walidację na poziomie Faktura.
Przykłady pól wymaganych wewnątrz bloków
W Naglowek: KodFormularza, WariantFormularza i DataWytworzeniaFa. W Podmiot1: dane identyfikacyjne (NIP, nazwa) oraz adres z kodem kraju. W Fa m.in.: KodWaluty, P_1 (data wystawienia) i P_2 (numer faktury).
Uwaga na format wartości: pole może istnieć, ale mieć złą zawartość — wtedy komunikat brzmi inaczej, np.:
Element '{...}NIP': [facet 'pattern'] The value 'abc' is not accepted by the pattern '...'.NIP musi być ciągiem cyfr o właściwej strukturze (bez kresek i spacji).
Jak naprawić
- Z komunikatu odczytaj element nadrzędny i brakujące dziecko (
Expected is (...)). - Uzupełnij odpowiednie pole w programie księgowym — nazwy techniczne (
P_1,P_2,KodWaluty) odpowiadają zwykle polom „data wystawienia“, „numer faktury“, „waluta“. - Wygeneruj plik ponownie i sprawdź jeszcze raz. Błędy naprawiaj od pierwszego — jeden brak potrafi wywołać kaskadę kolejnych komunikatów.
Częste pytania
Skąd mam wiedzieć, które pola z mojego programu trafiają do których elementów? Dokumentacja struktury logicznej publikowana przez Ministerstwo Finansów zawiera opis wszystkich pól; producenci oprogramowania zwykle mapują je automatycznie — brakujące elementy to najczęściej po prostu puste pola formularza.
Czy nasza walidacja sprawdza też sensowność danych (kwoty, daty)? Obecnie sprawdzamy zgodność ze schematem XSD: struktura, kolejność, typy i formaty wartości. Reguły biznesowe to osobna warstwa — plik poprawny strukturalnie może nadal wymagać weryfikacji merytorycznej.