IDR (Intelligent Document Recogniser) automatycznie rozpoznaje najważniejsze dane na fakturze PDF i zamienia je na ustrukturyzowane pola w e-fakturze. Zakres rozpoznawanych pól zależy od subskrypcji i konfiguracji.

Przy każdej konwersji PDF następujące pola są rozpoznawane automatycznie:

Niektóre formaty dostawców mogą powodować, że IDR pobiera inne pole niż numer faktury, na przykład identyfikator transakcji zamiast właściwego numeru faktury. Dobrze znany przykład to faktury Meta (Facebook), gdzie numer faktury pojawia się na dole późniejszej strony PDF, a identyfikator transakcji jest rozpoznawany bardziej prominentnie. Ten sam wzorzec występuje, gdy IDR zamiast numeru faktury przejmie numer KRS/NIP dostawcy, numer zamówienia/PO lub referencję bankową/płatności (na przykład referencję bankową, numer IBAN lub fragment numeru IBAN/konta), co prowadzi do nieprawidłowego numeru faktury w systemie Coda lub ERP. Ten ostatni wariant może też spowodować błędne zablokowanie noty kredytowej jako duplikatu (zob. Duplikat faktury). Jest to błąd wyboru pola w rozpoznawaniu, odrębny od poprawnego rozpoznania referencji płatności jako osobnego pola PaymentID (zob. Polecenie zapłaty i konto G): tam referencja płatności nie nadpisuje numeru faktury, tutaj jest rozpoznawana błędnie na jego miejscu.

Można to poprawić dla danego formatu dostawcy. Rozpoznawanie numeru faktury nie jest konfigurowalne przez klienta, ale jest wewnętrznie optymalizowane przez członka zespołu wsparcia za pomocą wykrywania wartości odstąpających, wyrażeń regularnych i wskazówek dla konkretnego dostawcy lub formatu. Nie jest wymagana żadna zmiana w harmonogramie; jest to ukierunkowana optymalizacja istniejącej funkcjonalności. Zgłoś taki przypadek do działu wsparcia — na podstawie zgłoszenia zespół dodaje wskazówkę specyficzną dla dostawcy, dzięki czemu przyszłe faktury w tym formacie będą zawierać prawidłowy numer faktury.

Jak działa rozpoznawanie w tle (SampleStore)? IDR używa do tego SampleStore: bazy danych wzorców rozpoznawania na dostawcę. Proces przebiega w trzech krokach: (1) wyszukiwanie numerów pasujących do wzorca RegEx w SampleStore, (2) porównanie z poprzednimi przykładami tego samego dostawcy (długość, budowa, myślniki, kropki, podkreślenia, spójność), (3) samouctwa korekta na podstawie nowych faktur. Support uzupełnia SampleStore o przykłady i ewentualnie RegEx po zgłoszeniu.

Krótki lub inny numer zamiast dłuższego wzorca z prefiksem. Gdy faktury dostawcy mają zazwyczaj stały prefiks i stałą długość, IDR czasami rozpoznaje krótszy lub inny numer bez tego prefiksu. Jeśli wzorzec (prefiks, długość, budowa) jest już jasny ze zgłoszenia, pierwszym krokiem jest bezpośrednia korekta SampleStore lub RegEx dla tego dostawcy; przykład PDF lub XML służy wtedy jako dowód, nie jako obowiązkowy pierwszy krok. Jeśli rozpoznawanie działało wcześniej poprawnie i z upływem czasu ponownie stało się błędne, obowiązuje to samo podejście: sprawdzić i skorygować SampleStore dla tego dostawcy, co nie wskazuje na defekt produktu.

Do badania platforma XML ze skrzynki odbiorczej jest przydatnym plikiem: zawiera ślad rozpoznawania IDR. XML, który samodzielnie eksportuje się z systemu ERP (np. AFAS) po tym, jak numer faktury został już ręcznie poprawiony, zazwyczaj nie zawiera tego bloku IDR i pokazuje jedynie już poprawiony numer — ten plik nie nadaje się do analizy błędu rozpoznawania.

