3PL WMS Software - program magazynowy WMS

Czym 3PL WMS Software różni się od systemu dla magazynu własnego

Operator logistyczny nie jest właścicielem towaru, który leży na jego regałach. Ta jedna okoliczność zmienia wymagania wobec oprogramowania bardziej niż wielkość hali czy liczba lokalizacji. System dla magazynu własnego odpowiada na pytanie, ile sztuk artykułu firma ma na stanie. System dla operatora musi dodatkowo wskazać, czyje to są sztuki, na jakich warunkach umowy leżą w magazynie i ile operator może za to naliczyć.

3PL WMS Software (od ang. Third-Party Logistics) obsługuje więc wielu zleceniodawców w jednej instalacji. Każdy z nich ma własne kartoteki, własne zasady kompletacji i własny cennik usług. Sposób rozdzielenia danych w bazie opisuje osobny artykuł o systemie WMS dla operatora 3PL i danych wielu klientów. Ten tekst dotyczy tego, co system robi z rozdzielonymi danymi: rozlicza usługi, udostępnia je klientowi i wymienia z jego systemami.

Reguła: każdy ruch magazynowy w systemie 3PL musi mieć właściciela towaru i kod usługi, do której przypisze się opłatę. Ruchu bez właściciela nie da się rozliczyć ani udostępnić klientowi.

Pojęcie operatora i zakres jego odpowiedzialności wyjaśnia strona o operatorze logistycznym, a definicję modelu outsourcingu - artykuł 3PL co to jest. Studio WMS.net od SoftwareStudio jest przykładem programu, który łączy segregację zapasów z portalem klienta. Program ma też automatyczne fakturowanie oraz integracje EDI i API.

Portal klienta i widoczność danych zleceniodawcy

Zleceniodawca chce wiedzieć, co dzieje się z jego towarem, i nie chce w tym celu dzwonić do magazynu. Portal klienta odpowiada na to pytanie przez przeglądarkę. Klient loguje się własnym kontem i widzi wyłącznie swoje rekordy, więc operator nie musi przygotowywać zestawień na zamówienie. Szczegóły dostępu opisuje strona o module internetowym dla kontrahentów w systemie WMS.

Zakres portalu wynika z umowy, a nie z możliwości systemu. Jeden klient chce widzieć tylko stany i statusy zleceń, drugi także dokumenty magazynowe oraz historię ruchów. Zakres ustawia się przez role i uprawnienia, tak jak w opisie ról i użytkowników w systemie WMS.

• Stany magazynowe - ilości dostępne oraz zablokowane, pokazywane w rozbiciu na partie i terminy ważności.
• Statusy zleceń - etap od przyjęcia zamówienia przez kompletację po wydanie, z czasem każdego etapu.
• Dokumenty - przyjęcia i wydania do pobrania w formie wydruku.
• Zakres uprawnień - decyzja, czy klient tylko przegląda dane, czy może także dodawać zlecenia wydania.

Każde wejście klienta do portalu zostawia ślad w dzienniku, z nazwą użytkownika i czasem otwarcia raportu. Ślad przydaje się przy sporze o to, czy klient znał stan zapasu w danym dniu. Operator zyskuje dowód, że informacja była dostępna, a klient - że nie musiał o nią pytać.

Klient nie dostaje bezpośredniego dostępu do tabel. Portal korzysta z widoków i procedur, które zawsze dopisują filtr właściciela do zapytania. Dzięki temu pomyłka w konfiguracji ekranu nie ujawni rekordów sąsiedniego kontrahenta, a zapytania klienta nie blokują operacji na hali.

Naliczanie opłat za usługi magazynowe

Przychód operatora składa się z wielu drobnych pozycji, na przykład opłaty za składowanie oraz za każde przyjęcie i wydanie. Bez automatu rozliczenie miesięczne oznacza ręczne przeglądanie dokumentów każdego klienta. System 3PL rozwiązuje to przez zdarzenia rozliczeniowe. W chwili zapisu ruchu WMS dopisuje wiersz opisujący właściciela i usługę. Wiersz zawiera też ilość, a rozliczenie okresu sprowadza się do agregacji takich wierszy.

Pełny opis rozliczeń kosztowych znajduje się w artykule o rozliczaniu kosztów magazynowych. Poniższy schemat pokazuje sam mechanizm; nazwy tabel są przykładowe i nie oddają struktury konkretnego produktu.

