Skip to Content
Personal Insights

Faturamento dos custos de serviço via SAP CS e SD

O objetivo desse post é fornecer uma visão geral de como a integração e utilização dos módulos de CS e SD podem funcionar como uma valiosa ferramenta para a implementação dos processos de faturamento de serviços no SAP ECC ou S/4HANA, abrangendo os diversos cenários envolvidos.

Começo com uma breve explicação sobre o fluxo do processo de serviço e em seguida forneço mais detalhes sobre as principais transações utilizadas na integração entre esses dois módulos.

Visão Geral

O faturamento baseado no apontamento de horas (mão de obra) e dos respectivos materiais utilizados na execução do serviço é uma rotina constante em empresas que fornecem esse tipo de atendimento aos seus clientes. Veja alguns exemplos de cenários que se encaixam nessa definição:

  • Reparos internos e serviços de revisão/manutenção realizados nas dependências da empresa prestadora do serviço, como por exemplo uma oficina de manutenção própria ou conveniada com uma montadora/revendedora, onde o cliente deixa o seu carro para ser revisado/reparado;
  • Reparos e visitas técnicas realizadas em campo (nas dependências do cliente). Por exemplo, quando uma empresa de TV a cabo ou internet envia um técnico na sua residência para executar uma instalação ou manutenção corretiva/preventiva;
  • Reparos externos executados através de sub-contratação de serviços.

Essa visita ao local do cliente ou mesmo a revisão/reparo realizada nas dependências do provedor do serviço muitas das vezes resulta na cobrança das horas que o técnico ou outro profissional especializado consumiu na resolução do problema.

Caso essas visitas e/ou serviços prestados não estejam cobertos por uma garantia, a empresa precisará faturar o cliente pelo serviço e peças substituídas. É nesse exato momento que a integração entre os módulos de CS e SD entra em ação.

O módulo de CS (abreviação em inglês para Customer Service, também conhecido como Service Management) é responsável pelos documentos e absorção das demandas do cliente, toda vez que o assunto envolver prestação de serviços.

O processo de reparo, ou qualquer outra solicitação de prestação de serviço, geralmente tem início no momento em que o cliente aciona o setor de pós venda ou service desk da empresa, contando o seu “problema” ou fazendo uma reclamação.

Continue lendo até o final que em seguida explicamos mais sobre o fluxo do processo de serviço e suas principais transações no SAP, utilizando como exemplo o cenário de reparo interno (o item retorna para as dependências do provedor do serviço, para a inspeção e execução do reparo).

Fluxo de processo e documentos no SAP

Fluxo Transacional do Reparo Interno (produto retorna para conserto)

Contrato de Serviço

Apesar de não ser obrigatório, é bastante comum a criação no SAP de contratos para prestação de serviços, principalmente para itens que necessitem de manutenção periódica, para negociações que envolvam faturamento contínuo e envolvam altos valores.

Contratos de serviços são criados, modificados e exibidos no SAP ECC usando as transações standards VA41, VA42, VA43, ou através de seus respectivos aplicativos no S/4HANA.

Condições de pagamento, validade dos acordos e demais parâmetros pertinentes aos serviços a serem prestados são aqui informados.

Notificação de Serviço (Service Notification)

Quando o cliente entra em contato com a prestadora do serviço, através do seu Service Desk ou outro tipo de canal de comunicação, o primeiro documento a ser criado pelo agente é a Notificação de Serviço, representado no SAP através da transação IW51.

Essa notificação pode ser criada com ou sem referência à um contrato de serviço. É aqui onde o agente responsável pelo primeiro contato com o cliente documentará detalhadamente o problema relatado e as solicitações de serviços.

O equipamento é um dado mestre compartilhado entre os módulos de PM e CS, que é criado através da transação IE01 ou de maneira automatizada. Ele deverá ser informado na Notificação, pois é quem identifica de maneira única a relação  “produto + número de série”  do item a ser reparado / revisado. Outra função importante do equipamento é o seu link com possíveis garantias fornecidas pelo fabricante do produto. É através desse link que identificamos se o serviço está coberto pela garantia ou se o cliente será cobrado por eventuais reparos.

