Lagerort von Artikel (der per PlentyGetVariations abgerufen wird)?

Hi Synesty,

ich benötige im Flow makeList-Kombination für den "letzten" Teil (alle Steps die mit CL beginnen) jeweils den Lagerort des Artikels.

Ich hab mir schon ein bisschen Gedanken dazu gemacht und würde wohl so vorgehen (Steps die mit LO beginnen):

1) ein (anderer) PlentyGetVariations ruft alle aktiven Artikel ab und dient als Input für

2) einen PlentyGetStockMovements-Step, der dazu die Bewegungen abruft um in einem

3) SpreadsheetFilter auf die Warenausgänge reduziert zu werden (Filter auf ReasonString)

4) ein SpreadsheetMapper gruppiert danach nach VariantID, wobei StorageLocationName (und alle anderen) jeweils den Wert der jeweils ersten Zeile erhalten.

Das gibt mir den Lagerort des letzten Warenausgangs, sprich den aktuell genutzten. Den schreib ich mir in einen Datastore den ich eh schon hab, und ruf den dann später per Querverweis wieder ab. Funktioniert soweit auch ganz gut, nur: die API-Last erscheint mir dann doch viel zu hoch :/

Für 11936 aktive Varianten werden mir endlos viele (läuft noch) Bewegungen abgerufen. Ich muss schon früher filtern!

Leider gibt PlentyGetStockMovements nicht allzu viele Filter her: CreatedAt From auf prop_lastruntime zu setzen macht nicht wirklich Sinn, ich kann nicht garantieren dass es überhaupt eine Bewegung gab seitdem.

Wenn ich allerdings limitItems auf (z.B.) 100 setzen würde, und der erste Artikel hat 150 Bewegungen, dann hab ich halt nur die Bewegungen für den ersten Artikel. Was ich gern hätte, ist quasi pro VariantID nur die ersten x Bewegungen abzurufen. So könnte ich die Last senken, seh aber nicht wie ich das bewerkstelligen kann. Jemand eine Idee?

Danke, Daniel

Idee: vielleicht klappt es ja doch mit dem CreatedAt=prob_lastruntime. Wenn es keine Bewegung gab, kommt auch kein Ergebnis, dann bleibt eben der letzte Lagerplatz gesetzt.

Ich muss den Datastore dann nur einmal ordentlich initialisieren, damit jeder Artikel auch einen "letzten" Lagerort hat. Ab da wär dann kein Problem mehr, nur: um an den Punkt zu kommen muss ich trotzdem für alle Artikel Warenbewegungen abgerufen haben, mir fehlt also wieder der Filter.

Jemand ne Idee, außer sich über ein frei gewähltes Datum für CreatedAt quasi langsam ranzutasten? Was mach ich wenn ein Artikel vor 3 Jahren die letzte Bewegung hatte? Dann "verstopfen" mir ja trotzdem alle Artikel die davor Bewegungen hatten quasi den Abruf :/

Ich steh in wenig auf dem Schlauch, vielleicht fällt euch ja was ein...

Hab jetzt mal alle Bewegungen ab April abgerufen, das waren 138092 in Summe. Leider bleiben mir immer noch 4226 Artikel ohne Lagerort jetzt. CreatedFrom dazu nehmen und als nächstes den Bereich von Januar bis April abrufen? Dann letztes Quartal von 2017, usw, und immer wieder schauen ob wir schon alles haben?

Gibts ne elegantere Lösung?

PS: VariationWarehouseStorageLocation aus GetVariations habt ich gesehen, aber das gibt mir LagerplatzIDs, ich brauch aber Lagerplatznamen. Alle Lagerplätze (140.000, müssen wir mal aufräumen) in einen Datastore zu schreiben macht wahrscheinlich auch nicht weniger Last, und kostet noch dazu DS-Zeilen, während ich für die oben skizzierte Lösung einen schon vorhandenen DS nutzen kann.

Habe ein ähnlich gelagertes Problem im Flow SH_saveItemData:


In den Steps mit "negative"-Prefix rufe ich per PlentyGetCurrentStocks den Bestand auf Lagerplätzen ab, und prüfe ob der irgendwo negativ ist. Wenn ja soll eine Mail ans Lager raus gehen.


Per SOAP sind hier immer auch die Lagerplatzbezeichnungen mit gekommen, per REST jetzt nur noch die ID. Wie komme ich an die Bezeichnungen? (Alle Lagerplätze in einen Datastore zu schreiben ist viel zu viel...)

Hallo Daniel,


das mit den Namen der Lagerpositionen ging bei REST auch schon. Seit dem Lager-Umbau bei Plenty ging es nicht mehr (siehe https://forum.plentymarkets.com/t/fehler-bei-get-rest-stockmanagement-warehouses-warehouseid-stock-storagelocations-call-to-undefined-relationship-storagelocation/308509). Bisher hat es auch keiner unserer Kunden vermisst bzw. haben sich die Kunden einen Workarround über den PlentyGetStorageLocations Step gebaut. Bei 140.000 Lagerplätzen wäre das natürlich nicht so toll.


Ich habe gerade den REST Call nochmal gestest. Offensichtlich ist es inzwischen wieder möglich die Details zur Lagerposition abzurufen. Ich werde den GetCurrentStocks Step wieder erweitern, sodass es voraussichtlich ab Mitte nächster Woche wieder möglich sein wird, die Details abzurufen.


Viele Grüße

Torsten

PS. das mit pro Variant ID nur die x Bewegungen im GetStockMovements wäre theoretisch auch möglich (ein GET Call pro Variante). Ich kann aber auch nicht für die Sortierung garantieren. Aktuell kommt die neueste Warenbewegung zuerst. Ich würde ich das vorerst nicht einbauen und hoffe du kannst das dann auch über den GetCurrentStocks Step lösen.

Cool, dann schau ich mir das Ende nächster Woche nochmal an, danke!


Wenn ich btw ein GetCurrentStocks im StorageLocation-Modus benutze und einen Filter anschließe, bietet mir der nur die Spalten für den Warehouse-Mode zur Filtergenerierung an...

Nebenfrage: Kann ich nur Bestände für einen/zwei definierte Lagerplätze abrufen? Mit GetCurrentStocks kann ich nur alle abrufen und dann anschließend auf die ID filtern...

Hallo Daniel,


der PlentyGetCurrentStocks Step hat jetzt einen neuen mode (Storage Location Stock with Warehouse Location) der auch die Informationen zur Lagerposition mit abruft. Den Filter für eine spezielle StroageLocationID habe ist auch eingebaut (erweiterte Einstellungen)




VG Torsten

Sehr cool, danke!

Klitzekleine Kritik: alle anderen Spalten fangen mit kleinem "storage*" an, nur der neue, der hat ein großes S ;-)


Gruß Daniel