Oprogramowanie logistyczne - który system odpowiada za jaki proces

Mapa oprogramowania logistycznego - który system odpowiada za jaki proces

Oprogramowanie logistyczne nie jest jednym programem. W typowej firmie działa kilka systemów, a każdy z nich prowadzi inny rekord, na przykład stan zapasu w lokalizacji albo awizację z oknem na rampie. Pytanie „jaki program kupić” ma sens dopiero wtedy, gdy wiadomo, który rekord jest czyj.

Podział wynika z miejsca, w którym towar lub pojazd fizycznie przebywa. Magazyn odpowiada za to, co leży na regałach i paletach, plac za to, co czeka pod bramą, a transport za to, co jedzie po trasie. Reklamacja i zwrot zaczynają się dopiero po wydaniu towaru, więc obsługuje je osobny obieg dokumentów.

Magazyn prowadzi system opisany na stronie Studio WMS.net, plac i bramę obsługuje moduł awizacji z artykułu o awizacjach VSS.net, a obieg palet omawia tekst o ewidencji palet. Każdy z tych systemów da się uruchomić osobno, ale dopiero wymiana statusów między nimi zamienia zestaw programów w jedną logistykę.

Reguła: każdy rekord ma jednego właściciela, a pozostałe systemy dostają jego kopię tylko do odczytu.

Reguła ma skutek praktyczny. Jeżeli stan zapasu edytują jednocześnie ERP i magazyn, po tygodniu nikt nie wie, która liczba jest prawdziwa. Przy jednym właścicielu rozbieżność da się zawsze wyjaśnić historią zmian w jednym miejscu.

Oprogramowanie do zarządzania logistyką - granice między systemami

Oprogramowanie do zarządzania logistyką dzieli się według obiektu, którym steruje. Praca przy regale ma inny rytm niż praca przy bramie, a ta z kolei różni się od pracy na trasie. Łączenie tych obszarów w jednym module kończy się kompromisami w każdym z nich.

WMS - zapas i lokalizacje

System klasy WMS zna każdą lokalizację i każdą jednostkę składowaną w magazynie. Przesunięcie palety z lokalizacji A do B to dwie zmiany stanu, a system zapisuje je w jednej transakcji, żeby przerwanie pracy terminala nie zostawiło towaru w dwóch miejscach naraz. Skanowanie kodów GS1 na terminalu z systemem Android zastępuje ręczne wpisywanie numerów, więc błąd przepisania znika już na wejściu.

Klient Windows i terminal Android pracują w rodzinie Studio WMS.net na jednej bazie SQL Server. Układ modułów opisuje artykuł aplikacje WMS - moduły i architektura. Wspólna baza oznacza, że dokument wystawiony na terminalu jest od razu widoczny w kliencie biurowym, bez kolejki pośredniej.

YMS - okno czasowe i rampa

System YMS przejmuje moment, w którym pojazd jeszcze nie jest w magazynie, ale już wpływa na jego pracę. Przewoźnik rezerwuje okno czasowe na rampie, dyspozytor je zatwierdza, a ochrona sprawdza pojazd przy bramie. Numer rejestracyjny z awizacji służy do porównania z odczytem kamery ANPR. Opis rozwiązania znajduje się w tekście o systemie YMS, a stronę producenta prowadzi serwis awizacje.softwarestudio.com.pl.

VSS.net wymienia dane z ERP przez API i EDI, a zatwierdzona awizacja trafia do WMS jako oczekujące zlecenie przyjęcia. Magazynier otwiera po przyjeździe pojazdu zlecenie z gotowymi pozycjami. Mechanizm opisuje artykuł o tym, jak VSS łączy się z WMS i ERP przy przyjęciach.

TMS - zlecenie transportowe i trasa

System TMS pracuje po stronie przewoźnika albo spedytora. Jego rekordem jest zlecenie transportowe z trasą i rozliczeniem z podwykonawcą. YMS stoi po drugiej stronie tego samego kontaktu: przyjmuje pojazd pod magazynem, podczas gdy TMS pilnuje jego trasy. Program tej klasy przedstawiamy na stronie Program TMS Linkway.

Zlecenie z TMS i awizacja z YMS mają wspólny element, czyli numer rejestracyjny pojazdu oraz numer zamówienia lub zlecenia. To on pozwala połączyć oba rekordy bez ręcznego wpisywania. Pola powinny mieć w obu systemach ten sam format, na przykład numer rejestracyjny zapisany wielkimi literami bez spacji.

RMA i PWS - obiegi poza wydaniem towaru

Reklamacja zaczyna się po sprzedaży: klient zgłasza wadę, a system prowadzi statusy i terminy odpowiedzi. Zwracany towar wraca do magazynu, więc status zgłoszenia i dokument przyjęcia powinny odwoływać się do tego samego numeru. Rozwiązanie opisuje strona o oprogramowaniu reklamacyjnym Studio RMA.net.

Palety i opakowania zwrotne tworzą osobne saldo dla każdego kontrahenta. Bez niego spory z przewoźnikami o brakujące palety rozstrzyga się na podstawie papierowych kwitów. Ewidencję prowadzi moduł PWS, a saldo kontrahenta powinno być widoczne już przy wydaniu towaru.

