Rule set - Fundamentals - 46C ECC6 Upgrade impact

Hi,
Am on CC 4.0 FF3.0, SP 12
1.Am I right to say that the rule set contains objects /tcds ?
2. During the upgrde from 46C to ECC6.0 many objects are present, how much is the impact if I use the same rule set as 46C on ECC6 ?
3. Do I really need to change the rule set now or can i defer it - to a date when i get to the GRC 53?
Thanks

Hi George,
Please find my response below:
1.Am I right to say that the rule set contains objects /tcds ? Yes. Rule set contains all the rules which in turn contains combinations of objects and tcodes which poses risks.
2. During the upgrde from 46C to ECC6.0 many objects are present, how much is the impact if I use the same rule set as 46C on ECC6 ? The same rule set will work but it won't have all the new tcodes or objects.
3. Do I really need to change the rule set now or can i defer it - to a date when i get to the GRC 53? *As long as you don't use new tcodes/objects from ECC, it should be fine. If you have to follow SOX then your auditors might not agree with thi
Regards,
Alpesh

Similar Messages

46C- ECC6 upgrade with EHP4 SAP_BASIS package not found

We are executing an upgrade from 46C to ECC6 SR3 and binding in EHP4.
We have successfully downloaded EHP4 using Solution Manager MOPZ and
provided the generated "XML" file during the PREPARE.
During the phase EHP_INCLUSION, PREPARE is stopping with a message "No
matching SAINT package for 'SAP_BASIS' found".
The KB70102.SAR and KB70103.SAR packages from EHP4 have definitely been unpacked
and are available in /usr/sap/trans/EPS/in and we have prompted PREPARE to search EPS/in but it just returns to the previous error after searching.
It appears from the logs that the upgrade is expecting a "SAINT"
install package for SAP_BASIS and does not consider the KB70102/3
patches as acceptable?
Any clues as to why PREPARE is not accepting the SAP_BASIS packages and looking for a SAINT install?
Below is an excerpt from the EHP_INCLUSION.LOG
2 ETQ732 Package descriptions uploaded successfully
4 ETQ399 Looking for SAINT package for 'SAP_BASIS' ...
4 ETQ399 ... Read uploaded packages calling function module:
4 ETQ399      current: name = 'SAP_BASIS', release = '700'
4 ETQ399      patch type = 'U', ncvers-component = 'SAP_BASIS'
4 ETQ399 R3upReadNewPackages:
4 ETQ399   patchType='U', langVect='DEFS'
4 ETQ359 RFC Login to: System="CB1", Nr="00", GwHost="dbusrcb1", GwService="sapgw00"
4 ETQ232 RFC Login succeeded
4 ETQ233 Calling function module "spda_read_new_packages" by RFC
4 ETQ399   ismovesVersion='0'
4 ETQ399 R3upReadNewPackages: exit: rc=0
4 ETQ399 ... No matching package found.
Regards,
Mike Tarr

