System zarządzania magazynem SQL - co dzieje się w bazie podczas pracy

System zarządzania magazynem SQL pracuje w tle każdego skanu. Pracownik odczytuje etykietę palety terminalem, a serwer w ułamku sekundy zapisuje operację w bazie i zwraca następną instrukcję. Cała logika magazynu, czyli stany i lokalizacje oraz dokumenty, leży w tabelach relacyjnej bazy danych.

Ten artykuł pokazuje, co dzieje się w bazie podczas typowej zmiany. Zaczyna od przyjęcia i kompletacji, potem opisuje indeksy oraz harmonogram awizacji, a dalej integrację z innymi systemami. Na końcu porównuje bazę SQL z arkuszem kalkulacyjnym i wskazuje sygnały, że pora na wdrożenie. Przykłady kodu mają charakter poglądowy i nie odzwierciedlają schematu produktu.

System zarządzania magazynem SQL przy skanerze

Pracownik skanuje kod kreskowy albo kod QR z etykiety, a terminal wysyła identyfikator do serwera aplikacji. Ten wywołuje procedurę, która zmienia stan w bazie i zwraca odpowiedź, na przykład adres lokalizacji do odłożenia. Papierowy dokument przestaje być pośrednikiem, bo zapis powstaje w chwili operacji. Skanowanie kodów w programie magazynowym opisuje strona o programie magazynowym z czytnikiem kodów.

Reguła: stan magazynowy zmienia się wyłącznie przez zapis ruchu w transakcji. Bezpośrednia edycja stanu w tabeli omija dziennik i uniemożliwia późniejszy audyt.

Odpowiedź terminalowi musi wrócić szybko, bo pracownik czeka z paletą na wózku. Czas składa się z transmisji przez sieć radiową, obsługi żądania przez serwer aplikacji i wykonania procedury w bazie. Dobrze zaprojektowana procedura kończy się w milisekundach, więc opóźnienia pochodzą zwykle z zasięgu sieci Wi-Fi w hali, a nie z bazy.

Automatyzacja zapisu skraca czas przyjęcia dostawy i usuwa błędy przepisywania. Brak papierowych list oznacza też, że każda operacja ma znacznik czasu nadany przez serwer bazy, a nie przez zegar terminala. Ten szczegół decyduje o wiarygodności raportów czasu realizacji.

Operacje magazynowe jako transakcje

Operacja magazynowa zmienia zwykle więcej niż jedną tabelę. Przyjęcie palety zwiększa stan lokalizacji i dopisuje wiersz do dziennika ruchów, a jeśli któryś zapis się nie uda, oba muszą zostać wycofane. Gwarantuje to transakcja bazy danych.

Przyjęcie towaru i zapis ruchu

Terminal przy przyjęciu wysyła numer palety i lokalizację oraz ilość i identyfikator operatora. Procedura zapisuje wszystko w jednej transakcji: pozycję dokumentu, a także stan lokalizacji i wpis dziennika. Przy błędzie żaden z tych zapisów nie zostaje w bazie, więc stan nie rozjeżdża się z historią. Ta sama zasada obowiązuje przy przesunięciach i wydaniach, które opisuje strona o operacjach magazynowych.

Kompletacja i rezerwacja zapasu

Przy kompletacji kilku zleceń naraz dwie osoby mogą chcieć pobrać towar z tej samej lokalizacji. Rezerwacja zapasu musi to rozstrzygać w bazie, a nie w aplikacji, bo aplikacja nie widzi drugiego terminala. Warunek dostępności zapisuje się w samej instrukcji UPDATE, więc sprawdzenie i zmiana odbywają się niepodzielnie.

-- przykład poglądowy, nie schemat produktu
UPDATE dbo.StanLokalizacji
SET Zarezerwowano = Zarezerwowano + @Ilosc
WHERE LokalizacjaId = @LokalizacjaId
  AND NrPalety = @NrPalety
  AND Ilosc - Zarezerwowano >= @Ilosc;

IF @@ROWCOUNT = 0
    RAISERROR('Brak wolnej ilosci na lokalizacji.', 16, 1);

Gdy dwie sesje wykonują to samo polecenie równocześnie, baza zakłada blokadę wiersza i obsługuje je po kolei. Druga sesja zobaczy już zmniejszoną ilość dostępną i dostanie zero zmienionych wierszy, więc terminal wyświetli komunikat o braku towaru. Szczegóły blokad i wersjonowania wierszy opisuje przewodnik po blokowaniu transakcji.

