Contrib.social

Check if invoice file exists before generating an invoice

Open on Drupal.org →
Created on 11 December 2020, over 4 years ago

Problem/Motivation

Following scenario happened on one of our sites:
We implemented a commerce store into an existing drupal site. We placed a test order and generated an invoice. Before going live with the eshop we deleted both of them and resetted the number patterns. When a real order was placed by a customer, he was sent a wrong invoice pdf (the one from the test order).

Proposed resolution

This happens because the pdf does not get deleted on invoice entity delete event (which I suppose is a desired behaviour). I understand that we should have cleared the invoice files manually before going live (or do such things in a testing environment), but I still think that we should check for an existing invoice pdf when generating an invoice, inform the administrator about the problem and probably not generate the invoice until the issue is resolved.

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇸🇰Slovakia gresko8

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇪🇸Spain prodigia Malaga

    I've encountered a similar issue. I've deleted invoices and PDF files, but when I generate new invoices, the test invoice still appears. Could you please explain how to completely delete the invoice entity?

  • Comment about 1 month ago →
    🇮🇱Israel jsacksick

    Could you please explain how to completely delete the invoice entity?

    Deleting the invoices from the file system should do the trick, have you tried that?

  • Comment about 1 month ago →
    🇮🇱Israel jsacksick

    Also note that this report is probably a bit confusing as we are actually checking if the invoice file exists before generating an invoice already.

    The suggested solution implies the invoice is generated from the admin which is most likely not the case for 90% of the merchants.
    Not really sure how to properly address that.

    The fact that we make sure to not regenerate an invoice file everytime is for compliance / immutability reasons... To make sure the invoice content isn't different if regenerated / resent a second time.

    With that said, using the invoice UUID instead of the invoice number in the filename could help mitigating that.
    I just wonder if this is an acceptable solution and would not be considered a breaking change.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024