Using specification for GDSN attributes?

[former_member561828]

We are planning to participate in Global Data Synchronization Network (GDSN).  For that additional master data must be defined and managed.

SAP does not provide standard solutions for this requirement.

We use EHSM for GLM and other functions.  We therefore have substances defined for materials.

We envision expanding the property tree to include GDSN related attributes which define the related material assigned.  Custom programs will be used to report the attributes as required.  The GDSN attributes are not required or related to GLM or other typical EHSM functions.

My question - would it be inappropriate or incorrect to use the specification database in this manner?  What would be the pro/con of this usage we need to be aware of?

[christoph_bergemann · Accepted solution]

Dear Richard

I googled a little bit to get an idea about GDSN: Nether heard about that before. In any case:

Regarding:

My question - would it be inappropriate or incorrect to use the specification database in this manner?  What would be the pro/con of this usage we need to be aware of?

After cross read about GDSN my answer is: yes you can use EHS classic; but may be you could use e.g. material classes

It is only a defintion of matter. If you have the feeling that

a.) there is a material relationsship

b.) we have attributes as "denisty" etc. to be maintained on spec level

you can do what you would like to do with EHS; SAP is only delivering a "STANDARD" tree (as "Best practise"; it is quitecommon to add further VATs or to use own developped property trees etc. : EHS can be extended without any risk; you could e.g. then use on top output variants, WWI layouts etc.; you could then execute inquiries in SAP EHS using normal technique. Recommendation from my side would be: generate a"new property tree without any relation to STANDARD (but this depends a littblebit on overlap of data etc.)

C.B

[former_member561828 · Accepted solution]

Thank you for this reply and you feedback.  We are consider Specification and other approaches.  I want other SAP user opinion on this approach.

[christoph_bergemann · Accepted solution]

Dear Richard

I googled only very short. First impression is: seems to be "nearly" on levle of so called eClass as shown here: http://www.eclass.de/

May be explain to the audience the scenario you are thinking about. In most case which I know about: it is a data transfer form third party system to SAP system using siome "identifier"; this approach is used to a certain extent as well in OCC etc.

So main question is: do you would liek to get data and store that in SAP or need to to consider the othere way around as well that means you would lioke to dispatch data from SAP to other party (which is quite common in the SAP world and therefore many solutions exists)

C.B.

[former_member561828 · Accepted solution]

You are correct in that GSDN is about transfer of information, primarily salable product information, between systems (from manufacturers to customers and also to regulatory bodies such as FDA).

In our case, we manufacture and therefore will be sourcing data from our SAP system outward to data pools for use by customers and regulatory bodies.

So we have must of the data in standard SAP master data (materials) but other attributes are GDSN unique and there is no standard solutions (today) to sources data in SAP.

For MM we might use Class.  But we are also sourcing some GLM/specification data to GDSN.  So including some additional there makes for a uniform database.  Also for extract limiting number for source data limits development.

I see eclass as industry solution.  However, many regulatory bodies for medical devices are now driving standards that must be met.

[christoph_bergemann · Accepted solution]

Dear Richard

e.g. SAP EHS MANAGEMENT is used to push to others data from MSDS/SDS etc.

E.g. IMDS Customer and Supplier Collaboration - SAP Product and REACH Compliance - SAP Library

shows one example. In the area of REACH a lot fo more examples can ge listed. ASs well there is a "IUCLIDE" interface etc.

A lot of regulations, industry bodies require exchange of data; e.g. check:

So as long as the data is related to "EHS" (and does have some material significance) EHS is a good option to store the data and to use SAP EHS Management as the "source" for exchange the data wirth 3rd parties. A lot of IT solutions a possible. most common is the scenario SAPERP( with EHS) => SPA XI/PI => External software; other options arepossible as well.

What are the pros of using EHS?

a.) you can easily enhance EHS so that the data can be stored

b.) you can perform data loads in EHS (unsing IMport, OCC or Data Editor option)

c.) you can use EHS easily for inquiries on the data stored

d.) you can print the data in WWI reports

e.) you can share the data using options as mentioned above

The use of material classes is "limited" here

From my point of view:

You can store data in material classes

You can do uploads (using SAP standards but on the same level as with EHS)

You can exchange the data

You can proint the data using Smartform and other classic ABAP feature as well may be use Adobe integration

The "inquiry" to the data is possible as well but limited

In most cases: if you analyze data relevance for EHS > 90% of the data to be shared can be classified as "EHS" data.

At the end it is a company decision which solution you would like to use.

C.B.