O número do equipamento acompanha o produto durante todo o seu ciclo de vida, e serve como um identificador único, fornecendo para o atendente e todo o time de serviço um histórico completo do item, incluindo reparos anteriormente executados e possíveis garantias vigentes.

Normalmente um supervisor da área de suporte ao cliente revisa o chamado e o endereça para um técnico, identificando na notificação o responsável pela tratativa do problema/solicitação.

Ordem de Reparo (Repair Order)

O próximo passo no fluxo de processo é criar a Ordem de Reparo com referência ao documento de Notificação de Serviço. Essa Ordem de Reparo é um documento do módulo de SD, do tipo “RA” ou “RAS”, que fica armazenado nas tabelas VBAK, VBAP, etc.

A criação da Ordem de Reparo é possível a partir da própria notificação (IW52) que gerará o documento de SD, contendo o item (material) a ser reparado ou revisado. Ela poderá ser alterada ou exibida utilizando as transações VA02 e VA03, respectivamente.

Esse item da Ordem de Reparo não é relevante para faturamento, servindo apenas como referência para o registro do item retornando para conserto, dando entrada no estoque temporário “consignado” do cliente, por exemplo utilizando o tipo de movimento 653.

Esse movimento de entrada é opcional e depende de como a empresa pretende controlar o estoque de terceiros em seu poder.

É com base nesse item de entrada da Ordem de Reparo que será criada a Solicitação de Faturamento, sobre o qual falamos um pouco mais à frente.

Ordem de Serviço (Service Order)

Dependendo de como o sistema é configurado, é comum que a Ordem de Serviço seja criada automaticamente com referência ao item da Ordem de Reparo. Ela poderá ser alterada ou exibida, respectivamente, através das transações IW32 e IW33.

É na Ordem de Serviço onde efetivamente o(s) técnico(s) informa(m) o(s) reparo(s) que precisa(m) ser executados, eventuais peças a serem substituídas, centro de trabalho e estimam data de início e previsão de conclusão do serviço.

A ordem de serviço funciona como um grande coletor de custos para o faturamento subsequente. É comum também que um WBS (acrônimo para “Work Breadkdown Structure” em inglês, ou “Elemento PEP” em português) seja informado na Ordem de SD, toda vez que o reparo, revisão ou serviço tenha uma estrutura projetizada, normalmente para serviços de longa duração e que envolvam várias ordens de serviço. Nesse caso, todas as ordens de serviços criadas debaixo do mesmo “guarda-chuva” ficam associadas ao mesmo WBS.

Todo material do estoque da empresa que for usado durante a execução do serviço, por exemplo em substituição a uma peça danificada, provoca um lançamento de custo de material contra uma conta WIP (Work in Progress) , utilizando o preço standard ou o preço médio móvel do item, até que o faturamento seja realizado e o custo da venda efetivamente reconhecido (COGS- Cost of Goods Sold). Os tipos de movimentos standards 261 e 262 são usados para movimentar os itens de estoque contra as ordens de serviço.

Posteriormente, as horas trabalhadas (timesheet) são confirmadas manualmente ou através de algum processo automatizado usando as transações IW41, IW44, etc. O processo de confirmação de horas alimenta o módulo de CO, fornecendo o custo das horas trabalhadas por ordem de serviço. NO SAP ECC esses custos são armazenadas em tabelas como COVP e COEP.

Solicitação de Faturamento (Billing Request)

Para faturar o cliente pelos serviços executados e eventuais materiais utilizados durante o reparo (spare parts), é necessário que o time de faturamento crie o documento mais importante de SD para esse cenário: a Solicitação de Faturamento (em inglês, Billing Request) , através das transações DP90 ou DP95.

A transação DP90 é utilizada para faturamento individual, ou seja, na tela inicial o usuário só consegue informar o número de 1 ordem de serviço ou de 1 ordem de SD (ordem de reparo) como parâmetro de seleção:

DP90%3A%20tela%20de%20sele%E7%E3o

DP90: tela de seleção

