Greetings all Visma.net API users!
The endpoint InventorySummary is one of the most used endpoints we have in the API today with millions of calls being made every week. We know that the current implementation of the endpoint is not optimal for your integrations, and we are therefore planning to implement a new version.
To make sure the new version will be the best possible solution for your use cases we would like to have your input on how the ideal signature and functionality should be.
The current endpoint has the following signature:
With this structure you are only able to ask for the summary of one item per call, optionally limited to one warehouse and/or one location.
Our goal is to make the new endpoint the best suited for your use cases, while at the same time improving the performance of the call and reducing the number of calls needed to perform the use case.
Please provide information on your use case and the change needed to best suit your integration.
Your input in this thread would be much appreciated!
We would appreciate some more functionality to this endpoint.
Use case 1: A user wants to know which products exists (and how much) on a location.
Use case 2: A user wants to know the summary of a list of (similar) products. Like a shoe of the same type, but different sizes and colors.
Instead of making several calls to the endpoint one by one, we would like to make one call with a list of products. Like https://integration.visma.net/API/controller/api/v1/inventorysummary/?warehouse=1 + a list of products
Use case 3: Compare the balance in Visma.net to the balance in a third party warehouse management system.
Would like the endpoint to return a summary for the whole warehouse, like https://integration.visma.net/API/controller/api/v1/inventorysummary/?warehouse=1
We have asked the team for an update on a possible ETA. Information will be posted in the Idea's thread when we have more information. If you have any concerns regarding the time to implement this, we recommend that you contact your partner service.
Request: Webhooks support for "inventorySummary" endpoint.
Implementation of this will eliminate the unnecessary traffic caused due to polling that the client makes in order to be able to get the latest inventory status. A push notification sent via the webhook when changes have been made would be beneficial for both side, and providing the customer with at better experience of integrations.
Input from BX Software (Sven Tore Iversen):
We believe inventory summary is lacking in two main categories. Listing them is easy enough: speed and information detail.
We can list a lot of use cases, but I think the important requirements boils down to fetching a list, with valid filters in a single request, and exposing the details of the allocations of each location. Another step to reduce the load of inventorySummary is to improve on other endpoints, eliminating the need to “abuse” the endpoint.
I see three different usage scenarios for stock quantity information.
C: When picking without reservations, either when needing to select another allocation on a shipment or when doing picking based on orders, before creating shipments. (When the warehouse needs the ability to add products lines on the order while picking)
All scenarios would greatly benefit from common improvements.
Implement availabilityLastModifiedDateTime in inventorySummary. Eliminate the need to use inventory to prefetch a list of products we need to fetch from inventorySummary. Combine the listing with this would reduce the following scenario from 301 to 1 request:
Get all products from inventory/ where stock value is changed the last hour/minutes etc.
Enumerate list returning 100 items with updated stock, fetch inventorySummary for 100 products, and 3 warehouses, with a total request count of 301.
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.
Use case 2: Looking at individual products.
Use case 3: Creating an order.
Use case 4: Filtering for only in-stock products.
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.
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)
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:
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.
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!
Copyright © 2022 Visma.com. All rights reserved.