How to Add a Custom Informational Field to Pricing Condition Records

[Former Member]

To begin, I am not a programmer or technician, but a business analyst. I have asked this question of my technical support team, but they have advised me that what I am asking is hard, maybe even not possible (they don’t know yet). Hence I am turning to the larger SAP community for help.

We have a request from our business to identify pricing conditions with attributes that are not pricing relevant, and would not be used in pricing per se, but would assist with the review of pricing conditions, and support updating or delimiting condition records.

For example, we do not use contracts, or other formal system constructs to manage pricing with our customers. But we do enter into business agreements with customers to price them in specific ways. Those business agreements turn into pricing condition records, but are undistinguished from any other pricing condition records. So pricing conditions exist for customer A and from a business point of view, don’t represent any particular commitment to the customer, but are meant to generate a generally acceptable price for that customer. On the other hand, pricing conditions exist for customer B which, from a business POV, represent a commitment to price in that specific way. Both business scenarios use the same condition record types.

This makes it very difficult to distinguish between them. For example, when a vendor has a price increase, in some cases we are not able to pass on the increase, or maybe we can pass on the increase but nothing more (customer A, with whom we have a business agreement), while in other cases we may be able to not only pass on the increase, but raise our price, to further improve our margin rate (customer B).

Because we cannot distinguish between condition records of the same type which represent commitments versus those which are not, much time and energy is spent trying to react to these situations. When large-scale action is necessary, the business struggles to understand which condition records represent commitments we have to maintain, versus condition records which do not.

My thought was to create a new field to house values that would help identify the purpose of a condition record. The values for the field could be held in a custom table that would be used to check entries made during condition record creation or change. On the surface it sounded like a simple table extension, with logic to check values for the new field against the check table. Part of the reason for considering this approach was to avoid having to make changes to configuration, or the pricing procedure. We simply thought to add a custom field to all the appropriate condition types, and that field may or may not be populated, but would have no effect on pricing – it’s simply informational, to support decision-making.

However I’m told that condition records don’t support this extension concept in the same way as most normal tables, and there are issues with making the field editable in t-codes that create or maintain condition records.

If this is feasible, I would appreciate any help I could pass on to my technical colleagues about how this is accomplished. If there is a better technical solution, I’m also open to that, though we are trying to avoid a conversion activity that would require coordination of technical implementation with business activity at go-live. We simply want to add a new, optional, informational field to our existing customer pricing condition records, the entry of which can be controlled or validated, so we can identify why a condition record exists, for analysis purposes and potential pricing action.