Niezależny plan testów odbiorczych na 2026 rok

Jak przetestować oprogramowanie e-reporting dla Francji przed wdrożeniem

Praktyczny plan demo i testów akceptacyjnych francuskiego e-reportingu: B2C, zagranica, wpływy, korekty, odrzucenia, PA i ścieżka audytu.

Praktyczne podsumowanie:
  • Nie zaliczaj demo bez eksportowalnych dowodów z każdego scenariusza.
  • Największą wartość ma test pełnego przepływu między systemami, nie pojedynczego ekranu.
  • Warunkowe odpowiedzi dostawcy zamieniaj w nazwane zadania, terminy i właścicieli.
Ostatnia aktualizacja: 24 lipca 2026Źródła oficjalneJasne podsumowanieInformacja praktyczna, nie porada prawna
Priorytet dla źródeł oficjalnych
Widoczne daty weryfikacji
Darmowy checker bez rejestracji

Co warto wiedzieć

Przewodnik

1. Najpierw ustal zakres reformy i definicję wyniku pozytywnego

DGFiP rozdziela reformę na trzy zakresy. Pierwszy to krajowe fakturowanie elektroniczne B2B. Drugi to e-reporting danych o transakcjach, między innymi sprzedaży i usług dla osób niebędących podatnikami, takich jak konsumenci, oraz operacji z podmiotami mającymi siedzibę poza Francją. Trzeci to e-reporting płatności lub wpływów dla operacji, w których VAT staje się należny przy zapłacie, typowo dla usług, jeżeli nie wybrano VAT od obciążeń i nie działa odwrotne obciążenie. Od 1 września 2026 r. wszystkie przedsiębiorstwa muszą umieć odbierać e-faktury. Duże i średnie podmioty od tej daty także je wystawiają i raportują, natomiast małe i mikroprzedsiębiorstwa mają na wystawianie oraz e-reporting czas do 1 września 2027 r. W teście należy oddzielić gotowość do odbioru, wystawiania i raportowania; zielony status jednego strumienia nie oznacza gotowości pozostałych. Przed demo zatwierdź pisemne kryteria: prawidłowa klasyfikacja zakresu, kompletne mapowanie danych, kontrolowana transmisja przez zatwierdzoną platformę (plateforme agréée, PA), obsługa statusów i błędów, uzgodnienie wartości oraz eksportowalny audyt trail, czyli ścieżka audytu. Każdy scenariusz powinien mieć wynik zaliczony, warunkowo zaliczony albo niezaliczony, z właścicielem i terminem usunięcia luki. • Potwierdź populację testową: podmioty francuskie, numery SIREN, zakłady, systemy źródłowe, reżimy VAT i typy klientów. • Rozpisz trzy osobne strumienie: krajowe B2B e-fakturowanie, e-reporting transakcji oraz e-reporting płatności lub wpływów. • Zdefiniuj dowód zaliczenia: rekord źródłowy, komunikat wyjściowy, identyfikator transmisji, status PA, dziennik zmian i raport uzgodnienia. • Zaznacz przypadki wymagające potwierdzenia z doradcą, PA lub aktualną dokumentacją DGFiP zamiast przyjmować domyślne reguły dostawcy.

Przewodnik

2. Przygotowanie przed demo: dane, środowisko i odpowiedzialność

