Perfis

E falando de perfil,

 

Bem o perfil muitas vezes pode esconder os motivos de determinada coisa acontecer para um usuário e para outro não.

 

Esteja sempre atento!!! Dados de logon TIPO DE USUÁRIO, sem contar o próprio parâmetro para o perfil do usuário.

 

São pegadinhas que te pegam

 

Tp.usuário

Diálogo 'A'

Um usuário de diálogo normal é utilizado apenas por uma pessoa para todos os tipos de logons.

No logon de diálogo, a verificação ocorre em senhas expiradas/iniciais com a possibilidade da própria modificação de senha.

São verificados múltiplos logons de diálogo e, se necessário, registrados em log.

Sistema 'B'

Utilizar o tipo de usuário Sistema para operações dentro de um sistema (processamento em background) e com base no sistema (-> ALE, Workflow, TMS, ZBV).

Não é possível efetuar um logon de diálogo (por meio do SAP GUI).

Um usuário deste tipo está excluído das configurações gerais para o período de validade de uma senha. A senha só pode ser modificada por meio dos administradores de usuários mediante a transação SU01 (Saltar -> Modificar senha).

É permitido efetuar um logon múltiplo.

Comunicação 'C'

Utilizar o tipo de usuário Comunicação para a comunicação sem diálogo com o sistema (->RFC ou CPIC).

Não é possível efetuar um logon de diálogo (por meio do SAP GUI).

Em princípio, um usuário deste tipo está sujeito às configurações gerais para o período de validade de uma senha e pode (como um Usuário de diálogo) modificar a senha. Os diálogos para modificar a senha devem ser fornecidos pelo chamador (cliente RFC/CPIC). A senha pode ser modificada por meio do módulo de função RFC <DS:FU.SUSR_USER_CHANGE_PASSWORD_RFC> SUSR_USER_CHANGE_PASSWORD_RFC ou por meio da função RFC-API RfcOpenEx().

Serviço 'S'

Um usuário do tipo Serv

 

 

 

 

 

TABELA NÃO GERA REQUEST

Customização de tabelas

 

Em algumas tabelas, o objeto de sua estrutura pode estar configurado para não gerar request.

 

Isso pode causar transtornos com tabelas divergentes entre ambientes.

 

Assim, dentro da tabela na visão de Status at. (status de atualização) o fleg do campo Classe de entrega irá determinar se:

 

Classe de entrega de uma visão de atualização

A classe de entrega de uma visão de atualização é analisada na Atualização ampliada de tabela (SM30). Se, para a visão de atualização, for gerada uma interface de atualização, as seguintes informações são analisadas na entrada de dados de visão por meio desta interface:

• Para as visões de atualização das classes de entrega E ou G, é efetuada a verificação de se os dados entrados na tabela TRESC para a vião, respeitam os conjuntos de nomes definidos.

• É efetuada a verificação de se a conexão para transporte instalada na atualização gerada de tabela é apropriada. Por exemplo, para as visões de atualização das classes de entrega L e W, não é efetuado qualquer transporte.

A forma como são tratados os dados entrados por uma visão em uma tabela de base da visão, aquando da mudança de release ou do transporte, é determinada exclusivamente pela Classe de entrega da respectiva tabela de base da visão.

A classe de entrega controla o transporte de dados da tabela, no caso de instalação, mudança de release, cópia de mandante, e no caso de transporte entre sistemas de cliente. A classe de entrega também é considerada na Atualização ampliada de tabelas.

Existem as seguintes classes de entrega:

• A: Tabela de aplicação (dados mestre e de movimento)

• C: Tabela de cliente, os dados são atualizados exclusivamente pelo cliente.

• L: Tabela para arquivar dados temporários.

• G: Tabela de cliente, a SAP pode inserir registros novos, mas não pode sobregravar ou eliminar aqueles que já existem. É necessário que o conjunto de nomes de cliente seja definido na tabela TRESC (utilizar o report RDDKOR54).

• E: Tabela de sistema com conjuntos de nomes próprios para entradas de cliente. É necessário que o conjunto de nomes de cliente seja definido na tabela TRESC (utilizar o report RDDKOR54).

• S: Tabela de sistema, as modificações de dados têm o status de modificações de programa.

• W: Tabela de sistema (por exemplo, tabela do ambiente de desenvolvimento), cujos dados são transportados por objetos de transporte próprios (por exemplo, R3TR PROG, R3TR TABL, etc).

Comportamento na cópia de mandante

Só são copiados os dados de tabelas dependentes de mandante.

• Classes C, G, E, S: Os registros da tabela são copiados para o mandante de destino.

• Classes W, L: Os registros da tabela não são copiados para o mandante de destino.

• Classe A: Os registros só são copiados para o mandante de destino, se tal for pretendido de forma explícita (opção de parâmetro). Em regra, um transporte destes dados não é apropriado mas, no entanto, é suportado de modo a permitir a transferência de todo um ambiente de mandante.

