Tyson

I see no reason the tax would act any differently. You can try to debug and see what your code is passing to Invoices::edit() and see if there are any abnormalities: if ($line->amount == 0) { $vars['lines'][0]['id'] = $line->id; $vars['lines'][0]['description'] = $this->getInvoiceDescription($fields->vs_id, "no"); } print_r($invoice); print_r($vars); die; $this->Invoices->edit($invoice->id, $vars);

Fixed in CORE-866 for v3.0.6.

Attached is the CC Avenue gateway for Blesta. Special thanks to Anoop at Nirays Technologies for creating the gateway and giving us rights to it. Because of CC Avenue's company policy of not providing test accounts, we are unable to test this gateway. So we are considering it an alpha gateway, and cannot recommend it for production use. That said, we would appreciate your feedback on its use. You can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the gateway under [settings] -> [Payment Gateways] -> [Available]. NOTE: If you use this gateway prior to v3.1 of Blesta, clients that pay with this gateway will be returned back to a blank page in Blesta, however, the payment should still be handled properly. ccavenue.zip

Yes, v3.1 has not yet been released, so those events are not usable with any version of Blesta currently available.

Yes, but what is the value of $invoice->id? 20? 25? 100? Hard-coding 20 or using an $invoice->id of 20 would produce the same result, so either the tax does not actually differ as you say, or 20 is not the value of $invoice->id. Where the invoice object comes from--basically the code before and after what you've shown already that puts it all into context.

What is the value of $invoice->id? Entering "20" works, but the invoice ID does not? It sounds like you're using an invoice that belongs to a different customer, but we would need to see more of the script that you're writing to determine anything else.

You need to make sure that the client is not tax exempt, and update your tax query parameter to be apart of the line item. Simply specifying a 'tax' parameter is not valid, as line items are taxed individually. In your example, you have a redundant "vars[lines][0][service_id]" parameter, and no "vars[lines][0][tax]" parameter.

Fixed in CORE-865 for v3.0.6.

Fixed in CORE-864 for v3.0.6.

Closing this as not a bug. You can create a feature request for any additions you'd like to see.

I'm moving this to the Feature Requests forum as it's not a bug. CORE-832 is currently scheduled for v3.1.

As Paul mentioned, it is a security risk to reveal information about users that do or do not exist based on such error/success messages. That said, there is a config setting in your blesta config file called "Blesta.default_password_reset_value" which regulates this. You may set its value to false to show any errors. I'm not able to duplicate this. Not entering a domain says that it is not available. But I'm using the sandbox, and maybe that differs from a live account.

I moved this to the Feature Requests forum, since this is not a bug. I can imagine, for some services, you may want to add the quantity back to the package, but certainly not for every package as MemoryX2 pointed out. There would need to be some feature that allows you to make such a determination.

Moving to Feature Requests forum, as this is an upcoming improvement and not a bug.

Fixed in CORE-858 for v3.0.6, which will be released soon. This issue can cause the cron to fail to finish creating invoices, so you may want to pre-patch yourself. Update /app/models/services.php and change: $service->package_pricing = $this->getPackagePricing(); to: $service->package_pricing = $this->getPackagePricing($service->pricing_id);

^This. In v3.1.0

It would be best to create a new thread for issues related to the module. A few commands that are issued need to be done sequentially, however, whether or not they execute that way is dependent on how quickly Proxmox handles them, and we don't know when that will happen. So it's more of a 'best effort' policy. Starting the server can still be done through the interface, though.

What version of MySQL, PHP, Blesta, and the Support Manager plugin are you using?

Added as CORE-858 so we can take a look into this issue.

What URL are you linking to? What is the value of $_GET?

Actually, since you're referencing the Support Manager plugin email templates, they are documented here. There is no {client} tag available to the template, which is why it is blank. And if you receive a response via email that generates the ticket, you would not know the client anyway. This may be a good feature request.

It doesn't. If you don't use the translator, then you need to maintain your own copy of the language files.

Check your module log under [Tools] -> [Logs]. There is probably an error mentioned in one of the responses being from Proxmox that would help identify what's going on. However, the empty red box looks like a language definition for an error that is not being displayed for some reason. That, or the response from Proxmox is nothing, and that is why the box is empty. You may want to confirm all of your Proxmox credentials are correct.

I'm not sure how cron jobs could have affected the client ID calculation. Has MySQL changed on your server? What version of MySQL are you having this problem with?

You can show the previous due, for example, in the "Invoice Delivery (Unpaid)" template: e.g. {% for invoice in invoices %} Invoice #: {invoice.id_code} Previous amount due: {invoice.previous_due | currency_format "USD"} Amount due on this invoice: {invoice.due | currency_format "USD"} {% endfor %} I'm not sure if you specifying the currency as a variable would work, but if so, it would be a better solution: {% for invoice in invoices %} Invoice #: {invoice.id_code} Previous amount due: {invoice.previous_due | currency_format invoice.currency} Amount due on this invoice: {invoice.due | currency_format invoice.currency} {% endfor %}