[Pro Forma Invoices] - Numbering Are Not Sequential

[PauloV]

Hello,

 

Some more free time to make a litle more testes and found anouther issue

 

Wen, for exemple we have 4 Pro-Forma invoices pending payment like this:

 

Pro Forma-1

Pro Forma-2

Pro Forma-3

Pro Forma-4

 

And we add a payment or the client pays the "Pro Forma-4", if there is new order it will be created with "Pro Forma-4" and this cannot happen, all numbering as to be sequential even if any document is pay, cancelled or voided.

 

Thanks in advance,

PV

[Paul]

There's already a task for this, CORE-1287 however there's some confusion of whether this is a requirement or not. Anything you can provide that supports this requirement would be helpful, thanks!

[PauloV]

Thanks Paul

Yes I think is the same

Why not retain a key ID in config table for each type of document this way a new document will check the ID key for that type and just increase a number to always store the latest sequential number

[Tyson]

all numbering as to be sequential even if any document is pay, cancelled or voided.

 

The proforma number is sequential, with no duplicates. The associated invoice, however, when paid, is no longer a proforma invoice. Voided invoices are still proforma, and still sequential. Once a proforma invoice number has been paid, it becomes a normal invoice, and the proforma number is 'released', whereby it can be used again elsewhere (sequentially, like your example). Are you saying there is a requirement that proforma invoice numbers cannot be used if they were used before, even when the proforma number is still unique? If so, could you reference the source for that requirement?

[Cody]

+1 for what Tyson said.

[Blesta Addons]

i never see a duplicated pro-forma invoice , the same as invoices .

i don't know if a law exist for proforma numbering , but what i'm sure of it with a long years of bussines , never i had se a duplicated proforma number, so i vote for paulov request . let imagine the fallowing case ;

i request a proforma for some products , i get it with number proforma-4 , i accept theni pay so i get the invoice, i request another qouate for product , i get the proforma invoice with number proforma-4 , so i'm confused because i have two proforma with the same id with diferent amounts/products/date .

[Cody]

so i'm confused because i have two proforma with the same id with diferent amounts/products/date .

 

You will never have two pro forma invoices in the system with the same number. Once an invoice has been converted from pro forma to an invoice, the pro forma records no longer exists!

 

Besides, the only way a customer would receive another pro forma invoice with the same number as a previous invoice is if the newest invoice belongs to them, they pay it, then the system generates a new invoice for the same customer before generating any other invoices, which is unlikely.

[Blesta Addons]

........................, which is unlikely.

 

this wich mean , it probably  occur ,

 

for a huge clients database and services , is 99.99% can't occur , but in a small system it can arrive to one client  has two proforma withthe same number for different designation .

[Paul]

While this is rare, it is a legitimate concern and I think it should be corrected. The problem is that it's not an easy fix.

[Blesta Addons]

While this is rare, it is a legitimate concern and I think it should be corrected. The problem is that it's not an easy fix.

 

we can wait until v3.9 or more  , no probleme, we are just talking about methodologie of things or how it should be in correct way . 

 

also this is not a trivial bug .

[Paul]

we can wait until v3.9 or more  , no probleme, we are just talking about methodologie of things or how it should be in correct way . 

 

also this is not a trivial bug .

 

Ok, we will leave the task open and plan to implement a fix, but it is unlikely to be in the official 3.3 release and will be fixed in a future version.

[PauloV]

In our personal case we cannot use blesta without unic sequential numbering because is very confusing for us admins also for clients and for tracking payments also.

For exemple, dosent make any sense 100 clients recive an email to pay with the same Proforma numbering even if diferent values and services it will be saved on logs and emails as the same number very veryyyyyy.... confusing

Sorry Paul/Tyson/Cody but dosent make any sense using a released number.

Another example is this:

Proforma 1

Proforma 2

.....

Proforma 1500

Now if we pay the Proforma 2 the number 2 will be released but the next order will be with Proforma 1501

The bigest problem is tracking proforma payments and confusing emails with same number

Edited September 10, 2014 by PauloV

[Blesta Addons]

Anouthe example is this:

Proforma 1

Proforma 2

.....

Proforma 1500

Now if we pay the Proforma 2 the number 2 will be released bit the next order will be with Proforma 1501

 

 

owowowow ..... i have tough that is re-issue just the last number , not all free slot numbers .

 

if this is the case , the proforma feature has no sense . so in one mounth we can see 20 proforma invoice with the same number .

 

difficult for us to track  , if is just the last number who is re-issued is not a trivial, so 97% can't occur , with free number slot re-issue , is 90% will occur .

 

what i can imagine as a fix the probleme , is adding a new field in the company setting that store the last issue proforma , so if is converted to invoice we still have the last issue number .

[Cody]

Paulo, I think you misunderstand how it works. Consider the following example:

 

1. Invoice created for Client A: PROFORMA-1
2. Invoice created for Client B: PROFORMA-2
3. Client A pays PROFORMA-1 becomes INVOICE-100
4. Invoice created for Client A: PROFORMA-3

 

PROFORMA-1 not reused!

 

---

 

