Menu
▾
▴
web-erp-developers
|
From: Jesse P. <jes...@st...> - 2004-03-25 16:28:17
|
> > Like the StockItemMoves table I sent you in those diffs. It=20 > would not > > hold a record for the inital move (in stockmoves and breaks ref. > > integrity), and would hole the item#,orig_stkmove, and new_stkmove . >=20 > This only contains moves of controlled items right with their=20 > reference and > stockmove id - why would it not show the qty of the batch=20 > movement - where > is this recorded? I guess the StockMoves table shows the=20 > total movement of > all serialised items per your logic. FromStkMoveNo and=20 > ToStkMoveNo - the > stock movements of a serialised item will not be in a range .... will > they??? > There's a one StockMoves.StockID to many=20 > StockItemMoves.StockID (I think > some ref to controlled items would be preferable in the=20 > naming of the table) > and the StockMoves.NewQOH would contain the sum of all=20 > serialised items in > stock - not just one serial number item .... would it not?? Yes, ItemMoves would only shows moves between StockMoves. And yes, Qty = should not be needed there as it should be correct in StockMoves. From & = To are not ranges... probably OrigStkMove and NewStkMove are better = names. Yes, 1 StockMove to many StockItemMoves - and StockMoves.NewQOH works as = it does today, which is as you mentioned.=20 Remember, though, Controlled & Serialised would be StockMaster fields. = Serialised implies controlled, but Controlled does not imply Serialised. = Controlled just forces someone to give some Ref number to each StockMove = of a StockMaster type. Possibly we call the tables SerialisedStock & SerialisedStockMoves ?? > OK I get it - that seems fine, just no qty control - probably=20 > ok - I prefer > my method ;-) I will keep this in mind and find another way to provide that = functionality. > > > - Don't understand you templatey idea? > > > > > Do you mean the above, my plan on how to allow easy extension of > > stockitem details, >=20 > yes that bit. I see the StockModules tables - I guess it=20 > would reduce a bit > of input but would require additional sql to get the=20 > necessary info. I don't > see it as necessary? The stock category could contain any other data > relevant to the category. It does require more sql queries to get all the data and maybe a little = confusing. The thought is, that I actually need to store, say 5 other = fields fo data for *each* item inventoried, and it will change between = lots of items. So, StockCat won't do for that... . For example, for an = IP Phone, I may call the MAC address my serial number and put the = devices' admin user&pass, assigned phone number, and other Phone = specific data in a separate table. The Module would act as the 'glue' = between the SerialisedItems.SerialNo and IPPhones.MAC . The majority of = items would not need that, though. For example, the GenericStockItem = module would not have an extra table, but the code would allow it to = work just like the other one. Adding a new business specific Stock type now becomes a simple task of = creating a StockModule and a Table to hold the data... the StockModule = would also help control the display, making it easier to present data in = a way that is more specific to a product than general enough to cover = all of them. > > > > > - how do we display all the serial numbers of items on=20 > hand at any one > time? > > > > > > > > I realized this a while ago as well. All Items will have=20 > their current > > StockMove associated with them in their table - upkeep=20 > necessary during > > adds/moves/etc. I figure to select on-hand items the base=20 > criteria will > > be based on selecting a set of StockMoves with appropriate SysTypes, > > then selecting Items still tagged with those StockMoves. Do=20 > you know the > > SysTypes necessary without me digging around to find them? > I don't understand this. The SysTypes table refers to the various > transaction types - not all of which create stock movements.=20 It looks to me that finding all SerialisedStock-on-Hand can be done by: = Get all StockMoves where Type=3D25, then get all SerialisedItems with = those StockMoveNo's. Limits could easily be put to select all for just a = Location, that a Customer have, etc... and just require determining = which Types in StockMoves reflect the Stock you want. Make sense? The = last part is where i was wondering about which ones should be checked. > Individual > stockmoves contain the total balance of all stock in the=20 > location in the > newqoh field if I understand your logic so the quantity in=20 > the batch is > unknown. or do you mean to re-calcuate the quantity remaining=20 > on hand in the > ControlledStockMoves record and just pick up the last The Qty for a batch of SerialisedItems would simply be the Qty in the = StockMove they refer to. We may need to talk about exactly how to = account for StockMove Qty's, but it looks like the same as above, where = certain Types can be referenced to get the total(s) we are looking for. > Perhaps summing the qty ins and outs in the=20 > ControlledStockMoves - this > could be a substantial exercise with your data volumes? Yes, it could. I did not intend on needing to do this. =20 > Not using the LocStock table seems nice but what about items=20 > that need to > mature before they are sold - so they need to be held or products - > serialised items that must be sold before a given date as per=20 > Danie's note. > I think if we are doing it, it would be a shame to limit the scope to > exclude this. > Are we looking at another table to hold serialised quantites=20 > on hand and > these variables. The table being maintained like LocStock but=20 > at the serial > number level - the total of serialised items always agreeing=20 > to the LocStock > table QOH. There seems a disturbing amount of double up with LocStock > though. Agreed, I wouldn't want to double up like that... I read Danie's = requests - I've never really thought about having to do that, so I = will... Right now, I'm thinking a StockMaster field for SellAfterDays = and SellByDays, and then determining Stock status (as above, by Type) = should just be an exercise of totalling StockMoves and examining date = differences. What do you think? > > > > > - how do we display on invoices the serial numbers of=20 > items sold - if we > > >wanted to ? > > > > > > > > This can be an option specified in the StockMaster table, in > > StockModules, or even at the time of printing/viewing the=20 > invoice, and a > > combination of those...I also forsee situations like I have=20 > where I want > > to invoice someone for 50,000 cards on a regular invoice (obviously > > without serialised line items) and have the option to=20 > provide/retrieve > > the invoice detail in some other format, say a csv list of serial > > numbers and possibly other data that can be sent to a=20 > customer for their > > own inventory requirements. > > >=20 > I am probably wasting your time with my inability to grasp=20 > the concepts. > Sorry I just can't get the logic of what you are proposing, I=20 > fear it seems > to be some way short of acheiving what you hope for. I think=20 > I should just > leave you to it - give it a go - if it works ... and I do=20 > hope so ... I'll > include it! You apologize too much. :) I'm going to get to work on things... if you = come up with any other concerns of how something might work, bring it up = so I can think about it as well. I may also end up differing from the = plan a little once I get to coding since that happens sometimes. I'll = mention it if I do, though. |
|
From: Jesse P. <jes...@st...> - 2004-03-25 22:00:59
|
comments down below.... > > > > > - how do we display all the serial numbers of items on > > > hand at any one > > > time? > > > > > > > > > > > > > > I realized this a while ago as well. All Items will have > > > their current > > > > StockMove associated with them in their table - upkeep > > > necessary during > > > > adds/moves/etc. I figure to select on-hand items the base > > > criteria will > > > > be based on selecting a set of StockMoves with=20 > appropriate SysTypes, > > > > then selecting Items still tagged with those StockMoves. Do > > > you know the > > > > SysTypes necessary without me digging around to find them? > > > I don't understand this. The SysTypes table refers to the various > > > transaction types - not all of which create stock movements. > > It looks to me that finding all SerialisedStock-on-Hand can=20 > > be done by: > > Get all StockMoves where Type=3D25, then get all=20 > > SerialisedItems with those > > StockMoveNo's. Limits could easily be put to select all for=20 > > just a Location, > > that a Customer have, etc... and just require determining=20 > > which Types in > > StockMoves reflect the Stock you want. Make sense? The last=20 > > part is where i > > was wondering about which ones should be checked. >=20 > But the goods received stock movement has the total qty=20 > received - not the > qty of the batch received? Even when linked to=20 > SerialisedStockMoves this > table has no qty in it either? > I just don't see how this system will track how many of each=20 > batch you have > left. I'm assuming a Batch will be a set of like StockMaster types and using = StockMoves.Bundle is an adequate tracking no. for each batch: Let's see... GoodsReceived would create a StockMove /w the Qty received = - if it is controlled, the Receiver would be required to enter a = BundleId (that would go in StockMoves.Bundle). As more goods were = received, we could allow it to be batched together with the previous one = or given/require a new Bundle=20 So then, to query a Bundle, you'd pick all StockMoves On-Hand = (type=3D25.. more?), Sum their Qty for a total number of items, then sum = the number of SerialisedItem moves where those StockMove(s) are set as = the OrigStockMoveNo . That could be a little slow, but I think it will = end up working out ok. For consistency (in that quantities always come = from StockMoves), it may be better to retrieve the distinct = NewStockMoves for the OldStockMoves and pull their Qty out of = StockMoves... that would give us a Total and the number Removed from it, = which obiously is enough to show us the number available. Tangent on BundleIds: do you think these should be auto-generated? I was = thinking treat Bundle as it if were a hex number and just keep adding = 1... so they'd go 00000001,...,00000009,0000000A,..0000000F,00000010 - = or a 'base26'(A-Z) or 'base36'(0-9,A-Z) scheme to accomodate even more = unique Bundle #s (I have some functions that count/convert things like = that already)... You may want/need to explain to me how batches *need* to work so I can = take a fresh look at that... > > > > > Individual > > > stockmoves contain the total balance of all stock in the > > > location in the > > > newqoh field if I understand your logic so the quantity in > > > the batch is > > > unknown. or do you mean to re-calcuate the quantity remaining > > > on hand in the > > > ControlledStockMoves record and just pick up the last > > The Qty for a batch of SerialisedItems would simply be the=20 > Qty in the > StockMove they refer to. We may need to talk about exactly=20 > how to account > for StockMove Qty's, but it looks like the same as above,=20 > where certain > Types can be referenced to get the total(s) we are looking for. > > > > > Perhaps summing the qty ins and outs in the > > > ControlledStockMoves - this > > > could be a substantial exercise with your data volumes? > > Yes, it could. I did not intend on needing to do this. > > > > > Not using the LocStock table seems nice but what about items > > > that need to > > > mature before they are sold - so they need to be held or=20 > products - > > > serialised items that must be sold before a given date as per > > > Danie's note. > > > I think if we are doing it, it would be a shame to limit=20 > the scope to > > > exclude this. > > > Are we looking at another table to hold serialised quantites > > > on hand and > > > these variables. The table being maintained like LocStock but > > > at the serial > > > number level - the total of serialised items always agreeing > > > to the LocStock > > > table QOH. There seems a disturbing amount of double up=20 > with LocStock > > > though. > > Agreed, I wouldn't want to double up like that... I read Danie's > > requests - I've never really thought about having to do that,=20 > > so I will... > > Right now, I'm thinking a StockMaster field for SellAfterDays and > > SellByDays, and then determining Stock status (as above, by=20 > > Type) should > > just be an exercise of totalling StockMoves and examining=20 > > date differences. > What do you think? >=20 > Clunky and processing intensive .... you asked what I thought :-) Ok :)... possibly so. If I do it now, I'll probably do it that way = unless I can work in another way. =20 > I'm looking forward to seeing the code - since this is a=20 > substantial project > I will confine my activities over the next 2 weeks to the EDI=20 > scripts and > suggest Danie and Dick do similarly - to give you a free run without > worrying about other changes in the scripts. That would be very nice. I'll keep my eye out in case changes are = needed, though, so that you guys aren't completely strapped by me = working on this. My hope is to have most of this done (assuming I don't = hit any big snags) within a week or so - that's probably a little = over-ambitious, though. The first thing I may end up sending back is = reworkings of some sections of code to allow us to class out the = StockItems, at least as a data structure... |
|
From: Phil D. <ph...@du...> - 2004-03-25 22:25:19
|
Typically a bundle of steel has a tracking bundle number as given to it by the vendor. Quality information would be available and certification by bundle reference. A manufacturer would want to know which steel went into its product so if there were some particularly rusty products produced or the carbon deposits causing structural flaws in the steel then these could be tracked to the bundle that they came from. Similarly, with cloth - a manufacturer receiving returned garments would want to know which roll of cloth this came from - so that the cloth manufacturer could be held accountable. Or when cutting the cloth to make garments a flaw is revealed - the cloth mill will need to know the roll reference they gave the roll when it was made to have a look at its quality processes. Food is the same - A batch of cheese with razor blades in it would need to be withdrawn and the manufacturer would need to issue a recall off the shelves immediately for batch xyz to all retail outlets - and need to be able to trace where this batch was sold to. Phil ----- Original Message ----- From: "Jesse Peterson" <jes...@st...> To: <web...@li...> Sent: Friday, March 26, 2004 10:00 AM Subject: RE: [Web-erp-developers] Serialised stock - how to code this up > comments down below.... > > > > > > > - how do we display all the serial numbers of items on > > > > hand at any one > > > > time? > > > > > > > > > > > > > > > > > I realized this a while ago as well. All Items will have > > > > their current > > > > > StockMove associated with them in their table - upkeep > > > > necessary during > > > > > adds/moves/etc. I figure to select on-hand items the base > > > > criteria will > > > > > be based on selecting a set of StockMoves with > > appropriate SysTypes, > > > > > then selecting Items still tagged with those StockMoves. Do > > > > you know the > > > > > SysTypes necessary without me digging around to find them? > > > > I don't understand this. The SysTypes table refers to the various > > > > transaction types - not all of which create stock movements. > > > It looks to me that finding all SerialisedStock-on-Hand can > > > be done by: > > > Get all StockMoves where Type=25, then get all > > > SerialisedItems with those > > > StockMoveNo's. Limits could easily be put to select all for > > > just a Location, > > > that a Customer have, etc... and just require determining > > > which Types in > > > StockMoves reflect the Stock you want. Make sense? The last > > > part is where i > > > was wondering about which ones should be checked. > > > > But the goods received stock movement has the total qty > > received - not the > > qty of the batch received? Even when linked to > > SerialisedStockMoves this > > table has no qty in it either? > > I just don't see how this system will track how many of each > > batch you have > > left. > > I'm assuming a Batch will be a set of like StockMaster types and using StockMoves.Bundle is an adequate tracking no. for each batch: > Let's see... GoodsReceived would create a StockMove /w the Qty received - if it is controlled, the Receiver would be required to enter a BundleId (that would go in StockMoves.Bundle). As more goods were received, we could allow it to be batched together with the previous one or given/require a new Bundle > So then, to query a Bundle, you'd pick all StockMoves On-Hand (type=25.. more?), Sum their Qty for a total number of items, then sum the number of SerialisedItem moves where those StockMove(s) are set as the OrigStockMoveNo . That could be a little slow, but I think it will end up working out ok. For consistency (in that quantities always come from StockMoves), it may be better to retrieve the distinct NewStockMoves for the OldStockMoves and pull their Qty out of StockMoves... that would give us a Total and the number Removed from it, which obiously is enough to show us the number available. > > Tangent on BundleIds: do you think these should be auto-generated? I was thinking treat Bundle as it if were a hex number and just keep adding 1... so they'd go 00000001,...,00000009,0000000A,..0000000F,00000010 - or a 'base26'(A-Z) or 'base36'(0-9,A-Z) scheme to accomodate even more unique Bundle #s (I have some functions that count/convert things like that already)... > > You may want/need to explain to me how batches *need* to work so I can take a fresh look at that... > > > > > > > > Individual > > > > stockmoves contain the total balance of all stock in the > > > > location in the > > > > newqoh field if I understand your logic so the quantity in > > > > the batch is > > > > unknown. or do you mean to re-calcuate the quantity remaining > > > > on hand in the > > > > ControlledStockMoves record and just pick up the last > > > The Qty for a batch of SerialisedItems would simply be the > > Qty in the > > StockMove they refer to. We may need to talk about exactly > > how to account > > for StockMove Qty's, but it looks like the same as above, > > where certain > > Types can be referenced to get the total(s) we are looking for. > > > > > > > Perhaps summing the qty ins and outs in the > > > > ControlledStockMoves - this > > > > could be a substantial exercise with your data volumes? > > > Yes, it could. I did not intend on needing to do this. > > > > > > > Not using the LocStock table seems nice but what about items > > > > that need to > > > > mature before they are sold - so they need to be held or > > products - > > > > serialised items that must be sold before a given date as per > > > > Danie's note. > > > > I think if we are doing it, it would be a shame to limit > > the scope to > > > > exclude this. > > > > Are we looking at another table to hold serialised quantites > > > > on hand and > > > > these variables. The table being maintained like LocStock but > > > > at the serial > > > > number level - the total of serialised items always agreeing > > > > to the LocStock > > > > table QOH. There seems a disturbing amount of double up > > with LocStock > > > > though. > > > Agreed, I wouldn't want to double up like that... I read Danie's > > > requests - I've never really thought about having to do that, > > > so I will... > > > Right now, I'm thinking a StockMaster field for SellAfterDays and > > > SellByDays, and then determining Stock status (as above, by > > > Type) should > > > just be an exercise of totalling StockMoves and examining > > > date differences. > > What do you think? > > > > Clunky and processing intensive .... you asked what I thought :-) > > Ok :)... possibly so. If I do it now, I'll probably do it that way unless I can work in another way. > > > > I'm looking forward to seeing the code - since this is a > > substantial project > > I will confine my activities over the next 2 weeks to the EDI > > scripts and > > suggest Danie and Dick do similarly - to give you a free run without > > worrying about other changes in the scripts. > > That would be very nice. I'll keep my eye out in case changes are needed, though, so that you guys aren't completely strapped by me working on this. My hope is to have most of this done (assuming I don't hit any big snags) within a week or so - that's probably a little over-ambitious, though. The first thing I may end up sending back is reworkings of some sections of code to allow us to class out the StockItems, at least as a data structure... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id70&alloc_id638&opÌk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Jesse P. <jes...@st...> - 2004-03-25 22:53:08
|
Ok. Sounds like what I have here will work, but that certain views will = be required to provide links to some easy way to track items back... jesse > -----Original Message----- > From: Phil Daintree [mailto:ph...@du...] > Sent: Thursday, March 25, 2004 17:32 > To: web...@li... > Subject: Re: [Web-erp-developers] Serialised stock - how to=20 > code this up >=20 >=20 > Typically a bundle of steel has a tracking bundle number as=20 > given to it by > the vendor. Quality information would be available and=20 > certification by > bundle reference. A manufacturer would want to know which=20 > steel went into > its product so if there were some particularly rusty products=20 > produced or > the carbon deposits causing structural flaws in the steel=20 > then these could > be tracked to the bundle that they came from. >=20 > Similarly, with cloth - a manufacturer receiving returned=20 > garments would > want to know which roll of cloth this came from - so that the cloth > manufacturer could be held accountable. Or when cutting the=20 > cloth to make > garments a flaw is revealed - the cloth mill will need to=20 > know the roll > reference they gave the roll when it was made to have a look=20 > at its quality > processes. >=20 > Food is the same - A batch of cheese with razor blades in it=20 > would need to > be withdrawn and the manufacturer would need to issue a recall off the > shelves immediately for batch xyz to all retail outlets - and=20 > need to be > able to trace where this batch was sold to. >=20 > Phil >=20 > ----- Original Message ----- > From: "Jesse Peterson" <jes...@st...> > To: <web...@li...> > Sent: Friday, March 26, 2004 10:00 AM > Subject: RE: [Web-erp-developers] Serialised stock - how to=20 > code this up >=20 >=20 > > comments down below.... > > > > > > > > > - how do we display all the serial numbers of items on > > > > > hand at any one > > > > > time? > > > > > > > > > > > > > > > > > > > > I realized this a while ago as well. All Items will have > > > > > their current > > > > > > StockMove associated with them in their table - upkeep > > > > > necessary during > > > > > > adds/moves/etc. I figure to select on-hand items the base > > > > > criteria will > > > > > > be based on selecting a set of StockMoves with > > > appropriate SysTypes, > > > > > > then selecting Items still tagged with those StockMoves. Do > > > > > you know the > > > > > > SysTypes necessary without me digging around to find them? > > > > > I don't understand this. The SysTypes table refers to=20 > the various > > > > > transaction types - not all of which create stock movements. > > > > It looks to me that finding all SerialisedStock-on-Hand can > > > > be done by: > > > > Get all StockMoves where Type=3D25, then get all > > > > SerialisedItems with those > > > > StockMoveNo's. Limits could easily be put to select all for > > > > just a Location, > > > > that a Customer have, etc... and just require determining > > > > which Types in > > > > StockMoves reflect the Stock you want. Make sense? The last > > > > part is where i > > > > was wondering about which ones should be checked. > > > > > > But the goods received stock movement has the total qty > > > received - not the > > > qty of the batch received? Even when linked to > > > SerialisedStockMoves this > > > table has no qty in it either? > > > I just don't see how this system will track how many of each > > > batch you have > > > left. > > > > I'm assuming a Batch will be a set of like StockMaster=20 > types and using > StockMoves.Bundle is an adequate tracking no. for each batch: > > Let's see... GoodsReceived would create a StockMove /w the=20 > Qty received - > if it is controlled, the Receiver would be required to enter=20 > a BundleId > (that would go in StockMoves.Bundle). As more goods were=20 > received, we could > allow it to be batched together with the previous one or=20 > given/require a new > Bundle > > So then, to query a Bundle, you'd pick all StockMoves=20 > On-Hand (type=3D25.. > more?), Sum their Qty for a total number of items, then sum=20 > the number of > SerialisedItem moves where those StockMove(s) are set as the=20 > OrigStockMoveNo > . That could be a little slow, but I think it will end up=20 > working out ok. > For consistency (in that quantities always come from=20 > StockMoves), it may be > better to retrieve the distinct NewStockMoves for the=20 > OldStockMoves and pull > their Qty out of StockMoves... that would give us a Total and=20 > the number > Removed from it, which obiously is enough to show us the=20 > number available. > > > > Tangent on BundleIds: do you think these should be=20 > auto-generated? I was > thinking treat Bundle as it if were a hex number and just=20 > keep adding 1... > so they'd go 00000001,...,00000009,0000000A,..0000000F,00000010 - or a > 'base26'(A-Z) or 'base36'(0-9,A-Z) scheme to accomodate even=20 > more unique > Bundle #s (I have some functions that count/convert things like that > already)... > > > > You may want/need to explain to me how batches *need* to=20 > work so I can > take a fresh look at that... > > > > > > > > > > > Individual > > > > > stockmoves contain the total balance of all stock in the > > > > > location in the > > > > > newqoh field if I understand your logic so the quantity in > > > > > the batch is > > > > > unknown. or do you mean to re-calcuate the quantity remaining > > > > > on hand in the > > > > > ControlledStockMoves record and just pick up the last > > > > The Qty for a batch of SerialisedItems would simply be the > > > Qty in the > > > StockMove they refer to. We may need to talk about exactly > > > how to account > > > for StockMove Qty's, but it looks like the same as above, > > > where certain > > > Types can be referenced to get the total(s) we are looking for. > > > > > > > > > Perhaps summing the qty ins and outs in the > > > > > ControlledStockMoves - this > > > > > could be a substantial exercise with your data volumes? > > > > Yes, it could. I did not intend on needing to do this. > > > > > > > > > Not using the LocStock table seems nice but what about items > > > > > that need to > > > > > mature before they are sold - so they need to be held or > > > products - > > > > > serialised items that must be sold before a given date as per > > > > > Danie's note. > > > > > I think if we are doing it, it would be a shame to limit > > > the scope to > > > > > exclude this. > > > > > Are we looking at another table to hold serialised quantites > > > > > on hand and > > > > > these variables. The table being maintained like LocStock but > > > > > at the serial > > > > > number level - the total of serialised items always agreeing > > > > > to the LocStock > > > > > table QOH. There seems a disturbing amount of double up > > > with LocStock > > > > > though. > > > > Agreed, I wouldn't want to double up like that... I read Danie's > > > > requests - I've never really thought about having to do that, > > > > so I will... > > > > Right now, I'm thinking a StockMaster field for=20 > SellAfterDays and > > > > SellByDays, and then determining Stock status (as above, by > > > > Type) should > > > > just be an exercise of totalling StockMoves and examining > > > > date differences. > > > What do you think? > > > > > > Clunky and processing intensive .... you asked what I thought :-) > > > > Ok :)... possibly so. If I do it now, I'll probably do it=20 > that way unless > I can work in another way. > > > > > > > I'm looking forward to seeing the code - since this is a > > > substantial project > > > I will confine my activities over the next 2 weeks to the EDI > > > scripts and > > > suggest Danie and Dick do similarly - to give you a free=20 > run without > > > worrying about other changes in the scripts. > > > > That would be very nice. I'll keep my eye out in case=20 > changes are needed, > though, so that you guys aren't completely strapped by me=20 > working on this. > My hope is to have most of this done (assuming I don't hit=20 > any big snags) > within a week or so - that's probably a little=20 > over-ambitious, though. The > first thing I may end up sending back is reworkings of some=20 > sections of code > to allow us to class out the StockItems, at least as a data=20 > structure... > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President=20 > and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >=20 |
|
From: Daintree <p.d...@pa...> - 2004-03-25 20:17:58
|
> > > > - how do we display all the serial numbers of items on > > hand at any one > > time? > > > > > > > > > > > I realized this a while ago as well. All Items will have > > their current > > > StockMove associated with them in their table - upkeep > > necessary during > > > adds/moves/etc. I figure to select on-hand items the base > > criteria will > > > be based on selecting a set of StockMoves with appropriate SysTypes, > > > then selecting Items still tagged with those StockMoves. Do > > you know the > > > SysTypes necessary without me digging around to find them? > > I don't understand this. The SysTypes table refers to the various > > transaction types - not all of which create stock movements. > It looks to me that finding all SerialisedStock-on-Hand can be done by: Get all StockMoves where Type=25, then get all SerialisedItems with those StockMoveNo's. Limits could easily be put to select all for just a Location, that a Customer have, etc... and just require determining which Types in StockMoves reflect the Stock you want. Make sense? The last part is where i was wondering about which ones should be checked. But the goods received stock movement has the total qty received - not the qty of the batch received? Even when linked to SerialisedStockMoves this table has no qty in it either? I just don't see how this system will track how many of each batch you have left. > > > Individual > > stockmoves contain the total balance of all stock in the > > location in the > > newqoh field if I understand your logic so the quantity in > > the batch is > > unknown. or do you mean to re-calcuate the quantity remaining > > on hand in the > > ControlledStockMoves record and just pick up the last > The Qty for a batch of SerialisedItems would simply be the Qty in the StockMove they refer to. We may need to talk about exactly how to account for StockMove Qty's, but it looks like the same as above, where certain Types can be referenced to get the total(s) we are looking for. > > > Perhaps summing the qty ins and outs in the > > ControlledStockMoves - this > > could be a substantial exercise with your data volumes? > Yes, it could. I did not intend on needing to do this. > > > Not using the LocStock table seems nice but what about items > > that need to > > mature before they are sold - so they need to be held or products - > > serialised items that must be sold before a given date as per > > Danie's note. > > I think if we are doing it, it would be a shame to limit the scope to > > exclude this. > > Are we looking at another table to hold serialised quantites > > on hand and > > these variables. The table being maintained like LocStock but > > at the serial > > number level - the total of serialised items always agreeing > > to the LocStock > > table QOH. There seems a disturbing amount of double up with LocStock > > though. > Agreed, I wouldn't want to double up like that... I read Danie's requests - I've never really thought about having to do that, so I will... Right now, I'm thinking a StockMaster field for SellAfterDays and SellByDays, and then determining Stock status (as above, by Type) should just be an exercise of totalling StockMoves and examining date differences. What do you think? Clunky and processing intensive .... you asked what I thought :-) I'm looking forward to seeing the code - since this is a substantial project I will confine my activities over the next 2 weeks to the EDI scripts and suggest Danie and Dick do similarly - to give you a free run without worrying about other changes in the scripts. Phil |
×
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