Ukryty lub przezroczysty tekst w PDF (ponowne użycie szablonu). Niektórzy dostawcy używają starego PDF faktury jako szablonu dla nowych faktur. Stare daty lub numery faktur mogą pozostawać jako niewidoczny lub przezroczysty tekst szczątkowy w warstwie tekstowej PDF. IDR używa hybrydowego OCR: oprócz widocznego obrazu odczytywana jest również warstwa tekstowa PDF. Na zrzucie ekranu lub na ekranie widać tylko widoczne linie, ale rozpoznawanie widzi pełną warstwę tekstową, w tym ukryty tekst szczątkowy. Może to być przyczyną, gdy stary i nowy numer faktury lub data mieszają się w rozpoznawaniu. W przypadku podejrzenia tego wzorca zawsze należy zażądać oryginalnego PDF: zrzut ekranu nie wystarczy, ponieważ nie zawiera warstwy tekstowej. Następnie należy skopiować tekst z pliku do edytora zwykłego tekstu, aby sprawdzić rozbieżność w stosunku do widocznego wyświetlania.

Wtórny objaw: faktura błędnie oznaczona jako duplikat. Kolejna faktura może zostać błędnie oznaczona jako duplikat, ponieważ IDR ponownie używa lub dopasowuje nieprawidłowy (ukryty) numer faktury. Jest to skutek podstawowego błędu rozpoznawania, a nie oddzielny problem: najpierw poprawć rozpoznawanie warstwy tekstowej zgodnie z opisem powyżej, zamiast oddzielnie zajmować się wykrywaniem duplikatów (zob. Duplikat faktury).

Warianty wyszukiwania: „inny numer KRS w XML", „numer KRS faktura vs XML", „numer KRS nadawcy różni się", „numer KRS dostawcy nieprawidłowy w XML", „numer KRS dostawcy XML inny niż faktura", „identyfikator podmiotu nadawcy XML PDF", „AccountingSupplierParty numer KRS".

Czasami numer KRS dostawcy (lub inny identyfikator podmiotu, taki jak numer NIP) w bloku nadawcy XML różni się od tego, co widnieje na oryginalnym PDF, albo rozpoznawanie dopasowuje fakturę do niewłaściwego dostawcy. Jest to błąd rozpoznawania pola dotyczący identyfikatora dostawcy, podobnie jak w przypadku kwot, waluty czy numeru faktury.

Uwaga — to nie to samo co „numer KRS odczytany jako numer faktury". W tamtym przypadku (patrz wyżej) numer KRS jest błędnie rozpoznawany w polu numeru faktury. Tutaj chodzi o identyfikator podmiotu w samym bloku nadawcy, który nie zgadza się z PDF. To dwie odrębne kwestie rozpoznawania.

Co możesz zrobić? Nie ma opcji samoobsługowej do edycji XML. Zbierz oryginalny PDF i powiązany XML (do pobrania z dokumentu w skrzynce odbiorczej) i/lub identyfikator dokumentu zadania konwersji, i zgłoś to do wsparcia. Na tej podstawie zespół dostosuje rozpoznawanie lub dopasowanie dostawcy. Podobnie jak w przypadku innych błędów rozpoznawania, nie obowiązuje tu żadne twarde zobowiązanie dotyczące czasu realizacji.

Warianty wyszukiwania: „waluta nie rozpoznana poprawnie", „waluta rozpoznana nieprawidłowo", „zła waluta IDR", „SEK zamiast NOK", „currency wrong PDF", „rozpoznawanie waluty faktura", „PDF waluta błąd", „waluta odczytana błędnie".

