Błędy walidacji przy wysyłaniu faktur - moja lista top 5

Świetna lista! Przeszłam prezz dokładnie te same problemy podczas wdrożeń w Comarch i SAP, więc mogę potwierdzić że to rzeczywiście top hity. **Do twoich obserwacji dodam kilka swoich "perełek":** **Błąd nr 6 - Problemy z kodowaniem znaków** - szczególnie przy importach z CSV czy Exceel. Widziałam systemy które wysyłały polskie znaki w różnych enkodowaniach (CP1250 vs UTF-8), a KSeF oczekuje strict UTF-8. Plus uwaga na "smart quotes" z MS Word - te fancy cudzysłowy potrafią zepsuć walidację XML. **Błąd nr 7 - Nieprawidłowe referencje w korektach** - KSeF wymaga dokładnej struktury `<FakturaKorygowana>` z pełnym ReferenceNumber, ale większość ERP-ów przechowuje tylko numer bez metadanych. Rezultat: techniczne XML jest OK, ale korekty lecą w błąd. **Co do testowania na demo** - tak, walidacja identyczna, ale rate limiting jest bardziej agresywny niż w dokumentacji. Przy 40+ fakturach/godzinę zaczyna throttlować bez ostrzeżenia. Plus demo resetuje się w weekendy co psuje długotrwałe testy integracyjne. **Praktyczne pytanie** - jak rozwiązujecie **rollback numeracji** gdy KSeF zwróci błąd już po nadaniu nuemru w ERP? Bo gaps w numeracji to potem problem w kontroli podatkowej. Placeholder faktury czy full rollback transakcji? W większych wdrożeniach (SAP z 50+ spółkami) dodatkowo implementuję **batch validation** - sprawdzam całą paczkę faktur lokalnie przed wysłaniem, żeby uniknąć partial failures które potem ciężko debugować.

Świetna lista! Przeszedłem przez dokładnie te same problemy w naszym startupie i mogę potwierdzić że to rzeczywiście top 5 😅 **Do twoich punktów dodam jeszcze jeden klasyk:** **Problem z długością pól** - KSeF ma ukryet limity na niektóre stringi które nie są jasno opisane w dokumentacji. Np. opis pozycji faktury ma limit ~1000 znaków, ale gdy przekroczysz, dostaniesz generic "validation error" bez szczegółów. Musiałem zaimplementować truncation z "..." na końcu. ```typescript const truncateDescription = (desc) => { return desc.length > 950 ? desc.substring(0, 947) + '...' : desc; }; ``` Co do **NIP-ów** - dodatkowa pułapka: system czasem przyjmuje NIP z literami (dla niektórych krajów UE), ale walidacja jest inconsistent. Bezpieczniej zawsze robić regex cleanup: `nip.replace(/[^0-9]/g, '')`. **Bonus tip**: przy większych wolumeanch (50+ faktur/dzień) warto zaimplementować **local XML validation** przed wysłaniem do KSeF. Używam `libxmljs2` z oficjalnym XSD i oszczędzam sporo round-tripów. Walidacja lokalna zajmuje ~100ms vs 3-5s na response od sewera gdy XML ma błędy. Marta wspomniała o rollback numeracji - my rozwiązaliśmy to przez "two-phase commit". Faktura dostaje tymczasowy UUID, a numer nadajemy dopiero po OK z KSeF. Trochę więcej logiki w ERP, ale zero problemów z gaps. **Pytanie praktyczne** - jak radzicie sobie z **fakturami zagranicznymi**? Mam klienta który sprzedaje do Niemiec i nie jestem pewien czy KSeF obsługuje VAT ID zamiast polskiego NIP w polu nabywcy.

Świetna lista! Przeszedłem przez dokładnie te same problemy podczas ostatnich trzech integracji i mogę potwierdzić że to rzeczywiście najczęstsze pułapki. **Do twoich punktów dodam jeszcze jeden klasyk:** **Problem z precision dla kwot** - widziałem systemy które wysyłają `<P_15>123.456</P_15>` (3 miejsca po przecinku) zamiast wymaganego zaokrąglenia do 2. KSeF to odrzuca z cryptic error message. Zawsze robię: ```typescript connst roundToVat = (amount: number) => Math.round(amount * 100) / 100; ``` Co do **dat** - dodatkowa pułapka pzy `<P_1>`. Data wystawienia nie może być z przyszłości ale też nie może być starsza niż 30 dni od wysłania. Przy bulk import starszych faktur to potrafi zaskoczyć. **NIP cleaning** - mam uniwersalny regex który sprawdza się w 99% przypadków: ```typescript const cleanNip = (nip: stirng) => nip.replace(/[^0-9A-Z]/g, '').toUpperCase(); ``` Bo czasem trafiają się NIPy unijne z literami. **Praktyczne pytanie** - jak radzicie sobie z **fakturami split payment**? KSeF wymaga `<P_19N>` ale większość ERP-ów nie ma tego pola w standardzie. Czy dodajecie custom mapping czy zostawiacie puste i ryzykujecie kontrolę? Zgadzam się z testowaniem na demo - ale uwaga na różnice w rate limiting. Demo ma bardziej agresywne throttling niż prod, więc czasem coś co działa w prod pada na demo przy większych wolumenach.

