Dragan, see below ...

>>>>Yes; the two-table structure (articles, composition) allows virtually any number of levels, but for practical purposes, for the end-user, the number of levels should be limited.
>
>The most complicated practical cases I heard of were about 8 levels deep, but those are huge and complicated things like transocean ships or jet planes.
>
>>>I put a limit after testing - I once manually created an endlessly repeating composition, and tried to display it. On my machine (which had only 4 megs at the time) it broke when attempting to display the 6th level; on better machines it would go as far as 8 to 10. So I put a limit at 5.
>>
>>I can't guess what this has to do with memory at all.
>
>In the grid simulation I was doing back then in FPD6, it took two calls on the return stack per level; that was not the problem. It was the bunch of arrays I used at each level to keep all the visible values at hand, their record numbers etc. That was eating quite a few kilos each time.

Don't forget to send some info to Fernando on FPD6; you hold some unique product here ! {g}
Now I think of it (see my earlier comment directly below) my "arrays" were easy to deal with because it was MUMPS back there. The "bunch" would be only one and these kinda things can be beautifully held there. It was 1980 and ran on a PDP11 at Shell; I wonder whether this PDP had 4 MB of memory ...


>
>>However, you could be dealing with the maximum stack depth. So, normal recursive routines call themselves, and for VFP you'd be dealing with the normal stack (already increased by an IF, a Loop etc) and the program-DO stack (also increasing the normal stack). But note that any recursive structure can be broken down to be in the one program (using arrays ... and yes, consuming memory then).
>
>Even using strings as arrays (did even that once) but I think the limit Hilmar suggests is not inspired by computing or any other technical reasons - it's the people who would eventually have to get the data in, look at them, and have a say in whether the data are right or not. With so many levels, it would just be too huge for anyone to keep track of. OTOH, for practical (i.e. human-sized) purposes, the tree could be chopped into branches, so nobody would have to deal with more than 4-5 levels at a time. Top guys wouldn't need to go into detail, and the guys in the basement needn't know they're seeing 4th level branch as root.

Dragan, I think you are wrong here; (okay I know ;)
Think of the recipe again; each level is held by a product and it can always be seen as elementary. So whether it's the cake, the flower, the caramel, all are products and they all hold one level of products. The maintenance is always performed on this one level i.e. the recipe for the caramel or the cake at the higher level. Difficult to expain further; you 'd have to see it.


>
>>We just have this, exactly like this (btw in Holland this 0-9 system is very often used).
>
>There's a difference between "often used" and "prescribed by law". Still, I'm somewhat relieved, knowing (now) that all the accounting I had to learn (to the level when no chief accountant could sell me another bright idea to introduce into the app - I had it there already, or I had good argument to dim the brightness) was not in vain. One of the fears of the people in socialist countries was that what they learned wouldn't hold anywhere else, because it was country specific. Including accounting, which probably had lots of other local quirks - glad to see they were wise and used a system which is a standard.

Hmm; I'd say accounting is accounting, and the basics of it can't be done otherwise. However, the rules on what to book when can be different, the same as how to book it. F.e. in Poland VAT for incoming invoices has to be booked per date the invoice falls om the doormat. IMO very strange, but there it is the rule. The app needed some small adjustment for that (usually this is per invoice date).

>
>>Just (and indeed) look at the general ledger as a same bunch of "Items" as for products, and look at it from the point of view of calculating the Item's cost price from the (raw) materials used in the recipies. With the ledger it's just the same; just create a "recipe" for an account and have some accounts in there
>
>...which is what some of the year-end specific reports had exactly dictated. Or (another surprise), monthly statistics for the regional health system, where we had something like a three-level recipy which would regroup the atomic day-doctor-patient category-workitem-diagnose records into whichever levels, groups, subgroups and reports they wanted. We even had to write a formula editor, so they could add and fix the groupings as they like. While this is not really the assembly list case, it does resemble it - the final rows in a report were a recipy on how to get the proper grouping, with a different recipy for almost each row on each of the reports. Actually, the only difference is that there were no mixed levels.
>
>> and if you want to do it again at the lower level, just do it. One rule : one is allowed to book only at the lowest level accounts.
>
>Makes sense to me, and made sense to chief accountants - but not to their clerks. Few whites in my beard come from that :)

Your beard could still have been beautifully black, brown, blond or even red (but white looks okay too;) when all was done with templates. I mean, the modern accounting app works with templates for bookings only, and nothing is done directly. Now don't ask me what is modern, where we had this 14 years ago (back then I never saw it before). Further, all is initiated by the according subsystem. F.e., complete logistics have some 100 interfaces to financials, and all run real-time without notice.


>
>>So all the "parent" accounts are just summarizations of the bookings of the lower level(s !!).
>>This system is flexible / dynamical with respect to which parent has which childs, IOW, the whole structure can be changed at any time.
>
>- or remapped into something different, as is the case with the two types of reports I mentioned in the long paragraph above.