Struktura danych wykorzystywanych przez KSeF API
Wymiana danych pośród programami księgowymi, systemami sprzedażowymi i centralnymi rejestrami wymaga dziś nie tylko dobrego oprogramowania, niemniej jednak też przemyślanego sposobu komunikacji. W sytuacji Krajowego Systemu e-Faktur istotną rolę odgrywa KSeF API, czyli zestaw mechanizmów umożliwiających programom zewnętrznym komunikowanie się z systemem. W praktyce oznacza to, że użytkownik nie musi każdej operacji wykonywać ręcznie w osobnym środowisku, ponieważ określone czynności mogą być wykonywane wprost z poziomu zintegrowanego kodu.
Samo połączenie systemów nie sprowadza się jednak do przesłania dokumentu. Powinno się uwzględnić sposób uwierzytelniania, strukturę danych, obsługę odpowiedzi systemu a także sytuacje, w których komunikacja zostanie przerwana lub przekazane dane okażą się nieprawidłowe.
Integracja z KSeF API wymaga głównie ustalenia, jakie informacje mają być przekazywane i w którym momencie. W najprostszym wariancie system sprzedażowy może przygotować dane faktury, a następnie przekazać je do dobrego interfejsu. Bardziej rozbudowane rozwiązania mogą dodatkowo pobierać informacje o statusie dokumentu, identyfikatorze nadanym przez system czy wynikach przetwarzania. Z praktycznego punktu widzenia ważne jest rozdzielenie tych etapów. Samo wysłanie danych nie powinno być traktowane jako równoznaczne z zakończeniem całego procesu, ponieważ system zewnętrzny musi jeszcze stosownie zareagować na otrzymaną odpowiedź. Jeżeli wystąpi błąd, potrzebna jest informacja pozwalająca ustalić jego przyczynę i zdecydować, czy dokument należy poprawić, przesłać ponownie, czy pozostawić do dalszej obsługi. Ma to znaczenie w szczególności przy większej liczbie faktur, gdzie ręczne sprawdzanie każdego przypadku bardzo szybko staje się czasochłonne.
Przy projektowaniu takiego połączenia warto także uwzględnić różnice pośród środowiskiem testowym a produkcyjnym. Kod odpowiedzialny za komunikację może działać poprawnie w trakcie prób, a pomimo to wymagać dodatkowych przekształceń przed wykorzystaniem w prawdziwym obiegu dokumentów. Znaczenie mają też limity, czas odpowiedzi oraz sposób reagowania na chwilową niedostępność usługi. W świetnie zaplanowanym rozwiązaniu nie zakłada się, że każda operacja zakończy się natychmiastowym powodzeniem. System powinien przechowywać informacje potrzebne do późniejszej sprawdzeniu i pozwalać odtworzyć przebieg operacji. Przydatne okazuje się też logowanie komunikatów technicznych, choć zakres zapisywanych danych trzeba dobrać tak, aby nie zbudować niepotrzebnego zbioru informacji.
Kolejną kwestią jest implementację integracji do sposobu pracy konkretnego przedsiębiorstwa. Przeciwnie może wyglądać przepływ faktur wystawianych pojedynczo, a przeciwnie proces obejmujący setki lub tysiące dokumentów generowanych samoczynnie. W pierwszym przypadku część czynności może pozostać pod kontrolą użytkownika, natomiast przy wielkiej skali większe znaczenie zyskują automatyczne kolejkowanie, ponawianie operacji i monitorowanie statusów. Należy też przewidzieć, co stanie się z dokumentem w systemie źródłowym, gdy przekazanie danych do KSeF zakończy się uchybieniem. Zbyt prosta logika może prowadzić do powstawania rozbieżności wśród lokalną bazą a stanem dokumentów w systemie centralnym. Dlatego KSeF API trzeba traktować nie jako pojedyncze połączenie techniczne, lecz jako szczegół całego procesu obiegu faktur, w którym znaczenie mają zarówno dane wejściowe, komunikacja, jak i dalsze przetwarzanie otrzymanych informacji.
Sprawdź również informacje na stronie: KSeF API dokumentacja.
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.