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:
I will try to give some overview about the scenario as described in the thread (and the pitfalls).
As mentioned above you can maintain on phrase level the “phrase status” and you can maintain phrases using “Change numbers”.
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:
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 !)
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:
An example of use is shown here:
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).
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.
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
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)
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
May be check the new document: Enabling Change Documents Log for Specification in EHS Specification Management.