MPS/DRP/MRP messages 'B' type and G type

[Geo Man]

MPS/DRP/MRP messages \'B\' type and G type

Would like to know about MPS messages, under what circumstances PeopleSoft MRP generates a “B” versus a “G” message.

Code Description
B -Order & Expedite
G Increase Order Quantity to

What causes the system to recommend increasing the quantity on a PO as opposed to the system recommending to create a new PO and expediting it.

For example.

We have an open PO for 100.
We have demand for 120.

The system can either recommend to order/expedite 20 or increase the PO to 120. How does the system make this decision?

Thanks in advance

George Manuval
EnterpriseOne 810/Oracle9iLinux/Windows

 

[ryan thomas]

Re: MPS/DRP/MRP messages \'B\' type and G type

hi george,

i tried to respond to your private message, but you have set up your profile to not accept them so i was unable to reply.

anyways, from the info you have given me there are a few different scenarios as to why the system would create a B message or a G message.

do you have any order maximums set up for the item in question in the branch/plant set up (quantities row exit from the item branch/plant)?

is the existing PO in question frozen or within the freeze fence?

is the increase in net demand (quantity of 20) on the same date or a different date as the current promised delivery date on the PO?

 

[MikeP1969]

Re: MPS/DRP/MRP messages \'B\' type and G type

We are also experiencing problems with the G message asking to increase orders instead of the B Message. Is there anything written on this subject? We seem to be getting the G Messages fairly randomly and I cannot find any good documentation on why or how this works within MRP (or how to stop the G Messages altogether - which is what I want).

 

[bruce_meyer]

Re: MPS/DRP/MRP messages \'B\' type and G type

It is very simple to eliminate the G messages (also the L decrease message). You take them out of the UDC table 34/MT, and the system does not plan the increase or decrease to existing orders anymore.

This is something that you could easily have found in the material planning manual.

 

[Kevin Reker]

Re: MPS/DRP/MRP messages \'B\' type and G type

We are also having issues with G messages and I would like to understand how MRP know when to issue these vs an order message. I see Bruce noted removing the UDC from table 34/MT but in discussions with our implementation consultants they highly recommended against it because MRP will assume the increase occured even though no message was generated. Can someone discuss this in further detail? Thanks!

 

[bruce_meyer]

Re: MPS/DRP/MRP messages \'B\' type and G type

I looked in the 8.12 documentation and XE but couldn't find the reference that JDE had sent out at one time. The G and L messages were added functionality that began in the earlier releases of A7.3. I think it may have been a white paper, but I haven't had time to hunt it down again. Basically the A messages along with the G and L messages are user controllable, that is, if they exist in the table, the system can try to apply the logic to them. The document that was given to me outlined how to eliminate one or any of the A messages, and also information on being able to eliminat the G and L messages. I have used this in multiple implementations from A73 to 8.12 and it has always worked correctly when the G and L message types are removed from the table.

The biggest complaint with the G and L messages is that depending on your settings for item lead-times, freeze fences, planning fences, order policy codes, and hold codes, the system would suggest that an open purchase or manufacturing order be increased or decreased and would continue with the rest of the planning accordingly.

We often had G messages on purchase orders where we couldn't the quantity after some point in the order cycle. The system would suggest changing the order quantity rather that creating a new order message. It was difficult at best to find time to review the G messages and determine on an item or order by order basis if we could change the open orders. Purchasing felt it was easier to to create a new order (most likely it would be a new B message) than try to increase an existing order. They could have accomplished the same goal by freezing the orders, but this would also have affected any defer or expedite messages.

I don't remember if you shared what your release level was or your system configuartion. I would ask your implementators to check with JDE on this. It would also be very easy to test the impact. Find an item that has a G message on it and use supply and demand to see how MRP/DRP is assuming that you will act on the G message. Then remove the G message from the UDC table 34/MT (depending on your release level and system configuration, you may need to clear cache or just sign off and back on) and run MRP/DRP again and verify the results.

 

[Kevin Reker]

Re: MPS/DRP/MRP messages \'B\' type and G type

Thank you very much for your reply. We are on 8.12 and have been live for about a year. My background is mechanical engineering but this past two years I have been pretty much full time ERP. Anyway, just some background.

I found two references on the Oracle website, solution ID's 200999152 & 200995308 both of which state the solution you are talking about. However, in discussions with our implementation consultant he was very concerned about ever deleting a UDC from table 34/MT for two reasons.
1. He is not sure if it is still this way but even to experiment in prototype he had experienced an issue where if a UDC is removed even if it is put back it will not work the same. This alone has made me guy shy to experiment.
2. He also had mentioned that even though MRP doesn't provide a "Message" it still thinks the increase / decrease messages were processed. I could verify this if I knew I could experiment.

That's about it, if you could comment on the two concerns that would help a ton. I also have a case with Oracle where they are doing some research for me in Colorado. Thanks again!

Kevin

 

[Larry_Jones]

Re: MPS/DRP/MRP messages \'B\' type and G type

"He is not sure if it is still this way but even to experiment in prototype he had experienced an issue where if a UDC is removed even if it is put back it will not work the same. "

wow, I can't believe he said that

 

[Kevin Reker]

Re: MPS/DRP/MRP messages \'B\' type and G type

So I'm assuming since you said "wow" that you have done this before? We're on 8.12. I'm sure he had his reasons for saying it, did it used to be this way on a previous version and now that we're on 8.12 the issue has gone away? I also think he was grouping the G&L messages with "hard coded" messages and I've heard these are "user controlled". Is that the reason? Thanks for the info!

 

[bruce_meyer]

Re: MPS/DRP/MRP messages \'B\' type and G type

I would agree with Larry. I think possibly your implementation consultant may be slightly inexperienced.

Since he is afraid to experiment with something that JDE has allowed for the last 20+ years, and now that you have the documentation that says you can do this, and he is still worried, I would be looking for a new resource.

 

[ajit_nadgouda]

Re: MPS/DRP/MRP messages \'B\' type and G type

I experienced this issue in 8.11 SP1 two years back. We removed one UDC and tested something. Even if it was restored, the system was not recognising it. May be it had something to do with the html design, because it starts working normally after sometime. May be you need to restart or wait for some time or bounce the webserver to get the UDC refreshed. It will not change the functioning immediately after you changed the UDC.

Regards,
Ajit Nadgouda

 

[Larry_Jones]

Re: MPS/DRP/MRP messages \'B\' type and G type

Yes, it sounds like what you experienced was simply caching.

 

[Kevin Reker]

Re: MPS/DRP/MRP messages \'B\' type and G type

Thanks to all for the insight. I have what I need to test removing the 34/MT UDC G&L to see how it reacts to specific situations.

In discussions with Oracle I discovered it is related to SAR 8621151 which came out the December of 2007. This SAR modified business function B3400500 used in R3482/R3483 by assuring that the G&L messages don't just "disappear" but generate something to replace them, like an order message.

Thaks again for your help!