On 9/27/07, David Tangye <..hidden..> wrote:
Yes, and this might parallel the idea of selling both parts and assemblies, and whether there is any price difference in a part alone compared to in an assembly.
There is a *huge* difference though. You know the cost of an item when it is purchased. You don't know the relative cost of every component of an assembly you purchase to break down. This is a fundamental data flow issue.
This gets back to my opinion about how LSMB should work. I think its best that it not impose rules. IOW, let the user arbitrarily decide on this. Allow the user is make his own business decision about what he is trying to do. Let him enter whatever he wants.
I would make a few points here. The main concerns I have are:
1) Established accounting rules
2) Mathematical principles
Obviously we don't want to break accounting rules, and we don't want to fight with the math. However, these are separate from issues of workflow, interface, or business practives (outside of a strict accounting scope). We can and should be very firm about the above two areas. Other areas we can and should allow customers to do what they want.
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.
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 don't know. For example, see Istvan's issue with drums which cost something from some vendors but are included free from others as part of the spool. This is one of those issues where I cannot think of a good robust way to do this with 100% confidence.
So these are either different products, or different prices per product-supplier. I thought the system already catered for this?
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.
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.
Best Wishes,
Chris Travers