Menu
▾
▴
web-erp-developers
|
From: Pak R. <pak...@gm...> - 2013-11-01 04:23:53
|
Hi all: We are facing a problem with Stock categories properties and would like to ind a good solution for everybody as now we keep the dimensions of stockid as a property in table stockcatproperties. Problem comes when an item changes stock category (quite often in our case), as we loose the data stored in stockcatproperties (because the stockcatproperties are linked with categoryid). A solution comes rewriting all stockcatproperties, so if stockcatproperties.label is equal in the new categoryid assigned to the stockid, then we copy all the values to the new stkcatpropid Another solution can be adding the field size into stockmaster. All physical items have a size (by definition). Services, software, etc no, but also do not have net weight, volume, etc and we kkep this info in stockmaster anyway. I think the most logical and universal solution is this second one, as the first one will have problems if label is not written exactly the same way, etc etc. Does everybody agree or there's any other option I'm missing here? Regards, Ricard |
|
From: Phil D. <ph...@lo...> - 2013-11-01 05:07:36
|
Well I think you are right we probably should have implemented weight and volume as category properties as they are not really relevant to some items particularly service items. To deal with changing stock categories correctly I think the correct way is to copy the category properties across if they are not already set up against the new category and then the item category properties can come across correctly too then to the new category item properties. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 01/11/13 17:23, Pak Ricard wrote: > Hi all: > > We are facing a problem with Stock categories properties and would > like to ind a good solution for everybody as now we keep the > dimensions of stockid as a property in table stockcatproperties. > > Problem comes when an item changes stock category (quite often in our > case), as we loose the data stored in stockcatproperties (because the > stockcatproperties are linked with categoryid). > > A solution comes rewriting all stockcatproperties, so if > stockcatproperties.label is equal in the new categoryid assigned to > the stockid, then we copy all the values to the new stkcatpropid > > Another solution can be adding the field size into stockmaster. All > physical items have a size (by definition). Services, software, etc > no, but also do not have net weight, volume, etc and we kkep this info > in stockmaster anyway. > > I think the most logical and universal solution is this second one, as > the first one will have problems if label is not written exactly the > same way, etc etc. > > Does everybody agree or there's any other option I'm missing here? > > Regards, > Ricard > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Pak R. <pak...@gm...> - 2013-11-01 06:09:49
|
Hi Phil: The detail t solve then is: How we detect if a category property "is the same" as another category property in another category? The table definition has a stkcatpropid but it's auto_incrment, so we can't use it as key. Label is the best candidate if it's used as a code, so in all categories, label should be exactly the same. is there any other way to solve it? Regards, Ricard 2013/11/1 Phil Daintree <ph...@lo...> > Well I think you are right we probably should have implemented weight > and volume as category properties as they are not really relevant to some > items particularly service items. To deal with changing stock categories > correctly I think the correct way is to copy the category properties across > if they are not already set up against the new category and then the item > category properties can come across correctly too then to the new category > item properties. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz > > On 01/11/13 17:23, Pak Ricard wrote: > > Hi all: > > We are facing a problem with Stock categories properties and would like > to ind a good solution for everybody as now we keep the dimensions of > stockid as a property in table stockcatproperties. > > Problem comes when an item changes stock category (quite often in our > case), as we loose the data stored in stockcatproperties (because the > stockcatproperties are linked with categoryid). > > A solution comes rewriting all stockcatproperties, so if > stockcatproperties.label is equal in the new categoryid assigned to the > stockid, then we copy all the values to the new stkcatpropid > > Another solution can be adding the field size into stockmaster. All > physical items have a size (by definition). Services, software, etc no, but > also do not have net weight, volume, etc and we kkep this info in > stockmaster anyway. > > I think the most logical and universal solution is this second one, as > the first one will have problems if label is not written exactly the same > way, etc etc. > > Does everybody agree or there's any other option I'm missing here? > > Regards, > Ricard > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
|
From: Phil D. <ph...@lo...> - 2013-11-01 07:26:25
|
No I don't think so we will have to check for the same label as you suggest... unless anyone else has any smart ideas? Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 01/11/13 19:09, Pak Ricard wrote: > Hi Phil: > > The detail t solve then is: How we detect if a category property "is > the same" as another category property in another category? The table > definition has a stkcatpropid but it's auto_incrment, so we can't use > it as key. Label is the best candidate if it's used as a code, so in > all categories, label should be exactly the same. > > is there any other way to solve it? > > Regards, > Ricard > > > 2013/11/1 Phil Daintree <ph...@lo... > <mailto:ph...@lo...>> > > Well I think you are right we probably should have implemented > weight and volume as category properties as they are not really > relevant to some items particularly service items. To deal with > changing stock categories correctly I think the correct way is to > copy the category properties across if they are not already set up > against the new category and then the item category properties can > come across correctly too then to the new category item properties. > > Phil > > Phil Daintree > Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> > http://www.logicworks.co.nz > > On 01/11/13 17:23, Pak Ricard wrote: >> Hi all: >> >> We are facing a problem with Stock categories properties and >> would like to ind a good solution for everybody as now we keep >> the dimensions of stockid as a property in table stockcatproperties. >> >> Problem comes when an item changes stock category (quite often in >> our case), as we loose the data stored in stockcatproperties >> (because the stockcatproperties are linked with categoryid). >> >> A solution comes rewriting all stockcatproperties, so if >> stockcatproperties.label is equal in the new categoryid assigned >> to the stockid, then we copy all the values to the new stkcatpropid >> >> Another solution can be adding the field size into stockmaster. >> All physical items have a size (by definition). Services, >> software, etc no, but also do not have net weight, volume, etc >> and we kkep this info in stockmaster anyway. >> >> I think the most logical and universal solution is this second >> one, as the first one will have problems if label is not written >> exactly the same way, etc etc. >> >> Does everybody agree or there's any other option I'm missing here? >> >> Regards, >> Ricard >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform that >> developers love is also attractive to malware creators. Download this white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development > platform that > developers love is also attractive to malware creators. Download > this white > paper to learn more about secure code signing practices that can > help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Pak R. <pak...@gm...> - 2013-11-06 02:39:23
|
Hi Phil: After checking and thinking for few days, it seems ugly to keep these dimensions in porperties, as we don't have any bullet proof way to compare them and be sure we transfer the data to the correct one. names can change, users can forget to update all the names for 1 same property between categoreies, etc... Seems too risky for me. I coded the 3 dimesions as fields in stockmaster. If you agree, I can commit it to SVN. Regards, Ricard 2013/11/1 Phil Daintree <ph...@lo...> > No I don't think so we will have to check for the same label as you > suggest... unless anyone else has any smart ideas? > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz > > On 01/11/13 19:09, Pak Ricard wrote: > > Hi Phil: > > The detail t solve then is: How we detect if a category property "is the > same" as another category property in another category? The table > definition has a stkcatpropid but it's auto_incrment, so we can't use it as > key. Label is the best candidate if it's used as a code, so in all > categories, label should be exactly the same. > > is there any other way to solve it? > > Regards, > Ricard > > > 2013/11/1 Phil Daintree <ph...@lo...> > >> Well I think you are right we probably should have implemented weight >> and volume as category properties as they are not really relevant to some >> items particularly service items. To deal with changing stock categories >> correctly I think the correct way is to copy the category properties across >> if they are not already set up against the new category and then the item >> category properties can come across correctly too then to the new category >> item properties. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz >> >> On 01/11/13 17:23, Pak Ricard wrote: >> >> Hi all: >> >> We are facing a problem with Stock categories properties and would like >> to ind a good solution for everybody as now we keep the dimensions of >> stockid as a property in table stockcatproperties. >> >> Problem comes when an item changes stock category (quite often in our >> case), as we loose the data stored in stockcatproperties (because the >> stockcatproperties are linked with categoryid). >> >> A solution comes rewriting all stockcatproperties, so if >> stockcatproperties.label is equal in the new categoryid assigned to the >> stockid, then we copy all the values to the new stkcatpropid >> >> Another solution can be adding the field size into stockmaster. All >> physical items have a size (by definition). Services, software, etc no, but >> also do not have net weight, volume, etc and we kkep this info in >> stockmaster anyway. >> >> I think the most logical and universal solution is this second one, as >> the first one will have problems if label is not written exactly the same >> way, etc etc. >> >> Does everybody agree or there's any other option I'm missing here? >> >> Regards, >> Ricard >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform that >> developers love is also attractive to malware creators. Download this white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
|
From: Phil D. <ph...@lo...> - 2013-11-07 06:49:30
|
Hi Ricard, I am not really keen to have these dimensions as separate fields in the stock master. Every installation has a requirement for other fields - dimensions really don't make sense for example for freight, bank charges, consultancy, dry cleaning or any service related items. I know we already have some redundant fields in stock master depending on what the item is. However, this is really what the properties are for. If you wish to have dimensions in your stockmaster table then I think it may be best to have these in your version only. Hope you understand Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 06/11/13 15:38, Pak Ricard wrote: > Hi Phil: > > After checking and thinking for few days, it seems ugly to keep these > dimensions in porperties, as we don't have any bullet proof way to > compare them and be sure we transfer the data to the correct one. > names can change, users can forget to update all the names for 1 same > property between categoreies, etc... > > Seems too risky for me. > > I coded the 3 dimesions as fields in stockmaster. If you agree, I can > commit it to SVN. > > Regards, > Ricard > > > 2013/11/1 Phil Daintree <ph...@lo... > <mailto:ph...@lo...>> > > No I don't think so we will have to check for the same label as > you suggest... unless anyone else has any smart ideas? > > Phil > > Phil Daintree > Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> > http://www.logicworks.co.nz > > On 01/11/13 19:09, Pak Ricard wrote: >> Hi Phil: >> >> The detail t solve then is: How we detect if a category property >> "is the same" as another category property in another category? >> The table definition has a stkcatpropid but it's auto_incrment, >> so we can't use it as key. Label is the best candidate if it's >> used as a code, so in all categories, label should be exactly the >> same. >> >> is there any other way to solve it? >> >> Regards, >> Ricard >> >> >> 2013/11/1 Phil Daintree <ph...@lo... >> <mailto:ph...@lo...>> >> >> Well I think you are right we probably should have >> implemented weight and volume as category properties as they >> are not really relevant to some items particularly service >> items. To deal with changing stock categories correctly I >> think the correct way is to copy the category properties >> across if they are not already set up against the new >> category and then the item category properties can come >> across correctly too then to the new category item properties. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >> http://www.logicworks.co.nz >> >> On 01/11/13 17:23, Pak Ricard wrote: >>> Hi all: >>> >>> We are facing a problem with Stock categories properties and >>> would like to ind a good solution for everybody as now we >>> keep the dimensions of stockid as a property in table >>> stockcatproperties. >>> >>> Problem comes when an item changes stock category (quite >>> often in our case), as we loose the data stored in >>> stockcatproperties (because the stockcatproperties are >>> linked with categoryid). >>> >>> A solution comes rewriting all stockcatproperties, so if >>> stockcatproperties.label is equal in the new categoryid >>> assigned to the stockid, then we copy all the values to the >>> new stkcatpropid >>> >>> Another solution can be adding the field size into >>> stockmaster. All physical items have a size (by definition). >>> Services, software, etc no, but also do not have net weight, >>> volume, etc and we kkep this info in stockmaster anyway. >>> >>> I think the most logical and universal solution is this >>> second one, as the first one will have problems if label is >>> not written exactly the same way, etc etc. >>> >>> Does everybody agree or there's any other option I'm missing >>> here? >>> >>> Regards, >>> Ricard >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform that >>> developers love is also attractive to malware creators. Download this white >>> paper to learn more about secure code signing practices that can help keep >>> Android apps secure. >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... <mailto:Web...@li...> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development >> platform that >> developers love is also attractive to malware creators. >> Download this white >> paper to learn more about secure code signing practices that >> can help keep >> Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform that >> developers love is also attractive to malware creators. Download this white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development > platform that > developers love is also attractive to malware creators. Download > this white > paper to learn more about secure code signing practices that can > help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Pak R. <pak...@gm...> - 2013-11-07 06:56:54
|
Sure Phil, that's why I asked ;-). I will keep them in stockmaster, until we all find a good solution for properties and can be transferred easily and safely. Are you already back in NZ or still in UK? Regards, Ricard 2013/11/7 Phil Daintree <ph...@lo...> > Hi Ricard, > > I am not really keen to have these dimensions as separate fields in the > stock master. Every installation has a requirement for other fields - > dimensions really don't make sense for example for freight, bank charges, > consultancy, dry cleaning or any service related items. I know we already > have some redundant fields in stock master depending on what the item is. > However, this is really what the properties are for. > If you wish to have dimensions in your stockmaster table then I think it > may be best to have these in your version only. > > Hope you understand > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz > > On 06/11/13 15:38, Pak Ricard wrote: > > Hi Phil: > > After checking and thinking for few days, it seems ugly to keep these > dimensions in porperties, as we don't have any bullet proof way to compare > them and be sure we transfer the data to the correct one. names can change, > users can forget to update all the names for 1 same property between > categoreies, etc... > > Seems too risky for me. > > I coded the 3 dimesions as fields in stockmaster. If you agree, I can > commit it to SVN. > > Regards, > Ricard > > > 2013/11/1 Phil Daintree <ph...@lo...> > >> No I don't think so we will have to check for the same label as you >> suggest... unless anyone else has any smart ideas? >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz >> >> On 01/11/13 19:09, Pak Ricard wrote: >> >> Hi Phil: >> >> The detail t solve then is: How we detect if a category property "is >> the same" as another category property in another category? The table >> definition has a stkcatpropid but it's auto_incrment, so we can't use it as >> key. Label is the best candidate if it's used as a code, so in all >> categories, label should be exactly the same. >> >> is there any other way to solve it? >> >> Regards, >> Ricard >> >> >> 2013/11/1 Phil Daintree <ph...@lo...> >> >>> Well I think you are right we probably should have implemented weight >>> and volume as category properties as they are not really relevant to some >>> items particularly service items. To deal with changing stock categories >>> correctly I think the correct way is to copy the category properties across >>> if they are not already set up against the new category and then the item >>> category properties can come across correctly too then to the new category >>> item properties. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz >>> >>> On 01/11/13 17:23, Pak Ricard wrote: >>> >>> Hi all: >>> >>> We are facing a problem with Stock categories properties and would >>> like to ind a good solution for everybody as now we keep the dimensions of >>> stockid as a property in table stockcatproperties. >>> >>> Problem comes when an item changes stock category (quite often in our >>> case), as we loose the data stored in stockcatproperties (because the >>> stockcatproperties are linked with categoryid). >>> >>> A solution comes rewriting all stockcatproperties, so if >>> stockcatproperties.label is equal in the new categoryid assigned to the >>> stockid, then we copy all the values to the new stkcatpropid >>> >>> Another solution can be adding the field size into stockmaster. All >>> physical items have a size (by definition). Services, software, etc no, but >>> also do not have net weight, volume, etc and we kkep this info in >>> stockmaster anyway. >>> >>> I think the most logical and universal solution is this second one, as >>> the first one will have problems if label is not written exactly the same >>> way, etc etc. >>> >>> Does everybody agree or there's any other option I'm missing here? >>> >>> Regards, >>> Ricard >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform that >>> developers love is also attractive to malware creators. Download this white >>> paper to learn more about secure code signing practices that can help keep >>> Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform >>> that >>> developers love is also attractive to malware creators. Download this >>> white >>> paper to learn more about secure code signing practices that can help >>> keep >>> Android apps secure. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform that >> developers love is also attractive to malware creators. Download this white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
|
From: Phil D. <ph...@lo...> - 2013-11-07 07:04:33
|
Back home in sunny NZ with team DaintreeNZ :-) Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 07/11/13 19:56, Pak Ricard wrote: > Sure Phil, that's why I asked ;-). I will keep them in stockmaster, > until we all find a good solution for properties and can be > transferred easily and safely. > > Are you already back in NZ or still in UK? > > Regards, > Ricard > > > 2013/11/7 Phil Daintree <ph...@lo... > <mailto:ph...@lo...>> > > Hi Ricard, > > I am not really keen to have these dimensions as separate fields > in the stock master. Every installation has a requirement for > other fields - dimensions really don't make sense for example for > freight, bank charges, consultancy, dry cleaning or any service > related items. I know we already have some redundant fields in > stock master depending on what the item is. However, this is > really what the properties are for. > If you wish to have dimensions in your stockmaster table then I > think it may be best to have these in your version only. > > Hope you understand > > Phil > > Phil Daintree > Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> > http://www.logicworks.co.nz > > On 06/11/13 15:38, Pak Ricard wrote: >> Hi Phil: >> >> After checking and thinking for few days, it seems ugly to keep >> these dimensions in porperties, as we don't have any bullet proof >> way to compare them and be sure we transfer the data to the >> correct one. names can change, users can forget to update all the >> names for 1 same property between categoreies, etc... >> >> Seems too risky for me. >> >> I coded the 3 dimesions as fields in stockmaster. If you agree, I >> can commit it to SVN. >> >> Regards, >> Ricard >> >> >> 2013/11/1 Phil Daintree <ph...@lo... >> <mailto:ph...@lo...>> >> >> No I don't think so we will have to check for the same label >> as you suggest... unless anyone else has any smart ideas? >> >> Phil >> >> Phil Daintree >> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >> http://www.logicworks.co.nz >> >> On 01/11/13 19:09, Pak Ricard wrote: >>> Hi Phil: >>> >>> The detail t solve then is: How we detect if a category >>> property "is the same" as another category property in >>> another category? The table definition has a stkcatpropid >>> but it's auto_incrment, so we can't use it as key. Label is >>> the best candidate if it's used as a code, so in all >>> categories, label should be exactly the same. >>> >>> is there any other way to solve it? >>> >>> Regards, >>> Ricard >>> >>> >>> 2013/11/1 Phil Daintree <ph...@lo... >>> <mailto:ph...@lo...>> >>> >>> Well I think you are right we probably should have >>> implemented weight and volume as category properties as >>> they are not really relevant to some items particularly >>> service items. To deal with changing stock categories >>> correctly I think the correct way is to copy the >>> category properties across if they are not already set >>> up against the new category and then the item category >>> properties can come across correctly too then to the new >>> category item properties. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >>> http://www.logicworks.co.nz >>> >>> On 01/11/13 17:23, Pak Ricard wrote: >>>> Hi all: >>>> >>>> We are facing a problem with Stock categories >>>> properties and would like to ind a good solution for >>>> everybody as now we keep the dimensions of stockid as a >>>> property in table stockcatproperties. >>>> >>>> Problem comes when an item changes stock category >>>> (quite often in our case), as we loose the data stored >>>> in stockcatproperties (because the stockcatproperties >>>> are linked with categoryid). >>>> >>>> A solution comes rewriting all stockcatproperties, so >>>> if stockcatproperties.label is equal in the new >>>> categoryid assigned to the stockid, then we copy all >>>> the values to the new stkcatpropid >>>> >>>> Another solution can be adding the field size into >>>> stockmaster. All physical items have a size (by >>>> definition). Services, software, etc no, but also do >>>> not have net weight, volume, etc and we kkep this info >>>> in stockmaster anyway. >>>> >>>> I think the most logical and universal solution is this >>>> second one, as the first one will have problems if >>>> label is not written exactly the same way, etc etc. >>>> >>>> Does everybody agree or there's any other option I'm >>>> missing here? >>>> >>>> Regards, >>>> Ricard >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Android is increasing in popularity, but the open development platform that >>>> developers love is also attractive to malware creators. Download this white >>>> paper to learn more about secure code signing practices that can help keep >>>> Android apps secure. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>>> >>>> >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... <mailto:Web...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open >>> development platform that >>> developers love is also attractive to malware creators. >>> Download this white >>> paper to learn more about secure code signing practices >>> that can help keep >>> Android apps secure. >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> <mailto:Web...@li...> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform that >>> developers love is also attractive to malware creators. Download this white >>> paper to learn more about secure code signing practices that can help keep >>> Android apps secure. >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... <mailto:Web...@li...> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development >> platform that >> developers love is also attractive to malware creators. >> Download this white >> paper to learn more about secure code signing practices that >> can help keep >> Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. Explore >> techniques for threading, error checking, porting, and tuning. Get the most >> from the latest Intel processors and coprocessors. See abstracts and register >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming > models. Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts > and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: rfthomas <rf...@as...> - 2013-11-15 16:39:39
|
A possible solution: The Category Properties should have a selection table, as exists for most other areas in the system. A system administrator should create the valid properties and when a new category is created only those existing properties may be selected. The properties would be interpreted invariant across categories. If dimensions, weight, etc. are properties for multiple categories there would be forced consistency across categories. The table for properties should have all of the current property options so that when selected all of the fields are automatically filled. If an inventory item is moved from one category to another and the source category has properties not available in the receiving category an error message should be displayed and the change disallowed. Bob Thomas -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Stock-Categories-Properties-issues-tp4656831p4656892.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: rfthomas <rf...@as...> - 2013-11-15 16:38:32
|
The most common properties should be preloaded in the table for a new installation by default so that support is made easier. For example weight, length, depth, height could all be individual properties available in the table. Bob Thomas -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Stock-Categories-Properties-issues-tp4656831p4656893.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