Uwierzytelnianie aplikacji korzystających z KSeF API

Wymiana faktur wśród systemami informatycznymi nie ogranicza się do samego przesłania pliku lub komunikatu. W realnym obiegu dokument przechodzi przez kilka etapów, a właściwie każdy z nich może posiadać znaczenie dla dalszej pracy. Faktura stworzona w systemie sprzedażowym może wymagać wcześniejszego sprawdzenia, przekształcenia danych, przekazania do Krajowego Systemu e-Faktur, a następnie zapisania informacji o wyniku całej operacji.

KSeF API umożliwia programową komunikację z tym systemem, ale sposób użycia interfejsu zależy od tego, jak zorganizowany jest obieg dokumentów. Przy projektowaniu rozwiązania warto zatem zacząć od analizowania faktycznego procesu, zamiast od razu skupiać się na samych wywołaniach technicznych. Częstym uchybieniem jest założenie, że skoro dokument można wysłać samoczynnie, to pozostałe czynności też mogą zostać zrealizowane bez dodatkowych reguł. W praktyce bardzo szybko ukazują się pytania dotyczące statusów, błędów, ponowień i sposobu informowania użytkownika o problemie.

Dużo sugestie wymaga przygotowanie informacji przekazywanych wśród systemami. Program wykorzystywany do wystawiania faktur może posiadać własną strukturę danych, nazewnictwo a także sposób zapisywania poszczególnych wartości. Przy przesyłaniu informacji trzeba jednakże uwzględnić strukturę wymaganą przez interfejs. Dlatego integracja z KSeF API na prawdę często obejmuje dodatkową warstwę odpowiedzialną za mapowanie danych. Na tym etapie należy rozstrzygnąć w głównej mierze, skąd pobierane są dokładnie sprecyzowane wartości, jak traktowane są pola nieuzupełnione a także co dzieje się z informacjami, których system docelowy nie stosuje. W praktyce problemy mogą wynikać z na pozór drobnych różnic. Data zapisana w innym formacie, nieoczekiwany znak w danych tekstowych czy brak wartości w określonym miejscu mogą spowodować, że cały komunikat nie zostanie przetworzony zgodnie z założeniami. Z tego powodu sprawdzanie danych przed wysłaniem ma inne znaczenie niż kontrola przeprowadzana dopiero po otrzymaniu odpowiedzi.

Kolejnym obszarem, który wymaga analizowania, jest obsługa operacji wykonywanych w tle. Jeżeli faktury są przesyłane samoczynnie, użytkownik nie obserwuje każdego wywołania systemu. Musi jednakże posiadać sposobność ustalenia, co stało się z konkretnym dokumentem. Sam zapis informujący o rozpoczęciu wysyłki może być niewystarczający, zwłaszcza gdy przetwarzanie trwa dłużej lub odpowiedź nie pojawia się natychmiast. Potrzebne jest rozróżnienie wśród dokumentem przygotowanym, przekazanym do obsługi, oczekującym na wynik oraz wymagającym interwencji. Znaczenie ma także sposób reagowania na przerwy w komunikacji. Automatyczne ponawianie operacji może być przydatne w określonych przypadkach, niemniej jednak powinno uwzględniać możliwość, że wcześniejsza próba została przyjęta, a wyłącznie odpowiedź nie dotarła do aplikacji źródłowej. Z drugiej strony pozostawienie wszystkich nieudanych operacji bez dalszego działania znaczy konieczność ręcznego wyszukiwania problemów. Dlatego mechanizm obsługi błędów powinien rozróżniać przyczyny i pozwalać ustalić dalszy sposób postępowania.

Na działanie takiego rozwiązania wpływa także skala prowadzonej działalności i sposób generowania dokumentów. Przy niewielkiej liczbie faktur możliwa jest ręczna kontrola części przypadków, jednakże przy dużym wolumenie konieczne stają się rozwiązania pozwalające śledzić wiele operacji jednocześnie. Wówczas znaczenia nabiera kolejkowanie zadań, rejestrowanie zdarzeń oraz możliwość ponownego przetworzenia konkretnego dokumentu bez uruchamiania całego procesu od początku. Ważne jest także rozdzielenie środowiska testowego od rzeczywistego oraz sprawdzanie zachowania aplikacji po zmianach w jej konfiguracji. Integracja nie powinna być traktowana jako szczegół w pełni niezmienny, ponieważ modyfikacje procesu wystawiania faktur lub pozostałych systemów mogą wpłynąć na wcześniejsze założenia. Wartościowy jest zatem mechanizm pozwalający bardzo szybko odnaleźć źródło kłopotu i określić, czy dotyczy on danych, komunikacji, konfiguracji czy sposobu obsługi odpowiedzi. Właśnie te szczegóły decydują o tym, jak system zachowuje się nie w standardowym przypadku, lecz wtedy, gdy przebieg operacji różni się od przyjętego schematu.

Warto sprawdzić: integracja z KSeF API.

Dodaj komentarz