Missing Labels > Status 'processed

[codebase-md]

Currently I'm investigating a problem in one of our shops where shipments are created via mass action but some labels are missing. Suprisingly the status for those missing labels is set to 'processed'. After debugging a while I noticed that the \Dhl\ShippingCore\Model\Pipeline\Shipment\ResponseProcessor\UpdateLabelStatus processor gets executed before the \Dhl\ShippingCore\Model\Pipeline\Shipment\ResponseProcessor\AddShippingLabel. I'm almost sure that order is incorrect.

In this state a retry for creation is impossible because of the label status(and an existing shipment, see further below). I noticed a few hard validation errors but can't put them in relation to any order or shipment since the response looks like this

<CreationState>
            <sequenceNumber>3</sequenceNumber>
            <LabelData>
               <Status>
                  <statusCode>1101</statusCode>
                  <statusText>Hard validation error occured.</statusText>
                  <statusMessage>Bitte geben Sie eine Hausnummer an.</statusMessage>
                  <statusMessage>Die eingegebene Adresse ist nicht leitcodierbar.</statusMessage>
                  <statusMessage>Bitte geben Sie eine Hausnummer an.</statusMessage>
                  <statusMessage>Der eingegebene Wert ist zu lang und wurde gekürzt.</statusMessage>
               </Status>
            </LabelData>
</CreationState>

No info about the order or a magento shipment id (the shipment gets created)- nothing I can work with. Not to mention this message which occurs on weak validation errors as well <statusMessage>Der eingegebene Wert ist zu lang und wurde gekürzt.</statusMessage> Every time this message comes along there is no hint what so ever which value it is. Maybe another point to improve?

Which leads to the next problem. If a label creation fails for whatever reason the store owner can't retry because of this:

// create shipments for requested orders
        $orderCollection = $this->filter->getCollection($this->collectionFactory->create());
        $orderIds = $orderCollection->getColumnValues(OrderInterface::ENTITY_ID);
        $orderIncrementIds = $orderCollection->getColumnValues(OrderInterface::INCREMENT_ID);

        $shipmentIds = $this->bulkShipmentManagement->createShipments($orderIds);

        var_dump($shipmentIds);
        // extract successfully created shipments, inform about creation errors
        $shipmentIds = array_filter($shipmentIds);
        $failed = array_diff($orderIncrementIds, array_keys($shipmentIds));
        if (!empty($failed)) {
            $this->messageManager->addErrorMessage(
                __('Shipment(s) for the order(s) %1 could not be created.', implode(', ', $failed))
            );
        }

The shipment can't be created because it already exists. This in turn will put the shipmentId into the failed array. Maybe there is a way to improve this. Another mass action for just label creation maybe? A logging at this point would also be nice, since the shop employee will not remember a message with multiple order increments not to say that it sometimes just doesn't get noticed or the day is so busy that they forget to copy and send it.

I hope you can shed some light on this or give me some idea what I might be missing. Thanks in advance

[mam08ixo]

Hi @codebase-md

The order of response processors is correct.

To associate web service responses to requests, have a look at the sequenceNumber field. The same sequence number exists in the request and this request has a customerReference field that contains the order increment.

The message Der eingegebene Wert ist zu lang und wurde gekürzt is indeed a weak validation error. It does not prevent a label from being created. As this warning message comes directly from the DHL web service, the module can only pass it on – but cannot guess which field is affected.

The module configuration determines which orders are sent to the DHL web service in automated modes (General Configuration → Bulk/Cron Settings). It does not matter if a shipment entity was already created or not. Automated mode will only create one if not there yet, then proceeds with booking the label:

• The mass action sends label requests to the web service based on label status.
• Cron sends label requests to the web service based on label status and order status.

Order Status is self-explanatory. Retry Failed Shipments works as follows:

• Off sends orders with label status Pending, Partial
• On sends orders with label status Pending, Partial, Failed

I cannot see how a failed label request would lead to label status Processed. Please clarify.

There is no need to log or remember order increments of failed labels. Using the orders grid filters (esp. Purchase Date, DHL Label Status), it is rather straightforward to review all orders that did not receive a label yet.

[mam08ixo]

Did this answer your questions?

[codebase-md]

Hi @mam08ixo

apologies for the late response and thanks for your answer.

To associate web service responses to requests, have a look at the sequenceNumber field. The same sequence number exists in the request and this request has a customerReference field that contains the order increment.

I have to admit I've been blind because I just saw the request in the log. Almost ashamed to admit that I didn't see the request because it had been off screen(no line wrapping for logs). Now I can indeed relate everything. Thank you for the hint.

Order Status is self-explanatory. Retry Failed Shipments works as follows:

Off sends orders with label status Pending, Partial
On sends orders with label status Pending, Partial, Failed

Our customer doesn't use the cron based creation just the mass action. Since it is a german store I couldn't relate Retry Failed Shipments to the bulk action because the translation doesn't mention it. Thanks for the hint again. I will adjust the setting for Retry Failed Shipments.

Still it happened that the label status was set to processed (see screenshots) while the label was not received/saved.

Since there are no new cases of missing labels with label status processed I will close the issue for now.

Thank you for your help.

[mam08ixo]

Thanks for the update. If this happens again and turns out to be caused by the extension, feel free to reopen the issue.