Wiegesoftware und ERP verbinden: Welche Daten in welche Richtung fließen

Eine Schnittstelle zwischen Wiegesoftware und ERP verbindet den kaufmännischen Auftrag mit der tatsächlich gewogenen Lieferung. Häufig stellt das ERP Kunden, Materialien und Aufträge bereit. Die Wiegesoftware meldet Gewichte, Lieferscheine und den Bearbeitungsstand zurück. Fahrzeugdaten und Preise werden dort übernommen, wo sie für den Ablauf benötigt werden und wo ihre Pflege vereinbart ist.

Damit entfällt das erneute Abtippen vieler Angaben. Doch ein Datenexport allein löst die Aufgabe noch nicht: Ein im ERP gesperrter Auftrag muss an der Waage rechtzeitig als gesperrt erkennbar sein. Eine erneut übertragene Lieferung darf nicht doppelt in die Abrechnung gelangen. Und bei einer Mengenabweichung müssen beide Seiten denselben Vorgang meinen.

Dieser Leitfaden richtet sich an Werksleitung, kaufmännische Verantwortliche und IT. Er zeigt ein typisches Integrationsmodell für Werke und Industrie sowie die Entscheidungen, die vor der Umsetzung erforderlich sind. Die beschriebenen Regeln sind Anforderungen an eine abgestimmte Schnittstelle; ihr genauer Umfang hängt von ERP, Wiegesoftware und Betriebsablauf ab.

Der Datenfluss zwischen Wiegesoftware und ERP im Überblick

Das ERP verwaltet in vielen Betrieben die kaufmännischen Grundlagen. Die Wiegesoftware ergänzt die Informationen, die bei der Verwiegung und Abfertigung entstehen. Beide Systeme tauschen außerdem Rückmeldungen aus, damit ein offener, abgelehnter oder abgeschlossener Vorgang auf der jeweils anderen Seite erkennbar wird.

Diese Übersicht beschreibt die fachliche Richtung. Ob ein System die Daten aktiv sendet oder das andere sie abruft, ist eine zusätzliche technische Entscheidung. Auch ein Portal oder eine Integrationsplattform kann dazwischenliegen. Entscheidend bleibt, wer die Daten verantwortet und woran der erfolgreiche Abschluss einer Übergabe erkennbar ist.

Zuerst festlegen: Welches System darf welche Daten ändern?

Für jedes Datenobjekt braucht es ein führendes System: Dort werden verbindliche Änderungen vorgenommen. Das verhindert beispielsweise, dass ein Kunde im ERP anders heißt als an der Waage oder eine lokal geänderte Materialnummer beim nächsten Import überschrieben wird.

Diese Verantwortung kann innerhalb eines Stammsatzes geteilt sein. Das ERP führt etwa Kundennummer und Rechnungsanschrift, die Wiegesoftware dagegen einen lokalen Abfertigungshinweis. Dann muss die Schnittstellenbeschreibung festhalten, welche Felder sie aktualisieren darf. Eine vollständige Überschreibung des Datensatzes wäre ungeeignet.

Für Zuordnungen sind stabile Kennungen erforderlich. Ein Kundenname, eine Materialbezeichnung oder ein Kennzeichen allein ist als Verknüpfung zwischen Systemen oft zu wenig. Bei mehreren Mandanten oder Werken kann dieselbe Auftragsnummer mehrfach vorkommen. Der vereinbarte Schlüssel muss deshalb auch diesen Geltungsbereich berücksichtigen.

Besprechen Sie außerdem, was beim Stilllegen eines Stammsatzes passiert. Ein gesperrtes Material soll für neue Vorgänge nicht mehr auswählbar sein. Bereits ausgestellte Lieferscheine müssen sich trotzdem weiterhin dem damals verwendeten Material zuordnen lassen. Ein Import darf diese historischen Bezüge nicht durch unkontrolliertes Löschen zerstören.

Welche Daten braucht die Wiegesoftware aus dem ERP?

Stammdaten mit eindeutiger Bedeutung

Zum Grundbestand gehören typischerweise Geschäftspartner, Materialien, Standorte und Lieferziele. Welche weiteren Angaben nötig sind, bestimmt der Prozess: Eine Abholung für eine Baustelle benötigt andere Bezüge als eine Anlieferung auf eine Einkaufsbestellung.

