Is it time for a change in our thinking.

[RainLover]

What happens when I buy a carton of milk and a loaf of bread.

I do get an electronic invoice/receipt.

The sale is recorded in the Database.

Does the Database store a new calculated balance or does it do this at the end of a time period. If so then is this not classed a a violation of Normalisation.

Then again maybe my question is out of scope for this forum and MS Access.

 

[dportas]

What happens when I buy a carton of milk and a loaf of bread.

I do get an electronic invoice/receipt.

The sale is recorded in the Database.

Does the Database store a new calculated balance or does it do this at the end of a time period. If so then is this not classed a a violation of Normalisation.

Then again maybe my question is out of scope for this forum and MS Access.

That depends on the database schema. The fact that you are calculating and storing a balance at some point in time doesn't necessarily violate Boyce-Codd or 5th Normal Form for example. A relation is in BCNF if every non-trivial determinant is a superkey. A relation is in 5NF if all of its non-trivial join dependencies are implied by the keys of that relation. So the answer depends on the database schema and on what exactly you mean by "normalisation" (e.g. what normal form).

 

[spikepl]

#25

The day's transactions would be summed after the close of business (period closed) at which point they could be saved.

Maybbe. Or maybe not. A discount store reorders for overnight delivery of fresh supplies around 6 or 7 pm, so already at that time they have to have a pretty good idea. An airline does not do a stocktake of remaining available seats at the end of the business day. Neither does a cinema. Etc etc. The point is to think before deciding, and do what is required.

 

[RainLover]

Well, that is not what I was expecting.

I felt that there was a strong feeling against storing calculated values, but it appears that there is one rule that overrides all the others. And that is common sence.

I did use the word Period which was non specific. This could allow for very regular storing for large volumes and not so often for smaller businesses.

In Accounting I believe thing are done in batches. Once the batch is processed and balanced it can then be commited. The only way to change would be by reversal which would leave the appropiate audit trail.

Thanks for confirming that I was of the correct thinking.

My next question will be along the lines of complex reporting. But not just now.

 

[PNGBill]

Some databases use a temporary value rather then a calculated balance.
Stock take is an example.
You "Freeze" the stock on hand value, then when the stock take count is known, any difference becomes a Transaction (Sale/Purchase).
This means One field is used to hold the Stock on Hand value for comparison only.

Early databases were designed with limited data storage being a big issue. My first experience was with a Prime main frame (two linked) sharing a 256kb hdd plus of course tape backup.
This mean't you had to be careful when retaining infinite transaction history.
Our GL software, today, appears to be built for such a system as it Rolls Over each year and retains little transaction history.

Who wants to printout cartons of transaction data each night/week/month/year and store same, any more ?? We do not.

With the storage capacity and speed of today's pc's I would prefer a system that retained as much transaction history as possible.
This implies Calculated balances for Stock ON Hand etc are a natural event.
Our business is Paper Less.