MANDT – Campo mandante no SAP – Entendendo de uma vez por todas
Ainda me surpreendendo com a confusão que o campo mandante (MANDT ou client) gera em grande parte de pessoas que trabalham com SAP. O conceito é simples mas pelo fato de poder ser aplicado em diferentes circunstâncias, creio que muita gente não esteja 100% segura do que deveria saber sobre ele. Se quiser entender tudo sobre o MANDT continue lendo este post. Se você não faz ideia o que é este campo também leia pois ele está presente na grande maioria das tabelas do SAP.
Onde está o MANDT no SAP?
MANDT na tela de login
O primeiro contato que temos com o campo MANDT (ou client) é logo na tela de login do sistema. Como ele vem preenchido para nós, pouco nos preocupamos com ele.
Em cada um dos ambientes (DEV, QAS, PROD, etc) podemos ter 1 ou mais mandantes. Cada um dos mandantes possui um número único que pode ser usado ao fazer login no ambiente em questão.
MANDT em tabelas do SAP
Caso você abra praticamente qualquer tabela de dados mestre ou transacional pela SE11 no SAP notará a presença do campo MANDT como parte da chave da tabela. Ainda, esta coluna será a primeira coluna da tabela, antes mesmo do “id” da tabela em si. Isso vale para as tabelas MARA, MARC, BKPF, BSEG, VBAK, VBAP, EKKO, EKPO e tantas outras no sistema.
Ainda, caso você tente visualizar os dados desta tabela pela transação Se11, Se16 ou SE16 notará que não terá como definir um filtro pela coluna MANDT. Logo, tiramos nossa primeira conclusão sobre clients: eles são independentes entre si.
Como o MANDT faz parte da chave, podemos ter mais de um material com o mesmo número no MATNR. Obviamente para isso o mesmo número do MANDT (outra parte da chave) deveria ser diferente.
MANDT (mandante) | MATNR (id do material) | MAKTX (descrição) |
---|---|---|
800 | M-123 | Arroz |
800 | M-124 | Feijão |
810 | M-123 | Arroz |
810 | M-124 | Milho |
Para quê serve o MANDT?
Ok… sabemos que o campo MANDT está em muitas tabelas (mas não todas). Sabemos que quando ele aparece faz parte da chave. Sabemos que ele está na tela de login por isso tem a ver com a sessão na qual o usuário usa. Mas para que serve o tal do MANDT?
O MANDT serve para separar dados dentro de um mesmo ambiente sem que haja a necessidade de duplicar tabelas. E porque preciso separar dados num mesmo ambiente?
Vou dar três exemplos de aplicação de mais de um mandante no mesmo ambiente. Isso não significa que todas as empresas usem todos os exemplos abaixo. Sua aplicação vai variar dependendo do tamanho da implantação da empresa em si e como funciona a manutenção e suporte do sistema.
MANDT em desenvolvimento
Um ambiente de desenvolvimento pode ter 2 ou mais mandantes para separar os dados usados por desenvolvedores ABAP dos dados usados por funcionais SAP.
No ambiente de desenvolvimento os ABAPers codificam enquanto funcionais configuram o sistema. A configuração feita por funcionais nada mais envolve que a inserção, alteração e exclusão de registros em uma porção de tabelas que não são de dados mestre. Estas modificações em dados em tabelas de configuração são capazes de alterar o comportamento do sistema.
Caso você (ABAP) esteja testando um enhancement (por exemplo uma user exit em SD) você pode ser impactado por uma configuração sendo feita ao mesmo tempo por um funcional. Por exemplo, a tabela TVAK é usada pelos funcionais em SD para definir documentos de vendas. Se você depender de algum documento que esteja sendo alterado por um funcional, talvez não consiga testar o que precisa. Isso SE você e o funcional estiverem compartilhando o mesmo mandante. Caso não estejam, os dados serão completamente independentes um do outro e ambos podem fazer seus testes com tranquilidade na mente. Note que a tabela TVAK possui o campo MANDT.
Por isso, pode-se ter 2 mandantes em DEV: 1 para desenvolvimentos em ABAP e o outro para configuração (este último é conhecido como ambiente “gold” em alguns lugares). Como o conteúdo de tabelas de customização alteram o comportamento do sistema o ideal é que sempre depois que um funcional fizer um teste bem sucedido em sua configuração rode a transação SCC1 para equiparar a configuração entre diferentes mandantes em desenvolvimento.
MANDT em qualidade
Testes são feitos no ambiente de qualidade. Testes podem ser manuais e automáticos. Testes manuais são geralmente feitos por funcionais usando dados de teste bem conhecidos por eles (por exemplo, usando a principal filial da empresa, o material mais vendido/conhecido, o centro ou depósito com mais estoque etc). Testes automatizados requerem que um conjunto de dados de teste estejam já prontos para que o teste possa ser executado. Caso haja apenas um mandante no ambiente de qualidade em que há testes manuais e automáticos, um funcional pode deletar ou alterar um material que é usado por uma série de testes automáticos: que consequentemente irão falhar – não por fracasso do teste em si, mas por conta de dados de teste errados.
MANDT em produção
Como mandantes determinam dados totalmente independente uns dos outros pode haver um mandante segregado para cada filial de uma empresa. Note que há empresas com diversas filiais que usam o mesmo mandante. Isso porque o conceito de filiais existe no SAP e a privacidade dos dados entre filiais pode ser realizado de outras formas.
Client-Independent vs Client-Dependent
Talvez você tenha ouvido os temos client-independent (ou independente de client /mandante) e client-dependent (ou dependente de client /mandante). Caso não tenha ouvido saiba que no help do ABAP estas definições são muito usadas. Elas são usadas para descrever tabelas do sistema de acordo com a existência ou não do campo MANDT em suas estruturas.
Em outras palavras, uma tabela (standard ou Z, não importa) que possua o campo MANDT será client-dependent. Isso porque os dados que você tem acesso nesta tabela depende do client usado para fazer logon. Da mesma forma, tabelas que não possuem o campo MANDT são client-independent. Estas tabelas são as mais perigosas pois qualquer alteração nas mesmas impactarão todos os usuários do sistema, independente em que mandante estejam. Felizmente há maioria das tabelas no sistema possuem o campo MANDT e tabelas independentes de client geralmente são de customização.
MANDT no SELECT
Como o mandante está atrelado a sessão do usuário, não há necessidade de especificar esta parte da chave quando se faz um SELECT (conceito conhecido como Client Handling). Porém, caso você deve selecionar dados de todos os mandantes do sistema, deverá usar a adição “CLIENT SPECIFIED” do comando SELECT FROM – o que particularmente nunca vi alguém usar em código Z.
Quantos mandantes existem no meu ambiente?
A tabela T000 guarda os mandantes do sistema. Se você notar, todas as tabelas que possuem a coluna MANDT tem uma chave estrangeira para esta tabela. Ou pelo menos deveriam ter.
Client 000
O mandante 000 é reservado pela SAP. A empresa não pode usar o client 000 pelo simples fato de ele ser “intocado”. Ou seja, ele tem a configuração 100% standard existente logo após a instalação do SAP. Empresas que tem o costume de alterar a configuração standard ao invés de criar uma cópia da mesma podem ter que recorrer a este mandante quando se perguntam “O que eu fiz/O que mudei mesmo?”.
Restou dúvidas? Comente!
Falei tudo que sei sobre o campo MANDT. Se você ainda tem alguma dúvida quanto ao assunto, comente a baixo. Este post deveria encerrar possíveis dúvidas sobre o conceito.
O mandante é um conceito que deve ser entendido se você estiver procurando vagas de ABAP. Aproveitando, você já se cadastrou no ABAP101?
Simples, rápido, claro e objetivo.
Obrigado Gledson! Bons estudos.
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
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?
Bom dia Fabio, excelente post. Uma duvida existe alguma transação que lista todos mandantes de um ambiente?
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!
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.
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!
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?
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.
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.
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.
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?
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.
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 ?