Blokady wierszy są tanie, ale zapytanie obejmujące kilka tysięcy wierszy może zostać zamienione na blokadę całej tabeli. Nazywa się to eskalacją i zatrzymuje wtedy pracę innych stanowisk. Dlatego duże aktualizacje, na przykład przeliczenie rezerwacji dla wszystkich zleceń, dzieli się na partie. Sam proces opisuje strona o kompletacji zamówień.

Inwentaryzacja bez zatrzymywania magazynu

Inwentaryzacja w systemie opartym na bazie jest dokumentem z pozycjami, a nie nadpisaniem stanu. Pracownik skanuje lokalizację i palety, a system zestawia policzoną ilość ze stanem systemowym z chwili liczenia. Różnice trafiają na listę do wyjaśnienia i dopiero po zatwierdzeniu powstaje ruch korygujący z zapisanym powodem.

• Spis cykliczny - liczy się część lokalizacji każdego dnia, więc magazyn pracuje bez przerwy, a dokładność stanu jest sprawdzana przez cały rok.
• Ruch korygujący - różnica jest dodatkowym wpisem w dzienniku, dzięki czemu historia stanu zostaje nienaruszona.

Wpis korygujący ma operatora i czas, więc kierownik może zestawić różnice według stref albo zmian. Zasady liczenia i rozliczania różnic opisuje strona o inwentaryzacji ciągłej w magazynie.

Indeksy i diagnostyka wydajności bazy

Wyszukiwanie palety po indeksie

Odpowiedź o lokalizacji palety w ułamku sekundy wynika z indeksu, a nie z samej mocy serwera. Indeks unikalny na numerze palety pozwala bazie dojść do jednego wiersza w kilku krokach, niezależnie od tego, czy tabela ma kilka tysięcy, czy kilka milionów rekordów. Bez indeksu baza przeszukuje całą tabelę, więc czas rośnie razem z jej rozmiarem.

CREATE UNIQUE NONCLUSTERED INDEX UX_StanLokalizacji_Paleta
ON dbo.StanLokalizacji (NrPalety, LokalizacjaId);

CREATE NONCLUSTERED INDEX IX_StanLokalizacji_Lokalizacja
ON dbo.StanLokalizacji (LokalizacjaId)
INCLUDE (NrPalety, Ilosc, Zarezerwowano);

Pierwszy indeks obsługuje pytanie „gdzie jest ta paleta”, a drugi pytanie „co leży na tej lokalizacji”. Kolumny dopisane przez INCLUDE pozwalają odpowiedzieć bez sięgania do tabeli. Każdy indeks wydłuża zapis, więc ich liczbę ogranicza się do zapytań wykonywanych naprawdę często. Odczyt bieżących stanów, który z nich korzysta, opisuje strona o stanach magazynowych.

Sesje blokujące innych użytkowników

Gdy terminale zaczynają czekać na odpowiedź, przyczyną bywa sesja, która trzyma blokadę zbyt długo, na przykład raport uruchomiony na bazie produkcyjnej. Zapytanie do widoków systemowych pokazuje, która sesja blokuje którą i na co czeka. Wynik wskazuje zapytanie do poprawienia albo raport do przeniesienia poza godziny pracy.

SELECT r.session_id, r.blocking_session_id, r.wait_type,
       r.wait_time, t.text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.blocking_session_id <> 0;

Stałe pomiary tych opóźnień pozwalają odróżnić spowolnienie bazy od problemu sieci Wi-Fi w hali albo awarii terminala. Trwała blokada tej samej tabeli sygnalizuje potrzebę indeksu albo krótszej transakcji. Sposób opisania takich wskaźników w raportach omawia tekst o KPI w systemie WMS.

Harmonogram awizacji i dokumenty magazynowe

Baza przechowuje także plan pracy bram: zapisy awizacji i okna czasowe oraz przypisanie przewoźników. Kalendarz w widoku tygodniowym pozwala z wyprzedzeniem zobaczyć, które dni mają największy ruch, i odpowiednio ułożyć obsadę. Przydział slotów czasowych ogranicza sytuację, w której kilka samochodów czeka jednocześnie pod jedną bramą.

Zapis awizacji zawiera datę i godzinę okna oraz bramę, a także przewoźnika i rodzaj operacji, bo rozładunek palet trwa inaczej niż rozładunek luzem. Długość okna wynika z tych danych, a nie z przeczucia dyspozytora. Przy próbie zapisu nakładającego się terminu na tej samej bramie system odrzuca zapis, ponieważ kontrola kolizji jest częścią procedury, a nie ręcznego przeglądu kalendarza.

