[Pro Forma Invoices] - Numbering Are Not Sequential

[PauloV]

Read only wouldn't work since users may want to change it to a larger value.

 

I also don't think bugs in WHMCS are something we should implement in Blesta.

 

 

Im not telling its a WHMCS bug Im only telling that we want sequential numbers to work, and we (Im talking myself), dont mind to leave the filed as it is writable

 

Here is the solution for what you said and we have alredy implemented on Blesta 3.3b2 and works greate

 

 

Open file app/models/companies.php

 

Find on line 748

 

'inv_proforma_start' => array(
'number' => array(
'if_set' => true,
'rule' => array("matches", "/[0-9]+/i"),
'message' => $this->_("Companies.!error.inv_proforma_start.number")
)
),

Add after:

 

'inv_proforma_start_check' => array(
'number' => array(
'if_set' => true,
'rule' => array("compares", "<=", $vars['inv_proforma_start']),
'message' => $this->_("Companies.!error.inv_proforma_start.greater")
)
),

Open file app/views/admin/default/admin_company_billing_customization.pdt

 

Find on line 53:

 

<?php $this->Form->fieldText("inv_proforma_start", $this->Html->ifSet($vars['inv_proforma_start']), array('class' => "small", 'id' => "inv_proforma_start"));?>

Add after:

 

<?php
                                if($this->Html->ifSet($vars['inv_proforma_start_check'])){
                                    $this->Form->fieldHidden("inv_proforma_start_check", $this->Html->ifSet($vars['inv_proforma_start_check']));
                                }else{
                                    $this->Form->fieldHidden("inv_proforma_start_check", $this->Html->ifSet($vars['inv_proforma_start']));
                                }
                                ?>

Open file panguage/en_us/companies.php

 

Find on line 34:

 

$lang['Companies.!error.inv_proforma_start.number'] = "Pro Forma Invoice Start Value must be a number.";

Add after:

 

$lang['Companies.!error.inv_proforma_start.greater'] = "Pro Forma Invoice Start Value must be iqual or greater then current number.";

Hope that helps you and outhers

 

[Blesta Addons]

Read only wouldn't work since users may want to change it to a larger value.

 

I also don't think bugs in WHMCS are something we should implement in Blesta.

Yes , and also don't make the same error to not correct this in the next 5 years

[Tyson]

Implementing PauloV's change would also make the value not reset per {year}, since that value is only intended to be the start value.

[PauloV]

Implementing PauloV's change would also make the value not reset per {year}, since that value is only intended to be the start value.

 

I dont find any reference on Blesta code that the "inv_proforma_start" will be reset every year

 

But if it is reset every year (if you can point me in the right direction to try to find an easy solution), that is not a problem, its an easy fix, just make a condition to check like for exemple this:

//it add's the year before the number to check if its greater then, to bypass the inv_proforma_start year reset
$check_inv_proforma_start_year = $this->Date->format("Y").$client_settings['inv_proforma_start'];

If the reset by year is made before the execution of the function getNextInvoiceVars() it will not mather because the next generated number is only generated in this function

[Blesta Addons]

if it reset every year ; so in the cronjob "00:00 1-1-20XX" make the reset directly in the database field .

[Cody]

The start value doesn't reset each year. Rather, if you're using the {year} tag in the numbering, a new set of numbers will be generated beginning at the start value given each year.

The start value is just that, a start value. It's not intended to be incremented as that's the opposite of how it was designed.

[PauloV]

The start value doesn't reset each year. Rather, if you're using the {year} tag in the numbering, a new set of numbers will be generated beginning at the start value given each year.

The start value is just that, a start value. It's not intended to be incremented as that's the opposite of how it was designed.

 

Yes, but its a great workaround, dont you think?

 

And we (Europien people ), that need Pro-Forma invoices to work as they should, this can fix everithing, dont you think?

 

My opinion, its better, for now work like I have said, and later on, wen you (Cody, and Tyson and ofcourse Paul ), had time, implement a better solution

 

I have seen the blesta code, and you can simple add a new "key" in database that will store the latest generated pro forma invoice, or better yet, store in a new fileld on invoices to us be able to search by final invoice and old pro-forma number, and this way it will only need also one or two lines of code to fix permanent, and it will not need to mess with "inv_proforma_start"

 

But you have also implementa  rule to check if the next generated number is greater then the new key, if an admin tries to change the "inv_proforma_start".

 

Im stiking with my solution, an I will also add a new field on invoices table to also store in a final invoice, the old pro-forma number to us to track invoices if the client only remember the pro-forma number

[Blesta Addons]

