Kapitel 5 – Becharged Settings: Die zentrale Schaltstelle

Ziel dieses Kapitels

Die Becharged Settings sind die zentrale Schaltstelle der ERPNext-Lösung. Hier hinterlegen wir die Verbindung zu Gridware, die Zuordnung der Vertragstypen zu Artikeln, Druckformate, E-Mail- und DATEV-Angaben sowie die Vorgaben für RFID-Kartenbestellungen.

Ohne gespeicherte Settings und eine gültige Authentifizierung laufen die Gridware-Aktionen nicht. Dieses Kapitel richtet sich an den operativen Betrieb: Welche Felder Sie pflegen, wann Sie welche Schaltfläche nutzen und woran Sie den Erfolg erkennen.

Nach diesem Kapitel soll der Leser verstehen,

• wie die Settings geöffnet und gespeichert werden,
• welche Abschnitte fachlich zusammengehören,
• wann Authentifizierung, Vertragsabruf und Aggregation ausgelöst werden,
• welche Aktionen nur zur Reparatur gedacht sind,
• welche Schaltflächen in der aktuellen Oberfläche nicht mehr angeboten werden.

5.1 Überblick und Zugriff

Zweck

Die Settings verbinden die technischen Gridware-Daten mit den kaufmännischen Prozessen in ERPNext. Sie steuern unter anderem:

• die API-Anmeldung bei Gridware,
• die Zuordnung von Vertragstyp und MwSt. zum Rechnungsartikel,
• den Standardkunden für Hubject-Roaming,
• Druckformate und Briefkopf,
• E-Mail-Vorlage, Ausweichkonto und DATEV-Adresse,
• den RFID-Kartenpreis und den Synchronisationsstand der Kartenbestellungen.

---

5.2 Aufbau der Seite

Die Seite gliedert sich in die folgenden Abschnitte (Reihenfolge wie im Formular):

1. Allgemeine Einstellungen (oberer Bereich ohne eigenen Abschnittstitel)
2. Gridware-Integration
3. Gridware-Importeinstellungen
4. Rechnungsdruck-Einstellungen
5. Konfiguration der Vertragsartzuordnung
6. RFID-Kartenbestellung

Zusätzlich stehen oben am Formular Buttons bereit. Sie sind in Gruppen unterteilt:

Im Abschnitt RFID-Kartenbestellung liegt zusätzlich die Formularschaltfläche Vollständige Neusynchronisation.

---

5.3 Allgemeine Einstellungen

Der obere Bereich sammelt Firmen-, E-Mail- und Standardwerte, die später in Rechnungen, Stammdatenanlage und Hubject-Abrechnung greifen.

Fachlicher Hintergrund

Automatisch erzeugte Belege brauchen einen Ansprechpartner, eine Gesellschaft und – bei Hubject – einen zahlenden Kunden, weil Gridware dort oft keinen Endkunden liefert. E-Mails an DATEV dürfen den Kunden-E-Mail-Status nicht verfälschen.

Default User

Auf manuell erstellten Belegen kommt der Ansprechpartner vom angemeldeten Benutzer. Bei automatisch erzeugten Ausgangsrechnungen würde sonst der Administrator auf dem Druck erscheinen. Deshalb hinterlegen Sie hier eine fachliche Person (z. B. die Sachbearbeitung).

Default Hubject Roaming Customer

Beim Hubject-Roaming rechnet becharged nicht den Endkunden ab, sondern die zwischengeschaltete Instanz (Grid & Co.). Der Lieferant am Vertrag bleibt der CPO. Fehlt das Feld, bricht die Synchronisation mit der Meldung ab: Standard-Hubject-Roaming-Kunde ist in den Becharged-Einstellungen nicht festgelegt.

Wann pflegen?

• einmalig vor dem ersten produktiven Sync,
• nach Wechsel der Gesellschaft, des DATEV-Postfachs oder der zuständigen Sachbearbeitung,
• immer dann, wenn Hubject-Verträge neu hinzukommen und der Standardkunde noch leer ist.

