cancel
Showing results for 
Search instead for 
Did you mean: 

Forecast Consumption in SNP

Former Member
0 Kudos

Hello,

can anyone tell me in customizing where we can select category types to forecast consumption?

Because we are having a forecast consumption in SNP from R3 sales orders and deliverys (type BM and BR) and this was not supose to happen. Only PGI from sales orders should be consumed so we are having duplicated consume.

Shouldn´t this be a standard procedure or we can choose categorys?

thanks,

Teresa

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Teresa,

The categories which should consume Forecast can be User Defined. Generally, the Sales Order (BM) should consume Forecast (FA). When a Delivery is created in ECC against this Sales Order, this Delivery gets CIFed to APO and it replaces the Sales Order.....means your BM Sales Order number gets replaced by the BR Delivery number.

If you want only Sales Orders to Consume Forecast and Do Not want Delivery to consume Forecast OR in other case, if you want both Sales Order as well as Delivery to consume Forecast then you should define these things in the Customizing.

In customizing, if you go to Requirement Strategy = 20 - Planning with Final Assembly, you see a field for Category = FA (this would be consumed) and you see other field as Category Group (this would be used to consume FA)

So you can put any Category Group of your choice, say for example Z01 and then define it as a category group having Category = BM or BR or both BM & BR.

hope this helps

~Abhi

Former Member
0 Kudos

Hi Teresa,

Please check in spro, Supply Chain Planning> Demand Planning (DP)> Consumption --> Specify Requirements Strategies path

Thanks,

Siva.

Former Member
0 Kudos

Hello,

i've already check that but that is the Category assign to the Requirements Strategy and it has FC (we are using stategy 20).

What I mean is the category that it is shown in table ZIRQREDUCT (log of withdrawal qty - sap note 623216) that shows in APO the sales order number created in R3 system that was consumed in APO. In my case we have BM - sales and BR - deliveries and we only should have orders.

Thanks,

Teresa

Former Member
0 Kudos

Hi Teresa,

I don't understand what you mean by "duplicated consume". Can you give an example?. Please take a look at [consumption in APO|http://help.sap.com/saphelp_scm70/helpdata/EN/fb/209e75d9414d1e81daa1f6a1703253/frameset.htm]

Consumption parameters are actually set in ECC not in APO and I don't think we can even change that in APO.

In ECC, look at SPRO>Production>Material Requirements Planning>Master Data>Independent Requirements Parameters>Define Strategy.

For example in strategy 10, SAP standard is Blank (No consumption with customer requirements)" for consumption and that is the reason why a sales order created with MRP group 10 in material master is not relevant for consumption all the time, which really means a sales order does not consume forecast and even though sales order appear in APO, it is name sake and does not drive any demand.

The strategy 10 in ECC correspond to strategy 10 in location product master- demand tab.This is automatically transferred when material is CIFed to APO.

If the same strategy is set to 40 In ECC, which becomes 20 in APO. Then the sales order consumes forecast.

Unless there is a bug, I see no way of double consumption.

I think what you need to do is use strategy group 10 in ECC material master - MRP3 tab, which translates to 10 in APO/.

Also please[read this post|] to understand how strategy 10 and strategy 20 differ:

Hope this helps. Please let me know if I am getting your point right.

Former Member
0 Kudos

Hi Visu,

we are uing strategy 20 and it works fine until now. Then the sales order consumes forecast and that is ok. The problem is that deliverys (type NL) also consume forecast and this was not happening until one week ago and I don't now why.

We only thing I can see is that in table ZIRQREDUCT (log in APO of PGI made in R3) we have category BM and BR and

it should be only BM. This category started to be in this table since one week ago. How are this categories customized? In R3 or APO?

Thanks and Regards,

Teresa

Former Member
0 Kudos

Hi Teresa,

Consumption of forecast by category BR is correct. As I understand once delivery is created, BM gets converted into BR. And hence whatever is consumed by BM that should remain as it is when BR is created. After this when PGI is created the consumed forecast is converted into withdrawal quantities.

Kindly check if same behavor is seen in your system.

Best regards,

Vaibhav

Former Member
0 Kudos

Hi,

I dont think BR is correct because we only have BR since 2 or 3 weeks, before that we only had BM. And this BR come from type NL deliveries from stock tranfer in R3 and I think this is not ok.

We have implemented SP in R3 system and I dont´t now if this issue has somethig to do with that.

Best Regards,

Teresa

Former Member
0 Kudos

Hi Teresa,

Sorry for the late reply.

Vaibhav explained it correctly. Having BR consumption relevant is correct for both sales orders and stock transfers. They both have the

Delivery type NL is for a delivery created for a STO. But the deliveries for STOs are not supposed to consume forecast. You are supposed to have different item types for the delivery of a sales order and delivery of a STO. Can you check if the same item type is being used? If so that could be root cause.

In ur message, you said the delivery type NL has been consuming forecast from the past 2 weeks. I would check with ECC guys if they implemented some thing int his time frame. May be that has changed the behavior.

Hope this helps.

Former Member
0 Kudos

Hi Visu,

That´s exactly what is happening, delivery type NL created for a STO are consuming forecast and they were not suppose to.

We have different item types for the delivery of a sales order and delivery of a STO, we have TAN for sales and NLN for STO deliveries, I think it is correct.

I found out that SP were implemented in R3 system so I think the problem cames from that but I really dont now were.

Thanks and Regards,

Teresa