Pomoc z korektami w KSeF - kompletnie się gubie

Nie musisz anuloać poprzedniej faktury! To częsty błąd który widzę u początkujących. **Korekta w KSeF działa tak:** 1. Wystawiasz nową fakturę z typem "korekta" 2. W XML-u podajesz numer oryginalnej faktury w polu `<tns:CorrectedInvoice>` 3. Korekta dostaje swój własny numer z sekwencji ```xml <tns:CorrectedInvoice> <tns:InvoiceNumber>2024/01/123</tns:InvoiceNumber> <tns:IssueDate>2024-01-15</tns:IssueDate> </tns:CorrectedInvoice> ``` **Praktyczna rada** - zacznij od środowiska demo (ksef-demo.mf.gov.pl). Tam możesz bezpiecznie testować korekty bez obaw że coś zepsujesz. Portal webowy ma nawet opcję "wystw korektę" która automatycznie wypełnia większość pól. **Uwaga na jeden szczegół** - jeśli korygujsz kwotę VAT, system bardzo rygorystycznie sprawdza poprawność obliczeń. Jeden błąd w zaokrągleniu i dostaniesz validation error bez jasnego komunikatu co jest nie tak. Przy pierwszej korekcie polecam użyć portalu webowego zamiast API - zobaczysz dokładnie jakie pola są wymagane i jak system obsługuje błędy. Dopiero potem możesz przejść na automatyzację jeśli potrzebujesz. I zapisz sobie gdzieś przykład XML-a z pierwsszej korekty - przyda się jako template na przyszłość.

Izabela świetnie to wytłumaczyła! Ja tylko dodam kilka praktycznych rzeczy które odkryłam testując korekty: **Najważniejsze** - faktycznie nie anuluj oryginalnej faktury. Korekta to osobny dokument ktróy "odnosi się" do pierwszej faktury ale oba dokumenty pozostają w systemie. **Co do numeracji** - korekta dostaje swój numer z normalnej sekwencji. Np. masz fakturę 2024/01/123, a korekta będzie miała numer 2024/01/124 (albo jaki tam następny). W polu `CorrectedInvoice` podajesz dane ORYGINALNEJ faktury. **Praktyczna raad z tetsów** - gdy testujesz na demo, zrób sobie najpierw prostą fakturę z jedną pozycją i małą kwotą. Potem korektę tej faktury. Zobaczysz dokładnie jak to wygląda w sytemie i jak się numeruje. **Częsty błąd** który widziałam u klientów - w korekcie trzeba podać PEŁNE dane faktury, nie tylko to co się zmienia. Jeśli zmieniasz kwotę z 1000 na 1200 zł, w korekcie musisz mieć wszystkie pozycje z nowymi wartościami, nie tylko różnicę +200. Portal webowy rzeczywiście jest najlepszy na początek. Ma nawet podgląd XML-a przed wysłaniem więc widzisz jak system interpretuje Twoje dane. A jak już opanujesz podstawy, to warto sprawdzić czy Twój program księgowy ma opcję "korekta" - większość nowszych wersji już to obsługuje i automatycznie wypełnia pola referencyjne.

Świetne odpowiedzi od Izabeli i Ewy! Ja dodam jeszcze kilka praktycznych rzeczy które odkryłam podczas testów korekt w naszej firmie. **Najważniejsze - sprawdź swoje dane przed korektą!** Często problem nie leży w mechanice korekty ale w jakości oryginalnych danych. Jeśli pierwotna faktura miała błędny NIP kontrahenta lub kod pocztowy, korekta też będzie odrzucona z tym saym błędem. **Praktyczna wskazówka z testów:** 1. Idź na demo i wstaw najprostszą fakturę (10zł, jedna pozycja, kontrahent z Polski) 2. Zrób korektę tej faktury - zmień kwotę na 120zł 3. Sprawdź w systemie jak wyglądają oba dokumenty i jak się do siebie odnoszą **Co do XML-a** - portal weboy jest naprawę najlepszy na początku. Ma opcję "wystaw korektę do faktury" która automatycznie wypełnia większość pól referencyjnych. Dopiero jak opanujesz logikę, możesz przejść na API czy integrację z programem. **Jeden szczegół który może Cię zaskoczyć** - jeśli oryginalna fakura miała termin płatności, w korekcie też musisz go podać (nawet jeśli się nie zmienia). System wymaga kompletności danych. A jakie masz konkretnie błędy gdy próbujesz wysłać korektę? Bo może da się szybko namierzyć co jest nie tak zamiast zaczynać od początku.

