Leaderboard

Simplest option is to add a few settings under "Display on Invoice" in [settings] > [Company] > [billing/Payment]: [ x ] Date Due for Drafts [ x ] Date Due for Standard Invoices [ x ] Date Due for Pro forma Invoices

So i can resume , the due date should be showed in proforma invoice , after convertion to final invoice is not needed to be shown , for that reason is safe to not change the due date . It remain a reference for proforma invoice .

I personally don't even think it needs to be a setting. Having an uploadable image field should always be there. You can either use it or not use it depending on your needs. If you do use it have the image display (thumbnailed?) in the ui and full page if you click on it both in the admin and client side. Maybe a checkbox to display it to the customer?

CORE-1605 - When proforma is converted to an invoice, set date billed to current date Also, CORE-1561 - Requeue invoice for delivery when converted from proforma Both of these should be in 3.4.3 as soon as next week. That leaves 2 things I believe, please correct me if I'm missing anything. 1. CORE-1287 - Prevent Proforma and draft invoices from reusing numbers. This is more complex. 2. Do not display date due on invoices converted from proforma. On #2 I think some more discussion is required. There are a couple ways to do this: 1. Have an invoice settings option to disable the display of due dates on all invoices. This may be useful for those who do not use proforma as well. 2. Do not display due dates on invoices that were created from paid proforma invoices. If we do this, we need to store more information on the invoice that indicates that it was previously a proforma invoice, possibly another field in the table. Thoughts on #2? Thoughts on CORE-1605, CORE-1561, or CORE-1287? EDIT: Also, to add, it would be simple to remove display of the due date on invoices that are not proforma with a little code. So, while we come up with the best solution, you could make this change now to affect all invoices (but not pro forma).

I like the idea. But -1 for saving images in database . I prefer save them in upload directory outside the public_html . Or add ability to attach notes with transactions.

Definitely not in the database, makes for large harder to restore, harder to backup databases. You should have a really good reason for using BLOB, and even if it was base64 encoded, too much data. Doesn't seem like a lot of support for this, but I'm tempted to create a task anyway, that we'll get to, sometime. Anyone think of any reasons we *shouldn't* add this, except for the fact that it may clutter the UI?

I believe the template is /app/views/admin/default/admin_clients_email.pdt, look for $this->Form->fieldText("from", $this->Html->ifSet($vars->from), array('id'=>"from")); Change to: $this->Form->fieldText("from", "your@emailaddress.com", array('id'=>"from")); I think that's right.

You could modify the template to hard code in a specific email address, but you'll have to merge that change on any upgrades.

Does this work for everyone?

Recovering encrypted data requires your system key (stored in your Blesta config file). Without it, the data is unrecoverable. Additionally, if you set a private key passphrase, certain encrypted data (e.g. credit card numbers) will need that entered as well to decrypt data. "How" to recover the data depends on your situation and what you're trying to do. Blesta already provides methods of decrypting data via the interface, such as to view a credit card number, which occurs automatically. If you want to decrypt all system data, for example, it may be best to write a short custom script to do so. If Blesta is still installed when you want to do this, you can have a developer call AppModel::systemDecrypt on each encrypted field.

PayPal must have the correct currencies selected for the gateway, and the packages being purchased must be in one of those currencies, and the order form must explicitly accept the same currency.

agree on this: I like the idea. But -1 for saving images in database . I prefer save them in upload directory outside the public_html .

Lol, my mistake sorry Cody and naja7host Naja7host is right its not a problem in due date because we do not legally need that field on final invoice, only need on Pro-forma for customers to see

+1

Tyson, please consider that this is a very important fix. We're using proforma as default, and so for every order we need to resend manually the invoices after payment: this isn't the best for us and for our clients. Thanks