Skip to main content

Kapitel 4 – Stammdatenverwaltung

Ziel dieses Kapitels

Die Stammdaten bilden das Fundament der ERPNext-Lösung. Sämtliche nachgelagerten Prozesse – von der Vertragsverwaltung über die Verarbeitung von Ladevorgängen bis hin zur Rechnungsstellung – greifen auf diese Daten zu.

Dieses Kapitel beschreibt den Aufbau der Stammdaten, deren Herkunft sowie deren Zusammenspiel innerhalb der ERPNext-Lösung.

Nach diesem Kapitel soll der Leser verstehen,

  • welche Stammdaten innerhalb ERPNext verwaltet werden,

  • aus welchem System diese stammen,

  • wie die Synchronisation erfolgt,

  • welche Daten manuell gepflegt werden dürfen,

  • welche Stammdaten ausschließlich aus Gridware übernommen werden.

4.1 Überblick

Die Stammdatenverwaltung umfasst sämtliche dauerhaft benötigten Informationen innerhalb der ERPNext-Lösung.

Hierzu gehören insbesondere:

Stammdaten Beschreibung
Customer Rechnungsempfänger
Supplier Betreiber bzw. Lieferanten
Contact AnsprechpartnerAnsprechpartnerdetails 
Address Rechnungs-, Liefer- und Standortadressen
Gridware Party Technischer Vertragspartner aus Gridware
Company Eigene Gesellschaft(en) innerhalb ERPNext
Item Artikel für Rechnungs- und Lieferantenabrechnung
Subscription Wiederkehrende und variable Gebühren
Payment Terms Zahlungsbedingungen
SEPA Mandate Lastschriftmandate
Bank Accounts Bankkonten für SEPA Lastschriftverfahren

Diese Stammdaten werden in nahezu allen Geschäftsprozessen verwendet.

Synchronisationsprozess

4.2 GrundprinzipGridware Party (Custom) 

Zweck

Die StammdatenverwaltungGridware basiertParty bildet die zentrale Integrationsschicht zwischen der Datenstruktur von Gridware und der kaufmännischen Datenstruktur von ERPNext.

Während ERPNext zwischen Customer und Supplier unterscheidet, verfolgt Gridware einen anderen Ansatz. Dort wird zunächst in Entitäten (Parties) gedacht. Eine Entität repräsentiert entweder eine Person oder eine Organisation und beschreibt damit den eigentlichen Vertragspartner.

