@Florian Haase wrote:
First we thought that the minor part of agreements is based on item-connections (instead of item-group), but now I see thats actually the major part. That means nearly each inventory-item has any connection to one or more of the agreements. Since we need the External InventoryID (stored in the attributes on the inventory-Items) I run a get call now on each involved inventory-Item to get the external ID. (we get each inventory just once even it is used on several discount agreements since we store the result in the memory and reuse it). That causes in the end an overflow in max number of requests (at least in some situations).
It seams to be better to get the whole inventory database from Visma.Net first with some fewer calls. We did not do this by design first, because the inventory endpoint is so extremly slow but that would of course reduce the number of calls. We will get some more inventories than needed but that's maybe the only way to get around the problem?
If the External-ID is static once the discount setup is done, storing all the historical data in your end would be definitely more efficient. In this way you can fetch the new records with "createdDateTime" or "lastmodifieddatetime" filters targeting to retrieve new inventories or only if there are any changes on the item.
Alternatively, you can check the New Sales Order API Service that GET-Inventory Endpoint is available and should perform better. <https://salesorder.visma.net/swagger/index.html>
Should return the inventory with the attribute values assigned.
https://salesorder.visma.net/api/v3/Inventory?expand=Attribute
Getting started with the first neXtGen service: Visma.net ERP Sales Order API
... Meer weergeven
.gif "VISMA"){kind=icon}
Visma Nederland
Visma Finland
Visma Letland
Visma Noorwegen
Visma Zweden
Visma Developers & Partners
Visma Latijns-Amerika