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 -------------------------------------------------------
