GRC Badi GRFN_MSMP REQUEST_FINISHED

Alguien tiene experiencia con el
BADI GRFN_MSMP REQUEST_FINISHED ES
Necesito implementar esta badi para ejecutar una transacción en el otro sistema una vez que termine una solicitud en GRC AC.

Hi,
I translated your question via google as follows:
"Anyone have experience with
BADI GRFN_MSMP REQUEST_FINISHED ES
I need to implement this badi to execute a transaction on another system once you finish an application GRC AC"
Personally no, but someone else may have.

Similar Messages

ECC EHP7 is necessary for NFe3.10?

Hello,
we are using ECC EHP6SP6 and we need to know if we should to migrated to ECC EHP7 in order to use new GRC BADI which one is recommended for Tax Declaration Framework ( we still not use TDF) , we are starting NFe 3.10 project next Monday 07.21.2014.
Thanks and regards,
Fernanda

Respondendo a sua pergunta.
Não é necessário você aplicar o EHP7 para fazer uso da badi "nova" para tratar a persistência dos dados. Veja a nota: 1860433 - NF-e: Storing Additional Data for DANFE & Reporting
* observe que foram liberadas diversas notas alterando essa badi.
Quanto ao TDF.. veja a nota 1923804 - Release Information Note: SAP Tax Declaration Framework for Brazil 1.0
Porém observe que o uso da badi nova J_1BNF_ADD_DATA não é requerido para implementação do layout 3.10.
Abraço
Eduardo Chagas

DEVOLUÇÃO DE EXPORTAÇÃO - CFOP 3201 - GRC VALIDA DADOS DI.

Boa tarde a todos!
Estamos em um projeto de NFE XML 2.00 e nos deparamos com o seguinte erro:
Ao emitirmos um NF-e de devolução da mercadoria que se encontrava no Porto (devolução de exportação - CFOP 3201), a validação do monitor GRC informa que é necessário constar os dados de importação, apesar deste processo não se tratar de importação. Os seguintes logs de validação são gerados:
Erro de validação: campo Código do fabricante estrangeiro no sistema. Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_ADI-CFABRICANTE, ID campo I028)
Erro de validação: campo Nº da adição. Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_ADI-NADICAO, ID campo I026)
Erro de validação: campo Nº sequencial do artigo na adição. Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_ADI-NSEQADIC, ID campo I027)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-CEXPORTADOR, ID campo I024)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-DDESEMB, ID campo I023)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-DDI, ID campo I020)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-NDI, ID campo I019)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-UFDESEMB, ID campo I022)
Erro de validação: campo . Campo é obrigatório e não pode ficar em branco. (campo IT_NFE_IMP-XLOCDESEMB, ID campo I021)
Estamos no SAPK-10015INSLLNFE e as seguintes notas relacionadas a validação estão aplicadas:
1493980     Validation for field xJust in cancel and skipping messages
1499921     Problem with validation after implementing SP15
1500046     Upgrade validation rule for field ID for version 2.00
1500742     Adjust validation for field NADICAO and NSEQADIC layout 2.00
1502217     Extend validation rules for , layout 2
1504379     Adjust validation for field X_CLISTSERV
1511291     Update allowed values for field E1_CPAIS for validation
1511577     Update validation rules for field VUNCOM_V20
1520861     Update validation rules for OIL_CPRODANP and OIL_UFCONS
Não encontrei nenhuma nota SAP recente para o componente SLL-NFE que seja relacionada a este problema.
Desde já agradeço pela ajuda.
Sds / Renato Penido.

Boa tarde, Fernando,
Obrigado pela pronta resposta.
Debugamos a BADI e descobrimos que os dados de importação estão sendo gravado "em branco", gerando o erro de validação no GRC, tal qual dito por você.
Aprimoramos a lógica da BADI para que a tag de importação não seja preenchida indevidamente para as notas de devolução do porto e as notas foram aprovadas.
Muito obrigado,
Renato Penido.

Ativar SCAN com solução de mensageria não GRC

Pessoal bom dia,
Estou em um projeto e o cliente deseja utilizar a contingência da NF-e com o SCAN, porém a mensageria é uma solução de mercado, não é o GRC. Vocês sabem o que fazer para ativar o SCAN quando a mensageria não é o GRC. A comunicação entre o SAP e a solução de mensageria ocorre, no envio, por arquivos texto. Somente o retorno para o SAP ocorre por RFC.
Qualquer dica será bem vinda, desde já agradeço!
Assis Medeiros

