Integracja KSeF, ktora dziala rowniez wtedy, gdy system Ministerstwa Finansow nie dziala

KSeF zmienia sposob wystawiania i odbierania faktur w Polsce - z dokumentu PDF czy papieru na ustrukturyzowany XML w schemacie FA(3), przechodzacy przez centralny system Ministerstwa Finansow. Projektuje i wdrazam integracje KSeF dla firm korzystajacych z Subiekta, Comarch ERP (Optima, XL), BaseLinkera oraz systemow wlasnych - z naciskiem na kolejkowanie, walidacje przed wyslaniem, retry i pelna sciezke awaryjna, gdy API MF odpowiada wolno lub wcale.

Czym jest KSeF i faktura ustrukturyzowana

Krajowy System e-Faktur (KSeF) to centralna platforma Ministerstwa Finansow do wystawiania, przesylania i przechowywania faktur w formie ustrukturyzowanej. W praktyce oznacza to, ze faktura przestaje byc plikiem PDF wygenerowanym przez Twoj system i wyslanym mailem - staje sie dokumentem XML zgodnym ze scisla struktura logiczna, ktory trafia do systemu KSeF, tam jest walidowany, numerowany (numer KSeF) i udostepniany odbiorcy. Dla dzialow ksiegowosci i IT oznacza to nowy element w lancuchu procesow: wystawienie faktury w ERP nie konczy sprawy - dokument musi zostac poprawnie zserializowany, uwierzytelniony i wyslany do API KSeF, a nastepnie system musi obsluzyc odpowiedz (numer KSeF, ewentualne bledy walidacji, UPO).

Format FA(3) i struktura XML

Aktualna wersja schematu to FA(3) - ustandaryzowana struktura logiczna okreslajaca kazde pole faktury: dane sprzedawcy i nabywcy, pozycje towarowe, stawki VAT, warunki platnosci, adnotacje szczegolne (np. mechanizm podzielonej platnosci, odwrotne obciazenie). Przy integracji kluczowe jest poprawne mapowanie danych z ERP na strukture XML - w tym pola opcjonalne, ktore czesto sa pomijane w starych systemach fakturowania, ale sa wymagane albo warunkowo wymagane przez schema FA(3). Buduje warstwe mapowania, ktora tlumaczy rekordy z bazy danych klienta (Subiekt, Comarch, baza SQL wlasnego systemu) na poprawny strukturalnie XML, oraz waliduje go lokalnie wzgledem oficjalnego schematu XSD przed wyslaniem - zeby odrzucenia przez KSeF byly wyjatkiem, a nie codziennoscia.

KSeF API: autoryzacja, tokeny, srodowisko testowe

Komunikacja z KSeF odbywa sie przez API REST udostepniane przez Ministerstwo Finansow, z osobnym srodowiskiem testowym i produkcyjnym. Autoryzacja opiera sie na tokenach (token KSeF lub podpis kwalifikowany/pieczec przy pierwszym uwierzytelnieniu), a sesja interaktywna lub wsadowa musi byc poprawnie zarzadzana - w tym odswiezanie sesji, obsluga limitow czasowych i kolejkowanie wysylek przy wiekszym wolumenie faktur. Kazde wdrozenie zaczynam od srodowiska testowego KSeF, gdzie sprawdzam pelny cykl: uwierzytelnienie, wyslanie faktury, odbior numeru KSeF i UPO, obsluge bledow walidacji - zanim cokolwiek trafi na produkcje.

Integracja z ERP

Wiekszosc firm nie chce recznie przepisywac faktur do osobnego portalu KSeF - potrzebuje, zeby integracja dzialala w tle, wpieta bezposrednio w system, ktorego juz uzywa. Dla systemow ERP (w tym rozwiazan wlasnych i mniej popularnych na rynku) buduje most integracyjny, ktory czyta dane fakturowe bezposrednio z bazy danych lub przez API ERP, generuje XML FA(3), wysyla do KSeF i zapisuje z powrotem numer KSeF oraz status w systemie zrodlowym. Cel jest prosty: ksiegowosc i handlowcy pracuja dalej w znanym interfejsie, a KSeF staje sie niewidoczna warstwa techniczna pod spodem.

