Payment status change not showing on PDF invoice

[Allen_K]

Hello,

Using VM 3.8.6.

I have created a payment method based on Standard to allow people to generate an invoice with EFT remittance details that sends to the purchaser. The default order status for this payment method is "Confirmed by shopper", which is a pending status, and recorded as "unpaid" on the PDF invoice initially sent.

When we receive payment by EFT, I update the order status to "Confirmed". If I view the updated order through VM, it shows the status as "Paid" at the bottom, just as it does on the order list page. However, the status change is not recorded to the PDF invoice that is generated and sent to the customer when I update the order status to "Confirmed". The updated PDF invoice available for download is not changed, and incorrectly still shows the latest invoice status (the only invoice status) as "Unpaid" - which means the PDF invoice status does not match the order as viewed through VM Administration.

I read at https://docs.virtuemart.net/manual/general-concepts/205-invoices.html that changing the order status should create a new invoice entirely. This does not appear to be working correctly.

Any ideas on how to fix this?

Regards,

Allen

[GJC Web Design]

Only one pdf is generated as I understand it it is considered a  "legal document" for tax purposes..

The idea is you only generate it when the order is paid and confirmed...  even if u choose multiple states only the first reached state will generate an invoice...

Why do u need to use the pdf as a purchase order? There is enough info on the email .. when they pay and you confirm THEN the invoice is produced and sent.

The only time a invoice is re-generated is if u physically delete it in the safe path folder - if u really want to use your current workflow then a plugin to delete the existing one when the status is changed and force the recreation?

BTW - multiple Invoices - with a suffix added to the name - can be produced when you edit an order or cancel etc

[Allen_K]

Hi,

