Инвентарь/место на складе
Ваш путеводитель по интеграции V5!
Интеграция Inventory/Stack Location между V5 Traceability и ERP-системой клиента позволяет товар сведения о запасах, такие как номера партий, количество в наличии и местонахождение, для отправки в V5 Traceability. Эти детали затем позволят использовать такие товары для производства/заказа и т. д.
В зависимости от нашей настройки ERP существует несколько различных способов обработки запасов/запасов:
- ERP как складской мастер: Здесь ERP будет передавать данные о запасах в V5, а затем V5 будет возвращать корректировки/потребление/производство/и т. д. (самый распространенный) (запас в наличии, выход из системы). Это можно сделать 2 способами; Обновленная стоимость запасов из журнала (лот 123 теперь составляет 50 фунтов); Или вы можете посмотреть значение корректировки в журнале (Lot123 -50LBS). Первый вариант обеспечивает большую синхронизацию, но имеет больше шансов пропустить транзакцию.
- V5 в качестве стокового мастера: V5 передает данные инвентаризации в ERP. Затем ERP через регулярные промежутки времени возвращает обновленные уровни запасов. (в наличии, в наличии)
- ERP как складской мастер: ERP передает запасы V5, затем V5 регулярно возвращает данные об уровне запасов, а ERP обновляет свой подсчет. Это выгодно, потому что ERP и V5 всегда синхронизируются. Однако это может быть проблематично из-за времени и частоты синхронизации, особенно если запасы могут быть вычтены в самой ERP, эти скорректированные уровни могут быть перезаписаны при следующей синхронизации V5. Этот метод может быть полезен, если ERP/MRP не корректирует запасы напрямую, а просто хранит их для финансовых данных. (в наличии, в наличии)
Если вы не уверены в том, какой путь лучше выбрать для вашей конкретной настройки ERP, SG Systems может организовать консультационную сессию, чтобы наилучшим образом оценить оптимальную методологию для вашей системы.
Содержание
1. Схема центра управления
С точки зрения того, как мы можем связать детали инвентаря/местоположения запасов с тем, что мы видим в Центре управления, мы будем использовать эту конечную точку в первую очередь для заполнения нижней левой панели для импорта и экспорта наших уровней/местоположений запасов для существующих товаров.
Используя шлюз V5, мы можем легко заполнить данные здесь, используя две конечные точки: ‘Stock’ и ‘StockLocation’.
2. API-ссылки
Чтобы узнать больше об определениях этих классов базы данных, перейдите по следующим ссылкам:
3. Шаблон интеграции
Шаблон интеграции для Stock Location можно скачать здесь.
4. Полевое руководство StockLocation
4.1. Первичные ключи
Первичные ключи — это уникальный идентификатор для каждой таблицы в V5 API. Для StockLocation, эти:
location.code – Уникальный идентификационный код для расположение склада.
stock.commodity.code – Уникальный идентификационный код для товар
stock.lotNo – Номер партии акции.
Для пакетов Stock, первичные ключи:
lotNo – Номер партии акции.
commodity.code – Уникальный идентификационный код товара.
Обратите внимание, что номера партий могут генерироваться системой автоматически или вводиться вручную. Номера партий поставщиков можно ввести в поле, описанное ниже. Номера лотов могут генерироваться глобально (не может быть двух одинаковых номеров лотов) или для каждого товара.
4.2. Обязательные поля
Другими полями, которые необходимы SG для заполнения действительной товарной строки в Центре управления V5, являются:
stock.expiry - Срок годности конкретного лота.
qty – количество товара в этой партии.
4.3. Предпочтительные поля
Предпочтительные поля служат для добавления дополнительной информации о рассматриваемом товаре, и, хотя они и не обязательны, они полезны, когда речь идет о дополнительных функциях в рамках V5 Traceability.
stock.supplier.code – Код поставщика, предоставившего партию товара.
stock.cost – Стоимость (за единицу измерения) товара.
stock.dateReceived – Дата, когда партия была зарегистрирована в запасах.
stock.supplierLotNo – Номер партии, присвоенный поставщиком.
4.4. Дополнительные поля
Также могут быть включены дополнительные поля, например:
stock.commodity.description – Описание товара.
stock.commodity.units.code – Единица измерения товара по умолчанию.
stock.commodity.recordStock – Будет ли отслеживаться использование этого товара с помощью V5 Traceability.
Обратите внимание, что эти дополнительные поля можно использовать для создания записей о товарах в V5 Traceability, а также для присвоения им складских местоположений и количеств. При использовании CSV-метод обмена данными мы должны убедиться, что «Создать дочерние объекты» выбрано в «Шлюзе» Центра управления. Однако существующие товары не могут быть обновлены в V5-API используя эту конечную точку, вместо этого мы должны обращаться к ним напрямую, используя 'Товарвместо этого конечная точка.
5. Методология
В зависимости от цели нашей API-интеграции мы можем использовать ‘StockLocation’ or ‘Stock’ конечная точка для импорта и экспорта JSON и CSV. Теперь мы можем посмотреть на это ниже.
5.1. JSON — Импорт
StockLocation:
Мы можем использовать ‘StockLocation’ конечная точка для вставки записей о запасах товаров (существующих или нет) в V5 Traceability, которые содержат информацию, касающуюся дат получения/срока годности, номеров партий/партий поставщиков и, конечно же, местонахождения запасов.
‘StockLocation’ импортировать конечную точку/URI –
http://host:port/V5-API/api/integrate/import/stock_location
Для этого примера импорта с помощью ‘StockLocation’ конечной точки, мы можем структурировать базовый файл импорта для одного лота, как показано ниже:
Этот образец файла JSON можно загрузить здесь.
Используя руководство по API, мы можем видеть здесь, что мы используем только ‘qty’ значение от ‘StockLocation’ class со всеми остальными значениями, вложенными либо в ‘stock’ or ‘location’ сорт. Мы также можем видеть, что ‘code’ и ‘units’ точки данных вложены дальше под ‘commodity’ класса.
Мы можем увидеть сводку этого процесса потока данных ниже:
Если мы запустим файл JSON выше, мы увидим, что наш лот для товара ‘I015’ (Jalepenos) теперь этот лот импортирован в Центр управления.
Однако то, что мы не можем сделать с ‘StockLocation’ конечной точкой являются значения изменения, такие как номер партии поставщика и дата истечения срока действия существующих запасов. Для этого нам потребуется использовать ‘Stock’ конечная точка.
Наличие на складе:
Как уже упоминалось выше, ‘StockLocation’ конечная точка может использоваться для вставки записей о запасах и связанных с ними местоположений. Однако, если мы хотим обновить и детали для этих лотов, которые подпадают под ‘Stock’ заголовок, мы должны использовать ‘Stock’ конечная точка. Это включает в себя такие детали, как номер партии поставщика, срок годности и полученный вес.
‘Stock’ импортировать конечную точку/URI –
http://host:port/V5-API/api/integrate/import/stock
Для очень простого ‘Stock’ import, который обновит дату истечения срока действия и номер партии поставщика партии, которую мы создали выше, мы можем использовать следующее:
В результате информация о партии обновляется в V5:
5.2. JSON — Экспорт
Что касается получения файлов, относящихся к местонахождению складских запасов, из V5 API, если мы проверим сводку методов в разделе IntegrationExport класс, мы могли бы подумать, что ‘StockLocations’ (export/locations/stock) будет то, что мы ищем. Однако это не так, поскольку эта конечная точка будет экспортировать список местоположений складов (вместо производственных мест), которые существуют в системе.
Чтобы получить информацию о местоположении и уровне запасов для наших товаров, мы можем использовать:
Индивидуальный товар + лот:
Экспорт конечной точки/URI –
http://host:port/V5-API/api/integrate/export/stock/{commodityCode}/{lotNumber}
Эта конечная точка будет экспортировать файл JSON со всей связанной информацией для указанной партии отдельного товара. Если мы запустим этот запрос, используя только что импортированную информацию о лоте, мы получим файл, который выглядит примерно так:
Образцы JSON-файлов этого типа можно скачать здесь.
Весь запас:
Экспорт конечной точки/URI –
http://host:port/V5-API/api/integrate/export/stock/{all}
Эта конечная точка будет экспортировать файл JSON, который включает список всей связанной информации для всех партий каждого товара в системе, в зависимости от значения поля {all}. Если это ‘true’ тогда мы вытянем все партии запасов, а если ‘false’ тогда мы просто получим возврат для новых товарно-материальных ценностей (т.е. большого количества товаров, которые не помечены как уже экспортированные).
Если мы запустим этот запрос как ‘true’ (так http://host:port/V5-API/api/integrate/export/stock/true) , мы получим файл, который выглядит примерно так:
Образцы JSON-файлов этого типа можно скачать здесь.
Вышеупомянутые конечные точки будут предоставлять только текущие уровни запасов. Но что, если мы хотим отслеживать уровень наших запасов по мере производства? Здесь у нас есть несколько различных вариантов в зависимости от того, как мы используем API и интегрируемся с ERP-системой.
Мы также можем использовать различные конечные точки транзакций и журналов для получения более актуальной информации об изменениях уровня запасов.
Для пакетов Системный журнал конечные точки, это:
Потребляемые/создаваемые системные журналы
Для пакетов Транзакционный/Общий конечные точки, это:
5.3. CSV – Импорт
Имя файла определения заголовка/столбца: “stockLocation.csvh”
Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\import\column_defs”
Импортировать имя файла CSV: “stockLocation-datetime.csv”
CSV для импорта должны быть размещены в: “<installdir>\SG Control Center\gateway\import”
Заголовочный файл:
Файлы заголовков, как правило, компилируются SG Systems до интеграции CSV, но мы можем видеть базовый пример файла, который мы можем использовать для инвентаризации/запасов, используя ранее определенные определения классовниже:
Для получения дополнительной информации о том, как мы структурируем эти файлы, см. главная страница интеграции. Этот образец заголовочного файла можно загрузить здесь.
Файл импорта CSV:
Затем мы можем использовать определенный порядок точек данных в заголовке, чтобы структурировать наш файл импорта. SG Systems может предоставить для этого файл шаблона, в котором перечислены точки данных для каждого столбца, чтобы было понятнее при заполнении списка. Обратите внимание, что эта первая строка может быть проигнорирована Центром управления и поэтому может быть сохранена в файле при отправке на импорт.
Пример файла импорта csv может выглядеть примерно так:
Здесь мы видим, что мы импортируем 3 новых партии от 2 разных поставщиков. Этот пример файла импорта можно загрузить здесь.
После завершения импорта мы видим, что эти дополнительные партии халапеньо были добавлены в Центр управления. Обратите внимание на разницу между ‘Qty’ (под рукой) и ‘Stock_WeightReceived’ в нашем импорте csv.
5.4. CSV — Экспорт
Как и в случае с экспортом JSON, здесь у нас есть несколько разных вариантов:
StockLocation:
При экспорте товаров с использованием этого метода мы можем использовать ту же конечную точку и определения классов как мы сделали для импорта.
Имя файла определения заголовка/столбца: “stockLocation.csvh”
Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\export\order”
Экспортировать имя файла CSV: “StockLocation-datetime.csv”
CSV для экспорта будут созданы в: “<installdir>\SG Control Center\gateway\export”
Этот экспорт также необходимо включить в разделе «Шлюз» Центра управления. Мы можем выбрать здесь для экспорта ‘Stock’ .
Заголовочный файл:
Отсюда будет простой случай структурирования нашего файла заголовка экспорта в соответствии с тем, какую информацию мы хотим получить обратно из системы.
Мы могли бы структурировать его очень похоже на то, как мы структурировали заголовок импорта:
Этот образец заголовочного файла можно загрузить здесь.
Файл экспорта CSV:
Это даст возврат csv для нашего недавнего импорта, который будет выглядеть примерно так, как показано в примере ниже. Здесь мы видим, что мы получили все ранее не экспортированные линии запасов, включая добавление некоторых продуктов, которые были произведены ранее в тот же день.
Этот образец файла экспорта можно загрузить здесь.
Однако, как и в случае экспорта JSON выше, это не вернет никаких транзакционных данных, поэтому мы снова можем использовать ‘SystemLog’ вместо этого для получения более релевантных данных о транзакциях и корректировках запасов.
SystemLog:
Эту конечную точку можно использовать для извлечения самых разных данных путем обхода доступных точек данных, связанных отсюда. Мы видим определения, которые мы можем использовать здесь.
Имя файла определения заголовка/столбца: “SystemLog.csvh”
Готовые заголовочные файлы должны быть размещены в: “<installdir>\SG Control Center\gateway\export\order”
Экспортировать имя файла CSV: “SystemLog-datetime.csv”
CSV для экспорта будут созданы в: “<installdir>\SG Control Center\gateway\export”
Как и выше, это необходимо включить в разделе «Шлюз» Центра управления:
Заголовочный файл:
Отсюда мы можем структурировать наш заголовок в зависимости от того, какие транзакционные данные мы хотим получить обратно в ERP. Для наших целей это может выглядеть так:
Этот образец заголовочного файла можно загрузить здесь.
Файл экспорта CSV:
Итак, здесь мы видим, что мы собираемся получить обратно данные, специально предназначенные для наших нужд, включая такие данные, как товар, номер его партии, исходное количество, любые корректировки и пользователя, который выполнил действие, а также любые причины и соответствующую работу. /Информация о партии.
Если мы запустим системный журнал с указанным выше заголовком, мы получим экспорт, который выглядит примерно так:
Этот образец файла экспорта можно загрузить здесь.