-- przykładowy schemat, nie struktura konkretnego produktu
CREATE TABLE BillingEvent (
    EventId     bigint IDENTITY PRIMARY KEY,
    OwnerId     int           NOT NULL,
    ServiceCode varchar(20)   NOT NULL,
    Quantity    decimal(12,3) NOT NULL,
    EventDate   date          NOT NULL,
    SourceDocId int           NULL
);

-- zamknięcie okresu: suma usług per klient
SELECT OwnerId, ServiceCode, SUM(Quantity) AS Qty
FROM BillingEvent
WHERE EventDate >= '2026-09-01' AND EventDate < '2026-10-01'
GROUP BY OwnerId, ServiceCode;

Składnię agregacji opisuje dokumentacja GROUP BY w Transact-SQL w Microsoft Learn. Zdarzenie powstaje w tej samej transakcji co ruch magazynowy, więc cofnięcie ruchu cofa także opłatę.

Zasada: opłatę za składowanie liczy nocne zadanie SQL Agent, które zapisuje migawkę zajętych paletomiejsc każdego klienta. Późniejsza korekta stanu nie przepisuje historii, bo faktura opiera się na migawce z danego dnia.

Opłaty dodatkowe wymagają dyscypliny. Czynność spoza standardowego procesu, na przykład ponowne etykietowanie towaru na życzenie klienta, operator zapisuje z powodem i osobą zlecającą. Klient, który dostaje fakturę z pozycją bez uzasadnienia, kwestionuje całe rozliczenie, więc dobry system nie pozwala zapisać takiej czynności bez opisu.

Cennik trzyma się w osobnej tabeli z okresem obowiązywania stawki. Zmiana ceny od nowego miesiąca nie zmienia wtedy wyliczeń za miesiące zamknięte. Gotowe pozycje trafiają do faktury w systemie księgowym klienta operatora albo w jego własnym ERP.

Integracje EDI i API z systemami klientów

Klienci operatora używają różnych systemów. Sklep internetowy wysyła zamówienia przez API, producent przekazuje awizo dostawy plikiem, a dystrybutor oczekuje potwierdzenia wydania w ustalonym formacie. Każdy z tych kanałów wymaga osobnej konfiguracji, ale sam mechanizm jest wspólny: komunikat trafia do kolejki i przechodzi walidację. Dopiero po niej zmienia stan magazynu. Zasady łączenia z systemami ERP omawia artykuł o integracji systemów magazynowych.

Najczęściej występuje duplikat. Klient ponawia żądanie, bo nie dostał odpowiedzi, a system wprowadza to samo zamówienie po raz drugi. Zabezpiecza przed tym identyfikator komunikatu nadawany przez klienta i indeks unikalny na parze właściciel oraz identyfikator.

-- przykładowy schemat, nie struktura konkretnego produktu
CREATE UNIQUE INDEX UX_InboundMessage_Owner_Msg
    ON InboundMessage (OwnerId, ExternalMessageId);

BEGIN TRY
    INSERT INTO InboundMessage (OwnerId, ExternalMessageId, Payload, ReceivedAt)
    VALUES (@OwnerId, @ExternalMessageId, @Payload, SYSUTCDATETIME());
END TRY
BEGIN CATCH
    -- 2601 i 2627: naruszenie unikalności, czyli duplikat, ignorujemy
    IF ERROR_NUMBER() NOT IN (2601, 2627) THROW;
END CATCH;

Kolejka wyjątków wymaga właściciela. Operator wyznacza osobę, która co zmianę przegląda odrzucone komunikaty, bo nieobsłużony wyjątek oznacza zamówienie, które klient uważa za przyjęte, a magazyn nawet go nie widział. Licznik komunikatów starszych niż ustalony próg warto wyświetlać na pulpicie kierownika.

Po zapisaniu komunikatu osobny proces sprawdza, czy kod SKU istnieje w kartotece tego klienta i czy ilości są dodatnie. Błędny komunikat trafia do kolejki wyjątków z opisem przyczyny, a nie blokuje pozostałych. Klient dostaje informację zwrotną w tym samym kanale, którego użył.

Raportowanie zgodne z umową SLA

Umowa z klientem zawiera wskaźniki, które operator musi umieć udowodnić. System 3PL liczy je z sygnatur czasu zapisanych przy każdym zdarzeniu, a nie z ręcznych notatek. Wskaźniki definiuje się raz na klienta i publikuje jako raport w SSRS, więc każdy zleceniodawca otrzymuje zestawienie w tym samym układzie. Zarządzanie wskaźnikami całego magazynu opisuje strona o zarządzaniu procesami magazynowania i wskaźnikach KPI.