Studio WMS.net udostępnia w menu moduły przyjęć i wydań oraz cross-dockingu i przesunięć. Osobne pozycje obsługują inwentaryzację i kalendarze oraz palety. Każdy z modułów zapisuje dokumenty w tej samej bazie, więc widok kierownika obejmuje wszystkie procesy naraz. Opis modułów produktu znajduje się na stronie systemu zarządzania magazynem WMS.

Integracja i raportowanie na wspólnej bazie

System magazynowy rzadko działa samodzielnie. Zamówienia przychodzą z ERP albo ze sklepu internetowego, a dokumenty PZ i WZ trafiają do księgowości. Wymianę realizują usługi sieciowe lub kolejka zdarzeń, dzięki czemu nikt nie wpisuje tych samych danych dwa razy. Techniczne warianty opisuje artykuł o integracji WMS z ERP przez REST i kolejki.

Wspólna baza jest też źródłem raportów. Kierownik analizuje rotację poszczególnych indeksów towarowych, czas realizacji zleceń i wydajność stref, a wnioski przekładają się na rozmieszczenie towaru i plan zatowarowania. Wskaźniki i sposób ich liczenia opisuje tekst o raportowaniu w systemie WMS z użyciem KPI i SSRS.

Historia sprzedaży zapisana w bazie może zasilać modele prognozujące popyt i sezonowość. Model uczy się na danych z kilku lat, więc jakość zapisu decyduje o jakości prognozy. Ogólne zastosowania takich modeli omawia strona o sztucznej inteligencji w firmie, a ogólną architekturę opisuje tekst o magazynowych systemach informatycznych.

Baza WMS w chmurze czy na własnym serwerze

Baza systemu magazynowego może stać na serwerze własnym albo u dostawcy chmury. Chmura zdejmuje z firmy utrzymanie serwerowni i wykonywanie kopii zapasowych, a w zamian pojawia się miesięczny abonament. Instalacja lokalna daje pełną kontrolę nad danymi i przy stałym, dużym wolumenie bywa tańsza w długim horyzoncie.

Wybór zależy od skali magazynu i budżetu na infrastrukturę oraz od wymagań dotyczących bezpieczeństwa danych. Szczegółowe porównanie obu modeli zawiera strona o programie magazynowym w chmurze i na własnym serwerze oraz zestawienie WMS w chmurze a on-premise. Niezależnie od modelu baza wymaga regularnych kopii dziennika i testów odtwarzania.

Miarą jakości kopii jest czas, w którym magazyn wraca do pracy po awarii, oraz ilość operacji, które można utracić. Oba parametry warto zapisać w umowie z dostawcą albo w wewnętrznej procedurze, bo magazyn bez systemu przechodzi na papier i po godzinie zaczyna gubić kontrolę nad stanem. Test odtworzenia bazy na osobnej instancji wykonuje się co najmniej raz w roku.

Arkusz kalkulacyjny czy baza SQL w magazynie

Mniejsze magazyny często zaczynają od arkusza, bo nie wymaga wdrożenia ani szkolenia. Różnica pojawia się przy większej liczbie dokumentów i lokalizacji oraz osób pracujących naraz. Wtedy widać ograniczenia, których arkusz nie obejdzie.

Dla firmy z jednym magazynem i kilkudziesięcioma indeksami towarowymi arkusz bywa wystarczający przez pewien czas. Gdy rośnie liczba zamówień i osób obsługujących magazyn, koszt utrzymania porządku w pliku przewyższa koszt wdrożenia. Przebieg takiego projektu opisuje strona o wdrożeniu systemu WMS, a rodzaje magazynów opisuje tekst o systemie magazynowym SQL.

Sygnały, że arkusz przestaje wystarczać

• Rosnąca liczba pomyłek - ręczne wpisywanie dokumentów PZ i WZ oraz przesunięć kończy się różnicami inwentaryzacyjnymi.
• Wydłużony czas kompletacji - brak wyznaczonej trasy zbiórki zmusza pracowników do chodzenia po hali bez planu.
• Brak wglądu w stany - dział sprzedaży i obsługi klienta nie widzi dostępności towaru na bieżąco.
• Brak historii zmian - nie da się ustalić, kto i kiedy zmodyfikował dany rekord.

Im więcej z tych punktów dotyczy danego magazynu, tym szybciej wdrożenie systemu opartego na SQL odzyska koszt w postaci mniejszej liczby błędów i czasu pracowników. Interaktywną wersję systemów firmy można uruchomić bez rejestracji pod adresem demo.softwarestudio.com.pl.