Tyson

Based on your video, i see that your service recurs over a 1 day period. Blesta invoices a service X days before it's renew date as defined in [settings] -> [billing/Payment] -> [invoice and Charge Options] for "Invoice Days Before Renewal". If you add a recurring 1-day service whose renew date is tomorrow, i.e. The service start date is March 24 and renews March 25, then with an invoice setting of 5 days before renewal, the system will catch up on invoicing for the next 5 days. e.g. March 24 - 25 (bill today). The 25th is one day from today, so the setting (5 days before renewal - 1 day from today) = 4 days. This service would normally have been invoiced 4 days ago. Because it wasn't, it is invoiced now. March 25 - 26 (bill today). The 26th is two days from today, so the setting (5 days before renewal - 2 days from today) = 3 days. This service would normally have been invoiced 3 days ago. Because it wasn't, it is invoiced now. March 26 - 27 (bill today). The 27th is three days from today, so the setting (5 days before renewal - 3 days from today) = 2 days. This service would normally have been invoiced 2 days ago. Because it wasn't, it is invoiced now. March 27 - 28 (bill today). The 28th is four days from today, so the setting (5 days before renewal - 4 days from today) = 1 day. This service would normally have been invoiced 1 day ago. Because it wasn't, it is invoiced now. March 28 - 29 (bill today). The 29th is five days from today, so the setting (5 days before renewal - 5 days from today) = 0 days. This service should be invoiced today, so it is invoiced now. March 29 - 30 (bill on the 26th). The 30th is six days from today, so the setting (5 days before renewal - 6 days from today) = -1 days. This service should be invoiced in 1 day. March 30 - 31 (bill on the 27th). The 31st is seven days from today, so the setting (5 days before renewal - 7 days from today) = -2 days. This service should be invoiced in 2 days.

Thanks for bringing this up, and for including the term that led to the error. We'll look into the problem shortly.

Can you provide an image you're attaching to a ticket that doesn't display when viewing it from the Support system? It could be that the image is, or has become corrupt, or that your 'picture manager' isn't able to render it properly.

Support ticket replies received by email are rate limited to 5 emails per 5 minute interval. If Blesta receives too many ticket replies, it will stop emailing out ticket replies to the offending email address. What may be happening is the email received is not created as a ticket or ticket reply, and instead generates a bounce email, and I don't think bounces are rate limited.

If you haven't been able to resolve this yet, I would enable error reporting in Blesta, and then run the cron manually to see if there is an error being encountered. Alternatively, you could take a look at your web server/cron logs to see if an error was encountered that prevented the task from completing. If you'd like to manually reset the stuck cron task, you can follow the instructions I outlined here.

It seems like the module row setup for the Namecheap module package cannot be determined. You mentioned you re-saved the package--which should have resolved the issue--but you may need to confirm that the Namecheap option for "Account" is selected on the package, which identifies the appropriate module row you have configured for the Namecheap module.

Renewal pricing has to be derived from each service separately. In the case of one-time services, there would be no renewal pricing. Also if we were to create a table column for listing expected renewal pricing, it would not be a sortable field.

The logs look correct. Does a transaction exist in the system for that $30.00 from PayPal?

It sounds like you may have the same issue as edunjoroge, where no connection could be established over the API because the servers were not able to negotiate which encryption algorithm to use. You could either add support for additional algorithms on your server, which the eNom server also supports (whatever they may be), or you could disable SSL with the sandbox entirely. The latter is the simplest work-around that edunjoroge used, but it means that all sandbox actions will be performed over HTTP, insecurely. It would be possible for listeners to view your sandbox credentials in plain-text. If you wanted to try disabling SSL altogether for the sandbox, update /components/modules/enom/apis/enom_api.php to change the sandbox URL protocol from https to http. i.e. change: const SANDBOX_URL = "https://resellertest.enom.com/interface.asp"; to: const SANDBOX_URL = "http://resellertest.enom.com/interface.asp";

The error appears to indicate that you used the tag "{package.*}" in your welcome email's HTML section for that package. Tags may not contain asterisks, hence the error. If you were using v3.4.2 of Blesta, you would receive an error when attempting to save the package because of this issue. The asterisk used in the tag is only informative in that it indicates that "any" field could exist, and the package email is not aware of what specific tags are available. I think you're using the Universal Module, so you would need to consult the product you created for that module, and only use the tags that represent the package/service fields you have explicitly defined.

