1. Rozbudowa DC o Kanban
2. Specyfikacja - Kanban Purchase Order Entry
3. Realizacja
4. Tematy powiązane
1. Rozbudowa DC o Kanban
W dokumentacji Trawersa taka funkcjonalność jest już w dużej części przewidziana
i opisana jako Kanban. Nie trzeba budować mechanizmu zamówień zakupu od zera -
trzeba raczej odpowiednio złożyć istniejące elementy i ewentualnie dodać prostą,
ograniczoną formatkę 'Kanban'.
Patrz szczegóły:
DC Data Collection. SkaneryCo Trawers ma już dzisiaj
Najważniejsza funkcja to:
DC > ZA > Zamówienie zakupu `[DC_DZA01]`
Jest ona odpowiednikiem dopisywania zamówienia zakupu w ZA, ale przeznaczonym do pracy ze skanerem.
Dokumentacja mówi wprost, że zastosowanie skanera do tworzenia propozycji lub zamówień zakupu
pozwala zbudować procedurę Kanban:
| magazynier / pracownik produkcji skanuje kod z etykiety pojemnika;
| jest to sygnał do dopisania pozycji do propozycji albo do zamówienia zakupu
| do głównego dostawcy, a ilość może być ustalona według przyjętej reguły,
| np. `NormaZam_KSOM`.
Czyli podstawowy scenariusz:
pusty pojemnik -> karta Kanban -> skan -> dostawca -> ilość -> PO
jest już zgodny z architekturą Trawersa.
Dodatkowo DC pozwala ustalić sposób pracy z ilością i zapisem, np. ilość 1
bez możliwości zmiany oraz zapis bez pytania 'Czy zapisać?', co jest bardzo
przydatne na stanowisku produkcyjnym.
Jak odwzorować funkcję - Kanban Purchase Order Entry
Najlepiej zrobić bardzo małą formatkę, np.
ZA > Zamówienia > Kanban - skanowanie
z jednym aktywnym polem:
`Kod Kanban / BarKod: [_____________]`
Po skanie program wykonałby automatycznie:
1. rozpoznanie indeksu KIM według EAN13/KID/indeksu,
2. odczyt magazynu,
3. odczyt głównego dostawcy KIM/KSOM,
4. odczyt `NormaZam_KSOM` albo innej ustalonej ilości Kanban,
5. kontrolę, czy indeks może być kupowany,
6. określenie ceny,
7. utworzenie `[ZL]` zamówienia zakupu,
8. komunikat np. `Utworzono ZA001234 000001 / KARTON01 / 20 szt.`,
9. opcjonalny automatyczny wydruk zamówienia.
Punkt 1 również nie wymaga nowej infrastruktury. Trawers potrafi wyszukiwać KIM
według symbolu, nazwy, BarKodu/EAN13, KID i MPN.
Dostawca: odpowiednik Primary Supplier / Purchase Part
Tutaj model danych Trawersa jest trochę inny niż w opisie angielskiego programu.
(Caliach - Kanban)
W Trawersie istnieje główny dostawca w KIM/KSOM, a dodatkowo oferty dostawców i ich priorytety.
Dokumentacja systemu zaopatrzenia przewiduje wybór m.in. głównego dostawcy oraz dostawcy
według ofert/prioritetów.
Dla najprostszego Kanbanu zastosować więc zasadę:
Kanban -> zawsze główny dostawca KSOM, a jeżeli brak -> główny dostawca KIM.
Jest to szczególnie dobre dlatego, że dokumentacja ZA ma już regułę wyboru:
`[8] Główny dostawca z karty KSOM / KIM`.
Jeżeli chcemy dokładnie odwzorować opisane `optPOKanbanNoChoice`, dodać parametr np.:
`Kanban - sposób wyboru dostawcy:`
`[1] tylko główny KSOM/KIM`
`[2] wg priorytetu ofert`
`[3] najniższa cena spośród ofert`
`[4] wskazana grupa/znacznik ofert`
Pierwsze dwa warianty dobrze pasują do obecnego modelu Trawersa. Natomiast odpowiednika
dokładnie takiego jak `optPOKanbanNoChoice` nie ma w dostarczonej dokumentacji -
byłaby to niewielka nowa reguła.
Ilość Kanban
Tutaj Trawers wręcz ma przewagę, bo można wykorzystać istniejące normy zapasów.
Dokumentacja przewiduje m.in. normy minimum, maksimum, średni rozchód oraz automatyczne
propozycje zamówień według tych wartości.
Dla konkretnego indeksu można więc przyjąć np.:
`Ilość Kanban = NormaZam_KSOM`
albo bardziej zaawansowanie:
`max(NormaMax_KSOM - stan dostępny - otwarte ZA, NormaZam_KSOM)`
Drugi wzór byłby już główną regułą biznesową. Standardowe mechanizmy Trawersa potrafią
przy obliczaniu potrzeb uwzględniać istniejące zamówienia zakupu, dzięki czemu nie
generują kolejnej potrzeby, jeżeli towar jest już zamówiony.
Dodać taką samą ochronę także w Kanbanie, żeby dwukrotne przypadkowe zeskanowanie
tej samej karty nie generowało dwóch identycznych zamówień.
Operator, który nie ma prawa wystawiać normalnych PO
To także da się sensownie zrobić.
Trawers ma uprawnienia RBAC, menu własne operatora, uprawnienia do poszczególnych
funkcji i obiektów oraz filtry dostępu.
Zwykły operator domyślnie nie ma żadnych praw, dopóki administrator ich nie nada.
Utworzyć rolę np. `KANBAN` z prawem wyłącznie do:
`DC_DZA01 Zamówienie zakupu`
lub jeszcze lepiej do nowego procesu:
`ZA_DKAN10 Kanban: skanowanie`
bez prawa do normalnego:
`ZA > Zamówienia > Dopisywanie/Korekta`.
Czyli magazynier nie dostawałby możliwości swobodnego wybierania dostawcy, ceny, indeksu
czy zmiany istniejących zamówień.
To funkcjonalnie odpowiada idei z przykładu: **użytkownik może wyzwolić zakup,
ale nie jest normalnym zaopatrzeniowcem**.
Jedną rzecz należałoby sprawdzić testowo: dokumentacja potwierdza, że `DC_DZA01`
jest osobnym procesem, ale nie stwierdza jednoznacznie, czy podczas jego wykonywania
nie następuje dodatkowe sprawdzenie prawa do bazowego `ZA_DZA10`.
Dlatego przy wdrożeniu warto zrobić test roli posiadającej wyłącznie DC.
Jeszcze bezpieczniejszy wariant
Można też nie tworzyć od razu PO.
Trawers ma:
DC > ZA > Propozycja zamówienia zakupu `[DC_DZA02]`
oraz SOA `PurchaseProposalNew`.
Wtedy:
skan Kanban -> propozycja zakupu -> zaopatrzeniowiec zatwierdza/generuje PO
To jest wariant bardzo dobry w firmach, które wymagają rozdzielenia kompetencji.
Propozycje można następnie opracować i wygenerować z nich właściwe zamówienia.
Jeżeli ma być dokładnie jak w opisanym systemie - scan = natychmiast powstaje PO -
użyć bezpośredniego `DC_DZA01`.
Akceptacja zamówień
Nie trzeba też rezygnować z kontroli zakupowej.
Nowo utworzone zamówienie otrzymuje status `[N] Nowe`, a Trawers ma osobny proces
akceptacji `[N] -> [A]`. Osoba akceptująca może kontrolować zapas, ceny i budżet.
Czyli bardzo dobry model to:
Magazynier skanuje -> powstaje PO `[N]` -> kierownik/zaopatrzenie akceptuje `[A]`-> wysyłka do dostawcy.
Dzięki temu operator Kanban nie musi mieć prawa do akceptowania zamówień.
Karty Kanban i ich drukowanie
To również można wykonać standardowym mechanizmem wzorców.
Trawers potrafi drukować etykiety bezpośrednio z KIM:
MG > Kartoteka KIM > Wydruk wg wzorca `[IM] [MG_KKI46]`
Etykieta może zawierać m.in. indeks, nazwę oraz kod EAN13.
Czyli można zbudować własny wzorzec:
KARTA KANBAN
`KARTON01`
`Karton opakowaniowy 600x400`
`Magazyn: 10`
`Dostawca: 000001`
`Ilość Kanban: 20 szt.`
`[ BARCODE / QR ]`
Kod nie musi nawet zawierać wszystkich tych informacji. Najbezpieczniej,
aby kod zawierał tylko stabilny identyfikator indeksu/KID, a aktualny
dostawca i ilość były za każdym razem odczytywane z bazy.
Dzięki temu zmiana dostawcy lub normy nie wymaga natychmiastowej wymiany
wszystkich kart.
Trawers ma też gotową obsługę kodów EAN13, GS1-128, QR i DataMatrix
w systemie wzorców.
Wariant z małą aplikacją / GUI
Jeżeli chcemy ekran wyglądający dokładnie jak ten z opisu, można zrobić
cienki interfejs korzystający z SOA.
Trawers ma InBound:
`PurchaseOrderNew`
który dopisuje `[ZL]` zamówienie zakupu. Przyjmuje m.in. `vendorKey`, `productKey`,
`quantity`, magazyn, cenę i termin.
Do wydruku istnieje:
`PrintPurchaseOrder`.
Dokumentacja wręcz pokazuje scenariusz: aplikacja zewnętrzna zapisuje PO przez
`PurchaseOrderNew`, a następnie wysyła żądanie wydrukowania go przez `PrintPurchaseOrder`.
To pasowałoby do ekranu:
`[ zeskanowany indeks ]`
`Towar: ...`
`Dostawca: ...`
`Ilość: ...`
`[UTWÓRZ I DRUKUJ PO]`
`[DRUKUJ KARTĘ KANBAN]`
SOA w Trawersie służy właśnie do pobierania i zapisywania danych przez aplikacje zewnętrzne.
Jest jednak ważne ograniczenie: opis `PurchaseOrderNew` podaje dla dostawcy walutę tylko PLN
i brak przeliczania cen w walucie obcej. Dlatego przy dostawcach EUR/USD bardziej
naturalna byłaby bezpośrednia funkcja wewnętrzna Trawersa/DC niż budowanie całego
rozwiązania wyłącznie na tej konkretnej usłudze SOA.
Co wybrać w praktyce
Najmniej ryzykowny wariant to nie pisać nowego modułu zamówień, tylko rozbudować
istniejący mechanizm DC.
Architektura:
| Karta Kanban -> skaner -> `DC_DZA01` -> KIM/KID -> KSOM -> główny dostawca -> `NormaZam_KSOM` ->
| `[ZL]` ZA -> ewentualna akceptacja -> wydruk/wysyłka.
Do tego nowy, prosty ekran Kanban powinien ukryć wszystko, czego pracownik produkcji nie powinien zmieniać.
W praktyce jest to małe/średnie rozszerzenie Trawersa, a nie nową funkcjonalność
od zera, ponieważ kluczowa logika - skanowanie, główny dostawca, ilość zwykle zamawiana,
PO, propozycje, akceptacja, etykiety i SOA - już istnieje.
Co ciekawe, w systemie RA jest nawet pozycja:
`RA > Dostęp dostawców > Zaopatrzenie KANBAN [RA_PRB20]`
oznaczona w dokumentacji jako alfa / w przygotowaniu.
To dodatkowo potwierdza, że taki kierunek był przewidziany w architekturze Trawersa.
W następnym kroku jest opis **konkretnej specyfikacji funkcjonalnej dla programisty Trawersa:
ekran `ZA_DKAN10`, pola, algorytm po skanie, wybór dostawcy,
zabezpieczenie przed podwójnym skanem, uprawnienia i wzorzec karty Kanban.
2. Specyfikacja - Kanban Purchase Order Entry w Trawers ERP
Poniżej specyfikacja. Rozdzielone świadomie to, co już potwierdza dokumentacja Trawersa,
od proponowanego rozszerzenia, żeby programista nie potraktował koncepcji jako istniejącego standardu.
2.1 Cel rozwiązania
Celem funkcji jest umożliwienie pracownikowi magazynu lub produkcji utworzenia
zapotrzebowania zakupowego przez zeskanowanie karty lub etykiety Kanban, bez udostępniania
mu pełnej funkcjonalności rejestracji i korekty zamówień zakupu.
Podstawowy przebieg:
| pusty pojemnik -> skan karty Kanban -> identyfikacja KIM -> ustalenie dostawcy i ilości
| -> utworzenie [ZL] Zamówienia zakupu -> opcjonalna akceptacja -> wydruk / wysłanie do dostawcy
Funkcja powinna być maksymalnie uproszczona i przeznaczona do obsługi skanerem.
2.2 Podstawa istniejąca w Trawersie
Rozwiązanie nie wymaga budowania mechanizmu zamówień zakupu od początku.
W standardzie Trawersa istnieje:
DC > ZA > Zamówienie zakupu `[DC_DZA01]`
będące odpowiednikiem:
ZA > Zamówienia zakupu > Dopisywanie `[ZA_DZA10]`.
Dokumentacja wprost opisuje wykorzystanie `DC_DZA01` i `DC_DZA02` do procedury Kanban.
Operator może zeskanować etykietę pojemnika, a skan stanowi sygnał do dopisania pozycji
do propozycji zakupu lub zamówienia zakupu do głównego dostawcy.
Jako przykładową ilość podano `NormaZam_KSOM`.
Moduł DC posiada już parametry upraszczające obsługę, m.in. automatyczne wpisywanie ilości
oraz zapis pozycji bez pytania 'Czy zapisać?'.
Dokumentacja wskazuje również, że przy rejestracji zamówienia zakupu na urządzeniu mobilnym
w DC operator podaje jedynie dostawcę, towar i ilość.
Wniosek: proponowana funkcja powinna wykorzystywać istniejącą logikę ZA/DC.
2.3 Proponowana nowa funkcja
Robocza nazwa:
ZA > Zamówienia > Kanban - zamówienia zakupu
Proponowany identyfikator procesu:
`ZA_DKAN10`
Identyfikator jest propozycją i należy go nadać zgodnie z obowiązującymi zasadami
numeracji procesów Trawersa.
Alternatywnie funkcję można umieścić w systemie DC:
DC > ZA > Kanban
i potraktować ją jako specjalizowany wariant `DC_DZA01`.
Preferowany jest wariant DC, jeżeli ekran ma być używany głównie na terminalach
i urządzeniach mobilnych.
2.4 Ekran funkcji
Ekran powinien być bardzo prosty.
1. Pole aktywneKod Kanban / BarKod
Pole pozostaje stale aktywne i po wykonaniu operacji program automatycznie
ustawia na nim kursor.
Kod można:
* zeskanować czytnikiem,
* wpisać ręcznie,
* opcjonalnie wybrać KIM z listy.
2 Pola informacyjne
Po rozpoznaniu kodu program wyświetla:
| Pole | Znaczenie |
| -------------- | ------------------------------------------------ |
| Indeks | Indeks KIM |
| Nazwa | Nazwa asortymentu |
| Magazyn | Magazyn, którego dotyczy Kanban |
| Dostawca | Wybrany dostawca |
| Nazwa dostawcy | Nazwa kontrahenta |
| Ilość Kanban | Ilość do zamówienia |
| J.m. | Jednostka miary zakupu |
| Cena | Cena zakupu ustalona przez standardową procedurę |
| Termin | Oczekiwany termin dostawy |
| Status | Wynik analizy / komunikat |
Pola te dla zwykłego operatora Kanban powinny być tylko do odczytu.
2.5 Przyciski
Podstawowy ekran:
[Utwórz zamówienie][Utwórz i drukuj][Drukuj kartę Kanban][Anuluj]
W wariancie maksymalnie automatycznym przyciski Utwórz zamówienie można pominąć:
skan -> walidacja -> zapis -> komunikat -> następny skan
2.6 Identyfikacja asortymentu
Po zeskanowaniu kodu program powinien odnaleźć kartę KIM.
Należy wykorzystać standardowe mechanizmy identyfikacji kodowej Trawersa.
Dopuszczalne identyfikatory:
* indeks KIM,
* BarKod / EAN13,
* KID,
* inne kody obsługiwane przez standardowy mechanizm skanowania.
Trawers umożliwia przypisanie EAN13 do KIM oraz wydruk etykiety z tym kodem
przy pomocy systemu wzorców.
Błąd
Jeżeli kod nie wskazuje jednoznacznie KIM:
Nie znaleziono indeksu dla kodu: XXXXX
Zamówienie nie jest tworzone.
2.7 Ustalenie magazynu
W pierwszej wersji rekomendowane jest przypisanie stanowiska Kanban do jednego magazynu.
Przykład:
`Terminal PROD01 magazyn 10`
Dzięki temu karta Kanban nie musi zawierać symbolu magazynu.
W późniejszej wersji kod karty może identyfikować:
KIM + magazyn
co pozwoli stosować różne ilości Kanban dla tego samego asortymentu w różnych magazynach.
Jest to istotne, ponieważ przykładowa ilość podawana przez dokumentację pochodzi
z `NormaZam_KSOM`, czyli normy dotyczącej KIM w konkretnym magazynie.
2.8 Wybór dostawcy
1. Wariant podstawowy
Dostawca wybierany automatycznie.
Operator Kanban nie może zmieniać dostawcy.
Dokumentacja istniejącego scenariusza Kanban mówi o utworzeniu zamówienia do głównego dostawcy.
Standardowe automatyczne procesy Trawersa również wykorzystują głównego dostawcę
oraz standardową metodę ustalenia ceny.
2. Proponowana hierarchia
Do ustalenia podczas implementacji:
1. główny dostawca właściwy dla KIM/KSOM,
2. jeżeli brak odpowiedniego powiązania magazynowego - główny dostawca z KIM,
3. brak dostawcy -> blokada utworzenia zamówienia.
Dokumentacja nie określa jednoznacznie takiej kolejności KSOM -> KIM, dlatego
szczegółową kolejność należy zweryfikować z aktualnym kodem procedury `DC_DZA01`.
3. Tryby konfiguracyjne
Proponowany parametr:
KANBAN wybór dostawcy
`[1] Tylko główny dostawca`
`[2] Dostawca wg standardowego rankingu ZA`
`[3] Dostawca wg ofert / priorytetu`
Dla wersji MVP zalecany jest wyłącznie tryb `[1]`.
2.9 Ustalanie ilości
1. Wariant podstawowy
Domyślna reguła:
Ilość = NormaZam_KSOM
czyli ilość zwykle zamawiana.
Dokładnie taki przykład podaje dokumentacja procedury Kanban DC.
Operator produkcyjny nie powinien mieć możliwości ręcznej zmiany tej wartości.
2. Dodatkowe warianty
W przyszłości można dodać parametr:
KANBAN sposób ustalania ilości
`[1] NormaZam_KSOM`
`[2] Dopełnienie do NormaMax`
`[3] Ilość zapisana na karcie Kanban`
`[4] Własny wzór potrzeb ZA`
Warianty `[2]-[4]` są rozszerzeniem projektowym, a nie funkcją potwierdzoną wprost dla `DC_DZA01`.
2.10 Cena zakupu
Cena powinna być ustalana przez istniejące zasady ZA.
Dokumentacja dla automatycznego tworzenia zamówień wskazuje standardową metodę:
oferta dostawcy -> jeżeli jej brak, cena ostatniego przychodu KIM.
Operator Kanban nie powinien mieć prawa ręcznej zmiany ceny.
Jeżeli standardowe reguły Trawersa nie pozwalają wyznaczyć poprawnej ceny, zamówienie nie
powinno być automatycznie tworzone.
Komunikat:
Nie można ustalić ceny zakupu. Zamówienie nie zostało utworzone.
2.11 Algorytm po zeskanowaniu karty
Po odczytaniu kodu program wykonuje kolejno:
1. Odczytaj kod.
2. Rozpoznaj KIM.
3. Sprawdź aktywność i możliwość zakupu indeksu.
4. Ustal magazyn.
5. Odczytaj normy KSOM.
6. Ustal dostawcę.
7. Ustal ilość Kanban.
8. Sprawdź ochronę przed powtórnym skanem.
9. Ustal cenę zgodnie ze standardową procedurą ZA.
10. Ustal termin realizacji.
11. Sprawdź standardowe ograniczenia operatora i dokumentu.
12. Utwórz `[ZL] Zamówienie zakupu`.
13. Zapisz informację, że dokument powstał w trybie Kanban.
14. Opcjonalnie uruchom wydruk.
15. Pokaż rezultat.
16. Wyczyść ekran.
17. Ustaw kursor ponownie w polu skanowania.
Najważniejsza zasada implementacyjna:
krok 12 powinien wywoływać standardową procedurę tworzenia zamówienia ZA/DC
Dzięki temu pozostają aktywne normalne reguły biznesowe Trawersa.
2.12 Jedno zamówienie czy wiele zamówień
Rekomendowany wariant MVP:
jeden skan -> jedno jednopozcyjne zamówienie [ZL].
Jest to najbardziej zbliżone do klasycznego Kanban Purchase Order Entry.
Możliwy jest jednak wariant:
kolejne skany dla tego samego dostawcy -> kolejne pozycje jednego otwartego zamówienia Kanban.
W takim przypadku należy ustalić regułę agregacji:
`firma + oddział + dostawca + magazyn + dzień + operator`
Po zmianie dostawcy program otwiera nowe zamówienie.
Wariant agregowany jest efektywniejszy przy dużej liczbie kart Kanban, ale jest bardziej złożony.
2.13 Ochrona przed podwójnym skanem
To powinien być element obowiązkowy rozszerzenia.
Nie można jednak po prostu blokować drugiego skanu tego samego indeksu, ponieważ
dwa fizyczne pojemniki tego samego materiału mogą prawidłowo wygenerować dwa sygnały Kanban.
Dlatego zalecany jest unikalny identyfikator karty Kanban.
Przykład:
`KAN|10|KARTON01|02`
gdzie:
* `KAN` - typ kodu,
* `10` - magazyn,
* `KARTON01` - KIM,
* `02` - numer fizycznej karty/pojemnika.
Program zapisuje ostatnią operację dla identyfikatora karty.
Reguła
Ponowne zeskanowanie tej samej karty np. w ciągu 30 sekund:
Karta została już zeskanowana. Ponowić?
Operator bez dodatkowego uprawnienia nie może wykonać ponownego zapisu.
W bardziej zaawansowanym rozwiązaniu karta otrzymuje stan:
PEŁNY -> PUSTY/ZAMÓWIONY -> DOSTARCZONY -> PEŁNY
co praktycznie eliminuje możliwość wielokrotnego wygenerowania tego samego sygnału.
2.14 Status zamówienia
Nowe zamówienie powinno wejść do normalnego cyklu ZA.
Standardowy cykl Trawersa:
[N] Nowe -> [A] Akceptowane -> [P] Potwierdzone -> [Z] Zamknięte
z możliwością odrzucenia `[R]`.
Rekomendowany wariant:
Kanban tworzy zamówienie `[N]`.
Pracownik produkcyjny nie otrzymuje prawa do akceptowania zamówień.
Następnie:
zaopatrzeniowiec/kierownik -> `[A]` Akceptowane
Akceptacja w Trawersie służy właśnie wyrażeniu zgody uprawnionej osoby
na realizację zamówienia i pozwala m.in. kontrolować zapasy, ceny oraz budżet.
Jeżeli przedsiębiorstwo nie stosuje akceptacji, standardowo można
wyłączyć jej obowiązek parametrem `0131`.
2.15 Uprawnienia
Należy utworzyć osobną rolę, np.:
`KAN` - Operator Kanban
Rola powinna mieć:
* dostęp do funkcji Kanban,
* prawo odczytu niezbędnych KIM,
* dostęp tylko do właściwych magazynów,
* prawo utworzenia dokumentu przez funkcję Kanban.
Rola nie powinna mieć:
* prawa do zwykłego `ZA_DZA10`,
* prawa korekty zamówień,
* prawa usuwania zamówień,
* prawa zmiany ceny,
* prawa zmiany dostawcy,
* prawa akceptowania zamówień,
* prawa zmiany norm zapasów.
Trawers posiada system RBAC, w którym prawa są przydzielane rolom i operatorom,
a oddzielnie można ograniczać dostęp do funkcji, obiektów i kartotek.
Istotne do sprawdzenia podczas implementacji:
czy wykonanie `DC_DZA01` wymaga również prawa do bazowego `ZA_DZA10`.
Dokumentacja potwierdza, że są to powiązane funkcje, ale nie rozstrzyga
tej zależności uprawnień. Powinien to być osobny test techniczny.
2.16 Oznaczenie zamówienia jako Kanban
Każde zamówienie utworzone tym mechanizmem powinno być możliwe do jednoznacznego rozpoznania.
Preferowane rozwiązanie:
pole źródło / rodzaj utworzenia = KANBAN
Jeżeli nie istnieje odpowiednie standardowe pole, można wykorzystać kontrolowany opis dokumentu, np.:
`KANBAN; karta=KAN|10|KARTON01|02; operator=MP`
Nie należy używać swobodnego tekstu, jeżeli informacja ma później służyć do raportowania.
Docelowo warto mieć możliwość zestawienia:
ZA > Zamówienia > Kanban - historia
z kolumnami:
data/czas, operator, karta Kanban, magazyn, KIM, dostawca, ilość, numer ZA, status.
2.17 Kronika operacji
Dla każdego skanu powinny być zapisane minimum:
* data i czas,
* operator,
* stanowisko / urządzenie,
* zeskanowany kod,
* rozpoznany KIM,
* magazyn,
* dostawca,
* ilość,
* numer utworzonego zamówienia,
* wynik operacji,
* komunikat błędu.
Jest to szczególnie ważne, ponieważ operator Kanban otrzymuje możliwość inicjowania
zobowiązania zakupowego bez dostępu do pełnego modułu zaopatrzenia.
2.18 Komunikaty użytkownika
Poprawne utworzenie
OK - utworzono ZA000123/08/26
`KARTON01 20 szt.`
`Dostawca: 000001 ABC Sp. z o.o.`
Kolor komunikatu: zielony.
Kod nieznany
Nie znaleziono KIM dla zeskanowanego kodu.
Kolor: czerwony.
Brak dostawcy
Indeks nie ma dostawcy dopuszczonego do zamówień Kanban.
Brak normy
Brak ilości Kanban / NormaZam_KSOM = 0.
Brak ceny
Nie można ustalić ceny zakupu.
Duplikat
Karta została już użyta do utworzenia zamówienia ZA000123/08/26.
Brak prawa
Operator nie ma prawa do utworzenia zamówienia Kanban.
Po błędzie program nie może opuszczać ekranu. Powinien wrócić bezpośrednio do pola skanowania.
2.19 Drukowanie zamówienia
Po utworzeniu dokumentu można wykorzystać standardowy mechanizm wydruku ZA.
Jeżeli funkcja zostanie wykonana jako aplikacja wykorzystująca SOA, istnieje gotowa funkcja:
`PrintPurchaseOrder`
przyjmująca numer zamówienia, wzorzec i urządzenie wyjściowe. Dokumentacja podaje wprost scenariusz:
`PurchaseOrderNew` -> `PrintPurchaseOrder`.
2.20 Drukowanie kart Kanban
Należy przygotować wzorzec:
`KANBAN_KIM`
Proponowana zawartość:
KARTA KANBAN
Indeks: `KARTON01`
Nazwa: `Karton opakowaniowy`
Magazyn: `10`
Ilość Kanban: `20 szt.`
Dostawca: `000001`
Karta: `02`
`[kod kreskowy / QR]`
Trawers posiada standardowy system wzorców dokumentów i etykiet, a dane wzorca
mogą pochodzić z pól bazy danych.
Dokumentacja zawiera również wzorce etykiet tworzone na podstawie `[ZL] Zamówienia zakupu`
i możliwość umieszczania na nich kodu kreskowego.
2.21 Zawartość kodu Kanban
Rekomendowane rozwiązanie:
kod nie powinien zawierać ceny ani dostawcy.
Powinien identyfikować kartę, np.:
`KAN|10|KARTON01|02`
Dostawca, ilość, cena i inne dane powinny być odczytywane z aktualnej bazy Trawersa w momencie skanowania.
Zaleta:
zmiana dostawcy, ceny lub normy zamawiania nie wymaga wymiany wszystkich fizycznych kart Kanban.
2.22 Parametry funkcji Kanban
Proponowana tabela parametrów:
| Parametr | Przykład |
| ------------------------------- | --------------- |
| Tryb dokumentu | PO / propozycja |
| Magazyn domyślny | 10 |
| Dostawca | główny |
| Ilość | NormaZam_KSOM |
| Operator może zmienić ilość | N |
| Operator może zmienić dostawcę | N |
| Operator może zmienić cenę | N |
| Automatyczny zapis | T |
| Automatyczny wydruk | N |
| Wzorzec ZA | ZAM-GRAF |
| Wzorzec karty | KANBAN_KIM |
| Kontrola duplikatu | T |
| Czas ochrony prostego duplikatu | 30 s |
| Wymagana akceptacja ZA | wg standardu ZA |
2.23 Wariant 'propozycja zakupu'
Należy przewidzieć możliwość pracy w dwóch trybach:
[1] skan -> [ZL] Zamówienie zakupu
lub
[2] skan -> propozycja zakupu operatora
Standardowy Trawers posiada już obie funkcje:
`DC_DZA01` - zamówienie zakupu
`DC_DZA02` - propozycja zamówienia zakupu.
Tryb `[2]` jest właściwy dla przedsiębiorstw, w których magazynier może zgłosić potrzebę,
ale formalne zamówienie musi utworzyć zaopatrzeniowiec.
2.24 Wariant SOA
Jeżeli interfejs Kanban ma być osobną aplikacją WWW, terminalem Android lub ekranem kiosku,
można wykorzystać SOA.
Trawers udostępnia:
`PurchaseOrderNew`
do utworzenia `[ZL] Zamówienia zakupu. Funkcja obsługuje m.in. dostawcę, indeks KIM,
ilość, magazyn, cenę, termin i opis pozycji.
Przykładowy przebieg:
skaner -> aplikacja Kanban -> SOA -> PurchaseOrderNew -> PrintPurchaseOrder
Ograniczenie:
w dokumentacji `PurchaseOrderNew` wskazano ograniczenie związane z walutą dostawcy -
tylko PLN i brak przeliczania ceny w walucie obcej.
Dlatego podstawowym rozwiązaniem dla pełnego zakresu ZA powinno być
rozszerzenie wewnętrznej funkcji Trawersa/DC, a wariant SOA traktowałbym
jako opcję dla konkretnych wdrożeń.
2.25 Funkcja RA_PRB20
W dokumentacji istnieje:
RA > Dostęp dostawców > Zaopatrzenie KANBAN `[RA_PRB20]`
ale oznaczono ją jako:
alfa - w przygotowaniu.
Opis mówi o zeskanowaniu przez odbiorcę etykiety pustego pojemnika jako sygnale
dla dostawcy do rozpoczęcia procesu zaopatrzenia.
Nie należy więc opierać projektu podstawowej funkcji na `RA_PRB20`.
Może ona natomiast stanowić punkt odniesienia dla późniejszego wariantu VMI / Supplier Managed Kanban.
3. Realizacja
3.1 MVP - minimalna wersja do wdrożenia
Pierwsza wersja powinna zawierać tylko:
1. jeden magazyn na stanowisko,
2. skan kodu KIM/karty,
3. automatyczny wybór głównego dostawcy,
4. ilość `NormaZam_KSOM`,
5. standardową cenę ZA,
6. utworzenie jednopozcycyjnego `[ZL]`,
7. status `[N]`,
8. brak możliwości edycji przez operatora Kanban,
9. kontrolę powtórnego skanu,
10. komunikat z numerem ZA,
11. kronikę skanów,
12. oddzielne uprawnienie do funkcji.
Bez własnego algorytmu dostawców, bez własnego kalkulatora potrzeb
i bez automatycznego wysyłania zamówienia.
3.2 Etap II
Po sprawdzeniu MVP można dodać:
* agregowanie wielu kart do jednego ZA,
* wiele magazynów,
* wiele kart dla jednego KIM,
* wybór dostawcy według rankingu,
* minimalną ilość zamówienia,
* wielokrotność opakowania,
* analizę istniejących otwartych ZA,
* automatyczną akceptację według limitów,
* automatyczny e-mail/EDI,
* panel historii Kanban,
* status fizycznej karty,
* Kanban dostawcy / VMI.
3.3 Testy akceptacyjne
T01 - poprawny skan
Dane:
KIM aktywny, dostawca istnieje, `NormaZam_KSOM > 0`, cena istnieje.
Oczekiwany wynik:
powstaje `[ZL]`, właściwy dostawca, ilość i cena; ekran pokazuje numer ZA.
T02 - nieznany kod
Nie powstaje dokument.
T03 - brak głównego dostawcy
Nie powstaje dokument.
T04 - ilość 0
Nie powstaje dokument.
T05 - brak ceny
Nie powstaje dokument.
T06 - brak uprawnień
Operator nie może uruchomić funkcji / utworzyć dokumentu.
T07 - podwójny skan
Drugi skan tej samej karty jest zatrzymany zgodnie z regułą duplikatu.
T08 - dwa pojemniki tego samego KIM
Karta `01` i karta `02` mogą utworzyć dwa poprawne sygnały.
T09 - akceptacja
Po skanie dokument znajduje się w stanie `[N]` i może zostać zaakceptowany standardową funkcją ZA.
T10 - zwykłe ZA
Operator Kanban nie może przejść do standardowej korekty zamówienia.
3.4 Kryteria odbioru
Funkcję można uznać za gotową, jeżeli:
* pracownik potrafi utworzyć prawidłowe zamówienie jednym skanem,
* nie musi znać symbolu dostawcy ani ceny,
* nie może zmodyfikować warunków zakupu,
* błędny skan nie tworzy dokumentu,
* każdy utworzony dokument można przypisać do konkretnego skanu/operatora,
* standardowy cykl ZA pozostaje niezmieniony,
* standardowe kontrole ZA są wykonywane,
* nie są wykonywane bezpośrednie zapisy omijające logikę zamówień,
* możliwe jest odróżnienie ZA utworzonych przez Kanban od pozostałych zamówień.
3.5 Rekomendacja techniczna
Najbardziej spójne z istniejącą architekturą Trawersa rozwiązanie:
| rozbudować `DC_DZA01` o specjalny tryb KANBAN albo utworzyć nową funkcję DC
| korzystającą z tej samej wewnętrznej procedury tworzenia `[ZL]`.
Schemat:
Skaner -> DC Kanban -> KIM + KSOM -> główny dostawca -> NormaZam_KSOM ->
standardowa logika ZA -> [ZL] `[N]` -> akceptacja ZA**
Nie zaleca się tworzenia równoległego minisystemu zamówień.
Takie rozwiązanie wykorzystuje funkcjonalność Kanban opisaną już w dokumentacji DC,
ale dodaje brakującą warstwę bezpieczeństwa, automatyzacji i ergonomii dla pracownika,
który nie powinien mieć pełnych uprawnień zaopatrzeniowca.
Jedna rzecz szczególnie warta decyzji przed programowaniem:
czy skan ma tworzyć od razu osobne ZA, czy dopisywać pozycję do bieżącego zamówienia
Kanban danego dostawcy.
Dla pojedynczych kart pierwszy wariant jest prostszy, ale przy 100-300 skanach dziennie
drugi może być znacznie praktyczniejszy.