Hi @adrianm, “What return code for timeout will be?”  504 Gateway Timeout. “If the timeout happens on PUT/POST, will the operation also be cancelled?” This depends on the business logic behind the endpoint. If there is no actual checking there - within the transaction or process - that the client still is connected, then the transaction should go through, even though the client got a timeout response. “OpenApi and versions” "v1" as version has been the same always and will probably still be for a while. It can be looked upon as the version of the ERP API, not to be confused with the v1 or v2 in the url, which points to a particular endpoint version, or the OpenAPI specification version which is the version of the (swagger) specification format.   Please let us know if you have any further questions.   Hi @thingsio ,  “I assume this will not change the token request URL too?” You are correct, the URL for the request token will stay the same.(https://connect.visma.com/connect/token)   Hi @jacob, “https://salesorder.visma.net/api/v3/ Wil this also move to https://finance.visma.net/ ?” The URL for Visma Net SalesOrder API will remain the same.(https://salesorder.visma.net/api/v3/) ... Meer weergeven

If the order types number series have been setup to default be auto-generated, you can in the API use the field "overrideNumberSeries": true. This way, with the order type, if created from UI it will get an order id generated by the system. And from the API, if the "overrideNumberSeries" is set true and a non-existing "orderId" is provided, the order will be created with the provided order id. ... Meer weergeven

Hi Johan, I suspect this is changed due to the expansion of the SalesOrders v3 endpoints. This information is now available under the shipment endpoint. See /api/v3/SalesOrders/{type}/{orderId}/shipment. Let us know if this information answers your question. ... Meer weergeven

The change is intentional, and this article, "How to Mark for PO in SalesOrder v3", provides some clarification on how this feature is transitioning from v1 to v3. If this does not answer your question, please let us know. ... Meer weergeven

Hi Johan, Thank you for your question. I will investigate this and get back to you as soon as possible. ... Meer weergeven

There was a mistake on our part regarding the dates mentioned above. We apologize for this and so the same dates that you mention above apply.  In accordance with our policy regarding Breaking Changes, we strive to give at least 3 months' notice before the change is made. Kind regards Sandra ... Meer weergeven

Hello, you can create an "Idea"  about that.      ... Meer weergeven

For the breaking changes we will follow the same guideline as what is today in the Visma.net ERP API, i.e. latest 3 months before. In the closest roadmap we have not planned to introduce createShipment in V3. Could you elaborate a bit more for why it is highly needed in V3? Is it, for example, for the easier use of the API through the sales process or expectation of better performance in that endpoint etc? ... Meer weergeven

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. ... Meer weergeven

Hello Johan,    1) Unfortunately we don't have a timeline revealed for the unification process at the moment, however we're doing our best to handle it as soon as possible.    2) Because currently they're using different authentication bases due to endpoint structures and their dependencies according to ERP UI rights. For sure this can be changed in the future, we'll keep the community updated if there are any plans.  ... Meer weergeven

Hello,    All functionality currently missing in the new Sales Order Service API has been planned to be added before removing the old endpoints.  ... Meer weergeven

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? ... Meer weergeven

Hello Johan,    have you tried overwriting the existing values in the Financials UI ?  (Inventory > Attributes > Uncheck Save > Check Save the boolean values) ... Meer weergeven

Hi,  We'll have a look at it and get back to you. As it is specified in the documentation we would assume that it should be returned, we'll lift this with the development team. ... Meer weergeven

Hi   In the POST of /customerpayments it is (according to the documentation) possible to add "paymentlines" with the documentType  FinCharge. What is that suppose to do?   I have not been able to complete a successful POST with lines of that documentType. Is there any special circumstances that need to be met? ... Meer weergeven