Ein Feldabgleich muss über gleiche Spaltennamen hinausgehen. Bedeutet „Kunde“ den Auftraggeber, Rechnungsempfänger oder Warenempfänger? Ist die angegebene Menge bestellt, noch offen oder für die nächste Fahrt reserviert? Ohne diese Klärung können technisch korrekt übertragene Daten fachlich falsch verwendet werden.

Auch die Reihenfolge des Imports zählt. Kommt ein Auftrag vor dem zugehörigen Kunden- oder Materialstammsatz an, benötigt er einen erkennbaren Wartezustand oder eine gezielte Fehlermeldung. Die fehlende Zuordnung durch einen beliebigen Standardkunden zu ersetzen, verschiebt den Fehler bis in die Abrechnung.

Aufträge mit Position, Gültigkeit und Freigabe

Die Auftragsnummer allein reicht nicht. Die Waage muss erkennen, welche Position für welches Material, welchen Standort und welches Lieferziel gilt. Hinzu kommen, soweit im Ablauf benötigt, Freigabe, Gültigkeitszeitraum, Restmenge, Toleranzen und ein Bezug zur vorgesehenen Fahrt.

Eine Restmenge ist nur so aktuell wie ihr letzter Abgleich. Wenn zwei Standorte gleichzeitig denselben Auftrag bedienen, genügt es nicht, beiden dieselbe offene Menge anzuzeigen. Für verbindliche Mengengrenzen braucht es eine abgestimmte Reservierung, eine zentrale Freigabe oder eine andere Regel für gleichzeitige Zugriffe.

Wie solche Mengenregeln mit zentralen Stammdaten und lokalem Weiterbetrieb zusammenspielen, erläutert Mehrere Waagen und Standorte zentral steuern. Ein Beispiel mit zwei Werken zeigt, wann eine zugeteilte Restmenge wieder verfügbar werden darf.

Definieren Sie insbesondere den Umgang mit Änderungen während eines offenen Besuchs. Wird ein Auftrag zwischen Erstwiegung und Verladung gesperrt, sollte eine aktuelle Sperre den festgelegten Prüf- oder Klärungsprozess auslösen. Ein stilles Weiterarbeiten mit dem alten Stand wäre ebenso problematisch wie ein unbegründeter Abbruch jedes bereits laufenden Vorgangs.

Fahrzeugdaten aus der passenden Quelle

Das führende Fahrzeugregister kann im ERP, in der Disposition oder in der Wiegesoftware liegen. Wichtig ist eine klare Regel für neue Fremdfahrzeuge, geänderte Kennzeichen und wechselnde Gespanne. Ein lokal erfasstes Fahrzeug sollte beim nächsten Stammdatenimport nicht als zweite, unabhängige Anlage wieder erscheinen.

Bei einer Anbindung von TBAutoIdent zur Kennzeichenerkennung geht es zusätzlich darum, die Erkennung mit dem richtigen Fahrzeug- und Besuchsbezug zu verbinden. Eine gespeicherte Tara benötigt darüber hinaus ihre eigene fachlich abgestimmte Herkunfts- und Aktualitätsprüfung; sie darf nicht wie eine beliebige Stammdatenzahl behandelt werden.

Müssen Preise an die Waage übertragen werden?

Nur wenn der Ablauf an der Waage Preise tatsächlich benötigt. Wird jede Lieferung anschließend im ERP bepreist, kann die Wiegesoftware freigegebene Mengen, Material, Kunde, Auftrag und Position übergeben. Die kaufmännische Bewertung erfolgt dann an einer Stelle.

Anders ist es beispielsweise bei einem vereinbarten Direktverkauf am Waageplatz. Wenn dort ein Betrag ermittelt werden soll, benötigt die lokale Anwendung die dafür gültigen Konditionen oder eine zuverlässige Preisabfrage. Welche Anwendung dabei Beleg und Abrechnung erstellt, ist ausdrücklich festzulegen.

