Systemy do ewidencji odzieży roboczej - konfiguracja norm i dane startowe

Systemy do ewidencji odzieży roboczej i ich dane podstawowe

Systemy do ewidencji odzieży roboczej liczą terminy i limity tylko na podstawie danych, które dostaną na starcie. Błąd w słowniku stanowisk albo w normie przydziału powiela się potem w każdym wydaniu, więc konfigurację warto traktować jak osobny etap, przed pierwszym skanem kodu.

Ewidencja opiera się na czterech słownikach. Każdy ma właściciela po stronie zakładu i źródło, z którego należy go przenieść.

Reguła: słownik stanowisk ma jedno źródło prawdy. Jeżeli ewidencja odzieży prowadzi własną listę, po roku nie zgadza się z kadrami.

Podobny podział na kartoteki i dokumenty stosuje się w magazynie, co pokazuje strona o kartotekach w systemie WMS. Dane pracowników opisuje osobno strona o modułach ewidencji pracowników w Studio TCS.net, a sam obieg sortu od przyjęcia do wycofania omawia artykuł o systemie zarządzania odzieżą roboczą.

Właściciela słownika trzeba wskazać z nazwy, bo bez niego nikt nie zatwierdza zmian. Dział kadr odpowiada za pracowników i stanowiska, dział BHP za normy przydziału, a zakupy za asortyment. Zmiana rozmiaru pracownika należy do osoby wydającej sort, która potwierdza ją przy najbliższym wydaniu.

Tabela norm przydziału jako źródło reguł

Struktura tabeli norm

Przypisanie rodzajów odzieży do stanowisk wraz z okresami używalności jest dokumentem, od którego zaczyna się konfiguracja. Jeżeli tabela nie była aktualizowana od lat, przeniesienie jej do systemu utrwala nieaktualne zasady. Przegląd warto przeprowadzić razem ze służbą bezpieczeństwa pracy, z uwzględnieniem zmian technologicznych i wyników oceny ryzyka na stanowiskach.

Wartości okresów zakład wpisuje sam na podstawie własnych norm i instrukcji producentów. Tabela powyżej pokazuje strukturę, a nie zalecane liczby.

W bazie norma ma klucz złożony ze stanowiska i asortymentu, więc jedno stanowisko nie może mieć dwóch sprzecznych wpisów dla tego samego sortu.

-- przykładowy schemat normy przydziału
CREATE TABLE dbo.NormaPrzydzialu (
    StanowiskoId  INT      NOT NULL,
    AsortymentId  INT      NOT NULL,
    Ilosc         TINYINT  NOT NULL CHECK (Ilosc > 0),
    OkresMiesiecy TINYINT  NULL,
    CONSTRAINT PK_NormaPrzydzialu PRIMARY KEY (StanowiskoId, AsortymentId)
);

Wartość NULL w kolumnie okresu oznacza sort bez z góry ustalonej używalności, na przykład okulary, które wymienia się po uszkodzeniu. Takie sorty nie generują powiadomień czasowych.

Zmiany normy w czasie

Norma zmienia się, gdy zakład zmienia technologię albo dostawcę sortu. Nowa wartość nie może przeliczyć wstecz terminów sortów już wydanych, więc wpis normy dostaje daty obowiązywania. Wydanie korzysta z normy aktualnej w dniu wydania, a stare wpisy zostają w historii.

ALTER TABLE dbo.NormaPrzydzialu ADD
    ObowiazujeOd DATE NOT NULL CONSTRAINT DF_Norma_Od DEFAULT (CAST(SYSDATETIME() AS DATE)),
    ObowiazujeDo DATE NULL;

-- norma aktualna dla stanowiska w danym dniu
SELECT AsortymentId, Ilosc, OkresMiesiecy
FROM dbo.NormaPrzydzialu
WHERE StanowiskoId = @StanowiskoId
  AND ObowiazujeOd <= @Dzien
  AND (ObowiazujeDo IS NULL OR ObowiazujeDo >= @Dzien);

Przy takim układzie klucz główny trzeba rozszerzyć o kolumnę początku obowiązywania, bo ten sam sort na tym samym stanowisku może mieć kilka wpisów w czasie. Zakres dat dwóch wpisów nie powinien się pokrywać, co sprawdza się dodatkowym warunkiem przy zapisie normy.

Kartoteka pracownika i przypisanie do stanowisk

Kartoteka pracownika łączy dane z kadr z normą przydziału. Zmiana stanowiska podmienia normę, a system porównuje nowy zestaw z tym, co pracownik już posiada. Zestawienie braków opisuje poniższe zapytanie w wersji uproszczonej.

