Czy FA(3) to nowy wzór PDF?

Nie. FA(3) to struktura logiczna danych faktury ustrukturyzowanej, a nie układ graficzny wydruku.

Czy osoba nietechniczna musi znać XML?

Nie musi pisać XML, ale powinna rozumieć, że dane w systemie muszą być kompletne i poprawnie zmapowane.

FA(3): co musi wiedzieć osoba nietechniczna

FA(3) wyjaśniona bez żargonu: czym jest struktura faktury, dlaczego dane są ważne, co sprawdzić w ERP i jak reagować na błędy.

FA(3) brzmi technicznie, ale osoba nietechniczna musi rozumieć jej praktyczny sens. To nie jest nowy szablon PDF ani formularz do ręcznego wypełniania. FA(3) to struktura logiczna faktury ustrukturyzowanej, czyli sposób opisania danych faktury tak, aby KSeF mógł ją przyjąć i nadać jej numer.

Dla księgowości, sprzedaży i właściciela firmy najważniejsze jest jedno: jeżeli dane w systemie są niepełne albo źle zorganizowane, błąd pojawi się przy wysyłce do KSeF. Wtedy problem techniczny często okazuje się problemem operacyjnym.

Dla kogo jest ten poradnik

Dla osób, które nie programują, ale odpowiadają za faktury: księgowych, właścicieli, handlowców, administratorów procesów i osób prowadzących testy. Nie musisz znać szczegółów XML, ale musisz wiedzieć, jakie decyzje wpływają na poprawność faktury.

Jeżeli firma używa ERP, programów fakturowych albo integracji, FA(3) wymaga rozmowy między biznesem i technologią. IT nie zgadnie, jak firma rozumie nietypową korektę, rabat albo opis usługi.

Co zrobić krok po kroku

Spisz typy faktur, które występują w firmie.
Ustal, skąd system bierze dane faktury.
Zapytaj dostawcę systemu o obsługę FA(3) i walidację przed wysyłką.
Przetestuj faktury z typowymi i nietypowymi danymi.
Przy każdym błędzie ustal, czy problem leży w danych, mapowaniu, uprawnieniach czy komunikacji.
Nie poprawiaj dokumentu „na skróty” bez zmiany danych źródłowych.
Zapisz najczęstsze błędy i sposób ich naprawy.

FA(3) a wygląd faktury

Wiele osób myśli fakturą jako dokumentem do przeczytania. KSeF myśli danymi. To, że PDF wygląda dobrze, nie oznacza, że dane są zgodne ze strukturą FA(3). Odwrotnie też może się zdarzyć: dane są poprawne, ale firma potrzebuje dodatkowej wizualizacji dla kontrahenta lub wewnętrznego procesu.

Dlatego testy powinny obejmować dane, nie tylko wygląd. Sprawdź pola kontrahenta, adresy, stawki, kwoty, opisy, numery zamówień, korekty i powiązania z dokumentami źródłowymi.

Gdzie najczęściej powstają problemy

Problemy często zaczynają się w kartotekach: brakuje danych, są stare nazwy kontrahentów, opis usługi jest zbyt swobodny albo firma ma własne skróty zrozumiałe tylko dla pracowników. KSeF nie naprawi takich danych.

Drugie źródło problemów to integracje. Jeżeli faktura powstaje z zamówienia, sklepu lub systemu branżowego, dane muszą przejść przez kilka miejsc. Błąd może pojawić się wcześniej niż w ERP.

Jak reagować na błąd

Nie zaczynaj od pytania „co znowu nie działa w KSeF”. Najpierw sprawdź dokument, dane źródłowe i komunikat. Ustal, czy błąd dotyczy jednej faktury, grupy dokumentów, konkretnego kontrahenta albo całego typu faktur.

Przed kontaktem z integratorem zbierz: numer dokumentu w ERP, datę próby wysyłki, komunikat, wersję schemy, środowisko i informację, czy problem da się odtworzyć. To jest konkret, który skraca diagnozę.

Najczęstsze błędy

Mylenie FA(3) z wyglądem faktury.
Testowanie tylko dokumentów idealnych.
Brak osoby odpowiedzialnej za dane źródłowe.
Ręczna poprawka XML bez poprawy systemu.
Brak listy typów faktur występujących w firmie.

Krótka zasada

Osoba nietechniczna nie musi znać schemy linijka po linijce. Musi natomiast umieć powiedzieć, jakie faktury firma wystawia, gdzie powstają dane, kto je poprawia i co zrobić, gdy system zwraca błąd. To jest realna gotowość do FA(3).