netresearch / dhl-shipping-m2 Goto Github PK
View Code? Open in Web Editor NEWDHL multi-division shipping extension for Magento 2
License: Open Software License 3.0
DHL multi-division shipping extension for Magento 2
License: Open Software License 3.0
I did a first test update to Magento 2.4.4 and ran into the following conflict:
Problem 1
- dhl/shipping-m2 2.5.0 requires dhl/module-carrier-paket ~2.5.0 -> satisfiable by dhl/module-carrier-paket[2.5.0].
- dhl/module-carrier-paket 2.5.0 requires monolog/monolog ^1.17 -> found monolog/monolog[1.17.0, ..., 1.27.0] but it conflicts with your root composer.json require (^2.3).
- Root composer.json requires dhl/shipping-m2 ^2.5 -> satisfiable by dhl/shipping-m2[2.5.0].
Using monolog/monolog version 1.17 as required by dhl/module-carrier-paket module is not possible as Magento 2.4.4 requires at least version 2.3. Is it safe to use this version also with dhl/module-carrier-paket?
Shipping costs are incorrectly calculated. Example: Shipping weight per item 0.150 kg. Customer orders 20 items, it weighs 3,000 kg, but a 5kg package will be charged and that is wrong. up to 3,000kg and only from 3,0001 kg, the 5kg package should be triggered, as it is calculated that way by DHL.
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.
This happens when "Track Shipment" is clicked in admin area. Only the link to DHL is shown then, instead of the tracking info itself.
This seems to only happen on all "predated" shipments, before the day they are predated to.
[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} []
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.
Hi!
Is there any way to get a module version compatible with Magento 2.4.1?
Currently the old module https://github.com/netresearch/dhl-module-shipping-m2 is incompatible because magento/framework version is compatible with only M2.2/2.3.
By packstation map popup you can get this error
https://drive.google.com/file/d/1rsp3YGkthJYxkq3QUheJL3fPsgIuNaIH/view?usp=sharing
Hi,
we have activated the parcel finder option for our customers.
The option for finding parcel station is not shown in frontend UNTIL a complete address is filled out.
It would be better the parcel finder option is shown in a deactivated state or with a tooltip, that the parcel finder can be used if the address is filled out.
You can check this at https://shop.icletta.com
Not sure if this us the Magento-Plugin (sinc eit transmits the shopping cart) or the DHL backend.
For a "Warensendung International" it prints a CN22 customs content declaration.
.... for shipments from Germany to Spain.
(but not for Germany to Portugal. )
Both are set up as EU countries in Stores->Config->General->General->Countries.
For shipments within the EU it should obviosly not do that.
Since you just closed the issue without giving me the opportunity to respond, I'm gonna go again.
Referring to: netresearch/module-shipping-ui#1
I already am on the latest version of dhl/shipping-m2
. My composer.lock reports version 1.5.1.
So what can I do to get the proper items inside a totals.phtml?
is there already a plan whether you will make the module also Hyva compatible?
https://checkout-demo.hyva.io/
We have added the module as Checkout Integration Tracker:
https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/85
Greetings Chris
Magento version: 2.4.5-p1 CE
I ran following commands to install and enable modules but getting error while run di compile.
$ composer require dhl/shipping-m2
$ bin/magento module:enable PostDirekt_Core PostDirekt_Autocomplete PostDirekt_Addressfactory DeutschePost_Internetmarke Netresearch_InteractiveBatchProcessing Netresearch_ShippingUi
$ bin/magento s:up && bin/magento s:d:c
Cache types config flushed successfully
Cache cleared successfully
File system cleanup:
/home/ndlinh/Works/DigitalFree/artisan/generated/code/Magento
/home/ndlinh/Works/DigitalFree/artisan/generated/code/Netresearch
/home/ndlinh/Works/DigitalFree/artisan/generated/code/Psr
/home/ndlinh/Works/DigitalFree/artisan/generated/code/Symfony
The directory '/home/ndlinh/Works/DigitalFree/artisan/generated/metadata/' doesn't exist - skipping cleanup
Updating modules:
Invalid path in extends attribute of config/system/sections/dhlshippingsolutions/dpim/dpimInfoBox node
In ExtendsMapper.php line 135:
Invalid path in extends attribute of config/system/sections/dhlshippingsolutions/dpim/dpimInfoBox node
We have an existing setup of magento version: 2.3.6
and now obsolete dhl-module-shipping-m2 module. My first attempt to update module by directly upgrading composer.json
didn't work, I was not able to add items to a cart(error I got was: quote couldn't be saved
)
I followed comments on other closed issue and as pointed out here If I remove the data manually I am able to upgrade to this release.
But we are using another module: DHL Label Status extension and it is tied to obsolete extension. When I try to remove data just for ./bin/magento module:uninstall --remove-data Dhl_Shipping
, I can't because of Dhl_LabelStatus
dependency.
Can this be resolved without removing data? Is there an alternate to Dhl_LabelStatus
that works with latest Dhl_Shipping
module?
Magento version 2.3.3
I did the following:
Replaced this lines in composer.json:
"dhl/module-label-status": "^1.1",
"dhl/module-shipping-m2": "^0.11",
with:
"dhl/shipping-m2": "^1.0.0",
Then
php composer.phar update
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush
php bin/magento cache:clean
When I access the frontend or backend I get the following Error:
main.CRITICAL: Class Dhl\Shipping\Model\Attribute\Backend\ExportDescription does not exist {"exception":"[object] (ReflectionException(code: -1): Class Dhl\\Shipping\\Model\\Attribute\\Backend\\ExportDescription does not exist at [...]/vendor/magento/framework/Code/Reader/ClassReader.php:19)"} []
Is this module compatible with Magento 2.4.6? After installing and running bin/magento setup:di:compile
my Magento shop breaks whenever this DHL module is referenced.
and in the logs I can see
[2023-10-17T13:52:38.735794+00:00] main.CRITICAL: ReflectionException: Class "Netresearch\ShippingCore\Observer\JoinOrderItemAttributes" does not exist in /bitnami/magento/vendor/magento/framework/Code/Reader/ClassReader.php:34
[2023-10-17T13:48:21.911644+00:00] main.CRITICAL: ReflectionException: Class "Netresearch\ConfigFields\Block\InfoBox" does not exist in /bitnami/magento/vendor/magento/framework/Code/Reader/ClassReader.php:34
Beim Ersten ausfüllen der Daten im Checkout wird der Button Packstation finden nicht angezeigt. Erst nach dem die Seite über den Browser neu geladen wird, wird der Button angezeigt.
Wenn die Checkout Daten vorhanden sind und man die Adresse ändert wird das Popup nicht immer mit der neuen Adresse befüllt sondern nimmt die alten Daten. (Es ist nicht immer reproduzierbar)
Des weiteren kommt es vor das die Versandart vorausgewählt ist und manchmal nicht das hat auch auswirkungen auf das Popup Packstation finden und die enthalten Daten z.B. Land. aber auch andere Daten
Wenn ich ein Custom Theme benutze wird das Land nicht ausgewählt und somit kann kein Auswahl der Packstation getroffen werden.
Ich benutzte Magento Version 2.4.1 und 2.4.2 auch versucht in kombination dhl-shipping-m2 v 1.5.0 und 1.5.0
Wie gesagt es ist schwer zu reproduzieren oder eine klare Aussage zu treffen wann weshalb warum auf jedenfall funktioniert es bei mir nicht wie es soll.
Hello together,
would it be possible for you to add another function for the module?
Currently I have not found a way to send the generated shipping labels to a specific email address.
This would be very helpful to reduce the amount of work. For example, all delivery bills are sent to a specific e-mail address as an attachment and automatically printed from there. We would also like to have this for the labels, which are generated automatically.
Best Regards Christoph
The old module used
"Stores → Konfiguration → Verkäufe → Versandarten → DHL Versenden → Allgemeine Versandeinstellungen → Versandarten für DHL Versenden"
to configure alternative offline shipping methods that would allow to create DHL postage.
We used this to print DHL postage for orders imported from Amazon.
So for these ordres, no human ever went through the Magento checkout process.
It worked fine after the migration.
Now we needed to create a new store view specifically for Amazon (so no longer send automated emails).
Printing DHL postage is no longer offered for these orders and we can not find a way to connect the offline shipping method to DHL again.
Fatal error: Class Dhl\Paket\Model\Webservice\ShipmentService contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Dhl\Sdk\Paket\Bcs\Api\ShipmentServiceInterface::validateShipments) in /htdocs/vendor/dhl/module-carrier-paket/Model/Webservice/ShipmentService.php on line 18
I get the following error message when I want to create a shipping label.
"Versandetikett konnte nicht erstellt werden: Web service request failed."
I called DHL to see if there was a problem. There I was told that a new polling interface has been active since Thursday and that I should update the module. But that did not bring the desired success.
Any ideas?
Although Dhl\ShippingCore\Model\Util\StreetSplitter
has a massively complex regex, it fails on the simple case where there is no space between street name and house number.
E.g. Musterstraße12
as street name leads to a not detected house number, see the following screenshot.
Labels cannot be created due to this issue and the address needs to be corrected manually.
We now solved it on our end with a custom plugin that matches this case, but it would be better if DHL Core module itself solves the issue.
Hi,
with Magento 2.4.4, PHP8.1 and labels created automatically by cronjob, I see a strange issue:
Labels are created in DHL. Label status in Magento goes to green, but no tracking ID or shipping label for download shows up in Magento.
Same applies also to GLS Labels created by cronjob, they are created in GLS but tracking ID and shipping label not showing up in Magento.
If I create the labels manually in Magento (via create shipping and create shipping label or bulk operation on order grid), everything is fine.
The system.log or exception log or the shipping extension logs do not show any error message.
The GLS log looks totally fine.
DHL Log see below:
[2022-07-12T07:28:00.066070+00:00] dhlpaket.ERROR: Error:
Not Found
with response:
HTTP/1.1 404 Not Found
Date: Tue, 12 Jul 2022 07:28:00 GMT
Content-Type: application/problem+json
Content-Length: 97
Connection: keep-alive
Correlation-Id: baf9a8d8-e263-4e34-803d-dfcb34e16243
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
Strict-Transport-Security: max-age=63113904; includeSubDomains; preload
For unknown reason the GLS repository is read only, maybe someone can clarify, no bugreport possible there.
Thank you!
It seems that a user may be able to select "[x] parcel station" delivery during checkout without actually selecting a parcel station or entering a Postnummer.
When creating the postage a generic error message, no entry in the dhl_paket.log and the following stack trace in exception.log happens.
[2020-11-05 11:11:18] main.CRITICAL: Notice: Undefined index: locationType in .../vendor/dhl/module-carrier-paket/Model/Pipeline/CreateShipments/RequestDataMapper.php on line 229 {"exception":"[object] (Exception(code: 0): Notice: Undefined index: locationType in .../vendor/dhl/module-carrier-paket/Model/Pipeline/CreateShipments/RequestDataMapper.php on line 229 at .../vendor/magento/framework/App/ErrorHandler.php:61)"} []
As a workaround you can manually unselect the "[x] parcel station delivery" in the postage creation dialog.
Hi,
after solving 3D Secure problem (netresearch/module-shipping-ui#8) a new issue occured.
Compatibility with Magedelight SubscribeNow module is broken. After the update, the subscription module is unable to generate orders.
Order generation fails with the following error:
Error: Rolled back transaction has not been completed correctly.
Kind regards.
Tobias
I have a free shipping option that can only be selected in the admin area. If I select this and try to create a delivery note, I am not redirected to the input mask for creating the shipping label, the shipping is created without a label and marked as shipped. Is there a solution for this?
Hello, I've just installed and configured the 2.7.0 version of your plugin for our Magento 2.4.4 instance. After marking an order as shipped with DHL and adding a tracking number, I'm no longer able to retrieve customer orders over GraphQL. The following simple GraphQL query, for example:
{
customer {
orders {
items {
items {
product_name
}
shipments {
tracking {
carrier
number
title
}
}
}
}
}
}
results in an "Internal server error." Specifically, the following response is returned:
{
"errors": [
{
"message": "Internal server error",
"extensions": {
"category": "internal"
},
"locations": [
{
"line": 5,
"column": 9
}
],
"path": [
"customer",
"orders",
"items",
0,
"items",
0
]
}
],
"data": {
"customer": {
"orders": {
"items": [
{
"items": [
null,
null,
null,
null,
null
],
"shipments": [
{
"tracking": [
{
"carrier": "dhlpaket",
"number": "<THE TRACKING NUMBER I SUPPLIED>",
"title": "DHL Paket"
}
]
}
]
},
... (more orders)
]
}
}
}
}
That is, all items within an order are, incorrectly, null
. After further inspection, the items
array queried through GraphQL under customer -> order -> invoices
is also always null
. The following error was retrieved from the system logs after performing the above query:
[2022-07-20T00:22:10.303033+00:00] main.ERROR: SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'item_id' in where clause is ambiguous, query was: SELECT `main_table`.*, `extension_attribute_nrshipping_country_of_manufacture`.`country_of_manufacture` AS `extension_attribute_nrshipping_country_of_manufacture_country_of_manufacture`, `extension_attribute_nrshipping_export_description`.`export_description` AS `extension_attribute_nrshipping_export_description_export_description`, `extension_attribute_nrshipping_hs_code`.`hs_code` AS `extension_attribute_nrshipping_hs_code_hs_code` FROM `sales_order_item` AS `main_table`
LEFT JOIN `nrshipping_order_item` AS `extension_attribute_nrshipping_country_of_manufacture` ON main_table.item_id = extension_attribute_nrshipping_country_of_manufacture.item_id
LEFT JOIN `nrshipping_order_item` AS `extension_attribute_nrshipping_export_description` ON main_table.item_id = extension_attribute_nrshipping_export_description.item_id
LEFT JOIN `nrshipping_order_item` AS `extension_attribute_nrshipping_hs_code` ON main_table.item_id = extension_attribute_nrshipping_hs_code.item_id WHERE ((`item_id` IN(108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155)))
Thanks a lot,
Max
Hello together,
currently the dependencies seem to be still on PSR LOG 1.
deutschepost/sdk-api-addressfactory 2.0.1 requires psr/log (^1.1.0)
deutschepost/sdk-api-autocomplete-authentication 1.1.0 requires psr/log (^1.1.0)
deutschepost/sdk-api-oneclickforapp 1.1.0 requires psr/log (^1.1)
deutschepost/sdk-api-oneclickforrefund 1.1.0 requires psr/log (^1.1)
deutschepost/sdk-api-prodws 1.1.2 requires psr/log (^1.1)
dhl/sdk-api-bcs 1.3.0 requires psr/log (^1.1)
dhl/sdk-api-bcs-returns 2.1.2 requires psr/log (^1.1.0)
dhl/sdk-api-parcel-management 3.1.0 requires psr/log (^1.1.0)
dhl/sdk-api-unified-location-finder 3.0.0 requires psr/log (^1.1.0)
dhl/sdk-api-unified-tracking 2.2.1 requires psr/log (^1.1.0)
Expected
requires psr/log (^1.1 || ^2.0 || ^3.0)
Hello,
I am currently working on migrating to your new magento shipping extension (dhl-shipping-m2) from the deprecated one (dhl-module-shipping-m2 or DHL Versenden). The following documentation was a great help to me: https://github.com/netresearch/dhl-module-carrier-paket/wiki/Documentation-English. After setting the extension up and configuring the settings for shipping label print-outs, I tried generating labels via mass-action. For this I used the newly present option in the orders menu: "DHL Shipping". However, despite the manual label generation working perfectly fine, using the mass-action returns "Order cannot be shipped with DHL". This was only tried with orders made using the new extension. The old option "Create shipping labels" still works for its respective orders.
It might also be important to mention, that the DHL Label Status always shows "Not Available" for the new orders.
I hope you can help me fix this problem.
Hi there, Can you please remove all references to Zend_Measure_Weight and replace with vendor/magento/framework/Measure/Weight.php
. Currently Magento is forcing out all Zend related classes and is migrating to Laminas. But in you case all weight references can be found in the Weight class of magento.
If this is fixed the composer requirement to magento/zendframework1
can be removed in the composer.json also. Magento also doesn't use this requirement anymore, only for dev usage.
The reason for this issue is that your module now gives a lot of warnings during composer install like this:
Warning: Ambiguous class resolution, "Zend_Cache_Backend" was found in both "/data/plutosport/magento2/vendor/magento/zend-cache/library/Zend/Cache/Backend.php" and "/data/plutosport/magento2/vendor/magento/zendframework1/library/Zend/Cache/Backend.php", the first will be used.
Warning: Ambiguous class resolution, "Zend_Cache_Manager" was found in both "/data/plutosport/magento2/vendor/magento/zend-cache/library/Zend/Cache/Manager.php" and "/data/plutosport/magento2/vendor/magento/zendframework1/library/Zend/Cache/Manager.php", the first will be used.
Warning: Ambiguous class resolution, "Zend_Db" was found in both "/data/plutosport/magento2/vendor/magento/zend-db/library/Zend/Db.php" and "/data/plutosport/magento2/vendor/magento/zendframework1/library/Zend/Db.php", the first will be used.
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
Since https://github.com/netresearch/dhl-module-shipping-m2 is deprecated and the new module https://github.com/netresearch/dhl-shipping-m2 should be used I wonder if there is any documentation for this project, both technical documentation and some guidance for shop owners.
Can you provide those resources?
For orders >125 GBP (according to ) to the UK (except northern ireland = ZIP codes starting with "BT"), the customer pays VAT and duties and the seller
has to do the usual export paperwork (just CN22/CN23 for orders <1000eur).
Looks like the backend handles that case but the frontend is missing the input fields
for an export and handles it like an EU parcel.
(Magento VAT rules can't handle value dependent VAT rules yet either, so we currently have a minimum order size for UK customers.)
HMRC rule:
official exchange rates for the 125 GBP rule:
https://www.gov.uk/government/publications/hmrc-exchange-rates-for-2021-monthly
Is there a plan or timeline for implementing Magento 2.4 support?
When trying to use the Location Finder with a new Mapbox API Token the Map isn't loaded and you can see in the Browser Console that the API Request is returning a 410 Error.
When calling the API Request separately in a new Tab you get the following Message:
{"message":"Classic styles are no longer supported; see https://blog.mapbox.com/deprecating-studio-classic-styles-d8892ac38cb4 for more information"}
The Link explains that no more new requests will be accepted:
Then on June 1st, we will no longer support requests to our Legacy Maps and Legacy Static Images APIs from new applications and websites.
It also explains how to transition to the new Style.
This currently makes the Location Finder unusable in any new Shop.
We use (or maybe misuse) the weight property of articles to calculate shipping costs via tablerate. This is not the real weight, but in most cases a much higher number. With the old extension this was no problem. This new extension seems to have a max_package_weight defined in https://github.com/netresearch/dhl-module-carrier-paket/blob/3a64acc69a14fd019319a70449ad49aadf5d1a82/etc/config.xml#L14. Could this value become configurable in the backend?
It would be a very handy feature if the shipping-M2 module would not only download the postage
but also the "Auslieferungsnachweis" (export certification) of shipments.
So users don't forget to manually download and archive them for each and every shipment destined for other EU or non-EU countries.
In the DHL brexit documentation it is not requires but recommed to enter one's EORI number.
https://www.dhl.de/brexit
Usually an EU company has but 1 EORI number issued by the country they are in.
Sometimes a second for a non-EU origin country they have a second shipping facility in.
The input in dhl-shipping-m2 requires the user to enter the EORI ("Customs Reference Numbers")
separately for each destination country. So for the usual case, you have to enter the same number about 200 times.
This way of handling the input seems suboptimal.
Currently you can only select a parcel station in the checkout via the shopfinder modal. It would be very useful to be able to save the parcel station as a shipping address in the customer address book and be able to set it as the default shipping address.
We faced an issue, where the DHL Soap Server did not responded correctly or in time (I guess so), when a label was requested.
The error was logged, however, not visible in backend, which led to confusion:
dhlpaket.ERROR: Error Fetching http headers
[2020-12-22 13:34:41] dhlpaket.ERROR: POST /services/production/soap HTTP/1.1
Host: cig.dhl.de
Connection: Keep-Alive
User-Agent: PHP-SOAP/7.3.24
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:createShipmentOrder"
Content-Length: 1855
Authorization: Basic [hidden]
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://dhl.de/webservice/cisbase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://dhl.de/webservices/businesscustomershipping/3.0"><SOAP-ENV:Header><ns1:Authentification><ns1:user>[hidden]</ns1:user><ns1:signature>[hidden]</ns1:signature></ns1:Authentification></SOAP-ENV:Header><SOAP-ENV:Body><ns2:CreateShipmentOrderRequest><Version xsi:type="ns1:Version"><ns1:majorRelease>3</ns1:majorRelease><ns1:minorRelease>0</ns1:minorRelease></Version><ShipmentOrder><sequenceNumber>0</sequenceNumber><Shipment><ShipmentDetails><product>V53WPAK</product><ns1:accountNumber>[hidden]</ns1:accountNumber><customerReference>YY</customerReference><shipmentDate>2020-12-23</shipmentDate><ShipmentItem><weightInKG>0.36</weightInKG></ShipmentItem></ShipmentDetails><Shipper><Name><ns1:name1>xx</ns1:name1></Name><Address><ns1:streetName>xx</ns1:streetName><ns1:streetNumber>15</ns1:streetNumber><ns1:zip>06120</ns1:zip><ns1:city>Halle (Saale)</ns1:city><ns1:province>SAC</ns1:province><ns1:Origin><ns1:countryISOCode>DE</ns1:countryISOCode></ns1:Origin></Address><Communication/></Shipper><Receiver><ns1:name1>xx</ns1:name1><Address><ns1:name2></ns1:name2><ns1:streetName>52/xx</ns1:streetName><ns1:streetNumber></ns1:streetNumber><ns1:addressAddition></ns1:addressAddition><ns1:zip>eh530dn</ns1:zip><ns1:city>east calder</ns1:city><ns1:province></ns1:province><ns1:Origin><ns1:countryISOCode>GB</ns1:countryISOCode></ns1:Origin></Address><Communication/></Receiver></Shipment><PrintOnlyIfCodeable active="1"/></ShipmentOrder><labelResponseType>B64</labelResponseType></ns2:CreateShipmentOrderRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
[] []
[2020-12-22 13:34:41] dhlpaket.ERROR: HTTP/1.1 200 OK
Date: Tue, 22 Dec 2020 13:34:40 GMT
Server: WebServer
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
X-XSS-Protection: 1; mode=block
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'none'; script-src 'none'; frame-src 'none'; object-src 'none'
Content-Type: text/xml;charset=utf-8
Content-Length: 1409
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
<soap:Envelope xmlns:bcs="http://dhl.de/webservices/businesscustomershipping/3.0" xmlns:cis="http://dhl.de/webservice/cisbase" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Header/>
<soap:Body>
<bcs:CreateShipmentOrderResponse>
<bcs:Version>
<majorRelease>3</majorRelease>
<minorRelease>0</minorRelease>
</bcs:Version>
<Status>
<statusCode>1101</statusCode>
<statusText>Hard validation error occured.</statusText>
</Status>
<CreationState>
<sequenceNumber>0</sequenceNumber>
<LabelData>
<Status>
<statusCode>1101</statusCode>
<statusText>Hard validation error occured.</statusText>
<statusMessage>Bitte geben Sie eine Hausnummer an.</statusMessage>
<statusMessage>Es handelt sich um eine ungültige Postleitzahl. Bitte verwenden Sie eine britisches Format: AA9A 9AA, A9A 9AA, A9 9AA, A99 9AA, AA9 9AA oder AA99 9AA. Es ist dennoch möglich, einen Versandschein zu drucken.</statusMessage>
<statusMessage>Bitte geben Sie eine Hausnummer an.</statusMessage>
</Status>
</LabelData>
</CreationState>
</bcs:CreateShipmentOrderResponse>
</soap:Body>
</soap:Envelope> [] []
[2020-12-22 13:34:41] dhlpaket.ERROR: Hard validation error occured. Bitte geben Sie eine Hausnummer an. Es handelt sich um eine ungültige Postleitzahl. Bitte verwenden Sie eine britisches Format: AA9A 9AA, A9A 9AA, A9 9AA, A99 9AA, AA9 9AA oder AA99 9AA. Es ist dennoch möglich, einen Versandschein zu drucken. [] []
[2020-12-22 13:38:48] dhlpaket.ERROR: POST /services/production/soap HTTP/1.1
Host: cig.dhl.de
Connection: Keep-Alive
User-Agent: PHP-SOAP/7.3.24
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:createShipmentOrder"
Content-Length: 1854
Authorization: Basic [hidden]
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://dhl.de/webservice/cisbase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://dhl.de/webservices/businesscustomershipping/3.0"><SOAP-ENV:Header><ns1:Authentification><ns1:user>[hidden]</ns1:user><ns1:signature>[hidden]</ns1:signature></ns1:Authentification></SOAP-ENV:Header><SOAP-ENV:Body><ns2:CreateShipmentOrderRequest><Version xsi:type="ns1:Version"><ns1:majorRelease>3</ns1:majorRelease><ns1:minorRelease>0</ns1:minorRelease></Version><ShipmentOrder><sequenceNumber>0</sequenceNumber><Shipment><ShipmentDetails><product>V53WPAK</product><ns1:accountNumber>[hidden]</ns1:accountNumber><customerReference>YY</customerReference><shipmentDate>2020-12-23</shipmentDate><ShipmentItem><weightInKG>0.36</weightInKG></ShipmentItem></ShipmentDetails><Shipper><Name><ns1:name1>XX</ns1:name1></Name><Address><ns1:streetName>xx</ns1:streetName><ns1:streetNumber>15</ns1:streetNumber><ns1:zip>06120</ns1:zip><ns1:city>Halle (Saale)</ns1:city><ns1:province>SAC</ns1:province><ns1:Origin><ns1:countryISOCode>DE</ns1:countryISOCode></ns1:Origin></Address><Communication/></Shipper><Receiver><ns1:name1>xx</ns1:name1><Address><ns1:name2></ns1:name2><ns1:streetName>xx</ns1:streetName><ns1:streetNumber>52</ns1:streetNumber><ns1:addressAddition></ns1:addressAddition><ns1:zip>eh530dn</ns1:zip><ns1:city>east calder</ns1:city><ns1:province></ns1:province><ns1:Origin><ns1:countryISOCode>GB</ns1:countryISOCode></ns1:Origin></Address><Communication/></Receiver></Shipment><PrintOnlyIfCodeable active="1"/></ShipmentOrder><labelResponseType>B64</labelResponseType></ns2:CreateShipmentOrderRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
[] []
[2020-12-22 13:38:48] dhlpaket.ERROR:
[] []
[2020-12-22 13:38:48] dhlpaket.ERROR: Error Fetching http headers [] []
I tried to install the extension in a new clean environment of Magento 2.4.
composer require dhl/shipping-m2
I get this output:
`Using version ^1.1 for dhl/shipping-m2
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for laminas/laminas-code (locked at 3.4.1) -> satisfiable by laminas/laminas-code[3.4.1].
- dhl/shipping-m2 1.1.0 requires dhl/module-carrier-paket ~1.1.0 -> satisfiable by dhl/module-carrier-paket[1.1.0].
- dhl/shipping-m2 1.1.0 requires dhl/module-carrier-paket ~1.1.0 -> satisfiable by dhl/module-carrier-paket[1.1.0].
- dhl/module-carrier-paket 1.1.0 requires dhl/module-unified-tracking ^1.0.0 -> satisfiable by dhl/module-unified-tracking[1.0.0].
- Conclusion: don't install dhl/module-unified-tracking 1.0.0
- Installation request for dhl/shipping-m2 ^1.1 -> satisfiable by dhl/shipping-m2[1.1.0].
Installation failed, reverting ./composer.json to its original content.
`
Any suggestions would be nice, thanks a lot!
I am maintaining 2 separate magentos (both 2.4.4). Both have the dhl/shipping-m2
module (2.7.0) installed.
In one of those shops the admin part looks somewhat broken as if some css is missing:
While in the other this looks fine:
How can I fix this?
In addition to that there is an issue with the display of dropdowns in BOTH shops:
The dropdowns and text fields are all collapsed. This can be fixed by adding these classes to the form fields:
admin__control-text
for text inputsadmin__control-select
for selectsMaybe there are more of these classes. I haven't dug too deep but I have a feeling this is something new in 2.4.4. I had the same issue with another module after upgrading to 2.4.4.
What is the right module to enable? It seems like that there are these modules:
"deutschepost/module-autocomplete-m2": "~1.1.1",
"deutschepost/module-addressfactory-m2": "~1.1.2",
"deutschepost/module-internetmarke": "~2.0.0",
"dhl/module-carrier-paket": "~2.0.0",
"dhl/module-carrier-paket-returns": "~2.0.0",
"netresearch/module-shipping-ui": "~2.0.1"
According to the installation instructions there seems to be something missing.
Hello,
DHL box at the bottom of the checkout is not updating after changing some settings in the "Shipping Services in Checkout" section.
Ways to reproduce:
We just tried to create postage as usual for a delivery to a regular house address in Germany
and noticed that the "Shipment Setup" dialog would show
"[X] Parcel Station Delivery" selected and
a DHL Postnummer.
The delivery address of the order didn't contain any DHL Postnummer and nothing in the customer's details show one.
In some cases it could be helpful to adjust customerPostnumber directly in the order. For example, if the customer specifies the wrong post number, there is currently no possibility to change it within the order. Alternatively, the postal number should already be checked when placing the order, so that the problem does not arise.
dhl/shipping-m2 2.9.0
magento/product-community-edition 2.4.6-p3
An input address line for a US address
"%housenb% %street%, Apt #%apt%
gets broken up into
Street Name: %street%
Street Number: %housenb%
Supplement: "Apt #%apt%"
But in the resulting label the supplement=apartment number is not printed as part of the label.
Causing an already expensive 36.13€ parcel to be returned with an additional 20€ return fee.
Just a very minor feature request to make usage more streamlined:
In some cases dhl-shipping-m2 makes entering parcel dimensions mandatory.
I just noticed that the fields are ordered width-height-length while
the common order is always length/longest side - width - height (shortest side)
Also cardboard boxes are sold in millimeter while the input is in centimeter.
People would usually copy&paste the size from one of their orders of cardboard boxes.
Currently version 2.2.0 is only available on packagist.org and not (yet?) in the magento repo (repo.magento.com).
This leads to an errror from the Magento composer dependency version audit plugin.
[Exception]
Higher matching version 2.2.0 of dhl/shipping-m2 was found in public repository packagist.org
than 2.1.0 in private https://repo.magento.com. Public package might've been taken over by a malicious entity,
please investigate and update package requirement to match the version from the private repository
Whenever I do
composer require dhl/shipping-m2:1.0.0
I get an error telling me
[InvalidArgumentException]
Could not find package dhl/shipping-m2 in a version matching 1.0.0
Is it not on the Magento repo?
I am currently upgrading a store that is still running on Magento 2.2.9. Of course it is also running the old dhl shipping module.
So I upgraded on my local system and everything seems to work fine except when I go to cart or the checkout.
I can still access the cart page but it is already odd that the cart's summary does not show up. But other than that there are no error messages (e.g. in JS console) or log entries (var/log/, var/report/). Btw... I enabled error reporting in index.php.
When I go to checkout I can see the shop's header and footer but in the middle of the page a spinner keeps spinning forever and nothing else happens. Also no error messages or log entries.
The same behaviour occurs when switching to magento's luma theme.
When I disable all dhl/shipping-m2 modules everything works fine.
So my question is: how can I narrow down the issue? Is there anything I can do to maybe rest all the DHL settings and start over? Since there are no error messages or log entries I am kind of lost here.
Thank you.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.