Deutsche Post
Zweck
Diese Anbindung kauft Briefmarken, keine Paketetiketten. Sie ist für den Briefversand da — Rechnungen, Mahnungen, kleine Warensendungen — und verhält sich deshalb grundlegend anders als jede Paket-Anbindung.
Funktionsumfang
- Kauf einer Internetmarke aus dem Versandprozess heraus.
- Höchstgewicht 1.000 g je Sendung.
- Die Marken-Kennung wird als Nummer geführt. Sie identifiziert den Kauf, nicht den Weg der
Sendung — aber sie ist der einzige Griff, den diese Sendung je bekommt, und ohne sie ließe sich nicht nachvollziehen, welche Marke zu welchem Vorgang gehört.
Einrichtung
Die Zugangsdaten stehen als Integration unter Integrationen — Anbieter deutschepost. Die Namen der Zugangsschlüssel tragen den Anbieter vorne; so bleiben sie von den Einstellungen anderer Anbindungen getrennt.
| Einstellung | Pflicht | Bedeutung |
|---|---|---|
deutschepost_api_key | ja | Anwendungsschlüssel der Internetmarke. Wird verschlüsselt abgelegt und nie wieder angezeigt. |
deutschepost_portokasse_user | ja | Benutzer der Portokasse — das Guthabenkonto, von dem jede Marke abgebucht wird. Wird verschlüsselt abgelegt und nie wieder angezeigt. |
deutschepost_portokasse_password | ja | Passwort dazu. Wird verschlüsselt abgelegt und nie wieder angezeigt. |
default_product_id | ja | Produktnummer der Marke, wenn die Sendung keine nennt (Position der Preisliste der Post). |
sender | nein | Absenderanschrift als Feldgruppe; geht unverändert an die Internetmarke, Feldnamen wie in deren Schnittstelle. |
production | nein | true schaltet in den Echtbetrieb. Ohne Angabe läuft alles gegen die Testumgebung. |
Zugangsdaten, die noch unter dem alten Namen ohne Anbieter-Präfix im Klartext stehen, übernimmt das System verschlüsselt — beim nächsten Speichern oder Lesen der Integration und mit dem Update-Schritt „Zugangsdaten verschlüsselt ablegen" (bin/console app:secrets:migrate).
Im Echtbetrieb kostet jede erzeugte Marke echtes Geld aus der Portokasse, und die Schnittstelle nimmt sie nicht zurück.
Zusammenspiel
Die Anbindung hängt am Versand: dort entsteht die Sendung, dort wird das Etikett gekauft, dort läuft die Sendungsverfolgung. Die Zugangsdaten stehen als Integration unter Integrationen in der verschlüsselten Ablage — nie in einer Einstellung und nie im Klartext; dieselbe Stelle schaltet zwischen Testumgebung und Produktion um. Etiketten und Lieferscheine gehen über Druck & Arbeitsplätze an den richtigen Drucker. Wann welches Etikett entsteht und in wie vielen Exemplaren, entscheiden Automationen — der Versand bringt dafür keine eigene Regel-Mechanik mit.
Grenzen
- Keine Sendungsverfolgung. Ein Brief wird nicht verfolgt. Das hier zu bejahen hieße, den
nächtlichen Abgleich auf eine Auskunft warten zu lassen, die es nicht gibt.
- Kein Storno. Die Marke ist beim Kauf bezahlt; die Schnittstelle nimmt sie nicht zurück.
- Kein Retourenetikett — Rücksendungen im Briefbereich laufen über ein anderes Produkt.
- Keine feste Produktliste. Die Produkt-Kennungen sind Positionen einer Preisliste, die die Post
ohne uns ändert und die je Vertrag abweicht. Welches Produkt gilt, sagt die Versandregel oder die Einrichtung — eine Liste im Code wäre eine Zahl, die niemand nachpflegt.
- Zollpapiere für Briefsendungen ins Drittland entstehen auf Papier (CN22/CN23), nicht über
diese Schnittstelle.
- Der Echt-Lauf steht aus. Geprüft ist, dass wir richtig fragen und die Antwort richtig deuten —
die Prüfungen fahren die Schnittstelle mit vorbereiteten Antworten. Dass die Post die erzeugte Anfrage tatsächlich annimmt, ist damit nicht belegt; dafür fehlt ein Zugang zur echten Testumgebung.
- Preise und Vertragskonditionen kommen nicht von hier. Was eine Sendung kostet, steht im
Vertrag mit dem Dienstleister; diese Anbindung kauft das Etikett, sie rechnet es nicht.