Ok, I was able to download the K-701DHINSAPBASIS package from Service Marketplace and this resolved the SAP_BASIS problem. Thank you Markus for this solution.
I also downloaded the SAP_ABA, SAP_BW, and the PI_BASIS components and unpacked those as well in /usr/sap/trans/EPS/in.    My upgrade is now stuck asking for a SAINT package for SAP_ABA! I'm sure the SAP_ABA install, K-701DHINSAPABA, is unpacked and available in /usr/sap/trans/EPS/in.
The SAP_ABA files are definitely readable and there are entries in table PAT03_SDA for them.
I have a ticket open with SAP support but they have not had a solution yet for the SAP_ABA
Solution Manager failed to identify any of these packages as required in MOPZ.
I'm starting to wonder if anybody has ever done a 4.6C to ECC6 upgrade with EHP4 bound before?
Any ideas on the SAP_ABA would be appreciated. Here's a section of the EHP_INCLUSION.LOG file from PREPARE.
4 ETQ399 R3upReadNewPackages: exit: rc=0
4 ETQ399      Found: name = 'SAP_BASIS', release = '701', package = 'SAPK-701DHINSAPBASIS'
4 ETQ399 ... Matching package found: 'SAP_BASIS','701','SAPK-701DHINSAPBASIS'
4 ETQ399 (trc) R3upPatchDisassembleQueue: 1 package queue entries
4 ETQ399 (trc) R3upPatchDisassembleQueue: force=NO
4 ETQ399 (trc) R3upPatchDisassembleQueue: 0 packages will be disassembled
4 ETQ399 ... ... INST/UPG SAINT decision ok
4 ETQ399 ... EhP component SAP_ABA, 701
4 ETQ399 Looking for SAINT package for 'SAP_ABA' ...
4 ETQ399 ... Read uploaded packages calling function module:
4 ETQ399      current: name = 'SAP_ABA', release = '700'
4 ETQ399      patch type = 'U', ncvers-component = 'SAP_ABA'
4 ETQ399 R3upReadNewPackages:
4 ETQ399   patchType='U', langVect='DEFS'
4 ETQ359 RFC Login to: System="CB1", Nr="00", GwHost="dbusrcb1", GwService="sapgw00"
4 ETQ232 RFC Login succeeded
4 ETQ233 Calling function module "spda_read_new_packages" by RFC
4 ETQ399   ismovesVersion='0'
4 ETQ399 R3upReadNewPackages: exit: rc=0
4 ETQ399 ... No matching package found.
4 ETQ010 Date & Time: 20090511150018

GRC Upgrade 4.7 to 5.3 - Rule Set Upload

Questions about upgrade from 4.7 to 5.3
Work in corporate conglomerate that consists of 4 independent business units each with own SOD rule set:
u2022How do we upload each independent set of rule sets so they can coexist within GRC 5.3?
u20224.7 mapping of files to 5.3 naming conventions u2013 see 4.7 rule set download below
CONFIG
CR_PROFS
CR_PROFST
CR_ROLES
CR_ROLEST
CR_TRANS
CR_TRANST
SOD_OBECT01
SOD_OBECT02
SOD_OBECT03
SOD_OBECTT
SOD_TCODE
SOD_TCODET

Alpesh
We are trying to upload our existing SOD 4.7 rules using the 5.3 the configuration tab u2013 rule upload. We are having difficulties associating old 4.7 SOD files names to the 5.3 SOD file names. Is this the correct location within 5.3 to associate a physical system to a specific set of SOD rule sets? If not could you please point us to correct location within 5.3.
Thanks

Multiple rule sets - impacts in GRC modules

Hi,
We are currently running CC 5.2 on our European perimeter. We would like to extend in the near future to our US perimeter. For that, we have to take into consideration a complete new set of rules.
I presume there will be no issue to handle multiple sets of rules in CC but I was wondering what could be the potential impacts/problems for the other GRC modules?
i.e.: in Role Expert, for the US roles we would like to avoid getting potential risks from European rule sets,...
Has anybody some attention points or good practice to share on that ? It would be a great help for us.
Thanks & Regards

Different installation of GRC Solutions for different regions is certainly not recommended and not even required. It is important to design your cross system landscape efficiently considering different regions in mind and create different rule sets for different regions. In a cross system landscape you can have multiple systems from different regions with entirely a different set of modules and data. Obviously the risk will be different, for that purpose you have to create different rule sets for sure.
Now when you are performing risk analysis for a particular region you have to select the considered system/connector and a rule set respectively so that you get the risks on targeted system only.
Bill-
as you asked, if there are chances of potential impacts/problems for the other GRC modules or not,
The answer is, There will be no impact at all because you are considering them as separate entities within a landscape. It is the beauty of GRC Access Controls to have multiple system connectors, logical systems and cross system landscape that provides almost every feature to cover all regional perimeters.
Regards,
Amol Bharti

Do you trust the SAP standard rule set ?

