SAP SD: o que faz e onde as implementações falham

O SAP SD (Sales and Distribution) executa o order-to-cash no SAP: cotação, ordem de venda, remessa, faturamento e a passagem para as finanças. No S/4HANA ele muda de maneiras que afetam o escopo do projeto. Os clientes passam a ser parceiros de negócio, a gestão de crédito passa para o SAP Credit Management, os rebates passam para os contratos de condição e o faturamento lança direto no Universal Journal. Este guia é para líderes de operações de vendas, controllers financeiros e gerentes de projeto que precisam saber o que o SD faz e onde ele falha. A resposta curta sobre o segundo ponto: dados mestre de clientes, condições de preço, verificação de disponibilidade e determinação de contas. Teste esses quatro com dados reais antes do go-live.

Em um rollout depois de uma implementação SAP completa, as etapas do order-to-cash foram construídas exatamente como desenhadas. Pareciam corretas no mapa de processos. Ninguém tinha verificado como as atualizações de estoque vinham da produção.

Vendas disse aos clientes cinco dias. A manufatura sabia que eram quase dez.

Essa diferença custou mais do que entregas atrasadas. Custou confiança, e confiança é mais difícil de reconstruir do que uma configuração.

O SD fica na frente da cadeia logística. Ele transforma o interesse de um cliente em uma fatura por meio de uma cadeia de documentos:

1. Consulta: o cliente pede preço ou disponibilidade
2. Cotação: oferta formal de preço e entrega com prazo de validade
3. Ordem de venda: o cliente se compromete, a verificação de disponibilidade roda e uma data de entrega é confirmada
4. Remessa: o armazém separa e embala; a saída de mercadorias reduz o estoque
5. Faturamento: a fatura é criada junto com seu documento contábil
6. Pagamento: as finanças compensam o pagamento recebido contra a partida em aberto

Cada documento faz referência ao anterior. Esse fluxo de documentos é o que torna o order-to-cash rastreável. Se a cadeia está limpa, dá para rastrear cada fatura até o pedido original. Se os documentos são criados fora de sequência ou contornados, os relatórios quebram e as disputas aparecem.

1. 01ConsultaPreço ou disponibilidade solicitados
2. 02CotaçãoOferta formal com data de validade
3. 03Ordem de vendaA verificação de disponibilidade confirma a data
4. 04RemessaSeparação, embalagem, saída de mercadorias
5. 05FaturamentoFatura e documento contábil
6. 06PagamentoAs finanças compensam a partida em aberto

Toda fatura rastreável até o pedido original

Bem-feita, essa cadeia elimina passagens manuais. Um cliente de manufatura reduziu seu ciclo de order-to-cash em 40% depois que o SD entrou em operação, principalmente eliminando as passagens entre vendas, armazém e finanças.

Ordens de venda e a verificação de disponibilidade

O processamento de ordens de venda é onde se concentra a maior parte do esforço de configuração do SD: tipos de ordem, categorias de item, divisões de remessa e a verificação de disponibilidade.

O available-to-promise (ATP) é a peça mais crítica para o negócio. Ele verifica se a data solicitada pode ser cumprida com o estoque, os recebimentos planejados e os compromissos existentes. Bem configurado, vendas diz aos clientes aquilo com que o sistema realmente pode se comprometer. Mal configurado, vendas diz aos clientes o que espera entregar.

No rollout do início do texto, ninguém tinha verificado como as atualizações de estoque vinham da produção. Vendas estava cotando datas que a fábrica não conseguia cumprir.

Precificação e condições

A precificação é a configuração mais subestimada do SD. Parece simples até a primeira disputa de fatura.

A técnica de condições do SD trata de preços-base, descontos por cliente, faixas de volume, acréscimos, frete e impostos. Cada elemento é um tipo de condição com uma sequência de acesso, e o registro de condição guarda o valor.

O problema de precificação mais comum que vejo: condições de preço antigas, do go-live, que nunca foram atualizadas. O negócio renegocia um desconto, ninguém atualiza o registro de condição no SD, a fatura sai errada e a disputa cai no contas a receber.

A governança de preços é uma decisão de processo, não de configuração. Alguém precisa ser o dono da manutenção dos registros de condição.

Expedição

O processamento de remessas abrange separação, embalagem e saída de mercadorias. A saída de mercadorias é o evento crítico: lança a redução de estoque, coloca a remessa na lista de faturamento pendente e registra a data real de entrega. O local de expedição e a determinação de rota controlam como as remessas são criadas. As empresas com redes de distribuição complexas ampliam isso com o SAP Transportation Management (TM).

