using two KDKGR sub fields in same access sequence

[DrenthBL]

Many times a customer is in one discount level for one season and a different discount level for another season. We want to use the KDKGR fields for this. I've created a condition table Sales Org/Distr. Ch/CustCondGrp/Material Group. I can include this table multiple times, once for each season, and map each to the correct sub-filed KDKG1 - KDKG4. The problem is that there doesn't seem to be an easy way to indicate to the business which one is which when they are loading pricing in VK11/12. We are using the same values L1 - L20 in both cases to indicate the discount group for that particular season. I could create a separate condition table for each level and manually change the name for each season, but that uses up 4 condition table names. Ideas?

[Lakshmipathi]

Have a custom table in sm30 with different seasons and pricing validity period. I presume a maximum of 4 entries would be there in this table. Create a vofm routine to validate the logic such that system to consider this custom table as and when billing documents are generated and based on the pricing date, system should fetch the related discount from condition record. Finally, assign this routine to that discount condition type in pricing procedure.

Here you also need to take into consideration one aspect that how SAP to validate when the billing documents are created in the 1st week of subsequent month when the discount varies. This will predominantly come in all Business process where the Business closes their sales in the 1st week of succeeding month.

[DrenthBL]

Thank you. I hadn't considered this option.

[Ryan-Crosby]

Hi Barb,

In order to handle that with one table you would have to intercept the key combination processing to allow a user to designate the season of interest. There may not be any enhancement spots or exits for you to do this in the VK* processing. Doing a separate table for each season requires more condition tables to be created/used, but at the benefit of zero ambiguity about user intent during condition creation, and certainly without the possibility of modification.

Regards,

Ryan Crosby

[DrenthBL]

We are nearing the end of the number range for condition tables, but I did create tables as an interim solution.