Tabela SAPObjetoLFA1MóduloMM_P2P

Tabela LFA1 — Dados Gerais do Cadastro de Fornecedor LFA1

LFA1 contém uma linha por número de fornecedor, armazenando os dados gerais independentes do cliente, como nome, endereço, país e flags de controle centrais, como os bloqueios central de exclusão e de lançamento. Não possui dados de empresa ou organização de compras; esses residem em LFB1 e LFM1. Problemas de cadastro de fornecedor ausente geralmente significam que o número existe aqui, mas nunca foi estendido para o nível da organização que uma transação precisa.

LFA1 é a tabela raiz do cadastro de fornecedor, uma linha por número de conta do fornecedor, contendo o segmento de dados gerais que não está vinculado a nenhum código de empresa ou organização de compras. Esta página aborda o que realmente dá errado quando um fornecedor não pode ser usado em um pedido de compra ou fatura, e como distinguir uma lacuna genuína de dados mestre de uma lacuna de extensão em LFB1 ou LFM1.

Publicado em 15 de set. de 2026· 992 palavras

O que armazena

Uma linha em LFA1 representa um único número de conta do fornecedor no nível de dados gerais: nome, endereço, país, idioma, termos de pesquisa, números de impostos, indicador de referência bancária e grupo de contas. Esses dados são compartilhados entre cada código de empresa e organização de compras para os quais o fornecedor é estendido posteriormente. LFA1 não carrega condições de pagamento, conta de reconciliação ou condições de compra; esses são dependentes da organização e residem em LFB1 (código de empresa) e LFM1 (organização de compras). Um número de fornecedor existente em LFA1 significa apenas que o parceiro de negócios foi criado centralmente, não que pode ser usado em um pedido de compra ou em uma fatura em um determinado código de empresa. Flags de bloqueio e exclusão centrais também residem aqui, razão pela qual um fornecedor pode ser utilizável em um código de empresa, mas bloqueado centralmente para todos os novos lançamentos em qualquer lugar.

Campos chave

  • MANDT - cliente, sempre o primeiro campo em qualquer seleção
  • LIFNR - número da conta do fornecedor, a chave que se conecta a todas as outras tabelas de fornecedores
  • NAME1 - nome do fornecedor conforme impresso na correspondência e usado em pesquisas de matchcode
  • LAND1 - chave do país, direciona a lógica de impostos e endereços
  • ORT01 - cidade
  • PSTLZ - código postal
  • STRAS - endereço da rua
  • SPRAS - chave do idioma usada para correspondência e texto longo
  • KTOKK - grupo de contas do fornecedor, controla o status do campo e o intervalo de numeração na criação
  • SPERR - flag de bloqueio central de lançamentos
  • LOEVM - flag de exclusão central
  • STCD1 - número de imposto 1, comumente o registro fiscal local
  • STCD2 - número de imposto 2
  • KONZS - chave de grupo, usada para identificar fornecedores relacionados sob o mesmo grupo corporativo

Como se junta ao modelo de dados

  • LFA1-LIFNR = LFB1-LIFNR, une-se a dados específicos do código de empresa, como conta de reconciliação e condições de pagamento
  • LFA1-LIFNR = LFM1-LIFNR, une-se a dados da organização de compras, como moeda do pedido e termos de entrega
  • LFA1-LIFNR = EKKO-LIFNR, une-se a documentos de compras emitidos contra o fornecedor
  • LFA1-LIFNR = RBKP-LIFNR, une-se a faturas de entrada lançadas contra o fornecedor

Como lê-lo com segurança

