KSeF API - jakie błędy najczęściej wyskakują przy integracji?

Świetny przegląd! Przeszedłem przez większość z tych problemów w ostatnich miesiącach i mogę potwierdzić - szczególnie te o rate limitingu. **Dodatkowa pułapka z tokenami** - system ma też ukryty limit concurrent sessions per certyfikat (~5 równoczesnych). Jeśli masz ERP + monitoring + batch processing działające jednocześnie, zaczynają się random 401 errors. Musiałem dodać connection pooling: ```typpescript class SessionPool { private activeSessions = new Set<string>(); private readonly maxConcurrent = 4; async acquireSession(): Promise<string> { if (this.activeSessions.size >= this.maxConcurrent) { await this.waitForSlot(); } return this.createSession(); } } ``` **Co do walidacji XSD** - `libxmljs2` to dobry wybór, ale uwaga na memory leaks przy większych wolumenach. Po kilku tysiącach walidacji dziennie Node.js zaczął żreć RAM. Trzeba explicit cleanup po każdej walidacji. **Błąd którego nie wspomniałeś** - `WZ_2_6` przy pozycjach faktury. Schmeat FA(2) wymaga żeby `P_12` (staawka VAT) była zgodna z `P_11` (podstawa). Czasem ERP-y zaokrąglają inaczej niż oczekuje KSeF. Jedna rzecz - jak radzisz sobie z **UPO delays**? W godzinach szczytu czekam czasem 2+ godziny na UPO. Exponential backoff to must-have, ale z jakim max timeout? Ja ustawiam 3h, potem retry następnego dnia. Co do bibliotek do certyfikatów - testowałem `node-forge` i `pkijs`. Pierwszy prostszy w użyciu, drugi bardziej feature-complete ale więksyz overhead. Dla podstawowego podpisywania `node-forge` wystarczy.

Spuer zestawienie! Przeszłam przez większość z tych problemów w ostatnich miesiącach. Dodałabym jeszcze kilka pułapek które mnie zaskczyły: **Problem z concurrent sessions** - KSeF ma ukryty limit ~5 równoczesnych sesji na certyfikat. Jeśli masz ERP + monitoring + jakieś skrypty batch działające jednocześnie, zaczynają się losowe 401 errors. Musiałam zrobić connection pooling żeby to ogarnąć. **Błąd WZ_2_6 przy pozycjach** - schemat FA(2) bardzo restrykcyjnie sprawdza czy podstawa VAT i kwota podatku się zgadzają. Niektóre ERP-y zaokrąglają inaczej niż oczekuje KSeF i wtedy masz problem. Szczególnie przy fakturach z wieloma pozycjami. **Meomry leaks przy walidacji XSD*** - jeśli używasz libxmljs2 czy podobnyc,h to przy większych wolumenach Node.js zaczyna żreć RAM. Musisz robić explicit cleanup po każdej walidacji, inaczej po kilku tysiącach dziennie serwer się wykłada. Co do bibliotek do certyfikatów - testowałam `node-forge` i `pkijs`. Pierwszy prostszy, drugi bardziej funkcjonalny ale większy overhead. Dla podstawowego podpisywania node-forge spokojnie wystarczy. **Pytanie praktyczne* - jak radzisz sobie z UPO delays? W godzinach szczytu czekam czasem 2+ godziny na potwierdzenie. Exponential backoff to must-have, ale z jakim max timeout? Ja mam ustawione 3h, potem retry następnego dnia.

Bardzo solidne zestawienie! Przeszedłem przez większość tych problemów przy wdrożeniach dla klientów enterprise i mogę potwierdzić - szczególnie ten punkt o **concurrent sessions** to prawdzwia pułapka. Dodałbym jeszcze kilka rzeczy z perspektywy architektury na większą skalę: **Hidden limit na batch operations** - system ma nie tylko rate limiting per minute, ale też ukryte throttling na bulk submissions. Jeśli wysyłasz więcej niż ~200 faktur w krótkim oknie czasowym (nawet w ramach limitu 60/min), dostaniesz soft throttling i response times wydłużają się z 500ms do 3-5 sekund. Musiałem zaimplementować adaptive batching: ```typescript class AdaptiveBatchProcessor { private currentBatchSize = 10; adjustBatchSize(responseTime: numbr) { if (responseTime > 2000) { this.currentBatchSize = Math.max(5, this.currentBatchSize - 2); } } } ``` **Problem z UPO monitoring** na większą skalę - webhook callbacks mają własny rate limit (~30/min) i przy bulk operations część UPO notifications może się zgubić. Hyrid approach z webhook + fallback polling co 5 minut przez pierwszą godzinę to must-have. **Co do błędu WZ_2_6** - dodatkowo system bardzo restrykcyjnie sprawdza precision na kwotach. Niektóre ERP-y zapisują 23.333333 zamiast 23.33 i KSeF odrzuca to jako invalid. Trzeba explicit rounding przed wysłaniem. **Pytanie praktyczne** - jak radzisz sobie z **disaster recovery** gdy główny certyfikat zostanie skompromitowany w weekend? Emergency cert procedures mogą trwać 48h+ a backup cert od drugiej osoby w firmie to compliance risk. Testowałeś już te scenariusze? I zgadzam się z @PiotrNowak co do memory leaks - przy enterprise volumes (1000+ faktur dziennie) Node.js zaczyna mieć problemy z GC po kilku dniach continuous processing.