Ein Preisimport braucht mehr als einen Zahlenwert: Währung, Preiseinheit, Gültigkeitszeitraum, Material- und Kundenbezug sowie die benötigten Zu- oder Abschläge gehören zur gemeinsamen Definition. Ein Preis pro Tonne und eine Menge in Kilogramm müssen vor der Berechnung korrekt zusammengeführt werden. Runden und Umrechnen sind ebenfalls verbindlich zu vereinbaren.

Besonders wichtig ist der maßgebliche Zeitpunkt. Soll eine nachträgliche Preisänderung eine bereits abgeschlossene Lieferung beeinflussen? Soll der Preis bei Auftragserteilung, Lieferung oder Abrechnung gelten? Die Antwort ergibt sich aus dem vereinbarten Geschäftsvorgang. Sie darf nicht zufällig davon abhängen, wann eine Datei übertragen wurde.

Was meldet die Wiegesoftware zurück?

Die Rückmeldung sollte eine Lieferung so beschreiben, dass das ERP sie ohne erneute manuelle Zuordnung verarbeiten kann. Welche Messdetails unmittelbar übertragen und welche über einen Dokument- oder Datensatzverweis zugänglich gemacht werden, hängt vom vorgesehenen Nachweis- und Abrechnungsprozess ab.

Ein PDF und strukturierte Lieferscheindaten erfüllen unterschiedliche Aufgaben. Das Dokument dient der lesbaren Darstellung. Strukturierte Daten erlauben die Zuordnung und Weiterverarbeitung einzelner Felder. Wer nur ein PDF versendet, hat deshalb noch keine automatische ERP-Verbuchung erreicht. Wer nur Zahlen überträgt, muss die Verbindung zum zugehörigen Beleg trotzdem sicherstellen.

Die freigegebene Nettomenge darf nicht unbemerkt durch eine Zielmenge oder einen geänderten Stammdatenwert ersetzt werden. Falls eine kaufmännische Abrechnungsmenge von der gewogenen Menge abweicht, sind beide Größen und der Grund dafür getrennt zu führen. Ebenso entscheidet ein technischer Import allein noch nicht, ob eine Rechnung erstellt werden darf.

Ein Beispiel: Vom Auftrag zur übernommenen Lieferung

Ein Kieswerk erhält im ERP einen Auftrag über 100 t Schotter. Die folgende Abholung ist eine Teillieferung auf Position 10. Alle Kennungen und Mengen in diesem Beispiel dienen nur der Erläuterung.

1. Das ERP stellt den Auftrag bereit. Übergeben werden unter anderem Auftrag A-4711, Position 10, Kunde, Baustelle, Material, Standort und Freigabe. Die Wiegesoftware bestätigt die Übernahme oder zeigt fehlende Zuordnungen an.
2. Die Wiegesoftware legt den Besuch an. Der Besuch V-00852 wird mit dem Fahrzeug und genau dieser Auftragsposition verbunden. Ein weiterer Besuch desselben Fahrzeugs erhält eine eigene Kennung.
3. Die Wiegungen ergeben die Liefermenge. Im Beispiel stehen 12.420 kg Tara und 31.680 kg Brutto fest. Daraus ergeben sich 19.260 kg Netto, also 19,26 t. Die bestellten 100 t bleiben eine eigene Auftragsgröße.
4. Der freigegebene Lieferschein wird übergeben. Die Rückmeldung zu LS-00852 enthält 19,26 t sowie den Auftrags-, Positions- und Vorgangsbezug. Die Definition der Schnittstelle legt fest, in welcher Einheit die Werte übertragen werden.
5. Das ERP bestätigt die fachliche Verarbeitung. Es meldet die übernommene Lieferung samt eigener Referenz zurück. Erst wenn keine anderen Lieferungen oder Reservierungen zu berücksichtigen sind, beträgt die verbleibende Auftragsmenge in diesem Beispiel 80,74 t.

Das Beispiel zeigt auch, warum Bestellmenge, Zielmenge, Wiegeergebnis und offene Menge getrennte Felder benötigen. Eine einzige Spalte „Menge“ könnte alle vier Bedeutungen haben. Den Ablauf auf dem Werksgelände erläutert ergänzend der Artikel Von der Fahrzeugwaage zum digitalen Wiegeprozess.

API, Datei oder Ereignis: Was muss die Schnittstelle leisten?

