[Skip to main content](#vessel-content)
# Profile for sven
##
[](/forum/user/83279-sven "View sven's Profile")
**[ Offline](/forum/user/83279-sven)**
- **User Type:** User
- **Register Date:** 24 Apr 2025
- **Last login:** 2 weeks 3 hours ago
- **Time Zone:** UTC +0:00
- **Local Time:** 23:13
- **Posts:** 2
- **Profile views:** 45
- **Gender:** Unknown
- **Birthdate:** Unknown
- **Medals:** Hikashop Business
- Posts
# sven's recent posts (2 messages )
All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year
| [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) |
|---|---|---|---|---|
| [](/forum/28-shipping-methods/910751-excluding-dutch-islands-from-shipping#373028) | [Excluding Dutch Islands from shipping](/forum/28-shipping-methods/910751-excluding-dutch-islands-from-shipping#373028 "-- HikaShop version -- : 6.5.2 -- Joomla version -- : 5.4.7. -- Browser(s) name and version -- : Ecosia Hi, I am trying to exclude the Dutch Islands from shipping. I only want to ship to The Netherlands for now, but want to make sure that people from the Dutch Islands can't order (due to too high shipping fees). Their postcodes numbers are: 1791–1797 8880–8889 8890–8891 8899 9160–9164 9166 I think I should use the "Postcode RegEx" field for this? But I can't get it to work. I filled in this code: #^(?!88(8[1-9]\|9[0-6]\|99)\|916[1-3]\|9166)\d{4}$ And this code: #^(?!179[1-7]\|888[1-4]\|8899\|916[1-4]\|9166)\d{4} ?[A-Z]{2}$ but both don't work. When I do this, every single address does not work anymore. Let me be clear: I don't really understand what I am doing in this regard, I have asked a GPT to generate the codes to fill in. But both don't work so I am stuck now. Can you help me to exclude these postcodes from my shipping methods? Thanks in advance!") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 2 months 4 weeks ago, by [sven](/forum/user/83279-sven "View sven's Profile") [Last Post](/forum/28-shipping-methods/910751-excluding-dutch-islands-from-shipping#373029 "Hi, The "Postcode RegEx" field is passed as-is to PHP's preg_match, so it has to be a complete pattern, delimiters included. Both of your patterns open with a # but never close it, so PHP rejects the pattern as invalid and the shipping method is then hidden for every address, which is the "every single address does not work anymore" you're seeing. The other thing to know is how the field is evaluated: the method is kept only when the postcode matches the pattern. So it is an "allow" test, which means your negative-lookahead idea (allow everything except the islands) is exactly the right approach, it just needs the closing delimiter. Based on the postcodes you listed (1791-1797, 8880-8889, 8890-8891), this works: It matches any 4-digit postcode that does not start with one of those island ranges, and it does not care about the trailing letters (like 1234 AB), so it works whether or not the letters are stored in the address. Put it on your Netherlands shipping method and the island postcodes will no longer be offered that method. If you also want to exclude the Ameland / Schiermonnikoog codes you had in your test (9161-9166), add them the same way:") 2 months 4 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1 Views:285 | [Last Post](/forum/28-shipping-methods/910751-excluding-dutch-islands-from-shipping#373029 "Hi, The "Postcode RegEx" field is passed as-is to PHP's preg_match, so it has to be a complete pattern, delimiters included. Both of your patterns open with a # but never close it, so PHP rejects the pattern as invalid and the shipping method is then hidden for every address, which is the "every single address does not work anymore" you're seeing. The other thing to know is how the field is evaluated: the method is kept only when the postcode matches the pattern. So it is an "allow" test, which means your negative-lookahead idea (allow everything except the islands) is exactly the right approach, it just needs the closing delimiter. Based on the postcodes you listed (1791-1797, 8880-8889, 8890-8891), this works: It matches any 4-digit postcode that does not start with one of those island ranges, and it does not care about the trailing letters (like 1234 AB), so it works whether or not the letters are stored in the address. Put it on your Netherlands shipping method and the island postcodes will no longer be offered that method. If you also want to exclude the Ameland / Schiermonnikoog codes you had in your test (9161-9166), add them the same way:") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 4 weeks ago |
| [](/forum/40-taxes/910749-issue-vat-btw-when-using-coupons-higher-than-total-price#373018) | [Issue VAT (BTW) when using Coupons higher than total price](/forum/40-taxes/910749-issue-vat-btw-when-using-coupons-higher-than-total-price#373018 "-- HikaShop version -- : 6.5.2 -- Joomla version -- : 5.4.7. -- Browser(s) name and version -- : Ecosia Hi all, I have discovered a VAT calculation issue in HikaShop that I can't seem to get fixed. I would appreciate it if you could check whether my analysis is correct and, if so, advise on the best solution or provide a fix. The Issue The issue occurs when using a coupon with a value higher than the remaining product subtotal or the exact same amount. If this happens, HikaShop stops showing the VAT (BTW) that is being calculated. The VAT is still calculated, but not shown anymore. In these examples, our webshop uses 9% reduced VAT for food products. Normally, the VAT calculation is correct. For example: Example 1 – correct behaviour - Screenshot 1 Products: €83.88 (so this amount is including 9% VAT) VAT: €6.93 Coupon: -€80.00 Final total: €3.88 Displayed VAT: €6.93 This is correct. The VAT is calculated as it should be: ((83,88 / 109) x 9) = 6,93. However, when the coupon value becomes higher or exactly the same as the product subtotal, the VAT calculation in the checkout changes unexpectedly. Example 2 – incorrect behaviour - Screenshot 2 Products: €76,89 (it still works with the price of the products including VAT here, so the VAT is still used in a correct way by the system) Coupon: -€80.00 Final total: €0.00 As you can see, it does not show VAT anymore. It seems not to calculate once the total amount is €0,-. When there are shipping costs, it only calculates VAT over the shipping: In the example below, we have shipping costs of €4.50 if someone buys for less than €75.00. Therefore I lowered the amount of groceries till below €75,00. Still only food products, so only 9% VAT. Example 3: Shipping Costs - Incorrect behaviour - Screenshot 3 Products: €69.90 Coupon: -€80.00 Shipping: €4.50 Final total: €4.50 Displayed VAT: €0.37 The VAT shown here is no VAT over the products. The VAT over the products AND shipping is supposed to be €6,14: Product VAT: (69,90 / 109) * 9 = 5,77 Shipping VAT: (4,50/109)* 9 = ,37 In total: 5,77 + 0,37 = €6,14. However, the VAT shown here is only ,37. So it only shows the VAT of shipping costs. But this is incorrect, because even though someone receives a discount via a coupon, he has still paid VAT over the products. So the correct VAT statement here should be €6,14. Example 4: Discount = exactly product costs - Incorrect behaviour - Screenshot 4 Also when the discount voucher is exactly the same as the amount of products, it does not show VAT. Products: 69,90 Discount: €69,90 Shipping: €4.50 Final total: €4.50 Displayed VAT: €0.37 Observation & analyses It appears that when the coupon reduces the taxable product amount below zero, HikaShop sets the product taxable amount to zero. This is not correct: even though somebody received a voucher with a certain value, VAT (or BTW) is still being paid. The system does perfectly understand this when there is still an amount to be paid, even if it is €0,01. The VAT remains correct. But when the amount goes to €0,-, it does not show the VAT anymore. This current situation means that the information shown to our customers is incorrect, but also that the VAT we have to pay to the government is not shown anymore in our report and therefore can not be calculated. This is a big issue for us. Possible Solutions Could you please look into this issue and let me know what the recommended solution would be? Since we can not use coupons right now, I would appreciate a fix or workaround as soon as possible. If you need any more information from us, please let me know. Regards, Sven") Category: [Taxes](/forum/40-taxes "Living in Canada and having troubles configuring your taxes? Come and get some help over there") Topic started 2 months 4 weeks ago, by [sven](/forum/user/83279-sven "View sven's Profile") [Last Post](/forum/40-taxes/910749-issue-vat-btw-when-using-coupons-higher-than-total-price#373022 "Hi, Thanks for the very detailed report, it let us reproduce the problem immediately on our side. Your analysis is correct and it is a bug in HikaShop. When a coupon brings the total of the products down to 0 or below, HikaShop clamps that total to 0 and, while doing so, it was also dropping the whole tax breakdown of the cart. That is why the VAT line disappears from the checkout, and why the order is then stored without any tax information, which is what empties your tax report. As soon as one cent is left to pay, the breakdown is kept, which is why your first example is correct. We fixed it so that the taxes still due on the products are kept when the coupon covers everything. On your examples, the VAT will be 6,35 for the second one and 6,14 for the third and fourth ones. The fix will be included in the next version of HikaShop. We've also hot fixed it on the current release. So you can download the install package of HikaShop on our website in the My account>My subscriptions menu and install it on your website in order to get the patch. One point to keep in mind: this concerns coupons which do not carry taxes themselves, which is the case when the "Apply coupons" setting of the Taxes area of your HikaShop configuration is on "After taxes". With "Before taxes", the coupon lowers the taxable amount of the products, so a coupon covering the whole order does bring the VAT down to 0, and that stays unchanged.") 2 months 4 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1 Views:342 | [Last Post](/forum/40-taxes/910749-issue-vat-btw-when-using-coupons-higher-than-total-price#373022 "Hi, Thanks for the very detailed report, it let us reproduce the problem immediately on our side. Your analysis is correct and it is a bug in HikaShop. When a coupon brings the total of the products down to 0 or below, HikaShop clamps that total to 0 and, while doing so, it was also dropping the whole tax breakdown of the cart. That is why the VAT line disappears from the checkout, and why the order is then stored without any tax information, which is what empties your tax report. As soon as one cent is left to pay, the breakdown is kept, which is why your first example is correct. We fixed it so that the taxes still due on the products are kept when the coupon covers everything. On your examples, the VAT will be 6,35 for the second one and 6,14 for the third and fourth ones. The fix will be included in the next version of HikaShop. We've also hot fixed it on the current release. So you can download the install package of HikaShop on our website in the My account>My subscriptions menu and install it on your website in order to get the patch. One point to keep in mind: this concerns coupons which do not carry taxes themselves, which is the case when the "Apply coupons" setting of the Taxes area of your HikaShop configuration is on "After taxes". With "Before taxes", the coupon lowers the taxable amount of the products, so a coupon covering the whole order does bring the VAT down to 0, and that stays unchanged.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 4 weeks ago |
[](/forum/topics/feed/mode-topics?format=feed&type=rss)
Time to create page: 0.083 seconds
[Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)