Faturamento, determinação de contas e impostos

O faturamento transforma a remessa em uma fatura e cria o documento contábil. A determinação de contas associa cada item de faturamento às contas de receita, de imposto e a outras contas do razão, com base na organização de vendas, nos grupos de atribuição de contas do cliente e do material e no tipo de condição. Quando está errada, a fatura é lançada na conta errada e as finanças só descobrem no fechamento do mês.

A determinação de impostos é igualmente frágil. Depende da classificação fiscal do cliente, da classificação fiscal do material e do país ou da jurisdição de entrega. Uma divergência pode gerar uma fatura sem imposto em uma venda tributável, ou com imposto em uma venda isenta.

Gestão de crédito

As verificações de crédito bloqueiam ou sinalizam ordens que levariam um cliente além do seu limite de crédito. Só funcionam se os limites forem mantidos. Limites estáticos definidos no go-live deixam de significar qualquer coisa à medida que o comportamento de pagamento e os volumes mudam.

Quando um limite fica abaixo do tamanho normal de pedido de um cliente, toda ordem é bloqueada automaticamente. As equipes de vendas então aprendem a liberar os bloqueios em vez de pedir uma revisão do limite.

Isso não é gestão de crédito. É um workaround.

Estes são os elementos da estrutura do SD e a que cada um se liga.

Elemento da estrutura	Finalidade no SAP SD	Ligação principal
Organização de vendas	Unidade de venda de nível mais alto, responsável pelas condições de venda e pela responsabilidade legal	Atribuída a um código de empresa no FI
Canal de distribuição	Como os produtos chegam ao cliente (atacado, varejo, direto)	Controla preços, dados mestre e determinação de parceiros
Setor de atividade	Grupo de produtos dentro da organização de vendas	Agrupamento de materiais para relatórios e saídas
Área de vendas	Organização de vendas, canal de distribuição e setor de atividade juntos	Obrigatória para todo documento de vendas e todo registro de cliente
Escritório de vendas	Unidade geográfica de vendas	Relatórios regionais e determinação de parceiros
Equipe de vendas	Time dentro de um escritório de vendas	Pessoa responsável nas ordens
Local de expedição	Local de onde as mercadorias saem	Liga o SD à gestão de armazéns e ao transporte
Centro	Unidade produtora ou fornecedora	Origem do estoque, ligada ao local de expedição

A área de vendas é a unidade operacional. Os dados de vendas do cliente são mantidos por área de vendas, e todo documento de vendas é criado em uma delas. Muitas migrações tropeçam aqui: registros de clientes legados que não se mapeiam de forma limpa para áreas de vendas exigem preparação de verdade antes da carga.

Se você está migrando do ECC, estas são as mudanças do SD a incluir no escopo. Na documentação do S/4HANA, a SAP classifica a área em “Sales”, embora a maioria das equipes ainda a chame de SD.

ECCS/4HANA

ClientesECCRegistro mestre de clienteS/4HANAParceiro de negócio com um papel de cliente

Gestão de créditoECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), não opcional

RebatesECCProcessamento de rebates do SD, reconstruído a partir de um índiceS/4HANAContratos de condição no Settlement Management

Verificação de disponibilidadeECCVerificação básica de disponibilidade de produtoS/4HANAATP avançado: alocação, backorders, centros alternativos

FaturamentoECCFI e CO reconciliados separadamenteS/4HANAUma única linha de item no Universal Journal (ACDOCA)

Reconhecimento de receitaECCLógica de diferimento customizada em muitos programasS/4HANASAP Revenue Accounting and Reporting, licenciado separadamente

