Przeniesienie obiegu faktur do środowiska cyfrowego zmienia nie tylko i wyłącznie sposób wystawiania dokumentów, ale 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śli jednym z etapów jest komunikacja z Krajowym Systemem e-Faktur, pojawia się potrzeba połączenia programu używanego wewnętrznie z zewnętrznym środowiskiem.
KSeF API służy właśnie do takiej konwersji 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 wiedzieć, kiedy dokument jest gotowy do wysłania, jakie dane trzeba przekazać i co zrobić z informacją otrzymaną po zrealizowaniu operacji. W praktyce świetnie zaplanowany proces uwzględnia także przypadki, w których faktura zostaje zmieniona przed wysyłką albo wymaga dodatkowej kontroli. Dzięki temu decyzje dotyczące dokumentu nie są podejmowane wyłącznie na bazie tego, czy techniczne połączenie z systemem zostało nawiązane.
Różnice pomiędzy 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 wymagania. Z tego powodu integracja z KSeF API na prawdę często wymaga warstwy, która pobiera dane z jednego systemu, kontroluje je i kreuje komunikat w stosownej strukturze. Na tym etapie wychodzą na jaw kłopoty, których nie widać w trakcie zwykłego wystawiania faktury. W podstawie może znajdować się wartość dopuszczalna dla użytkownika, ale wymagająca odpowiedniego przekształcenia przed przekazaniem. Czasami wystarczy niewielka różnica w zapisie, aby dokument wymagał dodatkowej obsługi. Dlatego warto rozdzielić kontrolę danych od samej wysyłki. Jeżeli 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ę w przyszłości. W prostym rozwiązaniu można zapisać jedynie informację o zrobieniu wysyłki, lecz przy większej liczbie operacji szybko okazuje się to niewystarczające. Przydatne staje się rozróżnienie wśród rozpoczęciem operacji, jej przekazaniem do przetwarzania, uzyskaniem wyniku a także wystąpieniem błędu. Takie podejście ułatwia również obsługę przerw w komunikacji. Jeżeli już aplikacja nie otrzyma odpowiedzi, nie zawsze można od razu uznać, że dokument nie został przekazany. Automatyczne powtórzenie działania także 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 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 automatycznie, a które powinny natrafić do ręcznej testom.
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, natomiast 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 umożliwia uniknąć sytuacji, w której chwilowy problem zatrzymuje cały wymianę dokumentów, choćby wymaga dodatkowego mechanizmu testom i obsługi zaległych zadań. Znaczenie ma także sposobność odtworzenia historii konkretnej 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 również testowanie zmian w konfiguracji a także aktualizacji oprogramowania na przykładach obejmujących zarówno właściwe, 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 kontroli a także obsługą użytkownika, zamiast działać jako odizolowany moduł.
Zobacz także: KSeF API integracja.