Yes, but the API doesn't say which numbering sequence each order type uses.   The SalesOrdertype endpoint gives very limited information:   ... View more

That is what we are trying to do but in the cases where the API-response is 502 we'll get a problem. Since customers want to to take advantage of the automations in Visma.net we need to know about the actual order created.   Would it be possible to include the created object in the response in the v3 version of the API? That would give us the information needed without an extra API-call. ... View more

I have done some more digging and here is the problem: When we create an order we need some information about the created order to continue working with it. However, the order POST just responds with a 201 but no order payload so we need to manually fetch the new order to get the information that we need.   On this occation (5:th of january at 12:24) the POST was successful but a GET to the location header address from the POST resulted in a 502 Bad Gateway. That was seen as an incomplete POST and therefor the order was sent again resulting in a duplicate order. So technically it wasn't the API that created the duplicate but since the POST didn't respond with the created order (which is the most common way) it lead to the error.   From what I can see in the SalesOrder documentation the POST still doesn't contain a response payload so this logical problem can continue to come up in the future. How should this be handled in the best way? ... View more

More information: 3 customers have tried this week and they have all failed with the same message.   It worked last week for at least 1 customer. ... View more

Correction: the problem occurs with SalesOrder but not with SalesOrderv2   It is the contacts that are affected. If "overrideContact" = false is combined with additional values (see below) on the first SO for a customer these values will be used on this SO and every consecutive SO, regardless of if it is created via API or manually.    "soBillingContact": { "value": { "overrideContact": { "value": false }, "name": { "value": "Billing Contact" }, "attention": {}, "email": { "value": "billing.contact@mail.com" }, "phone1": {}, "phone2": {}, "fax": {} } },   It can be argued that override and extra values shouldn't be used at the same time but there is nothing stopping it (tehcnically or in the docs). The effects are also very problematic since it will affect every future SO.   Regarding the use of v1 over v2: we had prior to this no urgent reason to move to v2 since the focus was on the initial SalesOrderService timeline. But since that has been pushed we have to rethink what we need to do. ... View more

No, there is no technical reason. I believe that my collegue have verified this behaviour manually with v2 also. ... View more

HTTP POST to https://integration.visma.net/API/controller/api/v1/salesorder   { "orderType": { "value": "SO" }, "orderNumber": { "value": "007-75" }, "customerVATZone": { "value": "01" }, "soBillingContact": { "value": { "overrideContact": { "value": false }, "name": { "value": "Kajsa Testar" }, "attention": {}, "email": { "value": "external.accounts@sharespine.com" }, "phone1": { "value": "0000000000" }, "phone2": {}, "fax": {} } }, "soBillingAddress": { "value": { "overrideAddress": { "value": false }, "addressLine1": { "value": "PB adress" }, "addressLine2": {}, "postalCode": { "value": "45132" }, "city": { "value": "Uddevalla" }, "county": {}, "countryId": { "value": "SE" } } }, "soShippingContact": { "value": { "overrideContact": { "value": false }, "name": { "value": "Kajsa Testar" }, "attention": {}, "email": {}, "phone1": { "value": "0000000000" }, "phone2": {}, "fax": {} } }, "soShippingAddress": { "value": { "overrideAddress": { "value": false }, "addressLine1": { "value": "PB adress" }, "addressLine2": {}, "postalCode": { "value": "45132" }, "city": { "value": "Uddevalla" }, "county": {}, "countryId": { "value": "SE" } } }, "date": { "value": "2023-05-09T10:45:39.000" }, "shipVia": { "value": "DHL" }, "branchNumber": { "value": "1 " }, "printDescriptionOnInvoice": { "value": false }, "printNoteOnExternalDocuments": { "value": false }, "printNoteOnInternalDocuments": { "value": false }, "note": { "value": "." }, "currency": { "value": "SEK" }, "customer": { "value": "10990" }, "status": { "value": "open" }, "hold": { "value": false }, "lines": [ { "operation": "Insert", "warehouse": { "value": "2" }, "inventoryNumber": { "value": "test123" }, "lineDescription": { "value": "En mycket fin testprodukt" }, "quantity": { "value": 1.0 }, "unitPrice": { "value": 15.2 } } ] }   ... View more

When will the new removal date be communicated?   We would like to plan our customer communication so that it will include both required authentication changes and information about the sales order changes. ... View more

We're planning an authentication upgrade of 60+ customers in preparation of moving to the SalesOrder service. However, there seem to be more and more issues where the "solution" is to use the old auth model or v1/v2 endpoints. This seems a bit strange sine the communicated deadline is now less than 2 months away.   With multiple customers affected we need to be sure that we can have clear communication with them regarding when things need to change. As it seem right now this is not a production ready implementation. ... View more

Ok, but the Sales Order Service API should today contain features that cover the endpoints that are going to be removed in June? ... View more

Is all of the features of the SalesOrder service implemented so that it should be possible to migrate from the old to the new?   It is vital that we know that the support is there before we dig to deep. Time is flying quickly and since we have multple customers that are affected by these changes (due to the new auth etc) we need to inform and implement our changes well before the deprication date. ... View more

Any updates on this question?   We would like to be able to get the next delivery date as a parameter on the inventory item itself. Would that be possible? ... View more

Any update on this? We have more customer related information but it isn't something that is suitable to post in an open forum. ... View more