SELECT p.PracownikId, n.AsortymentId,
       n.Ilosc - COUNT(e.EgzemplarzId) AS Brakuje
FROM dbo.Pracownik AS p
JOIN dbo.NormaPrzydzialu AS n ON n.StanowiskoId = p.StanowiskoId
LEFT JOIN dbo.SortEgzemplarz AS e
       ON e.PracownikId = p.PracownikId
      AND e.AsortymentId = n.AsortymentId
      AND e.Stan = 2
GROUP BY p.PracownikId, n.AsortymentId, n.Ilosc
HAVING COUNT(e.EgzemplarzId) < n.Ilosc;

Osobnej decyzji wymaga pracownik przypisany do dwóch stanowisk. Zakład musi wskazać, czy normy się sumują, czy obowiązuje wyższa z nich, a wybór zapisać w instrukcji obiegu.

• Norma sumowana - pracownik dostaje pełny zestaw z obu stanowisk, co zwiększa koszt, ale eliminuje spory.
• Norma wyższa - obowiązuje większa ilość dla każdego sortu, co upraszcza zakupy i wymaga wyjaśnienia różnic pracownikom.

Rozmiary odzieży i obuwia warto traktować jak dane osobowe i udostępniać tylko rolom, które ich potrzebują. Zakres danych i dokumentowanie przydziałów opisuje także strona o kontroli nad środkami ochrony indywidualnej i odzieżą roboczą.

Stan początkowy i migracja danych z arkuszy

Odzież znajdująca się u pracowników zwykle nie jest nigdzie odnotowana z datą wydania. Odtworzenie tych danych bywa niewykonalne, więc praktycznym rozwiązaniem jest przyjęcie daty wdrożenia jako punktu odniesienia i naliczanie okresów używalności od niej. Rozwiązanie to przesuwa pierwszą falę wymian, co należy uwzględnić w planie zakupów na pierwszy rok.

Dane z arkuszy wczytuje się najpierw do tabeli pośredniej, a dopiero po kontroli do kartoteki. Instrukcja BULK INSERT w dokumentacji Microsoft opisuje wczytanie pliku CSV; opcja FORMAT = 'CSV' jest dostępna od SQL Server 2017.

CREATE TABLE dbo.OdziezImport (
    Nazwisko    NVARCHAR(80),
    Stanowisko  NVARCHAR(80),
    Asortyment  NVARCHAR(80),
    Rozmiar     NVARCHAR(10),
    DataWydania DATE NULL
);

BULK INSERT dbo.OdziezImport
FROM 'C:\import\odziez.csv'
WITH (FORMAT = 'CSV', FIRSTROW = 2, CODEPAGE = '65001');

Nazwy z arkusza rzadko pokrywają się ze słownikiem, bo ten sam sort bywa zapisany na kilka sposobów. Rozwiązaniem jest tabela mapowania, która przypisuje każdej nazwie z arkusza identyfikator asortymentu. Mapowanie tworzy się raz, a przy kolejnych importach system rozpoznaje już znane warianty.

Pierwszą z kontroli można zapisać jednym zapytaniem. Wiersze, które je zwrócą, blokują przeniesienie, dopóki ktoś nie rozstrzygnie każdej nazwy.

SELECT i.*
FROM dbo.OdziezImport AS i
LEFT JOIN dbo.Asortyment AS a ON a.Nazwa = i.Asortyment
WHERE a.AsortymentId IS NULL;

Reguła: import wykonuje się na kopii bazy, a do środowiska produkcyjnego trafia dopiero po zerowym wyniku wszystkich kontroli.

Planowanie zakupów na podstawie ewidencji

Dobrze prowadzona ewidencja odpowiada na pytanie, ile sortów trzeba kupić przed końcem okresu. Zapotrzebowanie składa się z wymian, które wypadną w wybranym horyzoncie, oraz z braków wynikających z normy. Od tej sumy odejmuje się dostępny stan magazynowy, a podział na rozmiary jest tu niezbędny, bo zamówienie realizuje się w rozmiarówce.

SELECT a.Nazwa, p.Rozmiar, COUNT(*) AS DoWymiany
FROM dbo.SortEgzemplarz AS e
JOIN dbo.Asortyment AS a ON a.AsortymentId = e.AsortymentId
JOIN dbo.Pracownik  AS p ON p.PracownikId  = e.PracownikId
WHERE e.Stan = 2
  AND e.TerminUzywalnosci <= DATEADD(MONTH, 3, CAST(SYSDATETIME() AS DATE))
GROUP BY a.Nazwa, p.Rozmiar
ORDER BY a.Nazwa, p.Rozmiar;

