Szablon danych do zarządzania magazynem
Szablon danych do zarządzania magazynem
- Zalecane atrybuty do zebrania
- Czynności do śledzenia w operacjach magazynowych
- Wskazówki dotyczące ekstrakcji danych z Körber WMS
Atrybuty zarządzania magazynem
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładna data i godzina zapisania czynności lub zdarzenia w systemie źródłowym. | ||
| Opis Czas zdarzenia to znacznik czasu przypisany do każdej czynności, wskazujący dokładny moment jej wystąpienia. Te dane czasowe są niezbędne do obliczania czasu trwania procesu, czasu realizacji i oczekiwania między jego etapami. W analizie procesów ten atrybut służy do uporządkowania zdarzeń chronologicznie, odtworzenia przebiegu procesu i przeprowadzania analiz czasowych. Jest niezbędny w dashboardach mierzących wyniki, na przykład analizujących czas realizacji, oraz przy obliczaniu KPI, takich jak „Średni całkowity czas realizacji zlecenia”. Dlaczego to ważne Ten znacznik czasu pozwala uporządkować zdarzenia, obliczać miary czasowe, takie jak czas realizacji i oczekiwania, oraz oceniać wyniki procesu. Skąd pobrać Dostępny we wszystkich tabelach transakcji i dziennika zdarzeń w Körber WMS, zwykle pod nazwą taką jak „CreationDate”, „Timestamp” lub „EventDateTime”. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T08:15:00Z | |||
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w danym momencie cyklu życia zlecenia magazynowego. | ||
| Opis Ten atrybut opisuje pojedynczy etap procesu zarządzania magazynem, na przykład „Pobranie towaru z miejsca składowania” lub „Wysłanie dostawy”. Każda czynność oznacza odrębne zdarzenie biznesowe zapisane w systemie i powiązane z konkretnym znacznikiem czasu. Analiza czynności stanowi podstawę process mining. Pozwala zbudować mapę procesu i zobaczyć rzeczywisty przepływ pracy w magazynie. Ułatwia wykrywanie wąskich gardeł, powtarzanych prac i odstępstw od standardowych procedur. Dlaczego to ważne Określa etapy procesu, stanowi podstawę mapy procesu i umożliwia analizę jego przebiegu, wariantów oraz wąskich gardeł. Skąd pobrać Tabele dziennika zdarzeń lub transakcji w Körber WMS, w których zapisywane są zdarzenia biznesowe. Dane często pochodzą z kodów transakcji lub opisów zmian statusu. Przykłady Utworzenie zadania kompletacjiZakończenie pakowania towaruWysłanie dostawyZlecenie magazynowe anulowane | |||
| Zlecenie magazynowe WarehouseOrder | Unikalny identyfikator zlecenia magazynowego, używany jako główny identyfikator case do śledzenia wszystkich powiązanych operacji logistycznych. | ||
| Opis Zlecenie magazynowe to główny identyfikator grupujący wszystkie zadania i zdarzenia związane z konkretnym zapotrzebowaniem logistycznym, na przykład przyjęciem dostawy lub wysyłką. Umożliwia śledzenie całego cyklu życia zlecenia w magazynie, od jego utworzenia po wysyłkę lub anulowanie. W process mining analiza według zlecenia magazynowego pozwala zobaczyć przebieg procesu dla każdego zlecenia. Ułatwia to wykrywanie typowych ścieżek, odstępstw, wąskich gardeł oraz całkowitego czasu realizacji różnych rodzajów zleceń, na przykład standardowych i przyspieszonych. Dlaczego to ważne To podstawowy identyfikator case, który łączy wszystkie powiązane zdarzenia i umożliwia pełną analizę procesu zarządzania magazynem dla każdego zlecenia. Skąd pobrać Ten identyfikator znajduje się zwykle w głównych tabelach zarządzania zleceniami w Körber WMS. Szczegółowych nazw tabel i pól, na przykład nagłówków zleceń, należy szukać w dokumentacji Körber WMS. Przykłady WO-0012845WO-0012991WO-0013402 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane dotyczące tego procesu. | ||
| Opis Ten atrybut określa datę i godzinę ostatniego pobrania lub aktualizacji danych. Informuje, jak aktualne są analizowane dane i pozwala ocenić, na ile bieżący jest obraz procesu. W dashboardach i raportach ta informacja zapewnia przejrzystość. Pozwala ustalić, czy dane są bieżące, dzienne czy tygodniowe, co ma wpływ na podejmowane decyzje. Dlaczego to ważne Informuje o aktualności danych, co pozwala podejmować trafne decyzje biznesowe na podstawie analizy. Skąd pobrać Wartość jest generowana i zapisywana przez potok danych lub narzędzie ETL po każdym odświeżeniu danych. Przykłady 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| System źródłowy SourceSystem | System, z którego pobrano dane. | ||
| Opis Ten atrybut wskazuje system źródłowy danych o zdarzeniach, w tym przypadku „Körber WMS”. W środowiskach z wieloma zintegrowanymi systemami pole to pomaga rozróżniać źródła danych i śledzić ich pochodzenie. Podczas analizy dostarcza kontekstu, zwłaszcza gdy łączone są dane z kilku systemów. Pomaga kontrolować jakość danych i umożliwia ograniczenie analizy do czynności z wybranego systemu. Dlaczego to ważne Informuje o pochodzeniu danych i ułatwia ich weryfikację, szczególnie w środowiskach z wieloma połączonymi systemami. Skąd pobrać Zwykle jest to stała wartość dodawana podczas pobierania danych w celu wskazania systemu źródłowego. Przykłady Körber WMSKörberOne | |||
| Identyfikator użytkownika/operatora UserOperatorId | Identyfikator użytkownika lub operatora, który wykonał daną czynność. | ||
| Opis Ten atrybut wskazuje pracownika magazynu lub użytkownika systemu odpowiedzialnego za wykonanie konkretnego zadania, na przykład kompletacji, pakowania lub odkładania towaru. W niektórych przypadkach może też oznaczać system automatyczny lub bota. Ten wymiar służy do analizy wyników pracy zasobów. Pomaga ocenić rozkład obciążenia, wskazać pracowników osiągających najlepsze wyniki i wykryć osoby, które mogą potrzebować dodatkowego szkolenia. Stanowi podstawę dashboardu „Wykorzystanie zasobów i obciążenie pracą” oraz KPI „Wydajność na operatora”. Dlaczego to ważne Umożliwia analizę wyników pracy, rozkładu obciążenia i efektywności zasobów, a także pomaga określić potrzeby szkoleniowe i wskazać osoby osiągające najlepsze wyniki. Skąd pobrać Dostępny w tabelach transakcji lub dziennika, w których zapisywane są działania użytkowników. Warto szukać pól takich jak „UserID”, „UserName”, „ExecutedBy” lub „OperatorID”. Przykłady JSMITHABOT01CDAVISsystem | |||
| Ilość rzeczywista ActualQuantity | Ilość towaru faktycznie obsłużonego lub zarejestrowanego podczas zadania. | ||
| Opis Ilość rzeczywista to liczba sztuk fizycznie policzonych, skompletowanych, spakowanych lub przyjętych przez pracownika magazynu. Wartość jest zapisywana po zakończeniu zadania i może różnić się od „Ilości planowanej” z powodu braków w zapasach, uszkodzeń lub błędu ludzkiego. Porównanie tej wartości z „Ilością planowaną” stanowi podstawę dashboardu „Stan i dokładność procesu magazynowego”. Rozbieżności między tymi wartościami bezpośrednio wskazują na błędy procesu lub nieprawidłowe dane, które wymagają sprawdzenia. Dlaczego to ważne Pokazuje, ile towaru faktycznie obsłużono. Jest niezbędna do obliczania odsetka rozbieżności i kontroli zgodności stanów magazynowych. Skąd pobrać Dostępna w potwierdzeniach transakcji lub zapisach zakończenia zadań. Pole może nazywać się „ActualQty”, „ConfirmedQuantity” lub „PickedQuantity”. Przykłady 10491 | |||
| Poziom priorytetu PriorityLevel | Określa pilność lub priorytet zlecenia magazynowego, na przykład standardowy lub przyspieszony. | ||
| Opis Poziom priorytetu określa pilność obsługi zlecenia magazynowego. Zlecenie może być na przykład oznaczone jako „Przyspieszone” lub „Wysoki priorytet”, co oznacza, że należy je obsłużyć przed zleceniami standardowymi. Ten atrybut jest potrzebny do dashboardu „Analiza zleceń przyspieszonych” i KPI „Odsetek przyspieszonych wysyłek”. Pomaga ocenić wpływ pilnych zleceń na pracę magazynu i związane z nimi koszty, a także sprawdzić, czy są realizowane szybciej niż zlecenia standardowe. Dlaczego to ważne Pomaga analizować obsługę pilnych zleceń, ich częstotliwość oraz wpływ na wyniki procesu i koszty. Skąd pobrać Dostępny w danych nagłówka zlecenia. Warto szukać pól takich jak „Priority”, „Urgency” lub wskaźnika poziomu usługi wysyłkowej. Przykłady StandardowyPrzyspieszonyNocnyKrytyczny | |||
| SKU produktu ProductSKU | Jednostka magazynowa (SKU) lub numer materiału obsługiwanego towaru. | ||
| Opis SKU produktu to unikalny identyfikator konkretnego produktu lub materiału powiązanego ze zleceniem magazynowym. Zlecenie może obejmować jedno lub więcej SKU. Analiza według SKU produktu pomaga ustalić, czy obsługa niektórych produktów jest bardziej złożona lub problematyczna. Można na przykład wykryć, że pakowanie towarów delikatnych trwa dłużej albo że przy określonych SKU częściej występują błędy kompletacji. Takie informacje mogą pomóc zmienić sposób składowania lub procedury obsługi. Dlaczego to ważne Pozwala analizować wyniki procesu dla konkretnych produktów i wykrywać towary powodujące opóźnienia lub błędy. Skąd pobrać Dostępny w tabelach pozycji zlecenia, powiązanych z głównym nagłówkiem zlecenia magazynowego. Typowe nazwy pól to „SKU”, „MaterialNumber” lub „ItemCode”. Przykłady SKU-847361SKU-991204SKU-103557 | |||
| Czas realizacji CycleTime | Całkowity czas od utworzenia do zakończenia zlecenia magazynowego. | ||
| Opis Czas realizacji to obliczana miara całkowitego czasu trwania case, od pierwszego zdarzenia („Zlecenie magazynowe utworzone”) do ostatniego („Zlecenie magazynowe zakończone”). Pokazuje całkowity czas obsługi zlecenia. To podstawowy KPI w process mining, który odpowiada na pytanie: „Ile to trwa?”. Jest główną miarą dashboardu „Całkowity czas realizacji zlecenia magazynowego” i KPI „Średni całkowity czas realizacji zlecenia”. Pozwala śledzić ogólny stan procesu i wykrywać zlecenia, których realizacja trwa nietypowo długo. Dlaczego to ważne Ten KPI mierzy ogólną efektywność procesu magazynowego, która bezpośrednio wpływa na zadowolenie klientów i koszty operacyjne. Skąd pobrać Miara jest obliczana w narzędziu process mining jako różnica między znacznikami czasu ostatniego i pierwszego zdarzenia dla każdego zlecenia magazynowego. Przykłady 8640017280036000 | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy czynność została zakończona, jeśli ta informacja jest dostępna. | ||
| Opis Czas zakończenia to znacznik czasu zakończenia czynności. Czas rozpoczęcia (EventTime) wskazuje jej początek, a czas zakończenia pozwala bezpośrednio obliczyć czas trwania danej czynności. Nie każde zdarzenie ma osobny czas zakończenia. W wielu przypadkach czas rozpoczęcia kolejnego zdarzenia służy do oszacowania czasu trwania poprzedniego. Ten atrybut pozwala dokładnie obliczać czas realizacji poszczególnych zadań. Można na przykład wyznaczyć „Średni czas kontroli jakości”, mierząc czas od rozpoczęcia do zakończenia kontroli. Dlaczego to ważne Umożliwia dokładne obliczenie czasu realizacji poszczególnych czynności, co pomaga wykrywać nieefektywne zadania i wąskie gardła związane z zasobami. Skąd pobrać Szczegółowych informacji należy szukać w dokumentacji Körber WMS. Dane mogą znajdować się w tabelach transakcji obok czasu rozpoczęcia lub w powiązanych tabelach historii statusów. Przykłady 2023-10-26T10:15:00Z2023-10-26T11:45:20Z2023-10-27T08:30:00Z | |||
| Czy wystąpiła rozbieżność w kompletacji IsPickingDiscrepancy | Wskaźnik informujący, czy rzeczywista ilość skompletowanego towaru była zgodna z ilością planowaną. | ||
| Opis To wyliczany atrybut logiczny, który przyjmuje wartość true, jeśli „Ilość rzeczywista” różni się od „Ilości planowanej” w dowolnej czynności związanej z kompletacją. Jest prostym wskaźnikiem błędu kompletacji lub problemu z zapasami w ramach konkretnego zadania. Wskaźnik ułatwia analizę, ponieważ pozwala szybko filtrować zlecenia, w których wystąpiła rozbieżność w kompletacji. Służy do obliczania KPI „Odsetek rozbieżności w kompletacji” i pomaga zasilać dashboard „Stan i dokładność procesu magazynowego”, wskazując miejsca występowania błędów. Dlaczego to ważne Zapewnia prosty, jednoznaczny wskaźnik błędów kompletacji, ułatwiając wykrywanie i ocenę problemów z dokładnością stanów magazynowych. Skąd pobrać Obliczany podczas transformacji danych. Logika: Przykłady truefalse | |||
| Identyfikator magazynu WarehouseId | Unikalny identyfikator magazynu lub centrum dystrybucyjnego, w którym odbywają się czynności. | ||
| Opis Identyfikator magazynu wskazuje fizyczną lokalizację lub obiekt, w którym realizowane jest zlecenie magazynowe. W organizacjach z kilkoma centrami dystrybucyjnymi jest to ważny wymiar analizy. Atrybut ten pozwala porównywać wyniki różnych lokalizacji. Można na przykład zestawić „Średni całkowity czas realizacji zlecenia” w magazynie A i magazynie B, aby znaleźć dobre praktyki lub problemy operacyjne charakterystyczne dla danej lokalizacji. Dlaczego to ważne Umożliwia porównywanie wyników różnych magazynów i wskazywanie problemów charakterystycznych dla danego regionu lub obiektu. Skąd pobrać Informacje te są zwykle dostępne w tabelach nagłówków zleceń lub konfiguracji lokalizacji. Pole może nazywać się „Plant”, „Site” lub „LocationCode”. Przykłady WH-NYCDC-LAXFC-DAL | |||
| Lokalizacja składowania StorageLocation | Konkretne miejsce w magazynie, na przykład regał lub alejka, w którym składowane są towary lub z którego są pobierane. | ||
| Opis Ten atrybut wskazuje fizyczne miejsce w magazynie, na przykład regał, półkę lub pojemnik. Ma znaczenie przy czynnościach takich jak „Odłożenie towaru na miejsce” i „Pobranie towaru z miejsca składowania”. Dane te są wykorzystywane w dashboardzie „Efektywność odkładania i wykorzystanie lokalizacji” do analizy czasu przemieszczania, wykorzystania miejsc i skuteczności strategii składowania. Można na przykład sprawdzić, czy towary o dużej rotacji znajdują się w łatwo dostępnych miejscach, co skraca czas kompletacji. Dlaczego to ważne Pomaga usprawniać układ magazynu i sposób składowania dzięki analizie czasu przemieszczania oraz efektywności odkładania i kompletacji w poszczególnych lokalizacjach. Skąd pobrać Dostępna w tabelach zapasów, zadań lub danych podstawowych lokalizacji. Warto szukać pól takich jak „BinCode”, „LocationID” lub „StorageBin”. Przykłady A1-R02-S03-B01B5-R10-S01-B04C2-BULK-05 | |||
| Planowana ilość PlannedQuantity | Ilość towaru, której obsługi oczekiwano w ramach zadania, na przykład kompletacji lub przyjęcia. | ||
| Opis Planowana ilość to docelowa liczba sztuk określona w zleceniu magazynowym dla danego zadania. Jeśli na przykład zlecenie wymaga skompletowania 10 sztuk danego SKU, planowana ilość dla tego zadania wynosi 10. Ten atrybut pomaga wykrywać rozbieżności w porównaniu z „Ilością rzeczywistą”. Jest podstawą do obliczania KPI „Odsetek rozbieżności w kompletacji” i „Odsetek rozbieżności w zapasach”, które pomagają utrzymać zgodność stanów magazynowych. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie dokładności kompletacji i przyjęć oraz pomaga wykrywać rozbieżności w zapasach. Skąd pobrać Dostępna w tabelach zadań lub pozycji zlecenia. Warto szukać pól takich jak „OrderQuantity”, „PlannedQty” lub „ExpectedQuantity”. Przykłady 10501 | |||
| Przewoźnik Carrier | Przewoźnik odpowiedzialny za dostarczenie zlecenia do miejsca docelowego. | ||
| Opis Przewoźnik to zewnętrzny dostawca usług logistycznych, na przykład FedEx, UPS lub DHL, który transportuje towary z magazynu do miejsca docelowego. Zwykle jest przypisywany podczas planowania wysyłki lub jej realizacji. Analiza według przewoźnika może ujawnić różnice w wynikach partnerów transportowych. Można na przykład sprawdzić, czy współpraca z niektórymi przewoźnikami wiąże się z dłuższym oczekiwaniem w strefie buforowej lub częstszymi opóźnieniami. Dane te mogą pomóc w wyborze przewoźnika i negocjowaniu umów. Dlaczego to ważne Umożliwia porównanie wyników różnych przewoźników, co pomaga usprawniać logistykę i zwiększać niezawodność dostaw. Skąd pobrać Dostępny w tabelach wysyłek lub planowania transportu w Körber WMS. Warto szukać pól takich jak „CarrierCode”, „ShippingAgent” lub „SCAC”. Przykłady FedExUPSDHLLocal Freight Inc. | |||
| Status SLA SLAStatus | Informuje, czy zlecenie zakończono terminowo, z opóźnieniem, czy nadal jest realizowane, na podstawie wymaganej daty zakończenia. | ||
| Opis Status SLA to obliczany atrybut, który klasyfikuje każde zlecenie według terminowości względem pola „RequestedCompletionDate”. Może przyjmować wartości takie jak „Terminowo”, „Z opóźnieniem” lub „W trakcie”. Atrybut ten pozwala szybko ocenić poziom realizacji usług. Ułatwia filtrowanie i analizę opóźnionych zleceń oraz ustalanie ich przyczyn, takich jak konkretne wąskie gardła lub problemy z zasobami. Jest przydatny w analizach dotyczących zadowolenia klientów i niezawodności operacji. Dlaczego to ważne Bezpośrednio mierzy realizację umów SLA i ułatwia wykrywanie opóźnionych zleceń oraz ustalanie ich przyczyn. Skąd pobrać Obliczany podczas transformacji danych przez porównanie znacznika czasu zdarzenia „Zlecenie magazynowe zakończone” z wartością „RequestedCompletionDate”. Przykłady TerminowoZ opóźnieniemW trakcie | |||
| Typ zlecenia OrderType | Określa rodzaj zlecenia magazynowego, na przykład przyjęcie, wysyłkę lub przesunięcie wewnętrzne. | ||
| Opis Typ zlecenia określa cel biznesowy zlecenia magazynowego. Typowe rodzaje to wysyłki do klientów (wyjściowe), przyjęcia od dostawców (wejściowe), przesunięcia zapasów między lokalizacjami magazynowymi (wewnętrzne) oraz zwroty. Ten atrybut ułatwia filtrowanie i porównywanie danych. Pozwala analizować przebieg i wyniki różnych operacji logistycznych, na przykład sprawdzić, czy proces przyjęcia jest mniej lub bardziej efektywny niż proces wysyłki. Dlaczego to ważne Pozwala podzielić analizę według celu zlecenia i porównać wyniki procesów, takich jak przyjęcia dostaw i wysyłki. Skąd pobrać Zwykle znajduje się w tabeli nagłówków zleceń w Körber WMS. Warto szukać pola „OrderType”, „TransactionType” lub podobnego. Przykłady Wysyłka wychodzącaPrzyjęcie dostawyPrzesunięcie wewnętrzneZwrot od klienta | |||
| Używany sprzęt EquipmentUsed | Identyfikator sprzętu używanego do wykonania zadania, na przykład wózka widłowego lub skanera. | ||
| Opis Ten atrybut wskazuje sprzęt do transportu materiałów (MHE) lub technologię wykorzystywaną podczas zadania magazynowego. Może to być konkretny wózek widłowy, wózek paletowy, skaner ręczny lub autonomiczny pojazd transportowy (AGV). Analiza według sprzętu pomaga ocenić wykorzystanie zasobów, potrzeby konserwacyjne i wpływ różnych urządzeń na efektywność zadań. Jest to ważny wymiar dashboardu „Wykorzystanie zasobów i obciążenie pracą”, który pokazuje zarówno zasoby ludzkie, jak i sprzęt. Dlaczego to ważne Umożliwia analizę wykorzystania sprzętu i jego wpływu na wyniki zadań, co pomaga lepiej zarządzać flotą i wykrywać wąskie gardła związane z urządzeniami. Skąd pobrać Szczegółowych informacji należy szukać w dokumentacji Körber WMS. Dane mogą być zapisywane w rejestrach wykonania zadań, zwłaszcza gdy operatorzy logują się na konkretnym urządzeniu. Przykłady FORKLIFT-08SCANNER-112AGV-03 | |||
| Wymagana data zakończenia RequestedCompletionDate | Data, do której klient lub wewnętrzny interesariusz oczekuje zakończenia zlecenia. | ||
| Opis To planowana data zakończenia lub wysyłki zlecenia wychodzącego, często wynikająca z oczekiwań klienta lub umów SLA. Stanowi główny termin odniesienia przy ocenie rzeczywistych wyników. Data ta jest potrzebna do dashboardu „Analiza zleceń przyspieszonych”. Porównanie „Wymaganej daty zakończenia” z „Rzeczywistą datą zakończenia” (znacznikiem czasu czynności „Wysłanie dostawy” lub „Zlecenie magazynowe zakończone”) pozwala ocenić terminowość i wykryć zlecenia zagrożone opóźnieniem. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie terminowości i realizacji umów SLA oraz pomaga wykrywać zlecenia zagrożone opóźnieniem. Skąd pobrać Dostępna w tabeli nagłówków zleceń. Typowe nazwy pól to „RequiredDeliveryDate”, „RequestedShipDate” lub „SLA”. Przykłady 2023-10-28T23:59:59Z2023-11-05T23:59:59Z | |||
Czynności w zarządzaniu magazynem
| Działanie | Opis | ||
|---|---|---|---|
| Odłożenie towaru na miejsce składowania | Operator potwierdza wykonanie zadania, zwykle skanując miejsce składowania oraz paletę lub produkt. Działanie rejestruje przemieszczenie i aktualizuje lokalizację zapasów w systemie. | ||
| Dlaczego to ważne Ten ważny etap kończy proces przyjęcia towaru. Służy do obliczania KPI „czasu odkładania na miejsce” oraz „czasu od przyjęcia towaru do odłożenia na miejsce”. Skąd pobrać Zdarzenie jest rejestrowane, gdy operator potwierdza wykonanie zadania za pomocą urządzenia RF. Status zadania zmienia się na „Completed” i zapisywany jest timestamp zakończenia. Rejestrowanie Timestamp z transakcji potwierdzającej odłożenie towaru na miejsce. Typ zdarzenia explicit | |||
| Pobranie towaru z miejsca składowania | Operator potwierdza pobranie produktów do zamówienia z miejsca składowania. Zwykle skanuje produkt i lokalizację, co zmniejsza stan zapasów w danym miejscu i rejestruje działanie. | ||
| Dlaczego to ważne To ważny etap procesu realizacji zamówienia wychodzącego. Umożliwia analizę czasu kompletacji i wykrywanie potencjalnych opóźnień między kompletacją a pakowaniem. Skąd pobrać Zdarzenie jest rejestrowane, gdy operator potwierdza zakończenie zadania kompletacji za pomocą urządzenia RF. Status zadania zmienia się na „Completed” i zapisywany jest timestamp zakończenia. Rejestrowanie Timestamp z transakcji potwierdzającej zadanie kompletacji. Typ zdarzenia explicit | |||
| Przyjęcie i przeliczenie towaru | Pracownicy magazynu rozładowują, skanują i przeliczają przyjęte produkty, porównując je z powiadomieniem o dostawie. Ta jawnie rejestrowana transakcja potwierdza przyjęcie określonych ilości materiałów do magazynu. | ||
| Dlaczego to ważne To ważny etap przyjęcia towaru, który umożliwia obliczanie KPI, takich jak „czas od przyjęcia towaru do odłożenia na miejsce”. Pomaga też wcześnie wykryć rozbieżności między oczekiwaną a przyjętą ilością. Skąd pobrać Zdarzenie jest rejestrowane, gdy użytkownik potwierdza przyjęte ilości za pomocą skanera RF lub transakcji na komputerze. Działanie zmienia status zapasów na „Received” lub „On-Hand” w lokalizacji buforowej. Rejestrowanie Timestamp z transakcji potwierdzającej przyjęcie. Typ zdarzenia explicit | |||
| Utworzenie zamówienia magazynowego | Utworzenie w systemie zamówienia magazynowego, które oznacza zapotrzebowanie na przemieszczenie towarów. Zdarzenie jest zwykle rejestrowane w chwili, gdy użytkownik lub zintegrowany system, taki jak ERP, zapisuje zamówienie wraz z timestampem utworzenia. | ||
| Dlaczego to ważne To początek procesu realizowanego od początku do końca. Zdarzenie jest niezbędne do pomiaru całkowitego czasu realizacji zamówienia oraz analizy popytu i liczby zamówień. Skąd pobrać Informacja pochodzi z timestampu utworzenia w głównej tabeli nagłówków zamówień magazynowych, zapisywanego po dodaniu nowego zamówienia w Körber WMS. Rejestrowanie Zapis z timestampu utworzenia w nagłówku zamówienia magazynowego. Typ zdarzenia explicit | |||
| Wysłanie dostawy | Towar zostaje załadowany, a ciężarówka opuszcza magazyn. Zdarzenie jest wywoływane przez transakcję „Ship Confirm” lub „Post Goods Issue”, która finalizuje wysyłkę w systemie. | ||
| Dlaczego to ważne Ten ważny etap oznacza fizyczne opuszczenie magazynu przez towary. Często stanowi podstawę do wystawienia faktury i poinformowania klienta. Skąd pobrać Wykonywana jest jawna transakcja „Ship Confirm”, powiązana z drukowaniem listu przewozowego. Transakcja ma przypisany konkretny znacznik czasu. Rejestrowanie Znacznik czasu transakcji „Ship Confirm” lub „Post Goods Issue”. Typ zdarzenia explicit | |||
| Zakończenie pakowania towaru | Pakowanie pojemnika lub kartonu wysyłkowego zostaje zakończone, a paczka jest zamykana i oznaczana etykietą. Zdarzenie oznacza, że zamówienie jest gotowe do przekazania do strefy wysyłki i wysłania, i jest jawnie rejestrowane. | ||
| Dlaczego to ważne Ten ważny etap kończy przygotowanie towaru do wysyłki. Służy do obliczania przepustowości pakowania i wykrywania opóźnień przed załadunkiem. Skąd pobrać Operator wykonuje jawną transakcję „Packing Complete” lub „Close Carton”, która zapisuje timestamp zakończenia pakowania pojemnika wysyłkowego. Rejestrowanie Timestamp z transakcji „Close Container” lub „Packing Complete”. Typ zdarzenia explicit | |||
| Zlecenie magazynowe zakończone | Zlecenie magazynowe zostaje zamknięte w systemie, co oznacza zakończenie wszystkich powiązanych przemieszczeń fizycznych i transakcji. Zwykle można to ustalić na podstawie zmiany statusu w nagłówku zlecenia, która kończy jego cykl życia. | ||
| Dlaczego to ważne To główny punkt końcowy procesu. Jest niezbędny do obliczenia całkowitego czasu realizacji i odsetka zleceń zakończonych. Skąd pobrać Ustalane na podstawie zmiany statusu w nagłówku zlecenia magazynowego na końcowy, na przykład „Complete” lub „Closed”. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu w nagłówku zlecenia magazynowego na „Completed”. Typ zdarzenia inferred | |||
| Otrzymanie powiadomienia o dostawie przychodzącej | Od dostawcy przychodzi awizo wysyłki (ASN) lub powiadomienie o dostawie przychodzącej. Zdarzenie informuje o planowanym terminie dostawy i pozwala zaplanować przyjęcie towaru. Zwykle jest rejestrowane za pomocą komunikatu EDI lub ręcznie. | ||
| Dlaczego to ważne To działanie rozpoczyna planowanie dostawy przychodzącej. Analiza czasu między otrzymaniem powiadomienia a przyjazdem towaru pomaga ocenić terminowość dostawcy i zaplanować pracę personelu. Skąd pobrać Dane pochodzą z timestampu utworzenia awiza ASN lub rekordu dostawy przychodzącej, który często powstaje za pośrednictwem interfejsu EDI lub jest wprowadzany ręcznie. Rejestrowanie Rejestrowane po pomyślnym utworzeniu rekordu ASN w systemie. Typ zdarzenia explicit | |||
| Przekazanie do strefy wysyłki | Zapakowane kartony lub palety są przenoszone ze strefy pakowania do wyznaczonego pasa odkładczego, gdzie czekają na odbiór przez przewoźnika. Zdarzenie to często jest wnioskowane na podstawie timestampu transakcji przesunięcia zapasów do lokalizacji wysyłkowej. | ||
| Dlaczego to ważne Pozwala analizować czas oczekiwania między pakowaniem a wysyłką. Długi czas w strefie wysyłki może wskazywać na słabą koordynację z przewoźnikami lub nieefektywne zarządzanie dokami. Skąd pobrać Wnioskowane na podstawie zmiany lokalizacji jednostki ładunkowej z obszaru roboczego pakowania na pas wysyłkowy. Transakcja przemieszczenia zawiera wymagany timestamp. Rejestrowanie Wnioskowane na podstawie timestampu transakcji przesunięcia zapasów do lokalizacji docelowej w strefie wysyłki. Typ zdarzenia inferred | |||
| Przeprowadzenie kontroli jakości | Przyjęty towar przechodzi kontrolę jakości, która może wymagać przeniesienia go do wyznaczonej strefy kontroli. Działanie to często jest wnioskowane na podstawie zmian statusu zapasów, na przykład z „On-Hand” na „QI Hold”, a następnie na „Unrestricted”. | ||
| Dlaczego to ważne Umożliwia analizę czasu kontroli jakości, która może być znaczącym wąskim gardłem. Pomaga śledzić liczbę kontroli i wykrywać opóźnienia w udostępnianiu zapasów. Skąd pobrać Można je wywnioskować z serii zmian statusu zapasów związanych z blokadą jakościową. Niektóre systemy rejestrują osobne dzienniki transakcji zarządzania jakością. Rejestrowanie Wnioskowane na podstawie zmian statusu zapasów lub dziennika transakcji powiązanego ze zleceniem kontroli jakości. Typ zdarzenia inferred | |||
| Przyjazd towaru do rampy | Rejestrowany jest fizyczny przyjazd przewoźnika do rampy przyjęć magazynu. Zwykle odnotowuje go pracownik ochrony lub przyjęć. Zdarzenie to rozpoczyna fizyczny proces przyjęcia towaru i często jest wnioskowane na podstawie zmiany statusu dostawy. | ||
| Dlaczego to ważne Zdarzenie pozwala ocenić punktualność przewoźnika i przeanalizować czas oczekiwania przy rampie, a także wykryć potencjalne wąskie gardła przed rozpoczęciem rozładunku. Skąd pobrać Zwykle rejestrowane jako aktualizacja statusu dostawy przychodzącej lub za pomocą specjalnej transakcji „Check-In” w module zarządzania placem, jeśli jest dostępny. Rejestrowanie Wnioskowane na podstawie zmiany statusu dostawy przychodzącej na „Arrived” lub „At Dock”. Typ zdarzenia inferred | |||
| Rozpoczęcie pakowania | Skompletowane produkty trafiają na stanowisko pakowania, gdzie operator rozpoczyna ich pakowanie. Zdarzenie to często jest wnioskowane na podstawie pierwszego skanu produktu na stanowisku pakowania przypisanego do konkretnego zamówienia wychodzącego. | ||
| Dlaczego to ważne Oznacza początek pakowania. Pomiar czasu oczekiwania przed tym działaniem i czasu samego pakowania pomaga wykryć wąskie gardła w przygotowaniu wysyłki. Skąd pobrać Może być rejestrowane jako osobna transakcja „Start Packing”, ale częściej jest wnioskowane na podstawie pierwszego skanu produktu na stanowisku pakowania dla danego zamówienia. Rejestrowanie Wnioskowane na podstawie timestampu pierwszego działania na stanowisku pakowania dla danego zamówienia. Typ zdarzenia inferred | |||
| Utworzenie zadania kompletacji | Na podstawie wychodzącego zamówienia magazynowego system tworzy dla operatora zadanie kompletacji. Wskazuje ono lokalizację, z której należy pobrać określoną ilość produktu. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna proces realizacji zamówienia wychodzącego. Analiza generowania zadań kompletacji pomaga zrozumieć logikę obsługi zamówień i rozkład obciążenia pracą. Skąd pobrać W tabeli zarządzania zadaniami lub kolejki pracy w Körber WMS tworzony jest rekord typu „Picking” wraz z timestampem utworzenia. Rejestrowanie Zapis z timestampu utworzenia rekordu zadania kompletacji. Typ zdarzenia explicit | |||
| Utworzenie zadania odkładania na miejsce | System WMS tworzy dla operatora zadanie przeniesienia przyjętego towaru ze strefy buforowej do docelowego miejsca składowania. Na podstawie strategii odkładania system wybiera optymalne miejsce dla produktów. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna proces odkładania towaru na miejsce. Analiza czasu od utworzenia zadania do jego zakończenia pozwala ocenić sprawność systemu i operatora. Skąd pobrać W tabeli zarządzania zadaniami lub kolejki pracy tworzony jest rekord z typem zadania „Putaway” i odpowiednim timestampem utworzenia. Rejestrowanie Zapis z timestampu utworzenia rekordu zadania odkładania na miejsce. Typ zdarzenia explicit | |||
| Zlecenie magazynowe anulowane | Zlecenie magazynowe zostaje anulowane przed zakończeniem, co zatrzymuje wszystkie trwające prace. Zwykle można to ustalić na podstawie zmiany statusu w nagłówku zlecenia na „Canceled”. | ||
| Dlaczego to ważne Oznacza alternatywny koniec procesu. Analiza anulowanych zleceń pomaga ustalić przyczyny niepowodzeń, takie jak braki w zapasach lub zmiany po stronie klienta. Skąd pobrać Ustalane na podstawie zmiany statusu w nagłówku zlecenia magazynowego na „Canceled” lub „Deleted” oraz znacznika czasu tej zmiany. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu w nagłówku zlecenia magazynowego na „Canceled”. Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Kroki
- Uzyskaj dostęp do bazy danych: Zdobądź dane logowania tylko do odczytu oraz informacje o połączeniu (nazwę serwera, nazwę bazy danych i port) do produkcyjnej bazy Körber WMS lub jej repliki. Potrzebne będzie narzędzie klienckie, takie jak Microsoft SQL Server Management Studio (SSMS) lub Oracle SQL Developer.
- Znajdź główne tabele: Przed uruchomieniem skryptu skonsultuj się z administratorem systemu, aby potwierdzić dokładne nazwy tabel i kolumn w używanej implementacji Körber WMS, ponieważ mogą się różnić. Zwykle najważniejsze są tabele nagłówków zamówień, zadań i transakcji magazynowych.
- Połącz się z bazą danych: Uruchom klienta SQL i połącz się z bazą Körber WMS przy użyciu otrzymanych danych logowania.
- Wczytaj skrypt SQL: Otwórz nowe okno zapytania i skopiuj cały skrypt SQL z sekcji „query” tego dokumentu.
- Ustaw parametry: Znajdź zmienne zastępcze na początku skryptu. Zastąp
@[StartDate],@[EndDate]i@[WarehouseId]wybranym zakresem dat oraz identyfikatorem magazynu, aby ograniczyć eksport danych. - Uruchom zapytanie: Wykonaj skonfigurowany skrypt SQL. Czas wykonania zależy od zakresu dat i ilości danych w systemie.
- Sprawdź wyniki: Po zakończeniu zapytania sprawdź w kliencie SQL, czy wyniki zawierają wiersze i czy kolumny (
WarehouseOrder,ActivityName,EventTimeitd.) są wypełnione zgodnie z oczekiwaniami. - Wyeksportuj dane do CSV: Wyeksportuj cały zestaw wyników do pliku CSV. Większość klientów SQL ma wbudowaną funkcję bezpośredniego eksportu wyników zapytania.
- Przygotuj plik do przesłania: Zapisz wyeksportowany plik CSV z kodowaniem UTF-8. Sprawdź, czy nagłówki kolumn dokładnie odpowiadają wymaganym nazwom atrybutów, bez dodatkowych spacji ani znaków.
Konfiguracja
- Połączenie z bazą danych: Wymagane jest bezpośrednie połączenie z bazą. Należy podać adres serwera, nazwę bazy danych, prawidłową nazwę użytkownika i hasło. Zaleca się użycie konta tylko do odczytu, aby zapobiec przypadkowej modyfikacji danych.
- Filtrowanie według zakresu dat: Zapytanie wykorzystuje zmienne zastępcze
@StartDatei@EndDatedo określenia okresu ekstrakcji. Na potrzeby wstępnej analizy zaleca się zakres 3–6 miesięcy, który pozwala uchwycić wystarczającą liczbę wariantów procesu bez nadmiernego obciążania bazy. - Filtrowanie według magazynu i zamówienia: Skrypt zawiera zmienną zastępczą
@[WarehouseId], która ogranicza ekstrakcję do wybranego obiektu. W klauzulachWHEREmożna dodać inne filtry, na przykład typ zamówienia lub klienta, aby zawęzić zbiór danych. - Szczegółowość danych: Skrypt pobiera zdarzenia zarówno z poziomu nagłówka zamówienia (np. „Utworzenie zamówienia magazynowego”), jak i szczegółowych zadań lub transakcji (np. „Pobranie towaru”).
- Wymagania wstępne: Potrzebne są uprawnienia do odczytu wszystkich tabel używanych w zapytaniu. Należy znać schemat używanej instancji Körber WMS, aby zweryfikować i w razie potrzeby dostosować nazwy tabel i kolumn.
Przykładowe zapytanie sql
DECLARE @StartDate DATETIME = '2023-01-01';
DECLARE @EndDate DATETIME = '2023-12-31';
DECLARE @WarehouseId NVARCHAR(10) = '[Your Warehouse ID]';
-- 1. Warehouse Order Created
SELECT
ord.ORD_NBR AS WarehouseOrder,
'Warehouse Order Created' AS ActivityName,
ord.CREATE_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ord.CREATE_USER AS UserOperatorId,
ord.PRIORITY AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [ORD_HDR] ord
WHERE ord.CREATE_DATE BETWEEN @StartDate AND @EndDate AND ord.WH_ID = @WarehouseId
UNION ALL
-- 2. Inbound Delivery Notification Rcvd
SELECT
asn.ASN_NBR AS WarehouseOrder,
'Inbound Delivery Notification Rcvd' AS ActivityName,
asn.CREATE_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
asn.CREATE_USER AS UserOperatorId,
asn.PRIORITY AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [ASN_HDR] asn
WHERE asn.CREATE_DATE BETWEEN @StartDate AND @EndDate AND asn.WH_ID = @WarehouseId
UNION ALL
-- 3. Goods Arrived at Dock
SELECT
asn.ASN_NBR AS WarehouseOrder,
'Goods Arrived at Dock' AS ActivityName,
asn.ACTUAL_ARRIVAL_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
asn.MOD_USER AS UserOperatorId,
asn.PRIORITY AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [ASN_HDR] asn
WHERE asn.ACTUAL_ARRIVAL_TSTMP IS NOT NULL AND asn.ACTUAL_ARRIVAL_TSTMP BETWEEN @StartDate AND @EndDate AND asn.WH_ID = @WarehouseId
UNION ALL
-- 4. Goods Received and Counted
SELECT
tran.ORD_NBR AS WarehouseOrder,
'Goods Received and Counted' AS ActivityName,
tran.TRAN_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tran.USER_ID AS UserOperatorId,
NULL AS PriorityLevel,
tran.SKU AS ProductSKU,
tran.TRAN_QTY AS ActualQuantity
FROM [INV_TRAN] tran
WHERE tran.TRAN_TYPE = 'RECV' AND tran.TRAN_TSTMP BETWEEN @StartDate AND @EndDate AND tran.WH_ID = @WarehouseId
UNION ALL
-- 5. Quality Inspection Performed
SELECT
tran.ORD_NBR AS WarehouseOrder,
'Quality Inspection Performed' AS ActivityName,
tran.TRAN_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tran.USER_ID AS UserOperatorId,
NULL AS PriorityLevel,
tran.SKU AS ProductSKU,
tran.TRAN_QTY AS ActualQuantity
FROM [INV_TRAN] tran
WHERE tran.TRAN_TYPE = 'MOVE' AND tran.REASON_CODE = 'QI_INSP' AND tran.TRAN_TSTMP BETWEEN @StartDate AND @EndDate AND tran.WH_ID = @WarehouseId
UNION ALL
-- 6. Putaway Task Created
SELECT
tsk.ORD_NBR AS WarehouseOrder,
'Putaway Task Created' AS ActivityName,
tsk.CREATE_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tsk.CREATE_USER AS UserOperatorId,
tsk.PRIORITY AS PriorityLevel,
tsk.SKU AS ProductSKU,
tsk.TASK_QTY AS ActualQuantity
FROM [TASK_DTL] tsk
WHERE tsk.TASK_TYPE = 'PUTAWAY' AND tsk.CREATE_DATE BETWEEN @StartDate AND @EndDate AND tsk.WH_ID = @WarehouseId
UNION ALL
-- 7. Goods Put Away in Storage
SELECT
tsk.ORD_NBR AS WarehouseOrder,
'Goods Put Away in Storage' AS ActivityName,
tsk.CMPL_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tsk.USER_ID AS UserOperatorId,
tsk.PRIORITY AS PriorityLevel,
tsk.SKU AS ProductSKU,
tsk.CMPL_QTY AS ActualQuantity
FROM [TASK_DTL] tsk
WHERE tsk.TASK_TYPE = 'PUTAWAY' AND tsk.STAT_CODE = 'COMPLETED' AND tsk.CMPL_TSTMP IS NOT NULL AND tsk.CMPL_TSTMP BETWEEN @StartDate AND @EndDate AND tsk.WH_ID = @WarehouseId
UNION ALL
-- 8. Picking Task Created
SELECT
tsk.ORD_NBR AS WarehouseOrder,
'Picking Task Created' AS ActivityName,
tsk.CREATE_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tsk.CREATE_USER AS UserOperatorId,
tsk.PRIORITY AS PriorityLevel,
tsk.SKU AS ProductSKU,
tsk.TASK_QTY AS ActualQuantity
FROM [TASK_DTL] tsk
WHERE tsk.TASK_TYPE = 'PICK' AND tsk.CREATE_DATE BETWEEN @StartDate AND @EndDate AND tsk.WH_ID = @WarehouseId
UNION ALL
-- 9. Goods Picked from Storage
SELECT
tsk.ORD_NBR AS WarehouseOrder,
'Goods Picked from Storage' AS ActivityName,
tsk.CMPL_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tsk.USER_ID AS UserOperatorId,
tsk.PRIORITY AS PriorityLevel,
tsk.SKU AS ProductSKU,
tsk.CMPL_QTY AS ActualQuantity
FROM [TASK_DTL] tsk
WHERE tsk.TASK_TYPE = 'PICK' AND tsk.STAT_CODE = 'COMPLETED' AND tsk.CMPL_TSTMP IS NOT NULL AND tsk.CMPL_TSTMP BETWEEN @StartDate AND @EndDate AND tsk.WH_ID = @WarehouseId
UNION ALL
-- 10. Packing Initiated
SELECT
pck.ORD_NBR AS WarehouseOrder,
'Packing Initiated' AS ActivityName,
MIN(pck.CREATE_DATE) AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
MIN(pck.USER_ID) AS UserOperatorId,
NULL AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [PACK_TRAN] pck
WHERE pck.CREATE_DATE BETWEEN @StartDate AND @EndDate AND pck.WH_ID = @WarehouseId
GROUP BY pck.ORD_NBR
UNION ALL
-- 11. Goods Packed
SELECT
ctn.ORD_NBR AS WarehouseOrder,
'Goods Packed' AS ActivityName,
ctn.PACK_CMPL_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ctn.PACKER_ID AS UserOperatorId,
NULL AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [SHIP_CARTON] ctn
WHERE ctn.PACK_CMPL_TSTMP IS NOT NULL AND ctn.PACK_CMPL_TSTMP BETWEEN @StartDate AND @EndDate AND ctn.WH_ID = @WarehouseId
UNION ALL
-- 12. Staged for Shipment
SELECT
tran.ORD_NBR AS WarehouseOrder,
'Staged for Shipment' AS ActivityName,
tran.TRAN_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
tran.USER_ID AS UserOperatorId,
NULL AS PriorityLevel,
tran.SKU AS ProductSKU,
tran.TRAN_QTY AS ActualQuantity
FROM [INV_TRAN] tran
JOIN [LOC_HDR] loc ON tran.TO_LOC = loc.LOC_ID AND tran.WH_ID = loc.WH_ID
WHERE tran.TRAN_TYPE = 'MOVE' AND loc.LOC_TYPE = 'SHIP_STAGE' AND tran.TRAN_TSTMP BETWEEN @StartDate AND @EndDate AND tran.WH_ID = @WarehouseId
UNION ALL
-- 13. Shipment Dispatched
SELECT
shp.ORD_NBR AS WarehouseOrder,
'Shipment Dispatched' AS ActivityName,
shp.SHIP_CONFIRM_TSTMP AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
shp.USER_ID AS UserOperatorId,
NULL AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [SHIPMENT_HDR] shp
WHERE shp.SHIP_CONFIRM_TSTMP IS NOT NULL AND shp.SHIP_CONFIRM_TSTMP BETWEEN @StartDate AND @EndDate AND shp.WH_ID = @WarehouseId
UNION ALL
-- 14. Warehouse Order Completed
SELECT
ord.ORD_NBR AS WarehouseOrder,
'Warehouse Order Completed' AS ActivityName,
ord.MOD_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ord.MOD_USER AS UserOperatorId,
ord.PRIORITY AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [ORD_HDR] ord
WHERE ord.STAT_CODE IN ('99', 'COMPLETED') AND ord.MOD_DATE BETWEEN @StartDate AND @EndDate AND ord.WH_ID = @WarehouseId
UNION ALL
-- 15. Warehouse Order Canceled
SELECT
ord.ORD_NBR AS WarehouseOrder,
'Warehouse Order Canceled' AS ActivityName,
ord.MOD_DATE AS EventTime,
'Körber WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ord.MOD_USER AS UserOperatorId,
ord.PRIORITY AS PriorityLevel,
NULL AS ProductSKU,
NULL AS ActualQuantity
FROM [ORD_HDR] ord
WHERE ord.STAT_CODE IN ('95', 'CANCELED') AND ord.MOD_DATE BETWEEN @StartDate AND @EndDate AND ord.WH_ID = @WarehouseId; Gotowi do rozpoczęcia?
Już dziś zacznij wykrywać możliwości usprawnień i nieefektywności w procesie zarządzania magazynem. Ten szablon stanowi punkt wyjścia do optymalizacji opartej na danych.
Usprawnij zarządzanie magazynem i zwiększ efektywność
Ogranicz błędy kompletacji i szybko osiągnij 99,5% dokładności stanów magazynowych.
Nie trzeba podawać danych karty płatniczej. Można zrezygnować w dowolnym momencie.