Paul

I updated that thread with a possible solution, please give that a try.

Doesn't this work the same way as cPanel? If both servers are in the same server group in the module, then when you click to Manage the service as an admin on the clients profile page, you should have a drop down and be able to select the new server and save it.

Are they using root or a reseller user? If a reseller user, the user may not have enough permissions. Have you checked the cPanel/WHM logs? I don't recall what the log file is called, but it may be in /usr/local/cpanel/logs or /var/log/ or /var/log/cpanel.

The hostname should not contain protocol or port, just something like "server.host.name". If "Use SSL" is checked, it will attempt to connect to cPanel/WHM on port 2087 over HTTPS. If not, port 2086 over HTTP. Please ensure these ports are open at the firewall egress. Also make sure that CURL SSL is in your PHP. It's more obscure, but some people have had DNS resolution issues on their servers, so you could check for that also.

Good discussion. Definitely would need a module written for Blesta to interface with the SmartHosting Domain API.

Multiple groups would allow more control, but what if on the "Add/Edit" custom field form, the Client Group dropdown had an "All Groups" option? I wonder how difficult it would be for such an option to be observed by the rest of the system. When fetching custom fields for a client group, fetch ones that match all/null/whatever the field is called *and* ones specific to the group.

Does the customer who is getting the incorrect emails also have their email address listed as a billing contact under the other customer?

Congratulations!

Blesta has an exchange rate system that uses Google Finance, Yahoo Finance, or Foxrate that can be configured to update automatically under Settings > Company > Currencies > Currency Setup. Your plugin could use this, which would simplify it some. The plugin can register an automation task in Blesta to look up the invoices and perform an API request. Good luck!

What would be a use case where you would want a $0 invoice? And, what are the consequences of having a $0 due invoice if you accidentally submit a proforma invoice with a 0 balance? It is simple for us to say, if invoice type is proforma, and amount is 0, do not convert to invoice. But, it is more difficult to pop up a modal box and request action from the staff member. Also consider that the system could potentially generate a $0 proforma invoice itself, and manual intervention is not possible. We want to go with the simplest solution that works in as many cases possible.

Nice work @PauloV!

Your mockup is good @Licensecart, the reason should be displayed in the expandable area like this anywhere cancelled services are listed. The color likely would not be red, but it should be in there. I've updated the task with some more details. CORE-590

There are some changes planned for simplifying packages, including not requiring a module to be specified. What people do now is go to create a package, and realize that they need to at least install the Universal Module and create a Universal Module product. That's a pain. There are other changes also, the Package create/edit page layout is going to change significantly. We also plan to allow modules to define "default" welcome email content, so you can get up and running more quickly and tweak it later as needed.

How should this be handled? If the invoice is not positive, then close it but leave it as pro-forma?

Thanks for starting this thread PauloV, makes it easy to see everything in one place. I'll be going through this in more detail shortly to ensure we have a task for anything outstanding. Looking forward to the VAT MOSS report, many will thank you!

Jonathan is right, and you can get the full release for 3.4.3 at https://account.blesta.com/client/plugin/download_manager/client_main/download/63/blesta-3.4.3.zip Back up your database & installation files first. Your database and /config/blesta.php config file are very important. I'm not aware of any duplicate invoice issues. I would double check that you don't have 2 crons running, that there is just one service or group of services that are being billed and that there isn't also a recurring invoice. If you have any custom code or 3rd party extensions, I would suggest disabling them temporarily to try to rule them out.

Yes, thanks @serge and glad it's working for ya!

Do you see the transaction in Blesta? Was an invoice paid, or was payment made without an invoice specified? If the payment was issued as a credit in Blesta, then it would by default be applied to invoices when the cron runs. If a specific invoice is paid, then it should be applied immediately. I'm assuming the client clicked the PayPal button within Blesta also, correct?

I take it that helped? Awesome!

I believe it defaults to the companies default currency. Do you accept both USD and CAD? If only CAD, you can remove all other currencies under Settings > Company > Currencies > Active Currencies, and it won't have any other choice but to show CAD.

If you have an owned license with us, open a ticket to request a dev license and one will be issued. I'm personally not familiar with CarrotPay enough to recommend anything you can do in way of security, Cody or Tyson may be able to. Generally though, if a payment is made in a different currency then it'll be recorded in that currency. Since the invoice currency and the transaction currency do not match, the transaction cannot be applied to the invoice. I've seen orders come in via PayPal and they change the form to say 5 cents and make a payment. Blesta records 5 cents and applies it to the invoice, but the invoice is not closed because it's not paid in full. That's just an example, but Blesta is pretty smart about these kinds of things.

If you have suggestions on how this would look/work let's open up a discussion. The task doesn't have any real details, and those need to be worked out before it can be implemented.

Looking good, thanks for sharing! I also like the client # in the header. I believe we have a task to add that in there someplace.

Did the debug tag dump everything out, including the URL? What kind of web server are you running, and what version of PHP?

For whatever reason it sounds like the {payment_url} tag is not available to the template when run via your web server. That's interesting and unusual. You could add the {% debug %} tag to see if that's all that's missing, maybe gain some insight to the issue. But be careful, you don't want any emails to go to customers with that tag as it may contain sensitive information.