On 9/27/07, David Tangye <..hidden..> wrote:
Not sure I understand you correctly here. Suppose I purchase an assembly for $1 USD which includes a container item and 1000 units of something else. If I round costs to the nearest penny, I get no cost for any component, hence COGS gets screwed up.
I am suggesting that the calculated figures can get changed before saving them, so that in this extreme case the calculated figure wold have to be overridden.
Ok, so suppose I buy a lot of 10000 items for 10 USD. I sell each one for $0.01.
Suppose I sell 44 of those items to each of 100 customers. If I round off at sale, then I have a roundoff error because of bias in the data, and I will show $4 COGS instead of $4.40. In reality when we are dealing with large lots I don't see a way around applying COGS to a high accuracy and then rounding off sums in financial statements.
If you mean that the ratios ought to be rounded, I would disagree with you here too. One of the frustrations I have with the current codebase is the rounding that is applied to figures in assemblies. Rounding of non-financial numbers is somewhat arbitrary and I would say that we should let the user enter what they want.
I am only referring to rounding currency to its appropriate precision, eg a cent. Fractions of a cent might make sense 'mathematically', but not in the real world that this system is supposed to support.
I think that this violates the rule of "Don't fight with the math." Rounding in this case will result in roundoff errors in a number of foreseable circumstances just as it would with sales tax.
The large issue is what I call an information completeness problem. The fact is, we don't really ever know what the relationship between component costs are. Basing this on data from other vendors could run into problems (in the cable drum case, for example). Basing the data on the same vendor might not give you what you need. But either way you cannot *prove* that the flow of information is accurate, so you can only make educated guesses about cost relationships.
That sounds reasonable. I can only suggest again that the system continue to allow figures to be overridden by the user, and there is no problem.
If we are going to be making educated guesses about relative costs, I would want to make sure that we were following solid accounting guidelines. In my view the only acceptable option at the moment is to avoid automating it at all and force the company to change the relative costs whenever they need thee to change.
I would *hope* there are established accounting rules to cover this sort of thing. However, I do not know what they are and until I do, I don't want to build a system which in all likelihood could be doing it wrong.
If figures are overridable by the user there is no problem. There is only a problem when the rules are enforced.
No, you don't understand my concern. I do not want to automate a problem in such a way as to create suspect accounting figures. If you enter the data manually that is different. At least there is enough information to meaningfully make any required adjustments etc. In an fully automated system that gets it wrong, this would become a pain really fast.
It seems to me that for now, we should not automate any changes to cost relationships. If people want automation of this, they can define that requirement and customize the application to do that (or hire someone to do that). Over time as a concensus develops (with the blessing of accountants) about how to automate, we can do this.
My big concern here is that we need to ensure that this program is absolutely 100% correct accounting-wise. This means that a lot of time needs to be spent on making sure that the program is mathemtaically correct (in terms of accounting mathematics, relational algebra, and information algebra). Business rules, workflows, and interface are separate issues and need to wrap around the core application.
Best Wishes,
Chris Travers