Poproś dostawcę o demo na odizolowanym środowisku z danymi podobnymi do własnych, ale pozbawionymi danych osobowych. Zwykły PDF wysłany e-mailem nie jest zgodną e-fakturą. W przepływach fakturowych sprawdź obsługę ustrukturyzowanych podejść UBL, CII i mieszanego Factur-X oraz to, czy prezentowany dokument i dane maszynowe pozostają spójne. Ustal architekturę przed rozpoczęciem testu. Rozwiązanie zgodne lub rozwiązanie kompatybilne może przygotowywać dane i łączyć systemy, lecz nie wykonuje samo regulowanych transmisji, jeżeli nie jest zatwierdzoną platformą PA. Dostawca powinien wskazać konkretną PA, model połączenia, zakres odpowiedzialności, środowisko testowe, monitoring, umowę wsparcia i sposób postępowania po zmianie specyfikacji. Zamroź zestaw wejściowy i oczekiwane wyniki przed demonstracją, aby nie dopasowywać kryteriów do tego, co akurat potrafi produkt. Dokładna częstotliwość raportowania i mapowania zależy od reżimu VAT, rodzaju operacji, aktualnych specyfikacji oraz konfiguracji platformy; dlatego każdą przyjętą regułę oznacz źródłem, wersją i datą walidacji. • Przygotuj słownik pól z ERP, programu do fakturowania, POS lub kasy, księgowości i API, wraz z właścicielami danych. • Zbuduj kontrolowany pakiet transakcji obejmujący różne stawki VAT, waluty, typy kontrahentów, płatności i korekty. • Wymagaj diagramu połączenia od systemu źródłowego do PA i DGFiP, z zaznaczeniem kolejek, retry, statusów i punktów ręcznej ingerencji. • Zapisz wersje schematów UBL, CII lub Factur-X, reguł walidacji, konektorów, konfiguracji podatkowej i środowiska użytego podczas testu. • Przydziel właścicieli: biznes klasyfikuje zdarzenia, podatki zatwierdzają reguły, IT odpowiada za integrację, a dostawca i PA za swoje elementy transmisji.

Przewodnik

3. Testy 1–2: krajowe B2C i dzienna agregacja

Dane o krajowej sprzedaży B2C są zwykle agregowane dziennie według stawki VAT, a dane osobowe klienta nie są oczekiwane. Test ma wykazać, że POS, kasa lub system sprzedażowy przekazuje pełne i uzgadnialne sumy, nie ujawnia zbędnych danych konsumenta i nie miesza dni, stawek, zwrotów ani jednostek organizacyjnych. Nie ograniczaj testu do sytuacji, w której wystawiono fakturę. W wielu operacjach detalicznych źródłem będą paragony lub zbiorcze totalizatory kasy. Odbiór należy oprzeć na porównaniu raportu zamknięcia dnia, księgi VAT, komunikatu wysłanego do PA i końcowego statusu, z jasno wyjaśnionymi różnicami zaokrągleń. • Test 1 — krajowa agregacja B2C według stawek. Wejście: jeden dzień sprzedaży obejmujący co najmniej dwie stawki VAT, zwolnienie oraz zwrot. Oczekiwany wynik: oddzielne dzienne sumy podstawy i VAT według właściwej klasyfikacji, bez danych osobowych klientów i z kontrolą sum. Dowód: eksport z POS, komunikat do PA, identyfikator partii, potwierdzenie przyjęcia i raport uzgodnienia do księgi VAT. • Test 2 — B2C bez faktury, na podstawie totalizatorów POS lub kasy. Wejście: paragony, anulowany paragon, przerwa w numeracji i zamknięcie dnia z kilku kas. Oczekiwany wynik: kompletne, niepodwójne dzienne dane transakcyjne, poprawne uwzględnienie anulowania i widoczna informacja o brakującym źródle. Dowód: raporty Z, log importu, wyliczenie agregatu, komunikat PA i zapis obsługi wyjątku. • Kryterium negatywne: system wysyła pojedyncze dane konsumentów bez uzasadnienia, łączy wiele dni w jedną nieprzejrzystą sumę albo nie potrafi przejść od agregatu do kontrolowanych źródeł. • Pytanie do dostawcy: jak rozwiązanie traktuje sprzedaż po północy, strefy czasowe, późny import z kasy, zwroty z innego dnia oraz ponowne otwarcie zamkniętego okresu?

Przewodnik

4. Testy 3–4: zagraniczne B2B, waluty, eksport i transakcje wewnątrz UE