Erfolg: Die Felder sind gespeichert. Hubject-Verträge synchronisieren ohne die obige Fehlermeldung. Automatische Rechnungen zeigen den hinterlegten Default User, nicht Administrator.

---

5.4 Gridware-Integration

Dieser Abschnitt enthält die Zugangsdaten zur Gridware-API und den aktuellen Anmeldestatus.

Fachlicher Hintergrund

Sämtliche Vertrags-, Parteien- und Nutzungsabrufe laufen über diese Verbindung. Die Anmeldung erzeugt ein Sitzungstoken. Ist die Sitzung abgelaufen, müssen Sie sich erneut authentifizieren, bevor Sie Verträge oder Nutzungen holen.

Schaltfläche Authentifizieren

Die Schaltfläche Authentifizieren prüft die gespeicherten Zugangsdaten gegen Gridware.

---

5.5 Gridware-Importeinstellungen

Dieser Abschnitt steuert den älteren CSV-Weg (Consumption Data / Subscriptions), nicht den API-Abruf von Verträgen.

Wann setzen?

Den Haken Verbrauchsdaten importiert erst nach einem vollständigen, geprüften CSV-Import setzen. Zusammen mit dem Stichtag steuert er, ob verbrauchsabhängige Abonnements Rechnungen erzeugen dürfen.

Warnung: CSV-Import und API-Aggregation nicht unkontrolliert mischen. Vor einer parallelen Nutzung den Status der betroffenen Sätze prüfen (Uninvoiced / Invoiced). Sonst drohen Doppelabrechnungen oder Lücken.

Erfolg: Am Stichtag (oder ab dem 7., falls leer) und bei gesetztem Haken können Consumption-Data-Rechnungen erzeugt werden. Ohne Haken bzw. vor dem Stichtag bleiben die verbrauchsabhängigen Abos stehen.

---

5.6 Rechnungsdruck-Einstellungen

Hier hinterlegen Sie, mit welchem Druckformat Ausgangs- und Eingangsbelege sowie die Nutzungsanhänge erzeugt werden.

Die konkreten Formatnamen (z. B. BCH Rechnung, Customer Usage Detail BCH Rechnung, BCH Einkaufsrechnung) liegen in ERPNext als Druckformate vor. In den Settings wählen Sie die jeweils gültige Zuordnung.

Erfolg: Beim PDF-Download einer Kunden- oder Lieferantenrechnung erscheinen Rechnungskopf und der vorgesehene Nutzungsanhang mit dem hinterlegten Briefkopf.

---

5.7 Konfiguration der Vertragsartzuordnung

Die Tabelle Vertragsartzuordnungen / Contract Type Mappings entscheidet, welcher Artikel auf der späteren Rechnung oder Lieferantenabrechnung erscheint.

Fachlicher Hintergrund

Jeder Gridware-Vertrag hat einen Contract Type und einen MwSt.-Satz. Die Abrechnungslogik sucht in dieser Tabelle die passende Zeile und setzt den Item Code. Die gültige Liste steht ausschließlich in den Settings, nicht in einer festen Dokumentationstabelle.

Tabelle Contract Type Item Mapping

Beispielzeilen (nur zur Orientierung – die produktive Liste pflegen Sie in den Settings):

Wann pflegen?

• vor der ersten Aggregation von Customer Usage Data / Supplier Usage Data,
• wenn Gridware einen neuen Vertragstyp liefert,
• wenn sich der Artikelstamm ändert.

Ohne passende Zeile kann die Aggregation keinen Artikel setzen. Prüfen Sie nach dem Speichern, dass jeder benötigte Vertragstyp und der zugehörige MwSt.-Satz eine Zeile hat.

Erfolg: In Customer Usage Detail bzw. Supplier Usage Detail steht je Zeile ein existierender Item Code.

5.8 RFID-Kartenbestellung

Dieser Abschnitt steuert Preis und Synchronisation der Ladekartenaufträge aus dem Kundenportal bzw. aus Gridware.