Wynik porównuje się ze stanami magazynowymi tego samego asortymentu. Różnica dodatnia jest podstawą zamówienia, a ujemna oznacza zapas, który wystarcza na kolejny okres. Długość horyzontu zależy od czasu dostawy: im dłuższy termin realizacji zamówienia, tym wcześniej musi się zacząć planowanie.

Zapas minimalny ustala się osobno dla sortów, które wydaje się doraźnie, na przykład rękawic. Poniżej tego poziomu system powinien sygnalizować potrzebę zamówienia niezależnie od kalendarza wymian, bo zużycie takich sortów jest nierówne i zależy od charakteru prac na wydziale.

Inwentaryzacja sortów u pracowników

Po wczytaniu danych ewidencję trzeba zestawić ze stanem faktycznym. Spis polega na okazaniu sortów przez pracownika i zeskanowaniu ich kodów na urządzeniu mobilnym, tak jak w inwentaryzacji towarów. Zasady spisu opisuje strona o inwentaryzacji magazynowej, a metody porównuje zestawienie programów do inwentaryzacji.

Skanowanie odbywa się na terminalu z Androidem, którego pracę opisuje strona o aplikacji magazynowej na Androidzie.

Częstość spisu zależy od rotacji załogi. W zakładach z dużą rotacją sensowny jest spis próby, obejmujący wybrany wydział, co kwartał; pełny spis robi się raz w roku albo po zmianie systemu. Wynik każdego spisu wchodzi do historii jako zdarzenie z datą i osobą przeprowadzającą.

Korekty zapisuje się dokumentami, a nie edycją stanu, dzięki czemu po spisie zostaje pełna historia. Pierwszy spis po wdrożeniu daje też miarę jakości migracji, bo pokazuje odsetek kodów, które nie zgadzały się z arkuszem.

Raporty operacyjne i eksport danych

Do codziennej obsługi wystarcza niewielki zestaw raportów: zbliżające się terminy wymiany, lista pracowników bez kompletu oraz stan magazynowy w podziale na rozmiary. Raporty warto udostępnić kierownikom wydziałów, bo to oni odpowiadają za wyposażenie zespołów i najszybciej zauważą nieprawidłowość.

Wydruki i zestawienia w bazie SQL Server buduje się w narzędziach klasy SSRS, a sposób przygotowania szablonów RDL opisuje strona o SQL Report Builder. Przegląd funkcji ewidencji odzieży w produkcie znajduje się na portalu oprogramowania BHP do ewidencji odzieży roboczej.

Kierownik wydziału powinien widzieć wyłącznie swój zespół. W bazie osiąga się to widokiem z filtrem po wydziale przypisanym do konta, a raport w SSRS odpytuje widok zamiast tabel źródłowych. Dzięki temu nowy raport nie ominie reguł dostępu.

Kontrola jakości danych po uruchomieniu

Po wdrożeniu dane nadal się psują, głównie przez wyjątki wprowadzane pod presją czasu. Część błędów blokuje się w bazie, zanim trafią do kartoteki. Poniższe ograniczenie nie pozwala zapisać sortu w stanie Wydany bez wskazania pracownika.

ALTER TABLE dbo.SortEgzemplarz
ADD CONSTRAINT CK_SortEgzemplarz_Wydany_ma_pracownika
CHECK (Stan <> 2 OR PracownikId IS NOT NULL);

Pozostałe nieprawidłowości wykrywa cykliczny przegląd, na przykład tygodniowy, który przeglądają osoby z działu BHP.

• Sorty wydane bez użytkownika - blokuje je ograniczenie, ale przegląd sprawdza dane sprzed jego wprowadzenia.
• Terminy przeterminowane bez wymiany - sygnał, że powiadomienia trafiają do złej osoby.
• Zduplikowane kody - klucz unikalny zatrzymuje je przy zapisie, przegląd wykrywa kody z importu.
• Stany początkowe bez daty - pozycje z datą wdrożenia, które należy zweryfikować przy pierwszym spisie.

Przegląd nieprawidłowości warto uruchamiać jako zadanie SQL Agent z wynikiem wysyłanym do osoby odpowiedzialnej. Zadanie, które nic nie zwraca, jest dobrą wiadomością, a każdy zwrócony wiersz ma właściciela i termin rozstrzygnięcia. Bez tej pętli kontrola sprowadza się do jednorazowego sprzątania po wdrożeniu.

Słowniki poprawia się przez dezaktywację, a nie usuwanie. Asortyment wycofany z zakupów zostaje w bazie z flagą nieaktywności, ponieważ historyczne wydania nadal się do niego odwołują. Usunięcie wiersza zerwałoby te powiązania albo wymusiło kaskadowe kasowanie historii.