on ‎2018 Dec 11 2:49 AM
We have a requirement to utilise attributes on InfoObjects to derive information for calculations (e.g. An attribute on /ERP/GL_ACCT to determine the settlement account for each GL account). However, in BPC Optimized all InfoObjects delivered from SAP are populated from SAP HANA Views so there is no data replication.
We understand that you can extend the SAP delivered InfoObjects to include new attributes, and have these populated from SAP HANA Views. However, the values of these attributes cannot be maintained by business users. We also understand that you are able to create provisional master data in BPC Optimised through the use of a Z InfoObject (which is maintainable), then modify the underlying HANA views to join the S/4HANA master data with the Z InfoObject master data. This approach is fine for creating new members that don't exist in S/4HANA, however this approach won't work for maintaining attributes on existing S/4HANA master data. This issue, although the example has been given for /ERP/GL_ACCT, is present for all /ERP/* InfoObjects in BPC Optimised.
Can anyone please advise is they have come across this scenario before or know of SAPs recommended approach?
Request clarification before answering.
Hi Kieran,
if your main use case is to extent existing S4 master data with new attributes you can also replace B with a BW DSO, call it D. Then D contains S as key and your new attributes A1, A2 ,... as characteristics in the data part. You expose these characteristics as key figures 1KYF_A1, ... (feature characteristics as key figures), create an aggregation level on top of D and an input-ready query. This then allows to maintain the attributes in the DSO D, you have all features of a BW query to control valid values of S, A1, A2 ,... i.e. it is not possible to create new values s of characteristic S in the query.
Since I am from BW it is easy to suggest BW techniques; since master data belong to S4 in your use case a real extensibility concept would have to be in S4 maybe with support of master data maintenance using other client tools.
Regards,
Gregor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Kieran,
to my knowledge there is not recommended approach for your kind of scenario. But from your description it seems that you know the how to paper
https://archive.sap.com/documents/docs/DOC-59000
and the basic idea used there might be extended to your use case. The basic idea is to use a BW characteristic B that 'extends' the S4 characteristic S and exposes a union B UNION S has HANA view on the BW side. You might extend this idea as follows:
J1 := B INNER-JOIN S
C1 := COMPLEMENT of J1 with respect to S
U:= J1 UNION S
and then expose U as HANA view based characteristic (of course the text table has to be considered there as well). This is more or less what BW does in BW workspaces with local characteristics in local InfoProvider.
Using this approach you can allow master data maintenance of B using the BPC AdminClient.
Regards,
Gregor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gregor,
Thank you for the response. I understand your solution and agree the basic idea of provisional master data can be extended in my case. However, my concern is that when a user maintains attributes in BW Characteristic B, they will need to create the same master data ID in BW Characteristic B as the S4 Characteristic S, so the underlying HANA view join conditions work. For example;
- User wishes to update the attribute of Cost Center 12345
- They navigate to the BPC Web Client and open BW Characteristic ZCOST_CTR
- They now need to create Cost Center 12345 in ZCOST_CTR before they can maintain the provisional attribute value, so the underlying HANA view can join the S4 Cost Center master data with the BW Cost Center master data
This method exposes the risk of users potentially creating the incorrect Cost Center ID in ZCOST_CTR and causing issues. Another thought is to load ZCOST_CTR from S4 to avoid the need to maintain master data IDs, however this means persisting master data in a solution where virtual integration is key.
| User | Count |
|---|---|
| 41 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.