April 6, 2012 at 9:15 am
jewel.sacred (4/6/2012)
capn.hector (4/6/2012)
jewel.sacred (4/6/2012)
capn.hector (4/6/2012)
to lynn's point. if 6 months after you start using this you have to change the pieces per pack you have to make sure to update every item using that new measure. if you have 20 items and only change 18 you have errors in your database. if you have 20 items that are changing in my and lynn's setup but not all 12 peices to a pack are changing, you add a new unit of measure for the 20 items that are changing (or if you all ready have an x pieces per pack unit that they would fit you change the unit id)I agree with that. But that change is allowed only once through the application. Any change in that is logged and the application is configured to stop running if there is a change made manually in the table. And I also know that this hurdle can be overcome by a smartie, but I guess you cannot cope with all the situations.
your different peices per pack is like miles of distance per hour and kilometers of distance per hour. they both measure the same thing (distance over time) but are different units of measure. just like your pieces per pack. 12 pieces per pack and 20 pieces per pack both measure the same thing (Pieces per pack) but are different.
This is why we keep them per item basis 🙂 We cannot afford so many units of measure.
Now you are confusing the issue. If Item1 has 12 pieces per pack and Item2 has 20 pieces per pack and you keep the inventory by piece and you can sell these items by Pack as well as indivivually, how do you keep track of the quantity per pacK? And it each pack comes in a box of 20 packs (let's say fo the sack or argument both item1 and Item2 have the same number of packs per box) and you could sell a box of these items, how do you track that?
April 6, 2012 at 9:28 am
so its legacy that you are stuck doing it this way. its this way now so it has to be this way when we move to the new system?in that case i recind all remarks on normalizing since some mountians are easier to go around.
Its not legacy. But sometimes you have no other choice. Sometimes, you are bound to do things with the current architecture. In some environments, people start raising questions about your ability to do the work and such debate could get spicy. But after all the talk about the good design and efficient handling of the situation, you are let know that the change is not possible at the moment, so please give a solution rather than asking for a change. And you can imagine, how those people would be looking at you then 🙁
April 6, 2012 at 9:40 am
jewel.sacred (4/6/2012)
so its legacy that you are stuck doing it this way. its this way now so it has to be this way when we move to the new system?in that case i recind all remarks on normalizing since some mountians are easier to go around.
Its not legacy. But sometimes you have no other choice. Sometimes, you are bound to do things with the current architecture. In some environments, people start raising questions about your ability to do the work and such debate could get spicy. But after all the talk about the good design and efficient handling of the situation, you are let know that the change is not possible at the moment, so please give a solution rather than asking for a change. And you can imagine, how those people would be looking at you then 🙁
There is always a choice. The question is if you can't do it right now, when are going to get the time to do it right later? Past experience tells me you don't usually get a second chance to it right as there are always other things that have to be done.
Years ago, I built a process for handling orders from remote offices for a specific vendor. It was a sledgehammer, it got the job done but it wasn't scalable. A year later we needed to add another vendor to the process for another contract. Thankfully, my boss supported me in doing a complete rework of the process. It took me 6 weeks and my boss took a lot of heat during that time. When I was done we had a better process and it was developed to allow us to easily add additional vendors to the process in the future without major changes.
April 6, 2012 at 9:52 am
Lynn Pettis (4/6/2012)
jewel.sacred (4/6/2012)
This is why we keep them per item basis 🙂 We cannot afford so many units of measure.Now you are confusing the issue. If Item1 has 12 pieces per pack and Item2 has 20 pieces per pack and you keep the inventory by piece and you can sell these items by Pack as well as indivivually, how do you keep track of the quantity per pacK? And it each pack comes in a box of 20 packs (let's say fo the sack or argument both item1 and Item2 have the same number of packs per box) and you could sell a box of these items, how do you track that?
Sorry, may be I did not understand it properly. I have put the output in my question for ml,Litres,hectolitres calculation. Can you please post an example on that basis.
Or for a calculation on piece, pack and carton, here is how it would be done
We have current stock for Item1
ConversionFactor UOMType QuantityInHand
1 Piece 20
12 Pack 10
60 Carton 5The user sold
30 pieces, 5 Packs, 1 Carton
The remaining Stock would be
20-20+( 2 pieces remaining from the pack) , 11 Packs(10 pieces sold and remaining 2 are moved to pieces UOM) 4 Carton (1 Carton is sold)
At the moment, we are not dealing with fractions, so the remainder i.e. 2 pieces from packs are moved to the pieces UOM.
April 6, 2012 at 10:07 am
Sorry friends, In our part of world, its getting a bit late. Moreover, I may not be able to reply this thread for good time. So please accept my apology for any inconvenience and I hope when I will be live again, you would support me in the same manner. Thanks.
April 10, 2012 at 7:54 am
CELKO (4/9/2012)
Fields are not anything like columns. Again, another fundamental error!
Ya know what Joe? You are 100% correct. Your posts may sound arrogant but the plain fact is that if proper design, documentation and architectural standards were adhered to 80% of the problems people deal with day after day would not even occur. But for this to happen it would require that A) competent people only be allowed in the same room with a database server, and B) management insisting that proper software engineering practices and documentation are adhered to.
But alas... such is rarely the case.
The probability of survival is inversely proportional to the angle of arrival.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply