Jono

Not sure you could do that if you wanted to keep the client and simply make them inactive.  A client without a contact seems problematic.
If you are looking for relations on the client_id then there are some others.
module_client_meta - Blesta Core client_notes - Blesta Core client_packages - Blesta Core client_settings - Blesta Core client_values - Blesta Core reseller_pricing_clients - Reseller Pricing support_tickets - Support Manager You should also be concerned with tables related on the contact_id
accounts_cc, accounts_ach - Blesta Core contact_numbers - Blesta Core contact_permissions - Blesta Core log_contacts - Blesta Core support_replies - Support Manager download_logs - Download Manager mass_mailer_tasks - Mass Mailer I think that covers everything you missed.

Not sure you could do that if you wanted to keep the client and simply make them inactive.  A client without a contact seems problematic.
If you are looking for relations on the client_id then there are some others.
module_client_meta - Blesta Core client_notes - Blesta Core client_packages - Blesta Core client_settings - Blesta Core client_values - Blesta Core reseller_pricing_clients - Reseller Pricing support_tickets - Support Manager You should also be concerned with tables related on the contact_id
accounts_cc, accounts_ach - Blesta Core contact_numbers - Blesta Core contact_permissions - Blesta Core log_contacts - Blesta Core support_replies - Support Manager download_logs - Download Manager mass_mailer_tasks - Mass Mailer I think that covers everything you missed.

Ok thank you for your help, I will try this out tomorrow on my test installation.

This should be included in the default behavior.  When a client has credit a check box labeled 'Apply Credit ([credit_amount] Available)' should appear under the dropdown labeled 'New Payment Details'.   If you have no payment methods available for that order form then the 'Apply Credit' option will not appear.  Again, it will only appear if the client actually has credit.

Haha yep, I definitely read it as credit card.  Let me take a look and I'll give a clear answer to your actual question X)

The answer to you first question is no, we do not currently integrate with paysafecard.  As to how much effort it would be to do that, it really depends on how good the API is and what functionality you want to support.  Usually just receiving payments is not terribly hard to implement.  To get an idea of what is involved you can look at https://docs.blesta.com/display/dev/Payment+Gateways.  Additionally you can look at the existing gateways either on our github or in the file system under components components/gateways/.  If you want to get a developer to produce this for you or give you a quote, you can find a list here.  Each of them are here on the forums and you could send them a PM.
Your second question has a bit easier and more satisfactory of an answer.  First, make sure you have a merchant gateway installed (e.g. authorize.net, stripe, etc.).  Then when you add an order form  at admin/plugin/order/admin_forms/add/ check to enable the merchant gateway and currency you want.  After that you customers should be presented with the option to pay with credit card on checkout .

Are you referring to the module logs?  These are stored in the database in the 'log_modules' table and can be viewed through the interface at admin/tools/logs/module/.

Are you referring to the module logs?  These are stored in the database in the 'log_modules' table and can be viewed through the interface at admin/tools/logs/module/.

Are these settings being overwritten by the client group settings?

Evening update.
Myself and Beav @GosuHost have been hard at work on the hard parts I've been stuck on and helping me with my cockups.
Live Video: https://screencast.com/t/sUBbD3xqPm

Previews:
Forums now show the parent category in the admin area. (still 2 bugs on the admin edit we'll need to look into further though)

 
Now you can view the threads in each forum:

If there isn't any threads they show an error:

And we've got the Add new thread form sorted (just need to get the actions working and linking it up with each thread so it's posted to the correct forum, with the thread owner):

Thank you guys I've finally got where I want almost  just need to fix that routes as it's working at the moment via forum/index/1/ but not /forum/1/ so I need to use the client_loc and plugins and then the folder name I think  

You can disable it telling it's correct but it does that to stop brute forcing. eg: I hacked your email account, and I know you have an account so I keep trying everything until it goes to your email address.
Disable it: /config/blesta.php
find:
// Default password reset value. Set to true for improved security, false for more accurate error reporting Configure::set('Blesta.default_password_reset_value', true); change it to false.

Tools >> Logs >> User Logins.  Hope that helps

sorry for the long delay in replying
i could make the gateway a non-merchant BUT it means the customer has to pay for the invoice themselves and i cant let blesta take the payments etc itself without me doing anything
the gateway is sadly 'GoCardless' which handles UK Direct Debits
if i was to set it up as non-merchant, and a user bought a plan, gocardless wud need 3 WORKING days to setup the account and DD then 3 WORKING days to take the payment, then i would have to manually go into blesta and select the user had made a payment because i cant get gocardless to notifify blesta of a payment without using there PRO PLAN which costs £200 a month ONTOP of ur fees
i have however tho through of a way, so im going to get building and see where i end up
dont gocardless as a payment gateway, just doing it as a plugin or module
go into the customer, click a custom button which then created the gocardless account and mandate, and returns back to the blesta panel without any issue, then on the cronjob, once a day check for outstanding invoices that havnt already been tried to taken, and then go from there
but its going to be a trial and error, so onwards and upwards

Probably the most straight forward solution would be to change the status of the ticket when you reply.  Likely you would change it to "awaiting reply".  Then after the client replies it will automatically be transitioned back to the "open" status.

Does Would create another issue, the logical when proforma is created it should be counted in invoiced today, if paid shouldn't been counted as is already counted . if we exclude the proforma from being counted it would show a erroneous data as it would show only who was paid.
if you ask me a suggestion for this, in case of no proforma enabled let the stats as it now, but if proforma enabled, remove the invoiced today based on invoice created today  and replce it with invoiced Today based on proforma status only, i hope it's clear .
why? any invoice when the proforma is enabled it should be paid totally . so the invoice can't be with open status.

Are you familiar with the tags employed by the email templates?  You can find a list of tags for each email template in the docs here.  Particularly the Invoice object tag under 'additional tags' sounds like it will be useful to you.  For example you can include the invoice total in the email using the tag {invoice.total}

thanks @gosuhost all works fine now

Run upgrade via cli. I had same issue until I rerun the upgrade a second time

Okay I believe I identified the source of the problem and this should be a hotfix. Starting on line 1393 in app/models/invoices.php there should be this code:
if ($i == 0 && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) { Change that to:
if ($i == 0 && $allow_pro_rata && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) {  
This fix will be included in 4.2.1

Okay I believe I identified the source of the problem and this should be a hotfix. Starting on line 1393 in app/models/invoices.php there should be this code:
if ($i == 0 && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) { Change that to:
if ($i == 0 && $allow_pro_rata && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) {  
This fix will be included in 4.2.1

Currently that is not allowed in the system, since this would render those invoices and transactions inaccessible, thereby messing up reports for sales and revenue.  The only way to do a full delete on a client who has these things would be to modify the database directly.  NOTE: If you do decide to modify your database, absolutely back it up before making any changes.

Thank you! Was able to get this going.

Just FYI, if anyone is interested in buying any BTC, LTC, or ETH on coinbase.com you can sign up with this link and if you deposit $100 or more both of us will get $10 in bitcoin. https://www.coinbase.com/join/5a1a0e84942a40026d012e3f

That wasn't the case with us this time but I could see where your example could be another issue. The server that the service was assigned to has been maxed out for a long time now (6+ months).