Transakcje z operatorami mającymi siedzibę poza Francją mogą należeć do e-reportingu transakcji, nawet gdy klient jest firmą. Dla zagranicznego kontrahenta zagraniczny numer VAT lub inny identyfikator może zastąpić SIREN tam, gdzie ma to zastosowanie. Test powinien sprawdzić walidację bez wymuszania fikcyjnego francuskiego numeru oraz zachowanie oryginalnej waluty i kontrolowanego przeliczenia. Etykieta „zagranica” jest zbyt ogólna. System powinien rozróżnić eksport, dostawę lub usługę wewnątrzunijną i inne przypadki na podstawie danych źródłowych oraz zatwierdzonych reguł. Nie należy zakładać jednej uniwersalnej kwalifikacji podatkowej; oczekiwane mapowanie dla własnych przypadków trzeba potwierdzić z doradcą, PA i aktualną dokumentacją DGFiP. • Test 3 — zagraniczne B2B z identyfikatorem i walutą obcą. Wejście: klient bez SIREN, z prawidłowym zagranicznym numerem VAT lub identyfikatorem, faktura w GBP albo USD i kontrolny kurs. Oczekiwany wynik: brak fałszywego błędu SIREN, zachowanie wartości i waluty źródłowej, prawidłowe pola przeliczeniowe oraz routing do e-reportingu. Dowód: kartoteka klienta, dokument źródłowy, payload API, reguła kursowa, status PA i uzgodnienie księgowe. • Test 4 — eksport i operacja wewnątrz UE. Wejście: dwie podobne sprzedaże różniące się krajem, identyfikatorem, miejscem opodatkowania i kodem transakcji. Oczekiwany wynik: odrębna, uzasadniona klasyfikacja i właściwy zestaw danych bez automatycznego wrzucenia obu do jednego koszyka. Dowód: reguła decyzyjna, dane podstawowe kontrahenta, komunikaty wyjściowe, wynik walidacji PA i akceptacja podatkowa scenariusza. • Kryterium negatywne: rozwiązanie wymaga ręcznej zmiany kraju na Francję, gubi oryginalną walutę albo klasyfikuje operację wyłącznie na podstawie domeny adresu lub formatu numeru klienta. • Pytanie do dostawcy: gdzie przechowywana jest podstawa klasyfikacji i jak można wykazać po roku, która wersja reguły skierowała daną transakcję do określonego raportu?

Przewodnik

5. Testy 5–7: usługi, wpływy, częściowe płatności i zaliczki

E-reporting płatności dotyczy operacji, dla których VAT jest należny przy wpływie, niezależnie od tego, czy klient jest firmą czy konsumentem. DGFiP wskazuje między innymi datę wpływu i kwotę otrzymaną z podziałem według stawki VAT. W przypadku e-faktury informacja o zapłacie może uzupełniać fakturę statusem „encaissée”, czyli otrzymano zapłatę. Demo powinno zacząć się od rzeczywistego zdarzenia bankowego, kasowego lub z bramki płatniczej, a nie od ręcznego zaznaczenia faktury jako zapłaconej. Trzeba przetestować datę wartości, datę księgowania, identyfikację faktury, rozdział kwoty na stawki VAT, płatność częściową, nadpłatę i nierozpoznany wpływ. • Test 5 — krajowa faktura usługowa z VAT należnym przy wpływie. Wejście: faktura za usługę z dwiema stawkami, bez wyboru VAT od obciążeń i bez odwrotnego obciążenia, następnie pełna płatność. Oczekiwany wynik: zdarzenie wpływu z właściwą datą i podziałem kwoty według stawek oraz powiązanie ze statusem „encaissée”. Dowód: faktura, zapis bankowy, reguła rozliczenia, komunikat płatniczy, status PA i historia faktury. • Test 6 — płatność częściowa w dwóch datach. Wejście: jedna faktura, dwa wpływy w różnych okresach, z drugim wpływem obejmującym resztę i drobną różnicę kursową lub zaokrąglenie. Oczekiwany wynik: dwa odrębne zdarzenia, brak przedwczesnego statusu pełnej zapłaty, poprawna pozostała kwota i końcowe uzgodnienie. Dowód: wyciągi, dopasowania płatności, dwa payloady, potwierdzenia PA i raport otwartych pozycji. • Test 7 — depozyt lub zaliczka. Wejście: zaliczka przed fakturą końcową, późniejsze rozliczenie i ewentualny zwrot części. Oczekiwany wynik: kontrolowana kwalifikacja zdarzeń i powiązanie zaliczki z dokumentem końcowym bez podwójnego raportowania wartości. Dowód: dokument zaliczkowy, wpływ, faktura końcowa, historia alokacji, komunikaty oraz zatwierdzona notatka o przyjętej regule podatkowej. • Kryterium negatywne: moduł płatności zna tylko status zapłacona lub niezapłacona, nie przechowuje dat poszczególnych wpływów albo nie umie wyjaśnić podziału otrzymanej kwoty według stawek VAT.