Olá a todos!
Nossa instalação tenta combinar o SAP ERP com a mensageria não ERP. Na verdade nem sempre combinam bem, mas dá samba. Para funcionar o SCAN, conforme a dica do Fernando, aplicamos a seguinte solução:
Ao assinalar o campo u201CDeterm.aut.servd.u201D no Local de Negócio (customizing), o SAP automaticamente consultará se é SEFAZ ou SCAN que está ativo, através do método GET_SERVER da implementação da BAdI CL_NFE_PRINT
Neste método, a tabela CT_SERVER_CHECK contem os campos SEFAZ_ACTIVE e SCAN_ACTIVE. Apenas um destes campos de ser assinalado com X. Para cada campo o SAP definirá o formulário a ser utilizado ao fazer a numeração da Nfe, se para SEFAZ ou SCAN, conforme customizing.
Dentro do método GET_SERVER pode-se consultar uma tabela Z que indica quem está ativo, se SCAN ou SEFAZ, assinalando o campo correspondente da tabela CT_SERVER_CHECK.
Uma alternativa automática para saber qual serviço está ativo é consumir via PI o WS do Sefaz que indica o serviço que está ativo.
Valeu Fernando.
Espero ajudar quem está passando por aqui.
Abçs
Heron Caetano
www.hcaetano.blogspot.com

GRC Inbound - setar step POASSIGN manualmente

Bom dia Pessoal,
Preciso de uma ajuda, alguém sabe se é possível setar o step POASSIGN do GRC Inbound para Definido como OK manualmente?
Pergunto isso porque a solução aqui do projeto é que alguns passos do processo que o GRC faz sejam feitos por um desenvolvimento ABAP no ECC,que irá gerar uma série de workflows para áreas responsáveis em caso de erro..
Exatamente isso:
Para compras normais:
1.SIGNATUR (Auto)
Checagem da assinatura (EXECUTADO PELO GRC)
2.AUTHORIZ (Auto)
Checagem da autorização na SEFAZ (EXECUTADO PELO GRC)
3.NPURVALD (Auto)
Validação de processo normal (EXECUTADO PELO GRC)
4.POASSIGN (Auto) (NESSE MOMENTO HÁ INTEGRAÇÃO ENTRE GRCxECC PARA QUE O STEP SEJA EXECUTADO PELO DESENVOLVIMENTO ABAP NO ECC)
Associação do pedido ao XML
5.NFESIMUL (TAMBÉM EXECUTADO PELO DESENVOLVIMENTO ABAP NO ECC)
Simulação da nota
6.DELCREAT (Auto) (TAMBÉM EXECUTADO PELO DESENVOLVIMENTO ABAP NO ECC E APÓS OK, RETORNA UM STATUS AO GRC QUE OS 3 PASSOS FORAM EXECUTADOS COM SUCESSO, NESSE MOMENTO OS 3 PASSOS POASSIGN, NFESIMUL E DELCREAT DEVEM SER SETADOS OK MANUALMENTE NO GRC PARA DAR SEGUIMENTO NO PROCESSO, PORÉM LOGO NO PRIMEIRO PASSO POASSIGN JA NÃO FOI POSSIVEL SETA-LO, APARENTEMENTE ELE OBRIGA QUE ENTRE COM UM NR. DE PEDIDO PARA A ATRIBUIÇÃO, É ISSO MESMO?)
Pensei em usar o processo flexível FLEXPR01, porém afetaria os passos do monitor logístico que estão contemplados no processo normal,(GRCONFQU,.GRFICHCK e GRMMCHCK)
Há alguma outra saída?
Obrigado pela ajuda,
DANIEL

Olá Eduardo,
Desculpe pela demora em dar um feedback.
Atualizando a questão, acabamos por adotar o processo Flexível mesmo, deixando a parte de verificações de quantidade a cargo do sistema ABAP aqui da integração.
Respondendo suas perguntas
porque destes desenvolvimentos?
O cliente decidiu adquirir uma ferramenta desenvolvida em ABAP que irá controlar os passos que citei e gerar Workflows para as áreas responsáveis em caso de erros, esse seria o motivo principal dessa solução.
O que vocês irão fazer? Como irão fazer?
Iremos utilizar como ponto da integração as BADIs flexíveis, método before_danfe para o momento de atrib. de pedido até a geração da inbound delivery. e método after_danfe após a entrada da chave de acesso até a geração da MIRO
Obrigado pela ajuda,
Daniel

