On 9/27/07, Chris Travers <[EMAIL PROTECTED]> wrote:
>
> On 9/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> >
> >
> > Yes, but hopefully in a similar way to the parts-asembly situation, or
> > simply a parts price change irrespective of assembly/breakdown. Price
> > changes over time, and how to recalculate prices of current stock is an
> > issue on its own.
> >
> > My problem at the moment is that I am somewhat unclear on proper
> > accounting procedures in this case. It seems to me that there is never
> > enough information to do it with 100% confidence so all we have are educated
> > guesses which happen to balance out over time. This is one reason why I
> > want to start without the automation and add it only when I can work with
> > the accountants of users who need the feature.
> >
>
That sounds like a good approach.
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 agree there too. Moreover, I am suggesting that you need to explicitely
> > enter the costs of the components. However if a screen were to provide what
> > is effectively a calculator , so you can enter percentages for the system
> > to generate the absolute numbers, then that sounds like just a small
> > functional add-on to the system. (Plus see next...)
> >
>
>
> 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.
Either way I can see a user recalculating this a few times, using a button
> > > > in a similar way to how the Update button works for tax at present, so
> > > > he
> > > > could fine-tune a breakdown til it looks right, then save/post it.
> > > >
> > > Again, this brings us to the question of how frequently these may need
> > > to be adjusted, etc.
> > >
> >
It should not matter. Several fine-tunes, another later: it would work the
same: a recalc is needed.
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?
-------------------------------------------------------------------------
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
