Заказы на продажу

Интеграция заказов на продажу (SO) между V5 Traceability и ERP-системой клиента позволяет отправлять детали заказа, позиции заказа и информацию о планировании в V5 Traceability. В этом случае V5 также может выступать в качестве мастера данных и отправлять заказы, созданные в системе, в ERP.

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

Дополнительную информацию о том, как работает модуль заказов на продажу в V5 Traceability, см. в нашем руководстве по модулю. здесь.

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

С точки зрения того, как мы можем относиться ‘Sales Orders’ и ‘Sales Order Lines’ В отличие от того, что мы видим в Центре управления, мы видим, что верхняя панель предназначена для заказов на продажу, куда можно импортировать клиентов, даты заказа и доставки, внешние ссылочные номера и т. д.

 

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

Используя V5 Gateway, мы можем легко заполнить обе панели как по отдельности, так и вместе.

В нижней правой панели хранятся данные о том, откуда выбираются элементы SO при обработке SO. Эти данные станут частью экспортированных данных, которые мы сможем получить обратно от шлюза V5.

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

Заказы на продажу

Строки заказа на продажу

Журнал продаж 

Шаблон интеграции для Заказов на продажу можно скачать здесь.

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

salesOrder.orderNumber – номер СО.

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

salesOrder.orderNumber + commodity.code – номер SO вместе с товаром, который необходимо заказать

or

lineID – В расширенных целях, когда один и тот же товар может отображаться в нескольких строках, вы можете указать идентификатор строки в качестве уникального идентификатора вместо номера заказа и кода товара. Это необходимо, если в заказе более 1 линии одного и того же товара.

Другие поля, которые требуются SG для заполнения действительного ‘SalesOrderLine’ в Центре управления находятся:

quantity – количество продаваемого товара/продукта.

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

lineID – если не используется в качестве первичного ключа выше, это поле должно быть включено.

commodity.code – если не используется в качестве первичного ключа выше, это поле должно быть включено.

salesOrder.orderNumber – если не используется в качестве первичного ключа выше, это поле должно быть включено.

salesOrder.customer.code – уникальный код, используемый для идентификации клиента.

salesOrder.placedDate – дата размещения заказа.

salesOrder.deliveryDate – ожидаемая дата доставки заказа.

Обратите внимание, что для последних четырех из этих точек мы переходим к ‘SalesOrder’ класс от ‘SalesOrderLine’. Если бы мы вместо этого использовали ‘SalesOrder’ класс, который мы могли бы просто удалить ‘salesOrder’ из приведенных выше 4 записей.

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

salesOrder.referenceNumber – любые дополнительные примечания/ссылки, относящиеся к SO.

Учитывая характер ‘SalesOrder’ и ‘SalesOrderLine’, мы можем импортировать данные и управлять ими несколькими различными способами:

1. 1. Мы можем использовать ‘SalesOrder’ конечную точку для импорта заказов на продажу, а затем, как мы увидим ниже, перейдите к ‘SalesOrderLine’ class, чтобы затем включить все позиции компонента в один файл. Это наиболее логичный способ импорта целых заказов, поскольку для него требуется только один набор информации заголовка, а затем последующие позиции. Обратите внимание, что это также единственная конечная точка, которую мы можем использовать для изменения информации заголовка заказа на продажу.
   2. Мы можем использовать ‘SalesOrderLine’ конечная точка для изменения или добавления строк после создания заказа. Это по-прежнему можно использовать для импорта целых заказов, но оно менее эффективно, поскольку каждая позиция заказа должна содержать вложенную ссылку на заголовок заказа на продажу (например, номер заказа). Как указано выше, эту конечную точку нельзя использовать для внесения изменений в информацию заголовка заказа (номер заказа/даты доставки и т. д.).

Заказ клиента:

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

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

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

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

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

Мы можем понять, почему мы будем использовать ‘SalesOrder’ конечная точка для этого формата, учитывая способность файлов JSON хранить вложенные данные, что позволяет нам включать отступы ‘SalesOrderLine’ списки, а затем ‘Commodity’ точки данных в импорте, которые можно определить с помощью руководства SG API. Например, ‘commodity code’ точку данных можно найти, используя следующий путь в руководстве по API:

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

