Strange invoicing procedure! BUG when cancelling products! Better solution?

[keglevich]

Maybe everything will sound a little confusing, but I have lots of thoughts, questions, problems with order procedures in Prestashop. If anyone is willing to read through, I would be very happy to receive some kind of feedback. Here we go!

This is probably not a bug, but more strange prestashop behavior/acting, when customers are placing orders. The thing that bothers me the most is that each new (or old) customer can place an order and right after placing an order automatically final invoice is generated. Invoices are numbered 1,2,3, etc. So, someone decides to register at my web shop, then places 50 orders which he won't pay, so I have in database 50 invoices, where I can only set status to canceled, but the invoice still stays in the database. Furthermore, the problem is then at the end of the month when I print all invoices and take them to my finance sector I must explain that only valid invoices are for instance 1,7,8,25,33, all others weren't paid.

If I try to cancel an invoice and cancel the products from the invoice the final sum (price) stays the same, but there's no product at the invoice at all. This is definitely a bug, try it! It only works ok if I set it to PAYMENT ERROR, but in that case all products stay on the invoice, only price (sum) is 0.00EUR. Stock status doesn't change back to normal.

The right procedure for making orders in my opinion would be:

1. Client places an order, when he finishes an order automatically a PROFORMA or OFFER or maybe an ORDER CONFIRMATION is generated but not a final invoice!
2. When I (administator) approve that order in back office I set status to waiting payment. Then payment accepted and THEN I can manually create a FINAL INVOICE which will be then attached to that order. SO for instance order confirmation no. 55 will match invoice no. 32. That way I have only valid invoices in the database, not a whole mess.
3. If a client still wants to return that product, then I can cancel that invoice (invoice 32 which matches offer no. 55) and I can then create a new "contra-invoice" or credit-return or whatever. Maybe there is also a way to not even creat a new one but just to delete that canceled invoice from database and create a new one with the same ID number when needed? Whichever option would be OK.

Second thing, in back office I can forever change values (statuses) of one order from: payment accepted, cancelled, shipping, delivered, cancelled, waiting for cheque, delivered, shipping, etc. This is impossible! When package is delivered there shouldn't be an option to change it back to shipping? And when payment is accepted there shouldn't be again an option waiting for payment. This is really confusing.

Third thing, if I cancel an order and "restock products" and if I then make a refund, the value on the invoice still stays as paid. Where is an option to cancel (storno) the invoice? Each shop should have an option to cancel definitely one invoice and create a new one. No matter what I do an invoice stays in the database forever.

To sumarize everything, what would be the best way (with current version of Prestashop) to avoid faulty invoices? Is there a way for admin to manually confirm each invoice (customer can not do this!) only after the order was really paid? What do you users do when you get some fault (unpaid, cancelled, returned) invoices? How you compensate, do you manually print final receipts for finances sector?

Any thoughs, replys, opinions would be highly appreciated, Tomaz.

invoiceAfterCancel.pdf

[TropischBruin]

I agree with you.

I find the creation of invoices before a payment had been recieved a no-logical thing.
This has te be changed otherwise it is hardly usable for a lot of companys as they will have to create a-lot of creditslips.

I hope the def-Team will respond to this.

[Jiri FAMiNE Cermak]

Hi, I also agree with you.. I am also experiencing the same cancel invoice problem...

Btw, the immediate invoice generation can be solved by simple disabling when the invoice is generated (Orders > Order Statuses), i left checked only Shipping, Payment accepted, Delivered. This will force invoice generating only after the goods are shipped or the payment is accepted. But, yes this should be a default setting...

[TropischBruin]

Btw, the immediate invoice generation can be solved by simple disabling when the invoice is generated (Orders > Order Statuses), i left checked only Shipping, Payment accepted, Delivered. This will force invoice generating only after the goods are shipped or the payment is accepted. But, yes this should be a default setting...

Thank you for pointing that out.

[keglevich]

In the past few days I tried to "play" with invoice creating, refunds, returns - with the whole ORDERS category and I must say it really contains a few serious bugs and maybe better said "serious limitations".

1. First bug, as already reported in the BUG TRACKER by me before (also by Jiri Famine Cermak) and some other users is that when you try to remove a product from an order (from a generated invoice) a serious bug appears where the paid value stays the same and there's at the end no products in the list at all. So, in the end it looks like:

Products - (nothing)
Total SUM: 2000EUR

2. Very confusing are also some options:
- What really happens if you choose an option: REFUND? Nothing really. Invoice is generated, no credit slips are generated and total products value also stays the same. So, what really does REFUND function?
- If I select PAYMENT ERROR: The whole product value goes to 0.00EUR but all products still stay at the invoice and again, invoice is generated.
- If I select order CANCELLED again nothing special happens.
- After selecting order CANCELLED I have to manually remove each product from the invoice and create a CREDIT SLIP. If I forget to check some tickboxes I can't repair that later!
- There's no option to generate first only ORDER CONFIRMATION or PROFORMA INVOICE or something similar! Each sompany should have this option.
So here's my opinion how the whole order procedure should look like:


