Currently a very high interest seems to exists how OCC can be used for “data load purposes”. This document is intended to refer to “Threads” discussing OCC and to generate a kind of “FAQ”: how to use OCC properly.
Currently the interest focus on “normal data” upload (e.g. density, flashpoint, composition data etc.) and not on “regulatory content” upload. For regulatory content upload and related stuff: may be check: https://blogs.sap.com/2014/11/13/rule-sets-secondary-data-determination/.
SAP documentation is providing fact as: “The EH&S OCC needs a TXT file format to import data.”
I believe this part of the document should be improved. Reason
1.) tool is intended to load “phrase” context
2.) tool is intended to load “identifier” and data in “User Defined Text”
3.) Therefore: We do not talk (in most cases) about an “ASCII” related TXT file
In both cases: there is a good chance that we talk about “UNICODE” related characters as most of SAP installations are now operating in “UNICODE” mode.
Therefore. you should read this more like: use a “suitable” tool (e.g. EXCEL, WordPad etc.) to prepare the data. Make sure that the data is correct (UNICODE option !).
PLEASE READ CHAPTER 6.2.1 of OCC document. Content can be very helpful.
For specification import you can use “Offline” and “Online” modus.
For Offline: the tool create a “dat” file to be loaded using SAP Standard import
For Online: the tool directly pass the data to EHS (using BAPI interface) and the data will be created direct.
EHS Specification Standard import
It is a very good idea to first read once again the SAP Help for Standard Import of Specifications. You will understand hopefully much easier than how OCC is “working” and why you need to specify this “many” data in the load file.
What is the difference in real life? It depends a little bit on what you would like to “load”. This data can (according to my knowledge) only be loaded in online mode:
Data referring to tables as: CCUNT*
Regarding “Status”: I am not sure, if offline modus supports that
Regarding “Restriction”: I am not sure, if offline modus supports that
As discussed in some thread: the “Online” modus has some risks. The Offline modus is much stricter in checking the “data” as part of dat file. For Offline: You can always do a “test load”(without the need to “load”).
KEEP IN MIND: ONLINE IS ONLINE ! Do not use to “big load files”. You might get “time out” error (depending on set up of your SAP system) after some time.
Specification Header is defined via Table ESTRH. If you look on the examples provided in OCC document: The “keys” used in TXT file are equal the “technical” definition of the fields of the table. E.g:
|SUBID||Specification key||Yes||If you do not specify key: system will create new spec|
|AUTHGRP||Authorization Group||Yes||If you would like to create new spec key. Fields is mandatory. If you would like to “update”. you don’t need it|
|REM||Note||No||KEEP IN MIND: REM does have only some characters. There is no “check” in your “TXT” file if the “data” exceeds the length of this field|
If you would like to learn how to use OCC properly (and to understand structure of load file) it is a very good idea to first play “around” only with data related to ESTRH.
Technically: The “Restriction” is designed like: System uses ESTDU table in reference to ESTRH table. Therefore:
For load purposes: you need a “spec key” (if you do not provide it: system will generate the spec). One example of load file content is provided in OCC document.
If needed you can
a.) generate the specification
b.) and assign material numbers
in one run. Material assignments are handled in ESTMJ (with reference to ESTRH).
Most important fields in the table:
To assign materials using OCC you will need spec key. You can assign more than one material in one run. No examples are provided in OCC document.
You can populate as well “Reference” Tab using OCC. Here story is as: ESTRR is linked to ESTRH table. So you can “upload” in one run more than one “reference” to the same spec key.
Most important fields in the table according OCC docu:
Most interesting fields to consider:
The handling of identifiers is “more complex” as specification header. The reason is:
a.) an identifier can have zero, one or more than one usage assigned (Relation of ESTRH => ESTRI => ESTDU). On top: you can use “exclusion flag” as well (for validity area)
b.) an identifier can have zero, one or more “Regulatory Lists” assigned (Relation ESTRH => ESTRI => ESTRL)
In many cases: SAP system is set up like. any “identifer” (which is created using CG02) will get “default” usages. In such a case you need “only” to list the “identifier” in the load file. But you must accept then the “default usages” (pay attention: the same can be true for properties. If you do not defined “usage” per data record you might get “only” default usages; this might be un unwished result).
It can happen that you need to “assign” Regulatory lists to an identifier. Some examples can be found in OCC document. Just play around with load file to get the “wished” result.
You will find lot of examples for identifier stuff in OCC document. Therefore: preparing load files in context of “identifiers” can help you quite fast to understand how to prepare load files.
The usage is defined via table “ESTDU”. Therefore for load file we have these fields which could be used (with parameter U:)
You will find examples in OCC document for “Usage” load. You will find example sin context of “identifier” and data record in property.
PS: No idea what will happen if you do not “Specify” active flag in load file. If there is no “special” EHS Set up: I would assume: data record is loaded “in active”. But if you have done proper EHS setup i would assume that “.dat” file or online mode is acting the same: therefore data record will be active.
For Relevance flag: there is no similar EHS set up option. So if you need “relevance indicator” you have to specify it in load file.
Data upload in properties/Value assignment types
This is now the “complex” world ! How to prepare the “load file” properly depends on structure of property.
As discussed in many threads: as a first step: Try to upload only data in one property in one run. This reduces “complexity” (how to prepare the load file correct) and you can improve load file more easily (if needed).
E.g. we can have: Property of type “A” (Class based), “B”; (Specification Listing), “C” (Composition), and the “Dangerous Goods” properties (e.g. Transport Classification, Dangerous Goods Additional Data, Hazard Inducing Substances).
On top: you will find properties with a “Combination” (A + B or A + C).
Try to look for the “simplest” property you can think of (e.g. Odor, Form) and try to prepare a load file. Using this approach you will gain quite fast knowlegde how to use “Phrases”. If possible: Check for one “Characteristic” in which you only assign one phrase. This can as well simplify the content of the load file.
You should then “add” complexity step by step. E.g.”State of Matter”. Here you have characteristics with relation to an “UOM”. Try to upload e.g. three data records for one spec (one for solid, one for liquid, and last for gas). This will be a challenge (may be) but you will learn quite fast how to prepare load files so that you can generate in one property more than one data record in one run and how to use characteristic having relation to an “UOM”.
What do we now need to start using OCC?
first we need to specify the “property of interest” (ESTVH)
Then we need to define: which data record to upload (Table ESTVA) as we can have more than one data record present (e.g. example: density)
Then we need to understand “property” design (type of property). For “normal” property you do not need “ESTVP” data
We need to understand “Characteristic” structure if property is of type “A”
If you would like to upload compositions: don’t forget to specify “COMPREL” data in your file. KEEP IN MIND the limitations of “Average”, “Lower” and “Upper” limit (digit length !). If needed add “operators” (as >, <, etc.). Always specify an “UOM” per line of component (%, %0, etc.)
If you would like to load “Specification listing data”: do not specify “COMPREL” or other data related to a “composition”
But you can define “Source” data (ESTDS) and “Assessment” data (ESTDR) to upload as well as “Usage” data (ESTDU) and “Userdefined Text” data (ESTDF). In most cases “Source” and “Assessment” data can be ignored
You can upload in “User Defined Text” as well reference to a “DMS” document
Then you need to check: is the property “very” special (dangerous goods related). Take care to properly specify the “load file”. In the first run: this might be not an easy task
READ CAREFULLY THE OCC DOCUMENT: if you would like to use more than one “Data record” per subid; You need only to specify “once” the SUBID. And then in subsequent rows you can list the data to load. Here especially in the area of “identifiers” you will find some good examples in OCC document => for properties. MAKE SURE THAT YOU TAKE CARE ESTVA entries in your load file
Property load Detail
In OCC document examples are show for “numeric characteristic” with UOM. Details are not provided. Some experiments might be needed therefore. E.g. Density. in OCC document simply examples provided as: “0,79 g/cm^3”. But how to “specify” the “^3” might be tricky. There: in such cases I would assume: the best is: extract first EHS data using standard EHS export. Check how such values are “formatted” and then just use the same “format” for EXCEL file preparation. As this “^2” or “^3” is often part of an “UOM”: Just try it… Same for “°C”.
Phrase related data can only be loaded using “offline” option and SAP EHS Standard import option.
You can create new phrases, update text, code etc. or you can update the “phrase set” assignment as well. Some examples of load files are listed in OCC document.
To generate a “Dat” file for phrase upload manully can be a “nightmare”. So here OCC is really a useful tool (as it accepcts table oriented TXT files as input)
Links to current discussion on OCC