Issue found in EHS in using specification data import using process

[christoph_bergemann]

Dear EHS community

Now using EHS classic for a long time a issue has been detected in EHS standard import. During maintenance of EHS data normally using CG02 the system is always using the default "Data origin" specified in customizing to be stored in EHS tables (e.g. ESTRH, ESTRI etc.). In standard process to import specification data one can define a different "Data origin". Now we are using an import file with default" data origin and executed the import. Now a strange effect has been detected (and not always) for update of identifiers. For the import purpose you must nominate at least one identifier. If the identifier is found then normally no update happens but only the value assignment data is inserted (or updated). If the identifier is not found it get be inserted on spec level in ESTRI. Now during the update the "Data origin" of the identifier present in the system (and which matched to identifier on file level) was changed but not the identifier as such. Any data record on value assignment level received the defautl data origin. Actually there is no explanation for this behaviour. If Default "Data origin" would be "SAP" (as the term) this value has been change to "Space". Any explanation of this effect is appreciated (or and idea regarding that).

C.B.

PS: analysis of change logs in EHS etc. executed so far clearly indictae that an "Update" happened on the identifier; but only the field SRSID is effected; EHS import is quite old and therefore very stable;

PPS: I found a thread taking about the import file:

Example shown thre is like:

+BS

+BV   $ESTRH

SRSID                          EH&S

SUBID                          000000385000

SUBCAT                         REAL_SUB

AUTHGRP                        EHS_PS

+EV

+BV   $ESTRI

SRSID                          EH&S

IDTYPE                         NAM

IDCAT                          EHS_OLD

IDENT                          XY0002

ORD                            0001

+EV

+BV   SAP_EHS_1013_001

$ESTVA-SRSID                   EH&S

SAP_EHS_1013_001_VALUE         N09.00101280

+EV

If you compare SAP helpt normally only at the"begining pof the file you will find "SRSID" Here this field is nominated often. On Level of ESTRH as well as ESTRI.

PPS: e.g. refer to: TCG56 EHS: Data Origin - SAP Table - ABAP

[Ralph_P · Accepted solution]

Hi Christoph,

just to make sure I understood correctly: You had NAM EHS_OLD with value XY0002 and Data Origin "SAP" in the system. I the load file shown above, the identifer is identical, but the data origin here is "EH&S". After the import, you have the very same identifier in the system, but its data origin is changed to "EH&S". Correct? If so, what were your import settings, especially transfer parameter Spec. deletion type?

Further, SRSID is called at level ESTRH andESTRI and referenced on each property in the load file via entry $ESTVA-SRSID. That is standard behavior.

Ralph

[christoph_bergemann · Accepted solution]

Dear Ralph

in this case we executed an "additonal" load  Normally we do it like: first we extract the relevant identifiers then we add the data to the load file and just use the result for import.

