Gdy faktura zostaje przesłana do eConnect, dokument przechodzi przez szereg etapów przetwarzania. Sposób przetwarzania zależy od typu pliku (XML lub PDF) oraz jakości dostarczonego pliku. Niniejszy artykuł wyjaśnia, co dzieje się za kulisami.

eConnect oferuje dwie zasadniczo różne ścieżki przetwarzania:

Przetwarzanie XML (ścieżka bezpośrednia): jeśli przesłana zostanie prawidłowa faktura UBL (SI-UBL 2.0, Peppol BIS Billing 3.0 lub inny obsługiwany format XML), jest ona przetwarzana bezpośrednio. Platforma odczytuje dane strukturalne z pliku XML, waliduje je i kieruje dokument do odbiorcy. Jest to najszybsza i najbardziej niezawodna ścieżka.

Przetwarzanie PDF (konwersja przez IDR): jeśli przesłana zostanie faktura w formacie PDF, jest ona przetwarzana przez Intelligent Document Recogniser (IDR). IDR wyodrębnia dane faktury za pomocą OCR i rozpoznawania wzorców, a następnie generuje fakturę UBL na podstawie rozpoznanych danych. Proces ten jest z natury mniej niezawodny niż bezpośrednie przetwarzanie XML, ponieważ zależy od jakości pliku PDF.

Wskazówka: przesyłanie w formacie UBL jest zawsze preferowane w stosunku do PDF. Jest szybsze, tańsze i bardziej niezawodne. Warto sprawdzić u swojego dostawcy lub w pakiecie oprogramowania, czy eksport UBL jest dostępny.

Przy przesyłaniu pliku XML eConnect wykonuje następujące kroki:

Platforma automatycznie rozpoznaje format pliku na podstawie CustomizationID i schematu XML. Obsługiwane formaty to między innymi NLCIUS, BIS Billing V3, XRechnung, CII i Factur-X.

Faktura jest walidowana zgodnie z regułami rozpoznanego profilu. Obejmuje to:

• Walidacja schematu: czy XML jest zgodny ze strukturą schematu UBL 2.1 lub CII?
• Reguły biznesowe: czy obliczenia są poprawne? Czy wymagane pola są wypełnione? Czy wartości list kodów się zgadzają?
• Reguły krajowe: czy przestrzegane są odpowiednie reguły NL-R-, DK-R- lub inne reguły krajowe?

Wskazówka: Otrzymuje Państwo komunikat, że nie znaleziono "reguł walidacji"? Zazwyczaj oznacza to, że CustomizationID w XML jest nieobecny lub nierozpoznany. Bez rozpoznawalnego profilu walidator nie może zastosować reguł biznesowych. Proszę sprawdzić, czy faktura zawiera prawidłowy CustomizationID, taki jak NLCIUS lub BIS Billing V3.

Charakterystyczną cechą przetwarzania eConnect jest automatyczna naprawa plików XML. Za pomocą transformacji XSL korygowane są znane błędy. Platforma akceptuje zasadniczo każdy plik UBL; brakujące pola nieistotne są uzupełniane wartościami domyślnymi. Funkcja naprawy jest stale rozwijana na podstawie opinii klientów i jest gotowa do użytku produkcyjnego.

Przykłady automatycznych napraw:

• Brakujące pola opcjonalne są uzupełniane poprawnymi wartościami domyślnymi
• Znane błędy formatu w polach identyfikacyjnych są korygowane
• Niekompletne dane kontaktowe są uzupełniane (jeśli pole ElectronicMail dostawcy jest puste, eConnect automatycznie wstawia support@econnect.eu, tak aby odrzucone faktury trafiły do nadawcy)

Jeśli odbiorca obsługuje inny format niż format źródłowy, PSB automatycznie transformuje dokument. Na przykład faktura NLCIUS może zostać przekształcona na XRechnung, jeśli odbiorcą jest niemiecki organ publiczny. Jest to możliwe, ponieważ wszystkie obsługiwane formaty opierają się na tym samym modelu semantycznym (EN 16931).

Techniczne: podczas pobierania faktury za pośrednictwem API można podać żądany format odbioru za pomocą parametru targetDocumentTypeId. PSB przekształca wówczas dokument do wskazanego formatu.

eConnect nigdy nie rozpoznaje zamówienia sprzedaży (dokumentu zamówienia) jako faktury i nie konwertuje go automatycznie na fakturę. Jeśli prześlesz zamówienie sprzedaży w miejscu, gdzie oczekiwana jest faktura, dokument zostanie odrzucony.

Dostawca musi samodzielnie dostarczyć prawidłowy dokument faktury: UBL Invoice z odpowiednim InvoiceTypeCode. eConnect nie modyfikuje dokumentu źródłowego i nie wykonuje tej konwersji.