[GRC Inbound]Criação da remessa atualizar a identificacao do transporte

Bom dia a todos!
Gostaria de pedir, por favor, se alguém já precisou atualizar a identificação do transporte (LIKP-TRAID) na criação da remessa a partir do GRC Inbound utilizando a tag <placa> do xml de entrada (layout 3.10), se sim, há alguma BADi que permite isso?
Eu implementei a BADi 'Determination of Custom UI for Logistics Workplace for Inbound NF-es' conforme SAP note 2038967. No entanto, nesse momento a ordem de fornecimento já está criada e eu preciso que seja atribuído a placa do veiculo na criação da remessa, porque o veiculo precisa da ordem de descarga (impressa automaticamente) que segue o veiculo até o ponto de descarga e nesse doc. é obrigatório a placa.
Obrigada.
Patrícia

Boa tarde Patricia,
Pelo standard não tem como, já que a informação da placa não é repassada para o ECC no momento da criação da Inbound Delivery no ECC. O que pode ser feito é:
Cenário 1: Você criaria a Inbound Delivery antes da execução do step DELCREAT do GRC (via implicit enhancement-point no começo da função /XNFE/PROCSTEP_NFE_DELCREAT c/ uma chamada RFC p/ o ECC, fazendo a criação via BAPI/FM), já com os dados da placa (TRAID), como se fosse um processo externo criando a Delivery e implementaria a BAdI J_1BNFE_IN método INBOUND_DELIV_SEARCH, para indicar que neste passo a Delivery já foi criada e que o número dela é X;
Cenário 2: Você implementaria um implicit enhancement point na função /XNFE/PROCSTEP_NFE_DELCREAT, no final do módulo de função, chamando uma RFC Z do ECC, que seria a responsável por fazer a atualização da Inbound Delivery com o TRAID. Como não achei BAPI que fizesse a atualização da inbound delivery com os campos necessários, sugiro ou utilizar um BATCH INPUT ou o não recomendado update na likp.
[]'s
JN

SAP SP necessária para suportar os componentes para o SAP GRC NFE 1.0 no XI

oi,
Como estamos atualizando as nossas caixas de XI de SAP XI SAP PI 3.0 para 7,11, verificando o SLD notamos que Nota Fiscal componente de software está disponível. Assim, a pergunta é o que é que os Service Packs do sistema fonte precisa ter, a fim de fornecer todos os componentes necessários para a NF-e?
temos dois sistemas de fonte da qual enviamos os dados para XI, você pode sugerir o que é o pacote de serviços adequados para apoiar SAP GRC NFE 1.0 no XI
1> 6,0 SAP ECC, SP, 14
EHP 2, Nível 2
PI_Basis = 2005_1_700, Level 14
ST = PI 2008_1_700 Nível 2
2> 6,0 SAP ECC, EHP 4
Muito obrigado

Ola, vi o seu e-mail mas resolvi responder por aqui!
Na realidade, se voce for realmente trabalhar com o GRC, dependendo da secretaria da fazenda que voce ira trabalhar aconselhor que voce aplique o sp15 no grc, consule SAP Note 1487119, nessa nota haverao todos os procedimentos necessarios.
Como haviamos falado anteriormente por e-mail, seria necessario, caso vc realmente queira trabalhar com o GRC a aplicacao de algumas notas tecnicas no proprio GRC.
1477834     XML Layout Version 2.00: Missing parameters in NF-e BAdI
1487119     SAPK-10015INSLLNFE: Support Package 15 for SLL-NFE
1496216     Rejection of NFe because of wrong data type of date fields
1499921     Problem with validation after implementing SP15
1498700     Problem on signing NF-e
1497767     Fill field qTrib for new layout version 2.0
1500046     Upgrade validation rule for field ID for version 2.0
1500742     Adjust validation for field NADICAO and NSEQADIC layout 2.00
1501545     Problems in trying to see a XML in the IE
1502612     Select the NFe Status Check Service for Incoming B2B message
1502217     Extend validation rules for <DI>/<adi>, layout 2.00
Sem mais, precisando me mais ajuda avise

SAP GRC NFE 10.0 - Outbound B2B