Waluta jest polem rozpoznawanym standardowo (patrz tabela powyżej) i podlega tym samym ogólnym błędom rozpoznawania PDF→XML co numer faktury lub kwota: IDR może błędnie rozpoznać kod waluty ISO w porównaniu z PDF (np. SEK zamiast NOK). Nie jest to osobna funkcjonalność ani odrębny problem, ale ta sama kwestia rozpoznawania co w przypadku innych pól.

Co możesz zrobić? Zgłoś rozbieżność do wsparcia i dostarcz oryginalny PDF oraz powiązany XML (ze skrzynki odbiorczej) lub identyfikator dokumentu zadania konwersji. Na tej podstawie zespół optymalizuje rozpoznawanie dla danego formatu dostawcy. Podobnie jak w przypadku innych błędów rozpoznawania, nie ma tu twardego zobowiązania dotyczącego czasu realizacji.

Przy subskrypcji Professional rozpoznawane są dodatkowe pola:

Warianty wyszukiwania: "amerykańska data", "amerykańska data faktury", "data dostawcy z USA", "data faktury USA", "data faktury MDY", "MDY zamiast DMY", "format daty Stany Zjednoczone", "data faktury nieprawidłowo rozpoznana dostawca amerykański", "American date format invoice date", "US supplier date format MDY".

IDR rozpoznaje daty na fakturach PDF i konwertuje je do standardowego formatu daty UBL (YYYY-MM-DD). Ponieważ zapisy dat różnią się według krajów, IDR na podstawie kraju dostawcy określa, jak interpretować niejednoznaczne daty:

• Stany Zjednoczone: MDY (miesiąc-dzień-rok). Data 03/11 jest interpretowana jako 11 marca.
• Wszystkie pozostałe kraje: DMY (dzień-miesiąc-rok). Data 03/11 jest interpretowana jako 3 listopada.

Widzisz u dostawcy ze Stanów Zjednoczonych datę faktury, która według Ciebie została rozpoznana błędnie? Sprawdź najpierw tę regułę krajową, zanim zgłosisz to jako błąd rozpoznawania pola: u amerykańskiego dostawcy 03/11 to na przykład 11 marca, a nie 3 listopada. Jeśli zapis daty nie jest wyjaśnieniem, chodzi o inną kwestię rozpoznawania (zob. wyżej).

Jeśli automatyczne wykrywanie kraju nie wystarcza, dla danego dostawcy można dodać konkretną wskazówkę dotyczącą formatu daty za pomocą mechanizmu hints.

Tip: błędnie zinterpretowane daty (na przykład 03/11 jako 11 marca zamiast 3 listopada) to prawie zawsze kwestia rozpoznawania, nie platformy. Platforma zawsze pokazuje datę tak, jak jest w UBL.

Przy subskrypcji Professional rozpoznany IBAN jest porównywany z verification store: bazą wcześniej ręcznie zwalidowanych numerów IBAN na dostawcę. Jeśli IBAN na fakturze różni się od wcześniej zweryfikowanego, jest to sygnalizowane. Pomaga to wykrywać fikcyjne faktury lub zmienione dane bankowe.

Uwaga: zgodnie z europejską normą EN16931 IBAN na fakturze służy przede wszystkim do identyfikacji dostawcy, a nie jako instrukcja płatności. Zmieniony IBAN musi być zawsze najpierw zwalidowany w danych podstawowych systemu finansowego przed dokonaniem płatności.

Oprócz standardowych referencji (numer zamówienia, numer kontraktu, numer projektu) inne referencje można konfigurować osobno dla dostawcy, na przykład kody budżetowe, kody osób odpowiedzialnych za budżet lub referencje wewnętrzne. To praca na zamówienie wdrażana w modelu kart pracy.

Rozpoznawanie konfigurowalnych referencji opiera się na trzech warstwach:

1. Regex: walidacja formatu, aby wyodrębniona referencja dokładnie odpowiadała oczekiwanemu formatowi
2. Outlier detection: statystyczne wykrywanie odchyleń dla mało prawdopodobnych wartości
3. Hints: automatycznie generowane dane treningowe na podstawie poprawek zespołu QC