Já a transação DP95 permite fazer processamento coletivo (em massa), ou seja, processando um intervalo de ordens de serviço ou de reparos (SD) ao mesmo tempo:

DP95%3A%20tela%20de%20sele%E7%E3o

DP95: tela de seleção

O documento de Solicitação de Faturamento criado através das transações DP90 ou DP95 é o elemento faturável no módulo de SD, onde o time de faturamento revisará a determinação de preço, impostos, condições de pagamento, dados de nota fiscal na pasta “país” e outras determinações necessárias ao processo. As transações VA02 e VA03 podem ser utilizadas para modificar e exibir, respectivamente, o documento de solicitação de faturamento.

Ao executar as transações DP90 ou DP95, o módulo de CS chama uma funcionalidade nativa do SAP conhecida como RRB (Resource-Related Billing), que possui toda uma engenharia de busca dos custos alocados (planejados ou real) contra as ordens de serviços, e os transfere para o documento de Solicitação de Faturamento no formato de itens (linhas).

Os custos referentes as horas de mão de obra aparecem no Billing Request agrupados por tipo de serviço, enquanto os materiais são listados individualmente, totalizados por quantidade, refletindo a informação que precisará aparecer no documento de faturamento e na nota fiscal. O valor do custo é determinado automaticamente no tipo de condição EK01, sendo exibido na pricing do item.

Toda essa “mágica” de criar o Billing Request baseado em custos, utilizando a funcionalidade de RRB , se dá através da configuração do DIP profile (Dinamyc Item Processor profile) através das transações ODP1 e ODP2, cuja parametrização detalharemos em um próximo post.

Com relação à determinação de preços no documento de Solicitação de Faturamento (Billing Request), o cálculo poderá variar de acordo com o cenário e utiliza as funcionalidades de pricing existentes no módulo de SD, como por exemplo:

  • Preço baseado em cotação
  • Preço baseado em contrato Time & Material
  • Preço Fixo
  • Lista de preços de materiais

Nota: Alternativamente, ao executar a transação DP90 ou DP95 há também a possibilidade de transferir os itens que serão faturados para a Ordem de Reparo, ao invés de criar o documento de Solicitação de Faturamento. Ambos os cenários são possíveis de serem implementados e dependerá da arquitetura a ser adotada pelo time de projeto.

Faturamento e Cobrança

Uma vez que o Billing Request é revisado e aprovado, o próximo passo é gerar o documento de faturamento da mesma forma que é feito para qualquer outro cenário de venda no SAP, por exemplo utilizando as transações VF01 ou VF04.

Com relação à  Nota Fiscal, é comum a adoção de modelo de nota fiscal eletrônica conjugada sempre que houver itens de material e serviço no mesmo faturamento. Caso hajam apenas itens de serviço, então uma Nota Fiscal de Serviço é determinada.

Retorno do item reparado para o cliente

Uma vez que o serviço é concluído e o processo de faturamento executado, é necessário retornar com o item reparado para o cliente, registrando a sua saída do estoque “consignado” do cliente.

Conclusão

Apesar do módulo de CS não ser nenhuma novidade no mundo SAP, muita gente ainda desconhece qual é a sua aplicação prática.

Eu o classificaria como uma poderosa ferramenta de back-end que suporta grande parte dos processos de serviços ao cliente. Quando integrado com outras  soluções de Customer Experience, como por exemplo os produtos de front-end  SAP Field Service Management (FSM) e/ou o SAP Service Cloud (C4C), a experiência do cliente e do time de suporte/serviços da empresa se torna ainda mais completa.

Espero que essas dicas tenham ajudado a melhorar o seu entendimento sobre como o módulo de CS se aplica aos processos de faturamento de serviços, bem como sua integração com o módulo de SD, de uma forma geral e independente do tipo de indústria em que eles estejam inseridos.

Até o nosso próximo post!

2 Comments
You must be Logged on to comment or reply to a post.
  • /
    • Hi Diamila,

      Very nice input from your end! I love how C4C Service can fill the gap, providing great user experience when integrated with backend SAP CS.

      Best Regards