Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/19/2018 in all areas

  1. This is other real case that show blesta need to be adapted for hosting industry. if i have a client that is ready to pay for extend his service to 12 MONTH , blesta bill him only for what the diference between now and end date of the actual term . so if teh end date of the term is in the next 3 month, we will cover only 3 month, and after maybe his can change mind and do not renew !!! and before he was ready to pay for 12 month so we will lose 9 month of payment only because blesta do this like this !!!! Normally blesta should do us the fallowing : Calcul how mush we should return to the clients as credit to make the end date now create new invoice for the ne full term, and and the credit to invoice, allow client to pay then update the renew date to reflect the Now + the ne term chosen . and of course it should make in consideration that the actual term is monthly and the old term is yearly ect ...
    2 points
  2. This makes very little business sense. If a customer is ready to upgrade and pay, they should be invoiced right then. Either pro rated for 1 month and charged the full rate for 11 months or pro rated for 1 month and charged for 12 months but it makes no sense to wait until the end of the month to invoice for that new term (12 months in this case)
    1 point
  3. I have been using Blesta for many years (I've been storing up my feature requests for years too - sorry!) and I know that this topic comes up from time to time, however, I would like to give what I believe is a strong case as to why it should be allowed to delete clients. Firstly, I realise that it is not possible to delete clients if they have an invoice or service attached and I believe that the reason for this is for accounting purposes in particular geographic locations (one of them being the UK it would seem). However, in the UK we also need to comply with Data Protection laws. This says that we must not retain personal data for longer than necessary. See here: https://ico.org.uk/for-organisations/guide-to-data-protection/principle-5-retention/ According to the above page, we are allowed to retain the data if required for tax returns and this will not be considered to be retained for longer than necessary. So far so good...but according to my research, HMRC says that you only need to keep your business income records (including sales invoices) for 5 years after the submission of the tax return: https://www.gov.uk/self-employed-records/how-long-to-keep-your-records Therefore, my feeling is that UK businesses should be removing the client records after 5 years of them ceasing the relationship with the business, thereby complying with the data protection act that says that you must not retain personal data for longer than necessary. This is how I interpret the law and in my opinion this makes a much stronger argument for the necessity to be able to fully delete client records from Blesta. Also submitted to: https://requests.blesta.com/topic/delete-client-for-data-protection-reasons (posted here for awareness)
    1 point
  4. timnboys

    Directadmin module Bug

    I fixed the bug by doing this in direct_admin_api.php: 'suspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Suspend','location'=>'CMD_API_SELECT_USERS')), 'unsuspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Unsuspend','location'=>'CMD_API_SELECT_USERS')), from: 'suspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Suspend','location'=>'CMD_SELECT_USERS')), 'unsuspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Unsuspend','location'=>'CMD_SELECT_USERS')), that was likely a oversight on the blesta dev's part but is actually easily to fix as shown above, since directadmin's api information here: http://www.directadmin.com/features.php?id=807 states the default CMD_SELECT_USERS will not return the standard json api response like the module is expecting, CMD_API_SELECT_USERS does return the standard json api response and therefore it works finally, tried to find the module on github to submit a pull request to apply this patch to module but didn't find it so thought would just post it here instead. thanks to @Doctrine for providing the directadmin panel to patch the issue and make sure it works. information redacted for security reasons.
    1 point
×
×
  • Create New...