Timeout przy wysyłaniu paczki faktur - jak sobie radzicie?

Mieliśmy identyczny problem w Q3 zeszłego roku. Po analizie workflow okazało się, że timeout nie zawsze wynika z limitu MF, ale częściej z błędów walidacji w samej paczce - system wtedy "zawiesza się" zamiast zwrócić jasny komunikat. Kilka rzeczy które nam pomogły: **1. Pre-walidacja przed wysłaniem** - przeganiamy wszystkie faktury przez lokalny walidator XML przed pakowaniem. Jeśli choć jedna ma błąd struktury, cała paczka może wpaść w timeout. **2. Optymalna wielkość batcha** - po testach ROI wyszło nam że sweet spot to 50-70 faktur na paczkę. 150 to zdecydowanie za dużo, szczególnie jeśli masz tam pozycje z wieloma liniami czy załączniki. **3. Monitoring czasu odpowiedzi** - implementowaliśmy exponential backoff i retry logic. Czasem MF po prostu ma gorszy dzień (koniec miesiąca, koniec kwartału). Z mojego doświadczenia - **podziel na mniejsze paczki po 50 sztuk**, to da Ci też lepszą kontrolę nad błędami i możliwość parallel processingu. Tak, to wymaga refaktoru procesu, ale długoterminowo oszczędza więcej czasu niż debugowanie timeoutów. Btw, jakie oprogramowanie używasz? Niektóre rozwiązania mają builtin batching który można skonfigurować.

Potwierdzam obserwacje Barbary - 150 faktur to zdecydowanie za duża paczka. My również po wielu testach ustaliliśmy limit na 50 faktur w jednym batchu i od tamtej pory problem z timeoutami praktycznie zniknął. Dodam jeszcze jedną rzecz której Barbara nie wspomniała - zwróć uwagę na **rozmiar samych faktur w XML**. Jeśli masz faktury z dużą ilością pozycji (np. 50+ linii) albo rozbudowanymi opisami, to nawet mniejsza liczba faktur w paczce może powodować problemy. Ministerstwo nigdzie tego oficjalnie nie komunikuje, ale z naszych testów wynika że oprócz liczby faktur liczy się też całkowity rozmiar pakietu. Zgodnie z dokumentacją techniczną (sekcja 5.2.3 jeśli dobrze pamiętam) maksymalny rozmiar pojedynczego żądania to 50MB, ale praktycznie zalecane jest trzymanie się poniżej 10-15MB na paczkę. Możesz sprawdzić rozmiar swojego XML przed wysłaniem i na tej podstawie dobrać optymalną wielkość batcha. Co do timeoutu - standardowo jest ustawiony na 180 sekund i tego nie zwiększysz po stronie KSeF, więc naprawdę jedyne sensowne rozwiązanie to optymalizacja po Twojej stronie. Podziel faktury na mniejsze grupy, ewentualnie jeśli masz taką możliwość w swoim systemie zaimplementuj równoległe wysyłanie kilku mniejszych paczek jednocześnie (tylko uważaj żeby nie przekroczyć limitów rate limiting).

Dokładnie to samo przeszedłem pół roku temu! Barbara i Filip mają rację co do rozmiaru paczek, ale dodam jeszcze kilka rzeczy z moejgo doświadczenia: **Sprawdź logi po stronie aplikacji** - czasem timeout wynika z tego że Twoja aplikacja za długo buduje XML albo ma problem z pamięcią przy większych paczkach. U nas okazało się że przy 150 fakturach proces żarł 8GB RAM i system się dusił. **Przetestuj różne pory dnia** - koniec miesiąca to koszmar nie tylko dla Ciebie ;) Między 8-10 rano i 14-16 popołudniu KSeF bywa przeciążony. Ja ustawiem sobie job na 6 rano i różnica jest ogromna. **Monitoring per faktury w paczce** - nie wiem jakiego software'u używasz, ale warto dodać logowanie które faktury z paczki przeszły a które nie. Czasem po timeout'cie część jednak się przetworzy i nie musisz wysyłać wszystkich ponownie. Co do rozmiaru - u mnie sweet spot to 3-40 faktur, ale mamy sporo faktur z załącznikami co pewnie wpływa na rozmiar. Polecam zrobić sobie prosty test: weź 10 faktur, potem 20, 30 itd. i zobacz gdzie zaczyna się prolem. Jakie masz środowisko? .NET, Java, PHP? Może da się coś zoptymalizować po stronie buildu XML-a.

Dokładnie ten sam problem miałem miesiąc temu podczas testów.. Z mojego doświadczenia wynika że timeout przy 150 fakturach to nie przypadek - system po prostu nie radzi sobie z większymi paczkami. Ale jest jesszcze jeden edge case o którym nikt nie wspomniał - **sprawdź czy nie masz w paczce faktur z różnymi typami dokumentów**. Miałem sytuację gdzie w jednej paczce byył faktury sprzedaży (FA) i faktury korygujące (KO) i system się dusił na walidacji cross-reference między nimi. Po rozdzieleniu na osobne batche po typach dokumentów problem zniknął. Kolejna rzecz - jeśli używasz oprogramowania które automatycznie generuje numery KSeF dla całej paczki, czasem zdarzają się konflikty numeracji które powodują timeout zamiast normalnego błędu walidacji. Widziałem to szczególnie gdy faktury mają różne daty wystawienia w jednej paczce. Co do rozmiaru - zgadzam się z 50 fakturami jako górną granicą, ale uwaga na faktury z wieloma stawkami VAT. Jedna faktura z 20 pozycjami może "ważyć" tyle co 5 standardowych. Testowałeś może wysyłanie tej samej paczki 150 faktur o różnych porach? Czasem to kwestia obciążenia serwerów MF a nie rozmiaru paczki. Na demo środowisku widziałem timeout nawet na 30 fakturach gdy było dużo ruchu.

Z infrastrukturalnego punktu widzenia timeout przy 150 fakturach to klasyka. **Nie zwiększysz timeoutu po stronie KSeF** - masz standardowe 180s i koniec. Problem prawdopodobnie nie leży w połączeniu ale w **walidacji całej paczki**. System MF przetwarza wszystkie faktury sekwencyjnie i jak jedna ma błąd w strukturze XML to może zawiesić całą paczkę bez sensownego komunikatu błędu. Kilka rzeczy do sprawdzenia: **1. Rozmiar paczki w MB** - nie tylko liczba faktur ale całkowity payload. Sprawdź `Content-Length` w headerach żądania. Powyżej 15-20MB to już ryzyko. **2. Memory leak w aplikacji** - przy większych paczkach niektóre implementacje XML-a żrą pamięć jak szalone. Sprawdź monitoring RAM podczas bdowania paczki. **3. Exponential bcakoff** - jeśli masz możliwość, ddoaj retry logic z rosnącymi opóźnieniami. Czasem MF po prostu ma gorszy dzień. ```bash # Quik check rozmiaru XML przed wysłaniem ls -lh batch_150_faktur.xml ``` Z moojego doświadczenia - **40-50 faktur max** na paczkę i równoległe wysyłanie kilku mniejszych batchy jednocześnie (tylko uważaj na rate limiting). Tak, więcej kodu, ale mniej nerwów. Jakiego stacku używasz? Może da się coś zoptymalizować w budowaniu XML-a.