As you know. to do so you must specify an identifier in the file. Normally atthetop of the file the "Data origin" is specified as "EH&S" (using +ID). We have rechecked the import file and found no entry like $ESTVA-SRSID. As per customizing the Default Data origin is as well "EH&S" this is a strange effect. Coming backl to your example (NAM EHS_OLD 😞

In the import file an identifer has been specified.  E.g. NAM EHS_OLD havion the value e.g. "SAP". The identifier seems to be identical in comparison with the value store on database level. Interesting is that regarding some of the examples by "error" we added an identifier. The reason is simple. IN this case the identifier in the file and the existing wasn't identical any more and because of "additional load" it has been inserted. This was the correct result, as the identifier wasn't present in databse. Regarding NAM EHS_OLD the strange effect happend that Data origin "EH&S" was updated to get "Space" Therefore as we are using this import very often we did a research. And we found very often identical behaviour. Personally i have only one "last" idea before we will start OSS dialog. May be you can provide feedback.

I am not "100%" sure that if the identifier in the system and in the file are only different by a "Space" (e.g. at the end of the identifier) that this effect may happen. In any case,. In change log in EHS there is no update on the ´value". Only this strange effect regarding change of SRSID. May be you could check this as well: during upload of regulatory data (which we are using as well) I found the same effect. Any identifier coming in the system does have the "Data Origin" "Space". This is "frustrating" as normally and INsert/ update etc. is done using the Defazlt value in Customizing "EH&S" And the strange thing is on value instance level the correct Data origin is used. This is only related to identifiers. I have no explanation.  So may be: if you have the chance to validate that using data provider if or if not e.g. an NUM or NAMs do have the data orgin "EH&S" or not.

C.B

[Ralph_P · Accepted solution]

Hi Christoph,

If SAP is the content provider, the identifiers come with a data origin; it shoud be "EH&S". I guess the same is true for other content providers, but I'm not sure. I am quite sure, though, that a space in the name of the data origin is interpreted by the system as a different source, thus the update.

If you get a blank for the Data origin during import, hve you checked whther this specific data origin is defined in customizing?

Ralph

[christoph_bergemann · Accepted solution]

Dear Ralph

first thanks for feedback. Regarding content provider: we need to check that on deeper level

Regarding import may be my explanation was not good enough.

Imagine this case:

you have a specification in the system there you would like to add e.g. denisity data.. To do so you need at least one identifier which you must nominate during the import. As long as this identifier is "identical" in system and in the file this identifier should not be "changed/effected" etc. and only the additional data should be loaded, This was the process we used. Now we detected that this seems not to be the real effect. The identifier as part of the file is "updated" in EH&S. In the example above somebody used this logic:

+BV   $ESTRI

SRSID                          EH&S

IDTYPE                         NAM

IDCAT                          EHS_OLD

IDENT                          XY0002

ORD                            0001

+EV

Nearly the same is used in our process. Only difference ist, that we do not define the "SRSID". The same is true for any other data in the file. SRSID is nether specified.

What is happing now:

e.g. the "density" data is added with SRSID "EH&S". This effect is "normal". As by default SRSID should be EH&S (as this is defined as such in customizing) and because of the fact that at the top the ID is es well "EH&S". In the system we have the "XY0002" having SRSID EH&S. By using now this upload approach the only difference afterwards is tht kin th systeM; XY0002 does get "blank" as SRSID (and there is no data origin "blank" defined. Up to today my unertsanding was clearly: no update should happen in the identifier. This seems not to be the case. Is my understanding here different? Or is this SRSID in the load file is really mandatory in ESTRI level to avoid this effect. I hope that you can provide some feedback regarding this.

C.B.

PS: referring to: Example: Transfer File for Specifications - Basic Data and Tools (EHS-BD) - SAP Library

The header of import file should look like:

Comment	+C	Administrative section
Character standard	+SC	ISO-R/3
Identification (database name)	+ID	IUCLID
Format version	+V	2.21
Export date	+D	19960304
Key date for export	+VD	19960304
Set languages for export	+SL	E
Date format	+DF	DD.MM.YYYY

IN our case +ID = EH&S (as this is the value in export file)

IN this example this additional one is shown:

Begin table	+BV	$ESTRI
Table field	IDTYPE		NAM
Table field	IDCAT		IUPAC
Table field	IDENT		anisole
Table field	LANGU		E
Table field	OWNID		ID1

Therefore no SRSID is specified. And this is the data in our file (on high level) and the "only" change is that the identifer get "deleted" the SRSID

[Ralph_P · Accepted solution]

Hi Christoph,

The SRSID is inserted automatically by the DataEditor, I think. You define it in Options, Tab "READ/WRITE in Data origin in the middle section.

As a result, the import file has the SRSID inserted automatically if you don't specify in the load file:

Maybe this information is helpful.

Ralph

[christoph_bergemann · Accepted solution]

Dear Ralph

it is quite to get some information about the DataEditor. But coming back to my question: why is the identifier in the system updated ? So that SRSID will change from "EH&S" to "Space". Is this SRSID information really needed in the import file? My assumption has always been: no. My interepretation has always been: if i do not specify somethinh in the import file then the "default" entry of customizing should be used. And as explained. We do not deifne any SRSId fo rthe density data; but here SRSID is EH&S which is the default. Additional feedback is really appreciated. It is well known the import is "tricky" and you need to pain really attention but I never expected such effects.

C.B.

[Ralph_P · Accepted solution]

Hi Christoph,

I should have been more clear, sorry about that.

So, there are two different entries in the dat-file we're talking about. One is at the top of the dat-file:

+ID   EH&S. This one is filled in by the the DataEditor, specified in Options-->Substance Import and there either directly in the fields you see or, if flagged, taken from the Beispielheader.ini file.

The other one is the SRSID you are talking about. Ths one is also automatically added to the dat-file by the DataEditor. DE is using the entry Data Origin in Options-->Read/Write, as I explained above.

I assume that the latter has no entry in your DE, so no SRSID is added to the dat-file. However, the identifier in the system does have the SRSID EH&S. By importing, you overwrite "EH&S" with "blank", which constitutes a change and is written onto the identifier in EH&S.

So please check the above mentioned two entries in your DataEditor.

Ralph

[christoph_bergemann · Accepted solution]

Dear Ralph

we will check this once again and changing may be our approach toload additional data to a specification. But I sorry that I need to drill down more here to avoid additional work on our side.

Let us use this example: You have

IDTYPE                         NAM

IDCAT                          EHS_OLD

IDENT                          XY0002

ORD                            0001

In the system as you sue this idnetifier as part of dat file.  Now the idenfier does have in most cases "SRSID" = "EH&S". Sometimes on the top my be an ownid might be assigned to the identifier. I would like to use two scenarios:

Scenario 1:

1.) as long as "IDENT" content in database matches content of dat file

2.) as long as ORD content in data base matches content of dat file

