I am now reproducing the big stack trace in Postman by posting an invalid inventoryId POST https://integration.visma.net/API/controller/api/v2/salesorder     ... View more

Yes, but I am not sure the reason of failure is effecting the problem with big stack trace. It seems also Florian got the big stack trace with different situation/error.   I am neither able to reproduce this with simple calls from Postman, but we do get this in the error response stream when calling from code. I think it might be  ... View more

We are also now receiving a big stacktrace when receiving a 400 Bad request. I asume this is by a glitch. But it should be considered a security glitch as well - as it could contain information you would not want to show to an outsider.    In our case we sent an order with a orderType not existing in Visma.net - which of course absolutely SHOULD fail - as it does, but we received this error message: {"message":"VismaId: 54ce7920-e8cd-43d3-90ff-a4f560976a53. Error creating salesOrder. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> PX.Data.PXSetPropertyException: The specified inventory ID or alternate ID cannot be found in the system.\r\n at PX.Data.PXSelectorAttribute.throwNoItem(String[] restricted, Boolean external, Object value)\r\n at PX.Data.PXSelectorAttribute.SubstituteKeyFieldUpdating(PXCache sender, PXFieldUpdatingEventArgs e)\r\n at PX.Data.PXDimensionSelectorAttribute.FieldUpdating(PXCache sender, PXFieldUpdatingEventArgs e)\r\n at PX.Objects.IN.CrossItemAttribute.FieldUpdating(PXCache sender, PXFieldUpdatingEventArgs e) in D:\\Data\\BuildAgent\\work\\11023e52ea15d342\\Web\\Pure\\PX.Objects\\IN\\Descriptor\\Attribute.cs:line 8157\r\n at PX.Data.PXCache.OnFieldUpdating(String name, Object row, Object& newValue)\r\n at PX.Data.PXCache`1.SetValueExt(Object data, String fieldName, Object value)\r\n --- End of inner exception stack trace ---\r\n at Visma.net.ERP.Api.Base.BaseDomain.HandleChildCommand(IBaseCommand cmd, Boolean handleChildCommands) in D:\\Data\\BuildAgent\\work\\11023e52ea15d342\\Web\\Lib\\Visma.net.ERP.Api\\Base\\BaseDomain.cs:line 72\r\n at Visma.net.ERP.Api.Base.BaseDomain.ApplyChildCommands(IEnumerable`1 childCommands, Boolean handleChildCommands) in D:\\Data\\BuildAgent\\work\\11023e52ea15d342\\Web\\Lib\\Visma.net.ERP.Api\\Base\\BaseDomain.cs:line 44\r\n at Visma.net.ERP.Api.SO.CommandModel.SoCommandHandler.Handle_V2(ICreateSalesOrderCommand[] cmdList) in D:\\Data\\BuildAgent\\work\\11023e52ea15d342\\Web\\Lib\\Visma.net.ERP.Api\\SO\\CommandModel\\SoCommandHandler.cs:line 83\r\n at Visma.net.ERP.Web.Api.Repositories.SOOrderWebRepository.CreateSaleOrderReturnSaleOrderNumber(SalesOrderUpdateDto salesOrderUpdateDto, String orderType, Int32 version) in D:\\Data\\BuildAgent\\work\\11023e52ea15d342\\Web\\Lib\\Visma.net.ERP.Web.Api\\Repositories\\SOOrderWebRepository.cs:line 178\r\nThe specified inventory ID or alternate ID cannot be found in the system."} ... View more

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

This is not a priority for Gurusoft. We have only one big priority, getting pagination to work on all endpoints again But I guess Visma is very well aware of it 😉 - as I am using all occations to mention it since it stopped working in september 2020.   When this is fixed, we are ready to discuss next priority (but for us expanding by inventorysummari by lot/serial number would not be on the highest part of the list) ... 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

This is very welcome 🙂 I did not get to test it yest, just want to add one important issue just in case it is not covered. All responses should contain current version of Visma.net ERP Financials. Status warnings on updates should contain current version, new version and planned date of new version   Is this already in place? ... 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

Also, the error message is not pointing to which order line(s) which is wrong.   More precise error message makes it more possible for us to help the end customer -- in this case we wish to give the customer possibility to correct the failing order, and then try re-exporting. Todays error message is just as precise as "Something went wrong" -- with 40-50 or more order lines; there is a lot of manual work for the end customer to look for what actually went wrong -- and which orderline(s). ... View more