The records in this table are automatically deleted by the system when all of the quantity fields are zero.

However, whenever an Inventory Adjustment is done, the fields "Loss [tipgc010.loss] or Gain [tipgc010.gain] get a value assigned to them. This prevents the system from deleting these records forever [long after the requirement of the peg has been satisfied].

As far as I can see, the Loss or Gain quantities in this record do not contribute to any planning logic. [Also, the adjustment transaction is available in the hard pegged inventory history, if there is any need for a reference.]

My question is: What is the downside of making the Loss and Gain fields zero for those records where all the other quantity fields are zero and there is no need date on the record?

The reason for this is that the pegging records are the 'starting' point data of the planning engines, and these records with Loss/ Gain quantities are possibly slowing down the planning engine. When the Loss/ Gain quantities are made zero, the next regenerative planning cycle should delete these records systematically and subsequent planning runs should be a bit faster. [We have a total of about 500,000 records in this table.]

Good question - do you have a test system where you could do some testing to see if deleting these records might speed up the planning session? We have about 400,000 records in production. My question would be - does deleting them save minutes or hours of processing time? What about archiving them off and then processing?

As far as I know you do not need the tipgc010 records with just gains and losses - of course I have a print where used going, but it will take a while for me to get the results. We are also on 4c4, so that also might make a difference.

I am guessing the improvement could be substantial from the fact that, some time back, the system was loaded with requirements that caused some of the end-item records to have couple of thousand pegs each. The planning engine did not finish that night, and after a week or so of tracing, we identified the 'culprit items', and set up a special job such that just those items were run through the planning engine with Regenerative option just before the nightly Net Change run, so that the nightly Net Change would skip them and finish successfully. The list of end-items specially processed in this way was about a hundred or so compared to thousands of remaining end-items.

So my conclusion (and hope) is that if we get rid of 'useless' tipgc010 records, the planning engines have that much less to process. But I could be wrong. When the engine took a long time, the records had Requirements - the records I am thinking of deleting have no requirements - so maybe there is no savings.

But you make a good suggestion - I will hunt for a part number that has large number of such (Loss/ Gain) pegs in the test company, run the planning engine as is, then delete the tipgc010 records and run again. The test Company is much smaller, so not good comparison - but worth a try.

WOW - end items with a couple of thousand pegs. That is far worse(or more) than anything we will have. I think the worst I have seen is 40/50. I can see why it runs so long.

Sent a PM. :)

You are correct. Most of our end-items have less than 50 pegs. About a hundred range from 50 to 150. About a dozen going up to 500.

That must have been some special order. Good thing we are done with it. [Hopefully made some money while we were at it :) ]

In any case, I have a light day today so I was experimenting and unfortunately, I was wrong - there is no significant improvement in performance. So, I lay this 'project' to rest.

The reason, I suspect, is that there are no requirements on the pegs I am trying to delete, so the engine does not have any work to do on these, even though it reads them in. I guess I am going to leave them alone.

Did you check your PM's? :)