EDI bez pośrednika. Zlecenia i potwierdzenia przez SFTP

Duży klient operatora, międzynarodowy browar, wymaga komunikatów, a nie plików z Excela. W opisywanym wdrożeniu WMS przyjmuje zlecenia przyjęcia i wydania w formacie EDI przez SFTP, a potwierdzenia z numerami SSCC odsyła w plikach JSON i EDI. Dane przechodzą przez tabele pośrednie, więc każdy etap da się sprawdzić osobno.

Tytuł mówi o braku pośrednika. W opisywanym wdrożeniu WMS pobiera komunikaty z serwera SFTP klienta i sam zapisuje potwierdzenia w katalogu wyjściowym, bez platformy EDI w środku.

Mechanizm z tego artykułu należy do warstwy dedykowanej wdrożenia na platformie Studio WMS.net, czyli do skryptów i procedur napisanych dla tego klienta. Opisujemy cztery procedury importu, cztery widoki eksportu i sposób testowania bez ingerencji w pliki na serwerze.

Dlaczego EDI, a nie plik z Excela

Plik z Excela dobrze obsługuje wymianę z jednym nadawcą, który sam układa kolumny. Przy dużym kliencie sensowniejszy jest komunikat, w którym nagłówek i pozycje mają ustalony układ, a odbiorca nie zgaduje znaczenia kolumn. Plik z Excela zwykle nie ma narzuconego schematu, a komunikat EDI ma ustalone segmenty, więc procedura importu może odrzucić wadliwy dokument i zapisać powód w raporcie błędów. Excel jako źródło zamówień opisuje strona o imporcie z Excela, a wymianę plików CSV artykuł o integracji WMS z ERP przez SFTP.

Z notatek ze spotkania projektowego z 2020 roku wynika uzgodniony zakres. Od klienta do WMS idą dwa komunikaty, zlecenie przyjęcia (ZPZ) i zlecenie wydania z magazynu (ZWZ). Do klienta wracają potwierdzenia wykonania przyjęcia i wydania, a uzgodniono też komunikat o przygotowaniu palet mix. Jest to zakres ustalony na spotkaniu, a nie lista funkcji obecnych w każdym wdrożeniu. Import i eksport EDI przez SFTP pojawił się w opisywanym wdrożeniu w 2024 roku, a eksport w formatach JSON i EDI doszedł w 2025 roku.

Strony komunikacji

Wymiana odbywa się przez serwer SFTP klienta, a WMS loguje się do niego kluczem SSH. Po jednej stronie stoi system klienta, który nadaje zlecenia i odbiera potwierdzenia, a po drugiej WMS, który je importuje i eksportuje. Komunikaty od klienta WMS pobiera z serwera, a własne potwierdzenia zapisuje w katalogu wyjściowym. Schemat obejmuje oba rodzaje wymiany: plik CSV oraz komunikat EDI.

Opisana wymiana obejmuje cztery rodzaje komunikatów: zlecenie przyjęcia i zlecenie wydania w jedną stronę oraz potwierdzenie przyjęcia i potwierdzenie wydania w drugą. Każdy kierunek ma własny mechanizm po stronie WMS, a zestawienie przypisuje komunikaty do mechanizmów w WMS i ich efektu.

Jeden klient operatora wymienia dane plikami CSV, a inny komunikatami EDI, więc kanały różnią się między klientami. W magazynie operatora każdy z kilku klientów może wymieniać dane innym kanałem, o czym piszemy na stronie WMS dla operatora 3PL.

Import nagłówka i pozycji

Import dzieli się na cztery procedury. Dwie obsługują zlecenie przyjęcia: jedna jego nagłówek, druga pozycje. Dwie pozostałe robią to samo dla zlecenia wydania. Dla zespołu wdrożeniowego oznacza to cztery obiekty do uruchomienia i sprawdzenia osobno.

Podział odpowiada budowie komunikatu EDI, w którym nagłówek niesie dane całego dokumentu, a każda pozycja dane jednej linii. Jeden nagłówek otwiera więc wiele pozycji. Przyjęcia i wydania mają osobne procedury, tak jak mają inne pola w pliku CSV.

Dane trafiają do trzech tabel pośrednich, opisanych w zestawieniu. Import zapisuje je tam, zanim powstaną zlecenia, więc dane wejściowe zostają w bazie i można je odczytać osobno.

Raport błędów importu

Trzecia tabela pośrednia jest raportem błędów importu. Błędy komunikatów mają więc własne miejsce, osobne od tabel nagłówków i pozycji, a dane zleceń i informacje o odrzuceniach można czytać oddzielnie. Raport pozwala odpowiedzieć na pytanie klienta, dlaczego komunikatu nie ma w WMS, bez zaglądania do tabel nagłówków i pozycji.

W wymianie plików CSV błąd zapisuje kolumna w tabeli pośredniej, a przy EDI raport ma własną tabelę. Przyczynę odrzucenia komunikatu serwis szuka więc w jednej, wydzielonej tabeli.

Eksport potwierdzeń w JSON i EDI

Eksport zaczyna się od realizacji zlecenia na wózku. Operator potwierdza palety, WMS zapisuje wynik, a widoki składają go w potwierdzenie z numerami SSCC. Nagłówek potwierdzenia opisuje dokument jako całość, a pozycja jedną linię, w której stoi paleta. Dokumenty PZ i WZ, do których wracają potwierdzenia, opisuje strona o dokumentach magazynowych.

Eksport opiera się na czterech widokach: nagłówek i pozycje dla przyjęcia oraz nagłówek i pozycje dla wydania. Z widoków powstają pliki w dwóch formatach: JSON oraz EDI. WMS wysyła je do katalogu wyjściowego na serwerze SFTP, a osobna procedura oznacza zlecenie jako wysłane. Oba formaty powstają z tych samych widoków.

Dwie reguły dotyczą segmentów. Segment z numerem palety pojawia się tylko wtedy, gdy numer palety istnieje w danych, a w wydaniu segment z numerem seryjnym wynika z numeru serii. Skąd numer SSCC bierze się na palecie, wyjaśnia artykuł o trzech kodach etykiety GS1-128, a samą jednostkę logistyczną opisuje strona o SSCC i jednostkach logistycznych.

Testowanie bez usuwania plików z serwera

Do testów służy dedykowana aplikacja z poleceniami importu i eksportu przyjęcia oraz wydania, więc testuje się osobno każdy z czterech obiegów komunikatów. Polecenia importu w trybie testowym nie usuwają plików z serwera, więc ten sam komunikat można przetworzyć ponownie. Pozwala to poprawiać układ komunikatu po stronie klienta i ponawiać import bez każdorazowego wysyłania pliku na serwer.

Przy testach importu pliki zostają na serwerze. Produkcyjne przetwarzanie usuwa je po zapisie.