According to the VM documentation link I provided (https://docs.virtuemart.net/manual/general-concepts/205-invoices.html), a status update is supposed to create a new invoice. It does not.

The reason a PDF is needed for the "Pay by wire transfer option" I created is because many people who want their employer to pay, need a pro-forma invoice to get the purchase approved for payment. It's standard operating procedure at many companies. An invoice does not have to be paid upon creation to be a valid invoice for payment at a later date. It's a real pending invoice with payment due. When I update payment status, the order updates properly, but the invoice does not. There is no legal restriction that prohibits updating an invoice as being paid. That would make no sense at all at any rate.

Again, the VM documentation explains a status update should create a new revised invoice while re-naming the original. I'm not guessing at this; the documentation link says so. I need to know how to get VM to work as designed.

Regards,

Allen

[GJC Web Design]

Yes your right ..

I tested on VM3.8.4 with setting the PDF creation to 2 different states

when I manually flip between them 2 different pdfs are created and sent

Invoice 201221RICG0254
==Web Site==
Invoice date 2020-12-21
Delivery Date Same as invoice date
Order Number LQV40367
Order Date 2020-12-21
Order Status Confirmed by shopper

and

Invoice 201221WZDB0253
Invoice date 2020-12-21
Delivery Date Same as invoice date
Order Number LQV40367
Order Date 2020-12-21
Order Status Confirmed

I assume u have set the status you want to create pdfs?

[Allen_K]

Hello GJC,

Yes, I have PDF creation set for both states, "Wire Transfer Pending" state and "Confirmed" state. When I update 1 to the other, I am not getting the 2nd invoice creation behavior you are.

Thanks for testing at your end. Since your order ID is remaining the same, but the order number is changing, this gives me an idea to check. I am using Rupostel One Page Checkout, and it is configured to override order numbering so my invoices have sensible order sequencing based upon YYYYMMDD-#. I will check with Stan at Rupostel to see if OPC's order numbering override is potentially interfering with VM's desired PDF update creation capability. I checked my invoices in the safe path, and was able to verify that no second invoice is getting created.

Either I or Stan will update this post with what I/we learn.

Regards,

Allen

[stAn99]

hello allen, i read the forum and yes, OPC can alter this a few ways, but generally it is true that VM is not really made to suport 2 versions of invoice per order and thus OPC also provide only single numbering agenda to VM and thus the numbers might get into conflict and not work as they do in VM core where the numbering is not that strict. in previous VM versions it checked conflicts against the invoice number and added -1 on it's own when second version tried to be generated, but now it seems it just doesn't allow to generate the second one.

so now the question is what to do with it:

- alter VM core to support multiple agendas (i.e. pdf documents to customer such as delivery note/proforma/invoice/gift certificate/registration certificate/customs documents/etc... ) -> this would be nice to have, but i hope VM core is not really the one that should support such heavy feature since it can then lack good support and the feature might need plenty of customizations per customer -> there are multiple solutions to this one, including my "experimental" pdf generator that i am using for last 10 years, but supports still just fixed number of pages per document. (any amount of agendas is supported + any types of docuemnts + each with own or shared numbering system )

- alter my opc to allow second generation of the invoice even if it would hit the conflict with the invoice number within VM internally (i.e. locate the code which prevents it in VM and try to write a hack around it, or suggest a VM core change to alter this)

- see if any 3rd party extensions such as artio vminvoice support multiple documents per order (proformat + invoice)

- maybe the simplest workarond -> disable invoice pdf for proforma and generate proforma programatically withinin the order template and attach it to the email, so it's not a real VM invoice, but your order number = invoice number it should not be that coplicated to create and attach it (up to 4h of work)

best regards, stan

[Allen_K]

The fix should simply be to have VM automatically revise the existing invoice to reflect payment received as it should according to standard accounting practices. The VM order updates okay, but the invoice is not updated to match the order. Bizarre. Updating an existing invoice is normal with QuickBooks and all normal bookkeeping software. When a customer pays an outstanding invoice receivable, the QB invoice is marked "Paid" with $0.00 balance owing. No new invoice is created in QB; the old one is simply revised and all other ledgers are updated accordingly.

Now that I think of it, VM is breaking accounting rules by creating a new invoice since this would F' up the customers books too. The recorded payment of an invoice at the customer maps to the original invoice number, but then the customer would receive a new invoice (with new invoice number) marked as "Paid".  The customer's books would have the payment already recorded and applied to the original invoice. Technically, the old original invoice would need to be cancelled, and the new invoice recorded in its place so the payment can be applied – which would then screw up the customer's PO tracking for the original authorization. Likewise, the status of the original invoice in VM should actually be changed to "Cancelled" if it is to be replaced by a new invoice with a new number. When VM creates a new invoice with a new number to replace the old, accounting standards view this as a new transaction.

VM's invoicing simply does not conform to accounting standards unless 1.) the purchase is paid when ordered, and 2.) is never cancelled or refunded. Now that I think it through, VM's native behavior of creating a new invoice number with every order status update is worse than what I have now! It would wreak havoc with the bookkeeping of the seller and the customer both.

My final conclusion is this:
Since existing third-party invoicing alternatives appear out-of-date (from limited research), there are only two remaining acceptable solutions that will support proper bookkeeping practices:

• VM should be fixed to update the existing invoice to match the order. The status log at the bottom of the invoice should be current too. This is the proper fix. A single system where the order does not match its own invoice is just obviously bad – and this is what we get when we manually change an order as payment is received or if the order is cancelled or refunded. I am surprised this has not been raised as a serious issue before. Perhaps others are not using VM to sell higher-cost items requiring separate payment?
• If #1 is not possible, which would be pretty poor considering VM's purpose is to properly support transaction processing and recording, then I will simply manually correct existing invoices upon status change and send them by separate email myself. This is cumbersome and unprofessional, but technically possible.

I know that VM prohibits deleting an order and invoice. This is good, but this is different from editing, and follows good accounting practice that no transaction should ever "disappear" once entered into the books. Invoices should be able to be voided (cancelled), but not deleted. A cancelled invoice should be clearly marked as "Void", and a paid invoice should be clearly marked as "Paid" even if it started out as an invoice on accounts receivable.

Yes, I know VM is not designed to be a full-on bookkeeping system. But it still needs to conform to the rules if it creates invoices that are recorded into bookkeeping systems later.

You'll probably recommend going with #1, which is a shame since this is such an obvious VM flaw that should have been fixed a long time ago. I never noticed it before since I just assumed the update sent to the customer included a revised and updated invoice that actually matched the payment update. Until a customer complained, it totally went under radar. Leaving customers to just "deal" with this is failing to address a real logic and suitability bug in the extension itself.

Feedback anyone? If what I say makes sense, how can this be raised to be corrected?

Regards,

Allen

[AH]

 

I never noticed it before since I just assumed the update sent to the customer included a revised and updated invoice that actually matched the payment update. Until a customer complained, it totally went under radar. Leaving customers to just "deal" with this is failing to address a real logic and suitability bug in the extension itself.

VM does have some support to assist you here - as I have had similar concerns when Invoices are "updated" - There is a hidden configuration in virtuemart.cfg.

Not that this would solve all of your other issues - cancelling old invoices - emailing that to customers and issuing a new invoice and emailing that too.

This is the setting:-

Code Select Expand

ChangedInvCreateNewInvNumber=0 //dont create new invoicenumber if order is changed

I am unsure how this works with the invoice locking functionality - as I have overriden this in my code.

Perhaps others are not using VM to sell higher-cost items requiring separate payment?

Many certainly are!

Possibly you may be able to combine the above with additional overrides
Whereby you use a Payment Invoice/Purchase Order flow.

For specific Status/s generate a PDF (with the invoice setting configured) but handle those status/s in the invoice template overrides by changing the output to state PAYMENT INVOICE vs PAID INVOICE on the PDF instead of invoice. Or even PURCHASE ORDER.

The INVOICE terminology only being using when all other invoice statuses are set.


My final feedback:
Please try my hidden configuration suggestion in test version of your site.
As you noted VM is not a full (or even a basic accounting system) VM's new "PAID" setting is, at best, rudimentary. 

that will support proper bookkeeping practices

Comparing to QB and how that works makes me think that you should export all your orders to QB in the first instance and handle them there - But of course that is dependent on you having such an API  or getting someone to develop one for you.

Regarding "bookkeeping practices"  VM is deployed globally, my first hunch is that - such practices will vary.

[Allen_K]

Thanks. I will try your code change recommendation. In that my invoices are not re-creating anyway for some reason, I guess it's a moot point for me.

Regarding "bookkeeping practices"  VM is deployed globally, my first hunch is that - such practices will vary.

Bookkeeping practices typically follow international accounting standards. Accounting is standardized so we can all work well with each other in commerce, and this should be considered by developers when they make an e-commerce product.

[AH]

Thanks. I will try your code change recommendation. In that my invoices are not re-creating anyway for some reason, I guess it's a moot point for me.

You may be being hit with the invoice lock functionality - keep us posted :-)