Pessoal, estou tendo um problema no envio de e-mail através do GRC. Procurei no fórum mas não encontrei nada que me ajudasse, por isso vou tentar detalhar o máximo.
A implementação foi baseada nesse artigo:
http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=315524420
Meu problema agora está na URL do canal de comunicação. Tentei utilizar smtp://nomedoservidor, como no artigo, mas houveram vários erros, entre eles, um que haviam vários tópicos sobre ele:
server not responding OK to AUTH; 535 5.7.3 Authentication unsuccessful
Aqui nós utilizamos o Exchange 2010 SP3, e ontem o responsável por ele fez vários testes, até não conseguirmos fazer mais nada e ele abrir um chamado com a Microsoft. Tentamos de tudo (segundo eles), e no final o pessoal da Microsft sugeriu que fosse aberto um chamado na SAP...
Não entendo de Exchange, mas disseram que liberaram tudo no Relay:
Após isso, fizemos um teste no canal de comunicação utilizando a URL imap://servidor. Tentei com autenticação, sem autenticação... todas formas possíveis e imagináveis que essa configuração permitia...
Sem nome de pasta alguma, ocorre o seguinte erro:
unexpected append response; read 001I BAD Command Argument Error.
Por último, criei uma pasta Teste dentro desse e-mail, e alterei a URL para imap://servidor/Teste
Finalmente o e-mail (pelo menos) ia para a pasta criada dentro desse e-mail:
Bom... não faço mais ideia do que eu poderia testar. Tentei colocar algo como /SENT, /OUTBOX para ver se esse e-mail ia para a caixa de saída do Exchange, mas nada...
Alguém tem alguma idéia/sugestão do que eu possa fazer?
At.,

Bom dia, Ricardo
Obrigado pelas sugestões. Conseguimos resolver depois que o responsável pelo Exchange fez mais algumas liberações, mas, também havia um erro na nossa classe java... Nossa constante com o nome do e-mail from, estava com um ";" :
private final String NFe_Mail = "[email protected];";
Feito isso, tudo deu certo.
(detalhe, só depois de rolar uma "força tarefa" para tentar identificar o problema é que fomos isolando até chegar nesse último detalhe)
Obrigado!

Momento de disparo comunicação com GRC NF-e (Processo SD)?

Boa tarde a todos!
Uma dúvida interessante:
Qual seria o real momento de disparo de comunicação entre o ERP e o servidor GRC NF-e em um processo SD?
Imagine um cenário no qual a liberação contábil é feita após o salvamento do faturamento.
a. Seria no momento de se salvar o documento de faturamento;
b. Ou seria no momento de se liberar o documento para o lançamento contábil?
Acredito que seja a primeira opção, mas tenho dúvida.
Outra dúvida:
Seria possível, no caso de o disparo ser no momento de se salvar o documento de faturamento, realizar alguma configuração no SAP para que, ao invés disso, o mesmo realizasse o disparo no momento de se liberar o documento para o lançamento contábil?
Obrigado pela atenção,
Daniel.

A data de escrituracao = posting date da J_1BNFDOC.
O problema é para notas emitidas perto da meia noite, em que a autorizacao pode vir só no outro dia, é isso?
Pq nao tem hora pra escrituracao, só data, entao só vejo problema em querer alterar a data, a nao ser nesse caso.
Mas note que a NF-e nao aparece no livro (ou nao deveria aparecer) enqto ela nao estiver autorizada (docstat = 1, statcode = 100), ou aparece como cancelada (se ela tiver sido cancelada ou inutilizada, flag de cancelled = X).
De qq maneira, se vc quiser, pode analisar a possibilidade de alterar o valor do posting date no metodo call_rsnast00 da badi cl_nfe_print (que eh chamada no retorno do grc pro erp), e alterar qdo a nfe for autorizada (status atual = aguardando resposta e status da sefaz = 100 (autorizada)). Nao sei se dá, tem q ver os parametros q sao passados.
Abs,
Henrique.

NFe em processamento no ERP e OK no GRC mas teve erro de atualização do ERP