Hello all,
I have the impression that, too often, the SAP standard ruleset has been taken for granted : upload, generate and use. Here is a post as to why not to do so. Hopefuly, this will generate a interesting discussion.
As I have previously stated in other threads, you should be very careful accepting the SAP standard rule set without reviewing it first. Before accepting it, you should ensure that your specific SAP environment has been reflected in the functions. The 2 following questions deal with this topic :
1. what is your SAP release ? ---> 46C is different than ECC 6.0 in terms of permissions to be included in the function permission tab. With every SAP release, new authorization objects are linked to SAP standard tcodes. Subsequently some AUTHORITY-CHECK statements have been adapted in the ABAP behind the transaction code. So, other authorizations need to provided from an implementation point of view (PFCG). And thus, from an audit perspective (GRC-CC), other settings are due when filtering users' access rights in search for who can do what in SAP.
2. what are your customizing settings and master data settings ? --> depending on these answers you will have to (de)activate certain permissions in your functions. Eg. are authorization groups for posting periods, business areas, material types, ... being used ? If this is not required in the SAP system and if activated in SAP GRC function, then you filter down your results too hard, thereby leaving certain users out of the audit report while in reality they can actually execute the corresponding SAP functionality --> risk for false negatives !
Do not forget that the SAP standard ruleset is only an import of SU24 settings of - probably - a Walldorf system. That's the reason SAP states that the delivered rule set is a starting point.
So, the best practice is :
a. collect SAP specific settings per connector in a separate 'questionnaire' document, preferably structured in a database
b. reflect these answers per function per connector per action per permission by correctly (de)activating the corresponding permissions for all affected functions
You can imagine that this is a time-consuming process due to the amount of work and the slow interaction with the Java web-based GRC GUI. Therefore, it is a quite cumbersome and at times error-prone activity ...... That is, in case you would decide to implement your questionnaire answers manually. There are of course software providers on the market that can develop and maintain your functions in an off-line application and generate your rule set so that you can upload it directly in SAP GRC. In this example such software providers are particularly interesting, because your questionnaire answers are structurally stored and reflected in the functions. Any change now or in the future can be mass-reflected in all (hundreds / thousands of) corresponding permissions in the functions. Time-saving and consistent !
Is this questionnaire really necessary ? Can't I just activate all permissions in every function ? Certainly not, because that would - and here is the main problem - filter too much users out of your audit results because the filter is too stringent. This practice would lead too false negatives, something that auditors do not like.
Can't I just update all my functions based on my particular SU24 settings ? (by the way, if you don't know what SU24 settings are, than ask your role administrator. He/she should know. ) Yes, if you think they are on target, yes you can by deleting all VIRSA_CC_FUNCPRM entries from the Rules.txt export of the SAP standard rule set, re-upload, go for every function into change mode so that the new permissions are imported based on your SU24 settings. Also, very cumbersome and with the absolute condition that you SU24 are maintained excellent.
Why is that so important ? Imagine F_BKPF_GSB the auth object to check on auth groups on business areas within accounting documents. Most role administrator will leave this object on Check/Maintain in the SU24 settings. This means that the object will be imported in the role when - for example - FB01 has been added in the menu. But the role administrator inactivates the object in the role. Still no problem, because user doesn't need it, since auth groups on business areas are not being used. However, having this SU24 will result in an activated F_BKPF_GSB permission in your GRC function. So, SAP GRC will filter down on those users who have F_BKPF_GSB, which will lead to false negatives.
Haven't you noticed that SAP has deactivated quite a lot of permissions, including F_BKPF_GSB ? Now, you see why. But they go too far at times and even incorrect. Example : go ahead and look deeper into function AP02. There, you will see for FB01 that two permissions have been activated. F_BKPF_BEK and F_BKPF_KOA. The very basic authorizations needed to be able to post FI document are F_BKPF_BUK and F_BKPF_KOA. That's F_BKPF_BUK .... not F_BKPF_BEK. They have made a mistake here. F_BKPF_BEK is an optional auth object (as with F_BKPF_GSB) to check on vendor account auth groups.
Again, the message is : be very critical when looking at the SAP standard rule set. So, test thoroughly. And if your not sure, leave the job to a specialized firm.
Success !
Sam

