Menu
▾
▴
web-erp-developers
|
From: opto <bu...@op...> - 2012-05-23 06:50:47
|
Currently, all MRP planning calculations use the required (end) date of a WO. In my opinion, that is a major bug (deficiency, annoyance, however you call it). In practical life, it is just not possible to do a workorder if planned PO's are dated such, that, including the leadtime, the goods arrive on the closing date of the wo. I am in favour of changing that to use the start date. To also keep the old behaviour, one might add an extra checkbox on the screen where one starts MRP. One might be able to drop such a checkbox, as I cannot really see anybody want to plan his purchases so that the goods arrive too late to be worked on in the WO. Only kits or assemblies might make use of reqdate. I am currently reviewing functionality for manufacturing from openerp, adempiere/libero, ofbiz, openmfg/postbooks and our own business flow (both MTO and MTS, discrete manufacturing) to see what makes sense, and nobody else plans for the end of the WO. I think from the review I can make some more proposals of what to adapt for better usability. Also, it would be good to have a leadtime for items in a BOM and WO. Like part AA is needed 20 days after WO start (or xx days before WO end). That would help just in time ordering for long duration WO's (like delivery time 5 months, when do I need to spend the money for expensive parts needed in the middle of that period?). You find this in adempiere, libero, openmfg, don't remember about the other two. Didn't try whether it works there (I would assume openmfg because it is commercial) but it definitely makes sense. If the field defaults to 0 days, it is no extra complication for new users. What do you think? I am willing to make the change if agreed on. Klaus -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: Phil D. <ph...@lo...> - 2012-05-23 07:15:40
|
Yes - this makes abundant sense to me Klaus. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 23/05/12 18:50, opto wrote: > Currently, all MRP planning calculations use the required (end) date of a WO. > > In my opinion, that is a major bug (deficiency, annoyance, however you call > it). > > In practical life, it is just not possible to do a workorder if planned PO's > are dated such, that, including the leadtime, the goods arrive on the > closing date of the wo. > > I am in favour of changing that to use the start date. To also keep the old > behaviour, one might add an extra checkbox on the screen where one starts > MRP. One might be able to drop such a checkbox, as I cannot really see > anybody want to plan his purchases so that the goods arrive too late to be > worked on in the WO. > Only kits or assemblies might make use of reqdate. > > I am currently reviewing functionality for manufacturing from openerp, > adempiere/libero, ofbiz, openmfg/postbooks and our own business flow (both > MTO and MTS, discrete manufacturing) to see what makes sense, and nobody > else plans for the end of the WO. I think from the review I can make some > more proposals of what to adapt for better usability. > > Also, it would be good to have a leadtime for items in a BOM and WO. Like > part AA is needed 20 days after WO start (or xx days before WO end). That > would help just in time ordering for long duration WO's (like delivery time > 5 months, when do I need to spend the money for expensive parts needed in > the middle of that period?). You find this in adempiere, libero, openmfg, > don't remember about the other two. > Didn't try whether it works there (I would assume openmfg because it is > commercial) but it definitely makes sense. If the field defaults to 0 days, > it is no extra complication for new users. > > What do you think? I am willing to make the change if agreed on. > > Klaus > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Tim S. <ti...@we...> - 2012-05-26 09:49:46
|
On 23 May 2012 07:50, opto <bu...@op...> wrote: > Also, it would be good to have a leadtime for items in a BOM and WO. Like > part AA is needed 20 days after WO start (or xx days before WO end). That > would help just in time ordering for long duration WO's (like delivery time > 5 months, when do I need to spend the money for expensive parts needed in > the middle of that period?). You find this in adempiere, libero, openmfg, > don't remember about the other two. > Didn't try whether it works there (I would assume openmfg because it is > commercial) but it definitely makes sense. If the field defaults to 0 days, > it is no extra complication for new users. > Hi Klaus, Just thinking about this what would happen if an item was used at two different points in the production process? ie you use 10 after 7 days and another 10 after 30 days. At the moment an item can only appear once in a BOM, and I think there are implications elsewhere if we change that. Thanks Tim -- WebERP Africa Ltd +447710427049 +254706554559 www.weberpafrica.com @TimSchofield2 |
|
From: opto <bu...@op...> - 2012-05-27 10:19:55
|
well - possible answers: 1) Using WO required date for MRP PO clearly is a bug - even the manual says the items should be procured for WO start date. I will change that file in the next days 2) currently, any item can be only once per BOM. If it is used in two places at different times, I have to enter 2 required and the earliest time and procure both parts for that date (in the current implementation) 3) the current MRP implementation prevents the use of weberp in the electronics industry (actually, you can find a similiar complaint about openerp in their forum). Part lists for electronic assemblies typically have component counts higher than 1 (like I need two resistors of 1 kiloohm value), and the CAD numbers them like R1, R7 to indicate their position n the circuit diagram. For clarity, it would be nice to reflect that in the BOM's, but after a short look at the code, this would need more serious consideration whether the current mrp.php needs to be changed. 4) BOM's need a few custom fields to be usable in daily work (same for workorders). First, the BOM will correspond to a product number, will have a revision, documents, a staging URL, etc. Here, the current BOMs miss some mapping possibility to the actual engineering documents related to the BOM. You find that in other ERP/MRP software, and it should not be too difficult to add. just some more thoughts on the manufacturing implementation, Klaus -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655124.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: Tim S. <ti...@we...> - 2012-05-27 10:43:28
|
Hi Klaus, On 27 May 2012 11:19, opto <bu...@op...> wrote: > well - possible answers: > > 1) > Using WO required date for MRP PO clearly is a bug - even the manual says > the items should be procured for WO start date. I will change that file in > the next days Agreed. > > 2) currently, any item can be only once per BOM. If it is used in two places > at different times, I have to enter 2 required and the earliest time and > procure both parts for that date (in the current implementation) Yes, this was what I was commenting on in my previous mail. Personally I would rather see us move away from the concept of a BOM to the concept of a recipe. ie. Mixing a BOM and a route so you get a "You do this with that at this point" rather than just a "you use this to make that" approach. That is a lot of work though to change, and needs thought as to how we safely transition the code. > > 3) the current MRP implementation prevents the use of weberp in the > electronics industry (actually, you can find a similiar complaint about > openerp in their forum). Part lists for electronic assemblies typically have > component counts higher than 1 (like I need two resistors of 1 kiloohm > value), and the CAD numbers them like R1, R7 to indicate their position n > the circuit diagram. For clarity, it would be nice to reflect that in the > BOM's, but after a short look at the code, this would need more serious > consideration whether the current mrp.php needs to be changed. Would the recipe concept I talked about cover this? > > 4) BOM's need a few custom fields to be usable in daily work (same for > workorders). > First, the BOM will correspond to a product number, will have a revision, > documents, a staging URL, etc. > Here, the current BOMs miss some mapping possibility to the actual > engineering documents related to the BOM. You find that in other ERP/MRP > software, and it should not be too difficult to add. Agreed. Adding extra fields in the database for BOMs would not have to complicate matters too much. I suggested in an earlier thread to Exson that we could define a function that returned a BOM (in the current format) based on a particular date. Then all we have to do is to use this functionality wherever in the code we query the bom table (ok there is a bit of work to do, but locating all the points shouldn't be hard). I would suggest we looked at how we wanted to extend the bom table, add in those fields, define this function I mentioned, then we could start to incrementally improve the manufacturing functionality. > > just some more thoughts on the manufacturing implementation, > > Klaus > Thanks Tim -- WebERP Africa Ltd +447710427049 +254706554559 www.weberpafrica.com @TimSchofield2 |
|
From: ExsonQu <hex...@gm...> - 2012-05-27 11:20:31
|
*Dear all:*
I cannot agree that use WO started date as PO date is a bug. I
believe it's a operation mistake instead of bugs.
Most of time, wo is just execution phase instead of a Planning phase.
Although webERP has give a forecast type, that does not mean you have to use
a word forecast. You should use buid to plan, or build to stock. Nobody
don't allow you to do that.
For those products produced in shorter time, the WO only issued when
the materials are ready. That's why we should use a planning tools instead
of using Work orders as a planning tools.
And moreover, if you think it's a bugs, you have to face the problem of
excess (redundant products) in MRP suggested reschedule.
I think the more reasonable way is to rework the master plan to make
it be more intuitive and convenient instead of reworking those tested code.
Best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655129.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: opto <bu...@op...> - 2012-05-27 20:29:05
|
Hi Exson, this was the intention of Mark Yeager when he wrote the MRP extension: 'each of the components in the bill of material need to be available before the item being sold can be manufactured.' see http://localhost/we1/doc/Manual/ManualContents.php?ViewTopic=Manufacturing. He wants the procurements/PO items available before the wo starts. Same for Wikipedia, which defines under MRP Material Ressource Planning: 'MRP is a tool to deal with these problems. It provides answers for several questions: What items are required? How many are required? When are they required? ' ... when are items required. Those that I need to modify are definitely required before I modify them, not at the end of the workorder. Maybe we can have a flag to choose start or end of wo, if that is required or would keep the old functionality for current users of MRP. As we actually work on items during manufacturing, a MRP which procures for end date is not usable for us. and your remark: 'You should use buid to plan, or build to stock.' If I build to stock, MRP reschedules calls to cancel it, see my other post. thanks for your comments and inputs, Klaus -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655133.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: Phil D. <ph...@lo...> - 2012-05-27 21:56:46
|
I agree that components need to be available before the wo starts so it is the start date of the wo that should be worked back from not the required date. As regards the BOM functionality it is possible to have the same component required from different work centres. It is a bug that deletes both from the BOM and that the MRP does not deal with both components or at least add the two requirements together. -- Phil Phil Daintree +64 (0)275 567890 GMT+12 http://www.logicworks.co.nz opto <bu...@op...> wrote: >Hi Exson, > >this was the intention of Mark Yeager when he wrote the MRP extension: > >'each of the components in the bill of material need to be available >before >the item being sold can be manufactured.' see >http://localhost/we1/doc/Manual/ManualContents.php?ViewTopic=Manufacturing. > >He wants the procurements/PO items available before the wo starts. > >Same for Wikipedia, which defines under MRP Material Ressource >Planning: >'MRP is a tool to deal with these problems. It provides answers for >several >questions: > What items are required? > How many are required? > When are they required? >' > >... when are items required. >Those that I need to modify are definitely required before I modify >them, >not at the end of the workorder. > >Maybe we can have a flag to choose start or end of wo, if that is >required >or would keep the old functionality for current users of MRP. > >As we actually work on items during manufacturing, a MRP which procures >for >end date is not usable for us. > > >and your remark: >'You should use buid to plan, or build to stock.' > >If I build to stock, MRP reschedules calls to cancel it, see my other >post. > >thanks for your comments and inputs, > >Klaus > > >-- >View this message in context: >http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655133.html >Sent from the web-ERP-developers mailing list archive at Nabble.com. > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. >Discussions >will include endpoint security, mobile security and the latest in >malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Web-erp-developers mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Tim S. <ti...@we...> - 2012-05-27 21:32:44
|
Hi Klaus, On 27 May 2012 11:43, Tim Schofield <ti...@we...> wrote: > > Agreed. Adding extra fields in the database for BOMs would not have to > complicate matters too much. I suggested in an earlier thread to Exson > that we could define a function that returned a BOM (in the current > format) based on a particular date. Then all we have to do is to use > this functionality wherever in the code we query the bom table (ok > there is a bit of work to do, but locating all the points shouldn't be > hard). I would suggest we looked at how we wanted to extend the bom > table, add in those fields, define this function I mentioned, then we > could start to incrementally improve the manufacturing functionality. > I was giving some thought to this today while out in the garden soaking up the sun. It should be easy to upgrade the bom table definition without affecting backwards compatibility with the current scripts. As a test I created two tables as follows: CREATE TABLE bomheader ( `bomid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, `productid` VARCHAR(20) NOT NULL DEFAULT '', `uom` VARCHAR(20) NOT NULL DEFAULT '', `revisionlevel` INT NOT NULL DEFAULT 1, `loccode` char(5) NOT NULL DEFAULT '', KEY `ProductID` (`productid`), CONSTRAINT `bomheader_ibfk_1` FOREIGN KEY (`productid`) REFERENCES `stockmaster` (`stockid`), CONSTRAINT `bomheader_ibfk_2` FOREIGN KEY (`uom`) REFERENCES `unitsofmeasure` (`unitname`), CONSTRAINT `bomheader_ibfk_3` FOREIGN KEY (`loccode`) REFERENCES `locations` (`loccode`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 CREATE TABLE bomlines ( `lineid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, `headerid` INT NOT NULL DEFAULT 0, `componentid` VARCHAR(20) NOT NULL DEFAULT '', `uom` VARCHAR(20) NOT NULL DEFAULT '', `revisionlevel` INT NOT NULL DEFAULT 1, `quantity` double NOT NULL DEFAULT '1', `effectivefrom` DATE NOT NULL DEFAULT '0000-00-00', `effectiveto` DATE NOT NULL DEFAULT '0000-00-00', `workcentreadded` char(5) NOT NULL DEFAULT '', `autoissue` tinyint(4) NOT NULL DEFAULT '0', KEY `ComponentID` (`componentid`), CONSTRAINT `bomlines_ibfk_1` FOREIGN KEY (`componentid`) REFERENCES `stockmaster` (`stockid`), CONSTRAINT `bomlines_ibfk_2` FOREIGN KEY (`headerid`) REFERENCES `bomheader` (`bomid`), CONSTRAINT `bomlines_ibfk_3` FOREIGN KEY (`uom`) REFERENCES `unitsofmeasure` (`unitname`), CONSTRAINT `bomlines_ibfk_4` FOREIGN KEY (`workcentreadded`) REFERENCES `workcentres` (`code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 I know there are other things we could add in or not put in here but stay with me its an experiment. Then I copied the current bom data over to these news tables with: INSERT INTO `bomheader` (`productid`, `uom`, `revisionlevel`, `loccode`) (SELECT DISTINCT parent, (SELECT units FROM stockmaster WHERE stockid=bom.parent), 1, loccode FROM `bom`) and : INSERT INTO `bomlines` (`headerid`, `componentid`, `uom`, `revisionlevel`, `quantity`, `effectivefrom`, `effectiveto`, `workcentreadded`, `autoissue`) (SELECT (SELECT bomid FROM bomheader WHERE productid=bom.parent), component, (SELECT units FROM stockmaster WHERE stockid=bom.parent), 1, quantity, effectiveafter, effectiveto, workcentreadded, autoissue FROM `bom`) Then I drop the original bom table: DROP TABLE bom Finally I create a view which identically matches the original bom table taking the data from the new tables: CREATE VIEW bom (`parent`, `component`, `workcentreadded`, `loccode`, `effectiveafter`, `effectiveto`, `quantity`, `autoissue`) AS SELECT bomheader.productid, bomlines.componentid, bomlines.workcentreadded, bomheader.loccode, bomlines.effectivefrom, bomlines.effectiveto, sum(bomlines.quantity), bomlines.autoissue FROM bomheader LEFT JOIN bomlines ON bomheader.bomid=bomlines.headerid All of the old scripts with the exception of BOMs.php will continue to work as before, but now I have expanded the bills of material so that we can include a lot of extra functionality, that we can then start to bring into webERP without harming what is there already. Does this rambling make sense or have I had too much sun? Thanks Tim -- WebERP Africa Ltd +447710427049 +254706554559 www.weberpafrica.com @TimSchofield2 |
|
From: Phil D. <ph...@lo...> - 2012-05-27 22:00:32
|
Sun is fierce over there at the moment ;-) I think we have quite a bit of functionality in the BOM that is not actually dealt with properly in the MRP which we should deal with first. -- Phil Phil Daintree +64 (0)275 567890 GMT+12 http://www.logicworks.co.nz Tim Schofield <ti...@we...> wrote: >Hi Klaus, > >On 27 May 2012 11:43, Tim Schofield <ti...@we...> wrote: >> >> Agreed. Adding extra fields in the database for BOMs would not have >to >> complicate matters too much. I suggested in an earlier thread to >Exson >> that we could define a function that returned a BOM (in the current >> format) based on a particular date. Then all we have to do is to use >> this functionality wherever in the code we query the bom table (ok >> there is a bit of work to do, but locating all the points shouldn't >be >> hard). I would suggest we looked at how we wanted to extend the bom >> table, add in those fields, define this function I mentioned, then we >> could start to incrementally improve the manufacturing functionality. >> > >I was giving some thought to this today while out in the garden >soaking up the sun. It should be easy to upgrade the bom table >definition without affecting backwards compatibility with the current >scripts. As a test I created two tables as follows: > >CREATE TABLE bomheader ( >`bomid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, >`productid` VARCHAR(20) NOT NULL DEFAULT '', >`uom` VARCHAR(20) NOT NULL DEFAULT '', >`revisionlevel` INT NOT NULL DEFAULT 1, >`loccode` char(5) NOT NULL DEFAULT '', >KEY `ProductID` (`productid`), >CONSTRAINT `bomheader_ibfk_1` FOREIGN KEY (`productid`) REFERENCES >`stockmaster` (`stockid`), >CONSTRAINT `bomheader_ibfk_2` FOREIGN KEY (`uom`) REFERENCES >`unitsofmeasure` (`unitname`), >CONSTRAINT `bomheader_ibfk_3` FOREIGN KEY (`loccode`) REFERENCES >`locations` (`loccode`) >) ENGINE=InnoDB DEFAULT CHARSET=utf8 > >CREATE TABLE bomlines ( >`lineid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, >`headerid` INT NOT NULL DEFAULT 0, >`componentid` VARCHAR(20) NOT NULL DEFAULT '', >`uom` VARCHAR(20) NOT NULL DEFAULT '', >`revisionlevel` INT NOT NULL DEFAULT 1, >`quantity` double NOT NULL DEFAULT '1', >`effectivefrom` DATE NOT NULL DEFAULT '0000-00-00', >`effectiveto` DATE NOT NULL DEFAULT '0000-00-00', >`workcentreadded` char(5) NOT NULL DEFAULT '', >`autoissue` tinyint(4) NOT NULL DEFAULT '0', >KEY `ComponentID` (`componentid`), >CONSTRAINT `bomlines_ibfk_1` FOREIGN KEY (`componentid`) REFERENCES >`stockmaster` (`stockid`), >CONSTRAINT `bomlines_ibfk_2` FOREIGN KEY (`headerid`) REFERENCES >`bomheader` (`bomid`), >CONSTRAINT `bomlines_ibfk_3` FOREIGN KEY (`uom`) REFERENCES >`unitsofmeasure` (`unitname`), >CONSTRAINT `bomlines_ibfk_4` FOREIGN KEY (`workcentreadded`) >REFERENCES `workcentres` (`code`) >) ENGINE=InnoDB DEFAULT CHARSET=utf8 > >I know there are other things we could add in or not put in here but >stay with me its an experiment. >Then I copied the current bom data over to these news tables with: > >INSERT INTO `bomheader` (`productid`, `uom`, `revisionlevel`, >`loccode`) (SELECT DISTINCT parent, (SELECT units FROM stockmaster >WHERE stockid=bom.parent), 1, loccode FROM `bom`) > >and : > >INSERT INTO `bomlines` (`headerid`, `componentid`, `uom`, >`revisionlevel`, `quantity`, `effectivefrom`, `effectiveto`, >`workcentreadded`, `autoissue`) > (SELECT (SELECT bomid FROM bomheader WHERE productid=bom.parent), >component, (SELECT units FROM stockmaster WHERE stockid=bom.parent), >1, quantity, effectiveafter, effectiveto, workcentreadded, autoissue >FROM `bom`) > >Then I drop the original bom table: > >DROP TABLE bom > >Finally I create a view which identically matches the original bom >table taking the data from the new tables: > >CREATE VIEW bom (`parent`, `component`, `workcentreadded`, `loccode`, >`effectiveafter`, `effectiveto`, `quantity`, `autoissue`) >AS SELECT bomheader.productid, bomlines.componentid, >bomlines.workcentreadded, bomheader.loccode, bomlines.effectivefrom, >bomlines.effectiveto, sum(bomlines.quantity), bomlines.autoissue FROM >bomheader LEFT JOIN bomlines ON bomheader.bomid=bomlines.headerid > >All of the old scripts with the exception of BOMs.php will continue to >work as before, but now I have expanded the bills of material so that >we can include a lot of extra functionality, that we can then start to >bring into webERP without harming what is there already. > >Does this rambling make sense or have I had too much sun? > >Thanks >Tim > >-- >WebERP Africa Ltd >+447710427049 >+254706554559 >www.weberpafrica.com >@TimSchofield2 > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. >Discussions >will include endpoint security, mobile security and the latest in >malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Web-erp-developers mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Tim S. <ti...@we...> - 2012-05-28 08:25:23
|
Well initially you have to fix all the bugs in BOMs.php. It would seem sensible at the same time to include this small fix which would greatly enhance the BOM whilst not affecting anything other script. It will also be very hard to alter MRP without changing the BOM, but I shall watch with interest how you manage it. Thanks Tim On 27 May 2012 23:00, Phil Daintree <ph...@lo...> wrote: > Sun is fierce over there at the moment ;-) > I think we have quite a bit of functionality in the BOM that is not actually dealt with properly in the MRP which we should deal with first. > -- > Phil > Phil Daintree > +64 (0)275 567890 GMT+12 > http://www.logicworks.co.nz > > Tim Schofield <ti...@we...> wrote: > >>Hi Klaus, >> >>On 27 May 2012 11:43, Tim Schofield <ti...@we...> wrote: >>> >>> Agreed. Adding extra fields in the database for BOMs would not have >>to >>> complicate matters too much. I suggested in an earlier thread to >>Exson >>> that we could define a function that returned a BOM (in the current >>> format) based on a particular date. Then all we have to do is to use >>> this functionality wherever in the code we query the bom table (ok >>> there is a bit of work to do, but locating all the points shouldn't >>be >>> hard). I would suggest we looked at how we wanted to extend the bom >>> table, add in those fields, define this function I mentioned, then we >>> could start to incrementally improve the manufacturing functionality. >>> >> >>I was giving some thought to this today while out in the garden >>soaking up the sun. It should be easy to upgrade the bom table >>definition without affecting backwards compatibility with the current >>scripts. As a test I created two tables as follows: >> >>CREATE TABLE bomheader ( >>`bomid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, >>`productid` VARCHAR(20) NOT NULL DEFAULT '', >>`uom` VARCHAR(20) NOT NULL DEFAULT '', >>`revisionlevel` INT NOT NULL DEFAULT 1, >>`loccode` char(5) NOT NULL DEFAULT '', >>KEY `ProductID` (`productid`), >>CONSTRAINT `bomheader_ibfk_1` FOREIGN KEY (`productid`) REFERENCES >>`stockmaster` (`stockid`), >>CONSTRAINT `bomheader_ibfk_2` FOREIGN KEY (`uom`) REFERENCES >>`unitsofmeasure` (`unitname`), >>CONSTRAINT `bomheader_ibfk_3` FOREIGN KEY (`loccode`) REFERENCES >>`locations` (`loccode`) >>) ENGINE=InnoDB DEFAULT CHARSET=utf8 >> >>CREATE TABLE bomlines ( >>`lineid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, >>`headerid` INT NOT NULL DEFAULT 0, >>`componentid` VARCHAR(20) NOT NULL DEFAULT '', >>`uom` VARCHAR(20) NOT NULL DEFAULT '', >>`revisionlevel` INT NOT NULL DEFAULT 1, >>`quantity` double NOT NULL DEFAULT '1', >>`effectivefrom` DATE NOT NULL DEFAULT '0000-00-00', >>`effectiveto` DATE NOT NULL DEFAULT '0000-00-00', >>`workcentreadded` char(5) NOT NULL DEFAULT '', >>`autoissue` tinyint(4) NOT NULL DEFAULT '0', >>KEY `ComponentID` (`componentid`), >>CONSTRAINT `bomlines_ibfk_1` FOREIGN KEY (`componentid`) REFERENCES >>`stockmaster` (`stockid`), >>CONSTRAINT `bomlines_ibfk_2` FOREIGN KEY (`headerid`) REFERENCES >>`bomheader` (`bomid`), >>CONSTRAINT `bomlines_ibfk_3` FOREIGN KEY (`uom`) REFERENCES >>`unitsofmeasure` (`unitname`), >>CONSTRAINT `bomlines_ibfk_4` FOREIGN KEY (`workcentreadded`) >>REFERENCES `workcentres` (`code`) >>) ENGINE=InnoDB DEFAULT CHARSET=utf8 >> >>I know there are other things we could add in or not put in here but >>stay with me its an experiment. >>Then I copied the current bom data over to these news tables with: >> >>INSERT INTO `bomheader` (`productid`, `uom`, `revisionlevel`, >>`loccode`) (SELECT DISTINCT parent, (SELECT units FROM stockmaster >>WHERE stockid=bom.parent), 1, loccode FROM `bom`) >> >>and : >> >>INSERT INTO `bomlines` (`headerid`, `componentid`, `uom`, >>`revisionlevel`, `quantity`, `effectivefrom`, `effectiveto`, >>`workcentreadded`, `autoissue`) >> (SELECT (SELECT bomid FROM bomheader WHERE productid=bom.parent), >>component, (SELECT units FROM stockmaster WHERE stockid=bom.parent), >>1, quantity, effectiveafter, effectiveto, workcentreadded, autoissue >>FROM `bom`) >> >>Then I drop the original bom table: >> >>DROP TABLE bom >> >>Finally I create a view which identically matches the original bom >>table taking the data from the new tables: >> >>CREATE VIEW bom (`parent`, `component`, `workcentreadded`, `loccode`, >>`effectiveafter`, `effectiveto`, `quantity`, `autoissue`) >>AS SELECT bomheader.productid, bomlines.componentid, >>bomlines.workcentreadded, bomheader.loccode, bomlines.effectivefrom, >>bomlines.effectiveto, sum(bomlines.quantity), bomlines.autoissue FROM >>bomheader LEFT JOIN bomlines ON bomheader.bomid=bomlines.headerid >> >>All of the old scripts with the exception of BOMs.php will continue to >>work as before, but now I have expanded the bills of material so that >>we can include a lot of extra functionality, that we can then start to >>bring into webERP without harming what is there already. >> >>Does this rambling make sense or have I had too much sun? >> >>Thanks >>Tim >> >>-- >>WebERP Africa Ltd >>+447710427049 >>+254706554559 >>www.weberpafrica.com >>@TimSchofield2 >> >>------------------------------------------------------------------------------ >>Live Security Virtual Conference >>Exclusive live event will cover all the ways today's security and >>threat landscape has changed and how IT managers can respond. >>Discussions >>will include endpoint security, mobile security and the latest in >>malware >>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>_______________________________________________ >>Web-erp-developers mailing list >>Web...@li... >>https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers -- WebERP Africa Ltd +447710427049 +254706554559 www.weberpafrica.com @TimSchofield2 |
|
From: opto <bu...@op...> - 2012-05-30 06:43:06
|
Hi Tim, yes, this sounds very good, epecially using the view to keep track of all other old scripts. One might need a new header upon every change to the BOM? Ideally, each change to a BOM needs to create a new revisionlevel. For file storage, web2project does something similiar, autonumbers major/minor revisions and also stores the old db records. The 'new' product related directives of the European community demand more entensive product documentation than before, so a good system/support for automatic (maybe in addition to a free text field) revision numbers would be good. thanks, Klaus -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655141.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: Tim S. <ti...@we...> - 2012-05-30 10:42:12
|
Hi Klaus, Yes keeping each revision in the table and then just adjusting the sql in the view to pick the info from the latest revision. Also we could track major and minor revision numbers by keeping the numbers in the systypes table. Would need help from someone more knowledgeable about this, such as you, to decide on the correct fields we need, but using a view will allow us to do that without breaking weberp. BTW the sql in the view that I sent earlier was slightly wrong it should have been: CREATE VIEW bom (`parent`, `component`, `workcentreadded`, `loccode`, `effectiveafter`, `effectiveto`, `quantity`, `autoissue`) AS SELECT bomheader.productid, bomlines.componentid, bomlines.workcentreadded, bomheader.loccode, bomlines.effectivefrom, bomlines.effectiveto, sum(bomlines.quantity), bomlines.autoissue FROM bomheader LEFT JOIN bomlines ON bomheader.bomid=bomlines.headerid GROUP BY bomheader.productid, bomlines.componentid Thanks Tim On 30 May 2012 07:42, opto <bu...@op...> wrote: > Hi Tim, > > yes, this sounds very good, epecially using the view to keep track of all > other old scripts. > > One might need a new header upon every change to the BOM? > > Ideally, each change to a BOM needs to create a new revisionlevel. > For file storage, web2project does something similiar, autonumbers > major/minor revisions and also stores the old db records. > > The 'new' product related directives of the European community demand more > entensive product documentation than before, so a good system/support for > automatic (maybe in addition to a free text field) revision numbers would be > good. > > thanks, > > Klaus > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4655141.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers -- WebERP Africa Ltd +447710427049 +254706554559 www.weberpafrica.com @TimSchofield2 |
|
From: opto <bu...@op...> - 2014-09-24 19:15:40
|
I still fully support what I wrote two years ago: 1) MRP must be for start of WO, not for end of WO. Components must be available when I start manufacturing. 2) It would be preferable to have lead time for components. If they cost 20.000 EUR, I do not want to order them before wo start if I only need them after 12 weeks (optimise flow of capital funds) 3) History of wo changes is required by German and European product laws. I think I provided a bug fix for 1) in 2012. 2) We have lead time for parts I buy. how about defining myself as supplier for those parts I produce, define the item, then I have the field for the lead time and can even use that on my own components. So for all manufactured components, I would either use 0 or the time from: supplier:myself/mycomponent/leadtime Klaus -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4657670.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: rfthomas <rf...@as...> - 2014-09-29 14:34:13
|
Tim and Klaus, The MySQL table changes appear to make sense, but we have the problem of properly identifying the process revisions and production history. There are a number of areas that need to know and deal with such information. The following is coding of inventory could work: <product code>_<product revision>_<routing>_<routing revision> It would be assumed that in normal operation the latest active item would be produced and sold. Salesmen would for normal sales, quote <product> and the system would automatically select the most recent active product (<product code>_<product revision>_<routing>_<routing revision>). Order acknowledgements, shipping documents, work orders, etc. would normally default to the most recent active product. We need to be able to know the full pedigree of the parts sold. There are times when one must produce a product to an earlier revision. One would need to be able to select the full product code. One could end up with a very large number of fully qualified product codes. Bob Thomas -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4657676.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X