On 9/27/07, Chris Travers <[EMAIL PROTECTED]> wrote:
>
> On 9/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> >
> > Logically, it would have to work in a somewhat similar way as part
> > assembly works now. The user would have to define how an assembly is
> > composed and explicitly define how many of each part comprise the assembly,
> > and what each is worth. Then the system would need to add up the sum of
> > parts values, and ensure that the sum of parts equals the assembly total. I
> > can think of two ways to do this
> >
> > 1. Assign any remainder to another 'part'. That part would probably be
> > a default part.
> > 2. As an alternative perhaps a set of parts could be nominated at
> > breakdown time to have the remainder spread over them in some way, either
> > equally or weighted by relative volume of part.
>
>
>
> Agreed that this is the general outline. However, as prices fluctuate on
> purchase, this gets somewhat more difficult.
>
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.
Furthermore if an assembly component is also purchased separately, this
> could lead to interesting results (suppose we have enough data in the
> purchase history to conclude that component A goes up in price while
> component B drops. How much does this need to be automated?).
>
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.
The other question is *how* the cost breakdown data should be entered.
> Should it be a percent? Should it be a value that we use to calculate a
> ratio? What works best? (I would side with the value because it allows one
> to use rational numbers which do not convert losslessly to decimal.)
>
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...)
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.
>
I was thinking that initially a user could adjust/recalculate the breakdown
costs/prices repeatedly with a similar Update function as on Invoices etc,
prior to saving it. The system would need to have rules about reapplying
values to existing stock when an assembly or breakdown is
calculated/recalculated. However this requirement should no different to a
present requirement to do this on current stock in the current version of
the system. I suppose the question is whether the current system applies
price changes the way users want...
Historically, the ancestor system seemed to be designed along the lines of
"This is how the system works and it reflects how your business should work.
If you want something else, you obviously don't understand anything about
business." I have been involved in the past in a large application software
developer that decided to work somewhat this way, except their way of
expressing it was more "We contend we have experts in this field. So if you
want software that reflects this expertise, then buy ours." They were big.
They had cred in the field. This message from them was acceptable, and
welcomed by many customers, who did not want the expense of building up that
expertise inhouse. However in the case of this project, I think the opposite
approach is more suitable: something like "This is a general accounting
package, that dictates as little as possible about how you run your
business." Therefore a minimum of operational business rules should be
embedded in the system, and instead rules engines used to provide an 80/20
solution, and if you are lucky 100/0 in some cases. I think that the
strength of LSMB will come from developing the system with this sort of
philosophy in mind.
I think we should target a basic, non-automated version of this for 1.4 and
> continue to discuss requirements, etc. here.
>
> Best Wishes,
> Chris Travers
>
>
>
>
> -------------------------------------------------------------------------
> 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
>
>
--
The Last Great Frontier is in Your Mind
-------------------------------------------------------------------------
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