Erst innerhalb eines bestimmten Vertrags oder Geschäftsprozesses erhält diese Entität eine fachliche Rolle. Eine Entität kann beispielsweise:

    ausschließlich Kunde sein, ausschließlich Lieferant sein oder gleichzeitig Kunde und Lieferant sein.

    Diese Flexibilität lässt sich mit den Standard-Doctypes von ERPNext nicht abbilden, da Customer und Supplier dort voneinander getrennte Stammdatenobjekte sind.

    Aus diesem Grund wurde der Gridware Party Doctype als zentrale Integrationsschicht entwickelt.

    Rolle innerhalb der Systemarchitektur

    Der Gridware Party Doctype steht im Zentrum der Stammdatensynchronisation

    drawing-11-1784821527.png

    Alle späteren Geschäftsprozesse greifen indirekt auf einemden klarenGridware Architekturprinzip:Party Datensatz zurück.

    Aufbau des Doctypes

    Der Gridware Party Doctype speichert sämtliche grundlegenden Informationen eines Vertragspartners.

    Screenshot 2026-07-23 at 17.39.01.png

    Die Informationen lassen sich in mehrere Bereiche unterteilen.

    1. Identität

    Dieser Bereich beschreibt die eigentliche Person oder Organisation.

    Beispiele:

      Display Name

      Vorname

      Nachname

      Anrede

      Party Kind (Person / Organisation)

      Gridware Subject ID

      Die TechnischeGridware StammdatenSubject ID dient dabei als eindeutiger technischer Schlüssel zwischen Gridware und ERPNext.

      2. Kontaktinformationen

      Hier werden insämtliche GridwareKommunikationsdaten gepflegt.gespeichert. Kaufmännische StammdatenGezogen werden diese aus den contact informations von Gridware. 

      Screenshot 2026-07-23 at 17.46.46.png

      Beispiele:

        Telefonnummer

        E-Mail-Adresse

        Diese Informationen dienen später als Grundlage für Contacts innerhalb ERPNext.

        3. Rollenklassifizierung

        Ein Vertragspartner kann unterschiedliche Rollen innerhalb des Systems übernehmen.

        Beispiele:

          Customer

          Supplier

          Zusätzlich werden hier Gridware-spezifische Nummern gespeichert.

          Beispiele:

            Gridware Customer Number

            Gridware Supplier Number

            externe Kundennummern (abgelegt in ERPNextGridware) verwaltet.

            Dadurch kann derselbe Vertragspartner sowohl Kunde als auch Lieferant sein.

            4. Beziehungen

            Der Gridware Party Datensatz dient als zentrale Verknüpfung verschiedener ERPNext-Objekte.

            Hierzu gehören unter anderem:

              Customer

              Supplier

              Gridware Contract

              Dadurch lassen sich sämtliche Beziehungen eines Vertragspartners zentral nachvollziehen.

              5. Adressen und Kontakte

              Im zweiten Reiter werden sämtliche synchronisierten Adressen verwaltet. Hier werden die "Roh-Daten" zunächst gespeichert, um dann diese in ERP Next Adress- und Kontaktdaten zu übertragen. Die Adress und Kontaktdatensätze werden sowohl vom DocType Supplier als auch Customer verwendet, sodass es nicht zu Duplikaten kommt. Jeder Adress- und Kontaktdatensatz wird sichergestellt, dass jede Information nur anmit einer StelleID gepflegtversehen, die direkt zu der Gridware Party zugeordnet werden kann. 

              Screenshot 2026-07-23 at 17.52.14.png

              Screenshot 2026-07-23 at 18.22.54.png

              6. Zahlungsmethoden/ SEPA Lastschriftverfahren

              Im dritten Reiter befinden sich sämtliche Informationen rund um die Payment Methods aus Gridware. Auch hier wird erneut eine eindeutige ID aus Gridware gespeichert (Payment ID), um zukünftig bereits bestehende Datensätze updaten zu können auf Basis dieser ID. 

              Screenshot 2026-07-23 at 17.58.40.png

              Screenshot 2026-07-23 at 17.58.46.png

              Huaptsächlich handelt es sich hierbei um die SEPA Lastschriftmandate und Inkonsistenzendie vermiedendazugehörige werden.Bankverbindung. Im weiteren Verlauf wird dann ein neues SEPA Mandat erstellt, das dann die Bankkonto-Erstellung triggert.

              Beziehungen zu anderen Doctypes

              Der Gridware Party Doctype besitzt Beziehungen zu zahlreichen weiteren Objekten.

              ObjektDoctype Führendes SystemBeziehung
              PersonCustomer GridwareKaufmännischer Kunde
              OrganisationSupplier GridwareKaufmännischer Lieferant
              VertragGridware Contract GridwareVertragspartner eines Vertrags
              LadepunktAddress GridwareZugeordnete Adressen
              Contact Ansprechpartner Payment Method Gridware Customer ERPNext (auf Basis Gridware) Supplier ERPNext (auf Basis Gridware) Contact ERPNext Address ERPNextZahlungsinformationen

              Diese Beziehungen werden überwiegend automatisch über die Synchronisationsprozesse gepflegt.

               

              Typische Anwendungsfälle

              Ein Gridware Party Datensatz wird unter anderem verwendet für:

                Synchronisation neuer Kunden

                Synchronisation neuer Lieferanten

                Aktualisierung von Kontaktdaten

                Verknüpfung mit Gridware Contracts

                Zuordnung von Payment Methods

                Erstellung von Customer- und Supplier-Beziehungen

                Grundlage für Customer Portal Benutzer

                Identifikation von Vertragspartnern während der Abrechnung

                4.3 Customer

                Zweck

                Der Customer repräsentiert den kaufmännischen Rechnungsempfänger innerhalb ERPNext.

                Ein Customer kann sowohl eine Privatperson als auch ein Unternehmen sein.

                Der Customer bildet die Grundlage für:

                • Angebote

                • Aufträge

                • Rechnungen

                • Payment Entries

                • Subscriptions

                • Customer Portal

                Herkunft

                Customer werden nicht in ERP Next manuell angelegt.

                 

                Sie entstehen durch die Synchronisation der entsprechenden Organisation oder Person aus Gridware. 

                Während der Synchronisation erfolgt zusätzlich die Verknüpfung mit:

                • Contacts

                • Addresses

                • Contracts

                • Payment Methods

                Besondere Anpassungen

                Im Rahmen der Implementierung wurden Customer um projektspezifische Informationen erweitert.

                Hierzu gehören unter anderem:

                • Gridware-ID

                • Zuordnung zu Gridware Contracts

                • API-Synchronisation

                • Customer Portal

                • Vertragsinformationen

                4.4 Supplier

                Zweck

                Supplier repräsentieren Betreiber oder andere Leistungserbringer, welche später gegenüber becharged abgerechnet werden.

                Sie bilden die Grundlage für:

                • Purchase Invoices

                • Supplier Usage Data

                • Lieferantenabrechnungen

                • Rückvergütungen

                Herkunft

                Wie Customer entstehen auch Supplier auf Basis der Informationen aus Gridware.

                Die Zuordnung erfolgt über den jeweiligen Gridware Contract.

                Zukunft

                Mit der Erweiterung der Lieferantenabrechnung wird dieser Bereich deutlich an Bedeutung gewinnen.

                Insbesondere werden zukünftig weitere Funktionen ergänzt:

                • Lieferantengutschriften

                • Selbstabrechnung

                • Auszahlungsprozesse

                • Supplier Statements

                4.5 Contacts

                Contacts enthalten sämtliche Ansprechpartner eines Customers oder Suppliers.

                Ein Unternehmen kann mehrere Ansprechpartner besitzen.

                Typische Rollen:

                • Primary Contact

                • Billing Contact

                • Technical Contact

                Bei der Erstellung von Verkaufsdokumenten wird automatisch der passende Ansprechpartner verwendet.

                4.6 Addresses

                Adressen werden getrennt von Customer und Supplier verwaltet.

                Dadurch können mehrere Adressen einem Geschäftspartner zugeordnet werden.

                Beispiele:

                • Rechnungsadresse

                • Lieferadresse

                • Firmenstandort

                • Ladepark

                • Baustelle

                Für die Druckformate gelten projektspezifische Regeln bezüglich Customer Name, Address Title und Contact Person.

                (Verweis auf Kapitel "Druckformate")

                4.7 Items

                Artikel bilden die Grundlage sämtlicher Rechnungs- und Lieferantenabrechnungen.

                Je nach Geschäftsmodell werden unterschiedliche Artikel verwendet.

                Beispiele:

                • Ladevorgänge

                • Monatliche Grundgebühren

                • Hardware

                • Dienstleistungen

                • Erstattungen

                Die Zuordnung erfolgt später über die Vertragslogik.

                4.8 Subscriptions

                Subscriptions bilden die Grundlage für wiederkehrende Abrechnungen.

                Sie werden insbesondere verwendet für:

                • monatliche Grundgebühren

                • Vertragsgebühren

                • Servicegebühren

                Zusätzlich werden im Rahmen der monatlichen Abrechnung die entsprechenden Verbrauchsdaten ergänzt.

                4.9 Payment Terms & SEPA

                Für jeden Customer können Zahlungsbedingungen und SEPA-Informationen hinterlegt werden.

                Die SEPA-Stammdaten stammen grundsätzlich aus Gridware und werden nach ERPNext synchronisiert.

                Sie bilden die Grundlage für:

                • SEPA-XML

                • Payment Entries

                • Lastschriftverfahren

                4.10 Synchronisationsprozess

                Die Stammdaten werden automatisiert synchronisiert.

                Der grundsätzliche Ablauf sieht wie folgt aus:

                1. Gridware stellt neue oder geänderte Stammdaten bereit.

                2. ERPNext ruft diese Daten über die REST-API ab.

                3. Bestehende Datensätze werden aktualisiert oder neue Datensätze angelegt.

                4. Beziehungen zwischen Customer, Supplier, Contacts und Contracts werden automatisch hergestellt.

                5. Die Stammdaten stehen anschließend für alle nachgelagerten Prozesse zur Verfügung.

                4.11 Typische Fehler

                Problem Ursache Lösung
                Customer fehlt Synchronisation nicht durchgeführt API-Synchronisation prüfen
                Supplier fehlt Gridware Party nicht zugeordnet Contract prüfen
                Contact fehlt Ansprechpartner nicht synchronisiert API erneut ausführen
                Adresse falsch Änderungen nur in ERPNext vorgenommen Änderungen in Gridware durchführen
                SEPA fehlt Mandat nicht synchronisiert Payment Method prüfen

                4.12 Best Practices

                Für die Pflege der Stammdaten gelten folgende Grundregeln:

                • Stammdaten grundsätzlich im führenden System pflegen.

                • Manuelle Änderungen an synchronisierten Feldern vermeiden.

                • Kontakte und Adressen vollständig pflegen.

                • Dubletten vermeiden.

                • Änderungen nach Möglichkeit über die vorgesehenen Synchronisationsprozesse durchführen.

                Zusammenfassung

                Die Stammdatenverwaltung bildet die Grundlage aller weiteren Geschäftsprozesse. Eine konsistente Pflege und Synchronisation der Stammdaten ist Voraussetzung für eine fehlerfreie Vertragsverwaltung, Abrechnung und Finanzbuchhaltung.

                Ich würde hier allerdings eine kleine strukturelle Änderung vornehmen

                Je länger ich über euer System nachdenke, desto mehr glaube ich, dass Items und Subscriptions keine Stammdaten im eigentlichen Sinn sind.

                Ich würde deshalb Kapitel 4 ausschließlich auf die Geschäftspartner konzentrieren:

                • Customer

                • Supplier

                • Contact

                • Address

                • Gridware Party

                Items, Subscriptions, Payment Terms und SEPA-Mandate würde ich erst in den jeweiligen Fachkapiteln behandeln – also beispielsweise Items in der Abrechnungslogik und Subscriptions in der Kundenabrechnung. Dadurch bleibt jedes Kapitel thematisch fokussiert und der Leser findet Informationen dort, wo sie im Prozess tatsächlich relevant werden.