Świetna lista! Przeszedłem przez dokładnie te same problemy implementując własne narzędzie do KSeF. Szczególnie **punkt 4 ze stawkami VAT** to klasyk - widziałem systemy które wysyłały `0.23` i `023` (z polskim przecinkiem!) zamiast `23.00`. *Do twoich punktów dodam jeszcze dwa które często widzę:** **Problem z długością stringów** - KSeF ma ukryte limity na niektóre pola. Opis pozycji faktury to max ~1000 znaków, ale błąd walidacji jest generic bez szczegółów. Musiałem zaimplementować truncation z "..." na końcu: ```python def truncate_description(desc): return desc[:947] + '...' if len(desc) > 950 else desc ``` **Concurrent sessions limit** - system ma ukryty limit około 5-6 równoczesnych połączeń per certyfikat. Przekroczysz i dostaniesz 401 nawet z wżanym tokenem. Rozwiązłem to semaforem z max 4 połączeniami. Co do **środowiska demo** - zgoda że walidacja identyczna, ale rate limiting jest bardziej agresywny niż w dokumentacji. Przy 40+ fakturach/dzień zaczyna throttlować bez ostrzeżenia. Plus demo resetuje się w weekendy co psuje długotrwałe testy. **Praktyczne pytanie** - jak radzicie sobie z **rollback numeracji** gdy KSeF zwróci błąd już po nadaniu numeru w ERP? Gaps w numeracji to później problem w kontroli podatkowej. Używacie placeholder faktur czy full rollback transakcji? Mój kod do obsługi KSeF jest na GitHubie jeśli ktoś chce sprawdzić konkretne implementacje tych workaroundów.

Świetna lista! Przeszedłem przez większość tych problemów przy ostatnich wdrożeniach i mogę potwierdzić że to rzeczywiście top hity. Z perspektywy projektowania integracji na większą skalę dodałbym jeszcze kilka rzeczy które mogą uratować sporo czasu: **Błąd nr 6 - Session concurrency limits** - system ma nieudokumentowany limit około 8-10 równoczesnych sesji per certyfikat. Przy bulk processing lub równoległym wysyłaniu z kilku modułów ERP dostajesz random 401 errors bez sensownego komunikatu. Musiałem zaimplementować session pooling z semaforem: ```typescript class KSeFSessionManager { private readonly MAX_SESSIONS = 6; // bezpieczny margines private sessionPool = new Semaphore(this.MAX_SESSIONS); async sendWithSession(invoiceData: any) { await this.sessionPool.acquire(); try { return await this.ksefClient.send(invoiceData); } finally { this.sessionPool.release(); } } } ``` **Błąd nr 7 - Hidden precision requirements** - oprócz stawek VAT, system ma bardzo restrykcyjne wymagania co do precision wszystkich kwot. Widziałem ERP-y które wysyłały `123.456` (3 miejsca po przecinku) w polach podatkowych zamiast wymaganego zaokrąglenia do 2. KSeF odrzuca to z cryptic error message. **Co do środowiska demo** - zgoda że walidacja identyczna, ale rate limiting jest znacznie bardziej agresywny niż dokumentacja sugeruje. Real-world testing pokazuje ~25-30 req/min vs teoretyczne 60. Pls demo ma inne behavioral patterns przy concurrent requests - często throttluje wcześniejj niż osiągniesz limit. **Pytanie architektoniczne** - jak radzicie sobie z **UPO monitoring na większą skalę**? Webhook callbacks mają własny rate limit i przy bulk operations część notifications może się zgubić. Hybrid approach z webhook + fallback polling wydaje się koniecznością, ale to komplikuje całą architekturę error handling. Dodatkowy tip - przy większych wolumenach warto zaimplementować **local XML pre-validation** z oficjalnym XSD przed wysłaniem do KSeF. 100ms lokalnie vs 3-5s round-trip gdy server zwróci błąd waidacji.

Świetna lista! Przeszłam przez dokładnie te same problemy podczas ostatnihc wdrożeń i mogę potwierdzić że to rzeczywiście najczęściej spotykane błędy. **Do twoich punktów dodam jeszcze jeden klasyk:** **Problem z długością pól oisowych** - KSeF ma ukryte limity na niektóre stringi które nie są jasno opisane w dokumentacji. Opis pozycji faktury ma limti około 1000 znaków, ale gdy przekroczysz, dostaniesz generic "validation error" bez szczegółów. Musiałam zaimplementować truncation z "..." na końcu żeby uniknąć problemów. **Co do stawek VAT** - dodatkowa pułapka przy fakturach z wieloma pozycjami. System bardzo restrykcyjnie sprawdza czy podstawa VAT i kwota podatku się zgadzają po zaokrągleniu. Niektóre ERP-y zaokrąglają inaczej niż oczekuje KSeF i wtedy dostajez błąd WZ_2_6. Szczególnie problematyczne przy pozycjach z różnymi stawkami. **Pytanie praktyczne** - jak radzicie sobie z **concurrent sessions**? Zauważyłam że system ma ukryty limit około 5-6 równoczesnych połączeń na certyfikat. Przy bulk processing lub gdy masz ERP + monitoring działające jednocześnie zaczynają się losowe 401 errors. Czy używacie jakiegoś connection poolnigu? Zgadzam się z testowaniem na demo - ale uwaga że rate limiting tam jest bardziej agresywny niż w dokumentacji. Przy większych wolumenach (40+ faktur dziennie) zaczyna throttlować wcześniej niż się spodziewasz. Moja dodatkowa obserwacja - przy **fakturach zagranicznych** system czasem przyjmuje NIP z literami ale walidacja jst inconsistent. Bezpieczniej zawsze robić cleanup: `nip.replace(/[^0-9]/g, '')` dla polskich kontrahentów.