0

Jak u was działa automatyczne pobieranie faktur kosztowych z KSeF?

FakturyBezStresu15 lut0 wyświetleń

Cześć,

Buduję w startupie system do automatycznego pobierania faktur kosztowych z KSeF i zastanawiam się jak to robią inni. Mamy już działającą integrację dla faktur sprzedażowych (wysyłka), ale z kosztowymi jest trochę inaczej.

Na razie mam proof of concept, który:

- Co godzinę odpytuje endpoint `/api/online/Query/Invoice/Async` z zakresem dat

- Dostaje listę referencji faktur

- Dla każdej faktury pobiera XML przez `/api/online/Invoice/Get/{referenceNumber}`

- Parsuje XML (FA(2)) i wrzuca do bazy

Działa, ale widzę kilka problemów:

1. **Jak częste powinno być odpytywanie?** Co godzinę to sensowne czy za często? Nie chce obciążać API bez sensu

2. **Czy ktoś używa webhooków?** Widziałem w dokumentacji coś o powiadomieniach, ale nie ogarnąłem do końca jak to działa

3. **Jak radzicie sobie z duplikatami?** Czasami ta sama faktura pojawia się dwa razy w wynikach query (może to bug demo?)

4. **OCR vs XML** - widzę że niektórzy robią OCR na PDF zamiast parsować XML. Czemu? XML wydaje się prostszy

W demo czasami dostaje 504 przy dużych zapytaniach, więc pewnie będę musiał dodać retry logic. Jakieś best practices?

Dzięki za pomoc!

4 odpowiedzi

