Welches System führt? Schnittstellen für Lohn, Kasse und Zahlungsdienstleister
Welche Daten in welchem System führend sind, wohin sie fließen und wann eine Datei-Schnittstelle reicht oder eine API nötig ist.
Am Monatsende liegen drei Dateien auf dem Tisch: das Lohnjournal aus dem Lohnsystem, die Tagesabschlüsse der Kasse und die Abrechnung des Zahlungsdienstleisters. In der Buchhaltung stimmt ein Betrag nicht, und niemand kann sagen, welche Zahl die richtige ist. Jede Stelle verweist auf ihr eigenes System. Das kostet Rückfragen, doppelte Korrekturen und Buchungen, die später wieder aufgemacht werden müssen. Die Ursache ist fast nie die Schnittstelle selbst. Es ist die ungeklärte Frage, welches System für welche Daten das führende ist.
Der Fall: Eine Korrektur, zwei Wahrheiten
Ein Mitarbeiter wechselt die Kostenstelle. Die Personalabteilung ändert es im Lohnsystem, das Controlling im ERP. Im nächsten Lohnjournal steht die alte Kostenstelle wieder, weil der Import die Daten des Lohnsystems überschreibt.
Das ist Datenhoheit: Pro Datenart darf genau ein System Änderungen annehmen. Alle anderen Systeme lesen nur. Gibt es zwei Stellen, an denen ein Wert geändert werden darf, gewinnt irgendwann die falsche.
Prüffrage: Wo würden Sie heute eine Änderung an diesem Wert vornehmen, und würde sie beim nächsten Datenlauf bestehen bleiben?
Schritt 1: Datenarten auflisten
Notieren Sie je Fachsystem, welche Datenarten dort entstehen. Je Zeile eine Datenart:
- Mitarbeiterstammdaten, Lohnarten, Lohnjournal
- Artikelstamm, Preise, Verkaufsdaten der Kasse oder der Ticket-Terminals
- Zahlungen, Gebühren und Auszahlungen des Zahlungsdienstleisters
- Kunden, Lieferanten, Rechnungen
- Fahrzeuge, Anlagen, Wartungsobjekte, sofern Sie solche führen
- Bestand und Produktdaten, falls ein Shop angebunden ist
Fügen Sie nur Datenarten hinzu, die tatsächlich zwischen Systemen wandern. Ein Feld, das nur in einem System existiert, braucht keine Entscheidung.
Schritt 2: Je Datenart genau ein führendes System festlegen
Ein Betrieb mit Lohn, Kasse und Zahlungsdienstleister kann diese Faustregeln anwenden:
- Lohn: Das Lohnsystem führt Mitarbeiter, Lohnarten und Abrechnung. Das ERP erhält das Ergebnis, zum Beispiel das monatliche Lohnjournal, und bucht es. Simplify-ERP übernimmt in einem Projekt etwa das Lohnjournal aus einem SAP-Textexport nach Odoo. Die Richtung bleibt einseitig.
- Kasse und Terminals: Die Kasse führt den einzelnen Verkauf. Das ERP führt den Artikelstamm und liefert ihn an die Kasse. Zwei Datenarten, zwei Richtungen. Das ist erlaubt, solange jede für sich eindeutig ist.
- Zahlungsdienstleister: Er führt, was tatsächlich bezahlt, einbehalten und ausgezahlt wurde. Das ERP führt, was berechnet wurde. Beide Seiten stimmen Sie ab, keine überschreibt die andere. In einem Projekt werden Verkaufsdaten von Ticket-Terminals und Abrechnungen des Zahlungsdienstleisters in Odoo bereitgestellt und gebucht.
- Stammsatz als Anker: Wenn mehrere Objekte auf dasselbe Ding verweisen, braucht dieses einen Stammsatz. In einem Fahrzeugbetrieb ist das Fahrzeug der Stammsatz; Anlage, Wartungsobjekt und Kostenstelle verweisen darauf, statt es zu kopieren.
Entscheidungsregel: Führt das System, in dem die Daten zuerst entstehen und fachlich verantwortet werden? Wenn ja, bleibt es führend. Wenn nein, begründen Sie schriftlich, warum ein anderes führen soll.
Schritt 3: Die Richtung und den Weg festlegen
Für jede Beziehung zwischen zwei Systemen legen Sie fest, in welche Richtung die Daten fließen und wie.
Datei oder API? Wenn die Daten einmal je Periode fließen und niemand sie zwischendurch braucht, reicht eine Datei, etwa ein Export mit festem Format. Ein Beispiel sind die Exportprofile, mit denen Buchhaltungsdaten an die österreichische Software BMD gehen. Wenn Bestände, Bestellungen oder Zahlungen zeitnah in beiden Systemen stimmen müssen, brauchen Sie eine API, also eine Programmierschnittstelle, über die Systeme einzelne Datensätze austauschen.
Zweirichtungsfall Shop: Bei einer Shop-Anbindung führt meist das ERP die Produktdaten, der Shop führt die Bestellung. Produkte gehen von Odoo zum Shop, Aufträge und Kontakte kommen zurück. Bei mehreren Shops muss es weiterhin ein einziges führendes Produktsystem geben. Dazu passt, dass ein gemeinsamer Kanal-Kern mehrere Konnektoren an ein Odoo bindet.
Prüffrage: Gibt es eine Datenart, die in beide Richtungen fließt? Dann legen Sie Feld für Feld fest, welche Seite gewinnt.
Schritt 4: Die Karte zeichnen
Zeichnen Sie ein Blatt mit einem Kasten je System. Beschriften Sie jeden Kasten mit den Datenarten, für die er führt. Ziehen Sie Pfeile in Flussrichtung und schreiben Sie darauf: Datei oder API, Rhythmus, wer bei Fehlern zuständig ist.
Prüfen Sie die Karte gegen diese Fälle:
- Unternehmensweite Suche: Wenn eine Suche über alle Odoo-Daten läuft, liest sie nur. Sie darf nichts zurückschreiben. Ein Datenspeicher neben dem ERP, wie der Odoo DataLake mit seiner kontinuierlichen Synchronisation, erscheint auf der Karte als Leseziel, nicht als führendes System.
- KI-Automatisierung ohne Code: Ein Agent, der Dokumente verarbeitet oder Kundenanfragen beantwortet, schreibt Daten. Tragen Sie ein, in welches System und welches Feld er schreibt, und ob ein Mensch das Ergebnis vorher bestätigt.
- Shop-Anbindung: Siehe oben: Produkt führend im ERP, Bestellung führend im Shop.
- Versionsupgrade: Jede Schnittstelle, die in Odoo schreibt oder liest, muss nach einem Upgrade erneut getestet werden. Die Karte zeigt, welche das sind.
- Solar-PV-Betrieb: Laufen Vertrieb, Projekte, Lager und Buchhaltung in einer Software, entfallen Schnittstellen zwischen ihnen. Prüfen Sie dann nur noch die Grenzen nach außen, etwa zum Zahlungsdienstleister oder zum Lohn.
Schritt 5: Abweichungen regelmäßig abgleichen
Eine Karte verhindert Streit, aber keine Fehler. Legen Sie fest, wann Sie die Systeme vergleichen. Ein Beispiel ist der monatliche Abgleich eines Datenimports gegen die Saldenliste. Dabei vergleichen Sie die Summen aus dem Import mit den Salden im Hauptbuch. Weicht eine Summe ab, suchen Sie die Ursache im Quellsystem und korrigieren dort, nicht im ERP.
Bei Buchungen gilt: Gebuchte Belege überschreiben Sie nicht durch einen erneuten Import. Ein Probelauf, der nichts schreibt, zeigt vorher, was ein Import ändern würde.
Ihr nächster Schritt
Nehmen Sie heute eine Datenart, bei der es zuletzt Streit über die richtige Zahl gab, zum Beispiel Kostenstelle, Artikelpreis oder Auszahlungsbetrag. Schreiben Sie drei Angaben auf: Welches System führt sie? Wohin fließt sie? Wer korrigiert sie bei Fehlern? Können Sie nicht alle drei Fragen mit einem Namen beantworten, haben Sie Ihre erste Lücke auf der Karte gefunden.
