In response to your subject line-- if the code meets our standards and is
generally applicable to businesses, we accept contributions. See our
CONTRIBUTORS file for lists of people who have had contributions accepted.
On Dec 4, 2007 7:05 PM, <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
