For a percentage system, that would be correct. However percentage systems don't properly handle certain fractions (for example, 1/3 or 1/7) without loss of information. Hence my thinking that a rational number system would be better (
i.e. enter the portion, and we will display but not store the approximate percentage value). I am assuming however that everybody is limited to rational numbers in cost breakdowns.
I suggest that the numbers should be rounded within the precision of the user's monetary system, and as per above he be able to change this to whatever he wants, should he wish to do so. This makes it simple for the system too.
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.
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.
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.
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.