Przewodnik

6. Testy 8–10: korekty, wyłączenia, odrzucenia i odporność integracji

Najwięcej ryzyka ujawnia się po pierwszej transmisji. Oprogramowanie musi zachować związek między dokumentem pierwotnym, korektą, zwrotem, anulowaniem, odrzuconą partią i ponownym wysłaniem. Ręczna edycja wysłanego rekordu bez wersjonowania nie jest akceptowalnym mechanizmem kontroli. Wymagaj testu awarii i powtórzenia. Idempotencja oznacza, że ponowienie tego samego żądania nie tworzy drugiego skutku biznesowego. Pełny audyt trail powinien łączyć identyfikator źródłowy, wersję mapowania, hash lub inną kontrolę integralności, identyfikator komunikatu, status PA, użytkownika lub usługę wykonującą zmianę oraz wynik uzgodnienia. • Test 8 — nota kredytowa, refundacja i anulowanie. Wejście: sprzedaż już zaraportowana, częściowy credit note, zwrot środków i osobne anulowanie błędnego dokumentu. Oczekiwany wynik: każde zdarzenie ma właściwy znak, typ, odwołanie i wpływ na agregat, bez usuwania historii. Dowód: dokumenty źródłowe, powiązania, komunikaty przed i po korekcie, potwierdzenia PA oraz raport zmian. • Test 9 — VAT od obciążeń lub odwrotne obciążenie. Wejście: dwa przypadki usługowe, z których jeden ma udokumentowany wybór VAT-on-debits, a drugi odwrotne obciążenie. Oczekiwany wynik: płatność nie trafia automatycznie do raportowania wpływów, a transakcja jest skierowana zgodnie z potwierdzoną regułą. Dowód: ustawienia podatkowe, uzasadnienie klasyfikacji, log reguły, wynik transmisji lub kontrolowanego wyłączenia i akceptacja właściciela podatkowego. • Test 10 — odrzucona, poprawiona i ponownie wysłana partia oraz duplikat. Wejście: partia z celowo błędnym polem, korekta, ponowne wysłanie tego samego identyfikatora i techniczne powtórzenie po timeout. Oczekiwany wynik: czytelny błąd, kontrolowana korekta, pojedynczy skutek po retry, brak duplikatu oraz pełne uzgodnienie eksportu z księgą. Dowód: oryginalny i poprawiony payload, kody błędów, kolejka retry, klucz idempotencji, statusy PA, eksport audytowy i raport różnic równy zero albo wyjaśniony. • Kryterium negatywne: operator musi usuwać rekord w bazie, system nie odróżnia błędu biznesowego od technicznego albo eksport pomija odrzucone i historyczne wersje komunikatu.

Przewodnik

7. Przykład liczbowy: jak ocenić wynik bez udawania uniwersalnej kalkulacji