Sam and everyone,
Sam brings up some good points on the delivered ruleset. Please keep in mind; however, that SAP has always stated that the delivered ruleset is a starting point. This is brought up in sap note 986996     Best Practice for SAP CC Rules and Risks. I completely agree with him that no company should just use the supplied rules without doing a full evaluation of their risk and control environment.
I'll try to address each area that Sam brings up:
1. Regarding the issue with differences of auth objects between versions, the SAP delivered rulset is not meant to be version specific. We therefore provide rules with the lowest common denominator when it comes to auth object settings.
The rules were created on a 4.6c system, with the exception of transactions that only exist in higher versions.
The underlying assumption is that we want to ensure the rules do not have any false negatives. This means that we purposely activate the fewest auth objects required in order to execute the transaction.
If new or different auth object settings come into play in the higher releases and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these auth objects to the rules.
Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported.
2. For the customizing settings, as per above, we strive to deliver rules that are base level rules that are applicable for everyone. This is why we deliver only the core auth objects in our rules and not all. A example is ME21N.
If you look at SU24 in an ECC6 system, ME21N has 4 auth objects set as check/maintain. However, in the rules we only enable one of the object, M_BEST_BSA. This is to prevent false negatives.
3. Sam is absolutely right that the delivered auth object settings for FB01 have a mistake. The correct auth object should be F_BKPF_BUK and not F_BKPF_BEK. This was a manual error on my part. I've added this to a listing to correct in future versions of the rules.
4. Since late 2006, 4 updates have been made to the rules to correct known issues as well as expand the ruleset as needed. See the sap notes below as well as posting Compliance Calibrator - Q2 2008 Rule Update from July 22.
1083611 Compliance Calibrator Rule Update Q3 2007
1061380 Compliance Calibrator Rule Update Q2 2006
1035070 Compliance Calibrator Rule Update Q1 2007
1173980 Risk Analysis and Remediation Rule Update Q2 2008
5. SAP is constantly working to improve our rulesets as we know there are areas where the rules can be improved. See my earlier post called Request for participants for an Access Control Rule mini-council from January 28, 2008. A rule mini-council is in place and I welcome anyone who is interested in joining to contact me at the information provided in that post.
6. Finally, the document on the BPX location below has a good overview of how companies should review the rules and customize them to their control and risk environment:
https://www.sdn.sap.com/irj/sdn/bpx-grc
Under Key Topics - Access Control; choose document below:
    o GRC Access Control - Access Risk Management Guide   (PDF 268 KB)
The access risk management guide helps you set up and implement risk
identification and remediation with GRC Access Control.

For GRC 5.3 can I use the SAP GRC 5.2 rule set

We are going for an upgrade to GRC 5.3, I have a small concern here....
Can I use the same ruleset what I used in GRC 5.2 to SAP GRC5.3 ...?
because when I checked ruleset at permission level in GRC 5.2 it displays first object of an action from one function conflicting with first object of an action from another function, where as in GRC 5.3 it displays all objects of an action from one function vs all objects of an action from another function....
How will it impact analysis in GRC 5.3 with old rule set...?
appreciate your response & thanks in advance.

