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.
Lite: You only need total stock amount, either total or based on a specific store/warehouse. Typical use case: Sales, webshop, mobile device etc. Details about soBooked etc is often important, dependent of the consumer and use case. Some customers want the actual stock amount, some want what is available for sales (stock – sales order etc) and some want what’s available for future stock (add incoming POs). Dependent on the data structure I guess that being able to skip inPO/inTransit etc could reduce the load. I expect all 3 rd parties to be happy to specify url parameters to let you know if e.g. incoming and/or outgoing is needed. The inventory/ endpoint supplies this information, and the inventorySummary could probably be skipped. However, it’s currently not possible to get only the basic stock quantities, without getting the product information. (if product information itself is not needed fetching them is an unneeded cost)
Medium: This is basically the use case the endpoint supports today. We get stock information + location information in the warehouse. In a warehouse application/scenario this is very important for customers using more than one location for their goods. Other warehouse customers could live very happily with “lite” or “no” use of inventorySummary, since the stock amount is not really needed (most scenarios) for either receiving, picking or even stocktake. In this scenario the usage of inventorySummary is working for what it is intended to do (I guess), but it’s not doing it very efficient. We have also been “abusing” the endpoint due to missing functionality/information in other endpoints.
Advanced: In a warehouse application, typical for our customers, this is one of the most critical issues with Visma.Net: It’s not possible to get the allocation details from inventorySummary. The endpoint gives you information about how much is stored on a given location, but not what batches/serial-numbers or expirationDate hit has. In the UI you must specify that you need the allocation details, but the API is missing this feature. Sample usage scenarios that are not supported: A: Stock Movement. Before doing stock movement it is important to validate that the stock is not reserved on an active delivery etc. Getting the “free” stock for a specific batch on a location is much more efficient than getting all shipments, with lines, to compare if the serial number is assigned to any of them. Giving the user a change to verify this before confirming a lot of lines on a device is helpful. B: Stock Validation: Especially with fresh food, flowers and other high turnover goods it’s common to do a stock validation. Not a stock take. Locations are often floating zones, and when you have some time you scan a product/batch to see what location it’s supposed to be placed at. You can’t really halt production to do a stocktake, and it’s not always about counting, but more about “cleanup” or evaluating if a stocktake is needed.
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.
Listing/Paging. Today we need to do a single get per product, per warehouse. When counting requests. A customer with 30k products, and 10 warehouses. Needs a few requests. When including the request going to Inventory to fetch the actual product information we get 300.060 request. And still don’t have the allocation details. Queuing the request and having an average request time of around 0.5sec sets the initial sync for a new customers to 41,7 hours. The first stock value is obviously outdated at this point. Single get requests might be easier for the SQL server, but the overhead and load of the API itself must be noticeable. Even though you could to optimization on the request you still have to overhead of the request, and the client library etc. A 200% speed increase would not give 200% improved performance for the end user. If increasing the overall speed to much the customer will simply hit the rate limiter instead. Listing is key, paging is fine.
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.
... View more
.gif "VISMA"){kind=icon}
Visma Denmark
Visma Finland
Visma Latvia
Visma Netherlands
Visma Norway
Visma Sweden
Visma Developers & Partners
Visma Latin America