Migration from v2/SalesOrder to v3/SalesOrders Questions

[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? 

[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]

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]

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]

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.