Przeniesienie obiegu faktur do środowiska cyfrowego zmienia nie tylko i wyłącznie sposób wystawiania dokumentów, ale także organizację pracy z informacjami. W firmowym systemie faktura może powstać jako wynik zlecenia, sprzedaży albo innego zdarzenia gospodarczego, a następnie zostać przekazana do kolejnych modułów. Jeżeli już jednym z etapów jest komunikacja z Krajowym Systemem e-Faktur, pojawia się wymaganie połączenia programu używanego wewnętrznie z zewnętrznym środowiskiem.
KSeF API służy właśnie do owej zamiany danych. Warto natomiast patrzeć na nie jako na część większego procesu, a nie samodzielną funkcję odpowiedzialną za całą obsługę faktury. Program musi wiedzieć, kiedy dokument jest gotowy do wysłania, jakie dane trzeba przekazać i co zrobić z informacją otrzymaną po wykonaniu operacji. W praktyce bardzo dobrze zaplanowany proces uwzględnioraz przypadki, w których faktura zostaje zmieniona przed wysyłką lub wymaga dodatkowej kontroli. Dzięki temu decyzje dotyczące dokumentu nie są podejmowane wyłącznie na podstawie tego, czy techniczne połączenie z systemem zostało nawiązane.
Różnice w gronie systemami stają się widoczne zwłaszcza w trakcie przygotowywania danych. Program sprzedażowy może skorzystać z własnych nazw pól, oznaczeń towarów czy sposobu zapisywania informacji o kontrahencie. Format przekazywany dalej ma jednak określone oczekiwania. Z tego powodu integracja z KSeF API często wymaga warstwy, która pobiera dane z jednego systemu, kontroluje je i wykonuje komunikat w odpowiedniej strukturze. Na tym etapie wychodzą na jaw problemy, których nie widać w trakcie zwykłego wystawiania faktury. W podstawie może znajdować się wartość dopuszczalna dla użytkownika, niemniej jednak wymagająca odpowiedniego przekształcenia przed przekazaniem. W pewnych przypadkach wystarczy niewielka różnica w zapisie, aby dokument wymagał dodatkowej obsługi. Dlatego warto rozdzielić kontrolę danych od samej wysyłki. O ile aplikacja potrafi wskazać, że problem powstał jeszcze przed rozpoczęciem komunikacji, łatwiej zdecydować, co trzeba poprawić. Ma to szczególne znaczenie przy automatycznym wystawianiu wielu dokumentów, ponieważ jeden błąd w regule przetwarzania może dotyczyć całej serii faktur.
Nie mniej na prawdę istotna jest informacja zwrotna. Po przekazaniu dokumentu system źródłowy powinien zachować dane pozwalające ustalić, co wydarzyło się później. W prostym rozwiązaniu można zapisać tylko informację o wykonaniu wysyłki, lecz przy większej liczbie operacji bardzo szybko okazuje się to niewystarczające. Przydatne staje się rozróżnienie pomiędzy rozpoczęciem operacji, jej przekazaniem do przetwarzania, uzyskaniem wyniku a także wystąpieniem błędu. Takie podejście ułatwia też obsługę przerw w komunikacji. Jeżeli aplikacja nie otrzyma odpowiedzi, nie zawsze można od razu uznać, że dokument nie został przekazany. Automatyczne powtórzenie działania również nie powinno następować bez sprawdzenia wcześniejszego stanu, ponieważ brak odpowiedzi może wynikać z kłopotu po stronie komunikacji, a nie z braku utworzenia operacji. W praktyce potrzebny jest więc mechanizm, który daje możliwość rozróżnić błędy danych od problemów technicznych i określić, które przypadki mogą zostać obsłużone samoczynnie, a które powinny trafić do ręcznej kontroli.
Na sposób działania całego procesu wpływa także liczba dokumentów oraz moment, w którym są one generowane. Przy kilku fakturach dziennie możliwa jest bieżąca obserwacja, jednak większy wolumen wymaga innej organizacji pracy. Zadania mogą być umieszczane w kolejce, a aplikacja może przetwarzać je etapami, zapisując wynik każdej operacji. Takie rozwiązanie daje możliwość uniknąć sytuacji, w której chwilowy problem zatrzymuje cały obieg dokumentów, choć wymaga dodatkowego mechanizmu testom i obsługi zaległych zadań. Znaczenie ma również możliwość odtworzenia historii dokładnie określonej faktury. Po kilku dniach użytkownik powinien móc sprawdzić, kiedy dokument został stworzony, jakie dane zostały przekazane i jaki rezultat zwrócił system. Przydatne jest również testowanie modyfikacji w konfiguracji a także aktualizacji oprogramowania przykładowoach obejmujących zarówno prawidłowe, jak i problematyczne przypadki. Wtedy KSeF API pozostaje jednym z elementów procesu, który musi współpracować z bazą danych, systemem sprzedażowym, mechanizmami kontroli a także obsługą użytkownika, zamiast działać jako odizolowany moduł.
Źródło: KSeF API integracja.