Dein System hat keine Schnittstelle? Dann Dateien.
Acht definierte Datensätze, per CSV oder REST. Damit läuft max.dash auf jedem Lagersystem - auf einer Eigenentwicklung genauso wie auf einem Enterprise-WMS, das nie eine öffentliche API hatte.
Warum es diesen Weg gibt.
Weil die größten Fulfiller die schlechtesten Schnittstellen haben. Das ist kein Zufall, sondern eine Folge von Wachstum.
- Ab einer bestimmten Größe baut man selbst. Betriebe mit fünfstelligen Tagesmengen fahren häufig eine eigene Lagersoftware, weil kein Standardsystem ihre Prozesse abbildet. Eine öffentliche API haben diese Systeme nie - sie hatten nie einen Grund dafür.
- Enterprise-WMS sind projektiert, nicht integriert. Die großen Lagerverwaltungen im deutschsprachigen Raum werden pro Kunde parametriert und laufen typischerweise im eigenen Rechenzentrum. Ein Developer-Portal gibt es dort nicht, dafür eine Datenbank mit allem drin.
- Gewachsene Landschaften sind der Normalfall. Ein Standort auf System A, ein zugekaufter Betrieb auf System B, ein Großkunde mit eigenem Portal daneben. Wer darauf wartet, dass alle drei eine API bekommen, wartet dauerhaft.
Ein Adapter je Hersteller löst das nicht. Ein definiertes Schema löst es sofort - und zwar für alle drei Fälle gleichzeitig.
Die acht Datensätze.
Genau diese acht, keine weiteren. Sie sind bewusst schmal gehalten: alles, was für Steuerung, Nachweis und Abrechnung gebraucht wird, und nichts darüber hinaus.
Tabelle seitlich scrollen
| Datensatz | Was drinsteht | Wofür max.dash es braucht |
|---|---|---|
| Marken | deine Mandanten mit Kennung und Namen | die Trennlinie für jede Auswertung und jeden Portal-Login |
| Mitarbeiter | wer packt, mit der Kennung, die im Lager gescannt wird | Leistung je Person, Zuordnung zur Zeiterfassung |
| Sendungen | je Paket: Mandant, Zeitstempel, Bearbeiter, Carrier | Durchsatz, SLA-Quote, Abrechnungsmenge |
| Lieferscheine | der Auftragsbezug zur Sendung | Durchlaufzeit von Auftrag bis Versand |
| Positionen | was in der Sendung lag, mit Menge | Gewichtung und Punktesystem je Paketinhalt |
| Offene Aufträge | der aktuelle Rückstand | Tagesprognose, Personalbedarf, Frühwarnung |
| Bestand | je Mandant und Artikel | Reichweite, Lagerwert, Portal-Bestandsansicht |
| Bewegungen | Wareneingang und Retouren | Retourenquote, Wareneingangsleistung |
Nicht geliefert werden müssen Preise, Margen, Lohndaten und Endkundendaten über Name und Lieferadresse hinaus. Die Betriebssteuerung braucht sie nicht, also stehen sie nicht im Schema.
Wie die Daten zu uns kommen.
Zwei Wege, du wählst den, der zu deinem System passt. Beide sind gleichwertig, keiner braucht eine Installation bei dir.
CSV per SFTP
Dein System oder ein geplanter Datenbank-Export legt acht Dateien in ein Verzeichnis. max.dash holt sie ab. Das ist der Weg für alles, was einen Berichts- oder Datenbankexport kann - und das kann praktisch jedes Lagersystem.
REST-Push
Dein System schickt die Datensätze aktiv an einen Endpunkt. Der Weg für Eigenentwicklungen, die ohnehin eine eigene Schnittstellenschicht haben - meist eine Sache von wenigen Stunden auf deiner Seite.
Die harte Schemaprüfung ist Absicht. Ein Import, der fehlerhafte Zeilen stillschweigend überspringt, produziert Auswertungen, die plausibel aussehen und falsch sind - und niemand merkt es. Lieber eine abgelehnte Lieferung mit Zeilennummer als eine SLA-Quote, die drei Tage lang zu gut war.
Was du damit bekommst.
Den vollen Funktionsumfang. Der Unterschied zur direkten Anbindung ist die Latenz, nicht der Leistungsumfang.
Tabelle seitlich scrollen
| Funktion | Über den Import | Aus welchen Datensätzen |
|---|---|---|
| SLA-Quote je Mandant | ja | Sendungen, Lieferscheine, Marken |
| Durchsatz und Tagesprognose | ja | Sendungen, offene Aufträge |
| Leistung je Mitarbeiter | ja | Sendungen mit Bearbeiter, Mitarbeiter |
| Punktesystem nach Paketinhalt | ja | Positionen |
| Kundenportal je Mandant | ja | Marken als Trennlinie |
| Abrechenbare Mengen | ja | Sendungen, Bewegungen |
| Reichweite und Lagerwert | ja | Bestand |
| Retouren und Wareneingang | ja | Bewegungen |
Was der Import nicht kann: den Live-Monitor auf dem Wandbildschirm minutengenau führen. Wer stündlich liefert, sieht Stunden. Für SLA-Nachweis, Abrechnung, Leistungsauswertung und das Kundenportal ist das ohne Bedeutung - das sind Tages- und Monatsgrößen.
Wen dieser Weg erreicht.
Alles, was exportieren kann. In der Praxis fallen darunter drei Gruppen, die über einen Konnektor nie erreichbar wären.
- Eigenentwicklungen. Die eigene Lagersoftware, gewachsen über Jahre, mit einer Datenbank, die alles weiß. Genau hier ist der Import nicht die zweite Wahl, sondern der einzige und gleichzeitig schnellste Weg.
- Enterprise-WMS ohne öffentliche Schnittstelle. LFS, Infios, pL-Store X, PROLAG World, LogoS, storelogix, COGLAS, plx.wmx, SuPCIS-L8, Logistics Vision Suite, w3/max. Alle führen in der Datenbank, wer welche Buchung gemacht hat - ein Berichtsexport genügt.
- Systeme im Verbund. Wenn ein Standort auf einem System läuft und ein anderer auf einem zweiten, kommen beide in dasselbe Cockpit: eines direkt angebunden, eines über den Import. Für die Auswertung ist das transparent.
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.
Wie die Anbindung läuft.
Vier Schritte. Der Aufwand liegt einmalig bei dir, danach läuft es automatisch.
Schema und Exportweg
Du bekommst die Schema-Beschreibung der acht Datensätze mit Feldliste und Beispieldatei. Wir klären gemeinsam, welcher Weg in deinem System der einfachste ist.
Erste Lieferung
Du lieferst einmal historische Daten, üblicherweise 90 Tage. Daran wird das Mapping gebaut und die Vollständigkeit geprüft.
Regeln je Mandant
Cutoff-Zeit, Werktage, Feiertage, Ausschlüsse - je Marke. Dazu die Zuordnung deiner Scanner-Benutzer zu den Mitarbeitern.
Abnahme
Eine echte Woche wird gegengeprüft: stimmen Mengen, SLA-Quote und Leistung mit dem, was du selbst weißt. Erst dann läuft es scharf.
Kurz gefragt.
Reicht wirklich eine CSV-Datei?
Ja. Acht Dateien, ein definiertes Schema je Datei, Ablage per SFTP oder Push per REST. Wenn dein System exportieren kann, kann es max.dash beliefern. Ein Reporting-Export aus einer Datenbank oder ein geplanter Job genügen.
Wie aktuell sind die Zahlen beim Import?
So aktuell, wie du lieferst. Bei einem stündlichen Export sind die Zahlen stündlich aktuell, bei einem nächtlichen entsprechend täglich. In der App steht sichtbar, aus welchem Stand die angezeigten Zahlen kommen - damit niemand eine Zahl für aktueller hält, als sie ist.
Fehlen mir Funktionen, wenn ich über den Import komme?
Nein. Der Import trägt den vollen Funktionsumfang: SLA je Mandant, Leistung je Mitarbeiter, Punktesystem, Kundenportal, Abrechnungsmengen, Reichweite, Retouren und Wareneingang. Der Unterschied zur direkten Anbindung ist die Latenz, nicht der Umfang.
Was passiert, wenn eine Datei fehlerhaft ist?
Der Import prüft das Schema hart und lehnt eine fehlerhafte Lieferung ab, statt sie halb zu verarbeiten. Du bekommst die Meldung mit Zeile und Feld. Der letzte gültige Stand bleibt stehen - es entstehen keine stillen Lücken in den Auswertungen.
Wie viel Aufwand ist das auf meiner Seite?
Einmalig die acht Exporte aufsetzen, danach läuft es automatisch. Wer schon Reporting-Exporte aus seinem System zieht, baut meist auf Vorhandenem auf. Wir liefern die Schema-Beschreibung und prüfen die ersten Lieferungen gemeinsam mit dir.
Und wenn mein System später eine Schnittstelle bekommt?
Dann wechseln wir den Datenweg und aus Stunden Latenz werden Minuten. An deinen Auswertungen, Mandanten und Portal-Zugängen ändert sich dabei nichts - die Definitionen liegen in max.dash, nicht im Datenweg.
Schick uns, was dein System exportieren kann.
30 Minuten, unverbindlich. Wir sagen dir am Beispiel deiner eigenen Exportdatei, was daraus wird - und was noch fehlt.