Widzę że już dostałeś świetne odpowiedzi od Izabeli i innych, ale dorzucę kilka rzeczy z perspektywy testera które mogą Ci pomóc uniknąć typowych pułapek. **Co do tych błędów które dostajesz** - wklej tutaj dokładną treść błędu z systemu, bo "błędy" to za mało żeby pomóc konkretnie. System zwraca precyzyjne kody tyu `P_15_3_MISSING` albo `INVALID_DATE_FORMAT` i każdy wymaga innego podejścia. **Praktyczny test który polecam:** idź na demo i zrób najprostszą możliwą korektę - zmień kwoę z 100zł na 120zł, jedna pozycja, kontrahent z Polski. Jak przejdzie, celowo zrób błąd (np. wpisz ujemną kwotę w korekcie) żeby zobaczć komunikaty błędów. Zrozumiesz wtedy logikę systemu. **Edge case który odkryłem podzas testów korekt** - jeśli oryginalna faktura miała błędny kod pocztowy kontrahenta (np. 00-001 zamiast 00001), korekta też będzie odrzucona z tym samym błędem. System nie pozwala korygować błędów w danych podstawowych - trzeba wtedy anulować i wystawić nową. Co do numeracji - korekta rzeczywiście dostaje swój numer z normalnej sekwencji. W polu `CorrectedInvoice` podajesz dane ORYGINALNEJ faktury, ale sama korekta ma nowy numer typu 2024/01/124. Portal webowy na początku to najlepsza opcja - zobaczysz dokładnie jakie pola wypełnia automatycznie i jak wygląda gotowy XML przed wysłaniem.

Świetne odpowiedzi od koleżanek! Ja tylko dorzucę kilka rzeczy z perspektywy testera które mogą Ci pomóc uniknąć typowych pułapek przy korektach. **Co do tych błędów ktre dostajesz** - wklej tutaj dokładny komunikat z systemu, bo "błędy" to za mało żeby pomóc konkretnie. System zwraca precyzyjne kody typu `INVOICE_CORRECTION_INVALID_REFERENCE` czy `MISSING_CORRECTED_INVOICE_DATA` i każdy wymaga innego podejścia. **Praktyczny test który polecam:** idź na demo i zrób najprostszą możliwą korektę - zmień kwotę z 100zł na 120zł, jena pozycja, kontrahent z Polski. Jak przejdzie, celowo zrób błąd (np. podaj błędny numer oryginalnej faktury) żeby zobaczyć komunikaty błędów. Zrozumiesz wtedy logikę systemu. **Edge case który odkryłem podczas testów** - jeśli oryginalna faktura miała błąd w kodzie pocztowym kontrahenta (np. 00-001 zamiast 00001), korekta też będzie odrzucona z tym samym błędem. Sstem nie pozwala korygować błędów w danych podstawowych kontrahenta - trzeba wtedy anulować oryginalną i wystawić nową. **Ważna rzecz o XML** - w korekcie musisz podać WSZYSTKIE pozycje z nowymi wartościami, nie tylko różnicę. Jeśli zmieniasz kwotę z 1000 na 1200zł, w XML korekty musi być pełna faktura z kwotą 1200zł, a system sam wyliczy różnicę dla celów księgowych. Portal webowy na początku to najlepsza opcja - zobaczysz dokładnie jak system interpretuje Twoje dane i jak wygląda gotowy XML przed wysłaniem.

Świetne odpowiedzi już tutaj są! Dorzucę tylko kilka rzeczy z perspektywy infrastruktury które mogą Ci pomóc uniknąć typowych pułapek przy korektach. **Co do tych błędów które dostajesz** - wklej tutaj dokładny komunikat z systemu, bo "błędy" to za mało żeby pomóc konkretnie. System zwraca precyzyjne kody typu `INVOICE_CORRECTION_INVALID_REFERENCE` czy `VALIDATION_ERROR_AMOUNT` i każdy wymaga innego podejścia. ```xml <!-- Najczęstszy błąd w korektach --> <tns:CorrectedInvoice> <tns:InvoiceNumber>2024/01/123</tns:InvoiceNumber> <!-- Data MUSI być identyczna z oryginałem --> <tns:IssueDate>2024-01-15</tns:IssueDate> </tns:CorrectedInvoice> ``` **Praktyczny test** - idź na demo i zrób najprostszą możliwą korektę. Jedna pozycja, zmiana kwoty z 100zł na 120zł, kontrahent z Polski. Jak przejdzie, celowo zrb błąd (np. podaj błędną datę oryginalnej faktury) żeby zobaczyć komunikaty błędów. **Edge case** który odkryłam przy testach - jeśli oryginalna faktura miała błędny kod pocztowy kontrahenta, korekta też będzie odrzucona z tym samym błędem. System nie pozwala korygować błędów w danych podstawowych - wtedy trzeba anulować i wystawić nową. Portal webowy na początku to najlepsza opcja - zobaczysz dokładnie jak system interpretuje Twoje dane i jak wygląda XML przed wysłaniem. Rate limiting przy korektach jest też niższy (~60 req/min vs 100 dla zwykłych fatur).