1. USER CREATES A NEW ORDER
2. ADMIN CONFIRMS THAT ORDER - ORDER CONFIRMATION OR PROFORMA INVOICE IS AUTOMATICALLY GENERATED!
3. USER GETS ORDER CONFIRMATION (PROFORMA) OVER EMAIL AND ON THE WEB PAGE
4. ADMIN CAN CHANGE THE INVOICE / CREATE A NEW ONE IF NEEDED WITH THE ORIGINAL NUMBER - 1, 2, 3...
5. ADMIN CAN MANUALLY CHANGE PRICES IN THE PROFORMA IF DESIRED BEFORE CREATING FINAL INVOICE
6. ADMIN CAN ADD/REMOVE DIFFERENT PRODUCTS TO THE PROFORMA IF USER DESIRES
7. FINAL INVOICE CREATING, SHIPPING, DELIVERING (EVERYTHING BY ADMIN)
8. IF PAYMENT NOT ACCEPTED OR PRODUCT RETURNED, ADMIN CAN MAKE A STORNO-INVOICE (MAYBE DELETE THE INVOICE COMPLETELY FROM DATABASE) OR JUST CANCEL IT - EVERYTHING GOES BACK TO STOCK, PAYMENT DISAPPEARS.
9. ORDER CLOSED WHEN EVERYTHING FINISHED


In my opinion the whole ORDERS section need a good revision. I hope someone from development team will read through this and maybe write some opinions.

3. If the invoice is printed out and I try to cancel it (make a refund or storno-invoice) if I don't really click everything 100% right (that means if I select some wrong option) then BUG appears again and I can't do anything to change removed products again - maybe only manually editing database.

Lastly, I was testing MAGENTO COMMERCE to compare orders. I would be really glad if someone from development team can check that solution. Magento for me is not a perfect ecommerce (in fact Prestashop is way better in terms of flexibility and has many more options to configure, also Prestashop is way better for businesses in Slovenia), BUT everything regarding ORDERS and PAYMENT and INVOICING in MAGENTO is practically PERFECT! I (admin) can change everything in the invoice:
- create a whole new invoice with reference number as xxxx-1, xxxx-2, etc.
- make INVOICE manually when everything is confirmed!
- make a CREDIT MEMO from selected products
- edit prices in the invoice manually
- removing and adding different product to the current order
- if payment not received (or only a part received) create a CREDIT MEMO.

However, Orders, Invoices, Payment - those things are perfect in MAGENTO and should be used in the same way in PRESTASHOP. Everything else from Prestashop for me is really great.

Just my two cents...

P.S. Attachments show two of the BUGS I am talking about.

000004-4.pdf

[TropischBruin]

You can however set the orderstatus not to create an invoice.

But you nailed it head on!

[keglevich]

You're partially right. Truth is that there's no "need" to create invoice at some order status. But anyway, at some point you have to create invoice and send it to your client. After that (if something goes wrong with the order) there are many errors possible (as described above). I wrote some complaints regarding invoices, but if you read through my post carefully you will notice that invoice creating is not the one and only problem I am complaining about.
The thing that bothers me more is that AFTER invoice is created there are many limitations of cancelling or repairing it. I also mentioned two serious bugs (you can check my two file attachments) which really don't have direct connection with invoice creating but more with managing/changing/cancelling it.

However, if you have some time (and good will) try to run through MAGENTO's orders system. You will see what I am talking about.
Let me say it again, creating invoice at some point is not my biggest concern. What I am afraid the most is everything that can happen after the invoice is created and also I am afraid that no one from development team doesn't care much about those bugs regarding product cancellation from the order/invoice. And those few bugs were reported in the bug tracker at least five times!

Thank you for understanding again...

[TropischBruin]

I'm running osCommerce at the moment with the order-edittor and Prof. Invoice and Packingslip contributions and this works great.
I'm not interested in Magento atm.

I'm sharing you toughts about the order/invoice etc. used by PS and that it is not workable for me and I'll guess many others.
Like you say, forgetting to click a certain box creates so much problems and work before you can fix it that for now I'm not sure if I will change over.

I hope that dev-team will respond.........

[DrÿSs']

Hi,

Theses bugs should be fixed in last SVN version.

[keglevich]

Hello Philippe,

I tried last SVN version but it looks some bugs still are still present in the code. I sent you PM regarding two bugs which in my opinion has the same reason to appear. The main problem is removing product from the order. If you have (for instance) 10 products in the order (the same products), there's no problem to remove one by one up to number 9. The problem occurs when you remove the last product. It disappears from the list, but the total price doesn't change right. After that everything becomes a big mess. This should be fixed. Please reply when you fix this, so I can test again.

Thanks in advance, Tomaz.

[j]

no news on this?
Feels like a serious bug imho. Sure the invoice creation workaround as mentioned above works to some extent, but still,
this issue needs to be adressed.
Looking forward to see when/if it is solved.
#subscribing to this thread.

[L. Brett Sinclair]

yes, I totally agree. I learned the hard way of this problem in a test environment, it was sending credit slip to customer on my behalf...

[j]

Hi everyone.

How is it possible that nothing have been heard from the dev's / coders?

This is a bug in that regard that it renders this application not usable imo.

Sure there are workarounds, but nothing solid. Developers / Coders, i konw
you are all busy with your own lives, and lots of other development aswell,
but serious... This issue needs major ATTENZIONE !.

Looking forward to hear an update on issues mentioned above, by me and
all the other folks.

//J

[shodnett]

Just moved to Prestashop, and found this thread - these bugs are still here 5 years later.  I have been posting wanting help with changing invoice totals when partial refunds and etc are made - seems like it has been in issue since forever, and remains one now too. Vouchers are only any good if the customer is going to come back to buy again, but not if they don't - and legally we have to give them money back if they want it, not a voucher ... Really regretting switching to Prestashop as it is these small details that make it unusable.  (Another one is coping with partial shipping)