SAP EHS MANAGEMENT FOR EXPERTS

[christoph_bergemann]

Introduction

Based on this thread WWI Spec Multiple Status Conditional Output I would like to provide some overview of  potential use of SAP EHS Core. The scenario as described in the thread is a quite complex one (in my opinion) and therefore not easy to handle.

These are the reasons:

• The "Status" on specification header is used
• Change numbers are used
• The generation variant seems to be set up (or there is the need to do so) including a "Status" check

If there the company acting here would add these additional demands

• Use of "Status" on phrase level
• Use of change number on phrase level
• Use of inheritance
  
  

The result would be the most complex set up of EHS core.

So based on documents:

SAP EHS Management for Beginners

WWI for Beginners

WWI for Experts

I will try to give some overview about the scenario as described in the thread (and the pitfalls).

Phrase Management

As mentioned above you can maintain on phrase level the "phrase status" and you can maintain phrases using "Change numbers".

Phrase status

The use of the "Phrase status" is explained here: Phrase Status - Basic Data and Tools (EHS-BD) - SAP Library

The complexitiy of use of the "Phrase status" is related e.,g. to this key message: "You can assign a phrase status to each phrase item of a phrase"; therefore you can define different status per language. Quite complex indeed. The effects on WWI reports are as well explained in the link as mentioned.

Use of Change number in maintenance of phrases

The use of changes numbers in maintenance of phrases is described here: Engineering Change Management for Phrases - Basic Data and Tools (EHS-BD) - SAP Library

As well you will find an example:

Example: Engineering Change Management - Basic Data and Tools (EHS-BD) - SAP Library

What are the "pitfalls" in using Change numbers? As shown in the link you can use the change number in several contexts:

• Phrase Header
• Phrase item
• Phrase set assignment
  

Let us imagine now the "simple" case that per phrase item you have a

• Phrase Code
• Phrase text
• Phrase graphic
• Phrase Remark

maintained. Now if you have a phrase prepared and you would have prepared four changes numbers valid for Date A, B, C and D you could maintain the phrase time like (very fictive example !)

Change Numer	Code	Text	Graphic	Remark
	ABCD	Blue	BLABLA	SAPSAP
A	BCDE	Blue	BLABLA	SAPSAP
B	BCDE	Green	BLABLA	SAPSAP
C	BCDE	Green	BLUBLU	SAPSAP
D	BCDE	Green	BLUBLU	EHSEHS

The effect in CG12/CG13 is like this:

If you use as the "key date" a date before A you will see the original data; if you use key date A you will seed the data as whon above, etc.

The effect for WWI reports is "nearly" similar; that means using a genvariant language combination and imaging that all four data is needed in WWI report the content of WWI report is different (even nothing has changed in CG02) based on key date used.

So the use of change numbers on phrase level are not easy to explain to endusers. The same is clearly true if you use change numbers in the context of phrase set assignments.

Change Numbers and their use in CG02

The use of change numbers in CG02 is explained here:

Engineering Change Management for Specifications - Basic Data and Tools (EHS-BD) - SAP Library

An example of use is shown here:

Example: Engineering Change Management - Basic Data and Tools (EHS-BD) - SAP Library

As well this chapter is very important: "Specifying Key Dates and Change Numbers". The concept of the "Key Date" in context of use of Change number must be understood or you can not properly use Chaneg Numbers.

Please check as well e.g. About use of Change numbers in SAP EHS Management (Classic)

You can use change numbers in CG02 in any context. E.g. specification header, identfiers, inheritance, reference, status, restriction, material assignment and maintenance of data in property tree. The same is true for the "Create Report "process. This can be very complex !!! Here you can define a "key date". And therefore data retrieved in WWI process depends on the "key date " of the data.

Status on Specification header level

The Status on Specification header level is explained here: Specification Status - Basic Data and Tools (EHS-BD) - SAP Library

The most important facts in correlation to WWI reports is discussed here: Generation Not Permitted - Basic Data and Tools (EHS-BD) - SAP Library; using a special "Status" you can hinder other use to chaneg data (refer to: Change Not Permitted - Basic Data and Tools (EHS-BD) - SAP Library).

Generation Variant

The use of "Status Check" is described here: Generation Variant - Basic Data and Tools (EHS-BD) - SAP Library

Depending on the "Used" Status the effect in/for WWI reports can be different.