Próg z umowy przechowuje się w tabeli parametrów klienta. Raport porównuje wynik z progiem i oznacza okresy, w których operator go nie dotrzymał. Wtedy rozmowa z klientem opiera się na liczbach z tego samego źródła, z którego korzysta portal.

Chmura czy instalacja lokalna w modelu 3PL

Nowy klient często oznacza nowy magazyn albo nowy oddział. W modelu chmurowym operator dołącza lokalizację do działającej usługi i nie kupuje serwera, a koszt utrzymania przechodzi na regularny abonament. Porównanie kosztów i skalowania znajduje się w artykule o programie magazynowym w chmurze i modelu on-premise, a porównanie z perspektywy dostawcy - na stronie WMS w chmurze vs on-premise.

W systemie, który przechowuje dane handlowe wielu firm, ważniejsze od modelu wdrożenia są warunki ochrony danych. Operator powinien sprawdzić lokalizację serwerów, harmonogram kopii zapasowych i procedurę odtwarzania. Przydatne są dwa parametry: RPO, czyli największa akceptowalna utrata danych, oraz RTO, czyli czas do przywrócenia usługi. Dostawca podaje je w umowie, a operator przenosi je do umów ze swoimi klientami.

Okna serwisowe wymagają uzgodnienia z klientami. Jedna instalacja obsługuje wszystkich zleceniodawców, więc aktualizacja systemu w środku dnia zatrzymuje pracę każdego z nich. Operator ustala godziny przerw w umowach i ogłasza je w portalu z wyprzedzeniem. Klienci z własnymi integracjami muszą wiedzieć, że w tym czasie ich komunikaty trafią do kolejki i zostaną przetworzone po wznowieniu usługi.

Ostrzeżenie: kopia zapasowa, której odtworzenia nie przetestowano, nie jest zabezpieczeniem. Próbne odtworzenie bazy w osobnym środowisku warto wpisać do harmonogramu, a nie zostawiać na dzień awarii.

Kryteria wyboru systemu dla operatora 3PL

Przy wyborze programu dla operatora warto sprawdzać zachowanie systemu w sytuacjach granicznych, a nie liczbę pozycji w menu. Ekran przyjęcia wygląda podobnie w większości programów. Różnice ujawniają się przy pytaniu, co się stanie, gdy dwóch klientów ma ten sam kod SKU, gdy cennik zmienia się w połowie miesiąca albo gdy klient żąda historii ruchów sprzed roku.

Dobrą praktyką jest próba na własnych danych. Operator ładuje do wersji demonstracyjnej kartoteki dwóch prawdziwych klientów, wprowadza kilka przyjęć i wydań, a następnie prosi o raport rozliczeniowy. Wynik pokazuje więcej niż prezentacja, bo ujawnia sposób obsługi wyjątków, którego nie widać na przygotowanym scenariuszu.

Osobną kwestią jest zależność od dostawcy. Jeżeli aplikacja pozwala eksportować kartoteki i historię ruchów do plików, operator zachowuje możliwość zmiany systemu. Warto zapytać o taki eksport przed podpisaniem umowy, a nie w chwili, gdy relacja z dostawcą się pogorszy.

Dołączenie nowego klienta i wdrożenie systemu

Wdrożenie WMS u operatora obejmuje dwa różne zadania. Pierwsze to uruchomienie systemu w firmie. Drugie powtarza się przy każdym nowym zleceniodawcy: konfiguracja kartotek i cennika, a następnie uprawnień i integracji. Dobrze przygotowany system skraca to drugie zadanie do wypełnienia szablonu ustawień. Przebieg projektu opisuje strona o wdrożeniu systemu WMS.

1. Analiza przedwdrożeniowa - lista klientów z wolumenami oraz wskaźniki z umów; integracje opisuje się w osobnym kroku.
2. Konfiguracja właścicieli i cenników - strefy i lokalizacje oraz kody usług ze stawkami dla każdego klienta.
3. Integracje i migracja danych - podłączenie kanałów EDI oraz API i przeniesienie kartotek z testem na danych rzeczywistych.
4. Szkolenia i uruchomienie - praca magazynierów i brygadzistów oraz obsługi klienta w nowym systemie, a potem start produkcyjny z opieką dostawcy.

Standardowe wdrożenie Studio WMS.net trwa od 4 do 12 tygodni, zależnie od liczby magazynów i klientów oraz stopnia integracji z ich systemami ERP. Szczegóły funkcji programu przedstawia strona systemu zarządzania magazynem WMS, a ogólną definicję pojęcia - artykuł o Warehouse Management System.