Fábio Pagoti

Formado em Sistemas de Informação pela Universidade de São Paulo. Comecei no mundo da programação com Java mas logo caí no mundo ABAP. Estagiei na Nestlé por 2 anos e foi lá onde conheci o Furlan. Depois de efetivado fui morar no Canadá por 1 ano onde pude aprender a área de testes em desenvolvimento de software. Hoje sou consultor e instrutor ABAP, amante de projetos Open Source, Wordpress, Data Mining e da esfera SAP. Siga-me no twitter: @fabiopagoti

15 Resultados

  1. Gledson disse:

    Simples, rápido, claro e objetivo.

  2. Fábio Pagoti disse:

    Obrigado Gledson! Bons estudos.

  3. Eduardo disse:

    Olá Fábio. Ficou somente uma dúvida para o caso de ambientes “mais brasileiros”. No caso de filiais, a prática vai para a divisão por Mandantes (um cliente para cada filial) ou mantem-se um cliente único (corporativo) com suas respectivas filiais (sub-grupos de negócios)…. qual o mais habitual ? (levando-se em conta a possibilidade de ter outros clientes em copia para as testes / customizações). Obrigado Eduardo

  4. Fábio Pagoti disse:

    Oi Eduardo,

    A divisão de mandantes por filiais ou outros conceitos que podem ser definidos via configuração na SPRO é algo possível tecnicamente mas que não se vê tanto na prática.

    É muito mais comum ver empresas com um cliente único em prod configurado para atender diferentes filiais.

    Vale lembrar que um ambiente de QAS não precisa reproduzir fielmente os mandantes de produção. O que deve ser igual entre os ambientes são seus objetos do repositório ABAP e suas configurações afim de garantir testes fiéis.

    Vale lembrar também que mesmo que se divida um ambiente em diferentes mandates há muitas configurações independentes de mandates, o que torna uma possível segregação por filiais por exemplo não tão vantajosa.

    Logo, é mais comum ver um ambiente com múltiplos clientes nos ambientes de DEV e QAS.

    Repondi sua questão?

  5. Fbrabreu disse:

    Bom dia Fabio, excelente post. Uma duvida existe alguma transação que lista todos mandantes de um ambiente?

    • Fábio Pagoti disse:

      Bom dia Fbrabreu!

      Obrigado pelo feedback. É provável que exista uma transação que mostre isso mas o jeito mais simples é olhar a tabela T000 na transação SE11/SE16 ou SE16N.

      Abraços!

  6. Maxsuel disse:

    Olá Fábio, obrigado por compartilhar seu conhecimento. Sou um usuário de FI nível básico, não sou programador ABAP. Li o artigo mas ainda não compreendi a finalidade do campo MANDT ou mandante. Poderia dar mais detalhes? Obrigado.

    • Fábio Pagoti disse:

      Olá Maxsuel,

      A vantagem do mandante se torna mais clara com conhecimentos de modelagem de banco de dados… algo que é importante para quem trabalha com desenvolvimento. Para um usuário, a questão do mandante deveria ser totalmente transparente e você nem precisaria se preocupar com isso (contanto que faça o login no mandante correto).

      Como o post diz, o MANDT tem vantagens se você pensar do ponto de vista de cada ambiente. Como usuário, é bem provável que você somente faça login em produção. Sugiro ver a pergunta do Eduardo e minha resposta aí em cima para ficar claro o aspecto do MANDT em produção.

      Abraços!

  7. Emanuel disse:

    Bom dia Fabio,

    Estou com uma duvida. Comecei a atuar numa empresa que implanta o SAP na NUVEM. Resumindo existe um GOLD do qual ela gera o ambiente para um novo.

    O primeiro cliente tinha por exemplo empresa 1000/2000 e centros 1010/1012…..etc

    Foi feita uma cópia :

    O mandante é outro, na mesma maquina. Pode ser renomeada a chave da empresa 1000 para outra?

    Renomear também chave de contabilidade de custos? Excluir os centros que não fazem parte do novo cliente? Esta pratica é a correta?

    • Fábio Pagoti disse:

      Emanuel,

      Há algumas confusões na sua mensagem, mas para resumir…

      Não importa se o SAP está na núvem. O software ainda é o mesmo.
      Não se muda a chave de nada. Não porque não é uma boa prática, mas porque isso é impossível no nível de banco de dados. Deleta-se o que se quer e cria-se com outro nome.

      Agora quando se fala de dados de customizing (principalmente os que você mencionou), altera-se no ambiente de customização para garantir que todos ambientes tenham dispiníveis estes dados.

      Infelizmente você não disse o propósito desta nova cópia e logo não entendi qual o fim desta. Mas enfim.. Centros são client dependent então você pode sim criar novos por exemplo. Agora se eles devem ir a outro ambiente, é um outro problema.

      Caso não saiba como abrir a tabela na SE11 para ver se é client dependent ou não… na dúvida, eu simplemente abriria a SPRO no outro mandante, mudaria e que quero e veria se o outro ambiente também foi alterado.

      A prática correta é ter ambientes equalizados em termos de de customizing.

  8. Emanuel disse:

    Fábio tentarei ser mais claro,,

    Foi feita implantação para um cliente A (mandante PRD 30). Agora foi feita uma cópia desta implantação e o mandante é o DEV 40.para outra empresa, um outro cliente na nuvem.

    Na estrutura do empreendimento foram renomeadas empresa e etc mudando apenas o texto , excluído centros atribuídos na implantação anteior, renomeando o centro existente para o da nova implantação ou seja um tipo de ctrl+c / ctrl+v de um projeto para outro.

    Estou as voltas com erros no meu modulo que apontam para falta de vínculos / atribuições de centro para empresas, de empresas para sociedades ou empresas para áreas de contabilidade de custos,porem tudo aparentemente está correto que verificamos no customizing.

    Em uma tentativa de corrigir o erro, pois o meu modulo está sendo apontado como origem deste erro encontrei que a função PM_CHECK_WERKE nas linhas 46 e 86, verifica BURKS mas não encontra o código na tabela T185 o que para mim se deve as exclusões realizadas no customizing com tal procedimento visto como “acelerador” da implantação e que por esta razão não me permitem questionar tal procedimento.

    • Fábio Pagoti disse:

      O ERP vai para a núvem mas a prática continua sendo Flintstoneana.

      Se entendi bem… não quero entrar nem no mérito legal de tal implementação.

      Enfim.. se foi feito uma cópia suponho que você tenha acesso ao sistema de origem.

      Se você sabe a tabela que está errada pois está falando coisa vai no customizing dela e termine de copiar o resto.

      O problema não é MANDT, o problema é outro bem mais grave e não sistêmico.

  9. Alice Tsuno disse:

    Fabio, muito instrutivo as suas explicações sobre o Mandante SAP.
    Como sou da área de Compliance de TI tenho uma dúvida: quando o Mandante de produção está aberto, há riscos que os usuários de negócios faça algo que interfira na integridade do ambiente ?
    Eu entendo que somente as transações mais técnicas como SE38, SE16N ou SM30 trazem riscos. É isso mesmo?

  10. Fábio Pagoti disse:

    Obrigado pelo comentário Alice.

    Risco é fazer qualquer coisa em prod que não tenha sido feita antes nos outros ambientes, testada e validada.

    Não há risco ter acesso a SE38 e não ter acesso a rodar um programa ou alterá-lo. Nao há risco ter acesso a SM30 sem poder alterar o conteudo das tabelas. Isso requer autorizações diferentes.

    Da mesma forma, o client aberto não apresenta risco se quem nao deve ter acesso a tais transações não o tem. Não que isso seja um motivo para largá-lo aberto.. mas sempre tem aquelas coisas que você só pode fazer “do modo ruim”, por exemplo, abrindo o client.

  11. Fabricio Moreira disse:

    Boa tarde, Fabio
    Eu estou transferindo alguns dados de um Mandante para outro, ja levei quase tudo falta só os Dados mestre (Material, fornecedor e etc) tem uma forma de transferir esses dados sem ter que fazer um a um ?