News:

Support the VirtueMart project and become a member

Main Menu

One order, two incomplete pdfs/emails

Started by iWim, September 05, 2014, 16:07:33 PM

Previous topic - Next topic

iWim

Hey,

When a customer places an order he receives two emails with the same order number.
The emails are almost the same.

One email is an invoice displaying the shipping and payment method.
The other email is an invoice that does not display the shipping and payment method.
Both do display the price of both methods.

Both emails have a pdf with the invoice attached, but both do not display the shipping and payment method.

When I change  the status in the order list from Pending to Confirmed(Paid) VM sends 1 email. The invoice in the email has status Confirmed (Paid) with shipping and payment method displayed. However the attached pdf invoice has status Pending and does not display shipping and payment method.

Joomla! 2.5.24
VM 2.6.10

If you need more info, let me know.

Thank you.
Wim

slammy

#1
Hi iWim,

I am just doing test´s with jml 2.5.24 and vm 2.6.10. Can confirm your issue, it is exactly the same with my installation. Have no clue how to handle. will report if I find a solution.

Update: Did test it with 2.6.8c -> it remains the same. When I set the orderstate manually after double entry-confirmations, emails coming in normal one time ...

carolmarkerson

Hi I think I had your exact or very similar issue. It's to do with the Pending status.

Part of my problem was the database with the order states was outdated I think from a previous migration and it didn't have the 'Confirmed by shopper' status. So replaced it with a fresh one.
My second step was that when I had emails and Invoices generated on pending status which I removed and replaced with the Confirmed by shopper status. I did this both in the Configuration->Checkout as well as my payment method.
Not ideal but what the status read wasn't greatly important to me and I believe its possible to change it with a language override.

I hope this helps  ;)

slammy

Hi carol,

Quote from: carolmarkerson on September 08, 2014, 04:41:55 AM
Part of my problem was the database with the order states was outdated I think from a previous migration and it didn't have the 'Confirmed by shopper' status. So replaced it with a fresh one.
pls can u export with phpmyadmin e.g your orderstate table into *.xls so I take a look at the structure and entrys? I am a bit confused about your orderstate 'confirmed by shopper' - I don´t have such one ...
regards jens 

slammy

#4
can someone clarify what is meant with 'confirmed by shopper' Status - I don´t have such ...

jenkinhill

Kelvyn
Lowestoft, Suffolk, UK

Retired from forum life November 2023

Please mention your VirtueMart, Joomla and PHP versions when asking a question in this forum

slammy

#6
Hi Jenkinhill,

thx for your hint. I don´t get it why a missing status leads to double-mailing without partly shipment and payment information. Pls could you give me the original letter status code and precise name entry from database?
Will the adding of this status solve the double mail issue? thx for your help.
best regards jens

UPdate: order Status letter code is 'U' and Name is 'confirmed by shopper', adding these entries in database does not solve the double incomplete mailing ...

jlover


Milbo

Just set for the creation of invoice "confirmed"
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

iWim

Hey Milbo,

I'll try that.
Though we set sending invoices also to pending because customers can pay through a simple banktransfer. This way they receive the invoice even though they haven't paid yet.

The other issue of incomplete pdfs is still open:
The shipping and payment method is missing in the pdf.

I have added an attachment which displays (a part of) an invoice. And I added some notes for you.

This is the pdf invoice that is sent with the e-mails or that can be downloaded through the orderlist.

Also no matter what the status of the order is (even Shipped) the status in the pdf remains Pending.

I help with 3 shops and all 3 have this issue.
If I go back in my logs, I would say it started after the update from VM 2.6.6 to VM 2.6.8.
Invoices before the update are complete.

Current specs:
Joomla 2.5.27
VM 2.6.10

Thank you.
Wim

[attachment cleanup by admin]

Milbo

then the right setting is confirmed by shopper, not pending.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

slammy

#11
I needed some time to solve the issue with the double-mailing on my installation, which was TODAY - JUCHUU. Yet I am on vm_sr 2.6.12_2 and jmlo 2.5.27.
I post my solution here, because other may profit from my research and test but I have to say, if I would have read carolmarkersons post in detail - there was the solution ... so thank u carol!

I think the double-mailing issue started with my installation on vm 2.6.8c. After that update I´ve had the above described double and partly incomplete mailing when ppl were ordering (same order).

It´s important to understand for my story that I came from a migration from vm1 and did the following after it: While started with migrated vm2-shop I remember, that I once deleted at vm-admin-BE one of those predefined orderstates named "confirmed by shopper" and I think it was with STATUS-CODE U in origin. I did not understand the meaning of confirmed by shopper and for what I should use it. For me I used the status-code P and renamed the origin from pending to order-entry-confirmation or in german "Bestelleingangsbestätigung". For me, this state should be first notification for shopper and vendor for all incoming orders and it worked this way, because we used a lot of payments which proceed after delivery, for e.g pay on delivery in german "Nachnahme", so pending in my understanding, stands for "user-confirmed but not confirmed from vendor". The next step - because I both sell things on stock and things I have not on stock which I order on demand - was to proof the availabiltys and if necesssary by on-demand-article-orders the stocklevel from the supplier. If the proof was successful I confirmed the orders with with an extra state which I call order-confirmation or in german "Auftragsbestätigung", besides this is the moment where the contract between user and vendor is finally made.

What did I done to solve it in fact?


- I added a new (once deleted) orderstate with order status code "U" and gave it the name I used for "P" -> "order-entry-confirmation - Eingangsbestätigung"
- I edited my old "order-entry-confirmation - Eingangsbestätigung" state (P) and renamed it to "pending - wartend"
- I edited my own language strings which will be included in the orderstate-emails with easy if clauses depending on the order status code. so I´ve had to switch from "P" to "U" in mail_html_shopper.php and in my language files
- I edited and changed all payment-options to reset the old order-state-references and set the new ones. I used "pending - wartend" only for cancelled paypal-payments!, all other payments with oustanding payment (PrePaid, Invoice, Pay on Delivery, Takewith ...) starting with the new "order-entry-confirmation - Eingangsbestätigung" with order-status-code "U".

(my options in vmconfig at admin-be: for every orderstate I sent emails to vendor and shopper but not "pending-wartend" "P" | no Option for invoices: I don´t use em)

Result:

Now vendor and shopper get no double and incomplete (payment- and shipment-data) orderemails anymore and it works this way. Only cancelled btw. not finalized payPal-payments have the pending state where no email will be sent. I am so happy.

My Conclusion:

Why did all this occured? In my opinion  - and I say that not as an professional - it has something to do that you can´t use P for a normal-orderstate which is included in your order-state-email and payment configuration after vm 2.6.10, so it´s not a bug but a possible user-based missconfiguration. RTFM ! Maybe it would have been better if I have read the ***obscenity removed*** manual ... lol

greetz to you all
jens


[attachment cleanup by admin]