🚀 go-pugleaf

Isaac wrote:
> Ok guys, but I saw another solution used in the "Peachtree complete 
> accounting" package it uses the client to update the "running balance".
> 
> First no direct change in the window the user have to open another 
> window to make the update,
> 
> Then a global flag set for example "balance_need_update = true" and when 
> the user close the window and the the balance window get the focus a 
> small progress bar appear indicating of fixing the balance.
> 
> this scenario did not occur if no change happened and also controlled by 
> the current selected period of the year (3 months) and the update occur 
> from the modified record down to the end of the selected period so it 
> take few seconds.
> 
> it is also in my opinion more light to do the calculation on the client 
> with executing SQLs than using triggers and procedures on the server in 
> case of 50 user using the software.
> 
> What do you think ?

Isaac:

Go back to the rules of normalization on this one... (Which are derived 
from the business rules)

But generally, If you store this information in the same table as the 
transaction, you have dependent data. A "no-no" as I recall. :-)

It is better to generate this information "on the fly" and use a stored 
procedure widget linked to a table and a grid, for example, to display 
this _transient_ information.

If this is a "one-company" one-off package with a highly disciplines 
accounting group -- it does not matter _as much_, however if there are a 
lot of accounting updates, you are always re-generating the data -- and 
storing it back to a table -- which eats time and resources. This is 
"Date-Timestamped" information, and that is the calculation order, or 
Date, Sequence number order (hierarchical) ...

I have seen companies that demanded immediate payment for outstanding 
invoices -- when a customer was on pre-pay COD status -- because they 
always got their balances wrong due to input sequencing errors and just 
plain sloppiness.

Don't underestimate how tricky this calculation can be -- at least if 
the business rules aren't clear.

And of course you have to decide if you are running (account) "balance 
forward" or "open Item" (on account) on the accounting -- and I 
recommend "open Item" as a matter of course... Otherwise you can't age 
things very well.

These are more design issues than SQL issues. These design issues are 
derived from the business rules -- which you did not state. SO hence it 
is impossible to asses what rules of normalization and sequencing rules 
should apply. Hope that's clear.





-- 
Will R
PMC Consulting