Вакансии/производственные заказы

Интеграция работ/производственных заказов между V5 Traceability и ERP-системой клиента позволяет планировать рабочие задания для формул партий и продуктов в V5 Traceability. Эти данные затем позволят обрабатывать эти задания терминалом V5.

1. Компоновка центра управления
2. Ссылки API
3. Шаблон интеграции
4. Полевое руководство по заданию/производственному заказу
   1. Первичные ключи
   2. Обязательные поля
   3. Предпочтительные поля
   4. Дополнительные поля
5. Методология
   1. JSON — импорт
   2. JSON — Экспорт
   3. CSV – Импорт
   4. CSV — Экспорт

Что касается того, как мы можем связать детали задания с тем, что мы видим в Центре управления, мы будем использовать API V5 в первую очередь для заполнения верхней панели «Задание» для импорта и экспорта этих данных с информацией на нижней панели «Строка задания». заполняется автоматически на основе настройки формулы/рецепта.

Используя шлюз V5, мы можем легко заполнить данные здесь, используя ‘Job’ конечная точка. Однако можно использовать более продвинутый подход, использующий ‘PreBatch’ конечная точка. Мы рассмотрим использование обоих из них ниже.

Чтобы узнать больше об определениях этих классов базы данных, перейдите по следующим ссылкам:

Job

PreBatch

Шаблон интеграции для «Работы/Производственные заказы» можно скачать. здесь.

Первичные ключи — это уникальный идентификатор для каждой таблицы в V5 API. Для Job, эти:

jobNumber – Уникальный идентификационный код вакансии.

formula.commodity.code – Уникальный идентификационный код формулы, подлежащей планированию.

Для пакетов PreBatch, первичные ключи:

jobLine.job.jobNumber – Как указано выше, уникальный идентификационный код задания.

BatchSeq – Последовательность производства партии для этой конкретной линии работ.

Другие поля необходимы SG для заполнения действительной строки задания в Центре управления. Для Job, это:

products – Количество требуемых продуктов (отнесенное к базовой единице измерения формулы) на партию в верхней строке (задания) этого задания.

Для пакетов PreBatch, это:

products – Количество продукции, которую должна произвести отдельная партия.

Предпочтительные поля служат для добавления дополнительной информации о рассматриваемом задании и, хотя и не являются обязательными, полезны, когда речь идет о дополнительных функциях в рамках V5 Traceability. Для Job, они могут включать в себя:

batchesRequired – Количество партий, необходимое для работы. Если его нет, то система будет использовать количество товаров (описанное выше) и базовый размер + мин/макс продукты рассчитать количество партий для производства.

status – Статус, с которым будет импортировано задание (0 = Ожидание, 1 = Запланировано, 2 = В процессе, 3 = Завершено, 4 = Тестирование, 5 = Приостановлено). Обычно задания импортируются со статусом «1». если только они не будут запланированы вручную на более поздний срок и поэтому могут быть импортированы со статусом «0».

Эти поля также могут применяться к PreBatch как только мы перешли к объекту задания в API.

Дополнительные поля также могут быть включены для Job конечная точка, например:

productionDate – Дата, когда задание должно быть выполнено. Если он отсутствует, импортируется как пустой, что позволяет терминалам всегда видеть задания.

Для пакетов  PreBatch, мы можем перейти к этому же полю под jobLine.job.productionDate. Однако мы также можем использовать jobLine.productionDate поле, чтобы повлиять на дату производства отдельной линии работ, а не на всю работу в целом, что позволяет нам более жестко контролировать наш производственный процесс.

В зависимости от метода, используемого для нашей интеграции, мы можем использовать следующие конечные точки для облегчения импорта. Это может быть либо:

• ‘Job’ or ‘Prebatch’ конечные точки для интеграции JSON.
• ‘Job’ конечная точка для интеграции файлового ресурса CSV.

Экспорт можно осуществлять различными способами, все из которых мы рассмотрим ниже.

Профессия:

Мы можем использовать ‘Job’ конечная точка для создания новых рабочих мест для производства в V5 Traceability.

‘Job’ импортировать конечную точку/URI –

http://host:port/V5-API/api/integrate/import/job

Описание конечной точки

Для этого примера импорта с помощью ‘Job’ конечную точку, мы можем структурировать базовый файл импорта для одного задания, как показано ниже:

Этот образец файла JSON можно загрузить здесь.

Используя руководство по API, мы видим, что используем несколько точек данных в ‘Job’ класс для структурирования этого файла. Однако, чтобы правильно вызвать код формулы, которую мы хотим создать, нам нужно сначала перейти к ‘Formula’ класс, а затем используйте ‘Commodity’ класс для определения ‘Code’ точку данных, которую мы можем использовать, а затем соответствующим образом вставить ее в файл JSON, как мы видим выше.

Мы можем увидеть сводку этого процесса потока данных ниже:

Если мы запустим файл JSON, указанный выше, мы увидим, что наше задание теперь отображается на вкладке «Производство» в Центре управления.

Вы заметите, что это автоматически создало строки задания на нижней панели. ‘Job’ конечная точка сделает это автоматически на основе структура формулы.

Предварительная партия:

Как мы видим выше, мы можем использовать ‘Job’ конечная точка для ввода простых заданий в производственный план в V5 Traceability. Однако, если нам нужен более точный контроль над настройкой задания, мы можем использовать ‘PreBatch’ Вместо этого URI. Это позволяет нам указать такие детали, как размер отдельной партии/количество продукции и место производства.

‘PreBatch’ импортировать конечную точку/URI –

http://host:port/V5-API/api/integrate/import/pre_batch

Описание конечной точки

