Hi Hilmar

Thanks for responding to such a typical query of mine.

>The invoice header would go into one table, the invoice details ("part 2") into another one.

Okay the original Parent-Child tables

>In a situation similar to the one you describe (at least, I believe so), I had to register information about discounts. There being This seems is appropriate for a third table, and yes, I would use a grid for editing it.

Okay. Thanks.

>The third table seems justified because of the one-to-many relationship between the invoice, and the information you described as "part 3" (for one invoice, there can be several taxes).
>
>Taxes and discounts might be combined into a single table, or they can be in separate tables.

Single table is fair as they will be block sort of. One user customisable lot consisting of disc. p&f. etc. for before excise. Second the excise lot itself consisting of Excise, SED, AED, Cess, Service Tax <g> you name it, give it the most crazy way of calculation and they have a plan to implement another tax. 3rd lot for after excise which is again for the users. 4th lot Sales Tax, Central Sales Tax and maybe VAT from April. 5th again the user lot. The users requirements can also be mind bending, a percentge of a value or a qty. or a very sophisticated/complicated calculation.

Questions to this. Where can I put in the calculation logics for this grid of values? How can I show the user running balances of these calculation? The second question may be irritating but the users here want to see the values as and when they get calculated.

I don't know but we are tackling a lot of psycology here, the govt. wants to catch the people from doing misrepresentation of values by introducing laws and registers and returns. The people use the same laws to bend the laws <g> and misrepresent values, a chicken or egg kind of thing.

>In general, I would recommend to have this third table for "part 3", show the information in a grid, and try to pre-fill as much information as makes sense. That is, for a certain type of invoice, or client, certain kinds of taxes (and perhaps discounts) might be standard, so create the records automatically, but give the user enough flexibility to add additional taxes / discounts, or to modify the pre-generated recods.

Yes, thanks.