Tip: numer zamówienia to najczęściej używana referencja i większość dostawców podaje go na fakturze. Jeśli dostawca nie może wypełnić danego pola referencji w swoim oprogramowaniu, mało sensu jest go wymagać. W takim przypadku użyj numeru zamówienia jako głównej referencji.

Uwaga: numer zamówienia, numer kontraktu i numer projektu to standardowe pola Professional, ale rozpoznawanie działa dopiero po jednorazowej konfiguracji przez wsparcie dla klienta/dostawcy (na podstawie co najmniej 5 przykładowych faktur, opcjonalnie uzupełnionej o regex). Skontaktuj się ze wsparciem i najlepiej dostarcz przykładową fakturę.

Otrzymujesz przez API informacyjną odpowiedź Order Reference detection skipped as Sample store is empty lub Contract Reference detection skipped as Sample store is empty? To nie jest błąd przetwarzania. IDR wypełnia te referencje tylko wtedy, gdy Customer Sample Store dla Twojego endpointu zawiera przykładowe referencje do porównania. Jesli store jest pusty, pomijane jest tylko to wykrywanie referencji; pozostałe pola i funkcje są rozpoznawane normalnie.

Rozwiązanie: dostarcz kilka przykładowych numerów zamówień lub referencji kontraktowych (co najmniej 3 znaki na przykład) dokładnie tak, jak występują na fakturach, aby wsparcie mogło skonfigurować je w Customer Sample Store. Następnie najpierw obowiązuje dopasowanie etykiety (np. „Your order number”), z regex jako rozwiązaniem zapasowym. Do konfiguracji rozpoznawania numeru PO dostępny jest też Remote Starter przez sprzedaż.

Nie, nie bezpośrednio na platformie. Nie zarządzasz sam Customer Sample Store, regułami formatowania ani RegEx do rozpoznawania numeru zamówienia; to konfiguruje wsparcie eConnect.

Jednak pośrednio, możesz:

• poprosić dostawców o fakturowanie z jasnym, jednolitym formatem referencji zamówienia (zob. dobra praktyka poniżej);
• podzielić się wiedzą o formacie (prefiks, stała długość, struktura) ze wsparciem;
• po nieudanym rozpoznaniu dostarczyć oryginał PDF lub identyfikator dokumentu wraz z poprawnym numerem zamówienia, aby wsparcie mogło zaktualizować Sample Store.

Dobra praktyka formatu referencji zamówienia na PDF:

• podawaj referencję zamówienia najlepiej jeden raz na fakturze, bez powtarzania w wielu miejscach;
• używaj popularnej etykiety, np. Numer zamówienia, Numer PO, Numer zamówienia zakupu lub Your order number;
• oddziel etykietę i numer spacją lub znakiem interpunkcyjnym, np. Numer zamówienia: 420000007 zamiast PO420000007;
• zachowuj stałą strukturę i najlepiej stałe miejsce na fakturze.

Zobacz też Błędy przesyłania w przypadku blokowanej lub odrzuconej faktury z powodu niepoprawnie rozpoznanego numeru zamówienia.

Warianty wyszukiwania: "wiele numerów PO", "wiele numerów zamówienia jedna faktura", "wiele referencji zamówienia PDF", "OrderReference nagłówek", "PO na wierszu faktury", "rozpoznawanie wierszy PO", "rozpoznawanie wielu numerów PO".

• Poziom nagłówka: maksymalnie jeden numer zamówienia (OrderReference) na nagłówku faktury. Wiele numerów PO na jednym PDF nie wypełnia automatycznie wielu referencji zamówienia nagłówka.
• Poziom wiersza jako tekst: dodatkowe numery PO na PDF mogą trafić do opisu wiersza (fragment tekstu) poprzez rozpoznawanie wierszy — nie jest to sama strukturalna referencja wiersza zamówienia.
• Rzeczywista referencja zamówienia na poziomie wiersza: tylko jeśli odbiorca ma konfigurację na poziomie wiersza; nie jest to standardowe "wiele PO → wiele referencji zamówienia".