0
VATowiec15 lut
Hej, u nas w fundacji też implementowaliśmy pobieranie faktur kosztowych, ale trochę inaczej niż w startupie - mamy mniejsze wolumeny więc może moje doświadczenia będą mniej użyteczne. Co do częstotliwości - my odpytujemy raz dziennie rano, bo po prostu nie mamy takiego przepływu faktur żeby to miało sens robić częściej. W startupie pewnie zależy ile macie kontrahentów i jak często wystawiają faktury. Co godzinę wydaje mi się przesadą, chyba że naprawdę macie duży ruch. MF pewnie nie będzie zadowolone jak wszyscy zaczną bombardować API co 5 minut ;) Duplikaty - tak, widzę to samo w demo. Sprawdzam po numerze KSeF (ten z `<KodUrzedu>`) przed wrzuceniem do bazy i jak już jest to ignoruję. Nie wiem czy to bug demo czy tak będzie działać produkcja, ale lepiej się zabezpieczyć. OCR vs XML - szczerze nie rozumiem po co ktoś miałby robić OCR jak ma strukturalny XML. Jedyny powód jaki mi przychodzi do głowy to jak mają już gotowy pipeline do pdfów i nie chcą robić nowego parsera? Ale to wydaje się strzałem w stopę. Webhooków nie używamy, w ogóle nie badałam tego tematu bo nam wystarcza proste polling.
0
U nas w biurze mamy już to wdrożone dla kilkudziesięciu klientów i mogę podzielić się doświadczeniami: **Częstotliwość** - zależy od klienta. Dla małych firm wystarczy raz dziennie, ale mamy klku klientów z dużym obrotem gdzie odpytujemy co 2-3 godziny. Co godzinę to faktcyznie przesada dla większości przypadków. My ustaliliśmy harmonogram w zależności od profilu działalności - handel detaliczny częściej, uługi B2B rzadziej. **Duplikaty** - to nie tylko problem demo, widzimy to też w testach produkcyjnych. Mamy prostą logikę: sprawdzamy czy numer faktury + NIP wystawcy + data już istnieje w bazie. Czasami MF zwraca tę samą fakturę w różnych requestach, zwłaszcza przy zapytaniach na granicy okresów. **OCR vs XML** - totalnie nie rozumiem tego podejścia. XML daje ci wszystkie dane strukturalnie, po co robić sobie życie trudniejsze? Może ktoś ma legacy system który już przetwarza PDFy i nie cchce przepisywać? Ale to krótkowzroczne myślenie. Jedna rzecz której nie widzę w twoim PoC - jak radzisz sobie z błędami walidacji XML? Czasami MF zwraca dziwne struktury które nie przechodzą przez standardowy parser FA(2). Musieliśmy ddać kilka workaroundów. A retry logic to podstawa - 504 w demo to norma, zwłaszcza przy większych zakresach dat. My mamy exponential backoff z maksymalnie 3 próbami.
0
AlicjaKowal3 dni temu
Dodając do tego co już zostało napisane - u nas w biurez z 50+ klientami też mieliśmy ppodobne dylmaty przy wdrażaniu. **Częstotliwość**: Rozwiązaliśmy to profilami klientów. Mały zakład fryzjerski - raz dziennie wieczorem. Duży dystrybutor - co 4 godziny w godzinach pracy. Ustawiliśmy to tak żeby nie wszyscy klienci odpytywali jednocześnie, bo inaczej API MF paa w godzinach szczytu. Co do **webhooków** - testowałam to w demo i szczerze mówiąc wiięcej problemów niż korzyści. Musisz mieć publiczny endpoint, SSL, obsługę błędów... przy tym polling jest prostszy i bardziej przewidywalny. Może w przyszłości jak MF dopracuje dokumentację. **Duplikaty** - dokładnie tak jak piszecie, u nas też się zdarzają. Kluczem jest dobra logika deduplikacji. My sprawdzamy nie tyklo numer KSeF ale też hash z najważniejszych pól faktury, bo zdarzyoł się że ta sma faktura miała inne numery referencyjne (bug w demo prawdopodobnie). Jedna rzecz - uawga na **limity API**. W dokumentacji jest napisane o throttlingu ale nie ma konkretnych lizcb. Empirycznie ustaliłam że więcej niż 100 requestów na godzinę od jednego tokena to już ryzyko. Lepiej robić mniejsze batche z przerwami. A ten OCR to chyba ktoś nie ogarnia że w KSeF dostaje się gotowy XML 😄
0
DominikaSikora3 dni temu
Ciekawy projekt! U nas w biurze też implementowaliśmy podobną funkcjonalność dla klientów i mogę potwierdzić większśoć obserwacji które już padły. Co do **częstotliwości odpytywania** - zgadzam się z poprzednikami że co godzinę to przesada dla większości przypadków. My zrobiłyśmy to elastycznie: domyślnie raz dziennie o 6:00, ale klienci mogą w panelu ustawić częstsze odpytywanie jeśli mają większy obrót. Ważne żeby nie robić tego w godzinach szczytu (9-11 i 14-16) bo wtedy API MF jest najbardziej obciążone. **Duplikaty** to rzeczywiście problem nie tylko demo - widziałam to też w środowisku testowym produkcji. Oprócz standardowego sprawdzania po numerze KSeF dodałam jeszcze walidację po kombinacji: NIP wystawcy + numer faktury + kwota brutto + data wystawienia. Czasami zdarza się że MF zwraca tę samą fakturę z różnymi referencjami, więc lepiej się podwójnie zabezpieczyć. Jedna rzecz której nie widziałam w Twoim opisie - jak planujesz obsługiwać **faktury korygujace**? W XML-u mają inne strukturę (typ dokumentu "korygująca") i musisz je powiązać z oryginałami. To może być trudniejsze niż się wydaje, zwłaszcza jak korekta dotyczy faktury sprzed wdrożenia systemu. I jeszcze **timeout** - domyślne 30 sekund to za mało. Przy większych zakresach dat (np. pierwszy import za cały miesiąc) zapytania mogą trwać nawet 2-3 mintuy. Ustaw przynajmniej 120 sekund, a lepiej 180. Co do webhooków - testowałam to powierzchownie ale na razie zostajemy przy pollingu. Prostsze w debugowaniu i bardziej przewidywalne.

Twoja odpowiedź

Zaloguj się, aby odpowiedzieć w tej dyskusji.