If you’ve read past the title of this post, then you’re probably already familiar with SAP’s Hierarchical Access (HA) debacle. Long story short: SAP was sued for patent infringement in the US and they are now forced to disable one particular pricing feature for all of their US installations — the HA function. Therefore, this affects ALL of my clients.
Based on my personal experience, this feature isn’t widely used. And for those customers NOT using it, there is a relatively simple process to remove the feature, validate the removal and move onto more pressing matters. However, I recently encountered my first client who actively utilizes the HA function and the process becomes somewhat more involved.
| NOTE: This article has become moot since this is no longer an issue. Please review SAP Note 1692588 which should address the issue. You should be able to freely use the Hierarchical Access Sequence described in this article. I did work with a client who was behind in their support patches and decided to use custom ABAP code to bypass the restrictions in ECC 6.0 instead. Your call. |
The SAP Note dealing with this issue instructs companies which use the HA to engage SAP directly to assist with finding and implementing a solution. Because I work closely with this client, they wanted me to be involved in an advisory role. But first, perhaps I can recap the HA function a bit.
What is the SAP Hierarchical Access Seqence?
Hierarchical is an Access Sequence type that allows you to identify a series of optional fields to be used in determining a price or prices. When you create the pricing condition records, you can specify values in any combination of those fields. You must also give each field a weight between 01 and 99 which tells the system how to apply the conditions in the event that more than one are determined — a value of ’01’ being the highest priority. Two fields CAN have the same weight; in which case, both records can return values. Although you can specify any fields you choose, SAP seemed to have the material’s Product Hierarchy in mind when delivering their own configuration. To use an example, let’s say you have your products in a three-tier hierarchy. You can — or, I should say could — maintain two Sales Deal conditions at the 2nd and 3rd level respectively with the lower level taking priority. When SAP encounters a product that meets both of those conditions, it will take the value from the 3rd level and ignore the other. The main benefit of this function is to optimize the number of condition records for a given scenario within a single condition table. Think of it as an Access Sequence within an Access. Without this function, the number of required condition tables will multiply exponentially.
What happened with SAP and my client?
We met with the SAP representative and discussed the situation: My client uses the HA function as part of its Sales Deal determination. They have five custom fields on the customer master in which they maintain different classifications. They have these fields in an HA structure allowing them to maintain conditions at different priorities. In an email, the SAP representative first proposed that the structure is a good fit for a straight “migration”. This would mean creating additional condition record tables for each combination of criteria. Given the number of fields in the hierarchy, this means over thirty condition tables would be required to replace only one of several HA accesses. Needless to say, the client was not thrilled at this option.
After I helped the client digest the information provided, we immediately began a triage of the process. We quickly brainstormed some other alternatives — none of which were ideal and all of which were either time consuming or requiring custom development.
What options to the SAP Hierarchal Access Sequence exist?
We had a subsequent conversation with the SAP rep in which we further discussed the options. However, this time he brought up a DIFFERENT option which he referred to as the “whitelist solution”. I won’t pretend to understand the legal foundation for this, but evidently SAP customers have the option of specifying a list of allowed fields from either the customer master OR the material master (not both) as a sort of exception to the rule. This allows my client to name it’s five custom fields as the whitelist and resume using the as-is HA functionality. The downside is that they cannot specify any customer fields outside of this whitelist without SAP modifying the system and they will never be able to specify fields from the material master. Ever.
For my client, this was not a huge sacrifice since the configuration for this particular function had not required alterations since the initial implementation some years ago. We are currently pursuing this option and anticipate moving forward just as our SAP rep described. I only wish that he had led with this option to save us a bit of the frantic solutioning we did.
One final note: since the client had other Accesses which use the HA function including fields on the Material Master, we will have to “migrate” those using SAP’s recommended solution. But they were much smaller and aren’t heavily leveraged.
