Why is condition requirement code sometimes modification?

[pokrakam]

When creating custom requirements for conditions (Pricing, output, etc.), the system creates an editable include in SAP's namespace with the condition number in it's name, e.g. RV61B999 for requirement 999. Done it a few times in the past without a problem.

But I was surpised to discover that this system asked for a modification key to edit the code for a custom requirement; and even more surprised to find that this varies from one requirement to the next. Most odd.

So we have some that have the modification stamp, like:

FORM KOBED_923.
*{   INSERT         DEVK123456

Yet others are regular editable includes:

*---------------------------------------------------------------------*
*       FORM KOBED_919                                                *
*---------------------------------------------------------------------*
*       ........                                                      *
*---------------------------------------------------------------------*
FORM kobed_919.

Given that I've found alternating styles looking at conditions created over several years, this is not something that changed in a particular version of SAP. Nor can I find any obvious differences in the configuration.

So my question: Why are some conditions treated as modifications and others aren't?

For what it's worth, the particular ones we're currently working with are output conditions.

[pokrakam]

To illustrate the issue, here's a sample of the condition sources in SMODILOG (Log of Customer Modifications to Dev. Env. Objects):

The MOD enhancements are repair/modifications. I don't particularly care which way SAP does it, but this flip-flop business is bizarre.

[eduardo_hinojosa]

Hi Mike

According Note 327220 - VOFM function and its objects, point 2.2.1. under the title 'SSCR object registration' the reason is these objects are asigned to SAP development class or package.

Regards

Eduardo

[pokrakam]

Thanks Eduardo,

As per my other responses, all have registration keys, and all of them are assigned to the same package. Yet some are modifications or repairs, others aren't.

Regards,

Mike

[RaymondGiuseppi]

Also some Abapers, once they got a sscr key, deactivated the modification assistant, so no 'modification stamp' will appear. Once you got an sscr key, it would no longer be required, til next upgrade (version change, not SP).

You can get a list of already required SSCR keys on support site at https://launchpad.support.sap.com/#/sscr/objects/my

You can also browse modifications in transaction such as SE95 or browse table ADIRACCESS.

In recent versions, you could also use enhancement point or enhancement section and won't require a sscr key. But would get some trouble when trying to copy a formula...

[pokrakam]

Hi Raymond,

Thanks, I didn't think about the option that someone could have switched off the modification assistant, but this isn't the case here. I checked SE95 and three were without modification assistant, but they weren't among my samples.

All custom conditions appear in SE95 - as expected. But some are considered modifications or repairs - not expected.

Regards,

Mike

[hohoman]

Hello,

Object keys are requested for all programs within the SAP Namespace and therefore even customer defined forms are generated into a R... Source the system requests a key.

So it is not a modifcation ... SAP never changed the coding which makes the difference between Modification or not.

Regards

Holger

[pokrakam]

Hi Holger,

Corrent, you need a key to create the requirement, and from past experience you can then go and edit it as regular code. This is the case in my second example above and as I've done it at other sites.

But here some of the code is treated as a modification, requiring an additional key (my first example). I agree with you it shouldn't be a modification, but sometimes it decides so, even on a brand new condition. This is the scenario I'm puzzled about.

Regards,

Mike