Sposób przetwarzania faktur bardzo często uzależniony jest od współpracy kilku różnych skryptów. Dokument może zostać zaprojektowany 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 i wyłącznie przechowywanie dokumentów, niemniej jednak też zarządzanie 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 konieczne jest natomiast 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 dalszej obsługi. Właściwie każdy z owych etapów może wymagać osobnego mechanizmu kontroli. Właśnie dlatego projektowanie takiego rozwiązania zaczyna się zwykle od analizy istniejącego obiegu faktur, a dopiero w przyszłości 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 podmiany informacji. System sprzedażowy może przechowywać dane w sposób wygodny dla użytkownika, jednakże 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 stopień przekształcenia. Nie warto zakładać, że wszystkie informacje można przekazać bez przeróbek. W praktyce znaczenie mają także sytuacje nietypowe, tj. 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śli kontrola danych odbywa się dopiero podczas 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 daje możliwość dokładniej ustalić, gdzie wystąpiła nieprawidłowość, choć jednocześ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 znaczy 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. Zwłaszcza istotne 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 wyników a także reagowania na różnorodne typy problemów. Przy większej liczbie faktur takie rozwiązania przestają być dodatkiem i stają się elementem potrzebnym do bieżącej kontroli procesu.
Warto a przy tym pamiętać, że działanie integracji zależy także od przemian 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ę wyłącznie 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 bardzo ważna jest sposobność znalezienia dokładnie określonej operacji w historii systemu. Bez odpowiednich zapisów uwarunkowanie, co wydarzyło się z dokumentem kilka dni przedtem, może być trudne. W praktyce znaczy to potrzebę zachowania równowagi w gronie automatyzacją a kontrolą użytkownika. System może wykonywać powtarzalne czynności, niemniej jednak 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.
Źródło informacji: integracja z KSeF API.
