Email Receiver (inaczej Zaufany nadawca) to aplikacja na platformie eConnect, dzięki której odbierasz i przetwarzasz faktury e-mailem, w ramach Scan & Herken. Ustawiasz zaufany adres e-mail lub domenę, a faktury wysłane z tego adresu są przetwarzane automatycznie.

Uwaga: Email Receiver to aplikacja (w Aplikacjach w menu platformy), a nie połączenie. Jeśli chcesz, aby odebrane faktury były automatycznie przekazywane na adres e-mail, użyj konektora Email. Należy on do Połączeń. Zobacz Klucze połączenia: konektor Email, przekazywanie odebranych faktur.

Wiele pakietów oprogramowania używa Email Receiver jako głównej metody połączenia z eConnect. Platforma generuje unikalny adres e-mail na organizację. Oprogramowanie wysyła faktury jako załącznik na ten adres, a platforma przetwarza je dalej zależnie od ustawionego typu dokumentu.

Przy tworzeniu Email Receiver platforma generuje unikalny adres e-mail. Przekazujesz ten adres dostawcy oprogramowania albo wpisujesz go w pakiecie. Gdy oprogramowanie wyśle fakturę jako załącznik na ten adres, platforma przetwarza fakturę automatycznie. Faktury XML są przetwarzane bezpośrednio. Faktury PDF są konwertowane do formatu e-faktury (UBL) przez konwersję IDR.

To, jakie przetwarzanie nastąpi, zależy od typu dokumentu: faktura robocza, faktura sprzedaży albo faktura zakupu.

Przychodzący mail dostawcy trafia najpierw do Email Receiver. Tam odbywa się klasyfikacja, kontrola zaufanego nadawcy i przypisanie typu dokumentu. Potem przepływ się rozdziela: faktura do przetwarzania, dołączenie specyfikacji albo pominięcie logo i warunków. Każdy dostawca dostaje unikalny adres na trust.econnect.eu.

Przy tworzeniu Email Receiver wybierasz typ dokumentu. Określa on, jak przetwarzana jest odebrana faktura.

Faktura jest przygotowywana jako wersja robocza na platformie. Możesz ją sprawdzić, a potem ręcznie wysłać do odbiorcy przez Peppol. Jeśli włączysz automatyczne wysyłanie XML (auto-send), poprawne faktury XML są wysyłane bez ręcznej ingerencji.

Faktura trafia od razu do archiwum do przetwarzania administracyjnego. To rozwiązanie, gdy faktura jest już ostateczna i nie wymaga dalszej kontroli przed archiwizacją.

Faktura jest dostarczana odbiorcy jako faktura zakupu. Jeśli faktura jest już w UBL, konwersja jest pomijana. Przy fakturze PDF następuje konwersja IDR do formatu e-faktury.

Nawigacja dla nowych klientów: po rejestracji trafiasz do widoku środowiska / zarządzania kontem. Email Receiver nie jest tam widoczny od razu. W menu kliknij Aplikacje → Odbiorca e-mail (Email Receiver), aby otworzyć przegląd. W Wszystko zobaczysz automatycznie utworzony adres odbiorczy organizacji.

1. Zaloguj się na platform.econnect.eu.
2. Przejdź do aplikacji Email Receiver (w Aplikacjach w lewym menu).
3. Kliknij Nowy nadawca (pomarańczowy przycisk z plusem).
4. Ustaw pola:
   • Organizacja: wybierz organizację, dla której chcesz przetwarzać faktury.
   • Typ faktury: wybierz Fakturę roboczą, Fakturę sprzedaży albo Fakturę zakupu.
   • Typ białej listy: wpisz adres e-mail lub domenę nadawcy, który może wysyłać. Na jeden Email Receiver można dodać jedną domenę albo jeden adres e-mail.
   • Adres e-mail kontaktu: adres, na który trafiają powiadomienia o odrzuceniu.
5. Kliknij Zapisz. Platforma generuje unikalny adres e-mail dla tego połączenia.
6. Aktywuj zaufanego nadawcę. Dwa sposoby: ręcznie zmień status na "Aktywny" albo wyślij zaproszenie do nadawcy. Przy zaproszeniu nadawca dostaje e-mail z wyjaśnieniem wygenerowanego adresu. Przy pierwszym użyciu Email Receiver aktywuje się automatycznie.
7. Przekaż wygenerowany adres dostawcy oprogramowania albo wpisz go w pakiecie.

Organizacja ma odbierać faktury z kilku domen? Utwórz osobny adres Email Receiver dla każdej domeny.

