thirty bees community module: Virtual Vouchers Generator 0.7.3 - ALPHA

[the.rampage.rado]

Here is a tiny module that is s till in alpha stage so please test and use with care.

You want to offer virtual gift vouchers to your customers? OK then!
 
Virtual Vouchers Generator

How to use this module:
1. Create your voucher products - set those as Virtual so they don't incur delivery if ordered alone. The value of those products will be picked as voucher value. If multiple products are ordered at once the value will be combined into one voucher.
2. Specify the Product IDs for those products in Virtual Voucher Product IDs.
3. Specify the proper statuses when the virtual voucher order is considered paid in Paid Order States (IDs).
4. Configure the rest of the options to your liking.
5. Copy the cron URL and run it at proper intervals (recommended 5-10 mins).

Configuration page:

Email sent after order validated as paid:

Check voucher page (in Niara - adjust module css to your liking!):


As I'm still learning, so please keep in mind this module could (and most probably will) have some bugs. And still the lookback logic for validating the orders is not so cleared out. If in future somebody want to take over development would be more than happy.

Changelog:

• 0.7.3 alpha (12/1/2024) - Fixed bugs with translation strings, new email template (single column, mobile-friendly), fixed bug with cron link not including https.
• 0.7.2 alpha - Minor bugfixes with multistore reCAPTCHA settings, voucher check page, and controller name.
• 0.7.1 alpha - Introduction of 'Check voucher' page where the customer can see how much funds are left into their multi-use voucher. Integrated with Thirty Bees' reCAPTCHA module (if it's installed, enabled, and configured the reCAPTCHA will be shown here too) - the customer has to enter the validity date of the voucher as a safety measure. The page's friendly URL should be configured in SEO & URLs (or if you don't use SEO URLs, access from here: /index.php?fc=module&module=tbvirtualvouchers&controller=vouchercheck).
• 0.7.0 alpha - Option to limit the voucher country based on where it was ordered (from invoice address), email tweaks and fixes, new logo with attribution.
• 0.6.0 alpha - New email template, Bulgarian email language.
• 0.5.0 alpha - Initial release.
   
• 

To do:

• further voucher settings
• add T&C section to configuration so those are attached to the email.
• pass conditional information to email for country restriction (if available).
• introduce changelog in the module.

 

 

 

 

 

tbvirtualvouchers-0.7.2.zip

tbvirtualvouchers-0.7.3.zip

[datakick]

That's very nice, thanks for sharing.

I would just like to point to a problem related to VAT, and EU laws (https://www.vatcalc.com/eu/eu-review-of-vat-on-vouchers/)

When you sell voucher, it is considered to be a MPV voucher (A multi-purpose voucher is a voucher where, at the time of issuance, the VAT treatment of the goods or services to which the voucher relates is not known). You are required to collect VAT when customer redeem the voucher. 

Unfortunately, thirty bees does not do that. In thirty bees, cart-rules are treated as discounts, and they affect price before tax.

Example:

• Let say you have a product A that costs 1OO without tax, 120 with tax
• You also have voucher virtual product with face value 120

You sell voucher product with VAT rate 0, because VAT should be collected on voucher redemption.

When your customer use the voucher to purchase a A, the voucher will decrease the pre-tax amount to zero. This will result into free order, and there will be no tax applied at all.

The correct behavious should be the free order, but with applied tax.

Which is obviously wrong, and you can have problems with your tax authority.

In other words, credit vouchers should not behave like discounts, but more like a payment method. 

We are thinking about how to fix this. We will probably introduce new kind of cart rules, that will behave correctly.

Note: currently, the same problem is with vouchers generated from credit notes. It just isn't so obvious, because credit notes are not used that much. 

Example: 

1. you customer buy product A for 120€
2. you collect 20€ VAT and send it to your tax authority
3. you customer request full refund
4. you generate credit note, and will request refund €20 from you tax authority
5. you generate voucher with face amount €120 to your customer
6. your customer can use this voucher to purchase product A. The voucher will reduce the pre-tax amount, and your invoice will be with zero tax

You once again stole from your tax authority. You sold product A for price with tax, yet didn't actually send the tax to tax authority.

[the.rampage.rado]

Thank you for looking into that!

I'm not even sure if I can process card payment and not apply VAT currently as here we are obliged to issue a fiscal receipt and my machine is not configured to issue 0% VAT.

What about if we limit the vouchers to the country of purchase - we detect the invoice country and pass this information on the voucher creation logic. Not that it solves anything else other than the possible difference in VATs.

When I purchase a voucher in Bulgaria they issue me with receipt as a normal purchase and apply VAT at this moment. I'll have to look into that.

[datakick]

45 minutes ago, the.rampage.rado said:

When I purchase a voucher in Bulgaria they issue me with receipt as a normal purchase and apply VAT at this moment. I'll have to look into that.

It depends on what type of voucher it is. It can be either:

Single-Purpose Vouchers (SPVs) --- can be used only if the tax rate and the place of supply is known. So, if the voucher can be used only for products with standard VAT rate, and only in Bulgaria, than such voucher meet the SPV criteria. You can then collect VAT at the sale of such voucher, and voucher can be used as a standard discount.

or 

Multi-Purpose Vouchers (MPVs) -- voucher can be used for any product, or EU-wide -- an actual VAT rate is not known at the time of voucher sale. Voucher must be sold without tax, and tax must be collected when the voucher is applied. Voucher shouldn't be used as a discount, but as a method of payment. 

 

[the.rampage.rado]

New feature - check voucher page in FO and one question...

Why in 2 separate installations the module works with a controller named VoucherCheck.php and on another install it does not work and looks for vouchercheck.php (all updated to edge)?

[datakick]

6 hours ago, the.rampage.rado said:

New feature - check voucher page in FO and one question...

Why in 2 separate installations the module works with a controller named VoucherCheck.php and on another install it does not work and looks for vouchercheck.php (all updated to edge)?

Names of front controller files should be lowercase, I believe.

There was recently a fix for this https://github.com/thirtybees/thirtybees/commit/73bd67f18a143bf06fdc014302495ec7c77986f8 but for BC compatibility reasons (if you want module to run on older tb versions) you should use vouchercheck.php 

[the.rampage.rado]

Thanks, will use lowercase in the next version!

[vincentdenkspel]

On 11/4/2024 at 12:05 PM, datakick said:

Voucher shouldn't be used as a discount, but as a method of payment. 

I'm not a developer, so this may be a silly question: Is it not possible to create a payment option that only accepts vouchers?