Eine API ist ein programmatischer Zugang zum anderen System. Ein Dateiaustausch übergibt dagegen beispielsweise CSV- oder XML-Dateien in einem vereinbarten Verfahren. Ereignisbasierte Verbindungen melden Änderungen, etwa einen freigegebenen Lieferschein, zur weiteren Verarbeitung. Diese Ansätze lassen sich kombinieren.

Die Entscheidung sollte sich am Ablauf orientieren. Eine Preis- oder Freigabeabfrage vor der Abfertigung benötigt eine passende Antwortzeit. Die spätere Übergabe eines Belegpakets kann unter Umständen zeitversetzt erfolgen. Eine schnelle Verbindung ist nur dann hilfreich, wenn auch Datenbedeutung, Rückmeldung und Störungsbehandlung stimmen.

Eine gute Schnittstellenbeschreibung beantwortet mindestens folgende Fragen:

• Felder und Formate: Welche Angaben sind Pflicht? Wie werden Einheiten, Dezimalwerte und Zeitpunkte einschließlich Zeitzone dargestellt? Wie unterscheiden sich ein leerer Wert und eine echte Null?
• Kennungen und Versionen: Welche Schlüssel gelten systemübergreifend? Woran wird ein neuer Stand erkannt? Wie werden führende Nullen in Kennungen erhalten?
• Zeitverhalten: Wann werden Änderungen bereitgestellt, abgeholt und als veraltet bewertet? Wie schnell müssen Sperren wirksam werden?
• Rückmeldungen: Wie bestätigt der Empfänger einzelne Vorgänge? Wie werden teilweise abgelehnte Übertragungen behandelt?
• Weiterentwicklung: Welche Schnittstellenversion wird unterstützt, und wie werden Feldänderungen vor einem ERP-Update gemeinsam getestet?

Beim Dateiaustausch muss außerdem feststehen, wann eine Datei vollständig bereitliegt, wie ihre Verarbeitung bestätigt wird und wie eine erneute Einlieferung erkannt wird. Bei einer API sind unter anderem Zeitlimits, erlaubte Wiederholungen und die Bedeutung der Antworten festzulegen. Ein direkter Schreibzugriff auf fremde Datenbanktabellen sollte nur Teil einer vom Systemhersteller vorgesehenen Integrationslösung sein.

„Versendet“ ist noch nicht „fachlich verarbeitet“

Für einen belastbaren Tagesabschluss benötigen Waage und Verwaltung einen verständlichen Übernahmestatus. Sinnvoll ist die Trennung zwischen lokal abgeschlossen, zur Übertragung vorgemerkt, technisch angenommen, fachlich verarbeitet und zur Klärung abgelehnt. Die Bezeichnungen dürfen anders lauten; die Unterschiede müssen im Betrieb sichtbar sein.

Ein technisches Beispiel liefert HTTP: Der Status 202 Accepted bedeutet, dass eine Anfrage zur Verarbeitung angenommen wurde; die Verarbeitung selbst ist damit noch nicht abgeschlossen. Das legt RFC 9110, Abschnitt 15.3.3 fest. Eine solche Antwort genügt daher nicht als alleiniger Nachweis, dass ein Lieferschein im ERP fachlich verarbeitet wurde.

Vereinbaren Sie eine Rückmeldung mit Vorgangskennung, Ergebnis und gegebenenfalls ERP-Referenz. Bei Ablehnung sollte eine verständliche Ursache hinzukommen, beispielsweise „Materialnummer unbekannt“ oder „Auftragsposition gesperrt“. Ein bloßer Fehlercode ohne zuständige Stelle lässt die Nachbearbeitung liegen.

Die Übersicht sollte auch erkennen lassen, seit wann ein Vorgang wartet. Ein gestern abgelehnter Beleg verlangt eine andere Reaktion als eine gerade erst vorgemerkte Übertragung. Zum Abschluss einer Schicht lassen sich offene Fälle dann gezielt klären, statt die Vollständigkeit erst aus fehlenden Rechnungen abzuleiten.

Wiederholungen, Korrekturen und Ausfälle kontrollieren

Dieselbe Lieferung darf nicht doppelt wirken

