My Products
Help
erik-kle
PARTNER

Migration from v2/SalesOrder to v3/SalesOrders Questions

by erik-kle

Hi,

Upon a first glance of the POST v3/SalesOrders i find that ShipVia and ShippingTerms is missing. Will the NewSalesOrderCommand be extended with more fields in the coming months? 

4 REPLIES 4
Joni Wolff
PARTNER

by Joni Wolff

Hi! We will start working with the shipping and freight fields(ShipVia and ShippingTerms included) the coming weeks, we plan to have this available in start of February.

erik-kle
PARTNER

by erik-kle

Why do you have a fauna of different SalesOrder objects for different endpoints? Isnt it possible to define a domain SalesOrder object, that are used for GET, POST, PUT, instead of NewSalesOrderCommand, SalesOrderDto, SalesOrderListDto etc, that are all a bit different.

Joni Wolff
PARTNER

by Joni Wolff

Hi! We have tried to use the same objects in the places where the request or response are the same.

For example, in GET we have totals on order, which cannot be provided in POST or PATCH, so we want to response only with data which is needed.

Snuffsis
CONTRIBUTOR ***

by Snuffsis

Would it not make sense that the data that is returned at least looking the same?

 

A simple example (Endpoint for single SalesOrder):

GET /salesorders/SO/000100

In this request, the Status field is an object that looks like this:

 "status": { 
  "description": "string", 
  "cancelled": true, 
  "hold": true 
}, 

 

But in the request (Endpoint for list of salesOrders):

GET /salesorders

here the status field is a simple string:

 "status": "string", 

 

I would have assumed that, at the very least, since it's both a GET that the data that is returned looks the same in both endpoints, even if they don't return the exact same amount of data for the whole salesorder

 

An option to "expand" on attributes, as is possible for the endpoint for a specific salesorder, seems like something that should exist for the list endpoint as well.