Rola YMS w łańcuchu dostaw - przepływ zdarzeń między systemami

Rola YMS w łańcuchu dostaw

Łańcuch dostaw składa się z systemów, z których każdy zna inny fragment rzeczywistości. ERP zna zamówienie, TMS zna zlecenie przewozu, a WMS zna towar w magazynie. Żaden z nich nie zna pojazdu, który stoi na placu i czeka na rampę. Tę lukę wypełnia YMS, bo jako jedyny zapisuje, kiedy pojazd dotarł i gdzie stoi, a także kiedy zakończono obsługę.

Rola YMS polega więc na przekształceniu planu w zdarzenia. Plan pochodzi z ERP i TMS i obejmuje zamówienie oraz orientacyjną godzinę przyjazdu. Zdarzenia pochodzą z placu i dotyczą wjazdu oraz podstawienia pod rampę, a potem końca rozładunku i wyjazdu. Dopiero zestawienie obu poziomów pokazuje, czy dostawa jest terminowa, a nie sama data z zamówienia.

Na cztery pytania YMS odpowiada wszystkim pozostałym systemom łańcucha.

• Kiedy - rzeczywisty czas przyjazdu i końca obsługi względem okna czasowego.
• Gdzie - miejsce postojowe i rampa przypisane do wizyty.
• Kto - przewoźnik z kierowcą oraz kontrahent powiązany z awizacją.
• Jak długo - czas do rampy i czas obsługi oraz postój łączny.

Koordynacja transportów przewoźników z planem pracy magazynu likwiduje skokowe obciążenie. Płaski rozkład obciążenia ułatwia zaplanowanie prac w magazynie i ogranicza stres, który bywa przyczyną pomyłek i wypadków.

Reguła: YMS jest źródłem prawdy o czasie i miejscu pojazdu, WMS o stanie towaru, a ERP o dokumencie. Żaden system nie nadpisuje danych, które należą do innego.

Skutki braku systemu placowego

Bez systemu placowego zdarzenia z bramy istnieją w zeszycie ochrony i w pamięci dyspozytora. TMS dowiaduje się o dostawie dopiero z dokumentów, ERP wie o przyjęciu dopiero po dokumencie PZ, a między tymi punktami nikt nie policzy oczekiwania na rampie. Skutkiem bywa spór o opłaty za postój: przewoźnik wykazuje czas przyjazdu z własnych danych, magazyn z własnych, a żadna ze stron nie ma wspólnego dowodu.

Zakres funkcjonalny klasy rozwiązań opisuje artykuł o systemie YMS, a przebieg pojedynczej wizyty przedstawia tekst o yard management system.

YMS a WMS - przekazanie rozładunku

Punkt styku YMS i WMS to rozładunek. Do jego rozpoczęcia odpowiada system placowy, po zakończeniu system magazynowy. Zatwierdzona awizacja trafia do WMS jako oczekujące zlecenie przyjęcia z pozycjami i ilościami z zamówienia. Magazynier po przyjeździe pojazdu otwiera zlecenie, które nie wymaga ręcznego wprowadzania. Statusy z magazynu wracają do YMS, na przykład zakończenie rozładunku.

Weryfikację ilości z etykietami SSCC i obsługę rozbieżności omawia artykuł o awizacjach dostaw do magazynu od strony przyjęcia towaru. Mechanizm przekazania danych opisuje tekst o integracji VSS z WMS i ERP przy przyjęciach.

Statusy wracające z magazynu

Zdarzenia z WMS domykają wizytę. Należą do nich rozpoczęcie i zakończenie rozładunku oraz ewentualna rozbieżność ilościowa. Rozsądna zasada mówi, że rozbieżność jest zdarzeniem magazynowym, a nie placowym. Nie wstrzymuje więc zamknięcia wizyty ani zwolnienia rampy, a jej wyjaśnienie odbywa się w procesie przyjęcia.

Skrzynka nadawcza zdarzeń