Im Formular steht der Hinweis: Die vollständige Neusynchronisation holt jede Gridware-RFID-Kartenbestellung neu, ignoriert das Wasserzeichen und setzt bei Erfolg Wasserzeichen und „Letzte vollständige Neusynchronisation“ auf jetzt. Für den Alltag ist die Schaltfläche Bestellungen synchronisieren in der Liste Gridware RFID Card Order vorgesehen.

Warnung: Full Resync nur zur Reparatur

Vollständige Neusynchronisation ist aufwendig. Sie ist nur gedacht für:

• die erstmalige Einrichtung dieser Funktion,
• ein stecken gebliebenes oder beschädigtes Wasserzeichen.

Im Monatsbetrieb nicht verwenden. Der Alltags-Sync erfolgt über Bestellungen synchronisieren in der Liste der RFID-Aufträge bzw. über den täglichen Hintergrundjob.

Erfolg im Alltag: Neue Portalbestellungen erscheinen als Gridware RFID Card Order, der Preis entspricht den Settings, ein Sales Order im Entwurf entsteht. Last Sync Attempt bewegt sich täglich.

5.9 Schaltflächen – Gridware Vertragsaktionen

Die folgenden Schaltflächen stehen in der Gruppe Gridware Vertragsaktionen.

5.9.1 Verträge abrufen

Was passiert: Es werden alle verfügbaren Gridware-Verträge geladen. Der Vorgang kann lange dauern und lässt sich nicht ohne Weiteres rückgängig machen.

Wann: Erstmaliger Vollabzug oder bewusster Nachzug aller Verträge – nicht als tägliche Routine. Einzelne Verträge holen Sie mit Vertrag nach ID abrufen.

Schritt für Schritt

1. Settings speichern und ggf. Authentifizieren.
2. Verträge abrufen.
3. Es öffnet sich der Dialog Alle Verträge abrufen mit Warnung.
4. Unter Authentifizierung erforderlich geben Sie Ihr Passwort ein – das ERPNext-/Frappe-Anmeldepasswort des System Managers, nicht das Gridware-Passwort.
5. Bestätigen und fortfahren.
6. Hinweis: Vertragssynchronisation wurde in die Warteschlange gestellt. Überprüfen Sie die Hintergrundjobs für den Fortschritt.

Erfolg: Hintergrundjob läuft durch. In Gridware Contract erscheinen bzw. aktualisieren sich die Verträge. Anschließend können Parteien und Nutzungen nachgezogen werden.

5.9.2 Vertrag nach ID abrufen

Was passiert: Ein einzelner Vertrag wird anhand der numerischen Gridware-Vertrags-ID geholt. Danach läuft der bekannte Synchronisationsprozess für diesen Vertrag (Parteien, Customer/Supplier, zugehörige Nutzungen).

Wann: Nachanlage eines einzelnen Vertrags in Gridware, Nacharbeit, Tests.

Schritt für Schritt

1. Kopieren Sie die Contract ID in Gridware.
2. In den Settings: Vertrag nach ID abrufen.
3. Dialog Vertrag von Gridware abrufen, Feld Vertrags-ID.
4. Vertrag abrufen.
5. Der Job wird im Hintergrund eingereiht.

Erfolg: Ein Gridware Contract (Namenskreis GWC-…) existiert, Felder wie Vertragsnummer und Vertragstyp sind gefüllt. Über Alle Vertragsparteien verknüpfen können fehlende Customer-/Supplier-Links nachgezogen werden.

5.9.3 Alle Vertragsparteien verknüpfen

Was passiert: Für alle Gridware Contracts, bei denen Supplier oder Customer noch fehlen, werden die Verknüpfungen zu Gridware Party, Customer und Supplier nachgezogen.

Wann: Nach einem Vertragsabruf, wenn an Verträgen noch Lücken in den Parteifeldern stehen. Derselbe Vorgang läuft zusätzlich täglich automatisch.

Schritt für Schritt

1. Alle Vertragsparteien verknüpfen.
2. Bestätigen Sie: Dies wird Lieferanten und Kunden für alle Gridware-Verträge abrufen und verknüpfen, die Aktualisierungen benötigen.
3. Die Erfolgsmeldung nennt die Anzahl verarbeiteter Verträge sowie verknüpfter Lieferanten und Kunden.

