Wprowadzenie elektronicznego obiegu faktur zmienia sposób, w jaki dane są przekazywane pośród poszczególnymi elementami systemu informatycznego. Wcześniej część czynności mogła polegać na ręcznym przenoszeniu dokumentów, ich sprawdzaniu i zapisywaniu informacji w kilku miejscach. Przy większej liczbie faktur taki model szybko prowadzi do powtarzania tych samych działań.
W tym kontekście KSeF API daje możliwość połączyć system obsługujący sprzedaż lub księgowość z Krajowym Systemem e-Faktur. Nie znaczy to jednak, że po zrealizowaniu technicznego połączenia cały proces staje się automatyczny. Niezbędne jest określenie, jakie dane są przekazywane, kiedy następuje wysyłka, jak zapisywana jest odpowiedź a także co ma się wydarzyć w sytuacji odrzucenia dokumentu. Te decyzje mają wpływ nie tylko i wyłącznie na działanie samej integracji, niemniej jednak również na późniejszą pracę osób zajmujących się fakturami.
Istotnym elementem jest przygotowanie danych jeszcze przed ich przekazaniem do systemu. Faktura może powstawać w programie sprzedażowym na bazie wielu informacji, które pochodzą z różnorakich miejsc. Jeśli któryś z wymaganych elementów jest niepełny lub zapisany w sposób niezgodny z oczekiwaną strukturą, problem może pojawić się dopiero podczas próby wysłania dokumentu. Dlatego integracja z KSeF API wymaga wcześniejszego ustalenia sposobu sprawdzania danych. W praktyce warto rozdzielić kontrolę informacji od samego procesu wysyłki. Umożliwia to łatwiej ustalić, czy przyczyną kłopotu jest błędna faktura, niewłaściwe przygotowanie komunikatu, czy także chwilowy problem z połączeniem. Przy projektowaniu rozwiązania trzeba także zdecydować, które dane powinny zostać zapisane w lokalnym systemie i jak długo mają być dostępne do późniejszego sprawdzenia.
Znaczenie moraz sposób obsługi odpowiedzi otrzymywanych po przesłaniu dokumentu. Sam fakt przekazania danych nie musi oznaczać, że proces został zakończony. System źródłowy powinien rozróżniać co najmniej sytuacje, w których dokument został przyjęty, oczekuje na dalsze przetwarzanie lub wymaga reakcji z powodu błędu. To właśnie tutaj pojawia się sporo praktycznych problemów. Jeśli aplikacja w sposób automatyczny ponawia każdą nieudaną próbę, może dojść do wielokrotnego przesyłania tych samych danych. Jeżeli już natomiast nie ponawia żadnej operacji, chwilowa przerwa w komunikacji może pozostawić dokument bez następnej obsługi. Niezbędny jest zatem mechanizm, który umożliwi rozpoznać rodzaj kłopotu i dobrać odpowiednią reakcję. Przy większej liczbie dokumentów przydatne staje się również prowadzenie historii operacji, ponieważ bez niej postanowienie, co wydarzyło się z konkretną fakturą, może wymagać ręcznego porównywania danych z kilku systemów.
Osobnego podejścia wymaga obsługa zmian w samym środowisku integracyjnym. Interfejsy programistyczne, formaty danych i zasady komunikacji mogą być uaktualniane, dlatego rozwiązanie przygotowane raz nie powinno być traktowane jako element całkowicie bezobsługowy. W praktyce potrzebne są testy po zmianach, kontrola komunikatów a także okresowe sprawdzanie, czy proces wciąż odpowiada rzeczywistemu obiegowi dokumentów. Warto też uwzględnić sytuacje nietypowe, tj. korekta faktury, ponowienie operacji po przerwie technicznej czy ręczna ingerencja użytkownika w dokument zaprojektowany automatycznie. Im więcej czynności kreuje system bez udziału człowieka, tym ważniejsze staje się określenie momentów, w których użytkownik może sprawdzić status i przejąć obsługę konkretnego przypadku. Dzięki temu integracja nie jest rozpatrywana jedynie jako wymiana komunikatów między dwoma programami, lecz jako część szerszego procesu zarządzania dokumentami i informacjami o ich statusie.
Dodatkowe informacje: integracja z KSeF API.