Invoice sequence numbering

21

Yes, but that doesn’t mean that any entered text is that cell is wrong.
All the cells within a worksheet could be specified as numeric but this doesn’t mean that text under a column designated for description can’t be entered. I guess one could get pedantic enough and re-edit the cells so that they correctly align with the content type.

That is because the programme separately restricts the keystrokes that can be used in that location. The same can apply to an alpha field where non a to z keys can’t be used.

In other words, defining fields and permitting keystrokes are two entirely separate things.
For example, you maybe restricted to 1000 but the numeric field could display 1,000.

22

I used to have the same problem you have when I first switched to manager. But after thinking about it, manager does not mix up different types of documents (at least not by default) so the only reference you really need is a unique serial number. A fixed prefix adds no extra identification.

After all, if we are being completely honest, unless you have multi-dimensional meaning to the sequence (which you shouldn’t since manager does not use references as codes anyway), you are really going to refer to the invoice by its last 3 to 5 digits and completely ignore the prefixes. Otherwise, if you are using manager and have multi-dimensional coding to your references then this must mean you are getting them from somewhere else, so why nit just put automatic references and use a custom field for the external reference, this way you will have a much better audit trial imo.

Anyway, if you still want prefixes you can use a custom theme which should solve your problem; just replace this:

{% for field in fields %}
<div style="font-weight: bold">{{ field.label }}</div>
<div style="margin-bottom: 10px">{{ field.text }}</div>
{% endfor %}

with this:

<div style="font-weight: bold">Reference</div>
<div style="margin-bottom: 10px">
{% capture str_ref %}{{ reference | downcase | prepend: "000" }}{% endcapture %}
{% capture arr_ref %}{{ str_ref | split: "" }}{% endcapture %}
{% assign str_size = str_ref.size %}{% assign start = str_size | minus: 3 %}{% assign end = str_size | minus: 1 %}
VK{% for field in fields %}{% if field.label == 'Invoice date' %}{{ field.text | date_to_string | date: "%y" | default: "00" }}{% endif %}{% endfor %}F{{ str_ref | slice: start,end | newline_to_br }}</div>
{% for field in fields %}
{% unless field.label == 'Invoice date' %}
<div style="font-weight: bold">{{ field.label }}</div>
<div style="margin-bottom: 10px">{{ field.text }}</div>
{% endunless %}
{% endfor %}

You might need to debug this, no guarantees since I stopped using it a while ago.

23

Thanks for your input. However, everybody is, and should be, free to use the numbering format for invoices (or other documents) they wish. My observation was that the Guide indicates:

If the box within the field is checked, Manager will number the transaction automatically. The program will search for the highest number among all existing sales invoices and add 1.

And this is not the case as it doesn’t add 1 to the number format one is using. So maybe the Guide has to be edited by indicating that this is only true if the invoice numbering scheme is made up of only numbers?

I know that several other programs allow the use of prefixes. In fact, the majority of the purchase invoices I receive use them. I cannot give examples of other programs because the last one (not even another program but just an example of field defined as number in MS Access) was deleted by Tut but everybody knows they exist.

24

You are absolutely on point, and I think there might be something in this regard since the developers have made clear their intent to do something about account codes, so I can only assume voucher numbers would follow suit since if you search you will see numerous post for alphanumeric voucher numbering.

25

I indicated that to me it is not correct that when starting an invoice numbering scheme with VK20F001 and then ticking the option automatic numbering, the next invoice’s number is 20002 and not VK20F002. But the Mods think this is normal behaviour so I’m not going to dedicate more time on this.

26

No, both moderators explained the program works as designed. There is no question of normal versus abnormal behavior. The developer made a choice, the same way developers of Excel and Access made choices, and has shown no inclination over at least five years to modify that choice.

You would apparently make a different choice if you were writing your own program.