Dedykowane oprogramowanie logistyczne czy gotowy system

Gotowy system konfigurowalny ma wbudowany model procesu, który zmienia się parametrami. Dedykowane oprogramowanie logistyczne powstaje po analizie procesu i odwzorowuje go w kodzie. Oba podejścia mają swoje miejsce, a wybór zależy od tego, czy różnicę względem standardu da się wyrazić ustawieniem.

W praktyce najczęściej spotyka się układ mieszany: gotowy produkt jako baza i dedykowane moduły tam, gdzie standard nie wystarcza. SoftwareStudio rozwija takie rozszerzenia dla ERP w obszarze specjalistycznej logistyki, a także reklamacji oraz awizacji. Ramy współpracy nad kodem opisuje strona o dedykowanym oprogramowaniu na zamówienie.

• Nietypowy dokument - wydruk lub wymiana z kontrahentem, której format narzuca odbiorca i nie mieści się w szablonie produktu.
• Nietypowa jednostka - nośnik lub opakowanie, którego nie da się opisać standardowym typem jednostki logistycznej.
• Reguła rozliczeń - naliczanie opłat za przestój lub składowanie według umowy, która odbiega od cennika.
• Urządzenie w procesie - waga lub sorter, które muszą przekazywać dane bezpośrednio do systemu.

Dedykowany kod wymaga też dyscypliny, której gotowy produkt nie narzuca użytkownikowi. Zmiany schematu bazy wprowadza się skryptami migracyjnymi z numerem wersji, a każdą wersję testuje się na kopii bazy produkcyjnej. Bez tego pierwsza aktualizacja po roku kończy się ręcznym porównywaniem tabel.

Prosty test: jeśli zmianę da się zapisać jako wartość parametru, na przykład długość okna czasowego albo strategię FEFO, wystarczy gotowy system. Jeśli wymaga nowego pola z własną walidacją albo nowego kroku w dokumencie, do gry wchodzi kod. Przed decyzją opłaca się przejść analizę przedwdrożeniową, bo to ona odsłania, ile wymagań jest rzeczywiście niestandardowych.

Wspólna baza SQL Server i integracje między systemami

Aplikacje jednego systemu, na przykład klient Windows i terminal Android w WMS, korzystają z jednej bazy SQL Server. Przyjęcie towaru i zmiana stanu zapisują się wtedy w tej samej transakcji, a widok raportowy zawsze pokazuje aktualny stan. Ta sama zasada nie działa między produktami różnych dostawców, dlatego tam potrzebna jest integracja przez komunikaty.

Tabela wymiany jest najprostszym mechanizmem, który da się zbudować bez zewnętrznego brokera. Poniższy przykład ma charakter poglądowy, a nazwy obiektów są przykładowe. Komunikat trafia do kolejki ze statusem 0, a łącznik pobiera paczkę wierszy i oznacza je jako będące w toku.

CREATE TABLE dbo.ExchangeQueue (
    MessageId  BIGINT IDENTITY(1,1) PRIMARY KEY,
    SourceDoc  NVARCHAR(40)  NOT NULL,
    Payload    NVARCHAR(MAX) NOT NULL,
    Status     TINYINT       NOT NULL DEFAULT 0,  -- 0 nowy, 1 w toku, 2 wysłany
    ClaimedAt  DATETIME2(0)  NULL,
    CreatedAt  DATETIME2(0)  NOT NULL DEFAULT SYSUTCDATETIME()
);
CREATE UNIQUE INDEX UX_ExchangeQueue_Source ON dbo.ExchangeQueue (SourceDoc);
CREATE INDEX IX_ExchangeQueue_New ON dbo.ExchangeQueue (MessageId) WHERE Status = 0;

;WITH nxt AS (
    SELECT TOP (10) *
    FROM dbo.ExchangeQueue WITH (ROWLOCK, UPDLOCK, READPAST)
    WHERE Status = 0
    ORDER BY MessageId
)
UPDATE nxt SET Status = 1, ClaimedAt = SYSUTCDATETIME()
OUTPUT inserted.MessageId, inserted.SourceDoc, inserted.Payload;

Unikalny indeks na polu SourceDoc pełni rolę klucza idempotencji: ten sam dokument wysłany drugi raz po przerwie w łączności nie utworzy duplikatu. Indeks filtrowany z warunkiem Status = 0 zawiera tylko wiersze oczekujące, więc pozostaje mały, choć tabela z czasem rośnie. Podpowiedzi READPAST i UPDLOCK pozwalają kilku łącznikom pobierać różne paczki bez czekania na siebie, a ich składnię opisuje dokumentacja table hints w Microsoft Learn.

Reguła: komunikat z systemu zewnętrznego musi dać się wysłać drugi raz bez skutków ubocznych.

Obsługa błędów w kolejce wymiany

Łącznik może przerwać pracę w połowie paczki, na przykład po restarcie usługi. Wiersze ze statusem 1 zostają wtedy bez właściciela i nikt ich już nie pobierze. Rozwiązaniem jest zadanie SQL Agent uruchamiane co kilka minut, które przywraca status 0 dla wierszy zajętych zbyt długo.