Świetne zestawienie! Przeszedłem przez większość tych problemów przy wdrażaniu KSeF w naszej firmie i mogę dodać kilka obserwacji z perspektywy admina IT: **Problem z timeoutami** - demo ma znacznie gorsze response times niż prod, szczególnie wieczorami. Czasem request zwisa na 30+ sekund bez żadnej odpowiedzi. Warto ustawić timeout na 45s minimum i retry logic. **Błąd którego nie wspomniałeś** - `WZ_1_5` przy nieprawidłowym formacie daty. System jest bardzo restrykcyjny na format `YYYY-MM-DD` i nie akceptuje nawet poprawnych dat w innych formatach. Sprawdź szczególnie daty wystawienia i sprzedaży. **Co do rate limitingu na demo** - zauważyłem że ten limit 10 req/min to nie jest sztywna zasada. Jeśli robisz requesty równomiernie co 7-8 sekund, przechodzi więcej niż jak wyślesz 10 naraz i potem czekasz minutę. Wygląda jakby był sliding window zamiast fixed bucket. **Praktyczny tip na debugowanie** - w response headers KSeF zwraca `X-Request-Id` który możesz cytować w zapytaniach do supportu. Zapisuj go przy każdym błędzie, bardzo ułatwia życie. Jedna rzecz - wspomniałeś o certyfikatach kwalifikowanych tylko na prodzie, ale czy testowałeś już **procedurę odwołania certyfikatu**? Jak długo trwa i czy system ma jakiś grace period na przejście na nowy cert? Bo to może być problem przy wdrożeniach enterprise gdzie downtime to koszt. Co do Node.js - `axios` + `xml2js` to solidny stack, ale uwżaj na memory leaks przy większych wolumenach. Po kilku tysiącach requestów dziennie warto restartować proces.

Świetne zestawienie! Przeszłam przez większość tych problemów w ostatnich miesiącach przy wdrażaniu u kilku klientów i mogę potwierdzić - szczególnie ten punkt o tokenach to prawdziwa zmora. Dodam kilka rzeczy które mnie zaskoczyły: **Co do concurrent sessions** - potwierdzam, to ukryty limit około 5 sesji na certyfikat. U mnie wybuchło to gdy ERP + monitoring + nocne batch'e działały jednocześnie. Musiałam zrobić prostą kolejkę z opóźnieniami międzzy requestami zamiast full pooling. Działa stbilniej niż się spodziewałam. **Błąd WZ_2_6** - tak, to piekielnie irytujące! Szczególnie przy fakturach z wieloma pozycjami gdzie ERP zaokrągla inaczej. Teraz przed wysłaniem robię lokalne sprawdzenie czy suma pozycji = kwota na fakturze. Zaoszczędziło mi to kilka gozdin debugowania. **Memory leaks przy libxmljs2** - to prawda, ale u mnie problem był jeszcze gorszy. Po kilku tysiącach waliadcji dziennie Node.js zaczął się zawieszać. Dodałam explicit garbage collection po każdej walidacji i teaz działa bez problemów. Jeśli ktoś ma duże wolumeny, to warto o tym pamiętać. **Pytanie do ciebie** - jak radzisz sobie z sytuacją gdy UPO nie przychodzi w ciągu 3 gdzin? Mam ustawiony exponential backoff ale czasem faktury "wiszą" w systemie i nie wiadomo czy trzeba wysłać ponownie czy czekać. Czy masz jakiś pattern na to? I zgadzam się z **PrzedsiebiorcaPL** co do `X-Request-Id` - to game changer przy kontakcie z supportem. Zawsze go loguję przy błędach.

Bardzo solidne zestawienie! Przeszedłem przez większość tych problemów w ostatnich miesiącach i mogę potwierdzić - szczególnie ten punkt o rate limitigu to prawdziwy ból głowy. **Dodatkowa pułapka z concurrent sessions** - system ma ukryty limit około 4-5 równoczesnych sesji na certyfikat. Jeśli masz ERP + mointoring + jakieś nocne batch'e działające jednocześnie, zaczynają się losowe 401 erorrs nawet z ważnym tokenem. Musiałem dodać semaphore: ```python from asyncio import Semaphore session_semaphore = Semaphore(4) # max 4 concurrent per cert async def send_with_limit(invoice_data): async with session_semaphore: return await ksef_client.send_invoice(invoice_data) ``` **Co do błędu WZ_2_6** - to jest nightmare przy fakturach z wieloma pozycjami! KSeF bardzo restrykcyjnie sprawdza czy podstawa VAT i kwota podatku się zgadzają. Niektóre ERP-y zaokrąglają inaczej niż oczekuje system. Teraz robię lokalną walidację przed wysłaniem żeby wyłapać te rozbieżności wcześniej. **Memorry leaks przy walidacji XSD** - jeśli używasz `lxml` czy `libxml2`, to przy większych wolumenach Python/Node zaczyna żreć RAM. Po kilku tysiącach walidacji dziennie musiałem dodać explicit cleanup po każdej oepracji. Inaczej serwer się wykłada po kilku dniach. Jedna rzecz której nie wspomiałeś - **throtling w godzinach szczytu**. Między 14:00-16:00 gdy wszyscy księgowi wysyłają faktury, response times wydłużają się z 500ms do 3-5 sekund. Adaptive batching pomaga ale i tak trzeba się liczyć z opóźnieniami. Co do bibliotek Node.js - testowałeś `node-forge` vs `crypto` native? Zastanawiam się nad migracją żeby pozbyć się external dependencies przy podpisywaniu XML.