Инвентарь/место на складе
Ваш путеводитель по интеграции V5!
Интеграция системы отслеживания запасов/местоположения товаров между 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. Шаблон интеграции
Шаблон интеграции для функции «Местоположение склада» можно скачать здесь.
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:
Итак, здесь мы видим, что мы собираемся получить обратно данные, специально предназначенные для наших нужд, включая такие данные, как товар, номер его партии, исходное количество, любые корректировки и пользователя, который выполнил действие, а также любые причины и соответствующую работу. /Информация о партии.
Если мы запустим системный журнал с указанным выше заголовком, мы получим экспорт, который выглядит примерно так:
Этот пример файла экспорта можно скачать здесь.