Erfolg: Am Vertrag sind Supplier und die Customer-Zeilen gesetzt. Gridware Parties mit Customer bzw. Supplier sind über die Connections erreichbar.

5.10 Schaltflächen – Nutzungsaggregation

5.10.1 Nutzungsdaten aggregieren

Gruppe Kunden-Nutzung. Dialog Kunden-Nutzungsdaten aggregieren.

Was passiert: Aus vollständigen Gridware Usages entstehen Customer Usage Data-Sätze je Kunde und Abrechnungszeitraum.

Wann: Nachdem Usages den Status Complete haben und bevor Kundenrechnungen erzeugt werden. Pending-Usages blockieren die Aggregation.

Schritt für Schritt

1. Nutzungsdaten aggregieren.
2. Optional Filter: Von Datum, Bis Datum, Kunde.
3. Aggregation starten.
4. Hinweis: Kunden-Nutzungsdaten-Aggregation wurde in die Warteschlange gestellt.

Erfolg: Es existieren Customer-Usage-Data-Sätze im Status Uninvoiced, Details sind gefüllt, Item Codes stammen aus der Vertragsartzuordnung.

5.10.2 Lieferanten-Nutzungsdaten aggregieren

Gruppe Lieferanten-Nutzung. Dialog analog, Filter Lieferant statt Kunde.

Was passiert: Aus denselben Usages entstehen Supplier Usage Data-Sätze je Lieferant und Zeitraum.

Wann: Vor der Lieferantenabrechnung / Gutschrift. Mapping und gesetzter Supplier am Vertrag müssen stimmen. Bei Hubject bleibt der CPO der Lieferant; der Kunde auf der Gegenseite ist der Standard-Hubject-Kunde.

Schritt für Schritt

1. Lieferanten-Nutzungsdaten aggregieren.
2. Optional Von Datum, Bis Datum, Lieferant.
3. Aggregation starten.

Erfolg: Supplier Usage Data ist vorhanden, Totals nachvollziehbar, keine Pending-Usages mehr im Filter.

---

5.11 Abruf fehlgeschlagener/ausstehender Transaktionen wiederholen

Gruppe Gridware Nutzungsaktionen.

Was passiert: Der vorhandene Hintergrundjob für Failed und Pending Gridware Usages wird sofort angestoßen (derselbe Job, der täglich ohnehin läuft).

Wann: Wenn Usages auf Pending oder Failed stehen und die Aggregation deshalb blockiert. Nicht als Ersatz für eine fehlende Authentifizierung.

Schritt für Schritt

1. Abruf fehlgeschlagener/ausstehender Transaktionen wiederholen.
2. Bestätigen Sie den Hinweis, dass Details zu allen fehlgeschlagenen und ausstehenden Transaktionen erneut geholt werden.
3. Meldung Geplanter Auftrag ausgelöst. Über Protokolle der geplanten Aufträge anzeigen den Verlauf prüfen.
4. Usages aktualisieren: Status wechselt nach Complete.

Erfolg: Keine Pending-Usages mehr im relevanten Zeitraum. Danach Aggregation erneut starten.

---

5.12 Tägliche Hintergrundjobs (ohne Klick)

Unabhängig von den Schaltflächen laufen täglich unter anderem:

Die Schaltflächen in den Settings sind der manuelle Weg, dieselben oder verwandte Vorgänge gezielt anzustoßen.

5.14 Steuerlogik und Druckformate

Am Artikel gibt es Tax Handling mit Standard Tax und Pass-through Item. Beim Einfügen in Angebot, Auftrag, Lieferschein, Rechnung oder Einkaufsbeleg setzt das System Steuerkategorie und Vorlage (#268, #269). Dienstwagen 0 %, sonst oft 19 %. Porto bleibt in der Regel 19 % (#210).

Diese Druckformat-Namen stehen so im System:

Tägliche Server-Images allein reichen nicht. Es gibt eine Nextcloud-Anbindung: Hinweis bei Fehler, Löschung nach 30 Tagen (#196, #197, #201, #279).