Recovering encrypted data requires your system key (stored in your Blesta config file). Without it, the data is unrecoverable. Additionally, if you set a private key passphrase, certain encrypted data (e.g. credit card numbers) will need that entered as well to decrypt data. "How" to recover the data depends on your situation and what you're trying to do. Blesta already provides methods of decrypting data via the interface, such as to view a credit card number, which occurs automatically. If you want to decrypt all system data, for example, it may be best to write a short custom script to do so. If Blesta is still installed when you want to do this, you can have a developer call AppModel::systemDecrypt on each encrypted field.

It should be very similar. You will still create a package, however, when you select the module, you will choose the Universal Module and then select the product you created in the Universal Module. e.g. Go to [settings] -> [Modules] -> [universal Module] (Manage). Click "Add Product" Enter a Name for the product, e.g. "Recurring Fee" Save the product by clicking "Add Product" at the bottom. You can ignore all of the other package/service fields if you do not need to specify any custom information. Go to the [Packages] tab. Click "Create Package" For the "Module" field, select the Universal Module. An option will appear to then select a Universal Module product. Select the one you just created (e.g. "Recurring Fee"). Fill in the remaining package fields (I assume you already know how--I described an example in a previous post) Create a Service for a client, and choose this package you just created. An invoice will be created based on the pricing you have configured. It will then continue to be invoiced on a recurring basis based on that pricing

I think you do not want to create a recurring invoice, and instead just create a recurring service, which will automatically generate invoices as it recurs (based on your billing settings). If I understand your scenario correctly, I think you would need to create a one-off invoice for the one-time fee for the project completion cost. Then, use a recurring invoice (or create a service) that renews monthly to bill the recurring fee.

Yes, it is redundant and will result in duplicate invoices (1 created from the service renewing automatically each month, and 1 created from the recurring invoice). You can remove the recurring invoice and just allow the cron to handle invoicing based on each service's renew date automatically.

I think we have an understanding of the issue and will be providing an update to the module to address it soon.

We've only had a handful of requests for BrainTree, so the demand is a little low for us to integrate it yet. But I created a task for us to look into it in the future (CORE-1598).

No, it looks like the invoice line item is correct for that order, considering your pro rata settings. Since pro rata is enabled, the system will bill from now until the pro rata day. Your pro rata day is set to 1, i.e., to the first of the month. So one line item will be prorated from the order date (Mar 14) until the first of the next month (Apr 1). The pro rata cut off day indicates a day of the month after which the service should be billed for its full term. Because you have the cut off day set to the 15th, and ordered on the 14th, the cut off does not take effect. This behavior is also noted in the documentation. If you ordered the service on the 16th, then you would have a line item for the prorated cost from Mar 16 to Apr 1, and also another line item for the 3 months Apr 1 - July 1.

That depends on user demand, how useful we find the feature to be for Blesta compared to other features we have in queue, how much time we think it will take to complete, and whether it can be fit into our schedule for a particular version. We can't really be more specific than that until after the decision has been made.

When the invoice delivery 'email' option is set for an invoice, the email is sent the next time the cron is run, and it is only delivered once. If sometime later the invoice is paid, then no other email is sent because it had already been delivered. We have a task scheduled to re-queue pro forma invoices for delivery again after payment (see CORE-1561), but it has not been completed yet.

What would the other 10% of the problem be?

You will either need to have everything fully translated into French, or ensure you have defined French email templates and that the client's default language is in French.

Do you have a French email template defined for the "Ticket Updated" email template? What is the client's default language? The system will default to English in either case. If you do not have email templates defined in the default language, English may still be used since that is all the system knows to exist. You can update your system to set French as the default fallback language by updating /config/core.php and changing Configure::set("Language.default", "en_us"); to Configure::set("Language.default", "fr_fr");

Are you wanting to redirect a client after they logout from Blesta, or before? If before, you can setup a 301 or 307 redirect via .htaccess. If after, then you would need to update the appropriate controller in Blesta (e.g. /app/controllers/client_logout.php) to change the current redirect.

Yes, after you encounter the error, go to the logs as shown in your screenshot, and click on the top table row. Then a list of Input/Output API logs will be available.

I think Java security requirements are much higher than they were previously. You may need to add your site to the security exception list from your Java Control Panel before the console will load. Ideally, we'd like to setup an HTML5 version of the console instead.