Account hierarchical numbering

[Mike or Penny Novack]

>I don't think it's quite as simple as that.
>
>First, if you want to treat a field as numeric, then it needs to be stored in a numeric format, defined as numeric in the schema, and insertion of non-numeric values would need to be prevented.
>
>Next, you have the issue of how a number like 2.1.4 can be considered numeric.   The usual way to do that is by imposing an edit convention on a stored number.  Thus 2.1.4 could be 214 edited-masked as N.N.N, or 20104 edit-masked as 0N.0N.0N, etc.  This means that the system would have to know about the editing convention and apply it uniformly wherever the number is entered, displayed or printed.
>
>Nothing is impossible, of course, but unless the whole gnucash system is written with data-schema awareness built in (which given it's history I rather doubt), rather than with the schema hard-wired, then it's a very large task, and not one likely to be justifiable.
>
>  
>
It's actually even a bit harder than Colin described since the 
individual numbers are of undefined length and there are an indefinite 
number of them (the entries aren't all required to have the same depth 
of hierarchy).

The easiest way would be to attach a "tag" field on which a simple 
alphameric sort was applied with the edit copying over anything that DID 
match the criteria with lead zeros inserted and anything else unchanged. 
That cannot fail on "bad data"; the consequences being simply that not 
sorted as intended. We'd just get lots of questions "why didn't it sort 
properly?". Since the "tag" is used only to sort the records, not 
printed, etc. no need for an output edit.

It might help us understand the need if the objection to entering the 
data with the appropriate lead zeros was explained (since with that, 
sort works now)

Michael