Administration
Zweck
Diese Seite beschreibt die operative Administration von Shipping Labels, nachdem die gemeinsame und die carrierspezifische Einrichtung vorhanden sind. Im Mittelpunkt stehen URLs, wiederverwendbare Einrichtungspakete, Anfrageanalyse, Aufbewahrungsregeln und Support-Informationen, mit denen Key User und Administratoren die Lösung stabil betreiben.
Zugriff in Business Central
- Öffnen Sie Shipping Label Setup für globale Einstellungen, Anfrageprotokolle, Löschregeln und den Zugriff auf verwandte Einrichtungsseiten.
- Öffnen Sie Shipping Label URL, wenn produktive oder Test-Endpunkte angelegt oder geändert werden müssen.
- Öffnen Sie Configuration Packages, wenn Einrichtungsdaten exportiert, importiert oder über Gesellschaften oder Umgebungen hinweg ausgerollt werden sollen.
- Öffnen Sie BE-terna Support Info und die BE-terna-Lizenzaktualisierung, wenn Support oder Lizenzpflege erforderlich sind.
Voraussetzungen
- Die gemeinsame Einrichtung und mindestens eine Carrier-Einrichtung sind bereits gepflegt.
- Der Benutzer darf Einrichtungsdaten, URLs und Konfigurationspakete ändern.
- Produktive und Test-Zugangsdaten oder URLs liegen vom jeweiligen Carrier vor.
- Kundennummer, Ident und weitere Support-Metadaten sind verfügbar, wenn Lizenz- oder Supportaktionen notwendig sind.
Tätigkeiten
Versandetiketten-URLs für Produktiv- und Testbetrieb pflegen
Versandetiketten-URLs definieren, welcher Carrier-Endpunkt von der jeweiligen Einrichtung aufgerufen wird. In der Praxis bedeutet das meist, getrennte Einträge für Test- und Produktivzugang zu pflegen und diese den relevanten Carrier-Einrichtungen zuzuordnen.
Jeder URL-Eintrag sollte als gesteuerte technische Stammdatenpflege behandelt werden:
- vergeben Sie einen klaren Code für den URL-Eintrag
- pflegen Sie exakt den vom Carrier gelieferten Endpunkt
- halten Sie Produktiv- und Test-Endpunkte getrennt
- entfernen Sie veraltete oder doppelte URLs, sobald der Rollout stabilisiert ist
Eine URL-Änderung ist technisch klein, hat aber große operative Wirkung. Testen Sie deshalb nach jeder relevanten Änderung sofort eine Labelanfrage.
Konfigurationspakete für wiederverwendbare Einrichtung nutzen
Die erste Shipping-Labels-Einrichtung sollte manuell erfolgen, damit die fachlichen Zusammenhänge verstanden und geprüft werden. Danach können Configuration Packages genutzt werden, um die gemeinsame Einrichtung und carrierspezifische Einrichtungspakete zu exportieren und zu importieren.
Die gemeinsamen Setup-Pakete decken in der Regel Bereiche wie Versandagenten, Versandagentendienste, zugeordnete Herkunftsarten, Versandagentendienst-Einrichtungen, Shipping Label Setup, Versandetiketten-URLs und zugeordnete interne Handelsklauseln ab. Carrierspezifische Pakete ergänzen anschließend diese gemeinsame Basis.
Das ist besonders hilfreich, wenn Sie:
- eine validierte Basiskonfiguration in eine andere Gesellschaft übernehmen möchten
- eine getestete Einrichtung aus einer unproduktiven Umgebung in eine produktive Umgebung überführen möchten
- Carrier-Einrichtungen vergleichen oder auf einen bekannten guten Stand zurücksetzen möchten
In der Praxis umfasst diese gemeinsame Basiskonfiguration typischerweise folgende Einrichtungsbereiche:
- Versandagenten
- Versandagentendienste
- zugeordnete Herkunftsarten
- Versandagentendienst-Einrichtungen
- Shipping Labels Setup
- Versandetiketten-URLs
- zugeordnete interne Handelsklauseln
Carrierspezifische Pakete ergänzen diese Basiskonfiguration anschließend um Eigenschaften, Zugangsdaten und Codes des jeweiligen Carriers. Sobald die erste Einrichtung validiert ist, exportieren Sie die gemeinsame Basis zusammen mit dem relevanten Carrier-Paket zur Wiederverwendung.
Beispiel für gemeinsame und carrierspezifische Konfigurationspakete in Shipping Labels:
Anfrageprotokolle prüfen und Anfragedetails nachverfolgen
Das Anfrageprotokoll ist der wichtigste operative Einstiegspunkt für die Diagnose. Es protokolliert erfolgreiche und fehlgeschlagene Anfragen und stellt die technischen Details bereit, die bei unerwartetem Verhalten benötigt werden.
Zu den wichtigsten Protokollinformationen gehören:
- Eintragsnummer und Zeitstempel der Anfrage
- Herkunftsart, Benutzer und Versandetikettentyp
- Fehlerkennzeichen, Fehlertext und HTTP-Status
- URL, HTTP-Methode, Request-Payload und Response-Payload
Für das tägliche Troubleshooting empfiehlt sich diese Reihenfolge bei der Auswertung der Protokollfelder:
| Feld | Warum es wichtig ist |
|---|---|
| Error Text | Zeigt lokale Versandprobleme wie Verbindungsfehler, bevor die Anfrage den Carrier erreicht hat |
| Response | Enthält meist die konkreteste carrierspezifische Validierungsnachricht |
| HTTP Status | Trennt Transportprobleme von fachlich abgelehnten Anfragen |
| URL | Bestätigt, ob der richtige Test- oder Produktivendpunkt verwendet wurde |
| Request | Zeigt, welche Daten tatsächlich aus Business Central gesendet wurden |
| Herkunftsart / Benutzer | Hilft zu erkennen, welcher Belegfluss und welcher Benutzer die Anfrage ausgelöst hat |
| Eintragsnummer / Zeitstempel | Erleichtert die genaue Referenz in der Support-Kommunikation |
Nutzen Sie diese Abfolge für die Diagnose:
- Wenn die Anfrage den Carrier nie erreicht hat, beginnen Sie mit URL, Zugangsdaten, Internetverbindung und lokalem Error Text.
- Wenn der Carrier die Anfrage abgelehnt hat, lesen Sie zuerst Response und HTTP Status und vergleichen Sie danach die Request-Payload mit den erwarteten Quelldaten.
- Wenn bereits ein Label existiert, wechseln Sie anschließend in Request Shipping Labels, um Datei, Tracking-ID und Rücksende-Tracking-ID zu prüfen.
Von der ausgewählten Anfrage aus können Sie außerdem die zugehörigen Detailseiten öffnen:
- Request Parameters für die Header-Informationen der Anfrage
- Request Shipping Labels für Datei, Tracking-ID, Rücksende-Tracking-ID und Dateiendung bei erfolgreicher Anfrage
Globale Standardwerte und Housekeeping-Einstellungen pflegen
Die globale Seite Shipping Label Setup ist auch der Ort für operative Standardwerte und Bereinigungsregeln, die alle Carrier-Szenarien beeinflussen.
Zu den wichtigsten Einstellungen gehören:
- Log Deletion Date Formula, um festzulegen, welche Anfrageprotokolle durch die Bereinigung entfernt werden, zum Beispiel
-6M - Test Mode in den globalen Einstellungen, wenn alle Carrier-Einrichtungen vorübergehend im Testmodus arbeiten sollen
- die Standardtelefonnummer für DHL-Shipping-Rückruf-Szenarien
- Standardland und Standard-Empfängerland als Rückfallwerte, wenn das Quelldokument die benötigten Länderinformationen nicht liefert
- Convert Special Characters, wenn Anfragen Zeichen ersetzen sollen, die einige Carrier nicht zuverlässig verarbeiten
Diese Einstellungen sollten gemeinsam betrachtet werden. Ein fehlender Standardwert oder eine zu aggressive Bereinigung kann die spätere Diagnose deutlich erschweren.
Support- und Lizenzinformationen verfügbar halten
Für Eskalationen fasst die Funktion BE-terna Support Info Kunden- und App-Metadaten wie Kundennummer, Ident, Business-Central-Version, Umgebungstyp, Publisher, App-Name und App-Version zusammen. So kann das Support-Team die betroffene Installation schneller identifizieren.
Wenn die BE-terna-Lizenz aktualisiert werden muss, erfolgt die Aktualisierung mit Kundennummer, Kunden-Ident und der Aktion Update from Web Service. Stellen Sie sicher, dass Allow HttpClient Requests aktiviert bleibt, sonst kann die Aktualisierung nicht abgeschlossen werden.
Für eine kontrollierte Lizenzaktualisierung empfiehlt sich diese Reihenfolge:
- Öffnen Sie die Seite für die BE-terna-Lizenz.
- Tragen Sie Customer No. und Customer Ident aus den gepflegten BE-terna-Kundendaten ein.
- Führen Sie Update from Web Service aus.
- Prüfen Sie das Ergebnis, bevor die aktuelle Lizenzperiode endet.
Wenn die Aktualisierung fehlschlägt, prüfen Sie zuerst Internetverbindung, gepflegte Kundendaten und die Erweiterungseinstellung Allow HttpClient Requests. Eine deaktivierte HTTP-Ausgangskommunikation blockiert den Erneuerungsprozess auch dann, wenn die fachlichen Daten korrekt sind.
Die Lizenzseite zeigt die beiden benötigten Kundenfelder und die Aktualisierungsaktion klar an:
Halten Sie die Erweiterungseinstellung für ausgehende Requests während der Aktualisierung aktiviert:
Felder und Aktionen
| Feld / Aktion | Bedeutung |
|---|---|
| Shipping Label URL code | Identifiziert den Endpunkteintrag, der in einer Carrier-Einrichtung verwendet wird |
| URL | Der carrierspezifische API-Endpunkt für Test- oder Produktivbetrieb |
| Log Deletion Date Formula | Definiert, welche Anfrageprotokolle durch die Bereinigungsaktion gelöscht werden |
| Test Mode | Erzwingt Testverhalten global oder, wenn unterstützt, auf der carrierspezifischen Einrichtung |
| Default Country / Default Recipient Country | Rückfall-Länderwerte, wenn das Quelldokument sie nicht liefert |
| Convert Special Characters | Ersetzt Zeichen, die einzelne Carrier nicht zuverlässig verarbeiten |
| Request Parameters | Öffnet die Header-Details zu einem ausgewählten Protokolleintrag |
| Request Shipping Labels / Show Label | Öffnet die Label-Details und ermöglicht den Download der Datei |
| Update from Web Service | Aktualisiert die BE-terna-Lizenz anhand der gepflegten Kundendaten |
Überwachung und Troubleshooting
- Beginnen Sie mit Error Text, Response und HTTP Status im Anfrageprotokoll. So erkennen Sie, ob es sich um ein Verbindungsproblem, eine abgelehnte Anfrage oder eine unvollständige Einrichtung handelt.
- Nutzen Sie Request Parameters und die Request-Payload, um zu prüfen, welche Quelldaten tatsächlich an den Carrier gesendet wurden.
- Wenn Anfragen wiederholt fehlschlagen, prüfen Sie URLs, Zugangsdaten, zugeordnete Herkunftsarten, zugeordnete Incoterms und die verpflichtenden Stammdaten auf Firmen-, Kunden-, Lagerort- oder Belegebene.
- Bewahren Sie genügend Anfragehistorie auf, um wiederkehrende Vorfälle analysieren zu können. Löschen Sie nur wirklich alte Protokolle.
Best Practices
- Trennen Sie produktive und Test-URLs sauber und validieren Sie jede URL-Änderung mit einer echten Labelanfrage.
- Erstellen Sie die erste Einrichtung manuell und nutzen Sie Konfigurationspakete erst, wenn die Basiskonfiguration nachweislich funktioniert.
- Bewahren Sie Anfrageprotokolle lange genug auf, um wiederkehrendes Troubleshooting und Go-Live-Stabilisierung zu unterstützen.
- Aktivieren Sie den globalen Testmodus nur bewusst und setzen Sie ihn nach der Testphase wieder zurück.
- Halten Sie Support-Metadaten und Lizenzinformationen aktuell, damit Eskalationen nicht erst mit Datensammlung beginnen.
Links