Boa tarde,
Tem acontecido que ao tentar atualizar a NFe, ocorre o erro de atualização (tabela /XNFE/NFE_HISTconsta 108), porém no monitor GRC a NFe está com status OK (verde).
Ao verificar a tabela /XNFE/NFE_HIST, o registro de wasstat 05 (Result Received) tem o error_erp 108, porém o último registro da tabela é o de wasstat 08 (sent to B2B) e neste o erroe_erp está em branco. Inserindo o erro 108 neste último registro, a NFe aparece agora no monitor GRC com status de erro, e o erro ERP 108, e aparece na aba de "Erro atualização status ERP", permitindo assim o uso da opção Atual. (atualizar o ERP novamante), que após acionado, atualiza o ERP corretamente e volta a NFe para OK no monitor GRC.
Já pesquisei notas e aqui no SCN e não encontrei nada relacionado.
Alguém já passou por isso.
GRC 10.0 sp13
ERP 604 sp11
Abraços
Ricardo Carneiro.

Bom dia Ricardo,
Vamos por partes...
- o 05 significa resultado recebido da Sefaz, e o status 100 diz que foi tudo Ok por lá
- o 05 tenta comunicar com o ERP, e o 108 indica neste status que o ERP não pode processar seu status
- o 08 não comunica com o ERP, então nele não deve ter ERP_ERROR mesmo
Agora as questões:
- Deveria ter o processo parado no 05 já que houve um erro? Para alguns a resposta seria sim sim sim, para outros já que tá tudo OK faz o B2B
- Não deveria ter sido copiado o status 05 para 08? Talvez (pq resolveria a questão manual)
- O que fazer então?
Sobre o 108 ele é sintoma SEMPRE, algo não está bom no processamento ERP. A única coisa esperada de fato na emissão é o lock de processo no ERP, que o SAP NFE trata reenviando via job.
Na emissão muito provavelmente é algo errado seja configuração, seja código e deve estar dentro da BAdI.
Você não postou o que encontrou na RSRFCTRC. Poste por favor.
Com o foco em solução te indicaria investigar o que está errado no ERP, e a questão ERP_ERROR não estar visível no 08 vai ficar menor. De qualquer forma pode ser motivo de chamado para o desenvolvimento avaliar opções, mas é um remédio para sanar sintoma não para curar a doença.
* Se fosse um processo de cancelamento ou skip bem mais coisas poderiam acontecer como fonte de um erro de processamento ERP.
Atenciosamente, Fernando Da Rós

Reenvio do GRC para o ERP do Status de NFe 225

Pessoal,
Enviamos uma Nfe que foi rejeitada pela SEFAZ, com o validador GRC desativado.
Devido a uma falha de comunicação logada na /XNFE/BACKSTATUS o ERP não teve o update do status da nota, sendo que o GRC estava atualizado com o Status 225 para o lote, com o Error Status 46 para nota.
Em análise do programa de reenvio /XNFE/UPDATE_ERP_STATUS percebemos que o status enviado ao ERP é o status do cabeçalho da Nfe (tabela /XNFE/NFEHD, campo STATCOD).
Para o DOCNUM 138746, o campo STATCOD está em branco na tabela /XNFE/NFEHD, porém está preenchido na tabela /XNFE/BACKSTATUS, campo CSTAT como pode ser visto nos screenshots anexos.
No ERP, então, temos o erro u201CNo status code was received for NF-e 0000138746u201D
Existe alguma forma de reprocessar NF-e com status SEFAZ setado somente para o lote?
Segue os prints das telas:
http://img5.imageshack.us/img5/1936/screen1le5.jpg
http://img232.imageshack.us/img232/1678/screen2zs7.jpg
http://img232.imageshack.us/img232/4084/screen3ns1.jpg
http://img232.imageshack.us/img232/5003/screen4nt6.jpg
http://img232.imageshack.us/img232/1944/screen5hc2.jpg
Obrigado,
Dorval Neto.

