One of the uses of the Condition Index tables is to maintain and display condition records for multiple condition types or multiple access sequences at the same time. This allows for functionality in VK12 and VK13 that is similar to using the new VK32 and VK33 transactions with a pricing report.
Condition Maintenance – VK12
Having active condition indexes allows for the use of the Select Using Index button that is available in VK12 and VK13, and shown, surrounded by the red box, below.
When clicked, the Select Using Index button will display each active index table that is configured in SAP, similar to how SAP displays the various condition tables available in the access sequence assigned to a Condition Type when clicking the Key Combination box.
Pricing indexes are not condition type, or condition table, specific. This allows for the maintenance of multiple condition types across multiple condition tables, all at the same time. This can be particularly useful when updating all prices for a given customer or material.
A customer / material discount is created for 10% using condition type ZZ01.
A customer specific discount is offered to the same customer, but for only 5%, using condition type ZZ02.
Using normal condition record maintenance these two records will always need to be maintained separately, as they are two different condition types, even if they were the same they are in two different condition tables.
Using standard condition index 2, which is not activated by default, it is possible to maintain both of these conditions at the same time.
On the selection screen there are no required fields, meaning that condition records for even multiple customers could be selected, or across multiple sales areas.
Amounts for the two Condition Types can now be maintained.
SPRO –> Sales and Distribution –> Basic Functions –> Pricing –> Maintain Condition Index
Change condition types
Only Condition Types that have the Condition index flag checked are added to Condition Index tables.
Maintain condition tables for index
Condition tables for indexes are maintained the same way that condition tables for standard pricing are maintained. Custom tables should start at 500. The generated tables are prefixed with KOTF, so in the example above the table KOTF002 could be viewed using SE16n.
Conditions: Allowed fields
A field catalog can be maintained, using the same methods as the standard field catalog for Pricing Condition tables. All fields from KOMK / KOMP pricing communication structures are available and can be enhanced by adding append structures to KOMKAZ and KOMPAZ.
Activation of Condition Index
In addition to activating the condition index, choosing the correct requirement is critical.
In the example above condition type ZZ01 would not have been visible in condition index 2 if requirement 001 was selected instead of requirement 002.
Set up condition indices – V/I2
In order to populate the condition index table with condition records that were previously created it is necessary to Set up the condition indices, which is the 4th activity in Maintain Condition Index and can also be launched using Transaction V/I2 or program RV15F001. The first step that SAP performs when executing this process is to regenerate each pricing condition table, if any pricing condition table fails then the whole process fails with a Short Dump that can be viewed in transaction ST22.
Regenerate Pricing Condition Tables
SAP uses program RV12A001 to regenerate each pricing condition table. You can mimic this execution by running program RV12A001. Set the Usage to “A” and leave the table criteria un-populated, the Dictionary, Reports and screens, and Online fields should all be checked.
An issue I have run into has to do with the Pricing communication structure KOMG. If a pricing condition table exists in SAP, and for some reason the fields in the table are no longer in structure KOMG then a short dump would have been generated during the Set up condition indices step. The short dump references Program RV15F001 and program RV13AXXX, where AXXX is the condition table that SAP is having trouble regenerating.
In the example above SAP had trouble regenerating condition table A144 and it was due to the custom component PRODH1 being missing from KOMG. PRODH1 was a material specific attribute that should have been included in a customer specific append structure to the Pricing Communication Item structure KOMPAZ.
Once the problems running RV12A001 have been resolved it should be possible to successfully run the Set up of condition indicies.
This one is interesting. However, our SAP users don't like to do any extra steps. So I don't see them using this.
I probably could use this in a custom program - changing the index in the background depending on what was selected. In fact, I wonder if there is a BADI, Enhancement or user exit that could be used to select the index.
I really like that you can use an index with these tables.
I have used condition index tables to aid in custom reports that include pricing information. Instead of searching through multiple A tables it is possible to just search through one or maybe a few KOTF index tables.
I have not attempted to use indexes for automated pricing updates. I am interested to hear more if you try.
Really a well documented blog with screen shots wherever necessary. Kudos and keep continuing.
Where would performance issues with these indices be noted? Would it only affect condition creation/maintenance or would it also affect sales document / billing document processing?
Condition Indexes are only used in the maintenance and reporting of Pricing Condition Records. The potential for a performance impact would only be in the creation / change condition record process ( VK11 / VK12 / VK31 / VK32 ) and likewise on the MM side with MEK1 and MEK2, if using purchasing condition record indexes.
There is no impact to Sales Document or Billing Document performance.