• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)

Description of your issue, suggested solution and other information

Viewing of orders in the customers account section can result in JS errors, the module templates try to access elements defined by Magento elements and insert additional DOM content into them. However these elements are retrieved and used without checking if an actual element was found. This check should be added, as the module itself can not guarantee that an element can be found for the following expression $$('div.col2-set div.col-2 div.box-content')[0]. This PR adds a truthful check around the statement where a call is made on this element, preventing JS errors from occurring in cases where template changes have been made to the Magento templates in such a way that these identifiers have changed.

I've proposed a fix for this in #48, in general this is good practise as well. Check for validity before using the element.

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

$ modman update postnl-magento1
Already up to date.

Magento version 1.9.3.6, cache and compilation disabled.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

PostNL tries to erroneously show a delivery option/gekozen bezorgoptie on products that don't have any on the Sales details page of a product, thus breaking the rendering of the entire page:

A look at the HTML shows the page abruptly ending at:

<script type="text/javascript">
    sales_order_view_tabsJsTabs = new varienTabs('sales_order_view_tabs', 'sales_order_view', 'sales_order_view_tabs_order_info', []);
</script>
                    </div>
                    <div class="main-col" id="content">
                        <div class="main-col-inner">
                            <div id="messages"></div>
                            

    <div class="hor-scroll" id="postnl_delivery_option_info">
        <table cellspacing="0" class="form-list">
            <tr>
                <td class="label"><label>Gekozen bezorgoptie</label></td>
                <td class="value">
                    <strong>

The product doesn't have any shipping options as it is a digital subscription (through Adyen Subscriptions).

There are three PHP 7 incompatibilities on line line 99 of app/code/community/TIG/PostNL/Model/Core/System/Config/Backend/ValidateDefaultOption.php, caused by the introduction of the uniform variable syntax in PHP 7.0.

The line reads as follows:

$label = (string) $sections->$pathParts[0]->groups->$pathParts[1]->fields->$pathParts[2]->label;

In PHP 5.6 this line is interpreted as follows:

$label = (string) $sections->{$pathParts[0]}->groups->{$pathParts[1]}->fields->{$pathParts[2]}->label;

In PHP 7 indirect access to variables, properties, and methods are evaluated strictly in left-to-right order, which means that the line is interpreted as follows:

$label = (string) ((($sections->$pathParts)[0]->groups->$pathParts)[1]->fields->$pathParts)[2]->label;

This issue can be found using PHP compatiblity tools like php7cc or the PHP Compatibility Coding Standard for PHPCS.

hi, when is the next release planned for? I see several bugs squashed ... cant wait for update. thanks

Submitting issues through Github

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• [ x] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension. (version 1.15.7)

What is the purpose of your issue?

• [ x] Bug report (encountered problems with the TIG PostNL Magento extension)

We encountered a problem in the buspakje calculation process in particular methods
TIG_PostNL_Model_Core_Shipment _getIsBuspakje (line 4904) and TIG_PostNL_Helper_Data fitsAsBuspakje (line 1378)

We found that for orders with composite order items (one order item being the child of the other order item) the wrong order items are given to the method fitsAsBuspakje

At line 4925 in TIG_PostNL_Model_Core_Shipment::_getIsBuspakje we find the following code:

        $orderItems = array();
        foreach ($shipmentItems as $item) {
            $orderItem = $item->getOrderItem();

            if ($orderItem->getChildrenItems()) {
                $orderItems = array_merge($orderItems, $orderItem->getChildrenItems());
                continue;
            }

            $orderItems[] = $orderItem;
        }

        if (!$this->getHelper()->fitsAsBuspakje($orderItems)) {
            return false;
        }

The issue being that if the first shipment item contains the parent order item then its childItem gets added after which the second shipment item (which contains the child order item) will add the same order item to $orderItems.

In our case we have a product which fits 3 times in a "buspakje". The order consists of two order items one parent item with qty 1 and one child item with qty 2 (which is the underlying simple). Looking at the code above we end up with the scenario that $orderItems contains two orderItems namely the same order item is added to $orderItems twice. The method fitsAsBuspakje now thinks there are 4 simples and returns false.

Furthermore the method fitsAsBuspakje in version 1.15.7
contains the following code:

