Definicja: Faktura ustrukturyzowana jest fakturą elektroniczną w formacie XML zgodnym z obowiązującą strukturą logiczną KSeF. System ERP musi więc nie tylko przygotowywać dane do FA(3), lecz także obsługiwać ich wysyłkę, odbiór i weryfikację statusów.[1]
Gotowość ERP do faktur ustrukturyzowanych ocenia się w sześciu obszarach: obowiązek i proces, dane FA(3), integracja API, dostęp, pełny obieg dokumentu oraz testy awaryjne.
Najpierw trzeba ustalić, które procesy i rodzaje faktur firma rzeczywiście obsługuje.
Następnie należy porównać dane źródłowe ERP z wymaganiami FA(3).
Integracja powinna obejmować nie tylko wysyłkę, ale też odbiór, statusy, UPO i korekty.
Przed uruchomieniem produkcyjnym trzeba przetestować poprawne dokumenty, błędy i ponowienia transmisji.
Przygotowanie ERP do KSeF nie sprowadza się do instalacji modułu ani wygenerowania pliku XML. Potrzebny jest kontrolowany obieg danych: od ustalenia zakresu obowiązku i źródeł informacji, przez mapowanie FA(3) oraz autoryzację, po statusy, Urzędowe Poświadczenie Odbioru, korekty i obsługę błędów. Ostateczna ocena zależy od wersji systemu, jego konfiguracji, sposobu integracji i procesów realizowanych przez firmę.
Prace należy zacząć od inwentaryzacji procesu fakturowania, a dopiero później przejść do konfiguracji, aktualizacji albo wymiany rozwiązania.[2] System może prawidłowo tworzyć XML, a mimo to nie obsługiwać odbioru dokumentów, korekt, odpowiedzi KSeF lub dalszego przekazania danych do ewidencji.
Ustal zakres procesów i typów dokumentów
Punktem wyjścia jest lista czynności wykonywanych w firmie. Powinna obejmować wystawianie faktur sprzedażowych, przyjmowanie dokumentów zakupowych, korekty, kontrolę statusów oraz pobieranie UPO. Jeżeli przedsiębiorstwo korzysta z danych dodatkowych, załączników albo obsługuje zamówienia publiczne, te przypadki trzeba oznaczyć jako osobne ścieżki.
Czy ERP generuje dane zgodne z FA(3), a nie wyłącznie z wcześniejszą FA(2)?[6]
Czy rozwiązanie obsługuje wysyłanie i odbieranie dokumentów?
Czy rejestruje statusy KSeF i pozwala pobrać UPO?
Czy wspiera faktury korygujące i ich powiązanie z obiegiem dokumentu?
Czy wiadomo, jak zostaną przydzielone uprawnienia oraz odpowiedzialność użytkowników?
Czy określono sposób reagowania na niepoprawne dane i problemy komunikacyjne?
Czy zakres modułu został sprawdzony dla używanej wersji i konfiguracji ERP?
Efektem audytu powinna być lista procesów objętych projektem i luk wymagających działania. Dopiero na tej podstawie można oceniać funkcję wbudowaną w ERP, moduł producenta albo rozwiązanie integracyjne.
Sprawdź obowiązek oraz wyjątki przed planowaniem prac
Harmonogram wdrożenia zależy od kategorii podatnika, dlatego przed konfiguracją trzeba ustalić, do której grupy należy firma. Nie należy też zakładać, że każdy podatnik ma identyczny zakres wdrożenia od pierwszego dnia: wyjątki i limity odnoszą się do określonych warunków ustawowych i nie są ogólnym zwolnieniem z przygotowania ERP.[5]
Terminy oraz przepisy przejściowe trzeba potwierdzić bezpośrednio przed podjęciem decyzji wdrożeniowej. Pozwala to uniknąć zarówno pominięcia potrzebnej funkcji, jak i rozszerzenia projektu o procesy, których firma nie realizuje.
Zmapuj dane ERP do struktury FA(3)
Najważniejszym zadaniem po ustaleniu zakresu jest powiązanie danych źródłowych ERP z elementami FA(3). Mapa powinna wskazywać, skąd pochodzi każda informacja, kto odpowiada za jej jakość oraz jak system wykryje brak lub niespójność przed wysyłką.
FA(3) obejmuje między innymi nagłówek, dane podmiotów, pozycje i kwoty, informacje o płatności, stopkę oraz warunkowo element załącznika.[7] Układ ekranu faktury w ERP nie musi odpowiadać organizacji danych w XML, dlatego samo porównanie nazw pól jest niewystarczające.
Które obszary danych objąć mapowaniem
Obszar danych
Przykładowe źródło w ERP
Cel kontroli przed wysyłką
Właściciel danych
Dane techniczne dokumentu
Konfiguracja i rejestr faktur
Potwierdzenie kompletności danych wymaganych do utworzenia dokumentu
Administrator systemu i właściciel procesu
Sprzedawca i nabywca
Kartoteki podmiotów
Wykrycie braków oraz niespójnych danych stron transakcji
Księgowość lub opiekun kartotek
Pozycje i kwoty
Dokument handlowy
Sprawdzenie zgodności danych pozycji z wartościami dokumentu
Dział sprzedaży i księgowość
Płatność
Warunki handlowe i rozrachunki
Kontrola dostępności danych przekazywanych z fakturą
Księgowość
Stopka i dane dodatkowe
Konfiguracja dokumentu lub kartoteki
Ustalenie, które informacje są używane w danym procesie
Właściciel procesu
Załącznik, jeżeli jest potrzebny
Proces źródłowy i repozytorium danych
Potwierdzenie odrębnych wymagań formalnych i technicznych
Właściciel procesu i zespół techniczny
Jak kontrolować braki i niespójności przed wysyłką
Dla każdego obszaru danych trzeba określić warunek poprawności i reakcję systemu na jego niespełnienie. Błąd wykryty przed wysyłką powinien być czytelnie przypisany do dokumentu oraz osoby lub zespołu, który może poprawić dane. Taka kontrola ogranicza sytuacje, w których księgowość otrzymuje wyłącznie techniczny komunikat bez wskazania źródła problemu.
Mapa danych pozwala też oddzielić zmianę konfiguracji od zmiany procesu. Jeżeli informacja istnieje w ERP, lecz nie trafia do XML, problem może dotyczyć mapowania. Jeżeli nie jest gromadzona, potrzebna jest decyzja o jej źródle i odpowiedzialności za uzupełnienie.
Kiedy osobno zaprojektować obsługę załączników
Załącznika w FA(3) nie należy traktować jak dowolnego pliku dodawanego do dokumentu w ERP. Jego obsługa wymaga osobnego scenariusza formalno-technicznego.[1] Ten zakres należy włączać do projektu tylko wtedy, gdy wynika z rzeczywistych procesów firmy.
Oceń integrację API, uprawnienia i pełny obieg dokumentu
Integrację trzeba ocenić na podstawie aktualnego API KSeF, sposobu uwierzytelniania oraz obsługi całego przepływu dokumentu. Dokumentacja techniczna obejmuje między innymi scenariusze wysyłki, odbioru, uwierzytelniania i pobierania UPO.[3] Dostępne materiały integracyjne nie zastępują jednak sprawdzenia funkcji konkretnego ERP lub modułu.[4]
Wysyłka, odbiór, statusy i UPO
Pełna integracja nie kończy się po przekazaniu faktury. ERP powinien obsługiwać informację zwrotną, stan dokumentu, pobieranie Urzędowego Poświadczenia Odbioru, odbiór faktur oraz korekty. Lokalny komunikat o wysłaniu nie powinien być traktowany jako zamiennik informacji otrzymanej z KSeF.
Kryterium akceptacji musi zatem obejmować cały obieg dokumentu, a nie tylko wygenerowanie XML. Sama nazwa comarch ksef nie przesądza o zakresie integracji; trzeba zweryfikować funkcje dostępne w używanej wersji, module i konfiguracji.
Uwierzytelnianie oraz podział odpowiedzialności
Model dostępu należy zaprojektować razem z procesem biznesowym. Trzeba ustalić, w jaki sposób rozwiązanie jest uwierzytelniane, jakie operacje mogą wykonywać poszczególni użytkownicy oraz kto odpowiada za nadawanie, zmianę i odbieranie dostępu. Dostęp techniczny systemu nie jest tym samym co rola pracownika wystawiającego lub kontrolującego faktury.
Aktualne mechanizmy uwierzytelniania i uprawnień należy potwierdzić przed wdrożeniem. Dotyczy to również materiałów producenta ERP, ponieważ zakres i sposób konfiguracji mogą zależeć od konkretnej wersji rozwiązania.
Pytania do dostawcy ERP lub integratora
Wersja i zgodność rozwiązania
Czy używana wersja modułu obsługuje FA(3) i aktualny kontrakt API KSeF?
Zakres komunikacji
Czy rozwiązanie obsługuje wysyłkę, odbiór, statusy, UPO i faktury korygujące?
Uwierzytelnianie
Jak konfiguruje się dostęp systemu i jak zarządza się jego zmianą lub odebraniem?
Walidacja
Które błędy są wykrywane przed wysyłką, a które dopiero w odpowiedzi KSeF?
Monitoring
Gdzie użytkownik widzi stan dokumentu, komunikat błędu i historię wykonanych operacji?
Odpowiedzialność
Które działania wykonuje księgowość, które administrator ERP, a które dostawca integracji?
Przetestuj integrację zanim uruchomisz ją produkcyjnie
Test akceptacyjny powinien obejmować autoryzację, wysyłkę, odpowiedź statusową, UPO, odbiór faktury, korektę i reakcję na błąd. Samo utworzenie poprawnego XML nie dowodzi, że cały proces działa w sposób kontrolowany.
Scenariusze poprawnego przepływu
Przygotuj reprezentatywne dokumenty. Dobierz przypadki odpowiadające typom faktur i procesom rzeczywiście obsługiwanym przez firmę.
Zweryfikuj dane źródłowe. Potwierdź, że informacje wymagane przez mapowanie są dostępne i prawidłowo przypisane.
Sprawdź uwierzytelnianie. Ustal, czy ERP lub moduł integracyjny może wykonać przewidziane operacje w KSeF.
Prześlij dokument. Skontroluj jego status oraz sposób zapisania odpowiedzi w ERP.
Pobierz UPO. Sprawdź, czy potwierdzenie jest dostępne i powiązane z właściwym dokumentem.
Przetestuj odbiór. Zweryfikuj, czy pobrany dokument trafia do przewidzianego procesu i może zostać dalej obsłużony.
Wykonaj korektę. Skontroluj jej przepływ oraz powiązanie z dokumentem pierwotnym.
Testy błędów i ponowień
Osobny zestaw prób powinien wykorzystywać dokumenty niekompletne lub niespójne oraz sytuacje, w których operacja wymaga ponowienia. Dla każdego przypadku należy zapisać oczekiwany komunikat, stan dokumentu, właściciela reakcji i dozwolone dalsze działanie.
Testy muszą rozróżniać błędy biznesowe od problemów komunikacyjnych. Pierwsze mogą wymagać poprawy danych w ERP, a drugie działania po stronie integracji. Szczegóły techniczne i aktualne procedury awaryjne trzeba potwierdzić w dokumentacji Ministerstwa Finansów.
Kiedy uznać integrację za gotową
Integrację można odebrać dopiero wtedy, gdy uzgodnione scenariusze przechodzą przez cały obieg, użytkownicy potrafią rozpoznać stan dokumentu, a odpowiedzialność za błędy jest przypisana. Kryterium nie powinno brzmieć „system wysłał fakturę”, lecz „proces zakończył się oczekiwanym statusem i pozostawił możliwy do zweryfikowania ślad”.
Przygotuj obsługę błędów i niedostępności
ERP powinien pozwalać rozpoznać błąd, zachować informację o stanie dokumentu i wykonać właściwe dalsze działanie. Sposób kolejkowania, alertowania oraz ponawiania operacji zależy od architektury ERP lub integratora, dlatego nie można przyjmować jednego mechanizmu dla wszystkich wdrożeń.
Rozdziel błąd danych od problemu transmisji
Błąd danych dokumentu
Wymaga wskazania niepoprawnej lub brakującej informacji, właściciela danych i sposobu dokonania korekty przed kolejną próbą.
Problem komunikacyjny
Wymaga zachowania stanu dokumentu oraz kontrolowanego ponowienia operacji zgodnie z architekturą integracji.
Niejednoznaczny status
Wymaga ustalenia rzeczywistego stanu na podstawie informacji KSeF, a nie wyłącznie lokalnego oznaczenia w ERP.
Przypadek awaryjny
Wymaga zastosowania aktualnej procedury właściwej dla danej sytuacji, potwierdzonej w materiałach Ministerstwa Finansów.
Nie każda przerwa lub nieudana operacja oznacza ten sam scenariusz. Szczegółowych zasad trybów offline nie należy utrwalać w konfiguracji ani instrukcji bez sprawdzenia ich aktualnego brzmienia.
Ustal właściciela i ślad audytowy błędu
Dla każdego rodzaju problemu należy wskazać osobę lub zespół odpowiedzialny za reakcję, źródło komunikatu oraz sposób udokumentowania rozwiązania. Księgowość powinna móc odróżnić potrzebę poprawy faktury od awarii technicznej, a administrator lub integrator powinien otrzymać dane pozwalające zidentyfikować problem komunikacyjny.
Taki podział zamienia obsługę wyjątków w kontrolowany element procesu. Bez niego błędy mogą być rozwiązywane ręcznie, bez spójnej informacji o stanie dokumentu i wykonanych działaniach.
Uwzględnij przypadki szczególne i aktualność wymagań
Nie wszystkie firmy potrzebują identycznego zakresu funkcji. Załączniki, dodatkowe dane i procesy związane z zamówieniami publicznymi należy uwzględniać tylko wtedy, gdy wynikają z modelu działalności. Jednocześnie przed publikacją instrukcji lub uruchomieniem systemu trzeba ponownie sprawdzić przepisy, strukturę FA(3), API, mechanizmy dostępu i dokumentację używanego modułu.
Załączniki i dokumenty z dodatkowymi danymi
Jeżeli firma stosuje załączniki, ich obsługę trzeba wyodrębnić w analizie, mapowaniu i testach. Nie wystarczy potwierdzić, że ERP pozwala dołączyć plik do lokalnego dokumentu. Wymagany jest scenariusz odpowiadający zasadom FA(3) oraz związanym z nim formalnościom.
Kiedy rozważyć PEF
PEF należy rozpatrywać w kontekście właściwych procesów B2G. Nie jest ona tym samym systemem co KSeF, dlatego potrzeba jej obsługi nie powinna być automatycznie przypisywana każdemu wdrożeniu ERP. Jeżeli firma realizuje taki proces, zakres integracji trzeba ustalić osobno.
Lista elementów do ponownego sprawdzenia
aktualny zakres obowiązku i wyjątki dotyczące firmy,
obowiązującą wersję struktury logicznej faktury,
aktualny kontrakt API oraz scenariusze komunikacji,
zasady uwierzytelniania i zarządzania uprawnieniami,
procedury offline i działania przy niedostępności,
wersję oraz zakres funkcjonalny modułu ERP,
wymagania dla załączników i innych przypadków szczególnych.
Ta kontrola powinna być częścią odbioru wdrożenia. Artykuł nie zastępuje dokumentacji producenta systemu ani bieżącej weryfikacji wymagań publikowanych przez Ministerstwo Finansów.
Najczęstsze pytania
Czy ERP musi samodzielnie łączyć się z API KSeF?
Nie trzeba z góry przyjmować jednego modelu technicznego. Komunikację może realizować funkcja ERP, moduł dostawcy albo rozwiązanie integracyjne. W każdym przypadku należy sprawdzić rzeczywisty zakres wysyłki, odbioru, statusów, UPO, korekt i obsługi błędów.
Czy wygenerowanie XML oznacza, że system jest gotowy do KSeF?
Nie. Gotowość obejmuje także uwierzytelnianie, przesłanie dokumentu, obsługę odpowiedzi, pobranie UPO, odbieranie faktur, korekty oraz reakcję na nieprawidłowe dane i problemy komunikacyjne.
Czy załącznik można obsłużyć jak zwykły plik z ERP?
Nie. Załącznik w FA(3) wymaga odrębnego scenariusza formalno-technicznego. Lokalne dodanie pliku do dokumentu nie potwierdza prawidłowej obsługi tej funkcji w KSeF.
Co należy potwierdzić przed uruchomieniem produkcyjnym?
Trzeba zweryfikować obowiązującą strukturę FA(3), dokumentację API, metodę dostępu, zakres modułu ERP, aktualne przepisy oraz procedury awaryjne. Następnie należy wykonać test całego obiegu dokumentu.
