logo-it9-svg
Wczytywanie strony...

KSeF a EDI: Redefinicja procesów wymiany danych w przedsiębiorstwach

Wprowadzenie Krajowego Systemu e-Faktur (KSeF) stanowi fundamentalną zmianę dla polskich przedsiębiorstw, wymuszając rewizję dotychczasowych modeli operacyjnych. Jednym z obszarów, który podlega największej transformacji, jest tradycyjna Elektroniczna Wymiana Danych (EDI). Analiza wpływu KSeF na procesy EDI ujawnia konieczność głębokiej adaptacji strategicznej i technologicznej obecnych procesów z tym związanych.

I. E-faktura ustrukturyzowana a zmiana paradygmatu EDI

System EDI (Electronic Data Interchange) od lat stanowi fundament automatyzacji procesów logistycznych i finansowych, bazując na bezpośredniej, ustandaryzowanej wymianie elektronicznych dokumentów między partnerami biznesowymi.

Wprowadzenie KSeF redefiniuje ten model. Faktura wystawiana w ramach KSeF, czyli faktura ustrukturyzowana, nie jest standardowym plikiem PDF czy tradycyjnym komunikatem XML. Jest to plik XML o ściśle zdefiniowanej strukturze (schemat FA_3), opracowanej i walidowanej przez Ministerstwo Finansów.

Kluczowa zmiana polega na obowiązku przesłania każdej faktury do centralnej platformy rządowej w celu uzyskania unikalnego identyfikatora (numeru KSeF). Dopiero po tym kroku faktura jest uznana za prawnie wprowadzoną do obrotu i może zostać dostarczona do odbiorcy.

Ten nowy wymóg przerywa dotychczasowy, bezpośredni i natychmiastowy obieg dokumentów w modelu EDI, co stanowi główną przyczynę konieczności redefinicji procesów wewnętrznych w przedsiębiorstwach.

II. Przerwanie klasycznego procesu wymiany danych (EDI)

W tradycyjnym modelu proces był liniowy: faktura generowana w systemie ERP (np. w module SAP SD) była konwertowana do formatu EDI (np. EDIFACT INVOIC) i przekazywana bezpośrednio do kontrahenta, gdzie była automatycznie procesowana.

Platforma KSeF wprowadza nową, obowiązkową sekwencję zdarzeń:

1. Faktura musi zostać wygenerowana zgodnie ze schematem FA_3 i wysłana do KSeF w celu walidacji.

2. Dopiero po pozytywnej weryfikacji i nadaniu przez system unikalnego numeru KSeF oraz (opcjonalnie) wygenerowaniu Urzędowego Poświadczenia Odbioru (UPO), faktura jest uznana za prawnie wystawioną.

3. W konsekwencji, faktury nie mogą być przekazywane bezpośrednio do kontrahentów za pośrednictwem systemu EDI przed ich pomyślną rejestracją w KSeF.

Ta fundamentalna zmiana oznacza, że firmy, które zdecydują się na utrzymanie EDI dla faktur, muszą wdrożyć mechanizmy opóźnionej wysyłki (delayed dispatch). Muszą również uwzględniać one czas przetwarzania dokumentu przez system rządowy, który może wynosić od kilku minut do dłuższego okresu, szczególnie w przypadku wystąpienia trybów offline lub awarii.

III. Strategiczne modele integracji EDI z KSeF

Decyzja o sposobie integracji EDI z KSeF ma charakter strategiczny i jest podyktowana głównie wymaganiami partnerów biznesowych. Przedsiębiorstwa muszą ocenić, jakie dane i w jakim formacie są nadal oczekiwane przez ich kontrahentów.

Model 1: Rezygnacja z EDI dla faktur

W tym modelu zakłada się, że wyłącznie dokumenty poprzedzające fakturę (jak zamówienie, awizo dostawy czy potwierdzenie dostawy) są wymieniane tradycyjnie przez EDI.

· Dostawca wysyła fakturę wyłącznie do KSeF.

· Po walidacji i nadaniu numeru KSeF, faktura nie jest dodatkowo przesyłana przez EDI.

· Odbiorca ma prawny obowiązek pobrać fakturę ustrukturyzowaną bezpośrednio z KSeF.

Jest to rozwiązanie najprostsze pod względem technicznym, jednak wiąże się z rezygnacją z automatyzacji procesowania faktur po stronie partnerów, którzy dotychczas polegali na komunikatach EDI.

Model 2: Utrzymanie równoległej komunikacji EDI

Modele alternatywne (hybrydowe) są wybierane przez przedsiębiorstwa, dla których EDI pozostaje kluczowym elementem łańcucha dostaw, lub których partnerzy nadal wymagają otrzymywania faktur tradycyjnymi kanałami.

Główną przyczyną jest fakt, że komunikat EDI (np. INVOIC) często zawiera uzupełniające informacje biznesowe (np. numery partii, daty przydatności, szczegółowe referencje logistyczne), które nie są przewidziane w obowiązkowej strukturze KSeF.

Niezależnie od wybranego wariantu technicznego (np. wysyłka „propozycji” faktury do operatora EDI, który konwertuje ją do KSeF, czy tworzenie dokumentu EDI po otrzymaniu numeru KSeF), kluczowe pozostają dwie zasady:

• Dokument EDI/PDF wysyłany do kontrahenta po akceptacji przez KSeF nie jest nową fakturą. Jest traktowany jako kolejny (elektroniczny) egzemplarz tej samej faktury ustrukturyzowanej i nie rodzi samoistnie obowiązku podatkowego.

• Podatnik musi zagwarantować, że w przesyłanym dokumencie EDI (np. w segmencie RFF) znalazł się unikalny numer KSeF ID.

Decyzja o kontynuacji wysyłki poprzez EDI jest zatem bezpośrednio związana z potrzebą przekazywania bardziej szczegółowych danych transakcyjnych, niż te wymagane przez Ministerstwo Finansów.

IV. Wpływ trybów KSeF na procesy EDI

Nowe tryby fakturowania (online, offline, awaryjny) wprowadzają dodatkowe wyzwania w zakresie integracji EDI, wymuszając szczególną dbałość o chronologię i terminowość przesyłania dokumentów.

· Komunikacja w trybie online: Jest to tryb standardowy. Aby zachować zgodność prawną, wysyłka faktury poprzez interfejs EDI musi zostać zablokowana do momentu, aż KSeF przyjmie dokument i nada mu KSeF ID. Dopiero po pomyślnym zakończeniu tego etapu można aktywować wysyłkę komunikatu EDI do kontrahenta, wzbogaconego o uzyskany numer KSeF.

· Komunikacja w trybach offline i awaryjnym: W tych trybach data otrzymania faktury przez nabywcę ma kluczowe znaczenie dla rozliczeń VAT. Może nią być data faktycznego doręczenia faktury poza KSeF (np. przez EDI) albo data nadania numeru KSeF – w zależności od tego, która z tych dat wystąpi jako pierwsza. Wizualizacje faktur (PDF) przekazywane w tym trybie muszą zawierać specyficzne kody QR („OFFLINE” oraz „CERTYFIKAT”).

V. Kluczowe wyzwania techniczne i standaryzacja

Kluczowym wyzwaniem technicznym jest zapewnienie powiązania między dokumentem EDI a jego odpowiednikiem w KSeF. Numer KSeF ID jest niezbędny do automatyzacji procesu po stronie nabywcy (np. do automatycznego pobrania poprawnej faktury ustrukturyzowanej z KSeF).

Zgodnie z wytycznymi branżowymi (np. Grupy EDI GS1 Polska), w modelach utrzymujących EDI, numer KSeF ID należy obligatoryjnie zamieścić w odpowiednich segmentach RFF (Reference) komunikatów INVOIC i CORINV, używając kwalifikatorów GN i GNM. Bez tego powiązania automatyzacja u nabywcy jest znacząco utrudniona.

Kody QR są elementem wymaganym na wizualizacji faktury (np. wydruku, pliku PDF) przekazywanej poza KSeF. Służą one weryfikacji dokumentu i zapewnieniu dostępu do faktury ustrukturyzowanej.

Należy podkreślić, że prawnie komunikat EDI (np. EDIFACT) jest ustrukturyzowanym plikiem danych przeznaczonym do przetwarzania maszynowego (system-system), a nie wizualizacją przeznaczoną do odczytu przez człowieka. Z tego powodu nie ma wytycznych nakazujących umieszczanie graficznego kodu QR wewnątrz ustrukturyzowanego komunikatu EDIFACT.

Pojawiają się propozycje rozwiązań polegających na wprowadzeniu do komunikatu EDI dedykowanego pola zawierającego adres URL (odwołujący się do wizualizacji i trybu wystawienia faktury), który mógłby być nośnikiem informacji zawartej w kodzie QR. Należy jednak zaznaczyć, że:

· Wymaga to dodatkowych prac programistycznych i integracyjnych po obu stronach (nadawcy i odbiorcy).

· Nie zostało to dotychczas potwierdzone jako standardowe rozwiązanie przez organizacje ustanawiające standardy (np. GS1), gdyż regulacje odnoszą się do graficznych kodów QR na wizualizacjach.

VI. Podsumowanie: EDI jako kanał danych uzupełniających

Wprowadzenie KSeF fundamentalnie rewiduje rolę EDI w procesie fakturowania. Z podstawowego kanału wystawiania i dostarczania faktur, EDI staje się kanałem udostępniania dodatkowych danych biznesowych, które uzupełniają obowiązkowy standard KSeF.

Największym wyzwaniem operacyjnym i technicznym jest przerwanie klasycznego, natychmiastowego obiegu EDI i wdrożenie mechanizmu opóźnionej wysyłki. Interfejs EDI musi być wstrzymany do momentu walidacji faktury przez KSeF i uzyskania numeru KSeF ID. Następnie, ten 35-znakowy identyfikator musi zostać poprawnie zaimplementowany w komunikacie EDI i wysłany do klienta, wraz z informacją o trybie, w jakim dokument źródłowy został wygenerowany.

Decyzja o kontynuowaniu lub zaprzestaniu używania EDI dla faktur jest wyłączną domeną firm i ich partnerów handlowych. Jeżeli partnerzy wymagają szczegółowych danych procesowych, których brakuje w strukturze KSeF, utrzymanie i dostosowanie kanału EDI będzie koniecznością. Jeśli jednak procesy biznesowe partnerów mogą bazować wyłącznie na danych z KSeF, nowy system stwarza możliwość rezygnacji z utrzymywania tej formy wymiany danych dla faktur.

Scroll to Top