On 9/26/07, David Tangye <..hidden..> 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.
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.
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.
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...
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.
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."
No comment.
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.
That is an excellent case for separating strictly enforced accounting rules from interface and workflow logic, which is exactly where we are headed.
Chris Travers