Nach einer Unterbrechung kann unklar sein, ob eine Rückmeldung angekommen ist. Vielleicht hat das ERP den Lieferschein bereits verarbeitet, aber seine Bestätigung erreicht die Wiegesoftware nicht mehr. Die erneute Übertragung muss diesen Fall erkennen können.

Das Prinzip heißt idempotente Verarbeitung: Eine Wiederholung derselben fachlichen Übergabe erzeugt keine zweite Lieferung oder Buchung. Dafür benötigt der Empfänger eine stabile Kennung und eine passende Prüfung. Microsoft beschreibt die Bedeutung wiederverwendbarer Nachrichtenkennungen im Zusammenhang mit verlorenen Bestätigungen in seiner Dokumentation zur Duplikaterkennung. Eine solche Transportfunktion ersetzt jedoch keine abgestimmte Prüfung im empfangenden Geschäftsprozess.

Für die Abnahme bedeutet das: Denselben freigegebenen Beleg gezielt mehrfach senden und im Zielsystem prüfen, dass er nur einmal wirksam wird. Kommt unter derselben Kennung ein anderer Inhalt an, muss ein Konflikt sichtbar werden. Eine echte Korrektur erhält dagegen ihren vereinbarten Versions- oder Korrekturbezug.

Änderungen müssen auf beiden Seiten ankommen

Ist ein Beleg bereits übernommen, reicht eine lokale Änderung nicht aus. Der Empfänger muss erkennen, welcher ursprüngliche Vorgang betroffen ist, welcher neue Stand gilt und ob eine Stornierung oder ein Ersatzbeleg folgt. Ein älterer, verspäteter Datensatz darf den neueren Stand nicht wieder überschreiben.

Werden die Daten bereits in einer Rechnung verwendet, gehört die kaufmännische Korrektur in den dafür vorgesehenen Prozess. Die Schnittstelle sollte diesen Zusammenhang anzeigen und den Vorgang zur zuständigen Stelle führen. Einfach das Gewicht in einem importierten Datensatz zu ändern, schafft keine nachvollziehbare Korrekturkette.

Den vollständigen Ablauf von Begründung und Freigabe bis zum Abgleich der Liefermenge zeigt Wiegebelege korrigieren und Stornos nachvollziehbar dokumentieren. Das Praxisbeispiel behandelt eine bereits übernommene Lieferung mit falschem Auftragsbezug.

Eine Warteschlange ist noch kein Notfallkonzept

Eine dauerhaft gespeicherte Liste ausstehender Übergaben kann helfen, Daten nach einer Störung kontrolliert nachzuliefern. Sie beantwortet aber nicht, ob ohne ERP-Verbindung neue Aufträge angenommen oder Preise verwendet werden dürfen. Dafür sind lokale Datenverfügbarkeit, Aktualitätsgrenzen und Freigaberegeln gesondert festzulegen.

Nach dem Wiederanlauf sollten zunächst Abhängigkeiten und Datenstände geprüft werden. Technische Störungen können einen erneuten Sendeversuch erlauben; fachliche Ablehnungen benötigen meist eine Korrektur oder Freigabe. Jeder Wiederanlauf muss erkennen lassen, was übernommen wurde, was noch offen ist und was weiterhin geklärt werden muss.

Das Notfallkonzept für Netzwerk- und ERP-Ausfälle verbindet diese Übergaberegeln mit lokalem Weiterbetrieb, Ersatzbelegen und Wiederherstellung. Ein Rechenbeispiel zeigt, wie eine verlorene Bestätigung beim erneuten Import zu einer doppelten Liefermenge führen kann.

Berechtigungen und Zuständigkeiten gehören zur Verbindung

Ein technischer Zugang sollte nur die für seinen Zweck benötigten Daten und Aktionen erreichen. Legen Sie fest, wer den Zugang betreibt, Zugangsdaten erneuert und Fehler analysiert. Verschlüsselte Übertragung, kontrollierte Berechtigungen und eine Trennung von Test- und Produktivsystem gehören in die technische Umsetzung.

