On 9/28/07, Chris Travers <[EMAIL PROTECTED]> wrote:
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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