The only case where you will have the a pro forma invoice number reissued is if, and only if, Client A receives the latest invoice, pays that invoice, then generates a new (latest) invoice:

 

1. Invoice created for Client A: PROFORMA-1
2. Client A pays PROFORMA-1 becomes INVOICE-100
3. Invoice created for Client A: PROFORMA-1
4. Client A pays PROFORMA-1 becomes INVOICE-101

[Blesta Addons]

The only case where you will have the a pro forma invoice number reissued is if, and only if, Client A receives the latest invoice, pays that invoice, then generates a new (latest) invoice:

with this case is not trivial

[PauloV]

@Cody

Yes I have understood the way it works since the beginning

Like I said in my personal use its very confusing and like naja7host said is correct

In one month if we have every day, 10 new orders and every day 5 payments, for lets say for the last 5 orders, the same numbering will be used for outher clients and here is the problem

For any accounting even for no legal mather every type of document it's better to have a unic not repeated (Im not talking about duplicated documents) sequential numbering to not make any confusing wen tracking records

A very easy and dirty fix is to use an event to save the lastest proforma number in a separate field in the database and wen triggered an order get that number +1 and change the proforma invoice number

Wen blesta 3.3 goes stable we will add this event in our case because its much better to see things and track records

Its only my opinion, and i think every accounting software works this way also

[alexistkd]

+1

[astroroxy]

+1

[PauloV]

I add a meetting today with one of our company partners and the way to go is to always generate a sequential number, and never repet a number that was alredy generated wen creating an Pro-Forma invoice.

 

A cenario is for exemple.

 

The client only remembers the Pro-Forma number, but that Pro-Forma was alredy payed and converted to an Invoice, it call us, and we try to locate the Pro-Forma email or log with that number, if we have repeted Pro-Forma numbers in outher clients it will be a big mess to us to find things

 

I have also remember anouther way for Cody or Tyson implement on Blesta, is for exemple:

 

In Table Invoices, add two new fields:

 

old_id_format (it stores the Pro-Forma format after payment)

old_id_value (it stores the pro-forma number after payment)

 

This way wen adding a payment the function saves the current id_format and id_value and can always check the next sequential number

[Tyson]

 

I add a meetting today with one of our company partners and the way to go is to always generate a sequential number, and never repet a number that was alredy generated wen creating an Pro-Forma invoice.

 

A cenario is for exemple.

 

The client only remembers the Pro-Forma number, but that Pro-Forma was alredy payed and converted to an Invoice, it call us, and we try to locate the Pro-Forma email or log with that number, if we have repeted Pro-Forma numbers in outher clients it will be a big mess to us to find things

 

I have also remember anouther way for Cody or Tyson implement on Blesta, is for exemple:

 

In Table Invoices, add two new fields:

 

old_id_format (it stores the Pro-Forma format after payment)

old_id_value (it stores the pro-forma number after payment)

 

This way wen adding a payment the function saves the current id_format and id_value and can always check the next sequential number

 

 

I think most of us are in agreement that it is more convenient to have only the possibility of 1 pro forma number found, like your example, when checking logs for that particular pro forma invoice number.

 

We will likely explore a different solution than yours, however, since yours adds two fields to every invoice when only 1 invoice would contain valid information. For now, pro forma numbers will continue to be generated like beta 1.

[Blesta Addons]

I think most of us are in agreement that it is more convenient to have only the possibility of 1 pro forma number found, like your example, when checking logs for that particular pro forma invoice number.

 

We will likely explore a different solution than yours, however, since yours adds two fields to every invoice when only 1 invoice would contain valid information. For now, pro forma numbers will continue to be generated like beta 1.

 

 

make them generated as they are now in beta , but in final release make them as we need

[PauloV]

 

I Have found and implemented, and alredy tested a final solution for this problem

 

And the best part, it only requeries one line of code lol

 

 

And here it is to Blesta Devs implement befor Blesta 3.3 goes Stable

 

 

Open app/models/invoices.php

 

Find on line 2302

 

$inv_start = $client_settings['inv_proforma_start'];

Add after:

 

            // It fixes the sequential numbering on new Pro-Forma Invoices generated 
            $this->Record->set("value",($inv_start+1), false, false)->where("key", "=", "inv_proforma_start")->where("company_id", "=", "1")->update("company_settings");

Hope Blesta implement this, because we will usit on Blesta 3.3 stable

[Cody]

That would break as soon as someone changed the proforma start value to something less than the next value.

 

For example, you open settings to make some changes, before you save your changes the inv_proforma_start gets increment because invoices were created, then you save your settings and overwrite the inv_proforma_start value with an older value.

[PauloV]

That would break as soon as someone changed the proforma start value to something less than the next value.

 

For example, you open settings to make some changes, before you save your changes the inv_proforma_start gets increment because invoices were created, then you save your settings and overwrite the inv_proforma_start value with an older value.

 

 

But this easely fix, just put the field "read only" after the first "Pro-Forma" invoice is generated

 

A "stupid" exemple is in WHMCS that works in the same way lol and we also can change the next value breaking the WHMCS Pro-forma numbering, but everyone uses, and no one in 5 years has tell anything to fix or change this lol

[Cody]

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.