Sempre restrinja pelo MANDT primeiro, embora a maioria das ferramentas de relatório defina isso implicitamente. LIFNR é a chave natural e é altamente seletiva quando conhecida; selecionar por NAME1 ou LAND1 sem um filtro de código de empresa retorna resultados ruidosos e propensos a duplicidade, porque a mesma entidade legal pode aparecer sob vários números de fornecedor. LFA1 sozinho é uma tabela pequena e rápida para escanear pela chave primária, mas não diz nada sobre se o fornecedor é utilizável em qualquer lugar; não conclua a partir de uma linha LFA1 limpa que o fornecedor pode lançar. Antes de tratar um fornecedor como totalmente configurado, a extensão do código de empresa em LFB1 e a extensão da organização de compras em LFM1 precisam ser verificadas separadamente.

Como provar isso nos dados

Sintoma: um comprador relata que o fornecedor não pode ser selecionado ao criar um pedido de compra para uma determinada organização de compras. Selecione LFA1 por LIFNR para confirmar se o fornecedor existe centralmente e se SPERR e LOEVM estão em branco. Em seguida, selecione LFM1 pelo mesmo LIFNR e pela organização de compras em questão. Se nenhuma linha retornar, o fornecedor foi criado centralmente, mas nunca estendido para aquela organização de compras, que é a causa real, e não uma corrupção de dados mestre em LFA1.

ECC vs. S/4HANA

No S/4HANA, os dados mestre do fornecedor são tecnicamente armazenados através do modelo de parceiro de negócios, com LFA1 retido como uma visão de compatibilidade sobre as tabelas de parceiro de negócios subjacentes para que relatórios existentes e códigos customizados usando LIFNR continuem a funcionar. As leituras em LFA1 ainda funcionam; espera-se que a criação de novos fornecedores seja feita através da manutenção do parceiro de negócios, em vez das transações clássicas de fornecedor. O conteúdo do campo e o comportamento para dados gerais permanecem amplamente inalterados de uma perspectiva de relatório, embora a fonte da verdade tenha mudado.

Armadilhas comuns

  • Assumir que um fornecedor visível em LFA1 está pronto para aquisição ou pagamento; sem uma linha LFB1 correspondente para o código de empresa e uma linha LFM1 para a organização de compras, nenhuma transação o aceitará
  • Tratar SPERR como o único bloqueio que importa; um bloqueio de lançamento em nível de código de empresa em LFB1 ou um bloqueio em nível de organização de compras em LFM1 pode interromper uma transação mesmo quando LFA1-SPERR está em branco
  • Pesquisar por NAME1 e assumir que uma correspondência significa um fornecedor; a criação de fornecedores duplicados é comum e múltiplos valores LIFNR podem carregar nomes e endereços quase idênticos
  • Ler LOEVM como significando que o fornecedor foi excluído do banco de dados; é um flag de exclusão pendente de arquivamento, o registro mestre e todo o seu histórico ainda estão presentes e ainda podem ser unidos
  • Ignorar KTOKK ao comparar dois fornecedores que se comportam de forma diferente; o grupo de contas controla quais campos são obrigatórios ou ocultos e explica inconsistências aparentes entre registros de fornecedores
  • Esquecer que os campos de endereço e impostos em LFA1 são compartilhados globalmente; uma mudança feita para a necessidade de relatório de um código de empresa afeta todos os códigos de empresa que usam aquele fornecedor

De quem é este problema

A governança de dados mestre de fornecedor é responsabilidade da equipe de dados mestre MM ou manutenção de fornecedores, frequentemente uma função de serviços compartilhados, e não do solicitante ou comprador. A extensão para novos códigos de empresa ou organizações de compras geralmente requer uma solicitação formal através dessa equipe, pois envolve a atribuição de contas de reconciliação e condições de pagamento que as finanças também precisam concordar.

Objetos SAP relacionados

Páginas revisadas às quais este objeto se conecta no grafo de conhecimento da ERPClimb.

Fonte: ERPClimb — https://erpclimb.com/sap-tables/lfa1A ERPClimb é uma plataforma independente e não é afiliada à SAP SE. As páginas de referência são escritas e revisadas por consultores SAP para aprendizado e solução de problemas.