Condition table generation in SAP for non key fields.
Condition table generation in SAP is used across applications in SAP. The current blog post refers to pricing usage A in application area V (Sales). We use V/04 to create different keys for our price condition tables. Here we would select which key fields we would want as such. SAP already pre-deliveries certain access sequences for price condition PR00.
But most of these condition tables , table A305 for example are attached to access sequence and within access sequence we can define some fields as non key. Say we add custom fields to the table A305, these fields can be made as non key in access sequence. But we still have a problem of date overlap when we enter these conditions in VK11 because in the table A305 these are technically key fields.
This blog looks at a different approach to avoid date overlaps and treat such additional fields as non key fields in database A305 itself.
Non key approach at database condition table generation
The unique requirement is to create condition table with more detail. Often we can create keys and then in access sequence we describe them as non key. But it wont solve the issue as condition records need be unique for a given date when they are created or changed in VK11/VK12 as mentioned earlier.
So here is a quick cheat sheet.
Then generate using V/04. So this is my result .
T681E entries after cheat list edition
TMC1K and TMC1D
So when I generate now using V/04, I see the fields well without key and I get no syntax error as well.
Unfortunately the access sequence detailing is not up there yet as I see a red icon. But I would ignore it.
Final solution : You can see now enter details on VK11 or VK12 without worrying about date overlaps. Now to our beautiful screen on VK11 where we can see conditions with details or without details.
Additional topic: User Exit
We also have a user dynamic exit but I did not use it as such/ But you could manipulate the above here as well using program.
Additional topic More details on same date :
If there is a requirement to have more details for your pricing record, you can consider adding a time field to the key but advise your customer to keep the end of day record time as blank and rest as additional data records.
Conclusion: We can use TMC1D table to define our detail fields without key. Just ensure these fields are not in T681E and TMC1K. VK11 now looks really helpful to the customers who can add many details to the condition record without worrying each condition record with detail wont create an overlap. In the given example, we are adding historical price record to define what caused the additional price ( positive or negative). Again as I mentioned in the introduction, condition technique has is used across applications and varied usages within an application ( For example Output conditions), so the detailing of condition record ( non key fields) can be used across usages/applications in SAP.
Condition table generation in SAP is used across applications in SAP. The current blog post refers to pricing usage A in application area V (Sales). We use V/04 to create different keys for our price condition tables. Here we would select which key fields we would want as such. SAP already pre-deliveries certain access sequences for price condition PR00.
But most of these condition tables , table A305 for example are attached to access sequence and within access sequence we can define some fields as non key. Say we add custom fields to the table A305, these fields can be made as non key in access sequence. But we still have a problem of date overlap when we enter these conditions in VK11 because in the table A305 these are technically key fields.
This blog looks at a different approach to avoid date overlaps and treat such additional fields as non key fields in database A305 itself.
Non key approach at database condition table generation
The unique requirement is to create condition table with more detail. Often we can create keys and then in access sequence we describe them as non key. But it wont solve the issue as condition records need be unique for a given date when they are created or changed in VK11/VK12 as mentioned earlier.
So here is a quick cheat sheet.
- Delete the non key fields from table T681E
- Delete the non key fields from table TMC1K
- Add the non key fields to TMC1D
Then generate using V/04. So this is my result .
T681E entries after cheat list edition
TMC1K and TMC1D
So when I generate now using V/04, I see the fields well without key and I get no syntax error as well.
Unfortunately the access sequence detailing is not up there yet as I see a red icon. But I would ignore it.
Final solution : You can see now enter details on VK11 or VK12 without worrying about date overlaps. Now to our beautiful screen on VK11 where we can see conditions with details or without details.
Additional topic: User Exit
We also have a user dynamic exit but I did not use it as such/ But you could manipulate the above here as well using program.
Additional topic More details on same date :
If there is a requirement to have more details for your pricing record, you can consider adding a time field to the key but advise your customer to keep the end of day record time as blank and rest as additional data records.
Conclusion: We can use TMC1D table to define our detail fields without key. Just ensure these fields are not in T681E and TMC1K. VK11 now looks really helpful to the customers who can add many details to the condition record without worrying each condition record with detail wont create an overlap. In the given example, we are adding historical price record to define what caused the additional price ( positive or negative). Again as I mentioned in the introduction, condition technique has is used across applications and varied usages within an application ( For example Output conditions), so the detailing of condition record ( non key fields) can be used across usages/applications in SAP.
- SAP Managed Tags:
