Substance Volume Tracking based on the Manufacturing plant

[satya11719]

Hello All ,

I was working on s4 substance volume tracking EXP scenario set up and i found that Substance Volume tracking & blocking is working based on the Sales Organization and Legal entity assigned to the Sales organization, this is standard behavior and we would expect system to track based on the Manfacturing plant in the Sales order or delivery.

For Example : We have business scenario where Canada (CA) is the Manufacturing plant and CH(Switzerland) is the Sales Organization and Goods will ship to the Ship to Party (PO - Poland) which inside the REACH.

Now the Tracking & Blocking is working based on Sales org and Legal entity assigned to it CH, which is wrong.

We would expect system to track based on Manufacturing plant Canada (CA) , Cause we have direct assignment of plant and legal entity company code via T001K table and Manufacturing plant Canada (CA) assigned to the Singapore (SG) legal entity.

We would expect system should track & block under the Singapore (SG) legal entity.

We found a custom way of doing this by modifying the Standard FM's CBRC_SO_DATA_SEP other FM, But it would be lot of enhancement.

I would like to check here, is there any standard way of acheiving this ? Cause most of the business models will work in similar way. Please write if you come across any requirement like this acheived in standard way.

Thanks

Satya

[christoph_bergemann]

Dear Satya

if you check the SAP online help and the "SVT" part you will see a "legal sentence" from SAP.

Sentence from SAP help (https://help.sap.com/viewer/8a399f5444164440ac4f426e847ec901/6.17.17/en-US/d6cdc253d0a4b54ce10000000...😞

"SAP emphasizes that this component is only an example for the tracking of substance volumes. SAP does not therefore guarantee that the functions delivered comply with specific regulations such as the European Parliament and Council Regulation on the Registration, Evaluation, and Authorization of Chemicals (REACH)."

The whole SVT part is delivered to us customers as an "idea" how you can solve the topic.

Luckily: by SAP standard we can change/extend etc. the process easily

Regarding your statement;

"We found a custom way of doing this by modifying the Standard FM's CBRC_SO_DATA_SEP other FM, But it would be lot of enhancement."

You should NOT do it like that but make a "copy" of CBRC_SO_DATA_SEP to a FM in your "namespace" and adjust the code according to your needs.

So more or less: you have identified one (of the many) limitations in SVT; If you stick still to use "SVT"., you have no other chance then the "copy" of the FMs to an own one.

C.B.

PS: we have now some "BADIs" on place in the process. Check if you can use these to solve your demand. In this case. may be you can still use CBRC_SO_DATA_SEP and you avoid the "copy"

[satya11719]

Hello CB,

I meant to say copying the Standard FM and creating custom FM's which will fulfill our purposes.

Thanks

Satya

[christoph_bergemann]

Dear Satya

coming back to your statement

"We found a custom way of doing this by modifying the Standard FM's CBRC_SO_DATA_SEP other FM, But it would be lot of enhancement."

What is your definition of "lot"?? According to my experience: yes you need to change code (copy SAP FM to customer FM and adjust code) and logic and yes you need to test etc. But for the "code" part... it should not be more than 5 man days.

Keep in mind,. SVT is now in place since roughly 10 years; still if you check SAP marketplace: from time to time SAP delivers code corrections etc.

So the use of a "customer FM" is the one clear option but ! you can than not profit from any improvements which will be delivered by SAP in the future

My suggestion would be: check the "BADIs"...(which are part of the used FMs) these "are" part of the code; the use of the BADis is clearly "custom code oriented" and you may be still can use the frame work of CBRC_SO_DATA_SEP and you can profit then from code corrections via OSS notes.

C.B.

PS: for they many limitatios of SVT: check my SVT blog (e.g. japanese calendar year) and SAP marektplace.. not all of the limitations in SVT are "clearly" listed in the many OSS notes.. but luckily: we have these OSS notes