Przeniesienie obiegu faktur do środowiska cyfrowego zmienia nie tylko i wyłącznie sposób wystawiania dokumentów, niemniej jednak również 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ę potrzeba połączenia skryptu używanego wewnętrznie z zewnętrznym środowiskiem.
KSeF API służy właśnie do takiej podmiany danych. Warto jednakże patrzeć na nie jako na część większego procesu, a nie samodzielną funkcję odpowiedzialną za całą obsługę faktury. Program musi mieć świadomość tego, kiedy dokument jest gotowy do wysłania, jakie dane powinno się przekazać i co zrobić z informacją otrzymaną po zrealizowaniu operacji. W praktyce bardzo dobrze zaplanowany proces uwzględnioraz przypadki, w których faktura zostaje zmieniona przed wysyłką albo wymaga dodatkowej testom. Dzięki temu decyzje dotyczące dokumentu nie są podejmowane jedynie na bazie tego, czy techniczne połączenie z systemem zostało nawiązane.
Różnice pośród systemami stają się widoczne zwłaszcza w trakcie przygotowywania danych. Program sprzedażowy może korzystać z własnych nazw pól, oznaczeń produktów czy sposobu zapisywania informacji o kontrahencie. Format przekazywany dalej ma jednak określone wymagania. Z tego powodu integracja z KSeF API często wymaga warstwy, która pobiera dane z jednego systemu, testuje je i wykonuje komunikat w stosownej strukturze. Na tym etapie wychodzą na jaw kłopoty, których nie widać podczas powszechnego wystawiania faktury. W podstawie może znajdować się wartość dopuszczalna dla użytkownika, niemniej jednak wymagająca odpowiedniego przekształcenia przed przekazaniem. Zdarza się, że wystarczy niewielka różnica w zapisie, by dokument wymagał dodatkowej obsługi. Dlatego warto rozdzielić kontrolę danych od samej wysyłki. Jeżeli już 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 istotna jest informacja zwrotna. Po przekazaniu dokumentu system źródłowy powinien zachować dane pozwalające ustalić, co wydarzyło się później. W najprostszym rozwiązaniu można zapisać tylko informację o zrobieniu 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 także obsługę przerw w komunikacji. Jeżeli aplikacja nie otrzyma odpowiedzi, nie zawsze można w tym samym momencie uznać, że dokument nie został przekazany. Automatyczne powtórzenie działania też 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 stworzenia operacji. W praktyce niezbędny jest zatem mechanizm, który daje możliwość rozróżnić usterki 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 a także 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 pozwala uniknąć sytuacji, w której chwilowy problem zatrzymuje cały obieg dokumentów, choćby wymaga dodatkowego mechanizmu testom i obsługi zaległych obowiązków. Znaczenie ma również sposobność odtworzenia historii dokładnie sprecyzowanej faktury. Po kilku dniach użytkownik powinien móc sprawdzić, kiedy dokument został utworzony, jakie dane zostały przekazane i jaki rezultat zwrócił system. Przydatne jest także testowanie zmian w konfiguracji a także aktualizacji oprogramowania przykładowoach obejmujących zarówno prawidłowe, jak i problematyczne przypadki. Wówczas KSeF API pozostaje jednym z elementów procesu, który musi współpracować z bazą danych, systemem sprzedażowym, mechanizmami sprawdzeniu oraz obsługą użytkownika, zamiast działać jako odizolowany moduł.
Dodatkowe informacje: dokumentacja KSeF API.