wysyłka z poziomu systemu ERP

Wysyłka z poziomu systemu ERP integruje komunikację z klientem bezpośrednio z procesami sprzedażowymi firmy.

Wysyłka jako element procesu sprzedażowego ERP

Wysyłka z poziomu systemu ERP oznacza utworzenie i przekazanie wiadomości bezpośrednio z aplikacji, w której prowadzone są dokumenty handlowe, zamówienia, kartoteki kontrahentów i statusy realizacji. Użytkownik nie musi osobno przepisywać adresu odbiorcy do programu pocztowego. System może pobrać dane z konkretnego dokumentu, na przykład faktury, potwierdzenia zamówienia, awiza wysyłki albo informacji o zmianie statusu, a następnie przygotować wiadomość na podstawie zdefiniowanego szablonu.

Typowy przebieg obejmuje wybór dokumentu, wygenerowanie treści, dołączenie pliku oraz przekazanie zadania do mechanizmu wysyłkowego. ERP powinien zapisać, z jakiego dokumentu powstała wiadomość, do kogo została skierowana, kiedy ją utworzono i jaki rezultat zwrócił moduł transportowy. Dzięki temu wysyłka jest częścią historii sprzedaży, a nie działaniem wykonywanym poza systemem. Samo oznaczenie dokumentu jako „wysłany” nie powinno jednak oznaczać sukcesu dostarczenia, ponieważ przyjęcie wiadomości przez serwer nadawcy nie jest równoznaczne z jej odebraniem przez adresata.

Transport wiadomości: SMTP, API i pliki załączników

ERP może przekazywać wiadomości przez SMTP albo przez interfejs API dostawcy poczty lub zewnętrznej usługi transakcyjnej. W wariancie SMTP aplikacja łączy się z określonym hostem, uwierzytelnia konto i przekazuje komunikat zgodny z formatem poczty internetowej. Połączenie powinno korzystać z szyfrowania TLS, a dane dostępowe nie powinny być wpisane na stałe w kodzie aplikacji. W wariancie API ERP wysyła żądanie HTTP do usługi, zwykle z nagłówkiem autoryzacyjnym, treścią wiadomości, listą odbiorców oraz załącznikami zakodowanymi zgodnie z wymaganiami danego interfejsu.

Załącznik, na przykład dokument PDF wygenerowany z ERP, musi mieć poprawną nazwę, typ MIME i zawartość odpowiadającą dokumentowi wybranemu przez użytkownika. System powinien sprawdzić, czy plik istnieje, czy można go odczytać oraz czy jego rozmiar mieści się w limicie narzuconym przez serwer pocztowy lub API. Ważne jest także rozróżnienie adresatów „Do”, „DW” i „UDW”, ponieważ błędne mapowanie pól może spowodować wysłanie dokumentu do niewłaściwej osoby. W praktyce należy kontrolować również kodowanie znaków, aby polskie litery w temacie i treści nie zostały zastąpione nieczytelnymi symbolami.

Kolejka, statusy i obsługa nieudanej wysyłki

Wysyłka z ERP często działa asynchronicznie. Po zatwierdzeniu operacji aplikacja zapisuje zadanie w kolejce, a osobny proces pobiera je i wykonuje transmisję. Takie rozwiązanie pozwala zakończyć pracę z dokumentem bez oczekiwania na odpowiedź serwera pocztowego, ale wymaga spójnych statusów. Przydatne są osobne stany, takie jak „utworzono”, „oczekuje”, „w trakcie”, „przekazano do transportu”, „odrzucono” i „zakończono błędem”. Status nie powinien być zmieniany na sukces przed otrzymaniem odpowiedzi potwierdzającej przyjęcie komunikatu przez używany mechanizm wysyłkowy.

Błąd chwilowy, na przykład przerwa w połączeniu, przekroczenie limitu czasu lub niedostępność usługi, można obsłużyć przez ponowienie próby. Ponowienie musi mieć ograniczony zakres i rozróżniać błędy tymczasowe od trwałych, takich jak niepoprawny adres odbiorcy, odrzucone uwierzytelnienie albo przekroczony limit rozmiaru wiadomości. Każde zadanie powinno mieć identyfikator pozwalający wykryć duplikat. Bez takiego mechanizmu ponowiona operacja może wysłać ten sam dokument kilka razy. Log powinien zawierać identyfikator dokumentu, rezultat transportu, kod błędu i czas operacji, lecz nie powinien ujawniać hasła do konta ani pełnej zawartości poufnego załącznika.

Kontrola konfiguracji przed uruchomieniem wysyłki

Przed użyciem funkcji trzeba sprawdzić konfigurację nadawcy, serwera lub adresu API, port komunikacyjny, sposób uwierzytelniania, wymaganie TLS oraz reguły generowania adresów odbiorców. Warto wykonać test na kontrolnej skrzynce i potwierdzić nie tylko pojawienie się wiadomości, lecz także poprawność tematu, treści, załącznika i danych nadawcy. Jeżeli ERP korzysta z szablonów, należy zweryfikować, czy wszystkie zmienne są rozwijane dla każdego typu dokumentu. Pusty numer faktury, nieaktualna nazwa kontrahenta albo brak pliku wskazany w szablonie powinny powodować ostrzeżenie przed wysłaniem.

W środowisku roboczym należy obserwować historię kolejki i porównywać liczbę dokumentów oczekujących z liczbą zadań zakończonych. Nagły wzrost kolejki może wskazywać na zatrzymanie procesu wysyłkowego, problem z połączeniem albo wygaśnięcie danych uwierzytelniających. Powtarzające się odrzucenia wymagają sprawdzenia komunikatu zwrotnego i konfiguracji, a nie wielokrotnego klikania przycisku wysyłki.