if ($item instanceof Mage_Sales_Model_Order_Item) {
                $qty = $item->getQtyOrdered();
                if (empty($qty) && $item->getParentItemId()) {
                    $qty = $item->getParentItem()->getQtyOrdered();
                }

which differs from version 1.15.4:

foreach ($items as $item) {
            /**
             * Get either the qty ordered or the qty shipped, depending on whether this is an order or a shipment item.
             */
            if ($item instanceof Mage_Sales_Model_Order_Item) {
                if ($item->getParentItemId()) {
                    $qty = $item->getParentItem()->getQtyOrdered();
                } else {
                    $qty = $item->getQtyOrdered();
                }

This difference is not just semantics but functional. So in version 1.15.4 this resulted in $qty being 1 but since the item is double we pass this code twice and the calculation thinks there are 2 simples in the order. In version 1.15.7 $qty is 2, but again the order item is double so the calculation thinks that there are 4 simples in the order which is incorrect.

Despite that 1.15.4 produces correct results I feel that it is not really correct to loop over the same order item twice. The proposed fix: dont double the order items when deciding which order items should be passed to the fitsAsBuspakje method

$shipmentItems = $this->getShipment()
            ->getItemsCollection();

        /**
         * @var Mage_Sales_Model_Order_Shipment_Item $item
         */
        $orderItems = array();
        foreach ($shipmentItems as $item) {
            $orderItem = $item->getOrderItem();

            if ($childrenOrderItems = $orderItem->getChildrenItems()) {
                /** @var Mage_Sales_Model_Order_Item $childItem */
                foreach ($childrenOrderItems as $childItem) {
                    $orderItems[$childItem->getId()] = $childItem;
                }
                continue;
            }

            $orderItems[$orderItem->getId()] = $orderItem;
        }

In this case $orderItems has unique values.

My test case is an order with a composite product type consisting of 2 simples (the same simples).
After the shipment has been created I tested with the following code

<?php
require_once __DIR__ . '/../app/Mage.php';
Mage::app('admin');

$shipment = Mage::getModel('sales/order_shipment')->load(3);
$postnlShipment = Mage::getModel('postnl_core/shipment')->setShipment($shipment)->save();

If I am doing something wrong or there is something wrong with my assumptions let me know and I will close the issue.

With kind regards

To Reproduce
Steps to reproduce the behavior:

• php 7.2 Openmage LTS

Expected result

• Extension does no direct calls to mcrypt

Actual result

• Mcrypt warnings in log and mcrypt usage => need to remove it from the code asap

Solution

• Update extension to not use mcrypt directly but rather mcryptcompat (magento core 194x) or openssl

OpenMage/magento-lts#129

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/Mage.php#L50

Screenshots

[28-Sep-2020 21:34:40 UTC] PHP Deprecated: Function mdecrypt_generic() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 133
[29-Sep-2020 09:35:24 UTC] PHP Deprecated: Function mdecrypt_generic() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 133
[29-Sep-2020 09:35:24 UTC] PHP Deprecated: Function mdecrypt_generic() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 133
[30-Sep-2020 09:33:04 UTC] PHP Deprecated: Function mcrypt_module_open() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 77
[30-Sep-2020 09:33:04 UTC] PHP Deprecated: Function mcrypt_enc_get_iv_size() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 86
[30-Sep-2020 09:33:04 UTC] PHP Deprecated: Function mcrypt_create_iv() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 86
[30-Sep-2020 09:33:04 UTC] PHP Deprecated: Function mcrypt_enc_get_key_size() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 90
[30-Sep-2020 09:33:04 UTC] PHP Deprecated: Function mcrypt_generic_init() is deprecated in lib/Varien/Crypt/Mcrypt.php on line 97

in app/code/community/TIG/PostNL/Block/Adminhtml/Sales/Order/Shipment/Create/ShipmentOptions.php date is converted to Amsterdam time but the same logic in app/code/community/TIG/PostNL/Model/Core/Shipment.php is not

see difference in $deliveryDate->setTimezone(new DateTimeZone('Europe/Amsterdam'))

    $deliveryDate = DateTime::createFromFormat(
        'Y-m-d H:i:s',
        $postnlOrder->getDeliveryDate(),
        new DateTimeZone('UTC')
    );
    
    $deliveryDate->setTimezone(new DateTimeZone('Europe/Amsterdam'));
    if ($deliveryDate->format('N') === '0' || $deliveryDate->format('N') === '1') {
        return false;
    }

Collega's probeerden ook, één lukte het wel via Internet Explorer. Mij niet in Chrome en I.E.

To Reproduce

1. use order grid
2. this is very slow and colums sometimes are not used

Expected result
Option to remoe all postnl joins from order grid (there are at least 5 new table joins)!!!

Actual result
Loading time from 8 secs to 1 sec aain

Workaround
None

** Please complete the following information**

• Magento version: M1.9.4
• PHP version: 7.2
• TIG PostNL version: 16.3 latest

** Fix and a quickwin**

1. Add new setting: hide all postnl columns in order grid = yes/no
2. get seting in observer
3. add 3 line logic

Tada! 7 seconds won per every request

     * @event adminhtml_block_html_before
     *
     * @observer postnl_adminhtml_ordergrid
     */
    public function modifyGrid(Varien_Event_Observer $observer)
    {

        if ($seting_to_skip_all_from_grid) {
            return $this;
        }

util.js:224 Google Maps JavaScript API warning: RetiredVersion https://developers.google.com/maps/documentation/javascript/error-messages#retired-version

Possible error? occurred shortly after upgrade other buspakjes work well only not 1

VIA GRID

[17-Dec-2018 16:49:06] WARNING: [pool shirts] child 6692 said into stderr: "#4 app/code/community/TIG/PostNL/Block/Adminhtml/Template.php(55): Mage_Core_Block_Template->_toHtml()"
[17-Dec-2018 16:49:06] WARNING: [pool shirts] child 6692 said into stderr: "#5 /var/..."
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to a member function format() on boolean in app/code/community/TIG/PostNL/Model/Core/Shipment.php:4945"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "Stack trace:"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#0 app/code/community/TIG/PostNL/Model/Core/Shipment.php(5065): TIG_PostNL_Model_Core_Shipment->_getIsBuspakje()"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#1 app/code/community/TIG/PostNL/Model/Core/Shipment.php(5016): TIG_PostNL_Model_Core_Shipment->_extractProductCodeForType(Array)"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#2 app/code/community/TIG/PostNL/Model/Core/Shipment.php(730): TIG_PostNL_Model_Core_Shipment->_getProductCode()"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#3 app/code/community/TIG/PostNL/Model/Core/Shipment.php(2099): TIG_PostNL_Model_Core_Shipment->getProductCode()"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#4 app/code/community/TIG/PostNL/Model/Core/Shipment.php(5576): TIG_PostNL_Model_Core_Shipment->hasCustomBarcode()"
[17-Dec-2018 16:51:15] WARNING: [pool shirts] child 27192 said into stderr: "#5 app/code/core/Mage/Core/Mo..."

SIMILAR when manual shipping

[17-Dec-2018 16:55:29] WARNING: [pool shirts] child 26582 said into stderr: "#5 app/code/community/TIG/PostNL/Model/C..."
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to a member function setTimezone() on boolean in app/code/community/TIG/PostNL/Block/Adminhtml/Sales/Order/Shipment/Create/ShipmentOptions.php:301"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "Stack trace:"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#0 app/design/adminhtml/default/default/template/TIG/PostNL/sales/order/shipment/create/shipment_options.phtml(72): TIG_PostNL_Block_Adminhtml_Sales_Order_Shipment_Create_ShipmentOptions->getFitsAsBuspakje()"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#1 app/code/core/Mage/Core/Block/Template.php(241): include('/var/www/html/s...')"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#2 app/code/core/Mage/Core/Block/Template.php(273): Mage_Core_Block_Template->fetchView('adminhtml/defau...')"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#3 app/code/core/Mage/Core/Block/Template.php(287): Mage_Core_Block_Template->renderView()"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#4 app/code/community/TIG/PostNL/Block/Adminhtml/Template.php(55): Mage_Core_Block_Template->_toHtml()"
[17-Dec-2018 16:55:31] WARNING: [pool shirts] child 27191 said into stderr: "#5 /var/..."

Hello,

When you add a Coupon Code during the checkout process. The selected delivery option is reset to the default. This can cause a customer to send to their own address, instead of the pickup point they actually wanted.

As far as I can tell this happens only with OneStepCheckout with "Enable discount code field" set to yes.

Steps to reproduce:

• Have PostNL and Idev OneStepCheckout installed.
• Enable PostNL delivery options
• Enable OneStepCheckout Enable discount code field
• Add a product to cart and go to checkout
• Fill out address fields
• Select a pick up point
• Apply a cart price rule

Expected result:
The previously selected pick up point is still selected

Actually result:
The default PostNL delivery option is selected. Which is the earliest time it can be delivered to the customers address.

We are seeing rare cases that wen processing say 20 shipments using the massaction that only 1 customer receives the default magento transactional shipping email (so I dont mean postnl track & trace email) but the default Magento "your order has been shipped email"

The last word "confirm" in the massaction signifies to us that this means "Confirm to customer" (as last step in the massaction)

Quick questions:

• is postnl extension surpressing default Magento email messages maybe?
• is this something we can influence via settings/config?

To Reproduce
Steps to reproduce the behavior:

1. Ship order using multi action (happens occiasional, see error report)

Expected result
Success or at least a warning that tells us WHAT is wrong, or WHICH order and why

Actual result
Logging
2020-05-15T11:55:03+00:00 ERR (3): Notice: Undefined offset: 0 in /public_html/app/code/community/TIG/PostNL/Model/AddressValidation/Cendris/Abstract.php on line 122
2020-05-15T11:55:03+00:00 ERR (3): Notice: Trying to get property 'city' of non-object in /public_html/app/code/community/TIG/PostNL/Model/AddressValidation/Cendris/Abstract.php on line 87
2020-05-15T11:55:03+00:00 ERR (3): Notice: Trying to get property 'streetName' of non-object in /public_html/app/code/community/TIG/PostNL/Model/AddressValidation/Cendris/Abstract.php on line 88

Workaround
None

Screenshots

Possible solution
Improve error report in browser to tell WHAT is wrong
Improve error report in logging for WHICH order this is occuring
Quick win, in the end we want to fix the order and continue

** Please complete the following information**

• Magento version: Magento 1.9.3.4
• PHP version: 7.2.0
• TIG PostNL version: 1.8.1, latest

Dear,

We encounter a problem on a Vanilla Magento 1 Enterprise installation with versie 1.12.3 of the PostNL module:

"deliveryOptions.js?v=1.12.3:5243 Uncaught TypeError: Cannot read property 'insert' of undefined"

It occures when selecting an other pickup point from the google maps popup. After selecting the location and clicking on 'Opslaan' the error occures and the popup won't close.
I could reproduce it on a clean Magento 1.14.1 Magento Enterprise installation.

It has something to do with the method "renderAsOsc()" that tries to insert html in an DOM object ('postnl_add_moment .option-list') that does excist in the Magento onepage checkout. It only excist in the onestepcheckout templates.

$$('#postnl_add_moment .option-list')[0].insert({ bottom : html });

Hi, omdat wij de dag niet kunnen garanderen stond in onderstaande plaatje "eerstvolgende mogelijkheid"

sinds kort staat hier een dag
en dit is niet de bedoeling
(en heeft 3 jaren ook niet zo gewerkt)

nu lijkt het

• Als ik alle dagen leeg maak in settings: alles deselecteer
• en daarna opsla
• dan staan de dagen toch weer geselecteerd daarna
• als je dan (iets anders) opslaat; dan overshrijf je onbewust toch weer de niet geselecteerde dagen

dit is een bug

Ext v1.15.7
Magento 194x
Php 7.2

Vraag: Heeft v1.15.7 support voor php 7.2? zo nee: wanneer

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.
• [ x] Feature request (request for a new functionality)
• [ x] Bug report (encountered problems with the TIG PostNL Magento extension)

Please add packingslip processing to the API (now it only supports the labels)

    /**
     * Get the shipping labels for the requested shipments.
     *
     * @param TIG_PostNL_Model_Core_Service_Shipment $serviceModel
     * @param int                                    $shipmentId
     * @param bool                                   $confirm
     *
     * @return array
     */
    protected function _getPackingSlips(TIG_PostNL_Model_Core_Service_Shipment $serviceModel, $shipmentId, $confirm = false)
    {
        /** @var TIG_PostNL_Helper_Data $helper */
        $helper = Mage::helper('postnl');

        /**
         * Get the PostNL shipment for this shipment ID.
         */
        $postnlShipment = $serviceModel->getPostnlShipment($shipmentId);

        /**
         * If the PostNL shipment does not exist, return an error.
         */
        if (!$postnlShipment || !is_object($postnlShipment) || !$postnlShipment->getId()) {
            $response = array(
                'order_id'    => null,
                'shipment_id' => $shipmentId,
                'label'       => null,
                'warning'     => null,
                'error'       => array(
                    array(
                        'entity_id'   => $shipmentId,
                        'code'        => 'POSTNL-0225',
                        'description' => $helper->__('No PostNL Shipment found for shipment ID #%s.', $shipmentId)
                    ),
                ),
            );

            return $response;
        }

        /**
         * Form the base response array.
         */
        $response = array(
            'order_id'    => $postnlShipment->getOrderId(),
            'shipment_id' => $postnlShipment->getShipmentId(),
            'label'       => null,
        );

        $errors = array();
        try {
            /**
             * Check whether we should also get the return labels based on the shop's configuration.
             */
            $printReturnLabels = $helper->canPrintReturnLabelsWithShippingLabels($postnlShipment);

            /**
             * Get the actual labels.
             */
            $labels = $serviceModel->getLabels($postnlShipment, $confirm, $printReturnLabels, $postnlShipment->isBelgiumShipment());

            /**
             * Get the label model which will convert the base64_encoded pdf strings to a single, merged pdf.
             */
            /** @var TIG_PostNL_Model_Core_Label $labelModel */
            $packingSlipModel = Mage::getModel('postnl_core/packingSlip');

            /**
             * Create the merged pdf.
             */
            $packingSlips = $packingSlipModel->createPdf($labels);

            /**
             * Base64_encode the merged pdf and add it to the response array.
             */
            $response['packingslips'] = base64_encode($packingSlips);
        } catch (TIG_PostNL_Exception $e) {
            $helper->logException($e);

            $code = $e->getCode();
            if (empty($code)) {
                $code = null;
            }

            $errors[] = array(
                'entity_id'   => $shipmentId,
                'code'        => $code,
                'description' => $e->getMessage(),
            );
        } catch (Exception $e) {
            $helper->logException($e);
            $errors[] = array(
                'entity_id'   => $shipmentId,
                'code'        => null,
                'description' => $e->getMessage(),
            );
        }

        /**
         * Add any warnings that may have occurred.
         */
        if ($serviceModel->hasWarnings()) {
            $response['warning'] = $serviceModel->getWarnings();
        }

        /**
         * Add any errors that may have occurred.
         */
        if (!empty($errors)) {
            $response['error'] = $errors;
        }

        return $response;
    }

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

When updating from 1.12.4 to either 1.15.0 or 1.15.1, the webshop will display a 500 error and the logs show:

2018/03/13 18:04:02 [error] 19069#0: *322553 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined method TIG_PostNL_Model_Resource_Setup::installTestApikey() in /home/secret/domains/secret.tld/public_html/app/code/community/TIG/PostNL/sql/postnl_setup/upgrade-1.12.4-1.13.0.php:59
Stack trace:
#0 /home/secret/domains/secret.tld/public_html/includes/src/TIG_PostNL_Model_Resource_Setup.php(394): include()
#1 /home/secret/domains/secret.tld/public_html/includes/src/Mage_Core_Model_Resource_Setup.php(437): TIG_PostNL_Model_Resource_Setup->_modifyResourceDb('upgrade', '1.12.4', '1.15.0')
#2 /home/secret/domains/secret.tld/public_html/includes/src/Mage_Core_Model_Resource_Setup.php(320): Mage_Core_Model_Resource_Setup->_upgradeResourceDb('1.12.4', '1.15.0')
#3 /home/secret/domains/secret.tld/public_html/includes/src/TIG_PostNL_Model_Resource_Setup.php(244): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 /home/secret/domains/secret.tld/public_html/includ" while reading response header from upstream, client: 77.170.114.153, server: secret.tld, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm-secret.sock:", host: "secret.tld"

Magento version: 1.9.3.6 (fully patched).
Cache disabled/cleared.
PHP version: 7.0.27

Omzetten Postcode checker heeft MEER implicaties dan enkel code

Dit had bij de RELEASE getoond moeten worden: je moet POSTNL bellen en op je API KEY een uitbreiding aanvragen ... hier gaat 1-2- dagen overheen (of langer!)

Kortom. Het is niet enkel een minor upgrade ... er zitten meer acties aan vast

Tip: toon tenminste een duidelijke warning API KEY invalid for postcode checker contact PostnL, want nu returned de API enkel false

• [X ] Feature request (request for a new functionality)

feature request

Would it be an idea to add some kind of page numbering? (suppose you mass print and drop the pile; or when there are multipage orders)?

/**
 * Create new page and assign to PDF object.
 *
 * @param  array $settings
 * @return Zend_Pdf_Page
 */
public function newPage(array $settings = array())

POSTNL-0247 is about table rates, not about postcode checker

exception 'TIG_PostNL_Exception' with message '{"errors":[{"status":"400","title":"Bad Request","detail":"API key not valid"}]}' and code 'POSTNL-0247' in app/code/community/TIG/PostNL/Model/AddressValidation/Cendris/Abstract.php:70

https://confluence.tig.nl/pages/viewpage.action?pageId=8553654

When for example loading the nearest pickup points from 's Hertogenbosch the javascript gets screwed due to the apostrophe in the cities name. See Git Diff below for a fix:

From cfbb201311902e6e05c1a9f39ae392b275a95918 Mon Sep 17 00:00:00 2001
From: Peter Keijsers <[email protected]>
Date: Tue, 4 Jul 2017 13:31:56 +0000
Subject: [PATCH] [BUGFIX] Escape cities starting with an apostrophe in the
 name

---
 .../onestepcheckout/deliveryoptions.phtml          | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/app/design/frontend/base/default/template/TIG/PostNL/delivery_options/onestepcheckout/deliveryoptions.phtml b/app/design/frontend/base/default/template/TIG/PostNL/delivery_options/onestepcheckout/deliveryoptions.phtml
index 9f3bd17..6b54cec 100644
--- a/app/design/frontend/base/default/template/TIG/PostNL/delivery_options/onestepcheckout/deliveryoptions.phtml
+++ b/app/design/frontend/base/default/template/TIG/PostNL/delivery_options/onestepcheckout/deliveryoptions.phtml
@@ -330,23 +330,23 @@
         var postnlDebugMode = <?php echo $this->isDebugEnabled() ? 'true' : 'false'; ?>;
 
         params = {
-            saveUrl            : '<?php echo $this->getUrl('postnl/deliveryOptions/saveSelectedOption', array('_secure' => true)) ?>',
-            timeframesUrl      : '<?php echo $this->getUrl('postnl/deliveryOptions/getDeliveryTimeframes', array('_secure' => true)) ?>',
-            locationsUrl       : '<?php echo $this->getUrl('postnl/deliveryOptions/getNearestLocations', array('_secure' => true)) ?>',
-            locationsInAreaUrl : '<?php echo $this->getUrl('postnl/deliveryOptions/getLocationsInArea', array('_secure' => true)) ?>',
+            saveUrl            : "<?php echo $this->getUrl('postnl/deliveryOptions/saveSelectedOption', array('_secure' => true)) ?>",
+            timeframesUrl      : "<?php echo $this->getUrl('postnl/deliveryOptions/getDeliveryTimeframes', array('_secure' => true)) ?>",
+            locationsUrl       : "<?php echo $this->getUrl('postnl/deliveryOptions/getNearestLocations', array('_secure' => true)) ?>",
+            locationsInAreaUrl : "<?php echo $this->getUrl('postnl/deliveryOptions/getLocationsInArea', array('_secure' => true)) ?>",
             postcode           : postcode,
             housenumber        : housenumber,
             street             : street,
-            country            : '<?php echo $this->escapeHtml($_country); ?>',
-            city               : '<?php echo $this->escapeHtml($_city); ?>',
-            deliveryDate       : '<?php echo $this->escapeJavascriptHtml($_deliveryDate); ?>',
-            pickupDate         : '<?php echo $this->escapeJavascriptHtml($_pickupDate); ?>',
+            country            : "<?php echo $this->escapeHtml($_country); ?>",
+            city               : "<?php echo $this->escapeHtml($_city); ?>",
+            deliveryDate       : "<?php echo $this->escapeJavascriptHtml($_deliveryDate); ?>",
+            pickupDate         : "<?php echo $this->escapeJavascriptHtml($_pickupDate); ?>",
             imageBaseUrl       : baseUrl,
             fullAddress        : fullAddress,
             cutOffTimes        : {
-                weekday: '<?php echo $_weekdayCutOffTime; ?>',
-                sunday: '<?php echo $_sundayCutOffTime; ?>',
-                sameday: '<?php echo $_sameDayCutOffTime; ?>'
+                weekday: "<?php echo $_weekdayCutOffTime; ?>",
+                sunday: "<?php echo $_sundayCutOffTime; ?>",
+                sameday: "<?php echo $_sameDayCutOffTime; ?>"
             }
         };
 
-- 
2.7.4.1.g5468f9e

I made a separate ticket for this.

Situation
Unselect all delivery days
Click save

Actual
3 days are selected

Expected
No days are selected

When analysing the Magento system.log of a production system that runs the TIG_PostNL module (v1.15.3), I found dozens of occurrences (each day) of the following PHP notice:

Notice: Undefined property: stdClass::$Barcode  in /path/to/magento/app/code/community/TIG/PostNL/Model/Core/Cif.php on line 522

The line read as follows:

if ($shipment->Barcode === $barcode) {

This notice can be fixed by making this check more robust, for instance by adding an isset:

if (isset($shipment->Barcode) && $shipment->Barcode === $barcode) {

Or by adding an isset first and throw an exception:

if (!isset($shipment->Barcode)) {
    throw new TIG_PostNL_Exception(
        Mage::helper('postnl')->__('Invalid shippingStatus response: %s', "\n" . var_export($response, true)),
            'POSTNL-0055'
    );
}

Sorry but do think this is another issue?

Code comments states Letter box parcels cannot be delivered on mondays or tuesdays.

Then a little further in the code one check for day of the week 0 or 1 (is this not Sunday and MOnday?)

And then a little further one sets the delivery date to the next Tuesday

Should the comment maybe mean Letter box parcels cannot be delivered on Sundays and Mondays.

/**
 * Check if the current confirm and delivery dates are valid for letter box parcel shipments. If not, modify these
 * dates accordingly.
 *
 * @return $this
 */
protected function _checkBuspakjeDates()
{
    /**
     * Get the current delivery date.
     */
    $deliveryDate = $this->getDeliveryDate();
    $deliveryDate = DateTime::createFromFormat('Y-m-d H:i:s', $deliveryDate, new DateTimeZone('UTC'));

    /**
     * Letter box parcels cannot be delivered on mondays or tuesdays.
     */
    if ($deliveryDate->format('N') === '0' || $deliveryDate->format('N') == '1') {
        /** @var TIG_PostNL_Helper_Date $helper */
        $helper = $this->getHelper('date');

        /**
         * Modify the delivery date to the next tuesday.
         */
        $deliveryDate->modify('next tuesday ' . $deliveryDate->format('H:i:s'));

        $this->setDeliveryDate($deliveryDate->format('Y-m-d H:i:s'));

        /**
         * Also modify the confirm date accordingly.
         */
        $confirmDate = $helper->getShippingDateFromDeliveryDate($deliveryDate, $this->getStoreId());

        $this->setConfirmDate($confirmDate->format('Y-m-d H:i:s'));
    }

    /**
     * Letter box parcels have no expected delivery times.
     */
    $this->setExpectedDeliveryTimeStart(null)
         ->setExpectedDeliveryTimeEnd(null);

    return $this;
}

De group_concat in sales_order grid veroorzaakt veel problemen met andere extensies die ook iets willen doen met de grid. Het is ook niet de beste manier, want het extend de collectie wel, alleen past hem dusdanig aan door een group by toe te voegen; terwijl men normaal 1 of meerdere kolommen joint obv v/d primary id

Een aantal oplossingen

• subquery in een view?
• subquery in het select statement zetten als nested subquery (meest net dacht ik)
• zoiets als in deze link: https://www.diffchecker.com/KU4WvVee (enkel voorbeeld)
• subquery in een eigen model waardoor het resultaat van de postnl subquery gejoined wordt voordat de join plaatsvindt en niet daarna

Hope it helps

Hi,

i'm experiencing problems when scanning the shipping label bar codes, ready for transport.
Each package needs 5-10 attempts to get noticed by the scanner..

By default my Dutch packages have shipping labels in "lansdcape" mode
I think the bar-codes on the labels are too small / narrow, they could easily be 20% bigger..
to improve "scan-ability".

Note: Ink spread is a common cause an can be improved by this..

See examples and or testprint the examples:

The portrait mode options (mostly used for shipping abroad) could also be improved due to better alignment, although options are marginal..

(setting the printer to print at 120% doesn't work, as other elements are also affected, and being cut off. The barcode area has enough room for imrovement)

• Printer: Bixolon slp dx420 with 10cm by 15cm shipping labels

Best

A

Upgrade to M1934 cannot continue in checkout

Is the PostNL a postnl form? I dont think this comes from template does it?

stuck on this screen

I understand there are Some small issues. And does pickup points in Belgium work already?

Main question. When is The next official release?

Submitting issues trough Github

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

Explanation of your issue in arbitrary form goes here. Please make sure the [description is worded well enough to be understood]. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

TIG supportdesk

On Github we will respond in English even when the question was asked in Dutch.

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Feature request (request for a new functionality)
• Bug report (encountered problems with the TIG PostNL Magento extension)
• Extension support request (request for adding support for a new extension)
• Other

If the purpose of your issue is a bug report

The two lines with <li class="clearfix"> on line 58 and 70 of app/design/frontend/base/default/template/TIG/PostNL/address_validation/onestepcheckout/postcod_check.phtml causes duplicate <li> opening tags as the opening tag is already outputed by billing_fields.phtml (in the same folder).

I will prepare a PR with a fix.

Submitting issues trough Github

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• [ X ] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• [ X ] Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

We're getting the following error when clicking on the "PostNL - Print Verzendlabel" button:

Er is een fout opgetreden tijdens het verwerken van uw verzoek:Validation failed for shipment: 3STOTA646783173, Messages: 3STOTA646783173: {[13804] Insurance value is invalid}

• We've first created an invoice for the order,
• Then we're creating a shipment
• We're trying to print the shipping label

Explanation of your issue in arbitrary form goes here. Please make sure the [description is worded well enough to be understood]. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

TIG supportdesk

On Github we will respond in English even when the question was asked in Dutch.

This causes an undefined index of "locationCode" in TIG_PostNL_DeliveryOptionsController, which on strict error reporting throws a Notice, resulting in a catch that will show "invalid_data" in the console.log.

Fix: #1

Oh, and the tests fail on CI because you're trying to run PHP7, but it's not installed

When having lots of orders in Magento the sales grid tends to get slow together with this module.
Upon sorting a temporary table gets created due to a different group/order column combination.

Queries run op to 12.5 seconds when just viewing the basic order grid of 20 results (no filters applied)

SELECT `main_table`.*, IF(`postnl_shipment`.`confirm_date`, `postnl_shipment`.`confirm_date`, `postnl_order`.`confirm_date`) AS `confirm_date`, IF(`postnl_shipment`.`delivery_date`, `postnl_shipment`.`delivery_date`, `postnl_order`.`delivery_date`) AS `delivery_date`, `postnl_join_order`.`shipping_method`, `postnl_join_payment`.`method` AS `payment_method`, `postnl_join_shipping_address`.`country_id`, `postnl_order`.`is_pakje_gemak`, `postnl_order`.`is_pakketautomaat`, `postnl_order`.`type` AS `delivery_option_type`, `postnl_order`.`options`, group_concat(`postnl_shipment`.`confirm_status` ORDER BY `postnl_shipment`.`created_at` DESC SEPARATOR ",") AS `confirm_status`, group_concat(`postnl_shipment`.`shipping_phase` ORDER BY `postnl_shipment`.`created_at` DESC SEPARATOR ",") AS `shipping_phase`, group_concat(`postnl_shipment`.`shipment_type` ORDER BY `postnl_shipment`.`created_at` DESC SEPARATOR ",") AS `shipment_type`, group_concat(`postnl_shipment`.`product_code` ORDER BY `postnl_shipment`.`created_at` DESC SEPARATOR ",") AS `product_code` FROM `sales_flat_order_grid` AS `main_table`
 INNER JOIN `sales_flat_order` AS `postnl_join_order` ON `main_table`.`entity_id`=`postnl_join_order`.`entity_id`
 LEFT JOIN `sales_flat_order_payment` AS `postnl_join_payment` ON `main_table`.`entity_id`=`postnl_join_payment`.`parent_id`
 LEFT JOIN `sales_flat_order_address` AS `postnl_join_shipping_address` ON `main_table`.`entity_id`=`postnl_join_shipping_address`.`parent_id` AND `postnl_join_shipping_address`.`address_type`='shipping'
 LEFT JOIN `tig_postnl_order` AS `postnl_order` ON `main_table`.`entity_id`=`postnl_order`.`order_id`
 LEFT JOIN `tig_postnl_shipment` AS `postnl_shipment` ON `main_table`.`entity_id`=`postnl_shipment`.`order_id` GROUP BY `main_table`.`entity_id` ORDER BY created_at DESC LIMIT 20;

These times are insane and unworkable for a production environment. A fix for this is to add virtual columns to the sales/order_grid entity so all values are indexed in the table instead. That way all these joins become unnecessary as well as for the group by.

Looks like the 1.15.1 update breaks the Google maps Api.

I get the following error in the console.

Google Maps API warning: RetiredVersion https://developers.google.com/maps/documentation/javascript/error-messages#retired-version```

2019-08-16T12:57:46+00:00 ERR (3): Notice: Undefined offset: 1 in app/code/community/TIG/PostNL/Model/Adminhtml/Observer/OrderGrid.php on line 775

• [x ] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

• Feature request (request for a new functionality)
• [ x] Bug report (encountered problems with the TIG PostNL Magento extension)
• Extension support request (request for adding support for a new extension)
• Other

In het hieronder genoemde bestand wordt altijd ervan uit gegaan dat het geselecteerde land Nederland is. Echter als ik een ander land selecteer, bijvoorbeeld Frankrijk, krijg ik een validatie foutmelding dat de ingevulde postcode niet klopt en dat er nog 2 letters toegevoegd moeten worden. Alleen Frankrijk heeft helemaal geen letters in zijn postcode.

app/design/frontend/base/default/template/TIG/PostNL/address_validation/validate.phtml

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

running version 0.15.7, not going to upgrade since the work-around works enough for me.

What is the purpose of your issue?

• Feature request (request for a new functionality)
• Bug report (encountered problems with the TIG PostNL Magento extension)
• Extension support request (request for adding support for a new extension)
• Other

If your issue contains security sensitive information

** If your issue may contain sensitive information, please send us an e-mail at [email protected].**

• This issue does not contain any security sensitive information

Please describe the precise steps to reproduce your issue:

• Enable postcode check for NL
• Have 2 address lines
• Add order to UK with:
  • address line 1: 16 SomeSteet
  • address line 2: A06 SomeBuilding
• Expected result
  • i can still print a label
• Actual result (Please provide screenshots if applicable)
  • ERROR in logs: Invalid housnumber supplied: A06 SomeBuilding' and code 'POSTNL-0059'
• Workaround (If available, otherwise just write "None")
  • use 3 fields per adres and split manually

TIG support

• Please ask your question in English to ensure that your issue can help other people internationally. Nevertheless we will respond in English.
• If you want support with installing the PostNL extension, please contact [email protected] for free support, or contact us directly at [email protected] for paid support plans.

FYI in logs

2017-08-21T12:11:51+00:00 ERR (3): Notice: Undefined offset: 284 in app/code/community/TIG/PostNL/Model/Core/Cif.php on line 1785

maybe helps

M 194xx
PostnL version from 3-6-19, latest

Current

• cannot change shipping image on storeview

Expected

• change shipping image on storeview
• in line with Magento default invoice logo that can! be set on storeview level

(now we have 1 store that just cant show its logo and instead shows the image of another store -- this is unexpected)

TIG_PostNL_Model_Core_Label::_addPdfTemplate

case TIG_PostNL_Model_Core_Shipment_Label::LABEL_TYPE_LABEL: case TIG_PostNL_Model_Core_Shipment_Label::LABEL_TYPE_BUSPAKJE: case TIG_PostNL_Model_Core_Shipment_Label::LABEL_TYPE_BUSPAKJEEXTRA: case TIG_PostNL_Model_Core_Shipment_Label::LABEL_TYPE_RETURN_LABEL: $position = $this->_getLabelPosition($labelType, $this->getLabelCounter()); $this->increaseLabelCounter(); break;

Default behavior we faced that for (LABEL_TYPE_LABEL:) parcel count >= 3 it creates dupps for labels on second page instead adding new pages for new labels.

Workaround thats working for our side is:
$this->increaseLabelCounter(5);
Which adds new page for next labels(>=3) w/o dupps.

Selecting Orders in Grid => Massaction ShipConfirmSend returns orders in different order

• [ X] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.
• [ X] Extension support request (request for adding support for a new extension)

we mass print shipping labels from the order grid

If we select orders
4
2
1
3

then the shipping statements in PDF are returned in a different order

It is important to keep them in the same order for faster processing

we package order 4, then 2, then 1 then 3

and add the slips in the same order

how can the Postnl extension respect the order in which the orders are selected??

Submitting issues trough Github

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

I encountered an issue where a customer (from belgium) could not change his/her address in the customer/address/edit/ page.

the reason: postcodecheck.js was looking at harcoded shipping:country_id which does not exist on this page.

After examination of the code i noticed that at line 100 of /master/skin/frontend/base/default/js/TIG/PostNL/postcodecheck.js there is a check if the variable countryField is null and on line 102 the code tries to use this variable.

Next on line 106 the code is looking at the hardcoded element identifier.

I currently fixed this as follows:

diff --git a/skin/frontend/base/default/js/TIG/PostNL/postcodecheck.js b/skin/frontend/base/default/js/TIG/PostNL/postcodecheck.js
index 2e2d1d4..4bb6756 100755
--- a/skin/frontend/base/default/js/TIG/PostNL/postcodecheck.js
+++ b/skin/frontend/base/default/js/TIG/PostNL/postcodecheck.js
@@ -97,13 +97,13 @@ PostnlPostcodecheck = new Class.create({
 
         var postcodeCheck = this;
 
-        if($(countryField) === null || $(countryField).hasClassName('country_hidden') == false) {
+        if($(countryField) !== null || $(countryField).hasClassName('country_hidden') == false) {
 
             $(countryField).observe('change', function() {
                 // When using the billing as shipping the country value of shipping is not updated and always stays
                 // on the default country selected in the configuration.
                 countryId = this.getValue();
-                $('shipping:country_id').setValue(countryId);
+                $(countryField).setValue(countryId);
                 $('postnl_address_error_' + addressType).hide();
                 $('postnl_address_missing_' + addressType).hide();
                 $('postnl_address_invalid_' + addressType).hide();

Thanks in advance

TIG supportdesk

On Github we will respond in English even when the question was asked in Dutch.

In app/code/community/TIG/PostNL/Helper/Data.php

$timeZone = Mage::getStoreConfig(Mage_Core_Model_Locale::XML_PATH_DEFAULT_TIMEZONE, $storeId);

It's creating issues. Becuase it's not getting the path from Mage_Core_Model_Locale and get empty.

If you define : const XML_PATH_DEFAULT_TIMEZONE = 'general/locale/timezone';

then it's working fine.

TimeZone is given in backend.
Can you check on this?

• [x ] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento
• [ x] Bug report (encountered problems with the TIG PostNL Magento extension)

Description of your issue, suggested solution and other information

Hello We have encountered an issue with the latest (1.15.1) version of the extention
The issue is that our client cannot ship an old order, and with old I mean an order that was created when the previous version of the extention was installed (in our case this was in the 1.12.x range)

workflow: Go to magento backend get an older order and create a new shipment, fill the relevant fields and save the shipment. Result: blank page.

Here is the relevant part of the corresponding stack trace (I starred out sentitive data):
*****.app/code/community/TIG/PostNL/Helper/ProductCode.php(47):mageCoreErrorHandler(4096, 'Argument 1 pass..., 47, Array)

#1 *******************public_html/vendor/tig/postnl-magento1/app/code/community/TIG/PostNL/Model/Core/Shipment.php(1249): TIG_PostNL_Helper_ProductCode->getDefault(false, 'STORE_ID', 'domestic')

The issue is TIG_PostNL_Helper_ProductCode->getDefault(false, 'STORE_ID', 'domestic') getDefault is called with false in the first parameter.

Here is the corresponding function declaration in TIG_PostNL_Helper_ProductCode:
public function getDefault(
TIG_PostNL_Model_Core_Order $postnlOrder,
$storeId,
$shipmentType,
TIG_PostNL_Model_Core_Shipment $shipment = null
)

This is called from: Model_Core_Shipment line 1249: also see:

if ($this->hasDefaultProductCode()) {
return $this->_getData('default_product_code');
}
$storeId = $this->getStoreId();
$shipmentType = $this->getShipmentType();

    $postnlOrder = $this->getPostnlOrder();
    $productCode = $this->getHelper('productCode')->getDefault($postnlOrder, $storeId, $shipmentType);

The method getPostnlOrder() can return false which seems to happen in our case. However the method definition of getDefault( .. ) does not take that into account. When checking the code of getDefault I found various checks to check if $postnlOrder is indeed an object if ($postnlOrder) { ... } etc

Suggested fix: declare getDefault as
public function getDefault(
$postnlOrder,
$storeId,
$shipmentType,
TIG_PostNL_Model_Core_Shipment $shipment = null
)

Or change the order of params and let $postnlOrder have a default value, which seems to have more impact.

I am not sure if the case getPostnlOrder returns false is even an intended use case But I cannot be the judge of that. It could be that this is an edge case and that you will not be able to reproduce this however the incompatibility in code is quite clear.

With kind regards, Edwin Jacobs

• [ X] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.
  [X ] Feature request (request for a new functionality)

Currently the packingslip LABEL PART has the following info in the upper left corner. When one runs a multishop the BV name can respresent many websites. Can we add a variable parser to this confir field to allows us to add storename or storecode this way it is more clear from which store a customer ordered?

The Below then becomes

80000125
Afzender: Business Name B.V.
Street 1
PC1000aa
ETC

80000125
Afzender: Business Name B.V. Mysupersite.com
Street 1
PC1000aa
ETC

Request. Creating shipping return label for customer using our account.

I understand we can request an amtwoordnummer. But this is not the same as offering a return label. People can also use it when they want.

Practical. We would like to be able to create a shipping label in the backend resulting in a pdf that we can send to the customer (so they can return to us) / without an antwoordnummer

Submitting issues trough Github

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

Explanation of your issue in arbitrary form goes here. Please make sure the [description is worded well enough to be understood]. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

TIG supportdesk

On Github we will respond in English even when the question was asked in Dutch.

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• Feature request (request for a new functionality)
• Bug report (encountered problems with the TIG PostNL Magento extension)
• Extension support request (request for adding support for a new extension)
• Other

If your issue contains security sensitive information

** If your issue may contain sensitive information, please send us an e-mail at [email protected].**

• This issue does not contain any security sensitive information

Issue

In the file app/code/community/TIG/PostNL/etc/config.xml there is a field with an invalid http address. This can be found on line 1035 and contains: https:://api-sandbox.postnl.nl/shipment/checkout/

Hi
I want to submit issue with printing German combilabel. There are possibilities that label is created without DEPOT nr. The problem can be that address is not correct and POSTNL cannot resolve DEPOT nr. But at the same time the system create the label. As far I know the DEPOT nr is required on the shipping be delivered. If DEPOT is missing POSTNL is simple retuning back the shipment (return process take 2 weeks buu).
I had discussion with tech support POSTNL and they told me, that system required that street name and house number to exist. Then DEPOT name can be resolved. In case DEPOT name is not resolved it means address is not correct. He told me that they can do nothing to help us. We need to validate address not them. So I am thinking now, why the label is create in case address is wrong. I think in the moment system cannot resolve DEPOT name, it should return error. This can be done in similar way to the error: House nr not correct. This error occurred if you want to create label to the address where there is no space between street name and house nr. Unfortunately POST NL support told me that it is not their problem and they cannot help.
We have some cases that customer provide company name in address field together with street name (it happen a lot for amazon DE) In this case we have label without DEPOT. Amazon if created in the way that connector AMZON <->magento cannot discover when customer fill the street name or company name. So the only solution is HARD. We need manual process of the shipping for amazon, cannot run auto process I need to verify all orders from amazon.

Proposition of the solution:
As far I know DEPOT name is required to be on the shipping label. So in case system cannot resolve DEPO name there should be no label just ERROR. Can you do something about it, please? Please see example of the label without DEPOT nr:

Thanks!
Piotr

Submitting issues trough Github

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: https://tig.nl/postnl-magento-extensies/

Issues with outdated version will be rejected.

• [ x] I've verified and I assure that I'm running the latest version of the TIG PostNL Magento extension.

What is the purpose of your issue?

• [x ] Bug report (encountered problems with the TIG PostNL Magento extension)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

We are using GoMage LightCheckout. On the checkout page if an user is login, and switch between his billing/shipping address (event on #billing-address-select checkout.loadAddress(...)) then the postcode checker is not working anymore. Working fine when the page is reload, but not just after you switch addressese.

Hope you can help us with that issue.

Thank you!

TIG supportdesk

On Github we will respond in English even when the question was asked in Dutch.