Для этого примера импорта с помощью ‘PreBatch’ конечную точку, мы можем структурировать базовый файл импорта для одного задания с несколькими пакетами, как показано ниже.

Этот образец файла JSON можно загрузить здесь.

Итак, изучив этот файл, мы видим, что создаем новое задание (Задание-111) с двумя партиями формулы «Базового хлебного теста», одной на 2 фунтов, которая должна быть изготовлена ​​на производстве 30, и другой на 1 фунтов, которая должна быть изготовлена. сделано на производстве 50. Если мы посмотрим руководство API для ‘PreBatch’ class, то мы увидим здесь аналогичный метод обхода для создания нашего файла.

Если мы запустим приведенный выше файл JSON, мы увидим, что это новое задание создано, а затем, если мы посмотрим на представление партии для него, мы увидим различия в размерах партий/местах производства, а также в наших предустановленных настройках. номера партий. При желании сюда также можно включить пакетное секвенирование.

Что касается получения файлов, относящихся к заданиям, обратно из API V5, мы можем использовать несколько различных вариантов классов IntegrationExport и ExportTransaction, которые мы рассмотрим здесь.

Профессия:

Конечная точка/URI экспорта отдельных заданий –

http://host:port/V5-API/api/integrate/export/job/{jobNumber}

Описание конечной точки 

Эта конечная точка экспортирует файл JSON со всей связанной информацией для указанного задания. Если мы запустим этот запрос, используя номер только что импортированного задания, мы получим файл, который выглядит примерно так:

Пример JSON-файла этого типа можно скачать. здесь.

Все вакансии:

Конечная точка/URI экспорта всех заданий

http://host:port/V5-API/api/integrate/export/jobs

Описание конечной точки

Эта конечная точка экспортирует файл JSON, содержащий список всех активный задания в системе, определяемые как задания, имеющие статус, отличный от «завершенного», или удаленные из Центра управления.

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

Образцы JSON-файлов этого типа можно скачать здесь.

Мы также можем использовать конечные точки транзакций и журналов для получения более актуальной информации о рабочих местах и ​​производственных заказах.

Для пакетов  Системный журнал конечные точки, это:

Журналы заданий

Потребляемые/создаваемые системные журналы

Имя файла определения заголовка/столбца: “job.csvh”

Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\import\column_defs”

Импортировать имя файла CSV: “job-datetime.csv”

CSV для импорта должны быть размещены в: “<installdir>\SG Control Center\gateway\import”

Заголовочный файл:

Файлы заголовков обычно компилируются SG Systems до интеграции CSV, но мы можем увидеть базовый пример того, который мы можем использовать для заданий, используя ранее определенный определения классовниже:

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

Файл импорта CSV:

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

Пример файла импорта CSV для заданий может выглядеть примерно так:

Этот пример файла импорта можно загрузить здесь.

После завершения импорта мы видим, что эти дополнительные задания были добавлены в Центр управления вместе с заданием, которое мы создали с помощью импорта JSON выше.

Как и в случае с экспортом JSON, здесь у нас есть несколько разных вариантов. Мы можем начать с простого экспорта списка вакансий внутри системы:

Вакансии/График:

Экспортировать имя файла CSV: “job.csvh”

Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\export/order”

Экспортировать имя файла CSV: “job-datetime.csv”

CSV для экспорта будут созданы в: “<installdir>\SG Control Center\gateway\export”

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

Этот экспорт необходимо будет включить в разделе «Шлюз» Центра управления. Здесь мы можем выбрать экспорт «Расписания».

Заголовочный файл:

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

Файл экспорта CSV:

Мы получим ответный CSV-файл, который будет выглядеть примерно так:

Пример этого типа файла можно скачать здесь. Обратите внимание: если файл заголовка отсутствует в указанной папке, будет экспортирован файл CSV, содержащий все точки данных в папке. ‘Job’ класса.

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

Пакетные журналы:

Экспортировать имя файла CSV: “BatchLog-datetime.csv”

CSV для экспорта будут созданы в: “<installdir>\SG Control Center\gateway\export”

Самый простой способ получить данные о производстве заданий из V5 Traceability в форме CSV — просто использовать и обрабатывать «пакетные журналы».

Опять же, этот экспорт также необходимо будет включить в разделе «Шлюз» Центра управления. Здесь мы можем выбрать экспорт «Пакетных журналов».

Файл экспорта CSV:

Нам не нужно будет создавать здесь заголовочный файл, поскольку шлюз V5 по умолчанию заполнит заданный список точек данных. Если этот экспорт включен, система будет экспортировать ‘BatchLog’ файл каждый раз, когда пакет задания завершается системой. Базовый пример этого показан ниже:

Пример этого типа файла можно скачать здесь.

Системный журнал:

Если мы хотим получать более индивидуальные или подробные данные о производстве работ (‘CONSUMED’/’PRODUCE’) Однако, вернувшись из V5 Traceability, мы можем использовать ‘SystemLog’ конечная точка для этого.

Имя файла определения заголовка/столбца: “SystemLog.csvh”

Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\export\order”

Экспортировать имя файла CSV: “SystemLog-datetime.csv”

CSV для экспорта будут созданы в: “<installdir>\SG Control Center\gateway\export”

Для этого типа экспорта с использованием этой конечной точки мы структурировали бы наш заголовок, используя ‘SystemLog’ определения классов базы данных.

Как и в других примерах выше, этот экспорт необходимо включить в разделе «Шлюз» Центра управления:

Заголовочный файл:

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

Этот образец заголовочного файла можно загрузить здесь.

Файл экспорта CSV:

Если мы затем запустим простой пакетный анализ, экспорт системного журнала будет выглядеть примерно так:

Этот пример экспорта можно скачать здесь.