Audit-proof versioning of programs: VERS_AT_IMP

Hi there,

let’s have a look at a very handy system parameter, which is nevertheless not checked as frequently as others in audits — the tp parameter VERS_AT_IMP.

In a default installation, this parameter is set to »NEVER«, which means that no new version is created when transporting a program to a target system; the code is simply overwritten there.
If the parameter is set to »ALWAYS« (which is the only other valid option), a version history is maintained analogous to the development system.

Btw.: not only reports are affected by this, but all workbench objects that support versioning.

Functionality of tp parameter VERS_AT_IMP

Why does that matter?

The legal codes of many (all?) countries prescribe a duty to preserve records, which is also relevant for program code – the German HGB (Handelsgesetzbuch) for instance. Therefore, it is a risk to allow old program versions to be deleted (due to a lack of knowledge – or on purpose).

Developers are usually allowed to execute all reports on a development system, which also includes RSVCAD03 and RSVCAD04. These reports allow the deletion of a program’s version history (they’re NOT assigned to any program authorization group and the program code does NOT contain any AUTHORITY-CHECKs ← read comments below).

Update: Meanwhile SAP has added an authorization check for S_CTS_ADMI with value TABL to both programs. Anyway, this authorization is checked in many places and chances are high that some users have (and need) this authorization for other purposes. So, this does not change the general recommendation of this article…

Your options are:

  • if you want to keep the version history on the development system: do whatever it takes to secure RSVCAD03 and RSVCAD04 (just removing S_CTS_ADMI from all roles will not work, especially on non-productive systems) and be careful when restoring the system; you might lose versions (think of reinstallations)
  • set VERS_AT_IMP to »ALWAYS« on the productive system and keep your version history there (of course, the above reports have to be secured as well)

As you probably guessed, the second option is favorable, because:

  • authorizations on production are much more limited, so protecting the reports RSVCAD03/04 is much easier there
  • the continuity of a productive system can be ensured, while this is not true for a development system

Where to check it?

Start report RSTMSTPP, enter the productive system’s SID and go for it.

Where to set it?

Go to STMS → System Overview. Then double-click in your productive system and switch to the “Transport Tool” tab.
If the parameter does not appear there, it is set to the default value »NEVER«!

Update: Effect on installation of support packages

SPAM settings: Object versioning during support package installations


Switching the parameter to ALWAYS has no automatic effect on transaction SPAM. In other words: installing support packages does not lead numerous (useless) versions of SAP standard objects.
The simple reason is that SPAM allows you to choose whether to create versions of the objects in support packages or not (→ disabled per default).
To enable it, setting VERS_AT_IMP to ALWAYS is a prerequisite — check out SPAM → Extras → SettingImport queueCreate object versions during import — but be aware that this might have an impact on performance and database size.

So long!

7 comments

  1. Hello Daniel,
    thanks a lot for the great information you publish.
    Just some news on that topic: as SPAM is deprecated, SP & upgrades are handled through SUM and it seems that SUM does not offer any versioning option.

    Best regards.

  2. Hello Daniel,
    the DSAG audit guide also mentions this parameter and it is very helpful reading your blog in addition. Thank you. In this context also § 146 AO and the GoBS (Generally Accepted Principles of Computer-assisted Accounting Systems) can be mentioned as well. The GoBS is more detailed than the laws.
    But apart from legal requirements I think a version history is state of the art and can be very useful for testing and development.

    Martin

  3. Hello Daniel,
    I don’t understand your remark about the AUTHORITY-CHECKs. In my 7.02 system both reports are checking during initialization the authorization (Admin in CTS). This is a quite high authorization level. It is the same you need to set the system change options in TMS.

    Best regards, Ansgar

    1. Hello Ansgar,
      indeed SAP has finally added an authorization check to both reports (S_CTS_ADMI with value TABL) !!
      It must have been added in a SAP_BASIS release shortly after 701-2.

      Thanks for your helpful remark.
      Daniel

  4. Hello Daniel,
    thanks for this interesting article. You mention the duty to preserve records in the German HGB. On what paragraph / section of the law you are referring to. Do you know an auditor who complains about the missing parameter?

    1. Hi Bernhard,
      many thanks!

      §257 of the German HBG regulates the obligation to preserve records, which not only covers the accounting records themselves, but also the documents etc. that are required to comprehend the records in future. Concerning SAP, this also includes non-standard customer code, which cannot be obtained again from SAP. A typical example would be a custom program, which is used for the release of requisitions.
      Of course not each and every line of code is affected by this law (e.g. many “auxiliary reports” serve technical tasks only), but since it is impracticable to decide in every case, it would be sensible to simply maintain a version history for all in-house developments.

      In my experience the parameter is checked in audits, even though not as often as others; however I never received a complaint about it being set to the wrong value. 8)

      Daniel

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.