1. Os clientes são parceiros de negócio. Os dados mestre de clientes são mantidos por meio do parceiro de negócio com um papel de cliente. Em uma conversão, a integração cliente-fornecedor precisa ser configurada antes de a conversão rodar.
2. A gestão de crédito passa para o SAP Credit Management. A gestão de crédito do ECC (FI-AR-CR) não está disponível no S/4HANA. O SAP Credit Management (FIN-FSCM-CR) é o seu substituto, então uma conversão precisa migrar os dados e as configurações de crédito. Não é opcional.
3. Os rebates passam para os contratos de condição. O processamento clássico de rebates do SD é substituído pelo Settlement Management (gestão de contratos de condição). As condições de rebate se aplicam imediatamente, em vez de serem reconstruídas a partir de um índice.
4. ATP avançado. O ATP avançado do S/4HANA acrescenta alocação de produtos, processamento de backorders, confirmação baseada em alternativas entre centros, liberação para remessa e atribuição de suprimento. No S/4HANA Cloud essas funções fazem parte da licença padrão. No on-premise, exigem uma licença dedicada depois de ativadas.
5. O faturamento lança no Universal Journal. FI, CO e análise de margem compartilham um único item de linha na ACDOCA, o que elimina o trabalho de reconciliação FI-CO do ECC. A contrapartida: um erro de determinação de contas é um lançamento imediato na conta errada, visível no nível do item de linha.
6. Reconhecimento de receita. Para contratos de múltiplos elementos, assinaturas ou serviços de longo prazo sob a IFRS 15, o SAP Revenue Accounting and Reporting substitui a lógica de diferimento customizada que muitos programas de ECC construíram. É licenciado separadamente e precisa ser desenhado antes do go-live, e não descoberto no fim do ano.

O clean core muda a forma de tratar a customização do SD. Na nuvem pública, código customizado no core não é possível. Na nuvem privada e no on-premise é possível, mas dificulta todo upgrade. A maioria das antigas rotinas Z de preço pode ser substituída por tipos de condição padrão, fórmulas e BAdIs. O que realmente sobra pertence a uma extensão side-by-side no SAP BTP. Meu guia de clean core trata dessa decisão.

SD com MM

A verificação de disponibilidade lê o estoque do MM, e a saída de mercadorias lança a movimentação de estoque. Se os dados de inventário estão errados, os resultados do ATP não são confiáveis. Se a saída de mercadorias falha porque o estoque não está de fato no local de expedição, a remessa não pode ser concluída e o faturamento trava. Mantenha os dois alinhados por meio dos dados mestre e da disciplina: nada de ajustes manuais de estoque que contornem os lançamentos padrão.

SD com PP

Em cenários make-to-order, uma ordem de venda pode acionar a produção diretamente, de modo que a data confirmada passa a ser um compromisso respaldado por uma ordem de produção. O grupo de estratégia no registro mestre do material controla como as ordens de venda e as previsões interagem. Se for definido errado, elas se somam em vez de se compensarem, a execução do planejamento superestima a demanda e vem a superprodução. Meu guia do SAP PP trata do lado do planejamento.

SD com FI

O documento de faturamento é a interface. Cada fatura cria um documento contábil que lança receita, imposto e a partida em aberto do cliente no Universal Journal. As condições de pagamento no registro mestre do cliente determinam o vencimento. Quando vendas negocia condições sem avisar as finanças, o sistema aplica condições que as finanças nunca acordaram.

Se o design do SD trata toda a receita como reconhecida no faturamento e os contratos dizem outra coisa, o retrofit sai caro. Acorde o reconhecimento de receita com as finanças antes de o design ser aprovado. Para o lado financeiro da integração, veja meu guia do SAP FICO.

Quatro pontos de falha causam a maior parte da dor pós-go-live.

Registro mestre de clientes não pronto. Cada campo importa mais adiante. A falta de classificação fiscal significa imposto errado. A falta de condições de pagamento significa que o FI não consegue calcular os vencimentos. A falta de condições de expedição quebra o agendamento das remessas. Os volumes são maiores e os dados de origem piores do que o plano supõe, e a limpeza exige decisões de negócio. Comece cedo e trate isso como uma frente de negócio, não como uma carga técnica. Meu texto sobre por que a migração de dados SAP falha trata do método.

Condições de preço sem manutenção. As condições do go-live que ninguém revisa viram disputas de fatura no primeiro ano.

Verificação de disponibilidade desconectada da realidade. Um ATP que lê dados desatualizados produz promessas que o negócio não consegue cumprir. Valide-o contra cenários reais de produção e de estoque, e não contra os dados de teste limpos usados nos testes unitários.

Lacunas na determinação de contas descobertas depois do go-live. Teste com o plano de contas, os códigos de imposto e os grupos de materiais reais. Códigos de imposto que não correspondem podem bloquear ordens ou provocar disputas de fatura antes que alguém perceba o que está errado.

A tabela é o checklist que eu percorreria antes da aprovação do UAT.

