KSeF API a wymiana danych z systemami księgowymi
Wymiana faktur wśród systemami informatycznymi nie ogranicza się do samego przesłania pliku albo komunikatu. W realnym obiegu dokument przechodzi przez kilka etapów, a właściwie każdy z nich może mieć znaczenie dla kolejnej pracy. Faktura wykonana 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 daje możliwość programową komunikację z tym systemem, ale sposób zastosowania interfejsu zależy od tego, jak zorganizowany jest przepływ dokumentów. Przy projektowaniu rozwiązania warto więc zacząć od prześledzenia faktycznego procesu, zamiast w tym samym momencie skupiać się na samych wywołaniach technicznych. Częstym niedopatrzeniem jest założenie, że skoro dokument można wysłać w sposób automatyczny, to pozostałe czynności również mogą zostać zrobione bez dodatkowych reguł. W praktyce szybko ukazują się pytania dotyczące statusów, błędów, ponowień i sposobu informowania użytkownika o problemie.
Dużo uwagi wymaga przygotowanie informacji przekazywanych pomiędzy systemami. Program wykorzystywany do wystawiania faktur może mieć własną strukturę danych, nazewnictwo a także sposób zapisywania poszczególnych wartości. Przy przesyłaniu informacji powinno się 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 trzeba rozstrzygnąć w głównej mierze, skąd pobierane są konkretne wartości, jak traktowane są pola nieuzupełnione oraz co dzieje się z informacjami, których system docelowy nie stosuje. W praktyce kłopoty mogą wynikać z na pozór drobnych różnic. Data zapisana w innym schemacie, 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 rozważenia, jest obsługa operacji wykonywanych w tle. O ile faktury są przesyłane w sposób automatyczny, użytkownik nie obserwuje każdego wywołania systemu. Musi natomiast posiadać sposobność ustalenia, co stało się z konkretnym dokumentem. Sam zapis informujący o rozpoczęciu wysyłki może być niewystarczający, szczególnie gdy przetwarzanie trwa dłużej albo odpowiedź nie pojawia się natychmiast. Potrzebne jest rozróżnienie w gronie dokumentem przygotowanym, przekazanym do obsługi, oczekującym na wynik a także wymagającym interwencji. Znaczenie ma też sposób reagowania na przerwy w komunikacji. Automatyczne ponawianie operacji może być przydatne w określonych przypadkach, niemniej jednak musi 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 też 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, natomiast przy dużym wolumenie niezbędne stają się rozwiązania pozwalające śledzić wiele operacji równocześnie. Wtedy znaczenia nabiera kolejkowanie zadań, rejestrowanie zdarzeń oraz sposobność ponownego przetworzenia konkretnego dokumentu bez uruchamiania całego procesu od początku. Ważne jest też 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 albo pozostałych systemów mogą wpłynąć na wcześniejsze założenia. Wartościowy jest więc mechanizm pozwalający szybko wyszukać źródło kłopotu i określić, czy dotyczy on danych, komunikacji, konfiguracji czy sposobu obsługi odpowiedzi. Właśnie te detale decydują o tym, jak system zachowuje się nie w standardowym przypadku, lecz wtedy, gdy przebieg operacji odbiega od przyjętego schematu.
Warto sprawdzić: KSeF API dokumentacja.