Sposób przetwarzania faktur coraz częściej uzależniony jest od współpracy kilku różnorakich programów. Dokument może zostać wytworzony 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 istotne staje się nie tylko przechowywanie dokumentów, ale też kontrolowanie ich przepływu wśród poszczególnymi rozwiązaniami.

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

Jednym z częstszych problemów jest różnica pośród strukturą danych wykorzystywaną wewnętrznie a formatem wymaganym w trakcie konwersji 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. Znaczy to, że w gronie źródłem danych a interfejsem może być potrzebny dodatkowy odcinek przekształcenia. Nie warto zakładać, że wszystkie informacje można przekazać bez przekształceń. 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 już 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 równocześnie wymaga dodatkowej logiki w systemie.

Istotnym zagadnieniem jest także kontrolowanie statusem dokumentu. W codziennej pracy łatwo przyjąć uproszczenie, zgodnie z którym kliknięcie przycisku wysyłki oznacza 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 oraz przypadek zakończony prawidłowo. W szczególności ważne staje się to wtedy, gdy odpowiedź nie dociera w przewidywanym czasie. Automatyczne ponowienie wysyłki bez wcześniejszego ustalenia stanu operacji może spowodować powielenie czynności, jednakże 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 a także reagowania na różnorakie typy problemów. Przy większej liczbie faktur takie rozwiązania przestają być dodatkiem i stają się elementem potrzebnym do aktualnej kontroli procesu.

Warto prócz tego pamiętać, że działanie integracji zależy także od zmian zachodzących oprócz samym systemem źródłowym. Aktualizowanie 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ę jedynie do pierwszego uruchomienia. Przydatne jest sprawdzanie zarówno standardowych faktur, jak i sytuacji, w których dokument zostaje odrzucony, wymaga ponownego przetworzenia lub nie otrzymuje odpowiedzi w oczekiwanym czasie. Równie ważna jest możliwość znalezienia dokładnie określonej operacji w historii systemu. Bez odpowiednich zapisów uwarunkowanie, co wydarzyło się z dokumentem kilka dni uprzednio, może być trudne. W praktyce znaczy to potrzebę zachowania równowagi pomiędzy automatyzacją a kontrolą użytkownika. System może wykonywać powtarzalne czynności, ale powinien także 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.

Sprawdź: KSeF API.