Największe ryzyko przy przekazaniu to utrata komunikatu. Jeżeli aplikacja zatwierdzi awizację, a potem osobno wyśle wiadomość do WMS, awaria między tymi krokami zostawia awizację zatwierdzoną, o której magazyn nie wie. Wzorzec skrzynki nadawczej (outbox) rozwiązuje to w bazie danych: zmiana statusu i zapis komunikatu odbywają się w jednej transakcji. Osobne zadanie, na przykład w SQL Agent, odczytuje niewysłane wiersze i przekazuje je dalej. Nazwy tabel i kolumn są poglądowe.

CREATE TABLE dbo.IntegrationOutbox (
    MessageId bigint IDENTITY(1,1) PRIMARY KEY,
    Target    varchar(10)   NOT NULL,   -- adresat komunikatu
    EventType varchar(30)   NOT NULL,
    Payload   nvarchar(max) NOT NULL,
    CreatedAt datetime2(0)  NOT NULL DEFAULT SYSDATETIME(),
    SentAt    datetime2(0)  NULL,
    Attempts  int           NOT NULL DEFAULT 0
);
GO

CREATE PROCEDURE dbo.usp_ApproveAdvice
    @AdviceId int
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;
    BEGIN TRANSACTION;

    UPDATE dbo.Advice
    SET    Status = 'APPROVED'
    WHERE  AdviceId = @AdviceId
      AND  Status = 'BUFFER';

    IF @@ROWCOUNT = 1
        INSERT dbo.IntegrationOutbox (Target, EventType, Payload)
        VALUES ('WMS', 'AdviceApproved',
                (SELECT AdviceId, PlannedStart, WarehouseCode
                 FROM   dbo.Advice
                 WHERE  AdviceId = @AdviceId
                 FOR JSON PATH, WITHOUT_ARRAY_WRAPPER));

    COMMIT TRANSACTION;
END;

Warunek Status = 'BUFFER' w instrukcji UPDATE działa jak kontrola stanu: druga próba zatwierdzenia tej samej awizacji nie zmieni żadnego wiersza, więc @@ROWCOUNT wyniesie zero i komunikat nie powstanie po raz drugi. Dzięki SET XACT_ABORT ON błąd w dowolnym miejscu wycofuje całą transakcję, także zapis w skrzynce.

Zadanie wysyłające oznacza wiersz jako wysłany dopiero po potwierdzeniu odbioru przez adresata. Przy braku potwierdzenia zwiększa licznik prób w kolumnie Attempts, a po przekroczeniu limitu przekazuje wiersz do ręcznej obsługi, aby jedna wadliwa wiadomość nie blokowała kolejnych.

YMS a TMS - plan przewoźnika i czasy rzeczywiste

System TMS planuje trasy i przydziela zlecenia do pojazdów, więc zna godzinę planowanego przyjazdu. Jego widoczność kończy się na bramie. Od tego miejsca odpowiada YMS, który zwraca czas rzeczywisty. Różnica obu wartości jest opóźnieniem, które planista przewoźnika może uwzględnić przy kolejnych zleceniach tego samego dostawcy. Ogólne zasady planowania transportu opisuje osobny artykuł.

Kierowca przewoźnika może korzystać z aplikacji mobilnej, w której przegląda i aktualizuje informacje o transporcie. Zmiana trafia do YMS i stamtąd do TMS. Nie każdy przewoźnik ma jednak system, który wysyła komunikaty na bieżąco. YMS można zintegrować także przez wymianę plików z programami kontrahentów. Wystarczy, że dostawca udostępni dane transportowe w pliku, a system zaczyta go i przetworzy, bez ręcznego wprowadzania do bazy. Rolę systemu TMS w firmie transportowej opisuje strona o systemie TMS, a przykład rozwiązania po stronie przewoźnika prezentuje serwis Linkway TMS.

Terminowość przyjazdu

Zwrotna informacja dla TMS wymaga jednej definicji terminowości. Pojazd jest w oknie, gdy wjazd mieści się między początkiem okna a końcem bufora, a poza oknem, gdy przyjeżdża później albo wcześniej. Zapytanie klasyfikuje wizyty i liczy opóźnienie w minutach. Wartość bufora przekazuje się jako parametr, bo zależy od umowy z przewoźnikiem, a nazwy tabeli są poglądowe.

