On Dec 4, 2007 7:05 PM, <
..hidden..> wrote:
We have been using sql-ledger for years and are running into issues with
assemblies not being updateable.
For example if I have a labor unit L1 and a part P1 and together they make an
assembly 2 X L1 per 3 + P1 = A1
so assembly A1 contains 2 L1's and 3 P1's. Now we have for example 1000
assemblies that contain basic assemblies like that say A1 - A1000
Each of those 1000 assemblies contain other building block assemblies.
Example .04 L1 + 2P = A2 or part number P2 takes .04 L1's to install and so
on.
Now we change the amount of labor in A1 to L1 = .5 we have to redo over 10,000
assemblies by hand or hack the database. Not very appealing.
In the sql-ledger 2.7 version and I believe even the current there is no way
to update the quantity of items in an assembly and have it used by all new
transactions from theat point forward.
Yes this is a problem and it would be *really* nice to get this solved.
Ok, the big problem is that assembly data is not stored on stocked assemblies. It seems to me that the way around this is to store amounts of things used when an assembly is stocked. The assembly stock id is then used when the assembly is sold. For a service business, this solves the issue nicely. For a manufacturing business, it means that you can change things about components (substitute one part for another) without having to rebuild assemblies.
Basically, you want an item, when sold, to have an immutable cost and this accomplishes that pretty well. The current system does not store enough information to make that happen.
As this is becoming immensely mission critical we are developing the code to
do this. The question is weather it would be adopted, maintained, and
supported by ledgersmb or if ledgersmb users would find that useful?
Short answer, yes. However, please understand that not every contribution gets included and the best way to ensure that it does is to help work with us to ensure that things are done right and don't cause problems for other existing users. This means you will want to submit a proposal on this list detailing how you expect to solve the problem. Hanging out on IRC with us (#ledgersmb on freenode) is also helpful because you can often bounce ideas off contributors and authors in real time.
Also, get feedback on workflow and accounting needs on -users list.
In addition we have some custom modules that total stuff in an additional
abstraction layer. As we are Electrical Contractors we make quotations. Each
part is combined with a labor item to make an assembly for a particular
installation of that part. This is very handy for estimating complex work.
However we had no way of getting a total of all the items within the
assemblies that made up a quotation/ invoice/wor order or sales order. So we
developed a module.
We schedule and track projects and job costs, however these features are
undeveloped in sql-ledger. We are working on a better time card / work order
interface as well as developing some job costing summary's.
We are also looking into making a a calander module for scheduling work orders
or making a bridge to egroupware.
These all sound interesting and useful. Please also take a look at /trunk. We are working on making such modules a) easier to buld, b) more maintainable and c) less brittle.
We are currious about the more secure status of the GPL here in smbledger and
ledgersmb being able to roll in contributors (our) GPL code, and help us test
and develop the code.
The GPL is not a political choice for us. We licensed the SQL-Ledger code under that license when we forked, and I don't believe that it will ever be practical for us to move off that license. We are 100% committed to open source in general and there is *no* chance of us moving to licenses which are questionable in that regard. (Personally, I think it is important to stay compatible with Debian Free Software Guidelines as well simply because that is one more channel of distribution.) It is conceivable that we could accept or include contributions under more permissive licenses and we would probably keep those licenses intact.
The other major thing to note here is that LedgerSMB is not controlled by a single company. Sure, my view may carry a lot of weight but no single commercial entity has a majority voice on the core committee, or among committers, and I think we will keep it that way. IMNSHO, the promise of open source is undermined when a single commercial entity acts as gatekeeper for all commits because conflicts of interest are harder to avoid.
Hope this helps,
Chris Travers