Bom dia Alexandre,
O report /XNFE/UPDATE_ERP_STATUS foi lançado no SP05 através da nota 1251349, nela é comentado sobre a criação do job e a execução individual. Após esta nota o report foi modificado algumas vezes sendo a mais recente 1273616 ou SP06. Acredito que mais modificações são necessárias ao programa, como a descrita que não retorna individualmente para NFe que ocorreu rejeição 225 por lote.
Quanto a como identificar o erro:
a) NORMAL - Se foi uma rejeição de processamento "normal" do R/3, ou seja, por algum motivo conhecido ele rejeitou a resposta enviada pelo GRC, então a resposta será encontrada na tabela J_1BNFE_INVALID no R/3, procure pelo docnum (obter na /xnfe/nfehd-docnum). Existe algumas situações especiais que o R/3 usa como docnum o valor de 9999999999, invalidando a pesquisa anterior. Então procura pela data e hora (ACTION_DATE e ACTION_TIME) da transmissão do GRC para o R/3.
b) ST22 - Se o não processamento no R/3 foi devido a algum dump no momento da execução da função ou alguma EXIT/BADI, então este não será logado corretamento no R/3. Verifique na ST22 do ERP se existe alguma informação no momento da execução do report update_erp_status.
c) RFC - Se não encontrar nesta tabela no R/3 então o problema pode ser de comunicação ou impressão, neste caso verifique no GRC NFE os logs de RFC via transação AL11, é um pouco mais complicado, pois você terá pegar o exato work process que fez a comunicação (se seu sistema tiver poucos erros de RFC, então fica mais simples). Exemplo:
. Transação AL11, Name of Directory Parameter = DIR_HOME
. Para facilitar, coloque em ordem por data e hora decrescente
. Procure um arquivo chamado dev_rfcN, onde N foi o Work Process que executou o call function remote (este é o ponto onde talvez não saiba), então procure pelo último data/hora logo após a execução do report /XNFE/UPDATE_ERP_STATUS
d) SEM OPÇÃO - Em último caso pode-se executar diretamente a função chamada no R/3 (J_1BNFE_XML_IN_TAB) através da SE37 e acompanhar passo-a-passo com os valores que o GRC tentou enviar sem sucesso (atenção para preencher exatamente os mesmo valores)
Dorval,
Poderia abrir um chamado na SAP sobre esta situação, desta forma poderemos submeter à equipe de desenvolvimento para providenciar a correção.
Atenciosamente,
Fernando Da Rós
Edited by: Fernando Ros on Mar 4, 2009 9:53 PM

How to create a "Firefighter" type role when we do not have GRC

I am just looking for advice or input on this situation.
Currently my company does not have GRC or any other type of software that will allow for automated Firefighter type access and apparently there are no plans in the near future to purchase anything.
Our current process of creating a very powerful role to sign out to users on a case by case basis for a 24 hour period is not working and is getting out of hand.
I have been tasked with coming up with a better solution and they want me to build multiple roles for emergency access based on business area. Since there are thousands of transaction codes in SAP I find this to be a rather daunting task. My question is this...would it be a really bad idea to build say a Finance emergency role with F* in s_tcode and full access? I realize that there are more Finance codes that do not start with F but I am really just looking for input.
Has anyone else faced this situation and how did you approach it?
If someone out there has done this and could provide me with sample roles, that would be great.
Any help or advice is greatly appreciated.
Thanks
Bobbi

Hi Bobbi
There are couple of ways I did it in my previous customers. I am guessing you need these roles during Go-Live and Production Support
1. Create FF roles by business Process ( OTC, RTR etc) or Module wise. Get hold of the respective Functional people and ask them the nodes in SPRO Tcode what they think should be there for those FF roles. Then create those roles accordingly. Remove the Basis / Security admin tcodes and make 03 where-ever necessary.
2. Another way of doing it is you might already have global roles for different modules / business processes. So identify the roles that are best suited for the FF roles and during Go-Live/ Prod Support. Group them and may be create composite roles for those Global single roles
You might need FF roles for Transactional access and Configuration Access.
Transactional FFID: FFID with change access to business transactions of the stream/function. (Can use the create/change access roles built for end users)
Configuration FFID: FFID for any manual configu2019s to be performed directly in production and cannot/may not be transported (ex: number ranges)
There should be process for giving the FF roles and proper approval. Appropriate role owners should be identified for these roles who will give approval
Hope this helps

GRC Compliance Calibrator 5.3 and the "action" field for S_TCODE.