• Powiadomienie przy odbiorze: dostajesz e-mail, gdy faktura została wysłana i przetworzona.
• Wymóg SSL/TLS: przetwarzaj tylko e-maile wysłane bezpiecznym połączeniem.
• Automatyczne wysyłanie XML (auto-send): poprawne faktury XML są wysyłane bez ręcznej kontroli. Wymaga włączonego SSL/TLS i poprawnego XML.
• Dozwolone typy dokumentów: ustal, czy przyjmujesz tylko e-faktury (XML), tylko faktury cyfrowe (PDF), czy oba.
• Rozpoznawanie dostawcy: ustaw, na podstawie którego pola e-mail rozpoznawany jest dostawca. Domyślnie jest to adres nadawcy. Przy aliasach lub przekazywaniu możesz wybrać inne pole (na przykład Reply-To). Rozpoznany adres jest też przekazywany w XML dostarczanym do systemu księgowego.
• Konwersja dla wielu organizacji (Conversion for multiple organizations): wykrywanie administracji / konwersja multiparty. IDR automatycznie ustala, dla której administracji w tym samym koncie przeznaczona jest faktura PDF, także gdy wpłynęła przez email receiver innej organizacji. Wymaga co najmniej Professional (osobno w umowie), opcji feature pack Allow multi party for IDR conversion (zakładka IDR Features) i opcji na email receiver. Po włączeniu powstaje grupa IDR (grupa administracji) z organizacjami konta. Domyślna jest organizacja email receiver. Przy lepszym dopasowaniu system umieszcza fakturę na innej administracji. W razie wątpliwości zostaje wartość domyślna. Faza platformy routuje po Invoice/AccountingCustomerParty/Party/PartyLegalEntity/CompanyID i jest wiodąca przy wzbogacaniu XML (m.in. numer VAT i nazwa organizacji). Sztuczny Leitweg-ID w CompanyID (Niemcy) może spowodować brak dopasowania i wtedy zostaje organizacja domyślna. Szczegóły: Odbiorca e-mail.

Uwaga: ostateczna faktura z oprogramowania nie może być zmieniana w zakresie dłużnika i pozycji po przyjęciu jako faktura robocza na platformie eConnect. Sprawdź fakturę tylko pod kątem poprawności, a potem ją wyślij.

Uszkodzony lub nieaktywny Email Receiver nie musi być naprawiany przez utworzenie nowego. Często Zaufany nadawca nie jest jeszcze aktywny albo jest źle skonfigurowany. Przy "e-mail nieodebrany" sprawdź najpierw:

1. Adres skopiowany poprawnie. Sprawdź literówki w wygenerowanym adresie …@trust.econnect.eu, który przekazałeś do pakietu.
2. Status Email Receiver Aktywny. Jeśli Zaufany nadawca ma jeszcze status "Utworzono wersję roboczą", Email Receiver nie jest aktywny i nie można go użyć. Nadawca dostaje wtedy bounce (chyba że ustawiono inny aktywny Email Receiver z innym adresem kontaktu).
3. Poprawna biała lista. Sprawdź, czy adres lub domena nadawcy jest poprawnie ustawiona na białej liście Email Receiver.
4. Poprawny typ dokumentu. Przy złym typie dokumentu faktury są przetwarzane nieprawidłowo. Przykład: Zaufany nadawca utworzony z typem Faktura zakupu przetwarza faktury jako fakturę zakupu zamiast faktury roboczej. Nowy Email Receiver z typem Faktura robocza mógł być tymczasowym obejściem, ale lepiej popraw typ dokumentu na istniejącym Email Receiver.

Faktura jest widoczna na platformie po odbiorze przez Email Receiver, ale (jeszcze) nie w UBW/Agresso, Unit4 ani innym podłączonym pakiecie? Najpierw odróżnij tymczasowe opóźnienie partii lub przekazania od trwałego braku przekazania: zobacz Rozwiązywanie problemów ERP.

Gdy faktury są wysyłane e-mailem do odbiorców, którzy nie są w Peppol, konto klienta określa, które dokumenty są dołączane w zapasowej wysyłce e-mail. Chcesz, aby dokumenty były dołączane? Skontaktuj się w sprawie możliwości i ewentualnych kosztów.

Zalecane alternatywy dla odbiorców poza Peppol:

• Rejestracja Peppol odbiorcy: najsolidniejsza droga. Faktury idą wtedy przez Peppol, a nie e-mailem.
• Konto na platformie: odbiorca zakłada konto i używa konektora Email (Połączenia), aby automatycznie przekazywać odebrane faktury. Zobacz Klucze połączenia: konektor Email.

Przy odrzuceniu Email Receiver wysyła komunikat błędu na adres e-mail kontaktu tego receivera. To pole nie jest adresem e-mail awaryjnym. Dokąd idą powiadomienia receivera i jak samemu zmienić adres awaryjny: zobacz Adres e-mail awaryjny (fallback).

