Tyson

Any refund is given in the currency it was paid for in. Buy something in USD and get refunded in USD. This is based on the transaction, not the service. Blesta doesn't reference the first currency ever used to pay for a service's invoice and then always invoice in that currency. You can set an override price/currency for a service, or upgrade it to a different term in some other currency, so it would be confusing to never be able to change the currency. And if you removed the currency from Blesta, or no longer accept payment in that currency, you would run into unforeseen problems creating/paying for the invoice.

You mean he had credits on his account and they didn't cover the invoice because it's in another currency? Makes sense. That may be another reason for converting currencies.

Nothing new on this yet. Cody will need to decide what he wants to do about it.

Everything in the video looks like normal behavior. If you had ordered the service in USD rather than converting it to GBP, the invoice would have been created in USD, and upgrades to it would be in USD as well because that is the currency set for the service term. Upgrades don't currently do any currency conversion, as I mentioned, and whether it should convert to the client's default currency is something we need to talk about internally. It may present some issues. If you had ordered the USD service in EUR, then a EUR invoice would be created. Upgrading the service would then create an invoice in USD. Would you still expect it to be in GBP? Invoices don't change currency after they've been created unless you do so manually. Prices changed are reflected when the service renews or when a new service is added.

Could you give an example scenario including your expected result, and the result that you encounter? If you order a service from the order form, I believe the invoice created for that service is in the service's currency. However, you can set it up to convert the service's currency to another, in which case the invoice will be in the selected currency. All config options attached to the service will be in the same currency.

The error seems pretty straight-forward. The credit card you're using cannot be processed successfully. Take a look at the Stripe documentation for more info.

All config options should be in the currency of the service they belong to. If they're not, then something's amiss.

Upgrades don't currently perform any currency conversion, and that is a known limitation. If, for instance, you upgrade a service from one term to another (e.g. USD to AUD), then the new invoice is in AUD because that is the currency of the selected term. I'm not sure if that should use the client's default currency instead. If you order a service from the order form, does it create the invoice in the service's currency, or the client's default currency? I think it's in the service's currency, and the order form supports selecting a currency, which will convert the service's currency to the selected currency, and use that on the invoice rather than converting it again to the client's preferred currency. So we may need to give more thought to how and when currency conversion takes place throughout the system.

SOAP is not working properly on the server Blesta is installed on for some reason. To see a more descriptive error, update /components/modules/interworx/apis/interworx_api.php and find: throw new Exception("soap_error2"); and change it to: throw new Exception("soap_error2 " . $e->getMessage() . "\n" . $e->getTraceAsString()); Then try it again. When it fails, look at the log output as you did in the first post.

The order process is handled by the Order plugin. The module does not come in to play until it is used to create the service remotely, and this doesn't happen until the service is activated. You could, however, use a plugin to tie into the Services.add and Services.edit events.

To clarify, the spinning icon denotes the task is currently running. If it runs for too long than seems practical it may be stalled due to error or timeout. In that case, the task doesn't formally end, and is forced to end after the 6 hour wait period. If you continue to encounter this, you will need to try to debug the issue with the cron task or what it is running to determine why it is unable to complete successfully.

From what you're describing, it sounds like you have multiple Blesta installations running, and the ticket is being created on the other installation. The number 1778632 is the ticket code. This number only exists if the ticket exists from which it is derived. I suspect your other Blesta installation uses the same support department email address. You updated the email template to add "#{ticket.code}" and you have neither the # symbol nor the actual ticket code in the subject line of the email the sender receives? If so, then we're sure the email is being sent from another Blesta installation than from the one you modified. Check for multiple installations of Blesta, multiple databases, and multiple cron jobs running. If you moved Blesta to another server, check the old server to see if it still has Blesta on it.

Zero quantity config options are removed in CORE-1676. However, removing $0 line items would remove all free items you have as well.

How are you making the payment for the invoice? How long are you waiting for the service to be activated? It can take up to the interval you have set for the automation task Provision Paid Pending Services (default 5 minutes). Check the dashboard System Status widget to see if there is any error with the cron running. The cron task that provisions paid pending services could be stalled for some reason, which may be why it is not automatically processing the service. I may not have been clear on that feature. That feature is only for queued service changes. For example, changing a service configurable option from one value to another. So the service would be active in both cases. That feature doesn't queue new services. See CORE-1634