Risco	Impacto	Mitigação
Registro mestre de clientes incompleto	Erros de fatura, falhas de remessa, lacunas de lançamento no FI	Comece cedo a frente de dados; defina os campos obrigatórios por área de vendas antes da migração
Condições de preço desatualizadas	Disputas de fatura, receita incorreta	Nomeie um dono dos registros de condição e um ciclo de revisão no go-live
ATP desconectado do PP ou do MM	Promessas de entrega pouco confiáveis	Teste o ATP com cenários reais de planejamento antes da aprovação do UAT
Lacunas na determinação de contas	Receita lançada nas contas erradas	Teste com o plano de contas real e o conjunto completo de códigos de imposto
Liberação de bloqueios de crédito como rotina	Exposição sem controle, disputas de contas a receber	Imponha revisões de limite; acompanhe as liberações manuais nos primeiros 90 dias
Saídas não testadas	Faturas e notas de entrega não enviadas automaticamente	Teste cada tipo de saída com roteamento real de impressão e de e-mail antes do go-live
Condições de pagamento desalinhadas	Vencimentos errados, erros na previsão de caixa	Acorde as condições entre vendas e finanças antes de os dados dos clientes serem carregados

Se a equipe de vendas costuma liberar bloqueios de crédito em vez de pedir uma revisão, corrija isso nos primeiros noventa dias, antes que o hábito se consolide.

O que é o SAP SD e o que ele faz?

O SAP SD (Sales and Distribution) gerencia o order-to-cash: consultas, cotações, ordens de venda, remessas, faturamento e a passagem para a contabilidade financeira. Seu fluxo de documentos liga cada etapa à anterior, de modo que toda fatura pode ser rastreada até a ordem original. Ele se integra ao MM para estoque e saída de mercadorias, ao PP para make-to-order e disponibilidade e ao FI para receita, impostos e contas a receber.

Qual é a estrutura organizacional no SAP SD?

A unidade operacional é a área de vendas: uma organização de vendas, um canal de distribuição e um setor de atividade juntos. Todo documento de vendas é criado em uma área de vendas, e os dados de vendas do cliente são mantidos por área de vendas. Escritórios de vendas e equipes de vendas ficam abaixo, para relatórios e responsabilidades. Do lado logístico, locais de expedição e centros determinam de onde as mercadorias saem. Acerte a estrutura antes de carregar os dados dos clientes, porque mudá-la depois significa recarregar dados.

Como funciona a precificação no SAP SD?

A precificação usa a técnica de condições. Cada elemento de preço é um tipo de condição, uma sequência de acesso decide qual registro de condição se aplica e um esquema de cálculo combina os tipos de condição em ordem. A maioria das disputas de preço remonta a registros de condição que não foram atualizados quando as condições comerciais mudaram, e não a erros de configuração.

O que é o ATP avançado no SAP S/4HANA?

O advanced available-to-promise (aATP) é a verificação de disponibilidade do S/4HANA. Além da verificação básica de disponibilidade de produto, acrescenta alocação de produtos, processamento de backorders, confirmação baseada em alternativas entre centros, liberação para remessa e atribuição de suprimento. Essas funções estão incluídas no S/4HANA Cloud e exigem uma licença dedicada no on-premise depois de ativadas. Use-as onde o suprimento é restrito ou onde as regras de alocação importam. Em cadeias de suprimentos estáveis, uma verificação básica bem configurada costuma bastar.

Como o SAP SD se integra à contabilidade financeira?

Por meio do documento de faturamento. Liberar um documento de faturamento para a contabilidade cria um lançamento contábil de receita, imposto e da partida em aberto do cliente. A determinação de contas decide as contas do razão a partir da organização de vendas, dos grupos de atribuição de contas e do tipo de condição. O imposto depende das classificações fiscais do cliente e do material. As condições de pagamento no registro mestre do cliente definem o vencimento. Nos casos de IFRS 15, o SAP Revenue Accounting and Reporting diferencia e reconhece a receita ao longo do tempo.

O que muda no SAP SD na passagem do ECC para o S/4HANA?

Os clientes passam a ser parceiros de negócio. A gestão de crédito passa do FI-AR-CR para o SAP Credit Management, que é obrigatório. O processamento de rebates é substituído por contratos de condição no Settlement Management. O ATP avançado fica disponível, e o faturamento lança no Universal Journal. Coloque tudo isso no escopo desde cedo, porque cada item exige configuração, migração de dados e testes.

Quais são os erros mais comuns em implementações do SAP SD?

Cinco aparecem o tempo todo. Subestimar os dados mestre de clientes. Deixar as condições de preço sem dono depois do go-live. Testar o ATP apenas com dados limpos. Testar a determinação de contas com dados simplificados. Não testar as saídas de ponta a ponta. A última é fácil de passar despercebida. Quando as faturas não saem automaticamente, alguém começa a imprimi-las à mão, e o workaround se torna permanente.