You can easily plug in to the backend if you setup your own tables
and link to the existing ones.

i.e the assembly table is a bunch of pointers into the parts table, one
for itself and others for the individual parts. If the table does not
exists SL will still function, you just loose the assemblies.

I expanded the code for some manufacturing processes already and there is
more to come yet. I split up the code into small chunks so you really only
run what you need and it doesn't add that much to have some of the
manufacturing processes in the core. Whatever fits in with accounting is
going in, other things like drawing takeoffs, transmittal forms, fiche
readers, etc. will be standalone programs.


Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
=========== On a clear disk you can seek forever ===========

On Wed, 23 Oct 2002, Michael Stares wrote:

>
>
> >Date: Tue, 22 Oct 2002 17:16:56 +0100
> From: Paul Thomas <[EMAIL PROTECTED]>
> >Subject: Re: What we would like to see...
> >
> >On 21/10/2002 18:36 Michael Stares wrote:
> >> Hi, I'm a developer with an interest in SL, namely from a
> >> manufacturing point of view, as SL is quite close to providing a
> >> manufacturing ERP solution, due to its ability to record inventory, an=
> d
> >> a=3D
> >> lso
> >> the assembly facility.  However It would require some extensions, in m=
> y
> >> opinion fairly easy to do.  I would be interesting to know whether the
> >> id=3D
> >> eas
> >> described below  (1) would be supported in principle (2) would gather
> >> som=3D
> >> e
> >> development support.
> >>
> >> I am currently porting a software package to Linux that performs MRP*,
> >> wi=3D
> >> th
> >> the idea of establishing a C++ project.  The software is well tested a=
> nd
> >> =3D
> >> has=3D20
> >> Windows users, so this is not pie-in-the-sky. Tentative name is MRP
> >> Serve=3D
> >> r. =3D20
> >> Its core function is an algorithm to generate new purchase and works
> >> orde=3D
> >> rs=3D20
> >> at a parts level from plans and customer orders at the product level.
> >> It=3D
> >> =3D20
> >> depends on data already existing on an external database e.g. SL.  By=3D=
> 20
> >> necessity it is quite a complicated algorithm that takes account of
> >> the=3D20
> >> current supply snapshot (inventory, purchase and works orders) to
> >> identif=3D
> >> y=3D20
> >> what incremental new supply needs to be initiated. The DB interface wi=
> ll
> >> =3D
> >> be=3D20
> >> ODBC. =3D20
> >>
> >> [snip]
>
> >IMHO, one of the best things about SL is that the data is stored in an S=
> QL
> >database. This makes it possible for other applications to access that
> >data. I've been considering developing an SL-bolt-on application to trac=
> k
> >time and materials booked to a job. There are many businesses which work
> >on a T%M basis or need to record time and materials for job
> >costing/estimating purposes. Its this whole MRP/BOM/Job Costing area. Bu=
> t
> >I see no crushing need for such additions to be part of the main
> >Perl-based release. In many businesses, these tasks are performed by
> >people who have no need to access the general accounting functions.
> >Parallel applications can enhance security is such circumstances.
>
>
> >--
> >Paul Thomas
> >Thomas Micro Systems Limited
>
> Paul, thanks. Yes I can agree with you that developing a separate=20
> manufacturing app. as a bolt-on would be preferable to bloating the base=20
> accounting app.  However there would be integration issues, particularly=20
> enhanced Inventory functionality and additional data elements in some tab=
> les. =20
> I guess this could be handled by a base SL install then the manufacturing=
>  app=20
> install supersedes the relevant bits of SL.=20
>
> Then someone who wants a manufacturing ERP would install:
> 1) SL
> 2) the manufacturing app (basically enhanced inventory functionality and =
> a new=20
> works order table + functionality).
> 3) my proposed MRP Server algorithm to perform PO and WO generation for=20
> factories with complex products.
>
> Anyone interested in establishing a project to develop the manufacturing =
> app=20
> (as developers)?=20
>
> Mike Stares
>
>




Reply via email to