Monitoring zamówień i DLQ - jak nie stracić żadnego zamówienia
Jak system DLQ (Dead Letter Queue) chroni przed utratą zamówień. Monitoring, alerty i automatyczne retrying w NavyFlame.
Faktura się nie wystawiła i nie wiesz dlaczego? W większości przypadków winny jest błędny NIP, brak danych nabywcy albo chwilowy błąd API systemu fakturowego. Pokazujemy, jak szybko znaleźć przyczynę i ponowić wystawienie bez gubienia dokumentu.
Gdy faktura się nie wystawiła, prawie zawsze stoi za tym jedna z kilku powtarzalnych przyczyn. Zanim zaczniesz szukać winy w samym systemie fakturowym, warto sprawdzić te najczęstsze scenariusze, bo w większości przypadków problem leży w danych zamówienia, a nie w awarii oprogramowania.
Oto błędy, które najczęściej blokują wystawienie dokumentu:
Rozróżnienie przyczyny jest ważne, bo każda z nich wymaga innego działania. Błędny NIP poprawiasz w danych zamówienia, wygasły token odnawiasz w konfiguracji integracji, a chwilowy błąd API zwykle wystarczy po prostu ponowić.
To praktyczny przewodnik, a nie porada podatkowa. Zakres obowiązkowych elementów faktury i zasady jej wystawiania reguluje ustawa o VAT - konkretne wątpliwości warto skonsultować z księgowym i sprawdzić aktualne przepisy, bo bywają zmieniane.
Najczęstszą pojedynczą przyczyną, dla której faktura się nie wystawiła, są błędne lub niekompletne dane nabywcy. Przy sprzedaży na marketplace dane przychodzą w formacie platformy i nie zawsze mapują się idealnie na pola wymagane przez system fakturowy.
Przy fakturach dla firm krytyczny jest NIP. Warto zweryfikować go zawczasu - dla kontrahenta krajowego na Białej liście podatników VAT, a dla klienta z Unii w bazie VIES. Numer z literówką albo nieaktywny zostanie odrzucony, a Ty zobaczysz błąd dopiero w momencie wystawiania.
Drugą grupą są pola obowiązkowe. Faktura VAT musi zawierać określony zestaw danych, a ich brak blokuje wygenerowanie dokumentu. Jeśli nie masz pewności, co dokładnie musi się znaleźć na fakturze, sprawdź co musi zawierać faktura VAT. Najczęściej brakuje:
Dobra praktyka to walidacja danych jeszcze przed wysłaniem do systemu fakturowego. NavyFlame sprawdza kompletność danych nabywcy i poprawność stawek na etapie przetwarzania zamówienia, więc część błędów wychwytujesz, zanim w ogóle dojdzie do nieudanej próby wystawienia.
Druga rodzina przyczyn nie ma nic wspólnego z danymi - to problemy po stronie połączenia z systemem fakturowym. Tu faktura się nie wystawiła nie dlatego, że dokument był wadliwy, ale dlatego że żądanie nie dotarło lub zostało odrzucone.
Najczęstszy przypadek to wygasły token API. Połączenie z wFirma, inFakt, Fakturownia czy iFirma opiera się na kluczu lub tokenie OAuth, który po pewnym czasie traci ważność. Skutek to błąd autoryzacji i seria nieudanych prób, dopóki nie odnowisz połączenia w konfiguracji integracji.
Kolejne sytuacje związane z API:
| Objaw | Prawdopodobna przyczyna | Co zrobić |
|---|---|---|
| Błąd 401 / brak autoryzacji | Wygasły token lub klucz API | Odnów połączenie w konfiguracji integracji |
| Błąd 429 / rate limit | Przekroczony limit zapytań do API | Poczekaj i ponów - system rozkłada próby w czasie |
| Timeout / brak odpowiedzi | Chwilowa niedostępność serwisu | Ponów po przywróceniu dostępności |
| Odrzucenie duplikatu | Numer dokumentu już istnieje | Sprawdź numerację, ponów po korekcie |
Dobra wiadomość jest taka, że błędy API są zwykle przejściowe. System nie poddaje się po pierwszej próbie - wykonuje kilka automatycznych ponowień z rosnącymi odstępami (exponential backoff), więc krótka przerwa techniczna serwisu fakturowego często rozwiązuje się sama, bez Twojej interwencji.
Najgorszy scenariusz przy fakturowaniu masowym to nie sam błąd, lecz zgubienie dokumentu. Jeśli nieudane zamówienie znika bez śladu, po kilku dniach okazuje się, że brakuje faktur, a Ty nie wiesz których. NavyFlame rozwiązuje to mechanizmem kolejki błędów (DLQ, Dead Letter Queue) opisanym szerzej w artykule o monitoringu zamówień i DLQ.
Działa to tak: gdy faktura się nie wystawiła i automatyczne ponowienia się wyczerpały, zamówienie nie przepada. Trafia do DLQ razem z pełnym logiem błędu, który mówi wprost, co poszło nie tak - na przykład „błędny NIP", „wygasły token API" albo „brak adresu nabywcy". Zamiast zgadywać, od razu wiesz, co naprawić.
W sekcji Monitoring widzisz listę wszystkich zatrzymanych zamówień, a licznik DLQ jest widoczny na głównym pulpicie, więc problem nie umknie Twojej uwadze. Dodatkowo system wysyła powiadomienia email i w panelu, gdy coś wpadnie do kolejki - nie musisz wchodzić i sprawdzać ręcznie.
Proces odzyskiwania faktury jest prosty:
Najważniejsze jest to, że ponowienie odbywa się jednym kliknięciem i nie wymaga przepisywania danych ani logowania się do systemu fakturowego osobno. Cała logika fakturowania jest po stronie NavyFlame, więc po naprawie błędu po prostu uruchamiasz proces ponownie.
Naprawianie błędów jest proste, ale jeszcze lepiej, gdy w ogóle się nie pojawiają. Kilka nawyków znacząco zmniejsza ryzyko, że faktura się nie wystawiła w trakcie szczytu sprzedaży, kiedy najmniej masz czasu na ręczne poprawki.
Po pierwsze, weryfikuj NIP i dane firmowe na bieżąco, szczególnie w kanale B2B. Po drugie, pilnuj ważności tokenów API - jeśli korzystasz z połączeń OAuth, odnowienie ustaw zanim wygasną, a nie dopiero gdy posypią się błędy. Po trzecie, ujednolicaj mapowanie stawek VAT, żeby produkty trafiały do systemu fakturowego ze stawką, którą ten akceptuje.
Pomocne jest też zrozumienie, skąd biorą się typowe pomyłki na dokumentach - praktyczny przegląd znajdziesz w artykule o błędach na fakturach i jak ich uniknąć. Im wcześniej wychwycisz problem w danych, tym mniej zamówień wpada do DLQ.
Wreszcie warto rozważyć pełną automatyzację fakturowania z monitoringiem zamiast ręcznego wystawiania. Automatyczny proces z kolejką błędów daje przewidywalność: każde zamówienie albo kończy się fakturą, albo trafia do DLQ z jasną przyczyną. Nic nie ginie po cichu, a Ty zawsze wiesz, ile dokumentów czeka na naprawę i dlaczego.
Najczęstsze powody to błędny lub nieistniejący NIP, brak wymaganych danych nabywcy (adres, nazwa firmy), wygasły token API do systemu fakturowego oraz chwilowa niedostępność lub przekroczony limit zapytań po stronie wFirma, inFakt, Fakturownia czy iFirma. Rzadziej winne jest niepoprawne mapowanie stawki VAT lub duplikat numeru dokumentu.
Nie. W NavyFlame nieudane wystawienie nie kasuje zamówienia - po wyczerpaniu automatycznych prób trafia ono do kolejki błędów (DLQ) razem z pełnym logiem przyczyny. Dokument pozostaje do odzyskania, a Ty dostajesz powiadomienie.
W sekcji Monitoring znajdziesz listę DLQ z opisem błędu dla każdego zamówienia. Po poprawieniu danych (np. NIP, adres) lub odnowieniu tokenu API klikasz ponowienie i system ponawia całą operację. Nie musisz przepisywać danych ręcznie.
Numer NIP możesz zweryfikować na Białej liście podatników VAT prowadzonej przez Ministerstwo Finansów oraz w bazie VIES dla kontrahentów z UE. Warto to robić przy fakturach B2B, zanim trafią do systemu fakturowego, bo błędny NIP to jedna z najczęstszych przyczyn odrzucenia dokumentu.
Nie, jeśli korzystasz z integracji. Po naprawieniu przyczyny błędu ponawiasz wystawienie z poziomu panelu NavyFlame, a faktura powstaje w docelowym systemie (wFirma, inFakt, Fakturownia, iFirma) tak jak przy normalnym przebiegu. Ręczne wystawianie jest potrzebne tylko poza zintegrowanym procesem.
Jak system DLQ (Dead Letter Queue) chroni przed utratą zamówień. Monitoring, alerty i automatyczne retrying w NavyFlame.
Najczęstsze błędy na fakturach w sklepie internetowym: zły NIP, błędna stawka VAT, literówki w danych nabywcy, luki w numeracji i pomyłki w kwotach. Pokazujemy, ile kosztują korekty oraz jak automatyczne przenoszenie danych z zamówienia eliminuje pomyłki.
Dowiedz się, jak automatyczne fakturowanie eliminuje ręczną pracę w e-commerce. Integracja sklepu z systemem fakturowym oszczędza czas i redukuje błędy.
Kolejka błędów DLQ i ponowienie jednym kliknięciem w standardzie.
Zobacz demo