Invoice exposes internal ID

[anonymous]

((from previous ticket on 01/05/09))

The order id number on the orders (and printed on the invoices) is an incremental number that we cannot edit. The number is drawn from the "id" field of the Invoices table.

Request:

The order id that is displayed should be an editable section within the invoice, stored in a separate field in the Invoices table. The actual "id" field should not be printed on invoices.

Preferentially, that editable section could autofill with a generic invoice number, or an order id specific to the client.

Justification:

1) The way it is right now is very confusing to clients. "My first invoice from you was labeled 1000, but my second one is 1003? What happened to the other two?"

2) This gives away information about the number of invoices to-date to customers (and, potentially, competitors) who can determine the volume of business a company using phpBMS is involved in, give them the capacity to determine high and low points of activity in that business, and the total volume of business done to date.

3) In b2b, other businesses prefer to have logical invoice numbers to keep track of business they've done with your company before. They are used to having invoice numbers referring directly to them in a sequential order. The first invoice with your client is numbered 1, the second is numbered 2, and so on. This makes it easier on accounts payable.

4) Migration. A business migrating clients to phpBMS likely has already been invoicing clients before according to their preferred scheme. They may have thousands of invoices already delivered, and their customers will start to wonder if that number has changed. "Why did my invoice count reset? Why am I back at 0?" or: "Why did my invoice count suddenly jump to 1500?"

In many countries, remember that the industry standard is that a customer can expect their first invoice to be "invoice #1," and their second invoice to be "invoice #2," or some variation of that.

#2 seems a fairly large concern to any business looking to use phpBMS when their invoices disclose what some may consider sensitive data. At the bargaining table, a client who can tell you've had a slow month has an uncomfortable edge.

Past ticket: #308

Result: closing ticket due to excessive spamming. please open another ticket. ????

[anonymous]

Is it likely that this modification will ever be incorporated?

[brieb]

Because of the structure and setup of the "open bazaar" open source community here, anyone can contribute code to the project.

[brieb]

Duplicate of #220