Przykład jest wyłącznie ilustracyjny. Załóżmy, że francuski punkt sprzedaży jednego dnia rejestruje 1 200 EUR netto przy stawce 20% i 500 EUR netto przy stawce 10%, a także zwrot 100 EUR netto dotyczący sprzedaży ze stawką 20%. Oczekiwany agregat kontrolny wynosiłby w tym uproszczonym przykładzie 1 100 EUR netto i 220 EUR VAT dla 20% oraz 500 EUR netto i 50 EUR VAT dla 10%. Test nie dowodzi jednak, że taka prezentacja jest właściwa dla każdego reżimu lub typu operacji. Następnie załóżmy fakturę usługową na 1 000 EUR netto plus 200 EUR VAT, dla której w przyjętym scenariuszu VAT jest należny przy wpływie. Klient płaci 480 EUR 28 września i 720 EUR 7 października. System powinien zachować dwa zdarzenia wpływu, ich daty i łączne powiązanie z fakturą na 1 200 EUR; nie powinien oznaczyć całości jako otrzymanej już po pierwszej płatności. Dostawca powinien pokazać, jak rozwiązanie rozdziela otrzymaną kwotę na podstawę i VAT oraz jak zasila konkretny komunikat wymagany w danej konfiguracji. Nie wpisuj oczekiwanej metody alokacji na podstawie samego przykładu: potwierdź ją dla własnych transakcji, reżimu VAT, bieżących specyfikacji DGFiP i konfiguracji PA. • Porównaj sumy wejściowe z agregatem przed transmisją, payloadem PA, potwierdzeniem oraz księgą VAT. • Sprawdź osobno datę sprzedaży, datę dokumentu, datę wpływu, datę księgowania i okres raportowy. • Wymagaj wyjaśnienia każdego zaokrąglenia oraz wskazania poziomu, na którym jest ono wykonywane. • Powtórz przykład po korekcie i po timeout, aby potwierdzić brak podwójnej wartości. • Zapisz kalkulację kontrolną jako część pakietu odbiorowego, ale nie traktuj jej jako porady dotyczącej wszystkich przypadków.

Przewodnik

8. Macierz decyzji: pytania zaliczone lub niezaliczone

Macierz powinna wymuszać odpowiedź tak lub nie popartą dowodem. Odpowiedź „będzie w roadmapie” oznacza wynik warunkowy, nie zaliczenie. Dla każdej luki zapisz wpływ, obejście, właściciela, koszt, datę wydania, zależność od PA oraz warunek ponownego testu. Oceniaj cały łańcuch, nie tylko moduł dostawcy. Nawet dobry ekran nie naprawi brakującego identyfikatora w ERP, niewłaściwego kodu VAT w programie księgowym, niepełnego zamknięcia POS ani braku statusu zwrotnego z PA. Ostateczna akceptacja powinna należeć wspólnie do finansów, podatków, operacji, IT i właściciela procesu. • Zakres i klasyfikacja: czy system uzasadnia, dlaczego rekord trafia do krajowego B2B e-fakturowania, e-reportingu transakcji, e-reportingu płatności albo kontrolowanego wyłączenia? • Połączenie z PA: czy wskazano zatwierdzoną platformę, środowisko, interfejs, SLA, statusy zwrotne i granice odpowiedzialności rozwiązania kompatybilnego? • Mapowanie: czy każde obowiązkowe pole ma źródło, transformację, walidację, właściciela i wersję, a zagraniczny identyfikator nie wymaga SIREN? • Płatności i korekty: czy daty i kwoty wpływów według stawek, częściowe zapłaty, zaliczki, noty kredytowe, zwroty i anulowania zachowują właściwe powiązania? • Odrzucenia i uzgodnienie: czy błędy są czytelne, retry jest idempotentne, a raport różnic obejmuje przyjęte, oczekujące, odrzucone, poprawione i ponowione rekordy? • Bezpieczeństwo i uprawnienia: czy role rozdzielają konfigurację podatkową, zatwierdzenie, wysyłkę i korektę, a log jest odporny na nieautoryzowaną zmianę? • Eksport, wdrożenie i wsparcie: czy dane, statusy i audyt trail można wyeksportować w używalnym formacie oraz czy właściciele, terminy, monitoring i eskalacja są zapisane umownie?

Przewodnik

9. Ryzyka, typowe błędy i konkretne następne kroki