Integracja z Subiektem (Insert GT/nexo)

Subiekt GT i Subiekt nexo sa szeroko uzywane w mniejszych i srednich firmach handlowych w Polsce, ale nie maja natywnego, w pelni samodzielnego mechanizmu integracji z KSeF spelniajacego wszystkie wymagania wiekszych organizacji (kolejkowanie masowe, retry, logi audytowe). Buduje warstwe posrednia, ktora podpina sie pod baze Subiekta (MS SQL), przechwytuje wystawione faktury, generuje z nich poprawny XML i zarzadza cala komunikacja z KSeF, a status wysylki oraz numer KSeF wraca do widoku dokumentu w Subiekcie.

Integracja z Comarch ERP (Optima, XL)

Comarch oferuje wlasne moduły KSeF w ramach Optimy i ERP XL, ale w praktyce wiele firm ma niestandardowe procesy fakturowania, wielospolkowe struktury, integracje z hurtowniami danych lub systemami BI, ktore wymagaja dodatkowej warstwy logiki ponad standardowy modul. Zajmuje sie rozszerzaniem i dostrajaniem integracji KSeF wokol Comarch ERP: mapowaniem niestandardowych pol, obsluga wielu podmiotow (multi-firma) w jednym procesie wysylkowym, oraz spinaniem KSeF z innymi systemami (hurtownia danych, raportowanie, system WMS/CRM), tak aby numer KSeF i status faktury byly dostepne wszedzie tam, gdzie sa potrzebne.

Integracja z BaseLinker

BaseLinker jest centrum zarzadzania sprzedazu dla wielu sklepow e-commerce, ktore generuja duze wolumeny faktur w krotkim czasie, czesto z wielu kanalow sprzedazy jednoczesnie (Allegro, Amazon, wlasny sklep). Standardowe podejscie "jedna faktura na raz" nie skaluje sie przy setkach lub tysiacach zamowien dziennie. Buduje integracje, ktora podpina sie pod API BaseLinkera, agreguje dane zamowien i faktur, generuje XML FA(3) w partiach, wysyla je do KSeF z kontrolowanym tempem (rate limiting) i zwraca numery KSeF do zamowien w BaseLinkerze - z pelnym logiem tego, co poszlo, co czeka w kolejce, a co wymaga recznej interwencji.

Tryb awaryjny i obsluga bledow

System KSeF, jak kazde API rzadowe o duzej skali, moze byc niedostepny lub odpowiadac z opoznieniem - przepisy przewiduja tryb awaryjny i offline dla takich sytuacji, ale zaimplementowanie go poprawnie po stronie firmy to osobne zadanie inzynierskie. Kazda integracja, ktora buduje, ma wbudowana kolejke odporna na awarie: jesli KSeF nie odpowiada, faktura nie ginie ani nie blokuje sprzedazy - trafia do kolejki retry z rosnacym opoznieniem (exponential backoff), a caly proces jest logowany, wiec w kazdej chwili wiadomo, ktore dokumenty czekaja, ktore zostaly odrzucone przez walidacje, a ktore wymagaja recznej korekty danych.

Jak wyglada wdrozenie ze mna: SQL bridge, kolejkowanie, logi, retry

Wiekszosc moich integracji KSeF opiera sie na architekturze, ktora nazywam SQL bridge: lekki, dedykowany komponent, ktory czyta dane bezposrednio z bazy systemu zrodlowego (Subiekt, Comarch, baza wlasna), buduje z nich poprawny XML, zarzadza kolejka wysylek do KSeF i zapisuje wynik z powrotem do tej samej bazy. Takie podejscie ma trzy zalety: nie wymaga przebudowy istniejacego systemu ERP, dziala niezaleznie od dostepnosci API KSeF (kolejka buforuje), i daje pelna widocznosc - kazdy krok (odczyt, walidacja, wysylka, odpowiedz, zapis) jest logowany z osobnym identyfikatorem, co pozwala odtworzyc dokladnie, co sie stalo z kazda fakturą, nawet miesiace po fakcie.