SELECT VisitId,
       DATEDIFF(MINUTE, WindowStart, GateInAt) AS DelayMinutes,
       CASE
           WHEN GateInAt < WindowStart THEN 'WCZESNIE'
           WHEN GateInAt <= DATEADD(MINUTE, @BufferMin, WindowStart) THEN 'W OKNIE'
           ELSE 'SPOZNIONY'
       END AS Punctuality
FROM   dbo.YardVisit
WHERE  GateInAt >= @From
  AND  GateInAt <  @To;

Wynik dla przewoźnika jest zestawieniem, a nie karą: dopiero seria spóźnień tego samego dostawcy uzasadnia rozmowę o zmianie okien albo o dodatkowym buforze.

YMS a ERP - zamówienia i rozliczenia

ERP jest dla YMS źródłem planu. System pobiera z ERP zamówienia zakupu albo awiza ASN i tworzy z nich propozycje awizacji, które dostawca potwierdza przez portal www. Wymiana odbywa się przez REST API lub pliki EDI. W drugą stronę ERP otrzymuje statusy kolejnych etapów wizyty, a po przyjęciu w WMS własny dokument przyjęcia.

Przy takiej wymianie ten sam dokument może dotrzeć dwa razy, na przykład po przekroczeniu limitu czasu połączenia. Rekord awizacji potrzebuje wtedy klucza idempotencji, którym jest para: system źródłowy i numer dokumentu. Unikalny indeks pilnuje, aby powtórzenie zaktualizowało istniejący rekord zamiast tworzyć duplikat.

CREATE UNIQUE NONCLUSTERED INDEX UX_Advice_Source
    ON dbo.Advice (SourceSystem, SourceDocument);

UPDATE dbo.Advice
SET    PlannedStart = @PlannedStart
WHERE  SourceSystem = @Sys
  AND  SourceDocument = @Doc;

IF @@ROWCOUNT = 0
    INSERT dbo.Advice (SourceSystem, SourceDocument, PlannedStart)
    VALUES (@Sys, @Doc, @PlannedStart);

Dwie równoległe kopie tego samego dokumentu mogą obie wykonać UPDATE bez skutku i obie spróbować INSERT. Drugi INSERT narusza indeks unikalny (błąd 2601), więc aplikacja przechwytuje wyjątek i powtarza UPDATE. Baza pełni tu rolę ostatecznego arbitra, a nie kod aplikacji. Szersze omówienie łączenia magazynu z ERP przedstawia artykuł o integracji systemów magazynowych.

Statusy zwracane do ERP

W kierunku od YMS do ERP płyną dwie grupy danych. Obie powstają przy zamknięciu wizyty i nie wymagają ręcznego wprowadzania w żadnym z systemów.

• Status etapu - kolejne etapy wizyty z czasem każdego zdarzenia.
• Czas postoju - podstawa do naliczenia opłat postojowych zgodnie z umową z przewoźnikiem.

Korekty zamówień

Zmiana zamówienia w ERP dociera do YMS jako korekta awizacji. Jeżeli okno jest już zarezerwowane, przesunięcie terminu oznacza anulowanie starej rezerwacji i założenie nowej w jednej transakcji. Wykonane osobno, dwa kroki dałyby innemu dostawcy szansę na zajęcie zwolnionego miejsca, a przesunięcie skończyłoby się utratą obu terminów.

Przepływ zdarzeń między systemami

Komunikat między systemami wygodnie zapisać jako kopertę zdarzenia z czterema polami. Przykład w formacie JSON jest poglądowy i nie opisuje rzeczywistego interfejsu produktu.

• eventId - unikalny identyfikator zdarzenia, który odbiorca wykorzystuje jako klucz idempotencji.
• eventType - nazwa zdarzenia, na przykład UnloadingFinished.
• eventAt - czas wystąpienia zdarzenia w systemie źródłowym.
• data - treść zdarzenia z identyfikatorem wizyty i numerem dokumentu.