Dear GRC gurus,
I have read the threads here on the search terms for the "action" field in the "function" definitions, but not found a clear answer... so forgive me for asking a possibly obvious question.
When implementing the technical rules for the function, it seems that the "action" field is included in the check even if it's value is not in the "permissions" of object S_TCODE. But there is no "look up" nor validation (how could there be from the Java system?) on what that value is.
Appart from the fact that one might be tempted to enter some nonesense text in there, what is the logic behind the checks in the coding if it happens to fit a tcode name and is this field truncated at any points?
The reason for asking, is that we have some critical functions in the system for which we do not care how the user gets to it (tcode's... , rfc's..., service's... etc) but want to analyze whether the users can infact use the function (as opposed to attempt to start it). This makes sense in many business functions, and for the "basis" stuff which is critical it should be clear).
What we wanted to do was "name" the action by it's well known transaction code (in a symbolic sort of way, for the business users... to be able to recognize it, symbolically... although S_TCODE does not have an activity field........) but not have it checked in the rule set at the technical level. The standard delivered rules seemed to do the same thing... but we are still stuck on the s_tcode check because we dont want it in some cases and have good reasons for this.
- Can anyone confirm how this really works? For example wild carding FB* as the action name?
- Assuming our above analysis is correct, which tricks can you recommend (add a "dummy" action?; add a * action?; a possible naming convention?) to shed the harness of the tcode check (or having to document all of the buggers in the actions...) but still make it useable for the only slightly technically inclined folks who do understand that there are enough tcodes or it is critical enough that we should not rely on the "very general" protection provided by tcodes?
Bad news, future insights and work-arounds are all welcome
Cheers,
Julius
Edited by: Julius Bussche on Dec 10, 2008 11:30 PM

Thank you Sam and also Kaushal for searching
This describes exactly what we were looking for and the manual load / merge was also the intention using the file as the "master" to maintain and not make changes within the application.
Thanks again. I will try it out.
Cheers,
Julius

GRC 10.1 HR trigger BEGDA

Hello, everybody,
I have faced a problem with HR-trigger:
I need to delimit system in access requests that are created by HR trigger in GRC. I want to delimit valid from(for system) with BEGDA.
BEGDA comes from 0302 IT with MASSN and IT.
I checked lots of notes with describes this problem:
1738853 - UAM: System line item not added for mapped roles in HR req
1970860 - Valid To date of users not getting captured in the HR trigger request for Separation process and HR trigger request not getting due to No user assigned error
1705700 - UAM: Future termination does not work in HR Triggers
1823821 - UAM: HR Trigger delimit date is not captured
1999133 - HR Trigger is not capturing the termination date as end date
Maybe i need to set some parameters in spro?
Hoping for your soon help.
Thanks beforehand, Ivan.

Hi Ivan,
There is a functionality of default roles, that you could use to add roles to your request by implementing this logic in your BRF rule for HR triggers.
The bad news is that assignment for the default roles based upon Department is not supported.
There are only a certain fields which are supported for the Default Roles assignment, below:
Business Process, Business Subprocess, Company, Role Critical Level, Functional Area, Landscape, Location, Project Release, Role sensitivity, and System.
Lets suppose you can use Functional Area instead of Department. You will need to maintain Default Roles settings in SPRO, at REQUEST level, (parameters 1302, 2009, 2010, 2011, 2012, 2013).
In NWBC>Access Management>..>Default Roles, make sure that the entry maintained there (for attribute Functional Area) has SYSTEM set to "All Systems" or "All system in the role Landscape".
This should work.
Note 1964884 has a correction for this functionality, so if you go for it, make sure to have this Note applied.
Now, if any of the fields available for Default Roles will be good for your scenario, then it will not be possible to use Role Defaults, thus I am not aware of any customization on this area.
Hope this helps!
Luciana.

How can I get GRC V5.3 Users Guide for the four modules

Hi,
Does anyone know how I can get hold of GRC V5.0 User Guide(s) for Risk Analysis and Remediation, Compliant User Provisioning, Enterprise Role Management, and Superuser Privilege Management? So far I can only get Installation Guide, Configuration Guide, Upgrade Guide, etc. from the SAP Ramp-up website; but not the function modules. Is there a user guide for the four modules?
Also can anyone tell me about their experience with GRC V5.3 ramp-up? Good or bad, what to watch out, etc. Any information will be appreciated.
Thanks.

I previously downloaded the documentation of SAP marketplace, but I can't find it again.
A quick google search showed them here as well:
Moderators: If this is not okay to post, please feel free to delete the link...
Edited by: Alexander Obé on Sep 1, 2008 3:46 PM
The Access Control user guides are available on http://help.sap.com, specifically here:
http://help.sap.com/saphelp_grcac53/helpdata/en/45/92C7FA00494714A4162AD707D9B328/frameset.htm
SAP Documentation is regularly updated. I recommend against downloading it from sites that do not maintain the accuracy (and violate SAP copyright).

GRC Badi GRFN_MSMP REQUEST_FINISHED

Similar Messages

Maybe you are looking for