3.) as long as SRSID content in data base mateched content of dat file

4.) Ownid: content "irrelevanT"

no update will happen in database

Scenario 2

1.) as long as "IDENT" content in database matches content of dat file

2.) as long as ORD content in data base matches content of dat file

3.) as long as SRSID content in data base matches content of dat file

4.) as long as OWNID content in data based matches content of dat file

no update will happen in database

So which scenario is the right to make sure that no !" update happnes fo rthe identifier?

Second topic: according to help.sap.com during the export only the "OWNID" seems to be exported and not the SRSID? Is this correct? If this might be true we need to "redsign" our approach.

C.B:

[Ralph_P · Accepted solution]

Hi Christoph,

the Admin info of an identifier displays the field "data origin", which corresponds, in the DE, to the entry Options--> Read/Write and there the field "Data Origin" and in the dat-file it's the entry SRSID. I don't know what you mean by OWNID.

So the dat-file must have in the entries SRSID, IDTYPE, IDCAT, and IDENT the same values as are in the system. About the sequencing order (ORD in the dat-file) I'm not sure whether that is taken as a difference.

I'm also not sure what happens i,f though the above is given, you have a different entry in DE in the field Options-->Substance Import, field ID.

On top of things said above, of course the option during import play an important role, but I'm sure you have taken that into account already.

So, apart from my not understanding OWNID, I'd say that your scenario 2 shouldn't update the identifier if the import options in CG33 are correctly chosen.

Ralph

[christoph_bergemann · Accepted solution]

Dear Ralph

thanks for your last feedback. I have closed now this thread. We will "play" around a little bit so that the identifier is not updated any more based on your input. May be somebody could enhance the "help.sap.com" help regarding this (astructur of data file; what is "updated" based on parameter in import etc.)  information to make clear what e.g. "additional load does mean" and how you can avoid "updates" in database which are not needed.

C.B.

PS: thanks for once again sharing some inside in how DataEditor is "organized"/"designed" to do the load of data.