Nieprawidłowy lub nierozpoznany XML jest odrzucany i nie trafia jako przetworzona faktura na platformę. Blokada białej listy to osobna ścieżka (nadawca niedozwolony). Obecność nadawcy na białej liście nie wyklucza odrzucenia XML.

• Brak przetwarzalnych załączników: w e-mailu nie rozpoznano plików faktury.
• Blokada białej listy: nadawca nie jest na białej liście. Żaden plik nie jest przetwarzany.
• Błąd SSL/TLS: e-mail nie został wysłany bezpiecznym połączeniem i nie jest przetwarzany.
• Nieprawidłowy lub nierozpoznany XML: komunikat z instrukcją o ważności UBL i kodowaniu UTF-8. Jeśli e-mail zawiera też PDF obok XML, PDF jest przetwarzany. Komunikatu o odrzuconym XML nie da się wtedy ukryć, dopóki PDF jest przetwarzany.
• Błąd walidacji UBL załącznika XML (na przykład BR-CO-18 / BR-Z-01 / BR-Z-05 Zero rated / stawka zero): odrzucenie dotyczy tylko załączonego XML. Jeśli w tym samym e-mailu jest też PDF, ten PDF jest przetwarzany normalnie, a odrzucony XML generuje komunikat ("Przetwarzanie nie jest możliwe" / "Nie udało się przetworzyć faktury UBL w załączniku").

Wskazówka przy stałym dostarczaniu XML i PDF: jeśli dostawca zawsze wysyła XML i PDF, a potrzebny jest tylko PDF, są dwie drogi: (1) dostawca poprawia XML albo pomija załącznik XML (usuń XML); (2) support może ustawić Email Receiver tylko na faktury cyfrowe (PDF). Przy drodze 2 XML nie jest już poddawany walidacji i znika powiązany komunikat. To zmiana konfiguracji przez support, na wniosek klienta.

Email Receiver klasyfikuje załączniki przychodzącego e-maila i ustala, który dokument jest fakturą, a który załącznikiem. eConnect sprawdza każdy przesłany dokument osobno pod kątem statusu załącznik/faktura. Dokumenty są scalane w kolejności przesłania: pierwszy dokument staje się pierwszą stroną faktury, nawet jeśli jest załącznikiem. Gdy plik zostanie rozpoznany jako załącznik, wszystkie kolejne pliki w tym samym mailu też są traktowane jako załącznik.

Przy kilku plikach PDF:

• Jeden plik rozpoznany jako faktura, pozostałe to inne typy dokumentów. Pozostałe dokumenty w tym samym mailu są traktowane jako załącznik i domyślnie dodawane do faktury. Pomyśl o nocie szkody, liście przewozowym albo specyfikacji obok prawdziwego PDF faktury: możesz nazwać oba dokumenty "fakturą", ale jeśli Detect nie rozpozna jednego jako faktury, to nie błąd podziału, tylko oczekiwane zachowanie. Dokument niebędący fakturą staje się załącznikiem rozpoznanej faktury. Wątpliwość, czy drugi dokument jest jednak fakturą (numer faktury, VAT, kwota do zapłaty, dostawca/odbiorca)? Poproś o oryginalne załączniki PDF i XML ze skrzynki odbiorczej do sprawdzenia.
• Kilka załączników rozpoznanych jako faktura. Każdy PDF faktury jest przetwarzany osobno (osobne faktury). System nie łączy automatycznie pozostałych załączników z konkretną fakturą w tym samym mailu. W razie wątpliwości wyślij 1 fakturę na e-mail.

Logika scalania z XML i bez XML w e-mailu: jeśli e-mail nie zawiera XML, obowiązuje logika powyżej na podstawie klasyfikacji Detect (jedna deklaracja lub faktura, załączniki są dodawane; dwie lub więcej deklaracji lub faktur, wszystko jest przetwarzane osobno). Jeśli e-mail zawiera poprawną fakturę XML, obowiązuje inna reguła: PDF o dokładnie tej samej nazwie pliku co XML jest dodawany do tego XML. Pozostałe załączniki są klasyfikowane przez Detect i ewentualnie przetwarzane osobno. Przy dwóch lub więcej poprawnych XML w tym samym e-mailu załącznik o dokładnie tej samej nazwie jest dodawany do właściwego XML. Pozostałe pliki są przetwarzane osobno.

Jeśli Detect błędnie rozpozna luźny PDF zestawienia lub specyfikacji jako fakturę, obok prawdziwej faktury powstaje dodatkowa faktura. Zobacz Wiele załączników PDF w jednej wiadomości e-mail, aby temu zapobiec.

Załącznik Excel/ODS/CSV obok faktury PDF: załącznik Excel nie blokuje przetwarzania faktury PDF, o ile plik jest w obsługiwanym formacie i nie jest większy niż 5 MB. Zachowanie według scenariusza:

