Viele Marken, eine Instanz, keine getrennte Zahl.
max.dash liest dein plentyONE über die REST-API mit und macht daraus SLA-Quote je Mandant, Leistung je Mitarbeiter und ein Portal, in dem jeder deiner Auftraggeber nur seine eigenen Zahlen sieht.
plentyONE ist ein Produkt der plentyONE GmbH (vormals plentymarkets). Alle genannten Produkt- und Firmennamen sind Marken der jeweiligen Inhaber. Die Nennung dient ausschließlich der Angabe der Kompatibilität. Eine Geschäftsbeziehung, Partnerschaft oder Zertifizierung ist damit nicht verbunden.
Was ein Händler-ERP für Dienstleister offen lässt.
plentyONE führt Aufträge, Bestand und Warenwirtschaft. Es ist nicht dafür gebaut, deinen Auftraggebern zu beweisen, dass du geliefert hast - und genau danach wirst du gefragt.
- Die SLA-Quote ist nicht definiert, sondern nur berechenbar. Auftrags- und Statusdaten sind vollständig da. Was fehlt, ist die Rechenregel: ab wann läuft die Uhr, wann ist Cutoff, welche Tage sind Werktage, welche Aufträge sind ausgeschlossen, und das getrennt je Mandant.
- Leistung je Person steht überhaupt nicht im Auftrag. plentyONE trägt am Auftrag nur die Auftragsherkunft mit - den Auftraggeber-Bezug, keine Zuordnung, wer gepickt oder gepackt hat.
- Ein Mandantenportal ist nicht mitgedacht. plentyONE denkt Fulfillment als Auslagerung an Dritte, nicht als eigenen Betriebsmodus im System - die Trennung nach Auftraggebern für einen eigenen Login muss also von außen kommen.
- Abrechenbare Mengen je Mandant sammelt jemand zusammen. Aufträge, Retouren, Sonderleistungen - am Monatsende, aus Listen, von Hand.
Welche Daten wir aus plentyONE lesen.
Die Anbindung läuft über die dokumentierte REST-API mit Self-Serve-Zugangsdaten. Die Doku ist saubere Anbieter-Doku, es braucht keine Freigabe außerhalb deines eigenen Kontos und kein Zusatzmodul.
Tabelle seitlich scrollen
| Was wir lesen | Woraus | Wofür |
|---|---|---|
| Aufträge und Status | Auftragsobjekt, REST-API | Durchsatz, Rückstand, SLA-Uhr |
| Auftragsherkunft | eine Angabe am Auftragskopf | die Mandantentrennung, überall |
| Zeitstempel der Statuswechsel | Auftragsverlauf | Durchlaufzeit, Cutoff-Prüfung |
| Positionen je Auftrag | Auftragspositionen | Gewichtung, Punktesystem |
| Bestand und Lagerbewegungen | Warenwirtschaft | Reichweite, Wareneingang, Retouren |
Nicht gelesen werden Preise, Margen und Endkundendaten, die über Name und Lieferadresse hinausgehen. Beides braucht die Betriebssteuerung nicht.
Wie die Leistung je Mitarbeiter zustande kommt.
plentyONE liefert am Auftrag nur eine Herkunfts-ID, keine Bearbeiter-Zuordnung. Damit ist die Leistung je Mitarbeiter nicht direkt aus dem Auftrag lesbar - sie entsteht über einen zweiten, ebenso verlässlichen Weg.
Das ist keine Einschränkung von plentyONE, die die Anbindung ausschließt - es ist der gleiche Weg, den max.dash bei jedem System ohne Bearbeiterfeld geht. Die Zeiterfassung liefert, wer wann am Scanner angemeldet war, das Mapping verknüpft diesen Benutzer mit dem Auftrag. Details dazu stehen unter Zeiterfassung anbinden.
Tarif und Rate-Limit - ein ehrlicher Planungspunkt.
plentyONE begrenzt lesende API-Aufrufe tarifabhängig. Im Basic-Tarif sind es 80 Lese-Calls pro Minute, in höheren Tarifen bis 280 pro Minute. Das ist kein verstecktes Problem, sondern etwas, das im Onboarding einmal geklärt wird.
Für die Betriebssteuerung heißt das konkret: Abfragefrequenz und Umfang der synchronisierten Objekte werden auf den vorhandenen Tarif abgestimmt, bevor die Anbindung in den Regelbetrieb geht. Bei mehreren Mandanten auf einem Zugang verteilt sich das Limit auf alle Abfragen gemeinsam, das wird beim Mapping berücksichtigt. Wer einen höheren Tarif fährt, bekommt entsprechend mehr Abfragespielraum und damit aktuellere Zahlen im Cockpit - wer im Basic-Tarif bleibt, bekommt trotzdem eine funktionierende Anbindung, nur mit einem etwas großzügigeren Abfrageintervall. Ein Ausschlussgrund ist das Limit in keinem Fall, es ist schlicht ein Parameter, den die Anbindung von Anfang an einplant.
Fulfillment als Auslagerung, nicht als Betriebsmodus.
plentyONE ist als Auftrags- und Warenwirtschaftssystem für Händler gebaut. Fulfillment kommt darin als Konzept vor - aber als etwas, das ein Händler an einen Dritten auslagert, nicht als eigener Betriebsmodus des Systems selbst.
Für einen Fulfillment-Dienstleister heißt das konkret: Die Mandantentrennung, die ein 3PL-Betrieb täglich braucht, ist in plentyONE keine vorgegebene Struktur. Es gibt die Auftragsherkunft als Bezug am Auftrag, aber kein natives Konzept für "mein Auftraggeber A darf nur seine eigenen Zahlen sehen, Auftraggeber B nur seine". Diese Trennung muss von außen aufgebaut werden - genau das leistet max.dash: Auftragsherkünfte werden beim Mapping auf Mandanten abgebildet, jede Auswertung und jeder Portal-Login hält sich strikt an diese Linie. Für Fulfiller, die plentyONE als zentrales Auftragssystem für mehrere Auftraggeber nutzen, ist das der Unterschied zwischen einer Software für den eigenen Warenfluss und einem Cockpit, das mehrere Kunden gleichzeitig sauber getrennt bedient.
Was max.dash daraus macht.
Aus den gelesenen Objekten entsteht kein zweites Auftragssystem, sondern die Auswertung, die plentyONE nicht führt.
Tabelle seitlich scrollen
| Funktion | Mit plentyONE | Woraus |
|---|---|---|
| SLA-Quote je Mandant | ja | Zeitstempel, Auftragsherkunft, deine Cutoff- und Werktagsregeln |
| Durchsatz und Tagesprognose | ja | Aufträge je Stunde, Historie |
| Leistung je Mitarbeiter | über Zeiterfassung | Zeiterfassungs-Anbindung, Scanner-Benutzer-Mapping |
| Punktesystem nach Auftragsinhalt | über Zeiterfassung | Positionen je Auftrag, Benutzer-Mapping |
| Kundenportal je Mandant | ja | Auftragsherkunft als Trennlinie |
| Abrechenbare Mengen | ja | Aufträge, Retouren, Sonderpositionen |
| Reichweite und Lagerwert | ja | Bestand je Mandant |
| Retouren und Wareneingang | ja | Lagerbewegungen |
Wie die Anbindung läuft.
Vier Schritte, wenige Tage. Du installierst nichts, und dein plentyONE bleibt unangetastet.
API-Zugang anlegen
Du legst in deinem plentyONE-Konto Self-Serve-Zugangsdaten mit Leserechten an. Wir sagen dir, welche Rechte die Anbindung braucht - und welche ausdrücklich nicht.
Auftragsherkunft mappen
Die Auftragsherkunft wird auf deine Mandanten abgebildet. Das ist die Linie, an der später jede Auswertung und jeder Portal-Login trennt.
Tarif und Rate-Limit prüfen
Dein plentyONE-Tarif entscheidet über 80 oder bis zu 280 Lese-Calls pro Minute. Abfragefrequenz und Umfang werden darauf abgestimmt, bevor es in den Regelbetrieb geht.
Abnahme
Eine echte Woche wird gegengeprüft: stimmen SLA-Quote, Mengen und - falls angebunden - Leistung mit dem, was du selbst weißt. Erst dann geht die Anbindung in den Regelbetrieb.
Wenn im Verbund ein anderes System steht.
Viele Fulfiller fahren nicht ein System, sondern zwei oder drei - je Standort, je Auftraggeber, je gewachsener Historie. Das ist kein Sonderfall, sondern der Normalfall.
max.dash liest mehrere Quellen in dasselbe Cockpit. Aus derselben Gattung, ERP mit Lagerteil, kommen außerdem Xentral, weclapp und JTL-Wawi - jedes davon mit einer eigenen Seite, auf der steht, welche Objekte gelesen werden und wie der Zugang entsteht.
Für jedes System mit offener Schnittstelle läuft die Anbindung wie hier für plentyONE beschrieben. Für alles andere gibt es den definierten Import: acht Datensätze per Datei oder REST, voller Funktionsumfang, Latenz Stunden statt Minuten. Was dafür geliefert werden muss, steht offen auf Eigenes System anbinden.
Kurz gefragt.
Muss ich plentyONE wechseln oder erweitern?
Nein. plentyONE bleibt dein Auftrags- und Warenwirtschaftssystem und wird nicht verändert. max.dash liest über die vorhandene REST-API mit und legt eine Auswertungsschicht darüber. Kein Systemwechsel, kein zusätzliches Modul in plentyONE.
Schreibt max.dash in mein plentyONE?
Nein. Der Zugriff ist rein lesend. Die gelesenen Daten werden in eine eigene Datenbank gespiegelt und dort ausgewertet. In plentyONE wird nichts angelegt, geändert oder gelöscht.
Wie kommt die Leistung je Mitarbeiter zustande, wenn plentyONE keinen Bearbeiter liefert?
plentyONE hält am Auftrag nur die Auftragsherkunft fest - das ist der Auftraggeber- beziehungsweise Herkunftsbezug, keine Bearbeiter-Zuordnung für Pick oder Pack. Für die Leistung je Mitarbeiter nutzt max.dash den zweiten Weg: die Zeiterfassungs-Anbindung wird mit dem Scanner-Benutzer-Mapping verknüpft, damit steht die Auswertung trotzdem, ohne dass plentyONE selbst eine Bearbeiter-ID liefern muss.
Was bedeuten die Rate-Limits von plentyONE für die Anbindung?
plentyONE begrenzt lesende API-Aufrufe tarifabhängig: im Basic-Tarif 80 Lese-Calls pro Minute, in höheren Tarifen bis 280 pro Minute. Das ist kein Ausschlussgrund, sondern ein Planungspunkt im Onboarding - die Abfragefrequenz wird auf den vorhandenen Tarif abgestimmt, bevor die Anbindung in den Regelbetrieb geht.
Wie lange dauert die Anbindung?
Wenige Tage. API-Zugang anlegen, Auftragsherkunft und Mandanten mappen, Tarif und Rate-Limit prüfen, Abnahme an einer echten Woche. Du installierst nichts.
Sieh deine eigene SLA-Quote, bevor du dich entscheidest.
30 Minuten, unverbindlich. Wir zeigen an echten Zahlen, was aus deinen plentyONE-Daten wird.