MENU
    Модель данных для отслеживания заказов
    • 10 Jan 2025
    • 3 Минуты для чтения
    • Авторы

    Модель данных для отслеживания заказов


    Вводный текст

    Обзор

    Правильная архитектура данных имеет решающее значение для принятия правильных мер по улучшению процессов. Данные никогда не бывают универсальными, поскольку решаемые проблемы редко бывают одинаковыми. В этом {{глоссарий.Функциональный пример}} описана основная минимальная модель данных, рекомендуемая для отслеживания заказов.

    Заказы на фундаментальном уровне просты. У них есть набор атрибутов и набор входных данных. Таблица [Заказы] - это место, где хранятся "метаданные" заказа.

    В документе "Расширение концепции" рассматриваются некоторые способы построения этой модели данных для получения еще большей ценности.

    Таблицы

    Это приложение использует таблицы для хранения данных. Это рекомендуется (вместо использования дополнений), потому что это означает, что одна и та же таблица может использоваться в нескольких приложениях, что является критической характеристикой Composability.

    Это приложение опирается на единственную таблицу [Заказы].

    В разделе"Расширение концепции" рассматривается, как эту таблицу можно объединить со связанной записью в таблице [Материалы] для отслеживания зависимых материалов.

    Таблица [Заказы]

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

    Таблица Orders - это "голые кости", необходимые для обеспечения видимости вашего процесса. Некоторые поля записей таблицы являются необязательными, а другие действительно необходимы для обеспечения видимости ваших операций.

    Имейте в виду, что эти поля не обязательно должны заполняться человеком. Информация о заказе может поступать из внешнего источника данных или выводиться на основе условной логики.

    Например. В начале заказа в этом Functional Example статус заказа установлен на OPEN

    Обязательные поля

    ID (Текст)- Все таблицы нуждаются в столбце 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


    Номер материала (Текст) - Номер материала в данном случае - это номер детали (или SKU), которую производит данный заказ. Поскольку это не поле идентификатора, несколько записей (заказов) могут использовать один номер материала.


    Целевое количество (Число) - Количество единиц, необходимое для выполнения заказа.


    Статус (Текст) - текущее состояние этого заказа. В нашем примере заказы проходят через 6 статусов:

    1. НОВЫЙ
    2. ВЫПУЩЕН
    3. В ПРОЦЕССЕ ВЫПОЛНЕНИЯ
    4. ЗАВЕРШЕН
    5. В РЕЗЕРВЕ
    6. ОТМЕНЕН

    Дата выполнения (дата) - без установленной даты приоритезация работы может стать серьезной проблемой.


    Необязательные поля

    Описание материала (Текст)- Любая семантическая информация, которая может помочь вашим операторам лучше понять, что они делают.

    Например, я не знаю, что такое PN-24136, но описание материала - это "болт 3/16x2", поэтому я могу действовать в соответствии с заказом.


    Фотография материала (Image)- необязательная фотография конечного продукта, который будет произведен.


    Final Quantity (Number)- Как следует из названия, это конечное количество деталей. Предполагается, что это поле может использоваться для окончательного подсчета деталей отделом качества или отделом доставки перед отправкой заказа.


    Единица измерения (Текст) - В каких единицах описывается производимый материал? Это поле можно использовать, чтобы сообщить, нужно ли изготовить 15 унций продукта или 15 тонн продукта.


    Тип (Текст) - это категория более высокого уровня для заказа, которая может использоваться для группировки заказов.

    Например. Мы всегда выполняем задания по печати в начале недели, чтобы не чистить машины дважды, поэтому всем заказам на печать присваивается тип PRINTING, чтобы их можно было поставить на первое место.


    Планируемая дата производства (дата) - Когда следует начать выполнение этого заказа, чтобы он был доставлен вовремя?


    Дата производства (дата) - Когда фактически началось производство?


    Дата завершения (Дата) - Когда заказ был завершен?


    Текущее местоположение (Текст) - текущее местоположение заказа. Невероятно полезно на больших предприятиях, чтобы убедиться, что готовая продукция может быть найдена.


    Материалы (Связанная запись) - Материалы - это поле связанной записи в таблице [Материалы]. Это поле предназначено для связи материалов, необходимых для выполнения данного заказа, с родительским заказом.

    Здесь также может храниться {{глоссарий.BOM}} для вашей сборки.

    Warning

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


    Клиент (Текст) - В этом поле можно хранить имена клиентов, их идентификаторы и т. д.


    Была ли эта статья полезной?