Nicht jeder Empfänger benötigt dieselben Angaben. Ein Selbstbedienungsablauf mit TBTouchScale braucht die für den aktuellen Besuch freigegebenen Informationen. Vollständige Kundenkonditionen oder die Aufträge anderer Geschäftspartner sollten dadurch nicht automatisch für den Fahrer sichtbar werden. Entsprechend sind auch Schnittstellendaten und Protokolle auf ihren tatsächlichen Zweck zu begrenzen.

Benennen Sie vor dem Start eine verantwortliche Stelle für die gesamte Übergabe. Waagepersonal klärt eine falsche Auftragsauswahl anders als die IT einen Verbindungsfehler. Für kaufmännische Ablehnungen braucht es wiederum die zuständige Verwaltung. Diese Aufteilung sollte in Fehlermeldung und Arbeitsablauf erkennbar sein.

Mit diesen Fällen prüfen Sie die ERP-Anbindung

Ein erfolgreicher Musterimport ist ein Anfang. Die folgenden Situationen zeigen, ob die Verbindung auch mit Änderungen und Unterbrechungen umgehen kann. Führen Sie die Abnahme gemeinsam mit Waagepersonal, Verwaltung und den beteiligten Systemverantwortlichen durch.

Vergleichen Sie zum Abschluss nicht nur die Anzahl der Belege. Gleiche Anzahlen können unterschiedliche fehlende und doppelte Vorgänge verdecken. Prüfen Sie die einzelnen Kennungen und Versionen sowie die Summen je Material, Standort und Einheit. So wird aus einer Vorführung ein belastbarer Nachweis für den eigenen Ablauf.

Weitere Auswahlkriterien für Software, Betrieb und Einführung finden Sie in der vollständigen Anforderungsliste für Wiegesoftware.

Häufige Fragen zur Schnittstelle zwischen Wiegesoftware und ERP

Muss das ERP alle Stammdaten führen?

Nein. Entscheidend ist eine eindeutige Zuständigkeit je Datenobjekt beziehungsweise Feld. Kaufmännische Grundlagen können aus dem ERP kommen, während lokale Abfertigungshinweise oder Fahrzeugdaten in einem anderen System gepflegt werden. Die Schnittstelle muss diese Aufteilung respektieren.

Braucht die Anbindung immer Echtzeit?

Nein. Die erforderliche Aktualität hängt von der Entscheidung ab. Eine Freigabe vor der Verladung kann eine zeitnahe Prüfung verlangen; eine Belegübergabe zur späteren Abrechnung kann gegebenenfalls verzögert erfolgen. Für beide Fälle müssen zulässige Verzögerung und Verhalten bei veralteten Daten feststehen.

Genügt es, den Lieferschein als PDF zu senden?

Für die Bereitstellung eines lesbaren Dokuments kann das genügen. Für eine automatische Zuordnung und Weiterverarbeitung im ERP werden normalerweise zusätzlich strukturierte Daten oder ein entsprechender Zugriff benötigt. Dokument und Datensatz müssen denselben Beleg und dieselbe Version beschreiben.

Kann bei einem ERP-Ausfall weitergewogen werden?

Das hängt von der eingesetzten Lösung und dem freigegebenen Notfallverfahren ab. Lokal verfügbare Aufträge und eine gespeicherte Liste offener Übertragungen können unterstützen. Sie ersetzen keine Regeln dafür, welche Vorgänge mit welchem Datenstand während der Störung noch erlaubt sind.

Den Datenfluss mit TBScale konkretisieren

TBScale lässt sich über abgestimmte Schnittstellen in ERP-, Fakturierungs-, Portal- und Archivprozesse einbinden. Welche Stammdaten, Wiegedaten und Dokumente ausgetauscht werden, wird passend zur vorhandenen Systemlandschaft und zum Materialfluss festgelegt. Den branchenspezifischen Rahmen beschreibt unsere Seite zur Wiegesoftware für die Baustoffbranche.

Für ein erstes Gespräch helfen ein Beispielauftrag mit Positionen, ein typischer Lieferschein und die Schnittstellenbeschreibung Ihres ERP. Ergänzen Sie einen Fall, der heute regelmäßig Nacharbeit verursacht. Daran lässt sich konkret besprechen, welche Daten fehlen, wer sie pflegt und wie der erfolgreiche Abschluss einer Übergabe künftig erkennbar sein soll.

ERP-Anbindung mit TBSoft besprechen