Pular para o conteúdo
Como funciona este fórum

Moderado por Emanuel Kaufman. As três primeiras mensagens de cada pessoa passam por revisão e respondemos em até 1 dia útil.

Aqui se discute o comportamento do sistema. Decisão tributária é sempre da sua empresa, e ninguém neste fórum dá parecer.

Tudo o que você publicar é público e pode ser usado por terceiros, inclusive por sistemas de IA. Não publique dado de cliente, nome de empresa nem tela do produto.

Esta pergunta foi sinalizada
6 Respostas

O resultado que eu preciso é a equipe conseguir abrir os apps Fiori do DRC sem depender de acesso administrativo. Veja, a ideia é essa: estamos migrando para o SAP novo, a equipe fiscal usa o GUEPARDO Tax, e a tela de apuração não aparece para os usuários de negócio. Já conferi as funções no perfil, copiei o catálogo de outro cliente e reiniciei o gateway, mas o app continua sumindo. Alguém já montou essa parte de Fiori para DRC? Qual caminho vocês seguiram para liberar o acesso sem abrir papel de administrador?


Atualização:

Na minha rotina, o caso concreto é o gestor fiscal abrir o app e ver a tela vazia. Agradeço a resposta. Testei a atribuição com um usuário de consulta e o grupo entrou, mas com o usuário de alteração ainda some. Veja, a ideia é entender se é a camada de frontend que bloqueia ou se é a própria função de apuração. Vocês já viram esse caso em que o perfil de leitura funciona e o de alteração não?


Atualização:

Leonardo Pinto, agradeço a pergunta, que me fez testar algo a mais. Veja, a ideia é que a checagem não é só de camada: testei a ordem de carregamento e o gateway bloqueia antes quando o papel tem o grupo de alteração sem o de consulta. Mudando isso, o app abriu para o usuário de alteração. Agora, como vocês tratam esse carregamento em produção, sem mexer no catálogo?

Avatar
Cancelar
Melhor resposta

O resultado que importa é o usuário enxergar só o que a função dele exige, sem depender de um catálogo que muda de cenário para cenário. Na prática, o caminho é separar consulta e alteração, validar a camada de frontend e só depois revisar a visibilidade por organização de vendas. Vale validar cada perfil com massa de dados verdadeira antes da virada, porque a ausência de dados e o vazamento costumam ser dois lados do mesmo erro. Recomendo montar um roteiro por área, com dono e registro do que foi testado. Quando a equipe fizer isso, a discussão deixa de ser sobre o catálogo e passa a ser sobre quem acessa o quê. Para aprofundar, veja migração do GRC NFE para o DRC.

Avatar
Cancelar
Melhor resposta

Sérgio, uma pergunta rápida. Agora, no meu time, a gente separa o papel de consulta do de alteração, e o Fiori mostra o grupo errado para o usuário. Sérgio Marques, quando você fala de auditoria, o seu time pede o log de cada acesso ou só o relatório de perfis? Isso muda o que eu levo para a reunião de go-live.

Avatar
Cancelar
Melhor resposta

Concordo em parte com a atribuição de grupo, Sérgio Marques, mas discordo de deixar o frontend para o fim. E aí, pra constar, no meu caso de construção o ECC antigo ainda manda na autorização e o Fiori só reflete. Você diz para checar a camada de frontend primeiro. Quando o usuário de alteração some, isso é ordem de checagem ou é o gateway que bloqueia antes?

Avatar
Cancelar
Melhor resposta

O risco que eu já vi é o usuário de consulta virar alteração por engano, quando alguém copia o papel errado no perfil. Nelson Marques, completo o que você falou sobre visibilidade: bem, eu aprendi na marra que o filtro de organização tem que ser testado com dados reais, não com um usuário de teste vazio. Num serviço de logística, por exemplo, a área de frete viu notas de outra filial e ninguém percebeu até a auditoria.

Avatar
Cancelar
Melhor resposta

Mas e se o filtro falhar? Sérgio Marques, eu completo o que você disse: e aí, no go-live, o usuário enxerga o app, mas sem o filtro de unidade de negócio carregado ele vê dados de todas as áreas. Isso acontece quando a regra de acesso é feita por papel e não por organização de vendas. Eu faria uma revisão de visibilidade antes da virada, com um roteiro de testes por área. Assim, o problema da tela vazia não vira vazamento de dados depois.

Avatar
Cancelar
Melhor resposta

Se o app some mesmo com o catálogo certo, o problema costuma estar na atribuição do grupo de tiles, e não no catálogo. Eu verificaria primeiro se o usuário tem o papel de consulta e se o grupo está ativo no frontend. O cuidado é, viu, não dar acesso de administrador a quem só precisa consultar, porque isso já criou dor de cabeça na auditoria aqui. Quando o cenário for de apuração, separe um papel de leitura e outro de alteração, e teste com um usuário real antes de liberar para todos. Peça o log do gateway já na abertura.

Avatar
Cancelar

Sua resposta

Tente oferecer uma resposta substancial. Se quiser comentar sobre a pergunta ou resposta, basta utilizar a ferramenta de comentários. Lembre-se de que você sempre pode revisar suas respostas - Não há necessidade de responder à mesma pergunta duas vezes. Não esqueça de votar - Selecionar as melhores perguntas e respostas é realmente útil!

Perguntas relacionadas

Mais conversas em SAP DRC e eDocument.

Ver todas do fórum