I'm rather busy these days, but I'd be interested helping out with the database stuff (Postgres and Oracle), with a special interest in the Oracle part.
Rick Michael Stares wrote: >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 >manufacturing app. as a bolt-on would be preferable to bloating the base >accounting app. However there would be integration issues, particularly >enhanced Inventory functionality and additional data elements in some tab= >les. >I guess this could be handled by a base SL install then the manufacturing= > app >install supersedes the relevant bits of SL. > >Then someone who wants a manufacturing ERP would install: >1) SL >2) the manufacturing app (basically enhanced inventory functionality and = >a > new works order table + functionality). >3) my proposed MRP Server algorithm to perform PO and WO generation for >factories with complex products. > >Anyone interested in establishing a project to develop the manufacturing = >app >(as developers)? > >Mike Stares > >------------------------------------------------------- > > >