Nie oczekuj automatycznego powiązania wielu numerów PO z wieloma referencjami zamówienia nagłówka. W przypadku układu multi-PO najpierw sprawdź konfigurację Professional i Sample Store dla jednego PO nagłówka; dodatkowe numery PO trafiają jako tekst wiersza, a nie jako odrębna referencja wiersza zamówienia, o ile odbiorca sam tego nie skonfigurował. Zobacz też Rozpoznawanie wierszy dla pól referencyjnych na wiersz.

Zgodnie z europejską normą EN16931 referencja (buyer reference) jest obowiązkowa na fakturze elektronicznej; często jest to numer zamówienia lub inna referencja odbiorcy. Nadawca może umieścić niepoprawną wartość w tym polu.

eConnect domyślnie nie odrzuca faktury na podstawie referencji. Faktura nie spełnia podstawowych reguł europejskiej normy tylko wtedy, gdy nie ma żadnej referencji. To, czy faktura zostanie odrzucona z powodu nieznanej lub nieprawidłowej referencji, zależy od konfiguracji odbiorcy: w konkretnej konfiguracji odbiorcy faktura może zostać odrzucona, jeśli referencja jest nieznana. Jest to zatem właściwość konfiguracji po stronie odbiorcy, a nie standardowego przetwarzania eConnect.

Wskazówka: jeśli chcesz odrzucać faktury z brakującymi lub nieznanymi referencjami, skonfiguruj to przez RBE (Rule Based Enrichment) na endpoincie odbierającym.

Numer faktury (pole UBL cbc:ID, BT-1) jest obowiązkowy w EN 16931, UBL BIS Billing 3.0 i NLCIUS dla zwykłych faktur. IDR przetwarza jednak mieszany strumień dokumentów: zwykłe faktury, noty kredytowe, rozliczenia wydatków i paragony. Paragony objęte są uproszczonym reżimem fakturowania (transakcje do ok. 100 zł brutto), dla którego urząd skarbowy nie wymaga numeru faktury jako wymogu prawnego. Odrzucanie z powodu brakującego numeru faktury wykluczałoby wszystkie paragony i rozliczenia wydatków z przetwarzania.

Dlatego potok IDR automatycznie generuje numer zastępczy, gdy nie można wyodrębnić żadnego numeru faktury z dokumentu podczas rozpoznawania. Pole cbc:ID (BT-1) jest wtedy wypełniane strukturą:

YYYYMMDDHHmmss-NOTFOUND

Czas jest momentem przetwarzania przez potok IDR, a nie datą na dokumencie. Przykład: 20240315143022-NOTFOUND.

Filtrowanie jest możliwe na dwóch poziomach:

1. RBE (Rule Based Enrichment): skonfiguruj regułę sprawdzającą, czy BT-1 (cbc:ID) kończy się na -NOTFOUND. Na tej podstawie dokument może zostać zatrzymany do ręcznej weryfikacji, przekierowany do oddzielnej skrzynki odbiorczej lub automatycznie odrzucony.
2. Własne systemy (ERP/oprogramowanie księgowe): bezpośrednie wyszukiwanie ciągu znaków lub wyrażenie regularne na -NOTFOUND w polu cbc:ID jest wystarczające.

Dzięki rozpoznawaniu wierszy rozpoznawane są także poszczególne wiersze faktury: opis, cena jednostkowa, ilość, kwota wiersza i pola referencji na wiersz. To osobna funkcja, którą możesz włączyć samodzielnie w Mojym środowisku.

Chcesz wiedzieć, jak rozpoznawanie działa technicznie? Przeczytaj Jak działa Scan & Rozpoznawanie (IDR/OCR)?.