Konfiguracja komunikacji z KSeF API
Sposób przetwarzania faktur bardzo często zależy 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 ważne staje się nie tylko i wyłącznie przechowywanie dokumentów, niemniej jednak także administrowanie ich przepływu poś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 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 dalszej obsługi. Właściwie 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 później przechodzi do kwestii związanych z samym połączeniem technicznym.
Jednym z częstszych problemów jest różnica wśród strukturą danych wykorzystywaną wewnętrznie a formatem wymaganym podczas 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. Oznacza to, że w gronie źródłem danych a interfejsem może być niezbędny dodatkowy odcinek przekształcenia. Nie warto zakładać, że wszystkie informacje można przekazać bez przeróbek. W praktyce znaczenie mają też 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ż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 daje możliwość dokładniej ustalić, gdzie wystąpiła nieprawidłowość, choć równocześnie wymaga dodatkowej logiki w systemie.
Istotnym zagadnieniem jest również administrowanie statusem dokumentu. W codziennej pracy łatwo przyjąć uproszczenie, w zgodzie z którym kliknięcie przycisku wysyłki oznacza zakończenie operacji. Przy automatycznej wymianie danych takie założenie może jednakże 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. Szczególnie 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 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óżnorodne typy problemów. Przy większej liczbie faktur takie rozwiązania przestają być dodatkiem i stają się elementem potrzebnym do obowiązującej sprawdzeniu procesu.
Warto a przy tym pamiętać, że działanie integracji zależy też od modyfikacji zachodzących poza samym systemem źródłowym. Uaktualnienie 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 albo nie otrzymuje odpowiedzi w oczekiwanym czasie. Równie na prawdę ważna jest sposobność znalezienia dokładnie sprecyzowanej operacji w historii systemu. Bez odpowiednich zapisów ustalenie, co wydarzyło się z dokumentem kilka dni uprzednio, może być trudne. W praktyce oznacza to potrzebę zachowania równowagi pośród automatyzacją a kontrolą użytkownika. System może wykonywać powtarzalne czynności, niemniej jednak powinien też 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.
Polecam: KSeF API.