It might not be super relevant in this case, but in general you might consider implementing variants of the endpoint for different use cases with and addition in url. Some times one use case' need for info can kill performance for other use cases.   So instead of giving only once end point api/v2/generalledgerbalance as one-size-fits-all, you could generalize in  api/v2/generalledgerbalance   and then create special versions in    api/v2/generalledgerbalance/financial  for users with financial users and   api/v2/generalledgerbalance/logistics for use cases from logistics view  or    api/v2/generalledgerbalance/auditor if this could be another use case   I think focus on which use case the end point is going to serve will give a better result than new parameteres introduced as-you-go to fix issues that appears... ... View more

The orders which are failing are missing header Content-Length, and they have header Transfer-Encoding in addtition. Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with? Still orders are failing from time to time -- and in those cases the response header Content-Lenght is missing, and Transfer-Encoding is appearing.  Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with? ... View more

We did a rewrite to check Content-Length after this header was added after the infrastructure change on February 20th. Most POSTed orders are now 201 - and we again read ordrenumber from Location 🙂   But only most orders. The orders which are failing are missing header Content-Length, and they have header Transfer-Encoding in addtition. Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with? ... View more

Magnus wrote: > The only time we repond with a body is to return error messages or warnings.    It seems according to RFC 2616 there should be a body as well: If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30 ).   This is from section 9.5, paragraph 4; https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html ... View more

Magnus, you write nothing was changed on 16.02 -- I believe -- but this change which makes problems now was on Saturday 20.02 Could it be something done in infrastructure now chopping off empty response bodies totally?   Maybe it was returned {} before ? And something in infrastructure is trimming this? ... View more

But, something changed on Saturday evening, we changed nothing, and Visma changed something   Maybe something done different now by AWS?   This code runned as it should before this time on Saturday: 1 responseHeaderFields = connection.getHeaderFields() 2 InputStream stream = (InputStream) connection.content Now we get header fields in line 1 here, but line 2 crashes as there is no content. connection is HttpsURLConnection   So before this time on Saturday, this code ran well, after this time it crashes. Why? ... View more

