proALPHA ERP and the battery passport: integration pattern
How data from proALPHA ERP (proALPHA) reaches the battery passport through the BatteryPass API: interfaces, workflows and when we checked them.
An integration pattern, not a ready-made connector: your ERP or integration platform reads and writes through the BatteryPass API with an organisation key. The details below come from the vendor documentation and were checked on the date given.
- Vendor
- proALPHA
- Deployments
- On-premise (proALPHA ERP)
- Checked
- not checked
- Managed integration
- —
Not checked: a REST interface with an OpenAPI description is mentioned by third parties only. Until the vendor confirms it, a file export with the generic preset is the safe way.
Interfaces
| Interface | Protocol | Sign-in | Events | Objects | Checked |
|---|---|---|---|---|---|
| REST interfaceREST interface (not confirmed) | REST | Token | none | Product/material master, Batch/serial number | not checked |
Matching workflows
Units from production
Serial numbers from the production confirmation or goods receipt are staged as an import; members review, commit and approve before any passport appears.
Passport links back into the ERP
The middleware follows the change feed and writes the GS1 Digital Link and the passport status to the serial number record in the ERP, so labels and delivery papers carry it.
Import presets
- Generic CSV file: For any ERP and for files a middleware writes itself: GTIN, serial number, manufacturing date, facility (name or GLN), model version and battery status, with German and English column names.