--- title: "Шаблон сборки, подлежащей регулированию" slug: "regulated-assembly-template" status: "update" updated: 2026-10-22T16:05:05Z published: 2026-10-22T16:05:05Z canonical: "support.tulip.co/regulated-assembly-template" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Шаблон сборки, подлежащей регулированию :::(Info) To download this app, visit: [Library](https://library.tulip.co/apps/regulated-assembly). ::: В данной статье описаны таблицы, используемые в шаблоне сборки, а также конфигурации, необходимые для правильной работы приложения.* Шаблон предлагает два варианта запуска в зависимости от типа информации, указанной в идентификационной этикетке.* В описании также рассмотрены важные триггеры и их логика в системе. Приложение «Шаблон сборки» входит в пакет приложений Traceability App Suite. Если вы хотите узнать больше о пакете приложений Traceability App Suite, вы можете ознакомиться с дополнительной информацией по этой ссылке: [Traceability App Suite](https://library.tulip.co/suites/traceability). ## Обзор Приложение «Сборка» используется для проверки компонентов и завершения процесса сборки по выбранному производственному заданию. ![image.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28872%29.png) **Гибридная функциональность приложения Приложение**работает в гибридном режиме, сочетая как динамические, так и статические функции: - **Динамическая идентификация материалов:** - Приложение динамически управляет идентификацией материалов, что означает, что оно без проблем обрабатывает изменения идентификаторов материалов компонентов. - **Статические инструкции по сборке:** - Инструкции по сборке зафиксированы в приложении, что гарантирует: даже если материалы компонентов могут меняться, процесс сборки продукта остаётся неизменным. **Преимущества гибридного подхода** - **Простота управления:** - При таком подходе вам больше не нужно обновлять приложение каждый раз при смене материала. Вам не нужно повторно тестировать или утверждать приложение при каждом обновлении материалов. - **Эффективные обновления:** - При изменении материалов необходимо обновлять только таблицу спецификации (BOM), что упрощает процесс и снижает необходимость в частых обновлениях приложения. Это гибридное решение обеспечивает более гибкий и удобный интерфейс, оптимизируя процессы и сводя к минимуму сбои при изменении материалов. ## Таблицы Tulip в приложении ### Комментарии и исключения В приложении «Сборка» комментарии, созданные в ходе процесса, сохраняются в таблицах «Комментарии» и «Исключения». При создании комментария приложение автоматически сохраняет в таблице «Комментарии» следующие сведения: - Идентификатор производственного задания — указывает конкретное производственное задание, в рамках которого был сделан комментарий. - Идентификатор родительского материала — связывает комментарий с соответствующим материалом. - Название приложения — название приложения, в котором был записан комментарий. - Название этапа — конкретный этап процесса, на котором был создан комментарий. - Описание оператора — текст, введенный оператором. - Изображение — если оператор прикрепляет изображение, оно сохраняется вместе с комментарием. Каждому новому комментарию присваивается статус **«NEW** » и тип **«MANUAL**». Такая структура гарантирует надлежащее отслеживание всех комментариев, что упрощает анализ проблем, отслеживание введенных оператором данных и ведение четкой документации на протяжении всего процесса сборки. ### (Операционный артефакт) Заказы на работу Производственные требования вашего предприятия. Они формируются на основе заказов и представляют собой запрос на конкретные материалы, которые необходимо произвести для выполнения заказа. В приложении «Сборка» система изменяет количество выполненных работ по текущему производственному заданию в ходе процесса. Это означает, что по мере продвижения работ система динамически обновляет поле «Выполненное количество», чтобы отразить производственные данные в режиме реального времени. Это гарантирует, что операторы и супервайзеры всегда имеют точное представление о том, какой объем работы был выполнен в рамках конкретного производственного задания. ### (Журнал) Единицы Мы храним компонентные и родительские материалы в таблице «Единицы учета». В группе приложений «Регулируемые» мы отслеживаем процесс с помощью статуса родительской единицы. Статусы следующие: ![image.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28865%29.png) Когда в начале работы приложения «Сборка» выбирается родительская единица, её статус автоматически обновляется до **«В СБОРКЕ**». По завершении процесса сборки статус меняется на **«ОЖИДАЕТ ПРОВЕРКИ**». Статус **«ОЖИДАЕТ ПРОВЕРКИ** » запускает процесс автоматизации. ### (Журнал) Генеалогия Каждая запись представляет собой отношения «родитель-потомок». Потомком может быть как сериализованная, так и несериализованная подсборка или отдельная деталь. **Ключевые поля:** **Идентификатор родительского узла**— уникальный идентификатор родительской сборки, ссылающийся на соответствующую запись узла из таблицы узлов.**Идентификатор определения материала родительской единицы: представляет**определение материала родительской единицы, ссылаясь на таблицу определений материалов.**Идентификатор компонентной единицы**: уникальный идентификатор компонентной единицы (которая может быть серийной или несерийной подсборкой либо отдельной деталью).**Идентификатор определения материала компонента: ссылка**на таблицу определений материалов для компонентной единицы/детали.**Идентификатор производственного заказа**: связывает отношения «родитель-потомок» с конкретным производственным заказом из таблицы производственных заказов. ## Кнопки моделирования ![image.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28874%29.png) В приложении отображаются несколько кнопок розового цвета. Эти кнопки предназначены **исключительно для демонстрационных целей** и позволяют пользователям моделировать работу приложения с использованием предопределенных данных после его загрузки. **Важные примечания:** - В окончательной производственной среде они не нужны — эти кнопки предназначены только для симуляции. - Перед развертыванием приложения в рабочей среде эти кнопки необходимо удалить, чтобы обеспечить чистую и точную конфигурацию производственной среды. ## Настройка и персонализация Для использования ряда функций приложения требуется сканер штрих-кодов. Более подробную информацию о настройке сканеров штрих-кодов можно найти по следующей ссылке:[Как настроить сканер штрих-кодов](https://support.tulip.co/docs/how-to-set-up-a-barcode-scanner) Кроме того, для печати этикеток необходимо настроить принтер. Среди поддерживаемых принтеров — принтеры Zebra; руководство по их настройке можно найти здесь:[Как интегрировать принтер Zebra с Tulip](https://support.tulip.co/docs/how-to-integrate-a-zebra-printer-with-tulip) ### Параметры выбора в приложении Приложение предлагает два варианта на выбор. Выберите тот, который лучше всего соответствует вашим потребностям — другой вариант можно отключить. **Вариант 1: Сканирование идентификатора единицы*** Сканируемый штрих-код содержит идентификатор собранной единицы.* Приложение отображает в таблице список единиц со статусом **«KITTED** ».* После выбора единицы приложение переходит к этапу «Подтверждение», где вы можете увидеть подробную информацию о рабочем заказе.* После подтверждения процесс переходит к этапу «Идентификация материалов». **Вариант 2: Сканирование идентификатора производственного задания*** Этикетка содержит **идентификатор производственного задания** вместо **идентификатора единицы**.* После сканирования производственного задания приложение переходит непосредственно к этапу «Подтверждение», отображая подробную информацию о производственном задании.* Приложение также выводит список всех единиц со статусом **«KITTED»**, связанных с данным производственным заданием.* После выбора соответствующего устройства процесс продолжается этапом «Подтверждение». Следуя этим шагам, вы сможете эффективно настроить и адаптировать приложение под свой рабочий процесс ## Основные триггеры и логика в приложении ### Этап «Идентификация материалов» - При переходе к этапу «Идентификация материалов», если переменные **componentList** и **genealogyIdList** пусты, списки заполняются с помощью агрегаций. - В процессе агрегации для загрузки списков используются идентификатор производственного заказа (Work Order ID) и идентификатор родительской единицы (Parent Unit ID). - **componentList**: этот список заполняется идентификаторами компонентов (номерами партий). - **genealogyIdList**: этот список заполняется идентификаторами записей в таблице. **Процесс сканирования** - В ходе процесса сканирования сканируется идентификатор единицы материала. - Если отсканированный идентификатор присутствует в списке **componentList**, происходит следующее: - Триггер «Сканирование идентификатора единицы компонента» удаляет отсканированный идентификатор единицы из списка componentList и переносит его в переменную scannedComponentList. - Переменная scannedComponentList используется для фильтрации таблицы «Компоненты, подтвержденные для сборки». **Автоматический переход к этапу сборки** - Как только все идентификаторы компонентов будут определены и подтверждены, приложение автоматически перейдёт к этапу сборки. ### Этап сборки На этапе сборки вы можете добавить видеоинструкцию или изображение вместе с текстовым описанием, чтобы помочь пользователям в процессе сборки. - При необходимости процесс можно разбить на несколько этапов. - Для подтверждения завершения каждого этапа можно использовать флажки, что гарантирует правильное соблюдение рабочего процесса. - В разделе «Правила проверки» окна виджета можно пометить определенные флажки как обязательные для заполнения. **Логика проверки и взаимодействия**. К кнопке «Завершено» можно добавить логику, чтобы с ней нельзя было взаимодействовать до тех пор, пока не будут заполнены все обязательные поля (например, флажки обязательных полей). Это гарантирует, что ни один этап не будет пропущен и процесс сборки будет завершен правильно, как показано в этом примере шаблона. ### Этап обработки данных На этом этапе триггер «Обработка данных» отвечает за обновление значений QTY в таблице «Единицы» после завершения процесса сборки. **На этапе работы приложения «Комплектация»** количество единиц компонентов уменьшается на указанные величины**,** и такие же количества добавляются в поле «Зарезервированное количество». Это обеспечивает точность данных об уровне запасов материалов на складе. По завершении сборки приложение уменьшает зарезервированное количество для соответствующих единиц компонентов на основе количества, необходимого для сборки продукта (определяемого количеством компонентов в записи генеалогии). **Результаты автоматизации. Кроме того**, этот этап включает таблицу, отображающую результаты автоматизации. Автоматизация генерирует записи о результатах проверки для узлов подсборки, находящихся в статусе «В ОЖИДАНИИ ПРОВЕРКИ», на основе плана отбора проб. **Дополнительные настройки**При необходимости таблицу и кнопку «Далее» можно удалить (из этого шага), а триггер обработки данных можно настроить таким образом, чтобы при опустошении переменной genealogyIdList система автоматически переходила к следующему шагу. ## Дополнительная информация [Набор приложений для обеспечения прослеживаемости](https://library.tulip.co/suites/traceability)