Geen Date Modified in tabel `ItemWarehouseStorageLocations`

Voor het binnenhalen van de voorraad per locatie gebruik ik de volgende tabel:

ExactOnlineREST.Inventory.ItemWarehouseStorageLocations@eol

Deze tabel is bij ons nogal groot (13.000 records).

Ik wil daarom alleen nieuwe en aangepaste record binnen halen.

Als er geen Incremental is gebruik ik het veld DateModified.

Maar in deze tabel komt dit veld niet voor. Ik kan nergens een filter leggen.

Is hier een oplossing voor of een andere tabel waar ik de voorraad per locatie kan ophalen?

Het geheel binnenhalen zal momenteel 13.000 / 60 = circa 217 API calls vragen. Dit is te overzien.

Het is mogelijk dat deze tabel in Exact Online niet als dusdanig bestaat, maar mogelijkerwijs een API is die uit meerdere tabellen samengesteld en/of getotaliseerd wordt. Dit zou het ontbreken van een DateModifed kunnen verklaren, omdat er dan extra moeite gedaan zou moeten worden om met bijvoorbeeld max een kunstmatige datum te bepalen.

Het is ook mogelijk dat deze DateModified op de voorraadposities per opslaglocatie gewoon vergeten is.

In beide gevallen is het raadzaam om dit bij Exact onder de aandacht te brengen door een “Idea” op te voeren in de API groep op https://support.exactonline.com. Hier heb je de komende maanden echter waarschijnlijk weinig aan.

217 API calls is niet bijster veel, maar er zijn verschillende manieren om met minder toe te kunnen. Eerste vraag die je kunt stellen of het wel nodig is om de voorraad per locatie (StorageLocation) te weten. Vaak is de huidige totale voorraad of voorraad per magazijn al voldoende voor het bedrijfsproces en dan is de sync API StockPositionsIncremental vele malen efficienter.

Als het toch op storage location moet, dan kun je nog overwegen te werken met een startstand die eens per week opgehaald wordt, en uit de magazijnbewegingen zoals in WarehouseTransferLines (of uit de financiele transacties voor zover mogelijk) een schatting kunnen afleiden. Je mist dan misschien voorraadtellingen, maar geeft wel een beeld.

Ik zou zelf de 217 API-calls accepteren en gewoon de lijst dagelijks volledig ophalen.