Comportamento no caso de instalação, mudança de release e importação de idioma

Existe aqui uma distinção quanto ao comportamento de tabelas dependentes de mandante e ao de tabelas independentes de mandante.

Tabelas dependentes de mandante

• Classes A e C: Os dados são só importados para o mandante 000. Os registros existentes são sobregravados.

• Classes E, S e W: Os dados são importados para todos os mandantes. Os registros existentes são sobregravados.

• Classe G: No mandante 000 são sobregravados os registros existentes. Em todos os outros mandantes são inseridos novos registros, mas os registros já existentes não são sobregravados.

• Classe L: Não são importados dados.

Tabelas independentes de mandante

• Classes A, L e C: Não é efetuada qualquer importação de dados.

• Classes E, S, e W: São importados dados. Os registros existentes com a mesma chave são sobregravados.

• Classe G: São inseridos registros que não existem, sem que sejam sobregravados registros existentes.

Comportamento no caso de transporte entre sistemas de cliente

Os registros de tabelas da classe de entrega L não são importados para o sistema de destino. Os registros das classes de entrega A, C, E, G, S e W são importados para o sistema de destino (no caso de tabelas dependentes de mandante, isto é efetuado para o mandante de destino indicado no transporte).

Utilização da classe de entrega na atualização ampliada de tabelas

A classe de entrega também é analisada na Atualização ampliada de tabelas (SM30). A interface de atualização gerada para uma tabela, executa as seguintes verificações:

• Para as tabelas das classes de entrega W e L, não é possível qualquer transporte dos dados entrados, através da conexão para transporte da interface de atualização gerada.

• A quando da entrada dos dados, é efetuada a verificação de se estes violam o conjunto de nomes definido na tabela TRESC para a tabela. Se os dados violarem o conjunto de nomes, a entrada é rejeitada.

TRACE SQL

Trace de autorização, vamos falar da ST05, trace de SQL. Como sabem o SAP é um sistema que suporta diversos bancos de dados e devido à diversidade de linguagens e de bancos de dados existentes, a maneira de se comunicar entre uns e outros seria realmente complicado de providenciar, a não ser pela existência de padrões que nos permitem a realização das operações básicas de uma forma universal. É justamente disso que se trata o Structured Query Language ( SQL ) que não é mais do que uma linguagem padrão de comunicação com base de dados. Falamos portanto, de uma linguagem normalizada que nos permite trabalhar com qualquer tipo de linguagem em combinação com qualquer tipo de base de dados. No caso do SAP estamos falando do ABAP e do SQL juntos. Basicamente o comando SELECT é utilizado para ler Tabelas, O UPDATE para atualizar e o DELETE para excluir ( Deletar ) registros de uma tabela e o INSERT faz as inserções ( inclui ). Temos muitos outros comandos SQL e diversos tutoriais na Internet para quem quiser se aprofundar no assunto.

O nosso trace faz mapeamento de comandos SQL, muito útil para se saber que tabelas são tratadas em uma aplicação. No caso de um desenvolvimento "Z", mesmo se for chamado por uma aplicação Standard um trace faz este mapeamento SQL.

Passo a Passo:

1.            Executar a transação ST05,

2.            Marcar "SQL Trace"

 

3.            Ativar o trace, clicando em "Activate Trace"

e aguardar a mensagem "SQL trace is For User XXXXXXXXXXX Activated"

 

4.            Executar a transação a ser mapeada, com /N + Transação

 

5.            No meu caso executei a VA01 ( ordem de vendas e gravei um documento de vendas ).

 

6.            Executar novamente a transação ST05,

 

7.            Desativar o trace, clicando em "Deactive Trace"

 

8.            Executar a analise do trace, clicando em "Display Trace"

 

 

9.            Ao executar a analise, deixe marcado apenas "SQL Trace" e "Trace List",

assunto que o trace foi executado.

Devemos ficar atentos ao retorno do Objeto de SQL, Sendo RC=0 Ok e RC diferente de zero, um problema de execução. RC ( Return code , código de retorno da função ).
Para mais detalhes, dar um clik duplo no comando SQL

Neste momento também é possível verificar o código ABAP e o dicionário de dados.

OBS: Dica Importante

Se você estiver procurando problemas relacionado a performance, a linha onde o campo "Duration"estiver em vermelho, temos um serio problema de performance de acesso ao banco de dados. Ou seja, o Trace também pode ser utilizado para identificar problemas de performance.

 

Transação MASSS

Algum tempo depois ele me retornou e disse a VA05 não altera este campo.

Ele estava certo, na transação VA05, temos poucas opções para a modificação em massa.

Observem que temos apenas o Centro, material, nova determinação de preço e moeda.

 

 

 

Então partimos para a transação de alteração em massa standard da SAP,

além da XD99 para clientes, XK99 para fornecedores e a MM17 para materiais.

 

Vamos executar a transação MASS.

 

 

 

