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.
Synchronisationsprozess
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.
1.Connections
Im oberen Bereich werden sämtliche Beziehungen der Gridware Party zu anderen ERPNext-Objekten dargestellt.
Hierzu gehören insbesondere:
Dadurch ist jederzeit nachvollziehbar, in welchen kaufmännischen Prozessen die Entität verwendet wird.
Basic Identity
Dieser Bereich beschreibt die eigentliche PersonIdentität oderder Organisation.Entität.
Beispiele:Gespeichert werden unter anderem:
Display Name
Vorname
Nachname
Anrede
Party Kind (Person /oder Organisation)
Gridware Subject ID
Vorname Nachname Anrede AktivstatusDie Gridware Subject ID stellt den eindeutigen technischen Identifikator dar und dient dabei als eindeutigerReferenz technischerfür Schlüsselsämtliche zwischen Gridware und ERPNext.Synchronisationsprozesse.
2. KontaktinformationenContact
Hier werden sämtlichedie Kommunikationsdatengrundlegenden Kommunikationsinformationen gespeichert. Gezogen werden diese aus den contact informations von Gridware.
Beispiele:
Telefonnummer
E-Mail-Adresse
Diese InformationenDaten dienen später als Grundlage für Contactsdie innerhalbautomatische ERPNext.Erstellung bzw. Aktualisierung von ERPNext Contacts.
3.Role RollenklassifizierungClassification and Links
EinDieser VertragspartnerBereich kanndefiniert unterschiedlichedie Rollenfachliche Rolle der Entität innerhalb des Systems übernehmen.Systems.
Beispiele:Eine Entität kann dabei folgende Rollen besitzen:
Customer
- Supplier
Zusätzlich werden hier die jeweiligen Gridware-spezifischespezifischen Nummern gespeichert.
Beispiele:
Gridware Customer Number
Gridware Supplier Number
- Externe
externe Kundennummern (abgelegt in Gridware)
DadurchDiese kannInformationen derselbewerden Vertragspartnerin sowohlspäteren KundeGeschäftsprozessen, alsinsbesondere auchim LieferantVertragsmanagement sein.und in der Abrechnung, verwendet.
4.
Tab Beziehungen
2 – Address & Contact
Der Reiter Address & Contact verwaltet sämtliche Adressinformationen einer Gridware Party Datensatz dient als zentrale Verknüpfung verschiedener ERPNext-Objekte.Party.
HierzuDabei gehörenwird unterbewusst anderem:
Supplier
Gridware Contract
Dadurch lassen sich sämtliche Beziehungen eines Vertragspartners zentral nachvollziehen.
5. Adressen und Kontakte
den innerhalb ERPNext erzeugten Stammdaten unterschieden.
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 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:
Diese Daten stellen den unveränderten Datenbestand aus Gridware dar und dienen als Grundlage für die weitere Verarbeitung innerhalb ERPNext.
Address & Contact
6. Zahlungsmethoden/ SEPA Lastschriftverfahren
Im drittenunteren Bereich können aus den synchronisierten Rohdaten automatisch ERPNext-Stammdaten erstellt werden.
Hier werden anschließend die eigentlichen ERPNext-Objekte verwaltet:
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 befindenPayment sichMethod enthält sämtliche Informationen rund umZahlungsmethoden, die Paymenteiner MethodsGridware ausParty Gridware.zugeordnet Auchsind.
Da eine eindeutigeEntitä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:
Zweck
Dieser Bereich bildet die Grundlage für sämtliche Zahlungsprozesse innerhalb der ERPNext-Lösung.
Die gespeicherten Informationen werden insbesondere verwendet für:
Durch die Verknüpfung zwischen der Gridware Payment ID und dem ERPNext Bank Account kann jederzeit nachvollzogen werden, welche Zahlungsmethode aus Gridware gespeichertwelchem (Payment ID), um zukünftig bereits bestehende Datensätze updaten zu können auf Basis dieser ID.
Huaptsächlich handelt es sich hierbei um die SEPA LastschriftmandateBankkonto und diewelchem dazugehörige Bankverbindung. Im weiteren Verlauf wird dann ein neues SEPA SEPA-Mandat erstellt,in dasERPNext dann die Bankkonto-Erstellung triggert.entspric
Beziehungen zu anderen Doctypes
Der Gridware Party Doctype besitzt Beziehungen zu zahlreichen weiteren Objekten.
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:
Gridware stellt neue oder geänderte Stammdaten bereit.
ERPNext ruft diese Daten über die REST-API ab.
Bestehende Datensätze werden aktualisiert oder neue Datensätze angelegt.
Beziehungen zwischen Customer, Supplier, Contacts und Contracts werden automatisch hergestellt.
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.