SVT - what about data from non SAP systems

[Former Member]

Hi all,

We're investigating to implement SVT.

Unfortunately, the system landscape is not only within SAP systems.

Data are transferred to the SVT tables using function modules that can be defined in customizing. I would suppose that it is possible to create new function modules that read data from outside the normal SAP transaction tables.

Does someone has experience with this requirement and can give some hints on how to solve it?

Or does any know that this requirement is simply not possible to implement

Kind regards,

Luk

[christoph_bergemann]

Hello Luk

interesting approach/demand you have. I never have had a similar demand in the past:

First of all: you need to understand the "primary customizing of EH&S SVT and how it interacts with the tracking job. Then you need to define the approach in the different systems which should fit in some sense to EH&S. Furtheron you should consider if you will only "read" the data on the fly from system B or if you would try to store some data from system B in EHS SVT of system A.

In any case: there are a number of major topics you need to consider in my opinion:

1.) You need to understand the basic approach of EH&S SVT (customzing in combination with function modules)

2.) You need to understand how CBRC20 works to display data

3.) You may be need to consider if or if not you would like to block orders or if you are planing to integrate GTS

Now coming back to 1./2./3.:

If we talk about REACh in most cases you perform "once" a day the tracking. In the tracking you have scenarios. These scenarios are supported by the customizing and the use of the function modules you have mentioned; but to my knowledge "main" driver (selection criteria) of SVT is the customizinig and the function modules act on top. Therefore it is not easy to "combine" two systems in SVT. If you read carefully SVT documentation some scenarios are out of scope. e.g. a company is not allowed to be used in two different ERP system. Further on the SVT supports two basic scenarios: the "planing" and the "goods movement". A am not sure how you woulk like to combine this if the are talking about a SAP / Non SAP scenario.

That means the system retrieves planned data and make it available in CBRC20 etc. Once again this is done using "basic" SAP customizing (plant,. company code etc.).

Now it is not clear to me what do you mean by your statement:

"the system landscape is not only within SAP systems"; if you have different systems to consider (one SAp and one Non SAP): I believe the effort is not worth to try it to prepare a solution.

If we are talking about only SAP systems: yes there are solutions available in my opinion which will fit into SVT. In theory you can exchange the function modules in such a way that they would read data from system A and from system B (using RFC) but I have some doubt that you will be able to make the same selection in system B based on customizing in system A or if you try to do that my assumption you will "reprogram" SVT in some sense.

Coming back to topic 2.) There are a number of options to enhance/change CBRC20 which can be implemented in such a way that it is no modification. From SAP approach: normally you would read data from SAP tables and would show them but in priinciple you can enlarge / change CBRC20 but you will "loose" a number of options or you must takle care about these options in CBRC20

Regarding 3:) I believe if you plan to "block" orders or to integrate GTS in SVT you should not try to link a SAP and a non SAP system. If you try to link two or more SAP systems: In my opinion a better approach to use is to track in system A and to track in system B and the user must log on to both sysetm to get an idea about issues. This is a "much" simpler approach as to try to use the function modules. In reality somebody would like to understand: what is going on in system B"; why does it track this or what..

Conclusion: in most cases if two SAP systems are in scope it is much better to implement EH&S SVT twice and to try to combine the data "later" (if necessary)

With best regards

C.B.

Edited by: Christoph Bergemann on Sep 16, 2011 2:04 PM

Edited by: Christoph Bergemann on Sep 16, 2011 2:04 PM

Edited by: Christoph Bergemann on Sep 16, 2011 2:05 PM

Edited by: Christoph Bergemann on Sep 16, 2011 2:06 PM

[Former Member]

Hi Christoph,

Thank you for your extensive reaction again.

We've also checked with SAP.

They mention the solution I propose will work. They recommend however to only take into account the confirmed quantities.

What we will do (I think) is the following:

• get external data in SAP Z-table (material, date, quantity, ...)

• combine data from Z-table with EH&S data and save entries in SVT tables (link with RS, tracked substances, ....)

You mentioned you would not invest much effort to implement this, when part of the data has to come from outside of SAP.

What solution would you propose to track the volumes?

Kind regards,

Luk

[christoph_bergemann]

Hello Luk

the reason why I have some doubt from business point of view (technically it will may be work) are:

0.) Regarding: They recommend however to only take into account the confirmed quantities. => feasible approach

The logic of the "external" system regarding confirmed quantiites should be "comparable" to SAP approach or you combine "wrong" numbers in cbrc20 etc.

1.) the "material" number of the external system must have a link to the material number in your SAP system. How will you deal with this link? (or more precisely: how will you arrange this: * get external data in SAP Z-table (material, date, quantity, ...)... and break down to tracked substance ..?

2.) If I understood correct you will try to link external material number to SAP material number and then try to do cascading ? etc. (* combine data from Z-table with EH&S data and save entries in SVT tables (link with RS, tracked substances, ....)); not an easy task

Because of other reasons we have analyzed the EH&S SVT program flow and we obtained similar results: To use Z Tables. But after some discussion with business the approach was not "feasible" enough from legal point of view and we stopped this activity.

Main reason: on the "Z Table" level you must prepare the Z tables in such a way that they do have "similar" field like company code, plant etc. so that you can use cbrc20.

Therefore you need a high number of relations between the "external" system logic and the SAP system. Therefore If I understood you correct the "external" system will live for a long time together with the SAP system. So changes in organisations (new plant) etc. must be always taken into account. In scenario "IMP" or "EXP" may be you will find solutions but "production" is very complex and to try to "map" the external system logic to SAP logic will not be easy (take into account: SVT does know two options: repetitive manufacturing and normal manufacturing). You need to analyse your external system logic so that it fits to SAP logic. A hard job.

With best regards

C.B.

PS: be aware of the fact that you can not do a "feasible" retracking in your approach; other SAP SVT options can not be applied too in my opinion (OR etc.) or it will be again a very hard work

PPS: How to track if non SAP System is involved: in principle other ERP systems have "similar" logics as SAP. They need "confirmed" quantities; they need "adreess" data (so that imp, exp can be detected). But to my knowlegde no other ERP solution provdes a link between "material" and "specification" (REAL_SUB). I have no idea to do the job. At the end many companies "tend" to try to use "BI/BW" (business intelligence; Business Warehouse) solutions to make the necessary analysis or to use EXCEL etc.

Further remark: as you may be know: actually there is a "trend" to implement REACH in many countries. Therefore the need of tracking will increase in my opinion. Furtheron similar demands exists to track something in US, CA, TR, JP etc. This might be a further reason not to invest to much money in combining SAP and Non SAP systems to get tracking results.

Edited by: Christoph Bergemann on Sep 20, 2011 10:00 AM

Edited by: Christoph Bergemann on Sep 20, 2011 10:01 AM

Edited by: Christoph Bergemann on Sep 20, 2011 10:02 AM

Edited by: Christoph Bergemann on Sep 20, 2011 10:05 AM