MENU
    Model danych śledzenia zamówień
    • 10 Jan 2025
    • 4 Minuty do przeczytania
    • Współtwórcy

    Model danych śledzenia zamówień


    Streszczenie artykułu

    Przegląd

    Właściwa architektura danych ma kluczowe znaczenie dla podejmowania właściwych działań w celu usprawnienia procesu. Dane nigdy nie są uniwersalne, ponieważ rozwiązywane problemy rzadko są identyczne. Niniejszy Functional Example przedstawia podstawowy minimalny model danych zalecany do śledzenia zamówień.

    Zamówienia na podstawowym poziomie są proste. Mają zestaw atrybutów i zestaw danych wejściowych. Tabela [Orders] to miejsce, w którym przechowywane są "metadane" zamówienia.

    W dokumencie Rozszerzenie koncepcji omówiono kilka sposobów, w jakie ten model danych może zostać zbudowany, aby zapewnić jeszcze większą wartość.

    Tabele

    Ta aplikacja opiera się na tabelach do przechowywania danych. Jest to zalecane (zamiast używania Completions), ponieważ oznacza to, że ta sama tabela może być używana w wielu aplikacjach, co jest krytyczną cechą Composability.

    Ta aplikacja opiera się na pojedynczej tabeli [Orders].

    Extend the Concept obejmuje sposób, w jaki ta tabela może zostać połączona z Linked Record do tabeli [Materials] w celu śledzenia zależnych materiałów.

    Tabela [Orders]

    https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Orders.png

    Tabela Orders to podstawowe dane potrzebne do zapewnienia widoczności procesu. Niektóre pola rekordu tabeli są opcjonalne, a inne są naprawdę wymagane do utrzymania widoczności operacji.

    Należy pamiętać, że pola te niekoniecznie muszą być wypełniane przez osobę. Informacje o zamówieniu mogą pochodzić z zewnętrznego źródła danych lub zostać wywnioskowane na podstawie logiki warunkowej.

    Przykład. Na początku zamówienia w tym Functional Example status zamówienia jest ustawiony na OPEN.

    Wymagane pola

    ID (Text)- Wszystkie tabele potrzebują kolumny ID, aby jednoznacznie reprezentować każdy rekord tabeli. W tym przypadku używamy numeru zamówienia jako ID.

    Warning

    Record IDs cannot be used for multiple records, so if your process might have 2 orders with the same order number, we would recommend using a prefix or suffix to insure the record ID is unique


    Numer materiału (Tekst) - Numer materiału dla tego przypadku użycia to numer części (lub SKU), którą produkuje to zamówienie. Ponieważ nie jest to pole ID, wiele rekordów (zamówień) może współdzielić jeden numer materiału.


    Target Quantity (Number) - liczba jednostek wymagana do zrealizowania zamówienia.


    Status (Tekst) - aktualny stan tego zamówienia. W naszym przypadku zamówienia przechodzą przez 6 statusów:

    1. NOWE
    2. ZŁOŻONE
    3. W TRAKCIE REALIZACJI
    4. ZAKOŃCZONE
    5. WSTRZYMANE
    6. ANULOWANE

    Due Date (Datetime) - Bez daty docelowej, ustalenie priorytetów pracy może być sporym wyzwaniem.


    Pola opcjonalne

    Opis materiału (tekst) - wszelkie informacje semantyczne, które mogą pomóc operatorom lepiej zrozumieć, co robią.

    Na przykład - nie wiem, co to jest PN-24136, ale opis materiału to "śruba 3/16x2", więc mogę działać zgodnie z zamówieniem.


    Zdjęcie materiału (Image) - opcjonalne zdjęcie produktu końcowego, który ma zostać wyprodukowany.


    Final Quantity (Number) - jak sama nazwa wskazuje, jest to ostateczna ilość części. W zamierzeniu pole to może być wykorzystane do ostatecznego zliczenia części przez dział jakości lub dział wysyłki przed wysłaniem zamówienia.


    Jednostka miary (tekst) - Jaka jest jednostka opisująca produkowany materiał? To pole można wykorzystać do poinformowania, czy mają wyprodukować 15 uncji produktu, czy 15 ton produktu.


    Typ (tekst) - jest to wyższa kategoryzacja zamówienia, która może być wykorzystana do grupowania zamówień.

    Np. Zawsze uruchamiamy zadania drukowania na początku tygodnia, aby maszyny nie musiały być czyszczone dwa razy, więc wszystkie zamówienia drukowania mają typ DRUKOWANIE, dzięki czemu mogą być traktowane priorytetowo w pierwszej kolejności.


    Scheduled Manufacture Date (Datetime) - Kiedy należy rozpocząć realizację tego zamówienia, aby mieć pewność, że zostanie ono dostarczone na czas?


    Manufacture Date (Datetime) - Kiedy faktycznie rozpoczęła się produkcja?


    Complete Date (Datetime) - Kiedy zamówienie zostało ukończone?


    Current Location (Text) - bieżąca lokalizacja zamówienia. Niezwykle przydatne w większych obiektach, aby upewnić się, że można znaleźć gotowe towary.


    Materials (Linked Record) - Materiały to pole powiązane z tabelą [Materials]. Pole to ma na celu powiązanie materiałów wymaganych do realizacji tego zamówienia z zamówieniem nadrzędnym.

    Jest to również miejsce, w którym można przechowywać BOM dla zespołu.

    Warning

    In this Functional Example, The [Materials] table is not being used.


    Customer (Text) - To pole jest miejscem do przechowywania nazw klientów, identyfikatorów klientów itp.


    Czy ten artykuł był pomocny?