Greg-Mega

I would potentially chip in for the development for this feature.

I'd be happy with that. Makes more sense, and is more in line with what other products do (Thinking things like Magento etc. as an example). What would be great also, is to be able to set a default country for the Order plugin, for us we never list the tax exclusive price so I've always had to modify the order templates to factor in tax before they get to the checkout and can see the breakdown. Being able to select a default country to determine the taxes and display the pricing based of the inclusive\exclusive setting would be able to keep everyone happy.

You sure that's right? Here in Australia (GST is 10%) Inclusive would be: Subtotal $3.00 GST Portion (10%): $0.30 Total: $3.00 Exclusive would be: Subtotal: $2.40 GST Portion (10%): $0.24 Total: $2.64 In your example you tell me 20% of £3 is £0.60 but it also tells me 20% of £2.40 is $0.60 and it's not, it's £0.48. EDIT: If the Blesta developers want someone from Australia that has a good understanding of Australian taxation I'll stick my hand up. Sales tax really shouldn't be that complicated though you've done the hard part in appeasing for cascading taxes it's just now a matter of straightening it out in my opinion.

I had issues with this after upgrading from version 4 to 4.2.2 the other day after running in Excluding mode since V2 suddenly it was calculating wrong in 4.2.2 but only on the preview screen when adding a service the invoice would actually be right else was right. Very confusing, needs some work that's for sure! Australian here so GST (our version of VAT) is handled in the same manner.

Isn't this already possible by editing the "Theme" under "Look and Feel". Down the very bottom is a field for a "Header Logo" which can be a URL to an image. This is the same for client and admin themes or are you talking about the fav icon or something else?

Do you have SPF & DKIM records for your domain? Gmail has got quite picky about these in the last 6 months along with O365. As you've removed your domain name from the headers I was unable to check this for you.

In my view there is nothing wrong with the tax calculation, it's the applicable tax on a coupon that's the issue to determine what it off-sets a taxable and non-taxable service. If it didn't apply them as negative values and subtracted from the service line it'd be all good and so would it if it passed in the taxable status of the service to the coupon line item that it applied to. Both would solve the problem, getting rid of the negative values would probably be more transparent while creating a coupon but the negative values is probably better for the customer/client for feel good factor only, doesn't mean anything other than it lists the figure they're saving. The subtotal being visible is a moot point. Milk $1.00 TAX Free Hosting Services $1.00 10% TAX Subtotal $2.00 10% Tax $0.10 Grand Total $2.10 Is perfectly acceptable. Would be GREAT if a Blesta dev could chime in here...

In theory you are right, it should be calculated on the sub total but there are cases where invoices have taxable and non-taxable line items which is what Blesta supports so it has to be the sub-total of the taxable goods - but is the coupon related to a taxable good or not? The Coupon is a negative value which needs to offset another line item (be it a taxable item or non-taxable item) so the Coupon line needs to know if it's offsetting it from a taxable item or not. That being said, probably the easiest way would actually just be to get rid of the coupon negative value, just have it subtract it from the actual service line item and append [Coupon XXXXXXX] to the line item and be done with the worthless negative values. In an ideal world were everything is either taxable or not then from the subtotal is fine eg. No Tax Product 1 @ $1.00 Product 2 @ $1.00 Coupon 50% Total invoice = $1.00 10% Tax Product 1 @ $1.00 10% Tax Product 2 @ $1.00 10% Tax Coupon 50% Total invoice = $1.10 Taxable and Non-taxable Product 1 @ $1.00 10% Tax Product 2 @ $1.00 Tax Free Coupon 50% <-Without this line knowing what the taxable status of the line item it's off-setting is, whats the expected final invoice total? Total invoice = ??? If the coupon was applied to both Product 1 and 2 ($2.00), the sub-total would $1.00 + What tax? What portion of the 50% discount went to Product 1? If the coupon was applied to Product 1 ($1.00), the sub-total would be $1.50 + 10% for Product 1 would give you a total of $1.55 (Inc. 5 cents Tax) If the coupon was applied to Product 2 ($1.00), the sub-total would be $1.50 + 10% for Product 1 would give you a total of $1.60 (Inc. 10 cents Tax)

Doesn't seem like a hard fix to me... If the service has tax applied to it the coupon discount should too so it calculates correctly. Then if the service doesn't have tax, the discount is applied pre-tax and all is good (eg. if I was selling Outside of Australia it would be an export sale and would be GST free) I can't see any issue with that but I'm not all that familiar with taxation in other countries. The only thing confusing about it is when creating the Coupon, it could do with a note there maybe about it being based on the pre-tax amount maybe, just maybe, you would only do it once then learn you're doing it wrong.

This seems like a bug, it doesn't appear I am doing anything wrong but I could be. In Australia the sales tax (GST) is 10% on the total amount of the goods or services. I have a service priced at $130.91 in Blesta so $144.00 including GST. This is all fine, have been using Blesta for a few years now V2 and now V3 but I've just started using Coupons. I've created a Coupon which adds a discount of $40.91 to the above mentioned so the end result should be $99.00. When I add a service and on the preview this is spot on: Sub Total: $130.91 Setup Fee: $0.00 Discount: $-40.91 GST (10.0000%): $9.00 Total: $99.00 However, once submit this the invoice that's generated is $103.09 because it's calculated in a different order than the preview. Preview = Sub Total + Setup Fee - Discount + TAX = $99.00 Invoice = Subtotal +Setup Fee + Tax - Discount = $103.09 (and the total GST is no longer 10% of the sale price anymore) So one of these ways is right, one is wrong, my view is the preview is right and the invoice is wrong seeing as Blesta uses pre-tax pricing, the coupon should be pre-tax with tax added to the final sub total. I can fix this manually by apply tax to the coupon line in the invoice, but that's not ideal for automation of renewal. Make sense?

It'd be good if it was configurable so this functionality could be enabled, disabled or enabled but only on paid invoices ie. invoices with transactions.

Could be way off the mark here but is your cron set up in cPanel? you're probably receiving the cron email notification from that? it's at the very top of the cron jobs screen. http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/CronJobs#Adding a cron email This sends you an email every time a cron job is executed and includes its output if any, just get rid of it (leave blank and select update) to set it as blank.

I think for Blesta to really succeed it needs to have the buy in from the users obviously, but it also needs both community and commercial plug-ins to be available which is already 100 times better than Blesta 2 every was. We've got users developing all sorts of things for Blesta 3 this time around. From what I can see also is that there seems to be a few developers who have caught on to Blesta 3 this time around, perhaps because of the open code base, it's well written although the developer documentation is still a bit thin in some places it can be figured out. As for the OP's post, I didn't think this type of pricing was all that hard to access these days? My new wholesaler is $8.70 AUD for .com's but that's in AUD and includes 10% GST (Australia's equivalent to VAT).

It's a character encoding issue between the WHMCS. When it comes out of WHMCS's database in latin1 it looks like this: 'Bećarović' When it's inserted into a UTF-8 charset table, you get this: 'Bećarović' This can be demonstrated by running the following in MySQL: SELECT CONVERT(_latin1 'Bećarović' USING utf8); Not sure of a really simple fix without running some complicated MySQL queries on your database. The importer should be able to be adjusted though, forcing a UTF-8 connection to the WHMCS database by using mysql_set_charset or the PDO equivalent which i think is 'SET NAMES 'utf8' COLLATE 'utf8_general_ci;' or the below: SET character_set_results = 'utf8', character_set_client = 'utf8', character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8' and that should be enough to resolve it during the import process.

I will if you PHPMyAdmin export your company_settings table.