Content:

Property Tree



Specifications ( PROD_COM , PURE_SUB , …) are characterized by data which are managed through property trees. These data are organized in classes which are themselves subdivided into characteristics.

For example: the “Flash point” class (chapter 9) consists of the following characteristics : Value, Pressure, Test type, Remarks…


There are several property trees which enable to put in light different information types (compositions, chemical properties, SDS,…). Information are actually the same, property trees are different ways to handle the same data.


PURE_SUB and PROD_COM have their own dedicated property trees.

PURE_SUB view for Product StewardPROD_COM property trees

In the pure substance property tree, classification information (chapter 2 and 15), OEL (chapter 8), and intrinsic data (chapters 9, 11 and 12) can be found.

Intrinsic data classes are presented the same way in Pure_Sub and Prod_Com property trees.

Several property trees exist for PROD_COM specifications, regarding the zones

  • the zones property trees ( EMEA, AP, NA, LA ) enable to display all chapters of the SDS (according to each zone needs) + an additional chapter 0 containing compositions, type of diffusion of SDS, etc.

  • there are other property trees such as "Z_PC_PS PROD_COM view for Product Steward".


Concept of usage


Usage = Rating + Validity Area

RatingValidity Area

Rating need to be assigned to each data in order to be recognized by Rules and displayed on template
Rating can be:

  • PUBLIC: the data is read by the rules and displayed on the templates;
  • CUSTOMER: the data is NOT read by the rules but displayed on the templates;
  • INTERNAL: the data is not read by the rules neither displayed on the templates;
  • Z_LABEL: content in this instance will be displayed on the label, in priority over the other ratings. This can be used to have separate phrases just for the labels (often shorter).
  • Z_TRM: for Brazilian Tremcard;
  • FSL: for Japan label.

The validity area enable to define the geographical area for which a given value is applicable.

>> For more information about used Validity area in SAP refer to this link (broken link).


Multi value / Multi Instances

There is the choice between maintaining data with multiple values or instances in EHS.

It has a direct impact on the template! Typically it is a tool to allow to control the spacing in the document.

When you maintain with multiple instances, it creates a line break, allowing to add space and highlight some content.

When you maintain with multiple values, the phrases are usually mapped under one another, with no line break. There are a couple of exceptions, for example the display of incompatible products.

Unfortunately some standard SAP characteristics are made to receive only 1 value per instance so not always there is the choice!

For example, the type of filter or glove in the Personal Precautions section is a single value field.



Data origin

To identify the data origin of an instance (either manual or from a rule ), you must select the instance you are considering and then key Ctrl + F10. A pop-up window opens and specify the following information:
    • Creation date;
    • Person who created the data;
    • Date when data was last changed;
    • Person who last changed the data;
    • Data origin:
      • EH&S: data manually filled in or rule output modified*;
      • ZEXP_XXX : rule;
      • other: usually an uploading.

It is possible to modify the result of a rule while keeping the data origin of the rule ( allows to overwrite manually modified data next time the rule is launched).

It can be achieved by following this instruction: Utilities > Settings > Data provider + click on "Retain data origin/provider". This setting is temporary and only available until the next logoff.


Inheritance concept / Family of products

In SAP EHS, each PROD_COM generates its own SDS. It is possible to centrally managed data of homogeneous products within a “family”, by using master-slave inheritance link .

  • Any SDS can inherent any section (1-16) from any other master SDS;
  • Once inherited, it is linked. So any changes in the master cascade automatically to all slaves and will be implemented on next SDS validation => save time.
  • For a master, there can be as many Slaves SDS as needed. It is also possible to link different templates on the same Slave, if templates do not cover the same sections.

It is possible to link any section of SDS (1 – 16), different templates exist. Recommended ones:

  • Do not inherit composition and classification unless the products are exactly the same (different names for same product);
  • Only inherit the section 14 directly from the DG_CL_SUB ;
  • The standard templates for inheritance is SDS_FAMILY : all classes except the ones directly linked to the product's classification that are populated by the rules or manually maintained.

Finally, it is possible to create REAL_GROUP and use them as masters for some products with common hazards. For example, one mask for explosive products, one for environmental hazardous products, etc.

>> Refer to training materials Inheritance & Copy template.  (broken link)


If you need to create your own inheritance template , follow those recommendations :

  • Composition levels must never be included in inheritance template. They are dedicated to each PRCO and most of the time inputs of rules. So they have to be manually managed on each PRCO.

  • Rules outputs (GHS classification/labeling, Hazardous ingredients, components with OELs, local regulations, notification status…..) should not be included in inheritance template. Rules outputs are strictly linked to legal/standard compositions themselves dedicated to PRCO.

  • Inheritance templates managed in your private folder should be updated by you each time new properties/classes are available in EHS. Your EHS administration is not able to see and check your private inheritance templates, unlike those available to everybody (Standard inheritance templates).

    • For example: in the last version, the new property “burning rate” has been included in all PRCO property trees. All inheritance templates including chapter 9, should be updated with this new property.

  • It is not possible to remove a property from an existing inheritance template.

  • Be careful that some classes come together as outputs of the same rule (eg with Hazard_Comp rules), thus for inheritance you have to pay attention to consider both classes the same way.

  • You can find hereafter a guideline property tree by property tree listing the different classes for which an inheritance between PROD_COM is allowed, not recommended or not allowed.

  • Also note that it is strictly forbidden to modify the standard inheritance templates, this task is under the EHS administration responsibility.

      • Also note that any template may also be used for a one shot copy. This allows you saving time when creating a new product.
      • This is called the "copy template" functionality.


More questions? Contact EH&S support team .