True, RFC 2616, 4.2 says so (https://tools.ietf.org/html/rfc2616#section-4.2) But RFC 7231, 7.1.2  (https://tools.ietf.org/html/rfc7231#section-7.1.2) which defines Location says nothing about case it seems, but all the way they reffer to Location and not to location.   Anyway further debugging shows now capitalized Location, as Magnus says. It might be I have been fooled by swagger or Fiddler here   ... View more

Ok, thank you for clearification 🙂   But it seems definitely something changed after Saturday 21:51 -- this was the time of the last order where we successfully read the created ordernumber from Location header after 201   3 hours and 20 minutes later; after this time all orders exported fails, and it seems because we now cannot read the created order number in the header anymore.   It seems after that time we get   location with lowercase:  location: https://integration.visma.net/API/controller/api/v2/salesorder/000034 Earlier we got correct RFC-standard and as-in-swagger: Location: https://integration.visma.net/API/controller/api/v1/salesorder/000035   ... View more

@Florian Haase  skrev: Thank you, works again - that was nice. We investigated how to get around that. But we introduced this because when you are filtering on attributes you can get blank pages within the total result (the number of total pages will still be the same but the customers which don't match the filter are deleted from the pages). Therefore we don't know when to stop to fetch the next Page.  I don't know how others have implemented this, but to trust on that a blank page indicates the last page is not working in the end... (or is this behaviour changed in the meanwhile?) We are depended on this working to do smart and effective imports to Gurusoft eCommerce. Now we are doing full imports, it is sadly the only way. This is our big pain since it stopped working in september 2020.    Honestly I personally feel more like a child trying to get the attention of grown up Visma to tell how painful this is for our integrations, customers and business, but after 5 months still not enough attention and priority to be solved. ... View more

Hi Thomas   Correct and reliable information about the availability of goods is essential for any seller and buyer, so thank you very much for paying due attention to this matter.   Before focusing on the implementation details and signature of the endpoint, please consider the following basic use cases. They should be applicable to any solution which presents inventory items from Visma.net for online sale to end users, and they are described with the point of view of such customers in mind, e.g. interacting with a webshop application.   Use case 1: Browsing or searching for products.   At this stage, the customer might be interested in knowing about which products are available for purchase immediately, and which are not - with or without details about future availability. The customer may or may not be interested in availability at particular locations / warehouses. A typical service call might include a large list of product (inventory item) numbers, for any number of locations / warehouses. Use case 2: Looking at individual products.   At this stage, the customer is beginning to decide which product(s) to actually buy. Availability at particular locations / warehouses, as well as details about future availability may be important to some (e.g. if considering click-and-collect options, or looking for the seller who can deliver the most recent PlayStation quickest). A typical service call might include one or a small list (in case of bundle or variant products) of product (inventory item) numbers, for any number of locations / warehouses. A detailed response may be required, so that sufficient options can be presented to the customer to maintain interest. Use case 3: Creating an order.   At this stage, it might be crucial for the customer to be informed about any product(s) which can and cannot be delivered immediately - e.g. if that PlayStation of which there was only one remaining unit in stock a few minutes ago has been sold, and no delivery can be expected for several weeks or months. A typical service call might include a list of product (inventory item) numbers, for any number of locations / warehouses. Accurate information is critical, and a detailed response may be required, so that sufficient options can be presented to make sure the customer completes the order. Use case 4: Filtering for only in-stock products.   Customers value their time, and some are only interested in buying products which can be delivered immediately. In this case, product availability should be known in advance so that it may be filtered upon when performing queries, rather than querying first and then calling your endpoint to check for availability (which would impact performance and responsiveness adversely). Typical service calls might include regular pagination of data, with or without filter parameters and/or a last modified datetime parameter. The above use cases differ in terms of how they translate into inventory summary service calls in several ways which should be analyzed and understood. A good implementation may be driving sales and customer retention, while a poor one may be losing both.   General considerations   Product availability is highly volatile information which can change rapidly and by significant amounts. It is also critical information to customers, in that unavailability of certain products may be a deal-breaker, making the customer not commit to a purchase if available products are falsely presented as unavailable - or disappointing and potentially losing the customer if unavailable products are falsely presented as available.   You must therefore take necessary steps to understand and cater well for the realistic use cases, so that it is easy for integrators to meet our clients' requirements while at the same time not abusing your services (or incurring large costs for high-volume use).   We understand that our implementations should be able to minimize load on your services, but at the same time our need for reliable and up-to-date data must be understood and met.   We are aware of web hooks, but until they can be relied upon 100.00% (and for other reasons) other mechanisms that can handle the pressure must be available as well.   Extra information like restockability and expected longevity might also be relevant and useful information (e.g. to decide how often to refresh cached data)   ... View more

A change of this endpoint is very much welcome 🙂   You say it is one of the most used endpoints, but we are not using inventorySummary at all as of today.   We need to be able to do delta imports and to GET based on minimum these additional filtering: availabilityLastModifiedDateTime (stock) availabilityLastModifiedDateTimeCondition (stock) lastModifiedDateTime (product) lastModifiedDateTimeCondition (product) inventoryNumber list of inventoryNumber attributes (product) pageNumber pageSize I guess you already got this noted, but this is just a quick top-of-the-head response   We will document use cases today, and hope to get some more detailed response later today 🙂 When this is implemented; it might also be an idea to make the /inventory endpoint less expensive by making the warehouseDetails optional Please also consider POST to GET.   PS! Before you start working on this or any new endpoint; please fix the failing implementation of the same filtering options on other endpoints 😉 -- Plust REST nactos, plus spei nactos! ... View more

I think it is time to discuss when to deploy, and even more, when not to deploy. So, to deploy or not to deploy, that is the question. The answer is dependent on a risk evaluation. And the risk evaluation is dependent on probalility and impact. If expected impact is high; even low probability should suggest no deployment.   To understand impact, Visma need to understand the pratical consequenses at the ISV's and at the end customers. Visma need to understand our pain.   In our house, we have a very tough system administrator. He rules. And he often say NO. Honestly, some times it is frustrating for some of us. But all the time it is safe, for all of us. We do not deploy on Fridays - we dont want to bring potential problems into the weekend, neither for us nor for our customers. We do not deploy on Mondays - some times things happens during weekends, and it need to be handled, we need to deal with this first before we deploy. Clean the desk and be prepared. We do deploy on Tuesdays, Wednesdays and Thursdays.   If to discuss any exceptions from this, expected impact need to be low.   We stop deploying a few days before holidays and bigger events. Because we need to be at work and ready for action if not everything after deployment went as expected. And we do not want to introduce new risks just before hight traffic events. These events are already busy enough.   Of course this careful approach to deployment can be frustrating for both impatient customers and marketing departments. But in the long run it gives a more stable environment. It pays off.   The need of being prepared for handling situations after deployment is also valid in a world with continous delivery. Also the need of someone being at work, someone to handle situations and communication.   Like Forrest Gump says; **bleep** happens. And when it happens "someone" need to be "the chosen" - with a plan - to clean up and communicate. ... View more

This is a big pain for us -- and our common customers with you Visma.  This need to be fixed -- in the very near future. ... View more

And that is how it is done 🙂 Setting currency = "NOK" made the difference.   Thank you, Visma! 🙂 ... View more

@Yıldırım Maybe this case is related to this case: https://community.visma.com/t5/Ideas-in-Developers-Visma-net/missing-vat-in-orderhead/idi-p/317171   Both are about missing VAT in order head. In our case we also see that we get VAT in order head if  creating empty order and the later adding order lines. ... View more

Sorry for late answer, we have been searching a lot of possible causes in config.   I have tried posting order with UoM -- same story, no VAT in head. I have tried adopting all settings from the company where this fails to a test company -- still not able to reproduce this in test. We know that Cloud Connection have made an integration with WallMob and this company; and VAT is generated in the head for these orders - they made a special variant of settings to avoid challenges with rounding of VAT. But for them VAT generation in head works. ... View more

This is then problem with filtering and pagination -- also described here: https://community.visma.com/t5/Forum-in-Developers-Visma-net/Issue-with-filtering-of-attributes/m-p/320750#M337   ... View more

I agree the issue have to be fixed - and wait for V2 -- but it applies for all endpoints with pagination so some work to do for Visma.   It would actually help with totalCount in header; because now I have no idea how many calls to do. I get empty json and 200 when calling the first page. In this case I also get empty json and 200 when calling the next 30 pages. I also get empty json and 200 when calling non-existing page 55. So how to know when to stopp trying? At least if I knew there are 3197 records; I could call only 32 pages of 100.   totalCount in header would be a pain killer while waiting for the real treatment -- V2 ... View more

Making totalCount available in the response header would be more reliable -- as it is now the empty response also give no totalCount metadata.    One case; the customer entity has been alive for some time, and contains 3197 entities.  Only recently the attribute signaling we should pick it up is introduced.  The attribute is a checkbox, and we check it on five recent customers for test. We use the URLs given above to GET the customers. The five customers returned is now in the "far end" of the recordset. Meaning; when GET with  https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D&pageNumber=1&pageSize=100 I get the empty json in response. Only after reading 31 empty respones and not giving up, I get the five new customers. https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D&pageNumber=32&pageSize=100  If the totalCount is avaiable in response header, the json response can miss or be maleformed, we still know the size of the recordset. And can at least start try paginating to some page far, far away 😉   This was voted over here: https://www.visma.com/software/support/portal/forum/showthread.php?12866   We should of course have been more awake when this was voted over; but we missed it. With all respect, you as system owners also missed it - designing it by result of vote.   My conclusion:  "totalCount only in response body? no no no...."   So, maybe totalCount also in response header? 🙂     ... View more

Skipping pagination is not a solution for us; we are waiting for followup and final solution in this thread. ... View more

We can also confirm this problem. When we combine pagination and attributes filtering, we get empty response in testclient -- where we just recently added these attributes and started using them. In production this attribute has been present for a long time.   With production company 1555332; Correct response with this URL without pagination: https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D   Correct response with this URL with pagination: https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D&pageNumber=1&pageSize=10   With test company 1555345: Correct response with this URL without pagination: https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D   Empty response with this URL with pagination: https://integration.visma.net/API/controller/api/v1/customer?attributes=%7B%22DDLDKUNDE%22%3A%221%22%7D&pageNumber=1&pageSize=10   ... View more

So it could be then either a setting in Visma.net or an obscurity in this company -- we will investigate further and tell what we will find. ... View more

When creating this order in Visma.net UI, VAT in order head is updated as expected after field quantity is updated. ... View more