sylvain68

Hi @champsupertramp,

Many thanks for your prompt answer and this filter hook.

I will come back to you to confirm that it is working properly.

Thanks again and have a great day!

Sylvain

Hi @preciousomonze,

Yes I do ??!

Thanks again,

Sylvain

Hi @preciousomonze,

I hope you are doing well.

I come back to you to thank you for the different updates of the plugin. I finally took the time to install the last version 1.3.0.

Thank you very much for the fix related to this topic, the translations, the new filter hooks and maybe some other improvements in the future ??!

Wish you an excellent day.

Sylvain

Merci pour vos réponses rapides, c’est parfait !

Je passe en résolu et ferai la mise à jour plus tard dans la journée.

Sylvain

Hello @syammohanm,

I no longer have this warning.

But I can’t tell you that it’s the latest version of the plugin that fixes this. Indeed, I already had no more this warning in my logs before updating the plugin.

Maybe there was a conflict with another plugin that I would have updated in the meantime or with an option of your plugin (without knowing which one) that I was using previously, that I would have disabled in the meantime and that was generating this warning.

Other users may be able to tell you more.

Thanks for your plugin and feedback anyway!

Sylvain

Hello,

Thank you again for your responsiveness.

In fact, I’m not asking for any extra features. My request is only to help you improve the ergonomics and the current behavior of your plugin to avoid address errors during the ordering process.

If you read my previous post again, you’ll see that I finally think that you should indeed call the API systematically (and not only at zip code change as I initially suggested, again sorry).

I understand that your plugin is free, thank you for that, the help I’m trying to give you is as well. I understand that improving your plugin requires some analysis and development work. But you should know that there is a solution to the problem I have taken the time to describe to you.

Indeed, WooCommerce saves natively some address fields including the zip code and the city, even for shopping carts without login. In particular, this makes it possible to update shipping methods and costs (shipping calculator too). You can check this quite easily by simulating an order and navigating from the order page to the shopping cart page (and vice versa).

So when the order page is loaded (or the account address page), you should check that the city normally pre-filled by WooCommerce is part of the list of cities returned by the API for the given zip code. If this is the case, you can select this city from the list by default. Otherwise, none should be selected, which should generate an error if the customer tries to validate the order without a city. This would prevent the city selection list from opening when it is not necessary and would correct the post-navigation inconsistency I mentioned earlier.

Have a nice day. Of course I’m available if you need clarification.

Best Regards,
Sylvain

Hello,

Thank you for your prompt answer and fix.

Indeed the list of cities no longer opens unnecessarily. However, after performing several tests, other problems now seem to be present.

Example #1:
A visitor comes for the first time on the order page. He selects his postal code “19500” (France) then his town “Meyssac”. He continues to fill out the form but decides to return to the shopping cart page (to change the quantity of items for example). On the shopping cart page you can see that the address has been saved (“Meyssac” appears in the shipping line of the cart_totals table). However, when he returns to the order page, the postal code is still present but the city is no longer there. Moreover his city no longer appears in the selection list (although the postal code is still present). The visitor must therefore remove the postal code and enter it again to see his city.

Example #2:
The logged-in customer makes new purchases. When he is on the order page, he decides to change his address: 75000 PARIS (instead of 19500 Meyssac). He forgot to add an item and therefore returns to the shopping cart page. There, you can see that the new address has been taken into account (cart_totals). But when he wants to finalize his order 75000 MEYSSAC is now present in the form (wrong address, the correct one is 75000 PARIS).

On the other hand, sorry, but there’s one thing I didn’t think of when I advised you not to call the API until the zip code has changed. After the address is loaded, if a user just wants to replace his city with another nearby city (sharing the same zip code), he will have to remove his zip code to enter it again. Only after that he will be able to see the other cities.

Finally, one way to solve this problem might be to systematically call the API and if a saved city is already present in the form field and it exists in the list, to select it automatically. That will probably also solve the problem described above (examples #1 and #2).

What do you think?

Hope this helps.

Best Regards,
Sylvain

Just something I forgot to tell you about. The live() method has been deprecated from jQuery 1.7 (and removed from 1.9). It is now advised to use on() instead.

@oreedessavons : Pour information nous avons réussi à imprimer nos étiquettes à force de réessayer…

Il y a effectivement un message indiquant une maintenance en cours suite à des problèmes techniques sur le site de Colissimo Entreprise.

Bon courage !

Bonjour,

Je confirme, nous rencontrons de nouveau le même problème aujourd’hui.

Erreur : L’étiquette aller n’a pas été générée : OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104

Très embêtant en effet !

Hi @zorem,

Thanks for your answer.

I think your two current options are very convenient for people who want to easily add shipment tracking information in their invoices and packing slips. But I would also understand if you want to outsource them and refocus your plugin on its essential features. Not an easy choice.

Actually if you didn’t get a lot of feedback like mine you could leave those options for which I think there was a initial demand from users? And slightly modify the “if” conditions of your code so that it only affects the two only templates of the free version of PDF Invoices (invoice & packing-slip).

I’ll let you mark this topic as resolved if you wish, no problem ??

Best Regards,
Sylvain

Hi @zorem,

A credit note invoice is the document issued by the seller to the buyer after a refund. From a business accounting point of view, it provides justification for the refund that has been made.

A proforma invoice is like an estimate (quote). It is usually more valuable to a company because it accurately reflects the invoice that will be issued later.

These two documents are provided in the premium extension of WooCommerce PDF Invoices.

By default the shipment information doesn’t seem to appear in the refund invoices (credit note), which is fine for me. For my curiosity I just wanted to know why I had to remove the action hook only for the quotes (proforma).

I noticed indeed that it is your plugin that adds the tracking information in the documents generated by WC PDF Invoices (function “tracking_display_in_invoice”). I just wanted to warn you that there are other document template ids transmitted by the “wpo_wcpdf_before_order_details” hook: normally “proforma” and “credit-note”. If you look at your function, you will see that if the template is not “invoice” or “packing-slip”, the processing continues and the tracking information is added in the other document types:

		$wc_ast_show_tracking_invoice = get_option('wc_ast_show_tracking_invoice');
		$wc_ast_show_tracking_packing_slip = get_option('wc_ast_show_tracking_packing_slip');
		if($template_type == 'invoice' && !$wc_ast_show_tracking_invoice){
			return;
		}
		if($template_type == 'packing-slip' && !$wc_ast_show_tracking_packing_slip){
			return;
		}

Hope this helps,

Sylvain

Of course, your plugin is for me the best, so it’s been done here for almost a year ??!

Many thanks @zorem, I confirm that.

Really great, more time saved for shop managers ??

Have a nice day,
Sylvain

Hi @zorem,

It seems that the field focus feature has been removed in the meantime, isn’t it?

I am asking myself if it is linked to the 2.9.8 rollback.

Thanks in advance.

Best Regards,
Sylvain