Did you receive a separate email (at your admin email address) regarding the ticket? Does it have a code? If so, does it exist in the database? Try to update the Ticket Received email template again and include "#" before the ticket code, i.e. "We have received your ticket #{ticket.code}". Send the email and wait for the reply. The ticket code may not appear, but does the "#" symbol? Also, what version of Blesta are you using (can be found in the footer of the admin interface)? And what version of the Support Manager (can be found under [settings] -> [Plugins] next to the Support Manager)? If you're not using the latest versions, you can try updating it to the latest version to see if that makes a difference.

After you receive that error, head over to the module logs under [Tools]. Click on the table row for the latest log, and raw Input/Output data will be shown. It may give you more information on why the error occurred and what needs to be done to fix it.

Services are activated via cron from the Provision Paid Pending Services task. Details on this task (how often it runs, if it's enabled, etc.) are available under [settings] -> [Automation]. If an invoice is paid in full, then the service to which it belongs will be provisioned when the cron runs that task. If there are errors preventing the service from being activated, you can check the logs under [Tools] -> [Logs] for more information. If your service activates from a remote call to a module, then the Module Logs will contain information on the attempt. Otherwise, looking at the cron logs will help you determine whether or not the cron task has been run.

Then the ticket was deleted. Since the Support Manager plugin does not provide a way to delete tickets, the ticket must have been deleted manually from the database. However, it doesn't seem likely to me that it was deleted. I suspect that you are indeed not looking at the right database, or that you're unable to find the ticket from the table. You can run the following query on the database to retrieve the ticket you mentioned earlier in this thread: SELECT * FROM `support_tickets` WHERE `code` = '2539495'; If no records are found, then yes, it either has been deleted, or you're searching the wrong database. You can try testing this again to see what is going on: 1. Determine the current auto-increment ID from the `support_tickets` table. You can find this value by running the following query, but make sure to first replace "DATABASE-NAME" with the name of the Blesta database: SELECT `AUTO_INCREMENT` FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'DATABASE-NAME' AND TABLE_NAME = 'support_tickets'; Make a note of the number that is returned. 2. Update the "Ticket Received" email template to include the ticket number in the Subject line. Go to [settings] -> [Emails] -> (edit Ticket Received). Update the "Subject" line to include the tag: {ticket.code} Save the template, then email the support department another ticket. You should receive a response email that the ticket was received, and the subject line should contain the ticket code. 3. Take the ticket code number from the subject line of the Ticket Received email you got in step #2, and search the `support_tickets` table for that ticket. Does the ticket exist? 4. Run the query in step #1 again. What is the number returned? Does it differ from the number you got before?

If you're on an order form purchasing a product with zero cost, the order system currently continues onto the payment step. This is unnecessary, and is updated in v3.5.0 (currently in beta) to skip that payment step altogether. As for a zero due invoice--they are marked Closed immediately because only unpaid invoices with positive amounts due can be open. The invoice is still accessible, and can be found after clicking the "Closed" link at the top of the Invoices table in either the admin or client interfaces. Are you expecting zero due invoices to remain open?

That email content is used in the Staff Ticket Updated email template, which is the email sent to staff to notify them that a ticket was opened. The fact that details about the ticket are available, like the ticket number, status, priority, etc. indicates that the ticket was indeed created. Record of the ticket will exist under `support_tickets` and `support_replies` unless it has been deleted. If it doesn't exist, either it was deleted after the email was sent, or you're looking at the wrong database. As for the client being unable to reply via email, that could be because the associated ticket was already deleted, because information is missing from the Subject line of the email the client is replying to, or because of support department settings that you have configured.

What are your settings for Payment Due Notices? Check under [settings] -> [billing/Payment] -> [Payment Due Notices]. You may have the client group overriding the company values, so be sure to also check under [settings] -> [Client Groups] -> (edit a client group). Is the cron task for Payment Reminders enabled under [settings] -> [Automation]? Has it run recently? Do clients get these notices? You could check under their Mail Log to see.

I'm not familiar with the behavior you're describing. Blesta doesn't cancel unpaid invoices. However, in v3.5, it would be possible for invoices created for queued services to be voided if not paid within a few days. What happens to the invoice exactly? What status is it changed to?

I'm not sure if you were being sarcastic, but using DNA as a password would be a hacker's dream come true. You shed DNA all over the place (hair, skin, spit, etc.) and it would be trivial for anyone to get ahold of it. The general "rule" is that if something uniquely identifies you, it could be a username, but not a password.

Thanks. CORE-1689

This is fixed for v3.5