Time Phase

Epicor 9.05.701

Trying to work out why this part has 2 suggestions when there is no demand?

There are PO suggestions to purchase some of the above material.
Generate suggestions has been run (as was MRP on Friday)
Multi level pegging has also been run
There is no safety stock/min on hand, no fcst and no demand showing

Hi Mark,

I would take a look at the PartWhse table data to see if that exposes any reason for it.

Nancy

Hi Nancy,
Everything in the partwhse table is 0 apart from manual ABC which is a 1.
So i can’t see anything odd in there.

I have seen some odd behavior when running “Generate purchasing suggestions”. In practice here, we only validate purchasing suggestions when they are generated through MRP runs.

I haven’t gotten as far as validating what the differences are, I only know that the suggestions make sense when generated through MRP and not with the stand-alone “Generate purchasing suggestions” form.

How about some of what Rick suggests here?

1 Like

Mark,
Can you scroll over in your Time Phase and so we can see the other columns?
If you don’t see anything in PO Suggestions:

  1. Make sure you have access to all the buyers or run a BAQ against SugPODtl to be sure.
  2. Check for any Change PO’s, if there is an open PO line, PO Sugg can sometimes use that as a change suggestion.
  3. Finally, run PO Sugg again but specify a Log file name so it will create a log for you to review how it calculated these suggestions. Be sure to set the Logging Level to ‘Suggestions’ to get the most detail.
  4. As Nancy suggested, there maybe some data corruption in the PartDtl table, which is basically what TimePhase is displaying, but sometimes there is missing data in a record so it doesn’t show up.
  5. Another thought, is MRP and/or POSugg being ran as Net Change or Regen? Regen should be deleting all suggestions and recreating. If POSugg is often ran as Net Change sometimes it doesn’t actually recalc a part that has suggestions, so I recommend always running the MPRRecalcNeeded process before each POSugg Net Change so nothing is missed. MRP Recalc Needed runs pretty quick.

MRP Recalc Needed - what does that do besides determine if Recalc is needed or not? I’d love to know, because I am battling an issue with constraint non-functionality, and this has popped up as a possible contributor to that.

Documentation is a bit spotty on exactly what this does. Should it be run prior to running regenerative MRP? If we run regenerative MRP exclusively, is there any benefit to running MRP Recalc Needed?

Gil,
The best explanation of the MRP Recalc Needed process can be found in the MRP Technical Reference. You can get access to the PDF Technical Reference Guides via the Application Help. Here is an excerpt:

The MRP Recalculation Needed is a calculation method that lets you reduce the need to run the MRP engine in Regenerative mode. This mode deletes all previously generated MRP information in order to calculate new job, transfer order, and purchase suggestions.

Constantly running the MRP engine in Regenerative mode can strain your network resources, which can cause the MRP process to run slowly.

The MRP Recalculation Needed method provides better results than when you run the MRP engine in Net Change mode. Net Change mode restricts the amount of calculations run by the MRP engine, because it ignores any previously generated information. When you use the MRP Recalculation Needed method, however, demand is recalculated for records that are typically ignored by Net Change mode.

For example, suppose that no activity is placed against a sales order when the MRP engine is first run. If the sales order has a future Due Date that is outside the Cut Off Date range, the sales order is recorded by the MRP engine, but it does not create any suggestions against it. When MRP processing is run in Net Change mode, no activity will be placed against the sales order, because its values were already recorded by the Process MRP program. Thus, the sales order is completely ignored by MRP.

The MRP Recalculation Needed method makes sure that all the sales orders are correctly evaluated by the MRP engine. Because it eliminates the need to do a full regeneration every time MRP is run, this calculation improves efficiency. This is because the MRP Recalucation Needed process does not review a part’s Reschedule In, Reschedule Out, or Planning Time Fence date ranges. If no other changes are made to records linked to this part, then this part is ignored during the Net Change MRP processing run.

Note that you can set up this calculation method to run automatically on a recurring schedule. If you process MRP automatically, you should set up the MRP Recalculation Needed process to run just before the MRP process. This maximizes effeciency during the MRP process.

In the Technical Reference Guide there is additional information, such as the modifiers for the process, Logic/Algorithms and an Example Business Case.
Just search the PDF for ‘MRP Recalculation Needed’ should be around page 108.

MRP has ran overnight and the goalposts have changed…

That looks like a better plan.

1 Like

@Rowley150
BTW - Seeing your results jarred some memories of odd MRP/PO Sugg results I’ve seen before:

  1. Part or Part Site Part Type/Source not set to Purchase. This results in a suggestion but not a PO Suggestion.
  2. Part Site not enabled for MRP or PO Suggestions: Like #1 it results in a suggestion not an actual PO Suggestion. I have also seen situations where unless BOTH MRP & PO Sugg are enabled PO Suggestions are not generated.
  3. Deleting Job Suggestions: Had a client where the Scheduler was deleting Unfirmed Job Suggestions and later when Purchasing reviewed TimePhase it looked like there were suggestions without any demand.

Any idea, to where the table is for this in below image please.

Hi, Your minimum is set to 10000?

yeah , the 10,0000 is just a test. i have been searching all SQL to find this table… no luck yet.

Hi,

I think is one of those screens that collects the information for various tables and shows them on this screen, I don’t think there’s a “Table” for this data it populated on the fly so to speak.

Regards,

John

Hi John,

Exactly what i was thinking.

i wonder if there is a Epicor BAQ laying around some where.

yes, plus any needed -calculated on the fly- values, similar to many Epicor Custom Tracker, so what are you trying to achieve?

The “MRP” and “Generate PO Suggestions” processes aggregate into the PartDtl table, which is the main feed for Time Phase.

The suggestion you’re highlighting is calculated at the end of an MRP or “Generate PO Suggestions” process by subtracting your On-Hand balance from your Min On Hand quantity, and since it’s a purchased part, giving you a purchase suggestion. There is no data table holding that suggestion, it’s calculated when you open Time Phase for that part number.