Combination of the functions as explained above

Now at least in the thread as mentioned two of the options as discussed are used. The "Status in specification header" level and the use of a change number. At least three change numbers are used. So therefore the three "Status" as shown are valid for different point in time.

In time frame  02.06.2014 until 19.07.2014 we have a "Status" which is valid; a second one for time frame 20.07.2014 until 28.07.2014 and the third one which is valid from 29.07,2014 until 31.12.9999. It is important to look at the "design" of the "Status". Any of them is valid for any "Rating" and "REG_WORLD". On the top any of the Status used seems to be "customer specific" (ZRE and ZSR).

Now let us imagine that standard values would have been used: E.g. "RE" (released) and "IP" (In process). If "RE" would be set up like". display anything on a report" and "IP" would be designed "don't display in WWI report" it is clear that there is no chance to get a "nice" WWI document if the status would be IP.

Recommendations in use of the functions as mentioned above

It is very tricky to use combinations of the functions as explained above in daily business in EHS. You need to be really some "super EHS expert" to understand the effects (e.g. use of EHS Expert, ALE, SVT etc. etc. etc.). Therefore if possible you should not use combinations of the functions, only in the case that there is no other alternative you should combine the functions as explained Especially the use of Change numbers in CG02 in context of using "Inheritance" (can be a disaster) and / or "Reference" (can be very tricky) is not a good idea.

Keep in mind that the change number concept can be helpful (but as well a disaster) in context of "Dangerous goods management".

On the top: the use of change numbers increase the amount of data stored in your database; the deletion of data is quite tricky; the handling if WWI reports can be as well a "night mare" etc.

Other functions

Restrictions

As you may be know: you can maintained "Restrictions" on level of specification header. In most cases you do not need this option. In most cases this option is an "add" on in access concept on thetop to the "Substance authorization group" (better: specification authorization group). E.g. yoou could use this like: you have only may be 5 substance authorization groups in place. But may be you have a "regional specific" set up. Therefore you "cluster" your company in "branches"; may be : Oil And Gas, Chemicals etc.

So any body should use the same substance authorization group but by mandatory assignment of restrictions you can "hide" one specification form a different one in the same group (matter of differenciation of "maintenance" and "display" part.

In any case: check: Restrictions - Basic Data and Tools (EHS-BD) - SAP Library

Reference

The "Referencing" option is a quite nice option to support the "maintenance" of data. It is simple in use etc. in comparison to "Inheritance". Functionality is explained in SAP online help (Reference - Basic Data and Tools (EHS-BD) - SAP Library). Clearly the "Inheritance" is more flexible; but there are a lot of "cons" in using inheritance.

In most cases the "Reference" is a "good" choice.

In any case: Before you use "Reference" or "inheritance" you need to define your maintenance concept. E.g. Do you use rulesets etc. You should not mix "Reference" and "Inheritance" in your maintenance concept. Use either "Reference" or "Inheritance".

Remember: you can not use two specifications as a reference having the same data maintained (e.g. REAL_SUB => REAL_GRP1; REAL_GRP2; both objects should have data in "color"; this is not possible)

Inheritance

This is explained as well in online help (Inheritance - Basic Data and Tools (EHS-BD) - SAP Library). The use of Inheritance is more flexible in use but much more complicate in the daily use than the use of "Reference". You need mainly to understand the "Inheritance template" concept (Inheritance Template - Basic Data and Tools (EHS-BD) - SAP Library) and the "inheritance job" etc. to trigger. Before you use inheritance: take your time to write down a business concept: how to use etc. This is very important or you will get later a "disaster" in data base. Furtheron you need to define a group of persons who are maintaing the "inherance templates"; and you should do a lot of "experiments" in a sandbox to get a "good" feeling about pros and cons of this functionality.Keep in mind: it is not a good idea to mix "inheritance" and "reference".

Remember: you can use two specifications using inheritance having the same value assignment type/property populated data (e.g. REAL_SUB => REAL_GRP1; REAL_GRP2; both objects should have data in "color"): The only but is: both data records must ! have different usage ! and you must use two different inheritance templates. For CG02: this is a "nightmare" as CG02 can only display one identifier in the property tree to indicate from which specification the data is inheritated

New topics

May be check the new document: Enabling Change Documents Log for Specification in EHS Specification Management.