FAQ

Open Shipping Label Setup > Assigned Source Types and verify that the table ID required for the affected process is maintained together with the correct source type. Shipping Labels can only generate labels for the source types that are assigned there. If a new document context needs additional information, extend the Assigned Source Types setup accordingly. See Setup.

Start in the request log and compare Error Text, Response, and HTTP Status. If the request never reached the carrier, first verify internet connectivity, the maintained URL, and the credentials. If the carrier rejected the request, review the source data that was sent: shipping agent service setup, assigned Incoterms, country data, addresses, package data, and required contact information. The Administration page explains which technical details are available in the request log.

Use a short readiness check before the first end-to-end test:

• The source document is registered in Assigned Source Types.
• The chosen shipping agent and agent service exist as an approved line in Shipping Agent Service Setups.
• The carrier setup contains the correct URL and the credentials for the intended environment.
• Sender, recipient, location, and country data are complete for the scenario.
• Item-level or fallback package data is available.
• Shipment date, work date, and Incoterm mapping are meaningful for the request.

Run the first test with a realistic document and inspect the request log immediately afterward instead of trying multiple variants in parallel.

Check the character encoding first and use UTF-8 wherever possible. If the issue continues, review the transmitted fields for umlauts, special characters, or copied formatting that the carrier cannot parse reliably. Where appropriate, activate Convert Special Characters in the global Shipping Label Setup so that problematic characters are normalized before the request is sent.

Maintain the phone number and email address on the location or sender record that is used for the shipment. Some carriers reject the request if this information is missing, even when the recipient data is complete. Also verify whether the scenario uses a specific warehouse or company address that differs from the standard sender data.

In DHL Shipping, REST credentials should be preferred from the beginning and take priority once they are maintained completely. Verify that the API username, password, key, and REST URL are all filled on the relevant setup and that the correct URL entry is assigned. If the setup is incomplete, the process can still behave like a SOAP-based scenario and request SOAP-related data.

If DHL Shipping returns an error that points to the billing number during the test setup, also verify the Test CIS EKP immediately. In known DHL test scenarios, the message can be misleading although the actual issue is the invalid CIS EKP. Do not focus only on the billing user if the EKP value itself may be wrong.

Review company information, customer data, location data, item attributes, and the active document together. For DHL Shipping REST, the required ISO Alpha-3 country data must be maintained. For DSV, the phone-number format must match the expected format exactly. For PCH, the supported destination is limited to Switzerland and Liechtenstein. In all scenarios, use real addresses, maintain package dimensions and weights where needed, and make sure the work date and shipment date are meaningful. If item-level attributes for height, width, length, and weight exist, prefer them over carrier-level fallback values.