netresearch / dhl-shipping-m2

DHL multi-division shipping extension for Magento 2
Open Software License 3.0
13 stars 4 forks source link

No shipment with given tracking number found #23

Closed HenKun closed 3 years ago

HenKun commented 3 years ago

Preconditions

On some shipments an error is logged in exception.log as well as in dhl_paket.log that a shipment with this tracking number cannot be found.

Steps to reproduce

Expected Outcome

Actual Outcome

[2021-01-18 15:39:22] dhlpaket.ERROR: Error:
Not Found
with response:
HTTP/1.1 404 Not Found
Date: Mon, 18 Jan 2021 15:39:22 GMT
Content-Type: application/problem+json
Content-Length: 97
Connection: keep-alive
Correlation-Id: 8a3b2528-2772-4521-8b3d-cd4fcb7e690b
Content-Language: en
access-control-allow-origin: *
access-control-allow-headers: origin,x-requested-with,accept,content-type,dhl-api-key
access-control-max-age: 3628800
access-control-allow-methods: GET,OPTIONS

{"title":"No result found","status":404,"detail":"No shipment with given tracking number found."}

when sending request:
GET /track/shipments?trackingNumber=anonymized&service=parcel-de&requesterCountryCode=DE&originCountryCode=DE&recipientPostalCode=78357&language=de HTTP/1.1
Host: api-eu.dhl.com
DHL-API-Key: anonymized
Accept: application/json

 {"request":"[object] (Nyholm\\Psr7\\Request: {})","response":"[object] (GuzzleHttp\\Psr7\\Response: {})","exception":"[object] (Http\\Client\\Exception\\HttpException(code: 404): Not Found at /home/xy/public_html/magento2/prod/releases/20210101121849/vendor/dhl/sdk-api-unified-tracking/src/Http/Plugin/TrackingErrorPlugin.php:124)","milliseconds":292} []

Reason

I tested it using Postman and the DHL API indeed returns:

{
    "title": "No result found",
    "status": 404,
    "detail": "No shipment with given tracking number found."
}

However, if I leave the recipientPostalCode out, the API successfully returns the tracking info. So it seems the API has an error here. Maybe it considers the postal code wrongly on predated shipments?

Here the response of the same request, just without postal code:

{
    "shipments": [
        {
            "serviceUrl": "https://www.dhl.de/de/privatkunden.html?piececode=anonymized&cid=anonymized",
            "id": "anonymized",
            "service": "parcel-de",
            "status": {
                "timestamp": "2021-01-18T15:00:00",
                "location": {
                    "address": {
                        "addressLocality": "Deutschland"
                    }
                },
                "statusCode": "transit",
                "status": "Die Sendung wurde abgeholt.",
                "description": "Die Sendung wurde abgeholt."
            },
            "details": {
                "totalNumberOfPieces": 1,
                "pieceIds": [
                    "anonymized"
                ]
            },
            "events": [
                {
                    "timestamp": "2021-01-18T15:00:00",
                    "location": {
                        "address": {
                            "addressLocality": "Deutschland"
                        }
                    },
                    "statusCode": "transit",
                    "status": "Die Sendung wurde abgeholt.",
                    "description": "Die Sendung wurde abgeholt."
                }
            ]
        }
    ]
}

I tested it on multiple shipments, always the same. The postal code is always correct and equals the postal code set in Business Portal, so that cannot be the error. Due to privacy I left all personal data out. I can provide you some examples via email, if you let me know where to send it to.

mam08ixo commented 3 years ago

Please send request & response for both cases to the support address. We will then forward the issue to the API developers.

HenKun commented 3 years ago

Email is sent 👍

mam08ixo commented 3 years ago

I can confirm the issue and sent a support request to the DHL help center.

By the way, is there a reason why shipment is announced for tomorrow but picked up today ("predated")?

HenKun commented 3 years ago

Yes there is a reason we just found out recently. The dhlshippingsolutions/dhlglobalwebservices/cut_off_time setting came in with an update some time ago and is set to 00:00:00 initially. Because of that all shipments are created after the cut off time and hence, one day is always added. I think this additional day results in the shipment being considered as predated. We are about to switch the setting to 23:59:59 so all created shipments are before the cutoff time and an additional day is only added on sundays. (correct me if I am wrong with my assumption)

mam08ixo commented 3 years ago

I see, so sending the next day as shipment date is not done intentionally. IIRC there is an open issue with the cut-off time configuration that may come into effect here. One day being added may be a bug rather than a misconfiguration. We plan to replace it by a day-based setting in the future

HenKun commented 3 years ago

Correct, it is not intentionally. Can I see the ticket somewhere or is it internal?

mam08ixo commented 3 years ago

It is internal, not a user-reported issue.

ngolatka commented 3 years ago

@HenKun wrote:

Email is sent

... and received.

internal ref: DHLGW-1058

ngolatka commented 3 years ago

Short update: @mam08ixo is in contact with the API developer team at DHL. They are currently looking into the matter.

mam08ixo commented 3 years ago

We did not receive a response from DHL that explains the cause or announces a fix.

However, DHL Shipping v2.0.0 has the cut-off time calculation reworked. With this change and proper module configuration, shipments are no longer handed over the current day although announced for the next day.

Nothing more we can do about it, closing this.

HenKun commented 3 years ago

@mam08ixo Does the cut-off time setting now has a "different" meaning? Or rather do we need to change/adopt the setting to the new function or should we keep the current setting?

mam08ixo commented 3 years ago

@HenKun The setting has the same effect but, as announced earlier, it was moved and needs to be re-configured after upgrading to the new module version.