Descartes pixi weiß, wer gescannt hat. Ausgewertet wird es nicht.
max.dash liest dein Descartes pixi rein lesend mit und macht daraus SLA-Quote je Shop, Leistung je Mitarbeiter und ein Portal, in dem jeder deiner Auftraggeber nur seine eigenen Zahlen sieht.
pixi* ist ein Produkt der Descartes Systems Group Inc. 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 pixi führt und was es nicht auswertet.
Descartes pixi führt dein Lager. Es ist nicht dafür gebaut, deinen Auftraggebern zu beweisen, dass du geliefert hast - und genau danach wirst du gefragt.
- Die SLA-Quote je Shop ist nicht definiert, sondern nur berechenbar. Die Sendungsdaten liegen vollständig vor. 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 Shop.
- Leistung je Person steht im Rohdatensatz, nicht im Bericht. Wer die Sendung gescannt und wer die Position bearbeitet hat, gibt pixi heraus. Die Auswertung über Tage, Schichten und Paketinhalte ist damit möglich, aber nicht vorhanden.
- Dein Auftraggeber hat keinen eigenen Zugang zu seinen Zahlen. Also fragt er per Mail. Jeden Tag, je Marke.
- Abrechenbare Mengen je Shop sammelt jemand zusammen. Pakete, Retouren, Sonderleistungen - am Monatsende, aus Listen, von Hand.
Welche Daten wir aus Descartes pixi lesen.
Die Anbindung läuft über die offen dokumentierte REST-API von Descartes pixi, mit Basic Auth. Die Dokumentation ist frei zugänglich, ohne Sign-in und ohne Freigabe durch den Anbieter. Es braucht kein Zusatzmodul in pixi.
Tabelle seitlich scrollen
| Was wir lesen | Woraus | Wofür |
|---|---|---|
| Aufträge und Sendungen | Sendungsdaten | Durchsatz, Rückstand, SLA-Uhr |
| Bearbeiter je Sendung | Scan-Protokoll je Sendung | Leistung je Mitarbeiter |
| Bearbeiter je Position | Positionsebene | positionsgenaue Leistung, Gewichtung |
| Shop-Zuordnung | Rechnungsdaten je Shop | Mandantentrennung |
| Instanzprüfung | Systemcheck beim Onboarding | Prüfung, was in deiner Instanz verfügbar ist |
| Ereignisse | Systembenachrichtigungen | zeitnahe Aktualisierung statt fester Abfrage-Takt |
Nicht gelesen werden Preise, Margen und Endkundendaten, die über Name und Lieferadresse hinausgehen. Beides braucht die Betriebssteuerung nicht.
Wer gepickt und verpackt hat - direkt aus der Quelle.
Descartes pixi gibt die Bearbeiter-Zuordnung direkt heraus, auf zwei Ebenen. Deshalb ist die Leistungsrechnung hier ohne Zeiterfassungs-Umweg möglich - mit einem Setup-Schritt, der einmal erledigt wird und danach läuft.
pixi gibt die Sendungen mandantenübergreifend heraus, ohne dass eine Shop-Kennung direkt mitgeliefert wird. Für die Auswertung je Shop entsteht die Zuordnung deshalb über eine zweite Abfrage - ein Schritt im Onboarding, kein Hindernis. Dazu kommt ein zweiter Punkt, der bei pixi in der Architektur liegt: nicht jede Kundendatenbank hat denselben Funktionsumfang. Deshalb prüfen wir zu Beginn, was in deiner Instanz konkret verfügbar ist, bevor irgendetwas produktiv gestellt wird. Wie max.dash daraus Minuten pro Paket und eine Gewichtung nach Paketinhalt rechnet, steht im Leitfaden zur Mandanten-Auswertung.
Was max.dash daraus macht.
Aus den gelesenen Objekten entsteht kein zweites Lagersystem, sondern die Auswertung, die dein Lagersystem nicht führt.
Tabelle seitlich scrollen
| Funktion | Mit Descartes pixi | Woraus |
|---|---|---|
| SLA-Quote je Mandant | ja | Zeitstempel aus den Sendungsdaten, Shop als Mandantenlinie, deine Cutoff- und Werktagsregeln |
| Durchsatz und Tagesprognose | ja | Sendungen je Stunde, Historie |
| Leistung je Mitarbeiter | ja | Scan- und Bearbeiterdaten je Sendung und Position |
| Punktesystem nach Paketinhalt | ja | Positionen je Sendung |
| Kundenportal je Mandant | ja | Shop-Zuordnung aus dem Onboarding |
| Abrechenbare Mengen | ja | Sendungen und Positionen je Shop |
| Reichweite und Lagerwert | ja | Bestandsdaten aus der API |
| Retouren und Wareneingang | ja | Bewegungsdaten aus der API |
Wie die Anbindung läuft.
Vier Schritte, wenige Tage. Du installierst nichts, und dein Descartes pixi bleibt unangetastet.
Zugang und Instanz-Check
Du legst in pixi einen API-Benutzer mit Basic Auth an. Parallel prüfen wir, ob deine pixi-Instanz die für die Anbindung nötigen Funktionen tatsächlich bereitstellt.
Shops als Mandanten mappen
Deine Shops werden auf deine Mandanten abgebildet, inklusive der zweiten Abfrage, die die Shop-Zuordnung herstellt. Das ist die Linie, an der später jede Auswertung und jeder Portal-Login trennt.
Regeln und Scan-Benutzer
Cutoff-Zeit, Werktage, Feiertage und Ausschlüsse je Shop. Dazu die Zuordnung der pixi-Scan-Benutzer zu deinen Mitarbeitern.
Abnahme
Eine echte Woche wird gegengeprüft: stimmen SLA-Quote, Mengen und 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. Im deutschsprachigen Fulfillment stehen daneben am häufigsten JTL-Wawi, WEMALO und VARIO Cloud - 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 Descartes pixi 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 Descartes pixi wechseln oder erweitern?
Nein. Descartes pixi bleibt dein Lagersystem 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 pixi.
Schreibt max.dash in mein pixi-System?
Nein. Der Zugriff ist rein lesend, per Basic Auth über die offen dokumentierte REST-API von Descartes pixi. Die gelesenen Daten werden in eine eigene Datenbank gespiegelt und dort ausgewertet. In pixi wird nichts angelegt, geändert oder gelöscht.
Warum braucht die Mandantentrennung einen Zwischenschritt?
pixi liefert die Sendungsdaten, aber keine Shop-Kennung direkt mit. Für die mandantenscharfe Auswertung je Shop wird deshalb eine zweite Abfrage ergänzt. Das ist kein Mangel, sondern ein einmaliger Setup-Schritt, der beim Onboarding erledigt wird.
Wie kommt die Leistung je Mitarbeiter zustande?
Descartes pixi gibt die Bearbeiter-Zuordnung direkt heraus, auf Sendungsebene und auf Positionsebene. max.dash rechnet daraus Mengen und Minuten pro Paket je Person, ohne dass etwas rekonstruiert werden muss.
Wie lange dauert die Anbindung?
Wenige Tage. API-Benutzer anlegen, Prüfung deiner Instanz, Shops als Mandanten mappen, Scan-Benutzer zuordnen, 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 pixi-Daten wird.