# Batteriepass sicher an SAP, Business Central und Odoo anbinden > Welche Daten aus SAP, Business Central und Odoo in den Batteriepass gehören, wie die Anbindung über die API sicher bleibt und was ein Schlüssel nicht darf. [Integration](https://kabin.sh/blog/kategorie/integration) # Batteriepass sicher an SAP, Business Central und Odoo anbinden Welche Daten aus SAP, Business Central und Odoo in den Batteriepass gehören, wie die Anbindung über die API sicher bleibt und was ein Schlüssel nicht darf. Von [BatteryPass-Redaktion](https://kabin.sh/ueber-uns#batterypass-team)Veröffentlicht: 25. Oktober 2026Aktualisiert: 25. Oktober 2026Fakten geprüft: 25. Oktober 202615 Min. Lesezeit ## Kurz gesagt Das ERP liefert dem Batteriepass Produktstamm, Seriennummern, Fertigungsrückmeldungen und Lieferungen, aber keine geprüften Passwerte. Sicher ist die Anbindung, wenn ein technischer Benutzer mit minimalen Rechten im ERP arbeitet, ein API-Schlüssel nur bereitstellt und liest, Menschen übernehmen, freigeben und veröffentlichen und Änderungen über den Feed zurückkommen. ## Wichtige Fakten - Verantwortung für die Passdaten Der Wirtschaftsakteur, der die Batterie in Verkehr bringt; er kann andere schriftlich beauftragen, bleibt aber verantwortlich [Quelle](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_77) - Änderungsrechte Rechte zum Aufnehmen, Ändern und Aktualisieren von Informationen im Pass sind beschränkt [Quelle](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_78) - Integrität und Sicherheit Authentizität, Zuverlässigkeit und Integrität der Daten; hohes Maß an Sicherheit, Betrug wird vermieden [Quelle](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_78) - Kennung jeder Batterie Modellkennung und Chargen-, Serien- oder Produktnummer oder ein anderes Kennzeichen, in der Praxis meist aus dem ERP [Quelle](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_38) - Start der Passpflicht 18\. Februar 2027 [Quelle](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_77) Ihr ERP sollte Daten an den Batteriepass liefern, aber nie über seine Freigabe entscheiden. SAP, Microsoft Dynamics 365 Business Central und Odoo kennen den Produktstamm, die Seriennummern, die Fertigungsrückmeldungen und die Lieferungen; daraus entstehen die Einheiten im Pass. Die erklärten Passwerte mit Nachweis und Prüfung entstehen nicht im ERP. Sicher wird die Anbindung, wenn im ERP ein eigener technischer Benutzer mit minimalen Rechten arbeitet, ein API-Schlüssel nur bereitstellen und lesen kann und Menschen übernehmen, freigeben und veröffentlichen. Wie Sie mit Tabellen und Exporten beginnen, beschreibt der Beitrag [Von Excel- und ERP-Exporten zum geprüften Batteriepass](https://kabin.sh/blog/excel-erp-export-zum-batteriepass). Hier geht es um den nächsten Schritt: die automatische Anbindung und ihre Sicherheit. Die Grundlagen der Passpflicht fasst unser Leitfaden [Batteriepass](https://kabin.sh/batteriepass) zusammen. Alles Folgende sind Integrationsmuster über die BatteryPass-API, keine fertigen Konnektoren. ## Welche Passdaten liegen im ERP und welche nicht? Der Batteriepass enthält Informationen über das Batteriemodell und über jede einzelne Batterie (Art. 77 Abs. 2). Das ERP liefert vor allem Daten der zweiten Ebene: Jede Batterie trägt eine Modellkennung und eine Chargen-, Serien- oder Produktnummer (Art. 38 Abs. 6), und genau diese Daten bucht das ERP bei der Fertigung oder beim Wareneingang. | ERP-Objekt | Typische Daten | Rolle im Pass | | --------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------- | | Produkt- oder Materialstamm | Materialnummer, GTIN, Bezeichnung | Schlüssel zum Batteriemodell; eine Änderung ist Anlass, eine neue Modellversion zu prüfen | | Serien- und Losnummern | Seriennummer je Batterie | Die Einheit im Pass | | Fertigungsauftrag und Rückmeldung | Fertigstellungs- oder Buchungsdatum, Werk | Herstelldatum und Herstellungsort der Einheit | | Wareneingang bei Einführern | Seriennummern der eingeführten Batterien | Die Einheit im Pass | | Auslieferung | Lieferschein, Etikettendruck | Kein Passinhalt; trägt den Pass-Link aus BatteryPass | | Retoure, Service- oder Reparaturauftrag | Seriennummer, Art der Arbeit, Datum | Ereignis in der Historie der Einheit | Was das ERP für den Batteriepass liefert Was im ERP fehlt, sind die erklärten Werte: ausführliche Zusammensetzung, kritische Rohstoffe und gefährliche Stoffe, Leistungs- und Haltbarkeitswerte, Demontage- und Sicherheitsinformationen, die Konformitätserklärung. Selbst wenn Ihr Materialstamm Merkmale wie Kapazität oder Zellchemie führt, sind das Angaben, für die jemand mit Nachweis einstehen muss (Art. 77 Abs. 4). Sie gehören in den Prüfablauf, nicht in eine automatische Synchronisation. Welche Felder es gibt und auf welcher Ebene sie liegen, zeigt die Seite [Datenfelder](https://kabin.sh/batteriepass/datenfelder). Zwei Angaben wandern in die Gegenrichtung: der GS1 Digital Link und der Passstatus. Sie gehören an den Seriennummernsatz im ERP, damit Etiketten und Lieferpapiere den richtigen Link tragen. ## Wie sieht das Integrationsmuster über die BatteryPass-API aus? Zwischen ERP und BatteryPass steht eine Middleware: ein kleiner Dienst Ihrer IT, Ihre Integrationsplattform oder bei SAP S/4HANA Cloud meist die SAP Integration Suite. Sie holt die Daten aus dem ERP und spricht die BatteryPass-API mit einem Organisationsschlüssel an. BatteryPass selbst verbindet sich heute nie mit Ihrem ERP; jede Verbindung geht von der Middleware aus. 1. **Das ERP bucht.** Fertigungsrückmeldung oder Wareneingang legen Seriennummern an. Eine Ausgangstabelle (Outbox) hält die Buchung fest, damit nichts verloren geht, wenn die Middleware gerade nicht läuft. 2. **Die Middleware stellt bereit.** Sie schreibt eine CSV-Datei im Format einer Importvorlage und lädt sie mit einem Schlüssel hoch, der nur den Scope `import` hat. BatteryPass prüft jede Zeile. 3. **Menschen entscheiden.** Ein Mitglied liest den Prüfbericht und übernimmt den Import, eine Prüferin gibt die Werte frei, erst dann wird veröffentlicht. 4. **Die Middleware schreibt zurück.** Ein zweiter Schlüssel mit dem Scope `read` folgt dem Änderungsfeed und trägt Link und Status am Seriennummernsatz ein. Für SAP-Serialnummernlisten, Business-Central-Artikelposten und Odoo-Lose gibt es Importvorlagen, die die Spalten dieser Systeme zuordnen im Test. Die Schnittstellen beschreibt die Seite [Entwickler](https://kabin.sh/entwickler). ## Was darf ein API-Schlüssel und was nicht? Ein Schlüssel gehört der Organisation, nicht einer Person. Er hat einen bis drei Scopes und kann nie mehr, als diese erlauben im Test. | Scope | Erlaubt | Nicht erlaubt | | ----------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------- | | `read` | Modelle, Versionen, Einheiten, Werte mit Herkunft, Pässe und Exporte lesen; den Änderungsfeed abfragen | Irgendetwas ändern | | `condition` | Zustandsdaten mit Messzeitpunkt melden; Lebenszyklus-Ereignisse wie Reparaturen anlegen | Erklärte Werte schreiben | | `import` | Eigene Importe hochladen, Zuordnung anpassen, Prüfung starten, Ergebnis abrufen | Importe übernehmen, Werte freigeben | Scopes der BatteryPass-API-Schlüssel Kein Scope erlaubt es, Pässe zu veröffentlichen oder zurückzuziehen oder Mitglieder, Schlüssel und Einstellungen zu verwalten. Das ist Absicht. Der Wirtschaftsakteur, der die Batterie in Verkehr bringt, stellt sicher, dass die Angaben im Pass korrekt, vollständig und aktuell sind (Art. 77 Abs. 4), und Art. 78 Buchstabe f verlangt, dass die Rechte zum Aufnehmen, Ändern und Aktualisieren von Informationen beschränkt sind. Ein ERP-Benutzer, der nachts einen Datensatz ändert, soll keinen veröffentlichten Pass verändern. Deshalb gelangen erklärte Daten nur durch die Entscheidung eines Mitglieds in den Pass, bei eingeschaltetem [Vier-Augen-Prinzip](https://kabin.sh/batteriepass/glossar#vier-augen-prinzip) durch zwei. Warum das zählt, erklärt der Beitrag [Herkunft und Vier-Augen-Prüfung](https://kabin.sh/blog/herkunft-und-vier-augen-pruefung-batteriepass). Weitere Grenzen fangen Fehler in der Middleware ab: - Ein Schlüssel sieht nur die Importe, die er selbst bereitgestellt hat. - Übernommen wird genau der Stand, den das Mitglied geprüft hat. Ändert der Schlüssel danach die Zuordnung, scheitert die Übernahme. - Die Schlüssel einer Organisation haben in der Grundeinstellung zusammen höchstens 20 offene Importe der letzten sieben Tage, 200 MB Upload je Tag und eine laufende Prüfung. - Alle Schlüssel zusammen dürfen 600 Anfragen pro Minute stellen; darüber antwortet die API mit `429` und `Retry-After`. Eine Grenze fehlt noch: Ein Schlüssel lässt sich nicht auf einzelne Modelle oder Einheiten beschränken. Wer einem Servicedienstleister einen Schlüssel mit `condition` gibt, erlaubt ihm, für alle Einheiten der Organisation Zustandsdaten zu melden. ## Wie unterscheiden sich SAP, Business Central und Odoo an der Schnittstelle? Die Systeme unterscheiden sich weniger darin, welche Daten sie haben, als darin, wie man sie abholt und wie man sich anmeldet. Die Tabelle fasst unser ERP-Register zusammen. Grundlage ist die Dokumentation der Anbieter, die wir am 24. und 25. Oktober 2026 nachgelesen haben; wo nur Community-Quellen vorliegen, steht es dabei. | System | Schnittstellen und Protokoll | Anmeldung | Ereignisse aus dem ERP | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | SAP S/4HANA Cloud Public Edition | OData-APIs (V4 und V2) für Produkt, Serialnummern, Fertigungsaufträge, Rückmeldungen, Auslieferungen, Warenbewegungen, Retouren | OAuth 2.0 Client Credentials, X.509-Zertifikat oder Benutzer und Passwort | Business Event „Produkt geändert“ über SAP Event Mesh, schlank, nicht signiert; nur aus Community-Quellen belegt | | SAP S/4HANA on-premise und Private Edition | OP\_-APIs (OData V2 und V4); IDoc MATMAS für den Materialstamm | X.509-Zertifikat oder Benutzer und Passwort | MATMAS über ALE-Änderungszeiger (Community-Quelle); RAP Business Events nicht geprüft; nicht signiert | | SAP Business One | Service Layer mit OData V3 (`/b1s/v1`) und V4 (`/b1s/v2`) | Sitzung: `POST /Login`, danach Sitzungs-Cookie | Keine Webhooks dokumentiert; die Middleware fragt ab | | Microsoft Dynamics 365 Business Central | API v2.0 (OData V4); eigene AL-API-Seite für Seriennummern | OAuth 2.0 Client Credentials über Microsoft Entra ID | Webhook-Abonnements mit Validierungs-Handshake und `clientState`, nicht signiert, Ablauf nach drei Tagen | | Odoo 19 | JSON-2-API für alle Modelle; XML-RPC und JSON-RPC abgekündigt | API-Schlüssel als Bearer-Token | Ausgehende Webhooks aus Automatisierungsregeln, nicht signiert | Schnittstellen, Anmeldung und Ereignisse nach unserem ERP-Register Integrationsmuster [SAP S/4HANA Cloud Public Edition](https://kabin.sh/integrationen/sap-s4hana-cloud) - Hersteller SAP - Betriebsarten Cloud - Schnittstellen CE_PRODUCT_0002, CE_API_MATERIALSERIALNUMBER_0001, CE_PRODUCTIONORDER_0001, API_PROD_ORDER_CONFIRMATION_2_SRV, API_OUTBOUND_DELIVERY_SRV_0002, API_MATERIAL_DOCUMENT_SRV, API_CUSTOMER_RETURN_SRV, sap.s4.beh.product.v1.Product.Changed.v1 - Geprüft Herstellerdokumentation, 24. Oktober 2026 Integrationsmuster [SAP S/4HANA (on-premise and Private Edition)](https://kabin.sh/integrationen/sap-s4hana-on-premise) - Hersteller SAP - Betriebsarten On-Premise - Schnittstellen OP_API_PRODUCT_SRV_0001, OP_API_MATERIALSERIALNUMBER_0001, OP_API_BATCH_SRV_0001, OP_API_PRODUCTION_ORDER_2_SRV_0001, OP_CUSTOMERRETURN_0001, MATMAS, RAP business events - Geprüft Herstellerdokumentation, 24. Oktober 2026 Integrationsmuster [SAP Business One](https://kabin.sh/integrationen/sap-business-one) - Hersteller SAP - Betriebsarten On-Premise - Schnittstellen Service Layer /b1s/v1, Service Layer /b1s/v2 - Geprüft Herstellerdokumentation, 24. Oktober 2026 Integrationsmuster [Microsoft Dynamics 365 Business Central](https://kabin.sh/integrationen/dynamics-365-business-central) - Hersteller Microsoft - Betriebsarten Cloud, On-Premise - Schnittstellen API v2.0, Webhook subscriptions (/api/v2.0/subscriptions), Custom AL API page - Geprüft Herstellerdokumentation, 25. Oktober 2026 Integrationsmuster [Odoo](https://kabin.sh/integrationen/odoo) - Hersteller Odoo S.A. - Betriebsarten Cloud, On-Premise - Schnittstellen JSON-2 API (/json/2/\/\), Webhooks (automation rules), XML-RPC and JSON-RPC (deprecated) - Geprüft Herstellerdokumentation, 24. Oktober 2026 Drei Details, die in Projekten Zeit kosten: - **Business Central:** Die Standard-API liefert Artikelposten ohne Serien- und Losnummern. Dafür braucht es eine eigene API-Seite als AL-Erweiterung. Anlegen, Ändern und Löschen lassen sich auf einer solchen Seite abschalten, dann bleibt sie schreibgeschützt. - **SAP S/4HANA Cloud:** Unser Register vermerkt nach SAP-Hinweis 3772443: Bei Serialisierungsstufe 1 antwortet das Anlegen einer Serialnummer per API mit Erfolg, legt aber nichts an. Lesen ist nicht betroffen. Lassen Sie Seriennummern in der Fertigung entstehen und lesen Sie sie nur. - **Odoo:** Das Los (`stock.lot`) führt kein Herstelldatum. Die Middleware ergänzt es, etwa aus dem Enddatum des Fertigungsauftrags. Jeder Aufruf der JSON-2-API läuft in einer eigenen Transaktion. Alle 17 Systeme, für die wir Muster beschreiben, finden Sie unter [Integrationen](https://kabin.sh/integrationen), etwa [SAP S/4HANA Cloud](https://kabin.sh/integrationen/sap-s4hana-cloud), [Business Central](https://kabin.sh/integrationen/dynamics-365-business-central) und [Odoo](https://kabin.sh/integrationen/odoo). ## Wie richten Sie den technischen Benutzer im ERP ein? Eine Integration, ein technischer Benutzer, genau die Rechte, die der Ablauf braucht. Der Ablauf „Einheiten aus der Fertigung“ liest im ERP nur; der Rückweg schreibt nur Link und Status an den Seriennummernsatz. - **SAP S/4HANA Cloud Public Edition:** ein eigenes Kommunikationsarrangement je Integration mit genau den APIs, die sie braucht. Anmeldung bevorzugt per OAuth 2.0 Client Credentials oder X.509-Zertifikat statt Benutzer und Passwort. - **SAP S/4HANA on-premise und Private Edition:** X.509 statt Basic-Anmeldung. Das System bleibt im eigenen Netz; die Middleware erreicht es über den SAP Cloud Connector oder einen Reverse Proxy, nie direkt aus dem Internet. - **SAP Business One:** Der Service Layer kennt nur die Sitzung mit Benutzer und Passwort. Umso wichtiger ist ein eigener Benutzer mit eingeschränkten Berechtigungen, der sich nach getaner Arbeit wieder abmeldet. - **Business Central:** Anmeldung als Anwendung über Microsoft Entra ID (Service-to-Service). Microsoft lässt für solche Anwendungen den Berechtigungssatz SUPER nicht zu und rät, nur die Rechte zu vergeben, die die Integration braucht. - **Odoo 19:** ein eigener Bot-Benutzer, wie Odoo es für Integrationen empfiehlt. Jeder Aufruf wird gegen dessen Zugriffsrechte und Datensatzregeln geprüft. ## Wohin gehören Schlüssel und Passwörter? In einen Tresor für Geheimnisse, nicht ins ERP-Customizing. Ein BatteryPass-Schlüssel in einer Z-Tabelle, im AL-Code, in einem Odoo-Systemparameter oder in einer Serveraktion ist für jeden lesbar, der Customizing oder Code sieht, und wandert mit Transporten, Sicherungen und Systemkopien in Testsysteme. - **Geheimnisse liegen bei der Middleware:** im Secret Store der Integrationsplattform oder Ihrer Infrastruktur, getrennt nach Test und Produktion. - **Ein Schlüssel je Integration und Umgebung.** Eine Organisation kann bis zu 25 aktive Schlüssel haben. Jeder wird nur einmal angezeigt; BatteryPass speichert nur seinen Hash. - **Rotation planen.** BatteryPass-Schlüssel laufen nicht ab: Sie legen einen neuen an, stellen um und widerrufen den alten. Odoo-API-Schlüssel und Client-Secrets in Microsoft Entra ID haben dagegen eine Laufzeit. Steht ihr Ablaufdatum nicht im Betriebsplan, steht die Integration eines Morgens still. - **Geheime Adressen sind Geheimnisse.** Eine Webhook-Adresse, die selbst den Schutz bildet, gehört weder in Tickets noch in Protokolle. ## Wie gehen Sie mit Ereignissen und Webhooks aus dem ERP um? Als Anstoß, nicht als Datenquelle. Nach unserem ERP-Register signiert keines der fünf Systeme seine Ereignisse. Eine Middleware leitet aus einem Ereignis deshalb nur ab, dass sie nachsehen muss, und liest die Daten danach mit ihrer eigenen Anmeldung über die API. Ein gefälschter Aufruf löst dann höchstens eine überflüssige Abfrage aus. - **SAP S/4HANA:** In der Cloud kommen Business Events wie „Produkt geändert“ über SAP Event Mesh als CloudEvents mit schlanker Nutzlast. On-premise kann der Materialstamm als IDoc MATMAS über ALE-Änderungszeiger kommen. - **SAP Business One:** Ohne dokumentierte Webhooks fragt die Middleware in festen Abständen ab. - **Business Central:** Beim Anlegen und Verlängern eines Abonnements prüft Business Central die Empfängeradresse mit einem Validierungs-Handshake. Benachrichtigungen nennen nur Ressource und Art der Änderung und tragen den `clientState`, den Microsoft als gemeinsames Geheimnis zum Prüfen beschreibt. Abonnements laufen nach drei Tagen ab und müssen rechtzeitig verlängert werden. - **Odoo:** Ausgehende Webhooks aus Automatisierungsregeln senden eine unsignierte Nutzlast. Behandeln Sie die Empfängeradresse der Middleware deshalb wie ein Geheimnis. Eine Signatur prüfen Sie dort, wo ein Anbieter sie vorsieht. Bei diesen fünf Systemen bleiben Handshake, `clientState`, geheime Adresse und vor allem das Nachlesen über die API. BatteryPass selbst sendet noch keine Webhooks; den Weg zurück ins ERP übernimmt der Änderungsfeed. ## Warum den Änderungsfeed nutzen, statt alles abzufragen? Weil die Middleware sonst regelmäßig jede Einheit lesen müsste, um die eine zu finden, deren Pass sich geändert hat. Der Feed meldet in der Reihenfolge, in der Änderungen sichtbar werden, was an welchem Objekt geschehen ist: Einheit angelegt, Pass veröffentlicht, neu veröffentlicht oder zurückgezogen, Modellversion freigegeben, Import übernommen oder freigegeben, Ereignis erfasst, Zustandsdaten angenommen im Test. - **Dünne Einträge.** Keine Werte, keine Personen, keine personenbezogenen Daten. Die Middleware liest danach das Objekt mit demselben Schlüssel; ein mitgelesener Feed verrät nichts. - **Lückenlos.** Ein Eintrag erscheint erst, wenn alle älteren Transaktionen abgeschlossen sind. Ein Cursor überspringt deshalb keine Änderung, die spät festgeschrieben wird. - **Gefiltert.** Der Parameter `types` beschränkt den Feed etwa auf Passänderungen. - **Mindestens einmal.** Die Middleware speichert den Cursor erst, wenn das ERP die Änderung angenommen hat. Nach einer Wiederherstellung der Datenbank kann ein Cursor ungültig sein (`cursor_reset`); dann beginnt sie von vorn. Eine Abfrage etwa alle fünf Minuten genügt für Etiketten und Lieferpapiere meist und schont das Anfragelimit. ## Wie verträgt die Anbindung Wiederholungen, ohne Daten zu verdoppeln? Netzwerke fallen aus, Dienste starten neu, Buchungen kommen doppelt. Jeder Schritt muss deshalb eine Wiederholung vertragen. | Schritt | Verhalten bei Wiederholung | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Import hochladen | Ein zweiter Upload legt einen zweiten Import an; seine Zeilen gelten als Duplikate, sobald der erste übernommen ist. Keine Einheit entsteht doppelt. | | Zustandsdaten melden | Messungen, die nicht neuer sind als die gespeicherte, überspringt BatteryPass. | | Reparatur als Ereignis melden | Die Middleware merkt sich die Auftragsnummer, für die sie ein Ereignis angelegt hat, und meldet es kein zweites Mal. | | Link und Status ins ERP schreiben | Gleicher Link und gleicher Status ergeben denselben Satz. | | Antwort `429` | Warten, so lange `Retry-After` angibt; sonst Wiederholung mit wachsendem Abstand und Zufallsanteil. | Was bei einer Wiederholung passiert ## Was sollten Sie protokollieren? Genug, um jede Rückfrage zu beantworten, und nichts, was ein Geheimnis verrät. BatteryPass protokolliert jede Änderung, die ein Schlüssel auslöst, mit dem Schlüssel als Handelndem: den bereitgestellten Import, die gestartete Prüfung, das gemeldete Ereignis, die angenommenen Zustandsdaten. Lesezugriffe protokolliert BatteryPass nicht, weder für Schlüssel noch für angemeldete Mitglieder. Abrufe geschützter Zugriffsebenen über eine Freigabe je E-Mail-Adresse werden dagegen protokolliert. In das Protokoll der Middleware gehören je Lauf die Import-ID, die Zahl der Zeilen, Warnungen und Fehler, der gespeicherte Cursor des Feeds und bei Fehlern der `code` und die `request_id` der Fehlerantwort. Nicht hinein gehören Schlüssel, Passwörter, Tokens, Webhook-Adressen, Passinhalte und Kundendaten. Alarmieren sollte die Middleware bei `401` und `403` (Schlüssel widerrufen oder Scope fehlt), bei fehlgeschlagenen Prüfungen, bei einem `cursor_reset` und bei Abonnements oder Schlüsseln, die bald ablaufen. ## Welche Abläufe passen zu welchem System? Unser Register beschreibt fünf Abläufe, die von keinem bestimmten ERP abhängen: - Einheiten aus der Fertigung Seriennummern aus Fertigungsrückmeldung oder Wareneingang werden als Import bereitgestellt; Mitglieder prüfen, übernehmen und geben frei, bevor ein Pass erscheint. - Pass-Links zurück ins ERP Die Middleware folgt dem Änderungsfeed und schreibt den GS1 Digital Link und den Passstatus an den Seriennummernsatz im ERP, damit Etiketten und Lieferpapiere ihn tragen. - Zustandsdaten aus BMS und Service Ein Batteriemanagementsystem oder ein Servicewerkzeug meldet Messwerte wie Kapazitätsverlust oder Zyklen; BatteryPass übernimmt neuere Messungen und veröffentlicht nach der Richtlinie der Organisation. - Rücksendungen und Reparaturen als Lebenszyklus-Ereignisse Abgeschlossene Reparaturen, Prüfungen und Komponententausche aus Service- oder Retourenaufträgen erscheinen als Ereignisse in der Historie der Einheit. - Produktänderung führt zu neuer Modellversion Eine Änderung am Produktstamm im ERP löst eine Benachrichtigung aus; ein Mitglied legt in BatteryPass eine neue Modellversion an. Deklarierte Daten werden nie automatisch geschrieben. | Ablauf | Scopes | Auslöser | Systeme | | -------------------------------------------- | ------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------ | | Einheiten aus der Fertigung | `import` | Fertigungsrückmeldung oder Wareneingang im ERP | Alle fünf | | Pass-Links zurück ins ERP | `read` | Pass in BatteryPass veröffentlicht, neu veröffentlicht oder zurückgezogen | Alle fünf | | Zustandsdaten aus BMS und Service | `read`, `condition` | Neue Messwerte im BMS oder Servicewerkzeug | SAP S/4HANA Cloud und on-premise; sonst direkt vom BMS | | Rücksendungen und Reparaturen | `read`, `condition` | Abschluss eines Service-, Reparatur- oder Retourenauftrags | Alle fünf | | Produktänderung führt zu neuer Modellversion | `read` | Änderung am Produkt- oder Materialstamm | Alle fünf | Abläufe, Scopes und Systeme nach unserem ERP-Register Zustandsdaten stammen meist nicht aus dem ERP, sondern aus dem Batteriemanagementsystem, das bei stationären Speichern schon heute die Daten nach Anhang VII enthalten muss (Art. 14 Abs. 1). Sie gelten in BatteryPass als Messungen, nicht als Erklärungen. Eine Produktänderung dagegen schreibt nie automatisch in den Pass: Die Middleware benachrichtigt die verantwortliche Person, und diese legt die neue Modellversion an und lässt sie freigeben. ## Was ist fertig, und was ist geplant? - API-Schlüssel mit drei Scopes, Import per Schlüssel und Änderungsfeed sind im Test. - Die Integrationsmuster für 17 ERP-Systeme sind im Test. Es sind Muster über die API, keine fertigen Konnektoren. Die Anbindung baut Ihre IT, Ihr IT-Dienstleister oder Ihre Integrationsplattform. - Verwaltete ERP-Verbindungen, beginnend mit Odoo, sind geplant. Einen Termin nennen wir nicht. BatteryPass hat für keines dieser Systeme eine Zertifizierung oder eine Vereinbarung mit dem ERP-Anbieter. Das Prüfdatum im Register ist der Tag, an dem wir die Dokumentation nachgelesen haben, keine Prüfung durch den ERP-Anbieter. Die Verantwortung für die Passdaten bleibt beim Wirtschaftsakteur. Die Kommission stellt klar, dass die Batterieverordnung Lösungsanbieter nicht regelt und die Wahl eines Anbieters allein beim Wirtschaftsakteur liegt (FAQ 10.3). Worauf Sie bei der Auswahl achten sollten, steht unter [Batteriepass-Software auswählen](https://kabin.sh/batteriepass-software-auswahl); ob sich ein Eigenbau lohnt, unter [Selbst bauen oder kaufen](https://kabin.sh/batteriepass-selbst-bauen-oder-kaufen). ## Womit fangen Sie an? 1. **Den Ablauf ohne ERP einmal durchspielen:** Export, Import, Prüfbericht, Freigabe, Veröffentlichung. 2. **Das Gegenstück im ERP festlegen:** Welche Buchung erzeugt die Seriennummer, und wo sollen Link und Status stehen? 3. **Einen technischen Benutzer anlegen**, mit Lesezugriff auf Produkt, Seriennummern und Fertigung und Schreibzugriff nur auf die Felder für Link und Status. 4. **Zwei Schlüssel anlegen:** einen mit `import`, einen mit `read`, je Umgebung. 5. **Geheimnisse in den Tresor** der Middleware legen und die Rotation mit Ablaufdaten einplanen. 6. **Outbox und Cursor** einrichten, damit nichts verloren geht und nichts doppelt ankommt. 7. **Protokoll und Alarme** für `401`, `403`, fehlgeschlagene Prüfungen und `cursor_reset` aufsetzen. 8. **Mit einem Modell live gehen** und erst danach weitere Modelle und Werke anschließen. Bis zum Stichtag 18. Februar 2027 sollte dieser Ablauf mit echten Seriennummern gelaufen sein. Ihre Daten, ein geprüfter Batteriepass Wir zeigen Ihnen in 30 Minuten, wie Ihre vorhandenen Tabellen, Lieferantendaten und Seriennummern zu einem gepflegten Batteriepass werden. [Demo anfragen](https://kabin.sh/kontakt)[Beispiel-Batteriepass ansehen](https://kabin.sh/beispiel-batteriepass) ## Häufige Fragen ### Kann unser ERP über die API Pässe veröffentlichen? Nein. Ein API-Schlüssel kann lesen, Zustandsdaten und Ereignisse melden und Importe bereitstellen. Einen Import übernehmen, Werte freigeben, veröffentlichen und zurückziehen können nur Mitglieder Ihrer Organisation. So gelangen erklärte Daten nur durch die Entscheidung einer Person in den Pass. ### Brauchen wir für jede Integration einen eigenen Schlüssel? Wir empfehlen es: einen Schlüssel je Integration und Umgebung, jeweils nur mit den nötigen Scopes. Eine Organisation kann bis zu 25 aktive Schlüssel haben. Wird einer widerrufen, stehen die anderen Integrationen nicht still. ### Signieren Business Central oder Odoo ihre Webhooks? Nach unserem ERP-Register nicht. Business Central prüft die Empfängeradresse mit einem Handshake und schickt den clientState mit, Odoo signiert die Nutzlast seiner Webhooks nicht. Behandeln Sie ein Ereignis deshalb als Anstoß und lesen Sie die Daten danach über die API. ### Gibt es einen fertigen Odoo-Konnektor? Noch nicht. Verwaltete ERP-Verbindungen, beginnend mit Odoo, sind geplant. Bis dahin beschreiben wir ein Integrationsmuster über die JSON-2-API von Odoo und die BatteryPass-API, das Ihre IT oder Ihr IT-Dienstleister umsetzt. ### Was passiert, wenn die Middleware dieselbe Datei zweimal hochlädt? Es entsteht ein zweiter Import. Seine Zeilen gelten als Duplikate, sobald der erste übernommen ist, sodass keine Einheit doppelt angelegt wird. ### Laufen BatteryPass-API-Schlüssel ab? Nein. Sie rotieren einen Schlüssel, indem Sie einen neuen anlegen, die Middleware umstellen und den alten widerrufen. Odoo-API-Schlüssel und Client-Secrets in Microsoft Entra ID haben dagegen eine Laufzeit, die in den Betriebsplan gehört. ### Muss unser ERP aus dem Internet erreichbar sein? Nein. BatteryPass verbindet sich heute nie mit Ihrem ERP; alle Aufrufe gehen von der Middleware aus. Die Middleware erreicht ein SAP-System im eigenen Netz etwa über den SAP Cloud Connector oder einen Reverse Proxy. ## Quellen 1. [Verordnung (EU) 2023/1542, Artikel 77: Batteriepass](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_77) · Amt für Veröffentlichungen der Europäischen Union (EUR-Lex) · abgerufen am 25. Oktober 2026 2. [Verordnung (EU) 2023/1542, Artikel 78: Technische Gestaltung und Einsatz des Batteriepasses](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_78) · Amt für Veröffentlichungen der Europäischen Union (EUR-Lex) · abgerufen am 25. Oktober 2026 3. [Verordnung (EU) 2023/1542, Artikel 38: Pflichten der Erzeuger (Kennzeichnung zur Identifikation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_38) · Amt für Veröffentlichungen der Europäischen Union (EUR-Lex) · abgerufen am 25. Oktober 2026 4. [Verordnung (EU) 2023/1542, Artikel 14: Alterungszustand und voraussichtliche Lebensdauer](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#art_14) · Amt für Veröffentlichungen der Europäischen Union (EUR-Lex) · abgerufen am 25. Oktober 2026 5. [Verordnung (EU) 2023/1542, Anhang XIII: In den Batteriepass aufzunehmende Informationen](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/deu#anx_XIII) · Amt für Veröffentlichungen der Europäischen Union (EUR-Lex) · abgerufen am 25. Oktober 2026 6. [EU Digital Product Passport FAQ for Batteries (Fragen 2.1 und 10.3)](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/eu-digital-product-passport-faq-batteries_en) · Europäische Kommission, GD GROW · abgerufen am 25. Oktober 2026 7. [Working with webhooks (Business Central API v2.0)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/dynamics-subscriptions) · Microsoft Learn · abgerufen am 25. Oktober 2026 8. [Using Service to Service Authentication (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/automation-apis-using-s2s-authentication) · Microsoft Learn · abgerufen am 25. Oktober 2026 9. [itemLedgerEntry resource type (Business Central API v2.0)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/resources/dynamics_itemledgerentry) · Microsoft Learn · abgerufen am 25. Oktober 2026 10. [Developing a custom API (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-develop-custom-api) · Microsoft Learn · abgerufen am 25. Oktober 2026 11. [External JSON-2 API (Odoo 19.0)](https://www.odoo.com/documentation/19.0/developer/reference/external_api.html) · Odoo S.A. · abgerufen am 25. Oktober 2026 12. [Webhooks (Odoo 19.0, Studio)](https://www.odoo.com/documentation/19.0/applications/studio/automated_actions/webhooks.html) · Odoo S.A. · abgerufen am 25. Oktober 2026 13. [Logging in and logging out using Service Layer API (SAP Business One)](https://learning.sap.com/courses/leveraging-the-sap-business-one-service-layer/logging-in-and-logging-out-using-service-layer-api) · SAP Learning · abgerufen am 25. Oktober 2026 Dieser Artikel gibt den Stand der Rechtslage wieder, wie wir ihn am 25. Oktober 2026 an den verlinkten Primärquellen geprüft haben. Er ist keine Rechtsberatung; maßgeblich ist der Text im Amtsblatt der EU. ## Über den Autor BatteryPass-Redaktion Produkt- und Regulierungsteam von BatteryPass Wir bauen BatteryPass und lesen dafür die Batterieverordnung, die Leitfäden der Kommission und die Dokumentation der ERP-Hersteller im Original. Entwürfe entstehen mit KI-Unterstützung; jeder Artikel wird von Menschen geprüft, und jede regulatorische Aussage ist mit ihrer Primärquelle verlinkt. Ihre Daten, ein geprüfter Batteriepass Wir zeigen Ihnen in 30 Minuten, wie Ihre vorhandenen Tabellen, Lieferantendaten und Seriennummern zu einem gepflegten Batteriepass werden. [Demo anfragen](https://kabin.sh/kontakt)[Beispiel-Batteriepass ansehen](https://kabin.sh/beispiel-batteriepass) ## Weitere Artikel - [LeitfadenVon Excel- und ERP-Exporten zum geprüften BatteriepassWie aus vorhandenen Tabellen, ERP-Exporten und Lieferantendaten ein geprüfter Batteriepass wird: Datenquellen, Import, Freigabe, Herkunft und ERP-Anbindung.25. Oktober 2026](https://kabin.sh/blog/excel-erp-export-zum-batteriepass) - [LeitfadenLieferantendaten für den Batteriepass ohne LieferantenkontenWelche Passdaten von Zell- und Modullieferanten kommen, was Art. 39 verlangt und wie Sie fehlende Angaben per Link anfragen, prüfen und schützen.25. Oktober 2026](https://kabin.sh/blog/lieferantendaten-batteriepass-ohne-lieferantenkonto) - [DatenHerkunft und Vier-Augen-Prüfung: Warum zählt, wer was eingetragen hatWas die Batterieverordnung zu korrekten, unverfälschten Passdaten verlangt und wie Herkunft je Wert, Vier-Augen-Freigabe und signierte Versionen das belegen.25. Oktober 2026](https://kabin.sh/blog/herkunft-und-vier-augen-pruefung-batteriepass)