Строки заказа на продажу:

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

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

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

Мы также можем использовать ‘SalesOrderLine’ конечная точка для добавления или редактирования строк существующего заказа. Мы также можем добавлять заказы на продажу, используя эту конечную точку, но важно помнить, что мы можем редактировать заголовок заказа на продажу только с помощью ‘SalesOrder’ УРИ. Также обратите внимание, что информация SO должна быть вложена сюда для каждой строки SO.

Мы можем увидеть пример ‘SalesOrderLine’ JSON-файл ниже, в который мы добавим еще одну строку заказа. ‘SO-8471’ который мы создали выше:

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

Затем мы увидим в Центре управления, что наш заказ был импортирован вместе с только что добавленной дополнительной строкой. Обратите внимание, что такая информация, как дата размещения/доставки и ссылочный номер, была импортирована из исходного ‘SalesOrder’ .

Что касается получения файлов, относящихся к заказу на продажу, обратно из API V5, если мы проверим сводку методов в разделе «ИнтеграцияЭкспорт‘service, то у нас есть несколько разных вариантов:

Заказы на продажу:

Экспорт конечной точки/URI –

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

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

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

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

Заказ клиента:

Экспорт конечной точки/URI –

http://host:port/V5-API/api/integrate/export/sales_order/{ordernumber}

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

Эта конечная точка будет экспортировать полные файлы JSON заказов на продажу с использованием класса базы данных заказов на продажу, но только для указанного заказа и только в том случае, если этот заказ еще не был помечен системой как экспортированный. Как указано выше, это обеспечит возврат для каждой точки данных в ‘SalesOrder’ класс, а также любую информацию о комплектации отгруженных товаров.

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

Журналы заказов на продажу:

Экспорт конечной точки/URI –

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

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

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

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

Журнал заказов на продажу:

Экспорт конечной точки/URI –

http://host:port/V5-API/api/integrate/export/sales_log/{id}

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

Эта конечная точка функционирует так же, как и описанные выше «Журналы заказов на продажу», но может использоваться для возврата информации для определенного номера журнала, как определено системой V5. Как и прежде, здесь используется ‘SystemLog’ класс данных для предоставления транзакционных данных, таких как системные дескрипторы. Конечная точка предоставляет эти данные только для журналов выполненных заказов, которые не были помечены как уже экспортированные.

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

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

У нас есть один Транзакционный/Общий конечная точка, которую мы можем использовать здесь:

Сделки купли-продажи

Обратите внимание, что для импорта CSV мы обычно используем только ‘SalesOrderLine’ конечная точка, позволяющая нам создавать заказы на продажу и их отдельные позиции с помощью одного импорта CSV.

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

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

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

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

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

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

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

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

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

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

После завершения импорта мы видим, что эти заказы вместе с необходимыми позициями были добавлены в Центр управления. Обратите внимание, что если ‘Date Placed’ данные не включаются в импорт, размещенная дата будет ссылаться на сегодняшнюю дату.

При экспорте информации о заказах на продажу с помощью этого метода это будет частью ‘SalesLog’ экспорт. Мы можем видеть определения классов для этой конечной точки здесь.

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

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

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

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

Этот экспорт также необходимо будет включить в разделе «Шлюз» Центра управления. Это будет просто случай проверки ‘Sales Order’ поле и обязательно примените настройки и перезапустите Центр управления.

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

Мы можем использовать точки данных, такие как ‘user’, ‘timestamp’ и ‘quantity’ на этой вершине ‘Sales Log’, уровень, но затем мы также можем использовать страницы «Заказ на продажу» и «Строка заказа на продажу» для дальнейшего формирования необходимой нам информации, такой как номер заказа, проданные товары и откуда они были выбраны. Обратите внимание, что здесь ‘SalesOrder’ доступ к классу должен осуществляться через ‘Line’ класс, как показано в примере ниже

На самом базовом уровне наша часть ‘Sales Log’ заголовок, который касается наших заказов на продажу, может выглядеть примерно так:

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

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

Установив заголовок и включив экспорт, мы впоследствии получим файл возврата для этого заказа (вместе с любыми другими ранее неэкспортированными заказами), который выглядит следующим образом:

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