Integracja z KSeF API w środowisku testowym

Sposób przetwarzania faktur bardzo często uzależniony jest od współpracy kilku różnorakich kodów. Dokument może zostać zaprojektowany w aplikacji sprzedażowej, następnie przekazany do systemu księgowego, a część informacji może być wykorzystywana jeszcze w innych procesach. Przy takim modelu ważne staje się nie tylko i wyłącznie przechowywanie dokumentów, ale też administrowanie ich przepływu wśród poszczególnymi rozwiązaniami.

KSeF API pełni w tym układzie funkcję interfejsu pozwalającego na obieg danych z Krajowym Systemem e-Faktur. Z technicznego punktu widzenia konieczne jest jednakże uwzględnienie kilku niezależnych etapów. Aplikacja musi przygotować prawidłowe dane, stosownie się uwierzytelnić, przekazać komunikat, odebrać wynik operacji i zapisać informacje potrzebne do następnej obsługi. Właściwie każdy z takowych etapów może wymagać osobnego mechanizmu testom. Właśnie dlatego projektowanie takiego rozwiązania zaczyna się zwykle od analizy istniejącego obiegu faktur, a dopiero w przyszłości przechodzi do kwestii związanych z samym połączeniem technicznym.

Jednym z częstszych problemów jest różnica pomiędzy strukturą danych wykorzystywaną wewnętrznie a formatem wymaganym podczas podmiany informacji. System sprzedażowy może przechowywać dane w sposób wygodny dla użytkownika, jednak komunikat wysyłany przez KSeF API musi odpowiadać określonym zasadom. Oznacza to, że pomiędzy źródłem danych a interfejsem może być potrzebny dodatkowy stopień przekształcenia. Nie warto zakładać, że wszystkie informacje można przekazać bez przeróbek. W praktyce znaczenie mają również sytuacje nietypowe, takie jak brak wartości w konkretnym polu, różnice w sposobie zapisywania dat czy konieczność obsługi dokumentów powiązanych z wcześniejszymi fakturami. Jeżeli kontrola danych odbywa się dopiero w trakcie wysyłania, użytkownik może otrzymać komunikat o błędzie w momencie, gdy dokument powinien już przejść do kolejnego etapu. Lepsze rozdzielenie walidacji i komunikacji umożliwia dokładniej ustalić, gdzie wystąpiła nieprawidłowość, choćby jednocześnie wymaga dodatkowej logiki w systemie.

Istotnym zagadnieniem jest także kontrolowanie statusem dokumentu. W codziennej pracy łatwo przyjąć uproszczenie, w zgodzie z którym kliknięcie przycisku wysyłki znaczy zakończenie operacji. Przy automatycznej wymianie danych takie założenie może natomiast prowadzić do niejasności. System powinien rozróżniać fakturę oczekującą na przekazanie, operację będącą w toku, dokument wymagający sprawdzenia a także przypadek zakończony prawidłowo. W szczególności istotne staje się to wówczas, gdy odpowiedź nie dociera w przewidywanym czasie. Automatyczne ponowienie wysyłki bez wcześniejszego ustalenia stanu operacji może spowodować powielenie czynności, natomiast całkowite pozostawienie sprawy bez reakcji może wymagać późniejszego ręcznego przeglądania dokumentów. Z tego powodu integracja z KSeF API powinna uwzględniać mechanizmy identyfikowania poszczególnych operacji, zapisywania ich rezultatów oraz reagowania na różnorodne typy problemów. Przy większej liczbie faktur takie rozwiązania przestają być dodatkiem i stają się elementem potrzebnym do aktualnej kontroli procesu.

Warto ponadto pamiętać, że działanie integracji zależy także od przeróbek zachodzących oprócz samym systemem źródłowym. Update oprogramowania, zmiana konfiguracji, modyfikacja procesu wystawiania dokumentów czy pojawienie się nowego przypadku biznesowego mogą wpłynąć na sposób przekazywania informacji. Dlatego testy nie powinny ograniczać się tylko do pierwszego uruchomienia. Przydatne jest sprawdzanie zarówno standardowych faktur, jak i sytuacji, w których dokument zostaje odrzucony, wymaga ponownego przetworzenia albo nie otrzymuje odpowiedzi w oczekiwanym czasie. Równie ważna jest możliwość znalezienia dokładnie sprecyzowanej operacji w historii systemu. Bez odpowiednich zapisów ustalenie, co wydarzyło się z dokumentem kilka dni uprzednio, może być skomplikowane. W praktyce oznacza to potrzebę zachowania równowagi w gronie automatyzacją a kontrolą użytkownika. System może wykonywać powtarzalne czynności, niemniej jednak powinien również pozostawiać czytelny ślad operacji i umożliwiać obsługę przypadków, których nie da się rozwiązać według jednego, z góry ustalonego schematu.

Polecamy: dokumentacja KSeF API.