Issue found in EHS in using specification data import using process

Question

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:
spec import_inheritance data
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

Answer 1

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