W codziennej obsłudze dokumentów inwestycyjnych liczy się nie tylko i wyłącznie możliwość wystawienia faktury, ale również sposób, w jaki informacje o niej trafiają do kolejnych systemów. Przy niewielkiej liczbie dokumentów część czynności można wykonywać ręcznie, jednak wraz ze wzrostem liczby operacji pojawia się wymaganie uporządkowania całego przepływu danych. KSeF API stanowi warstwę komunikacji, dzięki której zewnętrzne aplikacje mogą wymieniać informacje z Krajowym Systemem e-Faktur w zgodzie z określonym sposobem działania interfejsu.
W praktyce oznacza to konieczność implementacji systemu źródłowego do wymogów dotyczących danych, autoryzacji a także obsługi odpowiedzi. Samo nawiązanie połączenia jest jedynie jednym z etapów. Znacznie więcej decyzji pojawia się w późniejszym czasie, gdy trzeba ustalić, co system zrobi z dokumentem przed wysłaniem, jak zapisze jego status i jak zachowa się w sytuacji wystąpienia błędu.
Przygotowanie integracji zaczyna się od określenia rzeczywistego obiegu informacji. Oczywiście nie każdy system potrzebuje pobierać i wysyłać wnikliwie te same dane, a próba objęcia automatyzacją wszystkich możliwych operacji od początku może niepotrzebnie skomplikować rozwiązanie. Integracja z KSeF API powinna zatem uwzględniać dokładnie sprecyzowane procesy zachodzące w danym środowisku. Całkiem inaczej wygląda przekazywanie kilku faktur dziennie, a zupełnie inaczej sytuacja, w której dokumenty powstają samoczynnie w wielu oddziałach i są przesyłane w krótkich odstępach czasu. W drugim przypadku znaczenie ma kolejność operacji, kontrola powtórzeń a także sposób przechowywania informacji o zaprojektowanych czynnościach. Bardzo dobrze utworzony przepływ musi też rozpoznawać sytuacje, w których faktura nie powinna zostać wysłana, ponieważ dane wejściowe wymagają wcześniejszej korekty. Daje możliwość to oddzielić problemy wynikające z zawartości dokumentu od problemów technicznych związanych z samą komunikacją.
W praktyce szczególnej sugestie wymaga obsługa sytuacji, które nie występują w trakcie typowego przebiegu procesu. Przerwane połączenie, brak odpowiedzi w oczekiwanym czasie czy odrzucenie danych mogą pozostawić użytkownika z pytaniem, jaki jest aktualny stan dokumentu. System nie powinien wówczas opierać się tylko na najprostszym oznaczeniu „wysłano” lub „nie wysłano”. Potrzebne są bardziej precyzyjne informacje, ponieważ ponowne wykonanie tej samej operacji bez sprawdzenia jej wcześniejszego rezultatu może prowadzić do niepożądanych powtórzeń. Z kolei brak mechanizmu ponawiania może wymagać ręcznego wyszukiwania dokumentów, których obsługa została przerwana. Właśnie dlatego przy projektowaniu komunikacji warto od początku uwzględnić rejestrowanie zdarzeń i możliwość odtworzenia przebiegu dokładnie określonej operacji. Taka historia jest przydatna też wtedy, gdy po pewnym czasie powinno się wyjaśnić, dlaczego dany dokument otrzymał konkretny status.
Na sposób działania rozwiązania wpływa także utrzymanie go po uruchomieniu. Integracja nie kończy się w chwili, gdy pierwsza faktura zostanie właściwie przekazana. Zmiany w środowisku, aktualizacje oprogramowania, modyfikacje procesów wewnętrznych czy pojawienie się nowych przypadków obsługi mogą wymagać sprawdzenia dotychczasowych mechanizmów. Ważne jest też rozdzielenie danych testowych od rzeczywistych a także zachowanie sprawdzeniu nad uprawnieniami wykorzystywanymi przez aplikację. W sytuacji większych systemów przydatne są informacje pozwalające szybko ustalić, na którym etapie znajduje się dokument i czy wymaga działania użytkownika. Ma to znaczenie zwłaszcza wtedy, gdy automatyzacja obejmuje kilka kolejnych czynności, a błąd na jednym etapie wpływa na następne. KSeF API jest więc częścią większego procesu technologicznego, w którym sposób przygotowania danych, komunikacja, kontrola statusów i obsługa wyjątków muszą zostać ze sobą odpowiednio związane.
Źródło informacji: dokumentacja KSeF API.