Cody

The current version of the WHMCS migrator doesn't link SolusVM services with the SolusVM module in Blesta, so they're imported using the Universal Module. The pricing issue sounds strange. What version of WHMCS are you using?

A URL is supposed to be a logical resource, which is how they're built in Blesta. It's sometimes nice to have sort URLs, but that usually requires removing information about a particular resource, making it less logical. Logic aside, as-is, I think they are quite pretty. Much prettier than say, "cart.php?template=foo&package=12".

Or could be an option within the reply section of the ticket, e.g.: After replying: [ take me back to ticket listing | stay on this page ].

Encoding is different than escaping. Don't have time to pull up the html spec, but this might help clarify: http://stackoverflow.com/questions/3705591/do-i-encode-ampersands-in-a-href.

"index.php?foo&bar" is the correct way to encode URIs. Are you saying the URI is doubly encoded (as in "index.php?foo&bar")? That would be a problem. Your fix, from what I see, would open the system up to XSS.

Another thought: you could allow cron to provision as it runs outside of apache and so should not be affected.

Unfortunately, there's no workaround. Plesk is killing Blesta while it's in the middle of performing a task. If you could configure plesk not to restart apache, or if you ran blesta under a different web server (nginx/lighttpd/etc.) or entirely separate server you probably wouldn't have any problems.

NACHA applies to payment gateway processors. Blesta will never be a payment gateway processor, so it will never implement NACHA standards.

Yes, we're well aware of that. The difference is that ACH is processed through a payment gateway, and are submitted individually not as a batch.

Sounds like all you need 2 things: SEPA XML - See CORE-1164. Transactions to appear on invoices, and liken this term to "Statements". That's not a feature request I can ever remember seeing, but it's super simple to do. Blesta supports what are called Invoice Templates. An invoice can contain whatever you want using a custom template. Because Blesta must support as many localities as possible, we sometimes have to work around issues which may produce legal compliance issues for our customers otherwise. This usually results in more generic default behavior, but if you play around with Blesta for a while you'll discovered that no other system is as flexible or customizable. If you feel there's something you're missing, there's a good chance other people may feel the same way, so it's always a good idea to make a feature request.

You have the contact_id, you can load the Contacts model and call Contacts::get(). Actually, looks like that isn't passed through after all. Will look into adding it. Error because the payment can not be processed until the mandate is set. This is equivalent to submitting a payment without a credit card number. I see, so you would need some utility within the staff interface to download the SEPA XML file for all payments that should be processed? This, obviously, makes it impossible to automatically process bank transfers since they can not be processed through a payment gateway. This is just like batch payments, except instead of automatically processing the batch an XML file is built. Looking at the format of the XML document, 100,000 transactions would probably be a 50 MB file.

Thanks. CORE-1165.

Company name is under the client's account.

If this must be unique, should it be automatically generated by Blesta? Or is there another system you use that generates the agreement document with this value? I wonder if this could work as a custom client field. This might work as a custom client field. Sounds like billing details that are already recorded for all payment accounts, with the exception of OrganisationIdentification and PrivateIdentification. If a mandate is required to process payment, why not just prevent the account from being included in any SEPA XML created? I see no reason to prevent clients from entering their payment details when creating an account. If the mandate is a custom field only available/visible to staff then there is no way that a payment can be processed without a mandate value being entered, regardless of whether or not there are bank details recorded for that client. Other questions: Where is this SEPA XML document submitted? Are these documents expected to be submitted in batches, or can they be submitted separately. For example, you have 1000 transactions to process using direct debit. Can you submit 1000 SEPA XML documents, or must it be one single SEPA XML document containing all 1000 transactions?

That's their nonmerchant gateway. This looks like their CC processing API Looks like this is their bank transfer API, but requires you to set up a "per invoice" recurring record, which you then call for every invoice you wish to process. Wonder if that would be problematic when attempting to pay multiple invoices at once? Kind of a bizarre process, obviously one-time debiting was an after thought. So what's is the process of splitting the account/routing number into the the four fields?: Bank Code Branch Code Account Code Suffix Code This particular gateway doesn't look like it requires any changes to Blesta. I'm more interested in seeing a payment gateway that requires additional fields as OP suggested are required for European bank transfers.

Can you reference any payment gateways that require such fields? Specifically we're looking for documentation for gateway APIs that require these fields to ensure/verify maximum support across all payment gateways.

Version 3.2.0-b1 is now available. You can download it in the Client Area. This is a BETA feature release. This release is not considered stable enough for production use. Please report any bugs in the 3.2 beta bug forum. Installing Blesta See Installing Blesta in the User Manual for instructions. Upgrading Blesta See Upgrading Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.2.0-b1. For older releases see all Change Logs.

The screenshots don't do it justice. These new order forms are incredible, and we've designed them to be super flexible. We didn't just slap together a few order form templates and toss them in. There's a lot of engineering and user expeirence design put into this release. The end result is pure awesome, and the best order forms in the industry by far.

No, why? This is a refactor todo, has nothing to do with functionality.

Create a plugin that does what the ClientInvoices::view() (/app/controllers/client_invoices.php) does.

Version 3.1.3 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.1.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes - Blesta Core - Version 3.1.3 ## Version 3.1.3 2014-03-27 ### Bug * [CORE-1074] - Support Manager: Some characters may be stripped from tickets emailed in to the system * [CORE-1077] - Support Manager: Email parsing fails if content-disposition is inline * [CORE-1078] - Support Manager: Improper character encoding conversion with subject line decoding * [CORE-1080] - The term for add-ons is displayed blank in the service expanded area * [CORE-1081] - Undefined property: AdminUpgrade::$Session when in maintenance mode * [CORE-1087] - Deleting a draft invoice does not show a success message * [CORE-1088] - Missing language for Admin Company General Localization widget title * [CORE-1095] - Client group setting "Auto Debit Days Before Due Date" missing "Same Day" option * [CORE-1097] - Support Manager: Incorrect date format in upgrade * [CORE-1104] - Editing a package sometimes results in an error message about missing pricing terms when no pricing terms have been removed * [CORE-1105] - Order System: Packages with a quantity available of 0 are still available for order * [CORE-1110] - Support Manager: Closing a ticket may cause formatting error on date_closed --- See all Change Logs.

Blesta bumps the renew date when the invoice is created, and this is for a very good reason. Suppose you had a service that renewed every day, but you invoice 3 days in advance. On March 25 you invoice for March 28, On March 26 for March 29, etc. If the renew date didn't advance until the invoice is paid then the March 26 invoice couldn't be generated until after the March 25 invoice is paid. Moreover, if the user failed to pay within 24 hours then all future billing would be X days off (where X is the number of days the user took to pay the last invoice). I think you might be thinking about "renew date" in the wrong way. Renew date is when a service's NEXT invoice should be due. It is not when a service's current invoice should be due.

I'd suggest making a feature request and include a sample invoice with detailed explanation of each section the way you and your customers would expect. Regarding the rounding issue, is the total displayed as "$100.01" in the PDF only, or also within the interface?

Closing as not a bug. If you're able to reproduce the issue and can provide steps to duplicate as described in How to Report a Bug please start a new thread.

That's not how Blesta works, but feel free to make a feature request if you'd like. If Blesta worked this way, services would renew at bizarre intervals, and the user would be able to control renew dates based on when they feel like paying. Sounds like a big a headache. I have not been able to duplicate this, but attempting to change the renew date of a service from some date to a future date should always work. Are you able to reproduce this continuously (that is, at various times of day: morning and evening)?