Zmiana sposobu obsługi faktur wpływa również na to, jak systemy informatyczne wymieniają między sobą dane. W wielu organizacjach dokument powstaje w jednym programie, informacje o nim są następnie przekazywane do kolejnego systemu, a część danych może być jeszcze wykorzystywana w księgowości lub raportowaniu. Przy takim układzie ręczne przepisywanie informacji staje się dalszym etapem procesu, w którym mogą pojawić się rozbieżności.

KSeF API służy do komunikacji pośród zewnętrznym oprogramowaniem a Krajowym Systemem e-Faktur. Z punktu widzenia użytkownika ważne jest natomiast nie samo techniczne połączenie, lecz sposób włączenia go w istniejący przepływ dokumentów. Należy określić, z którego systemu pobierane są dane, kiedy następuje ich przekazanie oraz w jaki sposób wynik operacji jest zapisywany. Dopiero wtedy można wycenić, które czynności faktycznie mogą być wykonywane w sposób automatyczny, a które nadal wymagają udziału pracownika.

W przypadku większej liczby dokumentów szczególnego znaczenia nabiera kolejność wykonywanych operacji. Faktura może zostać stworzona poprawnie w systemie sprzedażowym, ale przed jej przekazaniem dalej niezbędne może być sprawdzenie określonych pól i zależności wśród nimi. Integracja z KSeF API nie powinna więc być projektowana w oderwaniu od danych, które już znajdują się w przedsiębiorstwie. W praktyce różnice w sposobie zapisu numerów, stawek, dat czy danych kontrahenta mogą wymagać dodatkowego przekształcenia informacji. W pewnych sytuacjach kłopotem nie jest brak danych, lecz ich nadmiar albo sposób, w jaki zostały zapisane w systemie źródłowym. Jeżeli już takie kwestie zostaną pominięte na etapie projektowania, niedociągnięcia mogą pojawić się dopiero w trakcie wysyłki dokumentów. Ich późniejsze wyszukiwanie jest bardziej kłopotliwe, zwłaszcza gdy proces obejmuje dużą liczbę faktur generowanych automatycznie.

Osobnego potraktowania wymaga sytuacja, w której odpowiedź systemu nie pojawia się zaraz albo przekazane informacje wymagają dalszego przetworzenia. Intuicyjny mechanizm, który po wysłaniu dokumentu zmienia jego status na „zakończony”, może nie odzwierciedlać faktycznego stanu operacji. Znacznie praktyczniejsze jest rozróżnienie etapów, tak ażeby można było ustalić, czy dokument został przygotowany, przekazany, przetworzony, czy również wystąpił problem wymagający sprawdzenia. Ma to znaczenie też przy ponawianiu operacji. Oczywiście nie każdy błąd powinien prowadzić do automatycznej ponownej wysyłki, ponieważ są przypadki w których przyczyną jest zawartość dokumentu i ponowienie niczego nie zmieni. Z kolei przy problemie chwilowym brak ponowienia może pozostawić dokument bez następnej obsługi. Z tego powodu system powinien posiadać określone zasady reagowania na różnorakie rodzaje odpowiedzi i błędów, a informacje o zaprojektowanych operacjach powinny być dostępne do późniejszej sprawdzeniu.

Na końcowy kształt rozwiązania wpływa także sposób pracy osób korzystających z systemu. Automatyzacja części czynności nie znaczy, że użytkownik przestaje być potrzebny. W określonych przypadkach powinien posiadać możliwość sprawdzenia danych, zobaczenia aktualnego statusu dokumentu a także ustalenia, dlaczego dana operacja nie została wykonana. Przy większej skali działania przydatne są rejestry zdarzeń, które pozwalają odtworzyć przebieg komunikacji bez konieczności analizowania całej bazy dokumentów. Warto też uwzględnić zmiany techniczne, testowanie nowych wersji oraz sytuacje powiązane z czasową niedostępnością poszczególnych elementów systemu. Integracja z KSeF API jest zatem nie tylko misją programistycznym. Obejmuje także sposób zarządzania dokumentami, kontrolę danych wejściowych, obsługę wyjątków a także postanowienie, kiedy system działa własną pracą, a kiedy przekazuje sprawę do użytkownika.

Źródło: KSeF API integracja.