{
  "eventId": "9f3c2b1e-6d0a-4e4f-8a55-2f1d7c9b0a11",
  "eventType": "UnloadingFinished",
  "eventAt": "2026-10-05T09:42:10",
  "source": "WMS",
  "data": { "visitId": 48213, "dockCode": "R-07", "documentNo": "PZ/2026/10/0456" }
}

Odbiorca tak zapisanego komunikatu odczytuje pola w T-SQL funkcją OPENJSON. Przykład wyodrębnia z komunikatu identyfikator wizyty oraz typ zdarzenia wraz z czasem. Funkcja wymaga poziomu zgodności bazy 130 lub wyższego, czyli SQL Server 2016 albo nowszego. Składnię opisuje dokumentacja OPENJSON w Microsoft Learn.

DECLARE @msg nvarchar(max) = N'{"eventType":"UnloadingFinished","eventAt":"2026-10-05T09:42:10","data":{"visitId":48213}}';

SELECT j.visitId, j.eventType, j.eventAt
FROM   OPENJSON(@msg)
       WITH (
           eventType varchar(30)  '$.eventType',
           eventAt   datetime2(0) '$.eventAt',
           visitId   bigint       '$.data.visitId'
       ) AS j;

Reguła: nadawca gwarantuje dostarczenie co najmniej raz, a odbiorca musi być idempotentny. Dokładnie jedno dostarczenie jest niemożliwe do zapewnienia przy awarii łącza.

Skrzynka nadawcza wymaga monitorowania. Liczba niewysłanych wierszy i wiek najstarszego z nich są najprostszym wskaźnikiem kondycji integracji. Wzrost wieku ponad przyjęty próg oznacza, że odbiorca nie odpowiada albo zadanie wysyłające stoi.

SELECT Target,
       COUNT(*)       AS Pending,
       MIN(CreatedAt) AS Oldest
FROM   dbo.IntegrationOutbox
WHERE  SentAt IS NULL
GROUP BY Target;

Kolejność zdarzeń jednej wizyty ma znaczenie. Koniec rozładunku, który dotrze przed wjazdem, jest błędem danych, a nie informacją. Odbiorca sortuje zdarzenia według czasu i numeru w skrzynce, a komunikaty spoza kolejności odkłada do ponownego przetworzenia.

Moduły uzupełniające rolę YMS

Obok awizacji, którą opisuje artykuł o module awizacji VSS.net, platforma obejmuje moduły rozszerzające rolę YMS na cały teren zakładu. Ujęcie produktowe placu przedstawia tekst o yard management w Studio VSS.net. Moduł parkingowy pozwala tworzyć miejsca postojowe i monitorować ich wykorzystanie, a mapa placu pokazuje stan w czasie rzeczywistym. Zasady jej działania opisuje artykuł o wizualizacji zajętości miejsc parkingowych.

Funkcja zarządzania flotą wspiera śledzenie pojazdów oraz tworzenie tras i dysponowanie wysyłkami w tej samej platformie. Kartoteka pojazdów zakładowych oraz przestawienia między strefami opisuje tekst o transporcie wewnętrznym w module VSS.net. System klasy time slot management opiera się na platformie StudioSystem, rejestruje wizyty, kontroluje ich cel i czas oraz koordynuje dostęp do zasobów, takimi jak doki i wagi.

Wielojęzyczność

Aplikacja jest wielojęzyczna, więc korzystają z niej także firmy o zasięgu międzynarodowego. Komunikaty zdarzeń zawierają kody i identyfikatory zamiast tekstu, dlatego język interfejsu nie wpływa na integrację.

Sposób pracy z awizacją przez przeglądarkę przedstawia artykuł o programie online do awizacji dostaw. Wymagania techniczne platformy są proste: serwer IIS, baza SQL Server, klienci na Windows i Android oraz OSX, wersje językowe polska i angielska. Ewidencję narzędzi i sprzętu, która często działa równolegle na tym samym terenie, opisuje Studio TCS.net.