sexta-feira, 21 de dezembro de 2012

Relacionamento de tabelas - lista técnica

MAST – STPO

 

Mast código produto acabado, centro

recupera STLNR

 

STPO passa STLNR

E STLTY “M”

 

Componentes em IDNRK

 

quinta-feira, 20 de dezembro de 2012

INFORMAÇÃO SAP

Para informação... Trabalho com SAP, e tudo que aqui é postado, diz respeito diretamente a dicas, conteúdos encontrados na internet, que hoje são de domínio publico.

 

Como o próprio HELP da SAP... Disponível em:

 

http://help.sap.com/saphelp_46c/helpdata/pt/c3/70463423530444e10000009b38f83b/frameset.htm

 

e em fóruns como:

 

http://www.localizationforum.com/forum/

 

http://basisbrasil.blogspot.com.br/

 

http://scn.sap.com/thread/1661735

 

Você pode se referir aos RSS de discussão que serviram para encontrar esta documentação fazendo uma pesquisa.

·         Lien Wikipédia

·         Lien Wikipédia anglosaxon

·         SAP França (fr)

·         Formation à SAP R/3 (fr)

·         SAP Knowledge Base (inglês)

·         SND Community (inglês)

·         SAP Help Portal (inglês)

·         Bibliothèque SAP (certains documents sont traduits en fr)

·         SAP Library (inglês)

·         Programming, Basis Administration, Configuration Hints and Tips (inglês)

·         SAP Online Help (inglês)

·         SAP2000 English Manuals (inglês)

·         http://www.sap-bestof.com/

·         http://www.syren.fr/syra-media/sap/indexsap.htm

·         http://www.eyrolles.com/Accueil/Recherche/index.php?q=sap&themes=ACC



Note este conselho judicioso: 
/forum/affich-2664363#3 O melhor conselho que se pode dar a alguém que começa a se formar nas transações SAP na sociedade que o recruta, é a de solicitar ao serviço informático de lhe comunicar os manuais que foram concebidos durante o projeto de implementação SAP. 

Treinamento Oficial SAP

http://www.korun.com.br/cursos

Outros links

·         Tipos de documentos no sap utilização

·         ERP : Conseils pratiques

·         Sap documentação

·         Modelos de documentos online » Dicas - e-administrativo

·         Urbanização do SI (sistema de Informação) » Artigos - Sistema de informação

·         MS-Dos - Listar o conteúdo de um diretório no arquivo » Dicas - MS-Dos

·         Windows 7: Redes sem fio » Dicas - Windows 7

·         Anexos não abrem [email] » Dicas - Email

 

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.

terça-feira, 18 de dezembro de 2012

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.

 

Dados Mestres–Fornecedor 2

O registro mestre de fornecedor contém informações sobre fornecedores de uma empresa. Esta informação é armazenada nos registros mestre individuais de fornecedores. Além do nome do fornecedor e endereço, um registro mestre de fornecedor contém dados como o seguinte:

Moeda utilizada para as operações com o fornecedor;
Condições de pagamento;
Nomes dos contatos importantes (por exemplo, vendedores).

Uma vez que, para fins contábeis, o fornecedor também é um credor da empresa, o registro mestre de fornecedor também contém dados contabilísticos, tais como a conta de reconciliação da razão geral. O registro mestre de fornecedor é mantido por compras e contabilidade. Esta é também a razão para a subdivisão dos dados no registro mestre de fornecedor em diferentes categorias.

Os dados no registro mestre de fornecedor é subdividido nasseguintes categorias:

Dados Gerais
Estes dados são válidos para o cliente todo. Ele inclui o endereço do vendedor e os dados bancários, por exemplo.

Dados Contábeis

Esta é mantida ao nível do código empresa. É composto por dados como o número da conta de reconciliação e os métodos de pagamento para transações de pagamento automático.

Dados de Compra

Esta informação é mantida para cada organização de compras. Inclui a moeda ordem de compra, Incoterms, e diversos dados de controle relativos ao fornecedor. Você também pode manter dados diferentes para centros específicos ou para fornecedor subintervalos.
Você pode decidir se os registros mestre de fornecedor devem ser mantidos central (isto é, todos os dados são mantidos juntos), ou de forma descentralizada (isto é, os serviços competentes de cadamanter seus próprios dados).

Você pode apenas conceder acesso ao pessoal de compras, as as transações de operações MK01 e MK02 e MK03 (Logística Administração de Materiais Compras Dados MestreFornecedor Compras Criar / alterar / Display), eles só serão capazes de manter o endereço geral e controlar os dados e os dados de compra-específicos. O pessoal da contabilidade deve digitar os dados de pagamento de transações e os dados da empresa de código específicos.
No entanto, você também pode dar a sua autorização pessoal para manter os dados mestre de fornecedor no caminho do menu Logística
Gestão de Materiais Compras Master Data Fornecedor Central Criar / alterar / Display (transações XK01 eXK02 e XK03). Neste caso, a equipe pode manter todos os dados no registro mestre de fornecedor.
Antes que você efetue qualquer pedido de um fornecedor, você deve ter previamente os dados de compra atualizado. Uma pré-condição para a entrada da fatura e a criação prévia dos dados contabilísticos.