>Hi all
>
>I have generally noticed, as many (if not all) of you have noticed, that an Invoice (Bill) data-entry will generally have 3 parts. Part 1 Header contaning Bill no., date and various other details like the Party to whom the issued etc. Part 2 The Line items and it's rate, qty. and amount. Part 3 which wil contain the Total of Line items amounts.
>
>This Part 3 is what I am aiming for. I have also noticed that here we have a lot of ways this needs to be customized for each client. Plus we have a lot of Taxes, some are permanent but others types of levies come and go as per the ruling govt.
>
>Following a situation from real life.
>
>

     Items Total         10,000/-
>Less Discount u/s4 5%       500/-     && This can be amt for another client or not at all
>                         ---------
>                          9,500/-     && The accounting actually starts from here as sales amt.
>Add  Excise 16%           1,520/-     && constant but diff. %ages
>Add  Cess 2% of Excise       30/40    && may stay and/or other typical calc levy can come
>                         ---------
>                         11,050/40
>Add  C.S.T. 4%              442.02    && constant but diff. %ages
>                         ---------
>                         11,492/42
>Add  P&F                    650/-     && This can be for another client not at all
>Less Rounding                 0/42    && Another client may round all above value straight
>                         ---------
>Grand Total              12,142/-

>
>Like Cess in the above example is a recent introduction. Plus as you will notice these above values are affecting accounts. So I was thinking is there a way to attach accounts to the values and still keep the thing flexible. I also have to keep control of the Excise, Cess and C.S.T. values for other govt. documentation purposes, so I have to know which amount is the one to be used in such documents.
>
>Just thinking of the top of my head, these above I feel are candidates for a grid, but then how and from where can you control the eccentric calculation like for the Cess in the eg. Plus if it goes into a grid how does it affect the actual Parent table for the Invoice (we are generally used to 1 Parent Many Item Child relation).
>
>I want feedback if some of you have tackled such situations. Creating fields and maintaing them internally can be a strain and especially the clients customized ones are a drag. I currently have all these fields in the Invoice Parent table and I enable disable the clients ones by a seperate table which contains the account and type of calculation. These details are replaced internally in the Invoice Parent table whenever a new record is added so all the user has to do is enter the values/%age.
>
>This means I have to plan out how many customizations I will allow before and after Excise / Cess and also After C.S.T. These 2 namely Excise, Cess, C.S.T. are hardcoded maintained in the current app and it has it's pitfalls when new things are introduced.
>
>Please advise and also provide better ideas than what I have already done or want to do.

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

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.

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.

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.

Greetings,

Hilmar.