UPDATE dbo.ExchangeQueue
SET Status = 0, ClaimedAt = NULL
WHERE Status = 1
  AND ClaimedAt < DATEADD(MINUTE, -15, SYSUTCDATETIME());

Ponowne wysłanie nie szkodzi, bo odbiorca rozpoznaje dokument po kluczu idempotencji. Warto też liczyć wiersze, które wróciły do statusu 0 więcej niż raz, ponieważ oznaczają komunikat, którego odbiorca stale nie przyjmuje. Taki wiersz przenosi się do osobnej tabeli błędów i zgłasza operatorowi, zamiast zapętlać się w kolejce.

Raporty i blokady na wspólnej bazie

Osobną kwestią są raporty na tej samej bazie. Przy domyślnym poziomie READ COMMITTED długie zapytanie odczytowe czeka na zapisy i odwrotnie. Włączenie opcji READ_COMMITTED_SNAPSHOT sprawia, że odczyt korzysta z wersji wiersza i nie blokuje zapisów, co opisuje przewodnik po blokadach i wersjonowaniu wierszy. Masowa aktualizacja jednej tabeli może natomiast przekroczyć próg około 5000 blokad w jednej instrukcji i zostać eskalowana do blokady całej tabeli, więc duże korekty wykonuje się porcjami.

Wymianę komunikatów między magazynami i systemami zewnętrznymi opisuje osobno artykuł o integracji systemów magazynowych.

Sprzęt i identyfikacja w oprogramowaniu logistycznym

Oprogramowanie jest tak dokładne, jak dane, które wpisano na wejściu. W magazynie dane wchodzą przez terminale z systemem Android oraz skanery kodów. Drukarki Zebra otrzymują treść etykiety w języku ZPL, a system logistyczny generuje ją z danych dokumentu, więc etykieta nie wymaga ręcznej edycji.

Jednostki logistyczne identyfikuje numer SSCC, czyli 18-cyfrowy klucz GS1 zakończony cyfrą kontrolną. Kod zapisuje się na etykiecie w symbolice GS1-128, a skaner odczytuje go w ułamku sekundy. Zasady budowy etykiety opisuje artykuł o etykiecie logistycznej GS1. Ten sam numer trafia do awizacji ładunku, dzięki czemu przy rampie kontrola polega na skanowaniu, a nie na liczeniu.

• Terminal Android - aplikacja magazynowa pracuje na urządzeniu z czytnikiem kodów, także w trybie offline.
• Drukarka etykiet - odbiera ZPL z systemu i drukuje etykietę SSCC po zamknięciu jednostki.

Oprogramowanie dla logistyki - dobór na podstawie objawów w firmie

Oprogramowanie dla logistyki dobiera się od problemu, który da się zmierzyć, a nie od listy modułów. Każdy objaw ma zwykle jedną dominującą przyczynę, którą adresuje jeden system.

Kolejność wdrożeń wynika z tabeli, ale też z zależności. WMS daje wiarygodny zapas, na którym opiera się reszta, więc przy niepewnych stanach zaczyna się od niego. YMS wdraża się wcześniej, gdy wąskim gardłem są rampy, a magazyn wewnątrz pracuje sprawnie.

W firmie operatora logistycznego ten podział trzeba dodatkowo powtórzyć per zleceniodawca, bo każdy klient ma własne zapasy oraz własne reguły.

Wdrożenie oprogramowania logistycznego - od analizy do przełączenia

Wdrożenie zaczyna się od analizy przedwdrożeniowej, w której opisuje się procesy w stanie obecnym i wskazuje różnice względem standardu produktu. Wynikiem jest lista wymagań z podziałem na konfigurację i rozwój. Bez niej wycena dedykowanych elementów opiera się na przypuszczeniach.

• Kartoteki - indeksy towarowe z jednostkami miary i przelicznikami, które muszą zostać oczyszczone przed importem.
• Struktura lokalizacji - opis stref i regałów z zasadami składowania dla każdej strefy.
• Dokumenty - wzory wydruków i mapowanie typów dokumentów między ERP a WMS.
• Integracje - lista komunikatów z kierunkiem przepływu oraz sposobem obsługi błędów.

Po analizie uruchamia się pilot na jednym magazynie lub jednej strefie z prawdziwymi dokumentami. Przez ograniczony czas oba systemy pracują równolegle, a różnice w stanach wyjaśnia się na bieżąco. Przełączenie wykonuje się po inwentaryzacji, bo stany początkowe muszą być zgodne z rzeczywistością.

Zasada: przełączenie systemu magazynowego planuje się po inwentaryzacji, a nie przed nią.

Do wdrożenia dołącza się plan reakcji na awarię: co robi magazynier, gdy terminal traci łączność, i jak wprowadza się dokumenty po przywróceniu połączenia. Tego scenariusza nie da się wymyślić w dniu awarii. Testuje się go przed przełączeniem, na tym samym sprzęcie, na którym system będzie pracował.