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	Ansprechpartnerdetails
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.

4.2 Gridware Party (Custom)

Zweck

Die Gridware Party 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

Alle späteren Geschäftsprozesse greifen indirekt auf den Gridware Party Datensatz zurück.

Aufbau des Doctypes

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

Die Informationen lassen sich in mehrere Bereiche unterteilen.

Tab 1 – Details

Der Reiter Details enthält die grundlegenden Stammdaten sowie die fachliche Klassifizierung der Entität.

Connections

Im oberen Bereich werden sämtliche Beziehungen der Gridware Party zu anderen ERPNext-Objekten dargestellt.

Hierzu gehören insbesondere:

Customer – Verknüpfung zum kaufmännischen Kunden
Supplier – Verknüpfung zum Lieferanten
Gridware Contract – Zugeordnete Verträge

Dadurch ist jederzeit nachvollziehbar, in welchen kaufmännischen Prozessen die Entität verwendet wird.

Basic Identity

Dieser Bereich beschreibt die eigentliche Identität der Entität.

Gespeichert werden unter anderem:

Display Name
Party Kind (Person oder Organisation)
Gridware Subject ID
Vorname
Nachname
Anrede
Aktivstatus

Die Gridware Subject ID stellt den eindeutigen technischen Identifikator dar und dient als Referenz für sämtliche Synchronisationsprozesse.

Contact

Hier werden die grundlegenden Kommunikationsinformationen gespeichert.

Beispiele:

Telefonnummer
E-Mail-Adresse

Diese Daten dienen später als Grundlage für die automatische Erstellung bzw. Aktualisierung von ERPNext Contacts.

Role Classification and Links

Dieser Bereich definiert die fachliche Rolle der Entität innerhalb des Systems.

Eine Entität kann dabei folgende Rollen besitzen:

Customer
Supplier
Customer und Supplier gleichzeitig

Zusätzlich werden hier die jeweiligen Gridware-spezifischen Nummern gespeichert.

Beispiele:

Gridware Customer Number
Gridware Supplier Number
Externe Kundennummer

Diese Informationen werden in späteren Geschäftsprozessen, insbesondere im Vertragsmanagement und in der Abrechnung, verwendet.

Tab 2 – Address & Contact

Der Reiter Address & Contact verwaltet sämtliche Adressinformationen einer Gridware Party.

Dabei wird bewusst zwischen den Originaldaten aus Gridware und den innerhalb ERPNext erzeugten Stammdaten unterschieden.

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 mit einer ID versehen, die direkt zu der Gridware Party zugeordnet werden kann.

Raw Address

Im oberen Bereich werden sämtliche Adressen gespeichert, die direkt aus Gridware synchronisiert wurden.

Hierzu gehören beispielsweise:

Address ID
Adresstyp (z. B. POSTAL)
Straße
Hausnummer
Postleitzahl
Ort
Land
Zusatzinformationen

Diese Daten stellen den unveränderten Datenbestand aus Gridware dar und dienen als Grundlage für die weitere Verarbeitung innerhalb ERPNext.

Address & Contact

Im unteren Bereich können aus den synchronisierten Rohdaten automatisch ERPNext-Stammdaten erstellt werden.

Hier werden anschließend die eigentlichen ERPNext-Objekte verwaltet:

Address
Contact

Dadurch erfolgt eine klare Trennung zwischen den synchronisierten Gridware-Daten und den kaufmännischen Stammdaten innerhalb ERPNext.

Diese Struktur ermöglicht es, Änderungen an den Originaldaten nachzuvollziehen und gleichzeitig die ERPNext-Standards vollständig zu nutzen.

Tab 3 – Payment Method

Der Reiter Payment Method enthält sämtliche Zahlungsmethoden, die einer Gridware Party zugeordnet sind.

Da eine Entität mehrere Zahlungsmethoden besitzen kann (immer nur eine Methode aktiv, die anderen als Historie), wurde dieser Bereich als Child Table umgesetzt.

Jede Zeile repräsentiert eine einzelne Gridware Payment Method.

Gridware Payment Method

Für jede Zahlungsmethode werden unter anderem folgende Informationen gespeichert:

Gridware Payment ID
Payment Type (z. B. SEPA)
ERPNext Bank Account
Bank Name
IBAN
BIC
ERPNext SEPA Mandate
SEPA Mandate ID
Erstellungsdatum
Kennzeichnung als Standard-Zahlungsmethode

Zweck

Dieser Bereich bildet die Grundlage für sämtliche Zahlungsprozesse innerhalb der ERPNext-Lösung.

Die gespeicherten Informationen werden insbesondere verwendet für:

Erstellung von SEPA-Mandaten
Zuordnung von Bankkonten
Generierung von SEPA-XML-Dateien
Zahlungsabwicklung
Payment Entries

Durch die Verknüpfung zwischen der Gridware Payment ID und dem ERPNext Bank Account kann jederzeit nachvollzogen werden, welche Zahlungsmethode aus Gridware welchem Bankkonto und welchem SEPA-Mandat in ERPNext entspric

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.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.
Ä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.