Im stiking with my solution, an I will also add a new field on invoices table to also store in a final invoice, the old pro-forma number to us to track invoices if the client only remember the pro-forma number

 

with your solution is better to be the field in the company setting than in the invoice table . just my opinion . in the end what we need a workaround to solution that feat to our need

 

just a question : why not the numbering method is not the same as the invoices ?

[Cody]

just a question : why not the numbering method is not the same as the invoices ?

 

It is the same, but you don't notice any issues because a regular invoice can not be converted like pro forma and draft are converted to real invoices.

[blesta_tester]

It would be great if Blesta could store proforma number on a real invoice (optionally). That is needed for accounting here. When clients do manual bank wires, they just write "Proforma 2" in description, for example, and when you manually accept the payment, proforma invoice is instantly changed to a normal invoice, thus accountant is not able to detect which invoice was the payment for. An option to store the proforma number on a real invoice would solve that (somewhat like "Generated from proforma-2" at the bottom or top of the invoice).

[Ekim]

I agree that the issue needs to be fixed.

 

Is there a reason that the pro forma invoices can't be kept in the database and just marked as dealt with / converted / hidden? This way a pro forma invoice ID will never become available for use a second time and we get the added bonus of retaining records for all pro forma invoices which have been issued in the past. Granted, this seems too simple of a solution, so I'm guessing there is more to it (I'm not familiar with the Blesta codebase).

[PauloV]

@Paul , @Cody, @Tyson:

 

Is these enough people (on this Forum) asking for this to be core implemented?  

 

Regards,

PV

[Paul]

@Paul , @Cody, @Tyson:

 

Is these enough people (on this Forum) asking for this to be core implemented?  

 

Regards,

PV

 

I would say so, but feel free to keep nudging us 

 

If it were a simple fix, it'd be done already. We gots to put our thinkin' caps on.

[PauloV]

I would say so, but feel free to keep nudging us 

 

If it were a simple fix, it'd be done already. We gots to put our thinkin' caps on.

Its really easy, add a new field on table invoice to store the pro-forma invoice number and then there will be no conflit with existing code, also an extra field to invoices table to store as an array all client info and for legal eu invoices will be almost fixed

I will build a plugin for digital signed pdf invoices and with this will be 100% compatible with eu legal invoices

[serge]

PauloV said

 

I will build a plugin for digital signed pdf invoices and with this will be 100% compatible with eu legal invoices

 

But by the way according to most EU law, invoice must come from your acountability system, so as none billing system like Blesta, whmcs, etc do have plugin or module for EU accountability (except UK), that do mean you should see:

 

from an accountability point of view:

- Invoice generated by Blesta are just receipt

- Real Invoice are from your accountability software & using above receipt as cross reference (you export transaction from your payment gateway account, you "clean data", than you import it to your accountability software)

 

From your customer point of view:

- Invoice from Blesta are customers invoice

- Invoice from accountability software are just living for accountability purpose nothing more, customer are even not aware of these

[Max]

But by the way according to most EU law, invoice must come from your acountability system, so as none billing system like Blesta, whmcs, etc do have plugin or module for EU accountability (except UK)

 

 

Here in the Netherlands, you can even write out invoices by hand with pen on a piece of paper, and it would still be a legal invoice.

As long as it has the required information, and you make copies of the issued invoices (and do not alter them afterwards).

They do not have to come out of your accounting system. Can just enter the total amount of all invoices there, as a single batch journal entry at the end of the accounting period. 

 

 

We did had the requirement for a digital cryptographic signature on electronically sent PDF invoices in the past, but that requirement has been dropped, at least in my country (not sure about other EU countries).

When we wrote our own billing system, it did was still required, and we had to duct tape our PHP software, to some Java code using the iText library to make that happen, as there weren't any PHP classes capable of that at the time.

[serge]

I was re-reading this entire post & http://dev.blesta.com/browse/CORE-1287

At the end I think in Table "invoices", we could:

   1/ keep "id_value" as PERSITENT number, this is the sequential number of pro-forma/unpaid-invoice. It's should never be over written like it's by now by allowing old used number to be re-used again and again for new pro-forma.

   2/ for paid Invoices, we use a new column "id_paid", this number is  sequential and only created when invoice is paid, and it's will be displayed in place of "id_value" when printing the Invoice.

 

In EU accountability that require unique sequential number, what to consider is only paid invoices, accountability have nothing to do with quotes, pro-forma invoices or unpaid invoices.

So having very rare or not, same numbers for "id_value" and "id_paid" is not an issue, as there are very different things.


It's ever that way most billing system work