KSeF API a wymiana danych z systemami księgowymi
Zmiana sposobu obsługi faktur wpływa też 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 albo raportowaniu. Przy takim układzie ręczne przepisywanie informacji staje się kolejnym etapem procesu, w którym mogą pojawić się rozbieżności.
KSeF API służy do komunikacji pomiędzy zewnętrznym oprogramowaniem a Krajowym Systemem e-Faktur. Z punktu widzenia użytkownika istotne jest jednakże nie samo techniczne połączenie, lecz sposób włączenia go w istniejący wymianę dokumentów. Powinno się 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 de facto mogą być wykonywane samoczynnie, 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ć wykonana właściwie w systemie sprzedażowym, ale przed jej przekazaniem dalej konieczne może być sprawdzenie określonych pól i zależności pomiędzy nimi. Integracja z KSeF API nie powinna zatem być projektowana w oderwaniu od danych, które już znajdują się w zakładzie usługowym. W praktyce różnice w sposobie zapisu numerów, stawek, dat czy danych kontrahenta mogą wymagać dodatkowego przekształcenia informacji. Zdarza się, że problemem nie jest brak danych, lecz ich nadmiar albo sposób, w jaki zostały zapisane w systemie źródłowym. O ile takie kwestie zostaną pominięte na etapie projektowania, usterki mogą pojawić się dopiero w trakcie wysyłki dokumentów. Ich późniejsze szukanie jest bardziej kłopotliwe, szczególnie gdy proces obejmuje dużą liczbę faktur generowanych automatycznie.
Osobnego potraktowania wymaga sytuacja, w której odpowiedź systemu nie pojawia się od razu albo przekazane informacje wymagają dalszego przetworzenia. Łatwy 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 aby 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 dalszej obsługi. Z tego powodu system powinien posiadać określone zasady reagowania na różnorodne rodzaje odpowiedzi i błędów, a informacje o utworzonych operacjach powinny być dostępne do późniejszej testom.
Na ostateczny 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 mieć sposobność sprawdzenia danych, zobaczenia aktualnego statusu dokumentu oraz 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 a także sytuacje związane z czasową niedostępnością poszczególnych elementów systemu. Integracja z KSeF API jest więc nie tylko i wyłącznie celem programistycznym. Obejmuje również sposób zarządzania dokumentami, kontrolę danych wejściowych, obsługę wyjątków a także zobowiązanie, kiedy system funkcjonuje poświęcając własny czas, a kiedy przekazuje sprawę do użytkownika.
Zobacz także: dokumentacja KSeF API.
Category: Technologie