Wyjątek — orderflip: za pomocą funkcji orderflip dane zamówienia mogą służyć jako podstawa do przygotowania roboczej faktury (draft). Jest to odrębna czynność użytkownika, a nie automatyczne przekształcenie zamówienia sprzedaży w ostateczną fakturę. Dostawca musi samodzielnie uzupełnić tę roboczą fakturę i złożyć ją jako ostateczny dokument faktury (UBL Invoice + InvoiceTypeCode).

Uwaga: nie należy mylić rozpoznawania typu dokumentu z rozpoznawaniem referencji. Numer zamówienia sprzedaży, który ma zostać rozpoznany na fakturze (jako OrderReference lub order_reference), jest polem referencji, a nie typem dokumentu. eConnect odczytuje ten numer zamówienia z faktury i powiązuje go jako referencję, nie zmieniając jednak typu dokumentu.

ZUGFeRD i Factur-X to hybrydowe formaty faktur: plik PDF/A-3 z osadzoną fakturą XML CII. W przypadku takich dokumentów platforma najpierw próbuje wyodrębnić osadzony plik XML z pliku PDF. Jeśli plik XML jest prawidłowy, jest przetwarzany bezpośrednio, tak jak zwykła faktura XML. Dopiero gdy osadzony plik XML okaże się nieprawidłowy, system przechodzi na przetwarzanie OCR przez IDR.

Faktura ZUGFeRD, która przechodzi walidację w zewnętrznych walidatorach, ale mimo to jest przetwarzana przez OCR, wskazuje na problem z osadzonym plikiem XML w procesie walidacji eConnect. W takim przypadku można skontaktować się z działem wsparcia.

Techniczne: platforma legacy może przechowywać wyłącznie prawidłowe faktury UBL. Gdy faktura ZUGFeRD jest przetwarzana przez IDR jako PDF, dane wyjściowe IDR muszą najpierw zostać przekształcone na prawidłowy UBL (BIS Billing V3 lub NLCIUS). Jeśli ta transformacja nie powiedzie się, ponieważ dane źródłowe nie zawierają wystarczającej liczby pól do wygenerowania prawidłowej faktury UBL, platforma nie może zapisać faktury. W PSB/Control problem ten jest mniejszy, ponieważ faktury są tam przechowywane w oryginalnym formacie i transformowane dopiero przy dostarczeniu.

Jeśli przesłany plik XML nie jest prawidłowy, system automatycznie przechodzi na dołączony plik PDF. Działa to następująco:

1. Platforma najpierw próbuje przetworzyć komponent XML.
2. Jeśli plik UBL nie jest prawidłowy, jako fallback wykorzystywany jest dołączony plik PDF.
3. PDF jest przetwarzany ścieżką IDR (OCR i rozpoznawanie wzorców).

Mechanizm ten zapewnia, że faktura zostanie zawsze przetworzona, nawet jeśli plik XML zawiera błędy. Jest to jednak droższa i wolniejsza ścieżka niż bezpośrednie przetwarzanie XML.

Jeśli UBL zostanie odrzucony (ponieważ jest nieprawidłowy), eConnect nadal przetworzy pozostałe załączniki z tej samej wiadomości e-mail, takie jak PDF. Nadawca otrzymuje wiadomość e-mail z:

• powiadomieniem, że faktura UBL nie zostanie przetworzona, wraz z komunikatem o błędzie;
• powiadomieniem, że ewentualne inne załączniki w wiadomości e-mail zostaną przetworzone.

Uwaga: ten komunikat o błędzie dotyczący faktury XML nie może zostać wyciszony, dopóki inne załączniki w tej samej wiadomości e-mail są przetwarzane.

Przykład -- BR-AE-10 (Odwrotne obciążenie): UBL z kategorią VAT AE (Odwrotne obciążenie) bez BT-121 (kod podstawy zwolnienia z VAT) lub BT-120 (tekst podstawy zwolnienia z VAT) uruchamia regułę walidacji BR-AE-10. Przy kategorii AE musi być obecne co najmniej jedno z tych pól. UBL zostaje odrzucony, dołączony PDF jest przetwarzany przez fallback IDR, a komunikat o błędzie dotyczący UBL pozostaje widoczny w wiadomości e-mail do nadawcy.

SI-UBL 1.2 (Simplerinvoicing 1.2) został definitywnie wycofany z dniem 1 stycznia 2024 r. Faktury w tym formacie są odrzucane w sieci Peppol. eConnect może czasami jeszcze przekształcić przestarzałe pliki SI otrzymane pocztą elektroniczną na prawidłowy NLCIUS, pod warunkiem że niezbędne dane są obecne. W przypadku brakujących danych walidacja może się nie powieść.

Uwaga: czy podczas wysyłania faktur pojawiają się komunikaty o błędach? Proszę sprawdzić, czy Państwa pakiet oprogramowania nadal generuje SI-UBL 1.2. Jeśli tak, proszę poprosić dostawcę o aktualizację do NLCIUS/SI-UBL 2.0 lub BIS Billing V3.

Przetwarzanie różni się nieznacznie między platformą legacy a PSB/Control:

