Fluxo Transacional do Reparo Interno (produto retorna para conserto)
O objetivo desse post é fornecer uma visão geral de como a utilização e integraçã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, além é claro de conectar os custos incorridos com o valor a ser faturado do cliente.
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/ou dos respectivos materiais consumidos 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:
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 pela criação de 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).
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.
Nota ou 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 Nota de Serviço (também conhecida como notificação), representado no SAP através da transação IW51. Ela é uma espécie de chamado ou ticket.
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. É comum que o consultor de CS crie catálogos de serviços para que o agente capture os sintomas e as prováveis causas do problema, bem como documente as ações e atividades a serem executadas para a resolução do mesmo.
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, entre outras.
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.
Na ordem de reparo será informado o item de serviço (material DIEN) e o código do item que o cliente envia para inspeção, ambos previamente existentes no cadastro do material.
Para o código do material que é enviado pelo cliente para reparo será criado um documento de remessa subsequente, para registrar a entrada do mesmo em estoque de terceiro em poder da empresa, utilizando por default o tipo de movimento 653 (com indicação de estoque especial E).
Esse movimento de entrada é opcional e depende de como a empresa pretende controlar o estoque de terceiros em seu poder.
É com base no item de serviço (DIEN) da ordem de reparo que será criado o documento de 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. O tipo de documento SM03 é automaticamente gerado como padrão pelo SAP.
É 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, material de consumo, centro de trabalho e estimam data de início, duração 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" são associadas com um único WBS.
Os tipos de movimentos standards 261 e 262 são usados para consumir e reverter o consumo do estoque para a ordem de serviço, respectivamente.
As horas efetivas trabalhadas são confirmadas manualmente ou através de algum processo automatizado usando as transações IW41, IW44, etc. Assim como acontece com a baixa de material do estoque próprio para a ordem de serviço, o processo de confirmação de horas também alimenta o módulo de CO, fornecendo o custo das horas trabalhadas por ordem de serviço e tipo de atividade. NO SAP ECC esses custos são armazenados em tabelas como COVP e COEP.
Solicitação de Faturamento (Billing Request)
Para faturar o cliente pelos serviços executados e eventuais materiais de estoque consumidos 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:
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:
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).
No processo de reparo interno utilizando o tipo de ordem de reparo RAS e ordem de serviço SM03, o sistema não cria um novo documento de solicitação de faturamento. Ao invés disso, ao rodar a transação DP90 ou DP95, os custos provenientes da ordem de serviço são inseridos em formato de novas linhas dentro da própria ordem RAS, como subitens de custo do item principal do serviço sendo prestado.
Os custos referentes as horas de mão de obra aparecem na solicitação de faturamento agrupados por tipo de atividade, enquanto os materiais são listados individualmente, geralmente totalizados por quantidade, refletindo a informação que precisará aparecer no documento de faturamento e na nota fiscal. O valor do custo real é 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:
Faturamento e Cobrança
Uma vez que a solicitação de faturamento é revisada e aprovada, 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.
Nota: é comum a criação de tipo de ordens adicionais em SD para registrar a nota de entrada recebida junto com o item do cliente a ser reparado, e uma outra para retornar com o produto reparado/consertado para o cliente. Como o SAP CS não foi originalmente desenhado levando em conta os cenários da localização Brasil, então é necessário um esforço adicional para controlar as notas dessa etapa do processo. Como experiência própria, algumas empresas costumam implementar uma espécie de monitor para registrar e gerar essas notas fiscais adicionais do processo, ou algum outro tipo de automação ABAP, visto que a ordem de reparo RAS gerará apenas a nota fiscal de serviço ou conjugada para faturar o cliente pelo reparo realizado.
Conclusão
Apesar do módulo de CS não ser nenhuma novidade no mundo SAP, é comum que muitos consultores ou usuários nunca tenham ouvido falar da ferramenta.
É 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!
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/ou dos respectivos materiais consumidos 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 subcontratação de serviços, em sua totalidade ou parcialmente para componentes cujo conserto/substituição precisa ser feito por um terceiro.
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 pela criação de 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).
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.
Nota ou 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 Nota de Serviço (também conhecida como notificação), representado no SAP através da transação IW51. Ela é uma espécie de chamado ou ticket.
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. É comum que o consultor de CS crie catálogos de serviços para que o agente capture os sintomas e as prováveis causas do problema, bem como documente as ações e atividades a serem executadas para a resolução do mesmo.
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, entre outras.
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.
Na ordem de reparo será informado o item de serviço (material DIEN) e o código do item que o cliente envia para inspeção, ambos previamente existentes no cadastro do material.
Para o código do material que é enviado pelo cliente para reparo será criado um documento de remessa subsequente, para registrar a entrada do mesmo em estoque de terceiro em poder da empresa, utilizando por default o tipo de movimento 653 (com indicação de estoque especial E).
Esse movimento de entrada é opcional e depende de como a empresa pretende controlar o estoque de terceiros em seu poder.
É com base no item de serviço (DIEN) da ordem de reparo que será criado o documento de 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. O tipo de documento SM03 é automaticamente gerado como padrão pelo SAP.
É 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, material de consumo, centro de trabalho e estimam data de início, duração 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" são associadas com um único WBS.
Os tipos de movimentos standards 261 e 262 são usados para consumir e reverter o consumo do estoque para a ordem de serviço, respectivamente.
As horas efetivas trabalhadas são confirmadas manualmente ou através de algum processo automatizado usando as transações IW41, IW44, etc. Assim como acontece com a baixa de material do estoque próprio para a ordem de serviço, o processo de confirmação de horas também alimenta o módulo de CO, fornecendo o custo das horas trabalhadas por ordem de serviço e tipo de atividade. NO SAP ECC esses custos são armazenados em tabelas como COVP e COEP.
Solicitação de Faturamento (Billing Request)
Para faturar o cliente pelos serviços executados e eventuais materiais de estoque consumidos 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: 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: 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).
No processo de reparo interno utilizando o tipo de ordem de reparo RAS e ordem de serviço SM03, o sistema não cria um novo documento de solicitação de faturamento. Ao invés disso, ao rodar a transação DP90 ou DP95, os custos provenientes da ordem de serviço são inseridos em formato de novas linhas dentro da própria ordem RAS, como subitens de custo do item principal do serviço sendo prestado.
Os custos referentes as horas de mão de obra aparecem na solicitação de faturamento agrupados por tipo de atividade, enquanto os materiais são listados individualmente, geralmente totalizados por quantidade, refletindo a informação que precisará aparecer no documento de faturamento e na nota fiscal. O valor do custo real é 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: nesse caso geralmente aplica-se um markup sobre o valor do custo da mão de obra, levando em consideração as horas reais trabalhadas. Os materiais de estoque consumidos para a ordem de serviço geralmente são faturados com preço de revenda;
- Preço Fixo: independente do custo de mão de obra incorrido e dos materiais consumidos, nesse tipo de faturamento utiliza-se uma taxa fixa como preço de faturamento do serviço. O item principal da ordem RAS é relevante para faturamento, não os subitens (linhas de custos).
Faturamento e Cobrança
Uma vez que a solicitação de faturamento é revisada e aprovada, 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.
Nota: é comum a criação de tipo de ordens adicionais em SD para registrar a nota de entrada recebida junto com o item do cliente a ser reparado, e uma outra para retornar com o produto reparado/consertado para o cliente. Como o SAP CS não foi originalmente desenhado levando em conta os cenários da localização Brasil, então é necessário um esforço adicional para controlar as notas dessa etapa do processo. Como experiência própria, algumas empresas costumam implementar uma espécie de monitor para registrar e gerar essas notas fiscais adicionais do processo, ou algum outro tipo de automação ABAP, visto que a ordem de reparo RAS gerará apenas a nota fiscal de serviço ou conjugada para faturar o cliente pelo reparo realizado.
Conclusão
Apesar do módulo de CS não ser nenhuma novidade no mundo SAP, é comum que muitos consultores ou usuários nunca tenham ouvido falar da ferramenta.
É 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!
- SAP Managed Tags:
5 Comments
