How to Avoid MRP Requirements in the Past

[ashok_abraham]

Hello,

I'm a BI guy so please excuse my lack of understanding on how this is handled in ECC.  For some time now we've been extracting MRP data into BI for the current day going forward into the planning horizon.  Recently it was noted that requirements generated for subcontracted materials were not being transferred to BI.  The reason for this is while the requirement for the assembly is in the future, due to lead times in the subassemblies the requirements for the subcontracted subassembly are appearing in the past and thus not being transferred to BI. 

Is it normal practice for requirements to be generated in the past?  Is there a way to lump all past due requirements on the current calendar day that way these requirements will be transferred to BI.  Any input you can provide would be much appreciated.

Thanks,

Ashok

[Former Member]

Ashok,

Is it normal practice for requirements to be generated in the past?

This is a business decision.  I have seen both methods (requirements in the past; vs no requirements in the past) successfully used in production systems.

Is there a way to lump all past due requirements on the current calendar day that way these requirements will be transferred to BI. 

Hold on!  You want to change a business process, simply because your data extraction logic is faulty?  Isn't your job to create BI functionality based upon supporting existing business processes?

I suggest that you first consult with the local Planning people who are responsible for this particular business process.  There are many ways to get the proper data into your BI.  Normally, as a BI expert, wouldn't you change the extraction process?  And, yes, there is a way to set up MRP such that it will never create proposals with dates in the past.  Such a change, however, should not be made without serious consideration of all other business processes that will be affected.

Best Regards,

DB49

[ashok_abraham]

DB,

I think you may have misunderstood me.  My question is geared more toward understanding whether it is valid to have requirements in the past.  I have heard different opinions on this and wanted to open it up here to learn more.  Some of my colleagues on the business process side have mentioned that the dates in the past don't mean anything from a business perspective but merely how the system is handling the scenario.  I'd like to understand if that is a factual statement to understand if that is in fact true and then explore options with the planning team.

I wouldn't suggest changing business processes to support data extraction.  I should note that the extractor used is an out of the box SAP extractor, so it's nothing to do with faulty data extraction logic. 

Anything is possible, however customizations do have costs.  In this case extracting past requirements will lead to higher volumes and costly run times for all BI users to accommodate a subset of the data.  I realize this is a tangent but it's an interesting point you bring up since it seems that BI has traditionally been viewed as the "red-headed stepchild."

Thanks,

Ashok       

[Former Member]

Ashok,

...whether it is valid to have requirements in the past.

 I have heard different opinions on this

Yes and yes.  Again, it is a business decision.  SAP supports both.

I will confine my remarks here to Proposed (Planned) dates, where there are many opinions.  There are also a number of opinions as to how the start date of executables should be managed as well, but that is a topic for another discussion. 

Many companies make commitments to their customers for finish dates (delivery dates).  Then, the planners wish to see all planned supply exactly matched with all demand.  They review the entire integrated supply chain to see where it is infeasible (such as when the plan says you have to receive your subcontracted materials into stock 'last month').  The assumption for these planners is that the entire supply chain can be moved into the future 'en bloc' to make it feasible.  Other companies make the finish date commitments, and then wish to see all start dates 'forced' to 'no earlier than today'.  Infeasible plans in this case are characterized by scattering supply/demand mismatches throughout various places in the supply chain.  Each mismatch is addressed individually - some at RM, some at assembly, some at FGs, after which the entire plan must be re-integrated before it can be said to be feasible.  There are also hybrids between these two business practices.

When I first started in this business in the '80's, traditional MRP programs only did an exact match between supply and demand, and produced start dates in the past, along with appropriate exception messages.  SAP ERP, and most mature Planning systems, now permit multiple methods of tweaking the relationship between supply and demand. More modern systems (such as APO) support even more methods, such as 'bottom up scheduling', in which the plan starts from the earliest feasible start date (usually 'today') and exactly matches supply and demand all the way UP the supply chain, to determine the earliest feasible finish date, for the complete supply chain.  These advanced systems are also sometimes used to automatically determine initial customer commitment dates during order entry.

All of these methods are valid! 

R/3 & ERP by default disallows MRP from creating Basic start dates in the past, so someone in your organization deliberately made that setting to allow, presumably for some business reason.  I would think that someone in the organization should find out what that reason was, before changing it.  Or, commit yourselves to testing the crap out of it before you go 'live'.

Best Regards,

DB49