• Platforma legacy: faktura jest zawsze najpierw transformowana do prawidłowego UBL (BIS Billing V3 lub NLCIUS) przed zapisaniem. Jeśli transformacja nie powiedzie się, faktura nie może zostać zapisana.
• PSB/Control: faktura jest walidowana i zapisywana w momencie odbioru. Transformacja następuje dopiero później, gdy jest to konieczne, na przykład przy dostarczeniu do systemu ERP. Oznacza to, że faktura może zostać zapisana w PSB, ale później może wystąpić błąd transformacji, jeśli format docelowy nie może zostać wygenerowany.

eConnect przetwarza pola UBL przy odbiorze tak jak przesłane w źródłowym UBL i nie modyfikuje ich treści. Nie istnieje konfigurowalne przez klienta mapowanie pól po stronie odbiorcy umożliwiające przepisywanie przesłanych wartości. Brakujące lub nieprawidłowe wartości muszą zostać poprawione przez nadawcę w źródłowym UBL. eConnect koryguje tylko znane błędy techniczne formatu i wypełnia nieistotne pola opcjonalne wartościami domyślnymi (patrz automatyczna naprawa XML powyżej).

Konkretny przykład z przychodzącą wewnątrzwspólnotową notą kredytową (pola dostawy):

Oba pola są przez eConnect przetwarzane przy odbiorze tak jak przesłane. BT-80 jest obowiązkowe tylko wtedy, gdy faktura zawiera grupę Deliver-to-address (BG-15). eConnect nie zapewnia mapowania po stronie odbiorcy do przepisywania BT-72 lub BT-80. Korekty brakujących lub nieprawidłowych wartości dokonuje nadawca w źródłowym UBL.

Przykład -- mieszanie adresu domowego i skrytki pocztowej (PostalAddress) na widoku faktury: adres na widoku faktury, który miesza dane adresu domowego i skrytki pocztowej, nie jest mieszaniem tworzonym przez eConnect przy odbiorze. eConnect przekazuje pola adresowe UBL (cac:PostalAddress) 1:1 i nie przepisuje ani nie normalizuje adresów. Jeśli źródłowy UBL miesza komponenty adresu domowego i skrytki pocztowej w jednym bloku PostalAddress, widok podąża za tym źródłem.

Typowy wzorzec mieszania w źródłowym UBL:

• cbc:StreetName = ulica i numer domu (adres domowy)
• cbc:AdditionalStreetName = kod pocztowy adresu domowego, w niewłaściwym polu
• cbc:BuildingName = Skrytka pocztowa N (kanonicznym polem skrytki pocztowej w UBL jest cbc:Postbox)
• cbc:PostalZone = kod pocztowy skrytki pocztowej

Widok faktury często pokazuje wówczas linię ulicy razem z PostalZone/CityName, co daje wizualnie "zmieszany adres" bez łączenia lub korygowania pól przez eConnect. Oba komponenty adresu mogą być same w sobie poprawne, ale połączenie ich we wspólnym bloku adresowym z zamienionymi kodami pocztowymi jest błędem mapowania w źródłowym UBL.

Działanie: otworzyć źródłowy UBL i sprawdzić elementy podrzędne PostalAddress odpowiedniej strony. Dostawca koryguje mapowanie: albo spójny adres domowy (StreetName z odpowiadającym PostalZone), albo skrytkę pocztową we właściwym polu skrytki pocztowej (Postbox) z odpowiadającym kodem pocztowym -- nie oba naraz z zamienionymi kodami pocztowymi. Po poprawieniu źródłowego UBL widok automatycznie się zgadza.

Niestandardowa korekta przez usługi doradcze (nie self-service): eConnect może, poprzez usługi doradcze, skonfigurować RBE (rule/business engine) dla automatycznych korekt w przeplywie. Jest to praca na zamówienie za pośrednictwem usług doradczych eConnect, a nie coś, co klient konfiguruje samodzielnie. Nie istnieje konfigurowalna przez klienta samodzielna (self-service) rewrite pól UBL po stronie odbiorcy.

Przykład -- faktura kredytowa „Payee/odbiorca = własna organizacja": przy kredycie versus obciążeniu AccountingSupplierParty i AccountingCustomerParty nie zamieniają się. Kierunek (do zapłaty lub do otrzymania) zawiera się w typie dokumentu i znaku PayableAmount, nie w odwróconych stronach. eConnect nie koryguje ról stron i nie stosuje automatycznie wcześniejszej korekty Payee, gdy źródłowy UBL jest już prawidłowy -- ta sama zasada passthrough co powyżej. Omówione z przykładem: Warianty noty kredytowej.

Warianty wyszukiwania: "faktura kredytowa Payee", "faktura kredytowa Payee własna organizacja", "Supplier Customer zamiana kredyt".

Chcą Państwo sprawdzić, czy plik XML jest poprawnie przetwarzany? Proszę skorzystać z bezpłatnego Walidatora eConnect, aby przetestować fakturę z wyprzedzeniem.