To auto-calc or not auto-calc

[jk2addict]

That is my question. :-) This isn't a perl question more than it is a perl project question and a question about consistancy , user expectations, and staying out of the way of the user. It may very well be destine to meet Node Reaper.

In Handel there are two major sets of data: cart w/items and orders w/items. For the cart, subtotal is not a field but is instead calculated by adding the total price of all of the items. The total of each cart item is price*quantity. total is not a field and is calculated on the fly. Module consumers can not add/alter the subtotal/total values since their not fields. These were meant to same the module consumer work and seems like a normal expectance ot total/subtotal.

On the flip side, there is the order data. The subtotal field is a real field and is not calculated from the item totals. The items total field is also a real field and not calculated by price*quantity. Module consumers can edit/add/update this the subtotal/total fields at will.

This sprung from the idea that an order records should be ready and taken for their face value with no fields calculated on the fly as those calulation methods may change over time. The goal is to store the data as it was the time the order was placed and never calulated anything about that order again.

What I'm now struggling with is module consumer expectations and which way is really correct. What confusion is caused by auto-calculating subtotal/total in one place but not the other? On the flip side, what harm is generated by getting in the way of the module comsumer creating totals that may appear to be 'wrong' math wise, but not for some other business reason?

Like I said, this isn't a perl question. I'm just looking for experience from others here about when to or not to try and help the user by doing things for them vs. letting them shoot themselve in the foot.

[jhourcle]

It's actually a deeper question as to data normalization--

Some stuff seems redundant, as it can be calculated, but that assumes that the data never gets modified once it's been created, and that there are no special exceptions.

For someone who just wants something quick to sell something online, and doesn't care about historical trends and such, calculating on the fly is probably just fine ... But you have to understand that you can never look back up an old invoice in the system.

The auto-calculating situation you've described also doesn't allow for item bulk discounts (especially for the complex ones, where it's not just a total percentage off, but the first 1-20 items are full price, but there's a reduction on the 21-100 items, and a further discount on 101+)

Even the order total may not just be a straight sum -- maybe there's a discount if you order more than $100 (or whatever currency you're dealing in).

I'm all for the calculating it at the time the order, and writing out all of the values, rather than attempting to re-calculate the invoice on what may be different info (price changes, even item description changes, etc.). It's not efficient in terms of size, but it is efficient for speed, and I find it to be more useful in the long term.

As for 'correct' -- no one way is more 'correct' than the other other. You have to decide what your requirements and constraints are for the project, and make the decisions based on that. One way is easier to code, and takes much less space to store; the other way will take you longer to write, but gives extra functionality that may (or may not) be useful in the situations your program is going to be used.

[jk2addict]

And therein lays the problem. I can't come to grips with either side of that fence.

It makes sencs to autocal subtotal and items total if I'm creating an order from a cart. From there on out I guess it's safe to just let people change price/quantity and leave the calculation for subtotal and total up to them instead of doing it for them like we would in the cart.

It's more work, but more flexibility because as you point out, all bets are off in the order when it comes to totals and possible "new math" involved in discounts.