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

Обзор

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

Заказы на фундаментальном уровне просты. Они имеют набор атрибутов и набор входных данных. Таблица [Orders] является местом хранения "метаданных" заказа.

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

Таблицы

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

Данное приложение опирается на одну таблицу [Orders].

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

Таблица [Orders]

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

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

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

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

ID (Текст)- Все таблицы нуждаются в столбце ID для уникального представления каждой записи таблицы. В данном примере мы используем в качестве идентификатора номер заказа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scheduled Manufacture Date (Datetime) - Когда этот заказ должен быть запущен, чтобы он был доставлен вовремя?

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

Complete Date (Datetime) - Когда заказ был завершен?

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

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

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

:::(Warning) (Внимание) В данном Functional Example таблица [Materials] не используется. :::

Customer (Text) - В этом поле хранятся имена клиентов, их идентификаторы и т.д.