Najczęstszy błąd zakupowy to utożsamienie deklarowanej kompatybilności z prawem do regulowanej transmisji. Sprawdź aktualny status platformy na stronie DGFiP i umowę połączenia. Inne ryzyka to testowanie wyłącznie poprawnych faktur, pominięcie B2C bez faktury, raportowanie płatności według typu klienta zamiast momentu powstania VAT, brak obsługi częściowych wpływów oraz uzgodnienie tylko na poziomie łącznej kwoty. Nie opieraj decyzji na pojedynczym zrzucie ekranu ani marketingowym certyfikacie bez zakresu. Zachowaj pakiet dowodowy, listę otwartych luk i podpisaną decyzję. Przed wdrożeniem zweryfikuj dokładną częstotliwość raportowania, mapowania, kody i terminy w aktualnych materiałach DGFiP oraz z doradcą i wybraną PA, ponieważ zależą one od reżimu VAT, rodzaju transakcji i bieżącej specyfikacji. Po demo zamień wyniki w plan naprawczy i powtórz tylko scenariusze dotknięte zmianą wraz z testem regresji krytycznych przepływów. Uruchom próbę wolumenu, awarii połączenia i zamknięcia okresu, a następnie wykonaj kontrolowane przejście produkcyjne z monitoringiem, procedurą eskalacji i możliwością odtworzenia każdego komunikatu. • W ciągu 48 godzin po demo wydaj protokół z wynikiem każdego testu, dowodami, lukami i pytaniami bez odpowiedzi. • Zweryfikuj dostawcę PA i aktualny status na stronie DGFiP; nie polegaj wyłącznie na terminologii PDP używanej w starszych materiałach. • Uzgodnij z doradcą i PA przypadki graniczne: miejsce opodatkowania, VAT od wpływu, VAT-on-debits, odwrotne obciążenie, zaliczki i korekty. • Przeprowadź test wydajności na realistycznym wolumenie oraz test odtworzenia po przerwie w ERP, API lub połączeniu z PA. • Nie podpisuj odbioru, dopóki krytyczne luki nie są zamknięte albo formalnie zaakceptowane z konkretnym, kontrolowanym obejściem.

Lista kontrolna

Zatwierdź listę podmiotów, SIREN, systemów źródłowych, reżimów VAT i odpowiedzialnych właścicieli.

Rozdziel kryteria odbioru dla odbioru e-faktur, wystawiania e-faktur, e-reportingu transakcji i danych o wpływach.

Potwierdź konkretną zatwierdzoną platformę PA, zakres połączenia oraz status rozwiązania kompatybilnego.

Przygotuj zanonimizowane dane obejmujące wszystkie 10 scenariuszy, wraz z oczekiwanymi wynikami kontrolnymi.

Zmapuj pola z ERP, programu do fakturowania, POS lub kasy, księgowości i API do wersjonowanej specyfikacji.

Zarejestruj payloady, identyfikatory, statusy PA, kody błędów, retry i zmiany dokonane przez użytkowników.

Uzgodnij transakcje, płatności i korekty z księgą VAT, wyciągami oraz raportami zamknięcia dnia.

Sprawdź role, rozdział obowiązków, kontrolę dostępu, retencję logów i eksport pełnej ścieżki audytu.

Przypisz każdej luce właściciela, wpływ, termin, koszt, obejście i obowiązkowy ponowny test.

Przed produkcją potwierdź aktualne reguły z DGFiP, doradcą i PA oraz przeprowadź test awarii, wolumenu i regresji.

Najczęstsze pytania

Jak przetestować oprogramowanie e-reporting we Francji, aby demo było wiarygodne?

Użyj zamrożonego zestawu danych obejmującego B2C, zagraniczne B2B, płatności, korekty i błędy. Dla każdego scenariusza porównaj rekord źródłowy, regułę klasyfikacji, payload, status PA, księgowanie i eksport audytowy. Za dowód nie uznawaj samego ekranu ani ustnej deklaracji; wymagaj identyfikatorów transmisji, komunikatów zwrotnych i uzgodnienia wartości.