Vamos escolher o objeto BUS2032 - Ordem de cliente.

Esta transação também pode ser utilizada por MM em documentos de Compras.

Na primeira tela, no ícone abaixo é possível escolher os campos da tela de seleção.

 

 

Selecionado o campo condição de pagamento...

 

 

 

 

Digitar na coluna de cima, a condição de pagamento a ser alterada.

Clicar na coluna e no ícone abaixo para transferir o valor para todas as ordens de vendas. ( neste caso 0009 )

 

 

 

 

Após a gravação dos dados, o SAP emite uma lista com os status de atualização de cada documento.

Pela transação VA03, é possível consultar as modificações de uma ordem de vendas e neste caso, temos

o controle normal do SAP standard com a informação anterior 0001 e informação nova 0009, do campo

VBKD-ZTERM, pela transação MASS, usuário e data/hora da modificação.

 

 

 

Resumindo, a urgência do trabalho a ser executado pelo consultor era tal que o mesmo

já estava pensando em fazer um desenvolvimento para isso.

 

Direito Fiscal Taxbra

Outro dia, em uma interface, eu precisei do direito fiscal...e ai começaram os meus problemas, afinal, em que tabela ele é gravado....Onde o SAP grava o direito fiscal de uma record condition?, já que via standard não conseguimos consultar esta informação....pelo menos até agora eu não consegui...

Estes tipos de condições de direitos fiscais são chamadas de Lei, Norma, Law...mas no fundo, estamos Falando de direito fiscal de cada imposto.

Para alguns tipos de condição, de MM



E Tipos de condição de SD




Vamos ao Passo a Passo para chegarmos ao registro de condição de Direito Fiscal.


Primeiro Passo:
Localizar o grupo de imposto e o imposto que esta sendo procurado....




Neste case, temos imposto ICMS e grupo de imposto 82.

Consultando a tabela de Atribuição de Grupo com tabela de condição na J1BTAX, temos,



Concluindo a consulta, ICMS = J_1BTXIC3, Grupo 82....foi atribuída a tabela de condição 382.

Nesta case, vamos consultar a tabela de condições A382 pela transação SE16N, inserindo os dados da record condition.
Como se trata de ICMS o campo KSCHL, tipo de condição vai ser igual a ICLW.










Neste case o meu banco de dados é pequeno....além da chave completa, cuidado com os DATBI/DATAB, vigência e validade.

Com o campo KNUMH, neste case, 0000067627, com a transação se16n, vamos consultar a tabela KONH de
cabeçalho de condições, gravada pelo SAP em todas as Records conditions.





Observe que o campo KNUMA_BO traz o valor Z17, direito fiscal de ICMS imputado em nossa record condition de exemplo....
Bom até o momento, não encontrei nota que melhora esta consulta...

Procurando exit e badi

Executar a transação SE24,

Entrar o Tipo de Objeto  CL_EXITHANDLER.

 

 

 

Dentro da Classe, dar um clique duplo no método GET_INSTANCE

 

 

 

Colocar um break-point na linha 25, comando :   CASE sy-subrc, conforme abaixo:

 

 

Executar uma transação, neste caso VK11.

 

 

 

O campo EXIT_NAME, mostra a badi que será executada.

 

 

Dados MESTRE FORNECEDOR

Conceito de Dados Mestres de Fornecedor

 

Este artigo apresenta os dados mestres de fornecedor, que é de importância tanto no ordenamento e da fase do processamento de fatura de compras. Trata-se da estrutura e manutenção (Criar, Modificar e Exibir) dos dados mestres de fornecedor.

 

O registro mestre de fornecedor pertence aos dados mestres mais importantes no processo de aquisição. Sem um registro mestre de fornecedor, você não pode criar documentos de compra ou entrar faturas recebidas. Em conexão com a verificação de fatura, os fornecedores são muitas vezes referidos como credores.

 

A sua empresa entrou em uma relação de negócios com um novo fornecedor. Uma vez que você pretende fazer pedidos frequentemente com este fornecedor no futuro, você cria um novo registro mestre para o fornecedor.

 

Dados Mestres compreende os registos que são armazenados no banco de dados por um longo período de tempo. Estes registos de dados são armazenados centralmente, e são utilizados e transformados numa base aplicação cruzada. Desta forma, a duplicação de dados é evitada. O registro mestre de fornecedor, o registro mestre de material e o registro info para compras são dados mestres mais importantes no processo de aquisição.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Quando você cria um documento de compras, o SAP R/3 irá suporta-lo com a entrada de dados e fornecendo-lhe com os valores padrão dos registros mestre existentes. Outros dados do registro mestre de material, tais como unidades de medida, o texto material de curto, e o texto PO, também é adotado no novo documento. Os dados no registro mestre de fornecedor inclui o endereço e os dados de pagamento. Você pode armazenar dados específicos do fornecedor em um determinado material (por exemplo, tempo de entrega e o preço de compra) na compra nos registros info de compras.