Hi,
Here you will find the documentation to get Upgrade/Configuration Guides.
[https://websmp103.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000718172&]
SAP BusinessObjects Governance --> Access Control ---> SAP GRC Access Control 5.3
There you will find a Upgrade guideline.
Cheers,
Martin

ECC upgrade impact on data archival

Friends,
We are working on the data archival SAP version 4.7, parallely ECC upgrades activities are going on. We are working on the archive tools like transactions SARA, SARI etc as part of archiving. Not sure on what changes to the features will be available in the ECC6.0 version and its impact on already archived files. Can somebody give some inputs/direction?
thanks
Nalinikanth.

Hi,
Retrieval of Archived data
1. SAP system support to retrieve data archived from 4.7 system by ECC system. There is no negative impact in retrieving archived data of deferent version in ECC system.
Advice to take back ups of Field catalog, Archive infostructure in case it is Custom or any additional field added to standard structure.
2. Some changes in Archive index is there in ECC system -
In ECC system, if you want to retrieve archived data from FB03 then activate and fill the Archive infostructure, Archive build index will not work.
This method remains same for Material document and other documents
In ECC system SAP recommends to use Archive system instead of building archive index table such as ARIX_BKPF...
Archive Program
1. All the BC sets to upgrade archiving process are been implemented in ECC system, so you can see some changes in the Write program, Delete program.. or for some archiving object you may also see addition of preprocessing program..
For example: MM_EKKO in initial released 4.7 version didn't had preprocessing job, Write job variant had option of company code to archive purchase order. Later BC set was released with upgraded programs with Preprocessing program and in Write variant with selection of Purchase organization instead of Company code.
If you have already implemented latest release of BC sets then in ECC 6.0 will not have any changes otherwise some minor changes you can see.
Please specify which archiving object with program you are concern with.
Store Function
1. In ECC system, SAP has filled up a long standing gap of storing archived data of different company code in separate content repository. This is very much useful when you want to store the archived data of different organization units in different storage repository. This also easy to get rid of data that has completed total retention period from the storage system.
Remain other functionality remains the same. Please let me know if you have any concern about archiving object that you are using.
-Thanks,
Ajay

Best practice for the Update of SAP GRC CC Rule Set

Hi GRC experts,
We have in a CC production system a SoD matrix that we would like to modified extensively. Basically by activating many permissions.
Which is a best practice for accomplish our goal?
Many thanks in advance. Best regards,
Imanol

Hi Simon and Amir
My name is Connie and I work at Accenture GRC practice (and a colleague of Imanolu2019s). I have been reading this thread and I would like to ask you a question that is related to this topic. We have a case where a Global Rule Set u201CLogic Systemu201D and we may also require to create a Specific Rule Set. Is there a document (from SAP or from best practices) that indicate the potential impact (regarding risk analysis, system performance, process execution time, etc) caused by implementing both type of rule sets in a production environment? Are there any special considerations to be aware? Have you ever implemented this type of scenario?
I would really appreciate your help and if you could point me to specific documentation could be of great assistance. Thanks in advance and best regards,
Connie

GRC 10.0 : Maximum number of Rule Sets

Hi Experts,
What is the maximum number of rule sets we can define in GRC 10.0?
What could be the impact on performance if we defined a dozen of different rule sets?
Best Regards,
Nicolas

Hi,
In theory, you can have as many rulesets as you wish in the GRC 10 world. However, you rightly point out that there will be a substantial performance impact.
The number of rulesets is not really the key element here but the number of risks and rules defined within them will be.
If you know that you wish to manage a significant number of separate rulesets, be sure to spec them out accordingly and make use of the connector groups to rationalise the content as far as possible (e.g. group similar elements like Basis or systems together). You will also need to size the GRC system appropriately with a basis SME so that you can review the system performance appropriately.
Simon

Deployment Rule Set broken with Java 7u55

Hello!
I'm using Deployment Rule Set in my company environment, its signed by code signing certificate that is given out by internal CA. After I upgraded to Java 7u55, the Deployment Rule Set does not recognize older statically installed Java version.
Versions I have:
7u45 - install directory: C:\Program Files\Java\jre1.7.0_45
7u51 - install directory: C:\Program Files\Java\jre1.7.0_51
7u55 - install directory: C:\Program Files\Java\jre1.7.0_55 or C:\Program Files\Java\jre7\ - neither does not work
When I go to site described in Ruleset and that has to use Java 7u45, then I receive an message "Deployment Rule Set required Java version 1.7.0_45 not available. In the same way it doesn't recognize 1.7.0.51 or even Java version 6.
When I uninstall Java 7u55, everthing works fine again.
My ruleset looks like this:
<ruleset version="1.0+">
     <rule>
          <id location="first.site.com" />
          <action permission="run" version="1.7.0_45" />
     </rule>
     <rule>
          <id location="second.site.com" />
          <action permission="run" version="1.7.0_51" />
     </rule>
     <rule
          <id />
          <action permission="default" />
     </rule>
</ruleset>
Anyone knows what's wrong or is it a bug?

costlow - I disagree. If I'm using IE, then I only need the internal certficate used to sign the jar to be also insalled on the machine in question in the windows CA Certs store. If the cert was the issue, why does it work with 7u51. If it was a bad cert, it should fail with every version. Plus, I think the pop up has a different error message if it has a cert issue.
I'm having the exact same issue as the OP described and it all started with 7u55. Here's what I've found:
- With 7u55 or 7u60 installed, the error will come up rergardless of what prior version is being requested.
- If 7u51 is the latest installed, it works
- If 8u05 is installed with 7u55 and/or 7u60, it works
- If I install the 7u60 EA b15, it works
Something in the final release is being added that blocks this functionality, but for some odd reason only in the 7 family starting with 7u55.
Any insight you could give would be very helpful. In the meantime, I am deploying 8u05 to cover this up, but it does pose issues for some apps that don't work with the new 8 family plugin.

How to migrate Master Data (Rule set etc.) from GRC 5.3 to 10.1 without using the "Migration Tool"

Greetings,
We are currently on GRC 5.3 SP 18 (Java ONLY) and migrating to GRC 10.1. I referred the Migration Guide which outlines that GRC 5.3 needs to be upgraded to SP 20 as pre-requisite for using the "Migration Tool" . Our BASIS team is reluctant to perform this upgrade from SP 18 to SP 20.
Having said thus, I'm exploring options of migrating data from 5.3 to 10.1 without using the "Migration Tool:.
Rule set Migration:
I'm in the process of preparing the 9 different files (listed below) and later utilize the "Upload Rule" option for migrating the Rule set data from 5.3 to 10.1.
While I'm able to gather data for most of the files I'm not sure how can I obtain the data pertaining to the two files (Function Actions and Function Permissions) underlined and highlighted in Red below.
1. Business Process
2. Function
3. Function Business Process
4. Function Actions
5 .Function Permissions
6. Rule Set
7. Risk
8. Risk Description
9. Risk Rule Set Relationship
10. Risk Owner Relationship
Can someone please enlighten me and share their experience with regards to this exercise. Really appreciate your help !
- Janantik.

I have done this successfully before. Because you are having issues, I would NOT recommend using the migration tool to move the ruleset. Instead:
1. Download the ruleset files from 5.3
2. The 5.3 tcode-permission file, which defines which tcode permissions from SU24 need to be checked during risk analysis, needs to be split into the two files you mention above in red.
FUNCTION_ACTION : this file represents S_TCODE objects and TCD fields mapped to each function (Function to Tcode relationship). In the 5.3 file, you will filter on object S_TCODE and field TCD, and you will get a complete list that now represents "FUNCTION_ACTION". BUT instead of having all the jumbled permission info, you will just have 3 columns: Function - Tcode - Status.
3. The remaining permissions that are left over, after taking out the S_TCODE -TCD items, represent the "FUNCTION_PERMISSION" file in GRC 10.
4. Manually create the excel spreadsheets for each file.
5. Copy and past each sheet to a unique .txt file.
6. Upload the ruleset manually through SPRO-->GRC-->Access Control-->Access Risk Analysis-->SoD Rules-->Upload SoD Rules.
7. Select each file and then upload to the correct Logical Group.
This is a huge pain, but it works. Let me know how this goes and if you need any assistance.
-Ken

CC / RAR 5.2 - Multiple Rule Set Question

How does the system handle the use of multiple rule sets in CC / RAR 5.2?
For example, letu2019s say I want to keep a standard SAP rule set in tact to use for testing and comparison in RAR, but I also want to load another one.
I realize that only 1 can be the u201CDEFAULTu201D so what does that mean? I know that a risk analysis is only run against the rule set you set as default. I also know that you can select the rule set to use in processing when you manually run either through Informer or Configuration tab a risk analysis. What I am really concerned with is what happens if you take the results to u201Cmanagement reportsu201D from 2 different rule sets?
First, can you even do it?
Second, if you can, then I think you must have to come up with a different RISKID configuration schema for each rule set otherwise, I do not see how you can differentiate from which rule set the violation is generated. That said, you will also need to export the report information into Excel and make any u201Crule set sortu201D there as I donu2019t see a way to do it directly in RARu2026.maybe a future improvement?
Can anyone confirm the impact of multiple rule sets and how you manage them?
Regards,
Greg

Greg,
You can maintain the different severity levels for different Rule Sets. For example, in one Rule Set you can keep the "Critical" Risks and in other you can keep "High", "Medium" & "Low". Run your analysis against first Rule Set if you want to know the "Critical" Risks and second Rule set you can use for rest of the severity levels. I hope this way you can manage your multiple Rule Sets in RAR.
Thanks,
Tavi
SAP Security & GRC Consultant.

Non existing value EC for M_BEST_BSA / BSART used in rule set

Hello,
while implementing the 2010 rule set updates into our system, we realized that there is a value used that is not existing in the system.
It is for object M_BEST_BSA, field BSART. The value is EC.
In the rule update document from Q2 2010, there is the following comment:
5. PR02 u2013 Maintain Purchase Order u2013 Upon review of this function with the rules mini-council, the decision was made to remove document type from the rules. Previously, we delivered document types EC, FO and NB with our rules. However, the majority of customers create custom document types for purchasing. Many customers did not customize the rules, which results in only those users that had the standard EC, FO and NB document types being reported as having a risk. Users who had the custom document types would not be reported, which results in false negative reporting. Therefore, the decision was made to remove document type from our delivered rules. This will force each customer to review their document types and edit this function to include all relevant document types so all users who have a risk are shown.
However the value is still enabled in function PR04, even though it is not a valid value for field BSART. It is not existin in table T161, which holds the PO document types. It does not seem to exist since at least release 4.6C
The value is inherited from the transactions ME28 and ME29N
Does anyone know what it is about and why the value still is considered a standard value?
I know this does not give me false conflicts, as the BSART values are used in condition OR.
Why is the value not just removed, if it is not a valid value at all?
edit:
Sorry, forgot to mention, we use CC4.0 in an ECC6.0 system
end of edit:
Regards,
Thomas Schaeflein
IBM
Edited by: Thomas Schaeflein on Jan 26, 2011 4:14 PM

Start by saying bump.
I've still no word from Adobe if they are doing anything with
this problem. Any one had any replys from Adobe on it? Any one
found a work around with recoding queries?

A simple problem? - cannot grant create rule set

Hi,
Can anyone spot the stupid mistake i'm obviously making when trying to grant create rule set to my streams admin user? The script was working last week?!
BEGIN
DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(
privilege => DBMS_RULE_ADM.CREATE_RULE_SET_OBJ,
grantee => 'strmadmin',
grant_option => FALSE);
END;
ERROR at line 1:
ORA-00931: missing identifier
ORA-24000: invalid value , USER/ROLE should be of the form [SCHEMA.]NAME
ORA-06512: at "SYS.DBMS_RULE_ADM", line 167
ORA-06512: at line 2
Many thanks,
Warren

Yes, catpatch.sql is necessary only for existing 9.2.0.1 databases upgraded to 9.2.0.2.
I am assuming that when you created the database under 9.2.0.2 that catalog.sql and
catproc.sql were run. The next step, I guess, is to turn on sql tracing to see
which sql statement actually fails when you run the command. Turn on sql tracing
with the following command, and then execute the procedure again.
alter session set sql_trace=true;

Rule set/mitigation control tables backups

I am working in GRC AC 5.3 with old SPs. How can I take backup of existing rule set and mitigation controls so that I can compare those after GRC AC SP upgrade. Please guide me in detail.

You can download the ruleset via rule architect -> utilities -> export and mitigation via mitigation -> utilities -> export.
Regards,
Alpesh

Rule set - Fundamentals - 46C ECC6 Upgrade impact

Similar Messages

Maybe you are looking for