Hi Abdullah,
In which entity do we have the header information of CR? Is there any document related to this?
Thanks and regards,
Rama
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
Dear Ram,
please refer to the below link might help you.
↧
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
Hi Shankar,
Thank you for the details. The link talks about making a particular field in the CR header mandatory. I am looking at creating BRF+ rules based on Reason Code in the header of MDG CR. Please advise if there is a option.
Regards,
Rama
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
Dear Ram,
Please define the reason in the below path
Change Requests->Define Reasons for Change Requests
and then call the reason in the decision table that should work.
If you want to create the rules for validation and derivation then you have to create the data object in the BRF+ rules and call the same,not sure will this work because the validation and rule are defined on Data model.
double check what you want to achive,because I think you can control the WF as mention above.
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
Hi Shiva,
We already have a reason code. We cannot include them in the Data Model as these fields Change Request Type and Reason Code are MDG specific only and they do not exist in ECC.
I think we will have to go for customization and a logic will have to be built to check the correctness of material group.
Thank you.
Regards,
Rama
↧
↧
Re: BRF Plus rules based on MDG Change Request Type or Reason Code
In your validation application, expand the "Data Object" folder. There you will find CR header fields listed individually. Keep in mind that you need to assign them to the signature of your validation function in order for them to get any values assigned to them.
↧
Re: SAP MDG - Integration Approach
I disagree with you saying "the best approach is...". You can't have a one-size-fit-all approach with these projects. Every implementation is different and every MDG consultant has to weigh in all the different questions and make a decision that works for each specific instance.
↧
Re: SAP MDG - Integration Approach
Thank you Abdullah & Kiran for your inputs,
Below is our situation with respect to Abdullah's questions,
- Is there an already established interface between the existing ECC and the other target systems?
Ans: There are some scattered existing systems & interfaces. BUT, for the sake of simplicity, we want to assume, this as brand new landscape with MDG HUB & few other new systems like ECC, SRM, CRM , etc.
- What is the system of truth in the eyes of those target system? Is it going to be the new MDG hub or is it the established ECC system?
Ans: New MDG HUB & new ECC.
- Do you need to send data other than master data to those target systems?
Ans: Non-Master data would be handled using ECC.
- Is the whole landscape new? Do you even really want to implement MDG on a hub instead of co-deploying it on the existing ECC instance?
Ans: Lets go with whole landscape as new. we want to implement MDG on HUB.
- Is data distribution to those target systems a point-to-point or through a middleware or PI? Is the MDG hub already familiar with the middleware or is there extra effort needed?
Ans: mostly it would be point-to-point using out of box functionalities.
@Kiran,
i am in bit confusion, if you considered my second option
"Option2: MDG HUB feeding all master data to ECC & ECC distributing directly to other systems[ECC, CRM, SRM, SCM, etc]". before recommending. pls confirm.
@both,
we are mostly tilting towards MDG HUB distributing data directly to all SAP & Non-SAP systems.
But, we want to get good justification & want to make sure, it is the best practice across market in a similar situation of ours.
Please provide your thoughts accordingly.
Also, please provide few pros & cons for both the options, from integration persepective. Thx for all the help.
↧
MDG-S Customer Vendor Integration Error
Customer Vendor Integration :
Hi All,
While I am performing the configurations for Customer Vendor Integration - MDG-S in MDG 7.0 SP2 , I am stuck at the below place :
While in the step of "Activate Creation of Postprocessing Orders", when I add an entry for the Component AP-MD and Business Process is either CVI_02 and CVI_04, I get an error "Specify the key within the work area".
And it does not allow me to proceed further.
I maintained the necessary configuration in SPRO and the configurations are visible in the table below , but are not reflecting in MDG:
But are not reflected in MDG :
Did anybody face a similar issue during the configurations of the CVI ?
Please help.
I found a similar issue, but that too is unanswered. (Unable to set up Customer-Vendor Integration for MDG-C)
Please suggest.
↧
↧
Re: BRFplus MDG chanStatus 05 of Change Request
Dear Shankar,
You are describing the customizing, but that's not the issue.
Have a look into the attachment there you can see all the created status. At the end of the CR (process patern 99=Complete) I'm expecting any other CR status but not 05=Final Check Approved. The reason for this issue is that after process patern 06=activation (in my case condition alias 6+7) always status 05 will be set.
↧
Re: BRFplus MDG chanStatus 05 of Change Request
Dear Guen,
What is the status you want to see,you can achive this by assining the status to Condition alias step after activation.
Add one more step to close the CR.
↧
Re: BRFplus MDG chanStatus 05 of Change Request
Status 05 and 06 are hard-coded so you can't set them using configuration. You should still put them in the configuration for completeness sake. However, the values you set in the configuration table will be ignored by the activation method.
↧
Re: BRFplus MDG chanStatus 05 of Change Request
What is the purpose of you wanting to change the status from 05 to something else? Is it just the text? If so, you should be able to use a different variable than the status. One idea is to enhance the CR header to insert something like "custom status" that you can set in a BAdI or even in the CR header feeder class. Then, use this custom status field in your e-mail instead of the standard status field. Also, you can build your e-mail notification method to retrieve text from a custom table or a custom BRF+ application that takes the standard status and CR type and returns a text associated with that step.
In any case, if you want to change the status upon activation from 05 to something else (something I don't recommend), you can trace where usmd0_cs_crequest_status-finally_approved (and finally_rejected) is used and then enhance the corresponding methods using implicit enhancements. You will find this constant in type group USMD0 in transaction SE11.
↧
↧
Re: How to make an attribute visible on MDG Screen, hidden in genIL layer.
You should refer to other discussions where you got this from.
↧
Re: How to make an attribute visible on MDG Screen, hidden in genIL layer.
You need to enhance the BUPA GenIL model and assign a new handler class for the node you want to enhance. This new handler class should be a child of the original handler. In this child class, redefine the get_attributes_properties method to enable the fields you want.
↧
Re: Possibility to use multiple BADI in one Custom Change request Type with rule based workflow
Did you try? Did it not work?
↧
Re: SAP MDG - Integration Approach
Hi Sanjay,
Thank you for the link.
SAP Recommendation document mostly talks about Deployment/Database Architecture topics.
it mentions less on MDG Integration Approach options.
please let me know, if there is any other SAP recommendation document providing insight on MDG Integration details. Thx.
↧
↧
Re: Performance Issue in NWBC Material 6.1
Hi Subhronath,
Can you elaborate a little on the database buffer changes? Are these just database buffer parameter changes or did you adjust some database table buffering. Can you please confirm and provide some more details on the changes?
Appreciate your help
Thank you
D
↧
Re: Possibility to use multiple BADI in one Custom Change request Type with rule based workflow
Hi Sanjay,
Yes you can use multiple Badi in you rule-based workflow ...
Thanks
Nikhilesh
↧
Re: Possibility to use multiple BADI in one Custom Change request Type with rule based workflow
Hi Abdullah
Where to assign different service names used for both the BADI's in BRF+.?
In CR Type Releasted Service Name it seems that one can assign single service name only.
What is use of Service name column in Non agent decesion table and Dynamic agent service selection column in Single value decesion table?
↧