Incorrect Dynamic Product Proposal populated in sales order

[Former Member]

Hi Team,

Set up is such that while creating order, product proposal should work to propose sales order's from last 12 months for a customer and it's sales area.

But older dated orders are also getting populated.

I am using FM SD_DPP_READ

FM activity is ADD RESULT

Source is Order History

Product Proposal procedure is customized.

Date range is 12 Periods & Period Type is Month.

Could you help to check why older orders are pulled while creating orders.

Let me know if more details are required.

Thanking in advance.

Regards,

Anisha

[ChetnaK1 · Accepted solution]

Hi Anisha,

Please provide information on the whether the product proposal is being generated in background or online.

Also, to elaborate on this, FM- SD_DPP_READ is used only for reading the product proposal from database when a combination of background and online product proposal determination is used. So if you are using combination of both then your Product proposal (PP) procedure for background processing should contain FM - SD_DPP_HISTORY and PP proposal for online processing should contain FM- SD_DPP_READ.

However, if you using only online mode, then use FM -  SD_DPP_HISTORY.

One important point to note is that If you combine the background determination with the online determination then the function module SD_DDP_READ must always be listed as the first function module in the Online procedure.

[Former Member · Accepted solution]

Hi Chetna,

Thanks for the detailed reply.

We are using both online and background PP determination and setting seems to be correct as SD_DDP_READ is listed as the first FM in the online procedure.

We have recently upgraded to EHP7.

Also it is working in the test system but production has an issue.

I was also checking VBPV table and is it possible that the data in VBPV table can be incorrect?

In our test system only entries related to FM Source A (Order History) are populated in the table and in production FM Source A (Order Hostory) & D (CMIR) both are populated.

Regards,

Anisha

[ChetnaK1 · Accepted solution]

Hi Anisha,

In case of background processing the product proposals have to be generated using transaction SDPV (report SDPVGEN); this in turn updates the VBPV table.

In your case, please make sure that FM - SD_DPP_HISTORY is maintained in the access sequence of background procedure. Using the above t-code or running the corresponding report in background table VBPV would get updated and these updated entries could then be read by the online procedure containing SD_DDP_READ in its access sequence.

As long as the package versions are same for your test and production environment we need not worry about the upgrade; however if they are different then please try searching for the relevant SAP note.

For difference in the VBPV entries in test and prod environments, please check in prod whether there is any additional access sequence present in the background procedure containing FM - SD_DPP_CUSTOMER_MATERIAL_INFO; if yes, this might be the reason of having additional entries related to CMIR records in VBPV table.

P.S.: Please reward points if you find the responses helpful.

[Former Member · Accepted solution]

Hi Chetna,

I ran transaction SDPV in test system and table VBVP got updated with CMIR entries and issue is replicated in test system also now.

So now it seems when VBVP is getting updated with CMIR records via background processing (Using FM SD_DPP_CUSTOMER_MATERIAL_INFO ) we get incorrect entries for product proposal while creating sales order (which is taking online PP Procedure).

What can the cause for this and not sure how to proceed further?

Do we need a customised FM which will be a copy of SD_DDP_READ along with some validations?

Regards,

Anisha

[Former Member · Accepted solution]

Hi Chetna,

One more thing, PP Procedure is different for Online & background processing for the same sales area and customer PP Procedure.

Regards,

Anisha

[ChetnaK1 · Accepted solution]

Hi Anisha,

Yes, procedures would be different in online and background determination.

So what is the exact current setting in your system? only SD_DPP_CUSTOMER_MATERIAL_INFO in background procedure? You must have FM - SD_DPP_HISTORY in your background procedure for retrieving data relevant to order history.

If you don't require CMIR records, then SD_DPP_CUSTOMER_MATERIAL_INFO needs to be removed from the background procedure; but since you are saying this is already existing for the concerned sales area and customer determination procedure in production, I guess it would not be wise to touch the existing settings since it might impact the functionality for other customers. So, yes, as you said, you can opt for activity indicator 'D' with your own customized FM aligned with the access sequence

P.S.: Just reminding again, kindly mark my responses as helpful/correct if those were helpful for you.