Czy ERP lub program do fakturowania potrzebuje połączenia z zatwierdzoną platformą PA?

Tak, jeśli sam nie ma statusu zatwierdzonej platformy, regulowana wymiana i transmisja muszą przebiegać przez PA. ERP, program księgowy lub rozwiązanie kompatybilne może tworzyć dokumenty, mapować dane i obsługiwać proces, ale dostawca powinien pokazać konkretną PA, interfejs, statusy zwrotne i granice odpowiedzialności. Aktualny status platformy należy sprawdzić w materiałach DGFiP.

Jak sprawdzić dzienną agregację danych o transakcjach B2C?

Przygotuj dzień sprzedaży z kilkoma stawkami VAT, zwrotem, anulowaniem i danymi z więcej niż jednej kasy. Porównaj raporty Z lub eksport POS z agregatem według stawek, komunikatem PA i księgą VAT. Sprawdź brak zbędnych danych osobowych, kontrolę późnego importu oraz możliwość wyjaśnienia każdej różnicy i zaokrąglenia.

Jakie scenariusze płatności i danych o wpływach warto sprawdzić?

Co najmniej pełną zapłatę za usługę z VAT należnym przy wpływie, dwie częściowe płatności w różnych datach, zaliczkę, refundację, nierozpoznany wpływ i przypadek wyłączony z powodu VAT od obciążeń lub odwrotnego obciążenia. System powinien przechowywać datę i kwotę każdego wpływu, podział według stawek VAT, powiązanie z dokumentem i pełną historię statusów.

Jak testować częściowe płatności i korekty bez podwójnego raportowania?

Wyślij dwa wpływy do jednej faktury, potem credit note lub zwrot, a następnie zasymuluj timeout i techniczne ponowienie. Oczekuj odrębnych zdarzeń z poprawnym saldem, referencjami do dokumentu pierwotnego i kluczem idempotencji. Uzgodnienie powinno wykazać jeden skutek biznesowy każdego zdarzenia mimo ponownego wysłania.

Czy zwykły PDF lub faktura wysłana e-mailem wystarczy po reformie?

Nie. Zwykły PDF i e-mail nie stanowią zgodnej faktury elektronicznej w tym systemie. W testach fakturowych sprawdź obsługę danych ustrukturyzowanych w podejściach UBL, CII lub mieszanym Factur-X, spójność warstwy czytelnej z danymi maszynowymi oraz regulowaną wymianę przez zatwierdzoną platformę PA.

Jak testować zagranicznego klienta bez francuskiego numeru SIREN?

Użyj prawidłowego zagranicznego numeru VAT lub innego identyfikatora, gdy ma zastosowanie, oraz transakcji w walucie obcej. System nie powinien wymuszać fikcyjnego SIREN. Powinien zachować identyfikator i walutę źródłową, udokumentować przeliczenie, rozróżnić eksport od operacji wewnątrz UE oraz pokazać routing zgodny z zatwierdzoną kwalifikacją.

Jakie dowody powinien pokazać dostawca po teście odrzucenia i ponownej wysyłki?

Poproś o oryginalny i poprawiony payload, kod oraz opis błędu, identyfikator partii, historię kolejki i retry, klucz idempotencji, statusy zwrotne PA, użytkownika lub usługę wykonującą zmianę i końcowy raport uzgodnienia. Eksport powinien obejmować również odrzucone oraz historyczne wersje, a nie tylko ostatni stan poprawnego rekordu.

Kluczowe przepisy, formaty i pojęcia

Komisja EuropejskaEN 16931Dyrektywa 2014/55/UEustrukturyzowana faktura elektronicznaPlan demonstracji i testów odbiorczych francuskiego e-reportingu na lata 2026/2027Francja

Czytaj dalej

Źródła oficjalne

Priorytetowo traktujemy oficjalne źródła rządowe i UE, gdy są dostępne, oraz pokazujemy daty weryfikacji.