Unpaid orders are automatically paid in full when an invoice is generated

[sean-mullen]

When an invoice is generated, the default payment amount should be 0.

Currently when an invoice is generated for an order where there are no payments, a corresponding payment is silently added to the order - making it paid in full.

A major consequence of this issue is that Bank Transfer orders are unintentionally made paid and could ship for free and would never be discovered.

There are many scenarios where real world Invoices need to be generated before orders are paid in full, so I believe the current auto-payment is unintentional and causes other problems. e.g.:

• Credit accounts where orders are shipped before being paid at all
• Variable deposits to be paid for backorders or expensive items
• Corporate customers sometimes need an invoice to get managerial approval before making a purchase an so on

Proposed fix. Change default payment to 0:

` classes/order/Order.php (at #1651)

• $orderPayment->amount = $this->total_paid_tax_incl;
• $orderPayment->amount = 0; `

[eschiendorfer]

@sean-mullen Man you made my day! I was discussing this with Lesley some days ago. I completly agree, that it's a not a clever behaviour.

[kintaro1981]

How about have a pro-forma instead?

https://www.investopedia.com/terms/p/pro-forma-invoice.asp

If for 1.0.x this can be a compatibility problem, how about just be able to store/send as a pro-forma the printable version of the order?

[sean-mullen]

There are simple and complex ways of fixing this behaviour. I suggested changing the default to 0 to prevent introducing compatibility issues.

I'm not sure if a proper pro-forma should reserve stock or not. If so, it might be a case of conditionally modifying the Invoice template and sending it. If not, then it is probably an entirely new feature.

The main issue in this ticket isn't one single activity. BO users i.e. employees should be able to generate a TB Invoice PDF without being forced to pay a customer's order as well

This example hopefully highlights just how much trouble this default can cause:

During a week, multiple customers place orders and promise to pay by a bank transfer. Most payments happen in the days after the order is placed. Many of the orders come to the same total and are paid on the same day. Some customers call and pay by over the phone instead. Many ignore instructions to use the order reference on the transfer. Some customers decide they cant afford their order. They don't bother to cancel

• Employee generate invoices in the BO because they like to manually check all the items are in stock in their warehouse - or use them as a packing list or something else. In any case, this automatically makes every bank transfer order paid

• Consequently, lucky customers can receive orders they know then did not pay for. They can even log in to TB and download their invoice which confirms their order was paid in full. "Awesome, must be a gift"

• End of month bank, merchant gateway and PayPal report income less than web sales. An employee generate invoices in the BO to work out why. This make matters worse because generating invoice pdfs automatically pays more unpaid orders . In these circumstances, it is practically impossible to work out which order(s) where not actually paid for because the data in TB is wrong.

It make far more sense to assume invoices are not paid.

[RaptorX]

Completely agree.

My current workaround is to track payments with order tags... I ignore payment status on TB and just trust my tags.

But this could easily be avoided if as you say invoices aren't assumed to be paid in full as soon as they are generated.

[firstred]

Interesting. I never realized it was this big of an issue. What payment gateways do you all use? I always thought that problems like this were caused by the way payment modules validate orders and might even influence others. I guess seeing the source code will give the answers.

Thanks for all the info so far. Really helpful! We are going to get to the bottom of this.

[eschiendorfer]

I guess the intention of system is not too bad, but somehow it's not consequent. We have order status. They can have different "values". Like "shipped", "paid", "cancelled". I like this flexible system. Why don't we rely completly on them?

What is the sense of debatting, if an invoice is paid or not, when its genereated? It differs in country. In germany, switzerland or austria "invoice" has a different meaning... Let just the order status tell, if an order has been paid.

Edit: As with @RaptorX we do manually track the payments. They come in by classical bank transfer...

[RaptorX]

I live in Dominican Republic, so I am limited by the payment gateways I can use, so I end up doing a lot of manual work.

In my case I manually track payments to local banks none of them supported by us payment gateways.

[sean-mullen]

Default install

1. Bank wire payment. Status: Awaiting Pay wire payment ✓ Payments: none ✓

2. Generate Invoice. PDF created ✓ as expected

3. Result: Order Status ✓. Payments incorrect ✘ Invoice incorrect ✘

[firstred]

I think I've finally come across this issue today. Have you tested the behavior with previous versions of the bankwire module as well? It seems to be caused by newer versions, but I am not sure.

[sean-mullen]

@firstred I think you are right. I didn't notice this issue because I was using an older version of the bank wire module, which I had cloned and customised to Australian bank transfers.

I'm working on setting up trade/credit accounts so I'm not keen on the assumption all invoices are paid...