• Obsługiwany format i nie większy niż 5 MB (.xlsx, .ods, .csv): plik jest dodawany do faktury jako załącznik dodatkowy (nie wysyłany do IDR). Faktura PDF jest przetwarzana normalnie.
• Obsługiwany format i większy niż 5 MB: cały e-mail jest odrzucany z mailem bounce.
• Nieobsługiwany format (.xls, .doc, .docx): przetwarzanie nie jest możliwe.

Obsługiwane typy MIME: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xlsx), application/vnd.oasis.opendocument.spreadsheet (.ods), text/csv (.csv). Nieobsługiwane: application/msword (.doc), application/vnd.openxmlformats-officedocument.wordprocessingml.document (.docx), application/vnd.ms-excel (.xls).

Obrót stron: strony nie są obracane automatycznie. Klient odpowiada za właściwą orientację przy dostarczeniu.

Duże załączniki: bardzo duży załącznik jest zmniejszany, aby PDF pozostał użyteczny.

Scalanie załączników: platforma może scalić wszystkie załączniki e-faktury w jeden PDF.

Generowanie PDF z XML: jest opcja automatycznego generowania PDF z faktury XML. Łączy się ze scalaniem i ustawia na: zawsze, nigdy albo tylko gdy PDF jeszcze nie istnieje.

Dostarczony PDF bez zmian: eConnect wykonuje tylko tłumaczenie/przetwarzanie i nie zmienia dostarczonego pliku PDF (PDF może zostać wygenerowany).

Nadawca dostaje bounce lub powiadomienie, że dokument jest "załącznikiem lub specyfikacją", a powiązana faktura z tego samego e-maila została przetworzona? Ten sam komunikat pojawia się też jako "Typ dokumentu jest nieprawidłowy" lub "Przesłany plik (Faktura zakupu) nie może być obsłużony, ponieważ typ dokumentu jest nieprawidłowy". Angielski temat tej samej wiadomości to "This is an attachment/specification". Bounce może też dotyczyć obrazu inline (image012.png) albo zestawienia faktur w przekazanej wiadomości. To nie sprzeczność. To dwa osobne wyniki w jednym e-mailu.

1. Komunikat jest niezależny od statusu faktury. Nie mówi nic o tym, czy sama faktura się nie powiodła. Sprawdź status faktury osobno w skrzynce odbiorczej.
2. Fałszywie dodatni start zadania konwersji. PDF lub obraz z wystarczającym sygnałem faktury (na przykład słowo "Faktura" z numerem) uruchamia własne zadanie konwersji. Jeśli ten dokument nie jest fakturą, bounce na tym dokumencie jest zasadny, niezależnie od prawdziwej faktury w tym samym mailu.
3. Brak późnego powiązania. Gdy zadanie konwersji załącznika już wystartowało, załącznik nie jest później łączony z fakturą.
4. Osobnych zadań konwersji nie da się scalić. Kilka plików, które wystartowały jako faktura, pozostaje osobnymi zadaniami. Nie da się ich później scalić.

Mapa produktu: strukturalna poprawa klasyfikacji "przy drzwiach" jest planowana w przyszłej wersji PSB Email Receiver (horyzont około 12 miesięcy od września 2026). Do tego czasu obowiązuje opisane zachowanie.

Klienci z Microsoft 365 / Exchange mogą przekazywać maile z fakturami z własnych adresów (na przykład faktury@klient.pl) do Email Receiver bez nadawania użytkownikom końcowym dodatkowych praw do skrzynki. To przekazywanie po stronie klienta na adres odbiorczy eConnect. To nie jest połączenie Office 365, w którym PSB odczytuje skrzynkę przez Graph/OAuth.

Wzorzec: kontakt pocztowy + grupa dystrybucyjna (zachowuje pierwotnego nadawcę):

1. Utwórz adres Email Receiver na platformie i ustaw status na Aktywny.
2. W centrum administracyjnym Exchange utwórz kontakt pocztowy, którego adres zewnętrzny to adres Email Receiver platformy.
3. Utwórz grupę dystrybucyjną z adresem faktur widocznym dla klientów. Członek = kontakt pocztowy. Opcjonalnie: dodatkowy alias na tej samej grupie.
4. Przetestuj odbiór na platformie.

Przy jednym ogólnym adresie faktur receiver często ma białą listę Akceptuj wszystko (nie przy Fakturze roboczej). Jeśli Exchange blokuje przekazywanie zewnętrzne, wybierz połączenie skrzynki Office 365. Unikaj pętli: nie przekazuj maili z domen everbinding.nl ani econnect.eu.

Zobacz też Odbiorca e-mail dla ścieżki w interfejsie platformy.

Chcesz wiedzieć, jakie metody integracji są dostępne dla Twojego oprogramowania? Zobacz przegląd metod integracji.