parcelShopId is sent for non-PUDO shipments, causing shipment creation to fail
Environment
- PrestaShop: 1.7.6.8
- DPD Baltics module: 3.2.22
- Order page: legacy admin order page
- DPD API:
https://esiunta.dpd.lt/api/v1/
Problem
Creating and printing a label for a home-delivery order fails when the employee clicks the save_and_print action.
The DPD API returns:
PUDO id is provided but main service type is not PUDO
Example response:
[
{
"type": "https://esiunta.dpd.lt/api/v1/problems/address_conflict",
"title": "PUDO id is provided but main service type is not PUDO",
"detail": {},
"instance": ""
}
]PUDO deliveries continue to work correctly. The issue affects home-delivery orders.
Verified order data
The affected order used the following DPD product:
Product: D-B2C (home delivery)
is_pudo: 0
The related shipment had no PUDO ID, and there was no related row in dpd_pudo_cart. This confirms that the incorrect PUDO ID did not originate from the stored order or shipment data.
Root cause
In src/Service/API/ShipmentApiService.php, parcelShopId is added to the shipment request whenever ShipmentData::getSelectedPudoId() returns a value:
if ($shipmentData->getSelectedPudoId()) {
$shipmentCreationRequest = $this->setPudoData($shipmentCreationRequest, $shipmentData);
}getSelectedPudoId() only returns the value stored in the DTO. It does not verify that the selected DPD product is a PUDO service.
On the legacy admin order page, a parcel-shop ID can be present in the submitted form even when the selected product is a home-delivery service. Consequently, the API request contains both:
main service: D-B2C
parcelShopId: <a parcel-shop ID>
The DPD API rejects this conflicting combination.
Suggested fix
File:
src/Service/API/ShipmentApiService.php
Method:
ShipmentApiService::createShipment()
Only add PUDO data when the selected DPD product is actually a PUDO product:
-if ($shipmentData->getSelectedPudoId()) {
+if ($dpdProduct->is_pudo && $shipmentData->getSelectedPudoId()) {
$shipmentCreationRequest = $this->setPudoData($shipmentCreationRequest, $shipmentData);
}The product is loaded server-side earlier in the same method:
$dpdProduct = new DPDProduct($shipmentData->getProduct());
The shipment request must include parcelShopId only when the selected main service is a PUDO service. Checking only whether a PUDO ID has a value is insufficient and can produce an invalid API request.
Result after applying the fix
- Home-delivery labels can be created and printed again.
- PUDO label creation continues to work.
parcelShopId is not included for products where is_pudo = 0.
Steps to reproduce
- Open a home-delivery order on the PrestaShop 1.7.6.8 legacy admin order page.
- Ensure that the selected DPD product is
D-B2C and has is_pudo = 0.
- Click the button with
data-action="save_and_print".
- Observe that shipment creation fails with
PUDO id is provided but main service type is not PUDO when a parcel-shop ID is present in the submitted shipment data.
Expected behavior
parcelShopId must only be included in a shipment creation request when the selected main service is a PUDO service.
parcelShopIdis sent for non-PUDO shipments, causing shipment creation to failEnvironment
https://esiunta.dpd.lt/api/v1/Problem
Creating and printing a label for a home-delivery order fails when the employee clicks the
save_and_printaction.The DPD API returns:
Example response:
[ { "type": "https://esiunta.dpd.lt/api/v1/problems/address_conflict", "title": "PUDO id is provided but main service type is not PUDO", "detail": {}, "instance": "" } ]PUDO deliveries continue to work correctly. The issue affects home-delivery orders.
Verified order data
The affected order used the following DPD product:
The related shipment had no PUDO ID, and there was no related row in
dpd_pudo_cart. This confirms that the incorrect PUDO ID did not originate from the stored order or shipment data.Root cause
In
src/Service/API/ShipmentApiService.php,parcelShopIdis added to the shipment request wheneverShipmentData::getSelectedPudoId()returns a value:getSelectedPudoId()only returns the value stored in the DTO. It does not verify that the selected DPD product is a PUDO service.On the legacy admin order page, a parcel-shop ID can be present in the submitted form even when the selected product is a home-delivery service. Consequently, the API request contains both:
The DPD API rejects this conflicting combination.
Suggested fix
File:
Method:
ShipmentApiService::createShipment()Only add PUDO data when the selected DPD product is actually a PUDO product:
The product is loaded server-side earlier in the same method:
The shipment request must include
parcelShopIdonly when the selected main service is a PUDO service. Checking only whether a PUDO ID has a value is insufficient and can produce an invalid API request.Result after applying the fix
parcelShopIdis not included for products whereis_pudo = 0.Steps to reproduce
D-B2Cand hasis_pudo = 0.data-action="save_and_print".PUDO id is provided but main service type is not PUDOwhen a parcel-shop ID is present in the submitted shipment data.Expected behavior
parcelShopIdmust only be included in a shipment creation request when the selected main service is a PUDO service.