- SAP Managed Tags:
O objetivo desse post é fornecer uma visão geral da solução SAP para o gerenciamento de reivindicações (solicitações) de garantia utilizando o módulo de CS (Customer Service). A ideia aqui é falar um pouco sobre o fluxo do processo e apresentar a ferramenta de maneira genérica, para quem nunca ouviu falar ou nunca teve a oportunidade de trabalhar com a solução.
O SAP possui uma ferramenta nativa para gerenciar todo o fluxo de reivindicação de garantia de produtos ou serviços adquiridos, conhecido em inglês como Warranty Claim Management.
De uma forma geral, todo produto possui uma garantia padrão, concedida por requisitos legais ou comerciais, onde o fabricante do produto geralmente é o responsável por substituir o item defeituoso por um novo, consertá-lo ou, em último caso, realizar a devolução do dinheiro ao cliente.
Existem diversos cenários que podem ser considerados em um fluxo que envolva o processo de reivindicação de garantia, e um desenho bem elaborado da solução envolverá as seguintes questões:
Exemplo de fluxo do processo de garantia
Cenário: O cliente solicita o reparo em garantia diretamente com a oficina autorizada, que não faz parte da mesma empresa do fabricante do produto. A autorizada possui SAP e cria a reivindicação para o cliente. O fabricante pode utilizar o SAP ou não, mas como nesse cenário ele não é o nosso foco, logo não trataremos em que sistema ele recebe e responde as solicitações da autorizada.
Quem são os atores envolvidos nesse processo?
E para quem a solução de reivindicação de garantias se aplica?
E quando não vale a pena utilizar essa solução?
Transação WTY
A principal transação da solução de gerenciamento de reivindicações de garantia é a WTY. É nela onde são registradas as reivindicações dos clientes, as solicitações de aprovação de orçamentos feitos pelas empresas prestadoras de serviços aos fabricantes, a validade da garantia solicitada pelo cliente, as aprovações por parte do fabricante e possíveis contestações por parte do cliente, fabricante ou prestador de serviço. Ou seja, todas as etapas do processo passam de uma forma ou outra pela WTY.
Uma das principais funcionalidades da transação WTY é checar automaticamente se os requisitos que cobrem a garantia contratual se aplicam ao item para qual o reparo está sendo solicitado, com base no objeto técnico informado (equipamento, material, functional location, etc) e demais informações coletadas do cliente.
Versões da Reivindicação (Warranty Claim Versions)
Um dos principais recursos da transação WTY é o conceito de "versão", e um perfeito entendimento dessa funcionalidade é de fundamental importância para que você consiga configurar no SAP o cenário de acordo com a necessidade da empresa.
Cada solicitação, resposta ou contestação gera uma versão nova do documento de reivindicação, e indica a direção da solicitação (de quem / para quem). Existem 4 tipos de versões disponíveis na WTY e que serão utilizadas de acordo com o cenário sendo implementado. Note que existem inúmeras possibilidades de uso do esquema de versionamento da WTY. Nem todas são obrigatórias, e caberá à equipe do projeto decidir quais deseja implementar baseado no desenho do processo da empresa:
Todas as versões criadas na WTY ficam armazenadas, com suas respectivas informações preservadas. Não há sobreposição de versões. Aliás, a ideia é exatamente essa, manter um histórico preservando todas as etapas do fluxo, desde a solicitação até a aprovação e o encerramento do caso. As versões ficam visíveis na árvore localizada do lado esquerdo da tela (conforme mostrado na figura abaixo), e ao clicar em cada uma dela, o detalhamento com as respectivas informações são exibidas, incluindo o "parceiro" da interação naquela respectiva versão.
Botão "Ações" na WTY
A execução de ações na transação WTY é outro ponto importante a ser considerado em qualquer implementação. É através do botão "Actions" que avançamos nas etapas do fluxo de solicitação de garantia e o sistema entende quais os próximos passos que precisam ser executados.
Além de definir o status atual da versão, ao clicar nesse botão , o sistema poderá por exemplo enviar a reivindicação para aprovação do reembolsador ou criar uma nova versão contestando os valores aprovados.
Resumindo, é através das "ações" que as coisas acontecem na transação WTY : alteração de status do documento/versão, solicitação da aprovação, envio da versão da solicitação para o cliente ou reembolsador, geração de nota de crédito ou débito (lançamento contábil em FI e CO), geração de outputs (Idoc, PDF, email) para a partes interessadas, entre outras atividades.
Determinação automática de preço nos itens da garantia
Para cada versão e tipo de reivindicação de garantia, é possível configurar a determinação automática de preço para os valores a serem reembolsados, refletindo os acordos entre a parte solicitante (cliente, prestador de serviço) e o fabricante (reembolsador). A determinação automática de preços, taxas, descontos e impostos ocorrem da mesma forma que acontece no módulo de SD e MM, ou seja, através da utilização de esquema de cálculo específico e cadastro prévio dos valores nos registros de condições. É possível cadastrar valores por exemplo por fornecedor (prestador do serviço) ou por reembolsador (fabricante) para os itens de mão de obra, materiais e eventuais taxas (handling fees).
Determinação automática de Outputs via WTY
Sempre que você precisar gerar um documento (por exemplo um arquivo PDF contendo a lista com as horas gastas para reparar o produto, as peças que precisam ser substituídas, taxas contratuais de inspeção do produto) e enviar manualmente ou automaticamente via e-mail, IDOC/EDI, Web services, a solução permite configurar ações que executem essas tarefas.
Poderá também criar um output para informar o cliente sobre a finalização do reparo ou solicitar que ele envie o item para a oficina, por exemplo em até 10 dias, fornecendo um código de postagem gratuita nos Correios.
A determinação de outputs através das ações executadas na WTY segue o mesmo conceito que existe nos módulo de SD.
Cenários contábeis do processo de garantia:
Um outro ponto a ser considerado na hora de criar o documento de reivindicação na WTY é com relação à escolha do cenário contábil:
Criação dos documentos contábeis do processo de garantia:
Uma das etapas finais da execução da transação WTY é gerar o documento contábil para debitar o reembolsador, criando as partidas em abertos de FI, até que o reembolso seja efetuado e o documento baixado.
Se o fabricante (reembolsador) estiver controlando as solicitações através da transação WTY (supondo que ele também utilize o SAP), ao aprovar a solicitação de garantia/reembolso feita pelo prestador de serviço, ele executará uma ação para automaticamente gerar a nota de crédito e então pagar pelo serviço realizado (ou a ser realizado).
De novo, o usuário precisa escolher a ação correta na WTY para gerar os lançamentos em FI.
Dados Mestres
Principais configurações no SAP
A solução standard da SAP já vem com alguns modelos e é bastante customizável e flexível. Como ela visa atender todos os tipos de empresas e cenários, dificilmente você vai conseguir utilizar somente o que vem como modelo. É preciso primeiro entender bastante como o processo funciona, independente de sistema, e depois partir para o desenho da solução, pensando no fluxo de ações e documentos, quais versões seriam realmente aplicáveis, quais as ações que pretende habilitar para o usuário em cada uma das versões na WTY, e por aí vai. Utilize os modelos entregues pela SAP para criar a sua própria configuração de negócio.
Uma vez que o processo da empresa é entendido, utilize a transação OWTY para chamar a árvore que contém a maioria das entradas e opções de configuração para o processo de reivindicação de garantias.
Como o objetivo desse post não é detalhar as configurações, segue abaixo algumas das principais configurações que você precisará fazer, dependendo do seu projeto:
Automatização do fluxo de entrada e envio das reivindicações de garantia
Se o volume de reivindicações de garantia for muito alto e/ou o reembolsador ou prestador do serviço requerer alguma forma de automatização no processo de envio e recebimento da informação, muito provavelmente será necessário desenvolver algumas interfaces para que o fluxo de documentos de entrada e saída ocorram de forma automatizada.
Por exemplo, o fabricante, revendedor ou o prestador do serviço poderá já possuir um portal web onde o cliente possa solicitar o reparo em garantia do produto danificado. Ao receber essa solicitação, um serviço web/EDI poderá criar a primeira versão da reivindicação no SAP de forma automática, dispensando a presença de algum funcionário fazendo o trabalho manual.
O envio detalhado com o orçamento do trabalho a ser feito (mão de obra, peças a serem substituídas, etc) poderá ser enviado para o reembolsador (fabricante) de forma automatizada, por exemplo através de um arquivo XML, sendo enviado utilizando Idoc via EDI. O mesmo poderá acontecer com relação ao retorno da aprovação, dos respectivos ajustes ou até mesmo uma eventual recusa, enviada pelo reembolsador para o prestador de serviço, automatizando a captura da informação de entrada e criando uma nova versão da reivindicação na WTY.
Caso utilizem por exemplo o SAP C4C Service (Cloud for Customer), é possível receber as solicitações de clientes via e-mail, telefone, redes sociais (como facebook e twitter) , e após a geração de um tícket no sistema C4C, automatizar a criação da reivindicação de garantia no SAP CS (transação WTY).
Resumindo, considero uma boa solução principalmente para aquelas empresas que já utilizam o SAP e necessitam gerenciar um volume considerável de reivindicações de garantia. Afinal, ela foi pensada para facilitar a vida das empresas. Para que a solução seja mais eficiente, é preciso customizá-la de acordo com os processos da empresa, e realizar as integrações necessárias com os sistemas internos e externos, tornando-a mais automatizada.
O SAP possui uma ferramenta nativa para gerenciar todo o fluxo de reivindicação de garantia de produtos ou serviços adquiridos, conhecido em inglês como Warranty Claim Management.
De uma forma geral, todo produto possui uma garantia padrão, concedida por requisitos legais ou comerciais, onde o fabricante do produto geralmente é o responsável por substituir o item defeituoso por um novo, consertá-lo ou, em último caso, realizar a devolução do dinheiro ao cliente.
Existem diversos cenários que podem ser considerados em um fluxo que envolva o processo de reivindicação de garantia, e um desenho bem elaborado da solução envolverá as seguintes questões:
- Quem é responsável por coletar a reivindicação de garantia do cliente? O fabricante ou a empresa/oficina autorizada que realizará o reparo?
- Quem realizará o reparo? Algum fornecedor de serviço autorizado (externo) ou a própria empresa que fabricou o produto (interno)?
- Se for realizado pela própria empresa, haverá participação de alguma filial ou subsidiária no processo de reparo que justifique um pagamento pelos serviços prestados?
- Através de quais canais a solicitação do cliente será recebida (portal web, telefone, e-mail, redes sociais)? Haverá alguma automatização do processo via EDI ou web service?
- Como será realizada a comunicação entre as partes interessadas (fabricante, prestador do serviço de garantia, clientes)?
Exemplo de fluxo do processo de garantia
Cenário: O cliente solicita o reparo em garantia diretamente com a oficina autorizada, que não faz parte da mesma empresa do fabricante do produto. A autorizada possui SAP e cria a reivindicação para o cliente. O fabricante pode utilizar o SAP ou não, mas como nesse cenário ele não é o nosso foco, logo não trataremos em que sistema ele recebe e responde as solicitações da autorizada.
Exemplo de Fluxo de Garantia
Quem são os atores envolvidos nesse processo?
- O solicitante ou reivindicador da garantia (em inglês: "claimant") : dependendo do ponto de vista , o solicitante poderá ser o cliente ou a empresa que está realizando o reparo do produto. O cliente sempre fará parte desse cenário, pois é quem comprou o produto e está reivindicando o reparo ou a troca do mesmo. A empresa responsável por receber o equipamento e executar o reparo é também chamado de reivindicador, pois é ela quem pedirá autorização ao fabricante do produto para executar o reparo e o reembolso pelo trabalho a ser executado.
- O reembolsador (em inglês: "reimburser"): é geralmente o fabricante, aquele que paga pelo reparo e reembolsa o prestador do serviço (seja interno ou externo) pelo conserto do produto do cliente. Se o reparo não for possível ou não compensar, é o reembolsador quem gera um credito para o cliente ou realiza a troca do produto por um novo.
E para quem a solução de reivindicação de garantias se aplica?
- Empresas responsáveis pela realização do reparo (fornecedor/prestador do serviço), cuja obrigação de fornecer a garantia seja de uma outra empresa (o fabricante): nesse caso, a prestadora do serviço é quem solicita a aprovação do reparo ao fabricante. O fabricante é responsável por reembolsar a prestadora do serviço pelos materiais e mão de obra utilizados no processo de reparo da peça/produto do cliente.
- Empresa prestadora do serviço que pertença ao mesmo grupo do fabricante. Nesse caso pode ser uma filial, uma subsidiária (cenário intercompany) ou escritório regional responsável pela execução do reparo. A matriz (fabricante) executa o papel de aprovar a solicitação do cliente e autorizar o reparo para a prestadora de serviço interno, sendo responsável pelo reembolso das despesas do reparo.
- Empresas que queiram utilizar a solução SAP para solicitar reembolso, troca ou reparo de peças e partes em garantia aos seus respectivos fornecedores, por exemplo, de itens de estoque ou mesmo de equipamentos comprados para a linha de produção ou outro tipo de ativo.
E quando não vale a pena utilizar essa solução?
- Sempre que não houver o pagamento (reembolso) pelos serviços do reparo prestados, então utilizar a solução de reivindicação de garantias não se aplica. O custo e todo o trabalho que a empresa terá para customizar a solução standard não justifica por exemplo, utilizar a ferramenta apenas para captar a solicitação do cliente, uma vez que não haverá pagamento entre empresas (internas ou externas). Esse é o caso quando o próprio fabricante é responsável também por realizar o reparo no produto do cliente, sem que haja um prestador de serviço ou outra empresa/filial do mesmo grupo envolvido no processo. Utilize os dados mestres de garantia (que explicamos a seguir) e do equipamento para controlar se o item retornando para reparo se encontra em garantia e, nesse caso, não fatura o cliente.
Transação WTY
A principal transação da solução de gerenciamento de reivindicações de garantia é a WTY. É nela onde são registradas as reivindicações dos clientes, as solicitações de aprovação de orçamentos feitos pelas empresas prestadoras de serviços aos fabricantes, a validade da garantia solicitada pelo cliente, as aprovações por parte do fabricante e possíveis contestações por parte do cliente, fabricante ou prestador de serviço. Ou seja, todas as etapas do processo passam de uma forma ou outra pela WTY.
Uma das principais funcionalidades da transação WTY é checar automaticamente se os requisitos que cobrem a garantia contratual se aplicam ao item para qual o reparo está sendo solicitado, com base no objeto técnico informado (equipamento, material, functional location, etc) e demais informações coletadas do cliente.
Versão 1 (inicial) da transação WTY, com os dados capturados do cliente.
Versões da Reivindicação (Warranty Claim Versions)
Um dos principais recursos da transação WTY é o conceito de "versão", e um perfeito entendimento dessa funcionalidade é de fundamental importância para que você consiga configurar no SAP o cenário de acordo com a necessidade da empresa.
Cada solicitação, resposta ou contestação gera uma versão nova do documento de reivindicação, e indica a direção da solicitação (de quem / para quem). Existem 4 tipos de versões disponíveis na WTY e que serão utilizadas de acordo com o cenário sendo implementado. Note que existem inúmeras possibilidades de uso do esquema de versionamento da WTY. Nem todas são obrigatórias, e caberá à equipe do projeto decidir quais deseja implementar baseado no desenho do processo da empresa:
- Do solicitante (em inglês: "from claimant"): é a versão do documento de reivindicação que contém basicamente os dados do cliente e do produto/equipamento para o qual o reparo em garantia está sendo solicitado. Nesse caso é importante informar no campo "parceiro" da solicitação o código do cliente. Dependendo da regra de negócio, o primeiro contato por parte do cliente solicitando o reparo poderá ser feito ao fabricante ou diretamente à empresa/autorizada que realizará o reparo. A empresa fabricante do produto também poderá utilizar essa versão para registrar no seu SAP a reivindicação enviada pela prestadora do serviço, contendo por exemplo o orçamento com os custos previstos de mão de obra e materiais a serem utilizados para reparar o item do cliente.
- Para o reembolsador ( em inglês: "to reimburser"): é a versão enviada pelo prestador do serviço (interno ou externo) ao reembolsador, contendo os detalhes do reparo a ser feito no item do cliente. No exemplo da figura abaixo, a J&J Equipamentos é o reembolsador da solicitação.
- Do reembolsador (em inglês: "from reimburser"): é a versão recebida pelo prestador de serviço, com a resposta enviada pelo reembolsador da garantia (fabricante). Nela estarão os valores aprovados e possíveis ajustes feito pelo reembolsador do que de fato poderá ser feito, ou até mesmo eventuais recusas.
- Para o solicitante (em inglês: "to claimant"): é a versão final com a resposta enviada pelo prestador do serviço ou o próprio fabricante ao cliente, contendo por exemplo o resultado do que será feito: garantia aprovada ou reprovada, o produto será substituído, reparado ou em último caso ele terá o dinheiro reembolsado. Dependendo do cenário, pode ser também a versão com a resposta a ser enviada pelo reembolsador ao prestador do serviço, contendo as aprovações e ajustes referentes aos valores a serem reembolsados pelos serviços prestados.
Todas as versões criadas na WTY ficam armazenadas, com suas respectivas informações preservadas. Não há sobreposição de versões. Aliás, a ideia é exatamente essa, manter um histórico preservando todas as etapas do fluxo, desde a solicitação até a aprovação e o encerramento do caso. As versões ficam visíveis na árvore localizada do lado esquerdo da tela (conforme mostrado na figura abaixo), e ao clicar em cada uma dela, o detalhamento com as respectivas informações são exibidas, incluindo o "parceiro" da interação naquela respectiva versão.
Versão 2 com os dados do reparo para o Reeembolsador
Botão "Ações" na WTY
A execução de ações na transação WTY é outro ponto importante a ser considerado em qualquer implementação. É através do botão "Actions" que avançamos nas etapas do fluxo de solicitação de garantia e o sistema entende quais os próximos passos que precisam ser executados.
Além de definir o status atual da versão, ao clicar nesse botão , o sistema poderá por exemplo enviar a reivindicação para aprovação do reembolsador ou criar uma nova versão contestando os valores aprovados.
Resumindo, é através das "ações" que as coisas acontecem na transação WTY : alteração de status do documento/versão, solicitação da aprovação, envio da versão da solicitação para o cliente ou reembolsador, geração de nota de crédito ou débito (lançamento contábil em FI e CO), geração de outputs (Idoc, PDF, email) para a partes interessadas, entre outras atividades.
Determinação automática de preço nos itens da garantia
Para cada versão e tipo de reivindicação de garantia, é possível configurar a determinação automática de preço para os valores a serem reembolsados, refletindo os acordos entre a parte solicitante (cliente, prestador de serviço) e o fabricante (reembolsador). A determinação automática de preços, taxas, descontos e impostos ocorrem da mesma forma que acontece no módulo de SD e MM, ou seja, através da utilização de esquema de cálculo específico e cadastro prévio dos valores nos registros de condições. É possível cadastrar valores por exemplo por fornecedor (prestador do serviço) ou por reembolsador (fabricante) para os itens de mão de obra, materiais e eventuais taxas (handling fees).
Determinação automática de Outputs via WTY
Sempre que você precisar gerar um documento (por exemplo um arquivo PDF contendo a lista com as horas gastas para reparar o produto, as peças que precisam ser substituídas, taxas contratuais de inspeção do produto) e enviar manualmente ou automaticamente via e-mail, IDOC/EDI, Web services, a solução permite configurar ações que executem essas tarefas.
Poderá também criar um output para informar o cliente sobre a finalização do reparo ou solicitar que ele envie o item para a oficina, por exemplo em até 10 dias, fornecendo um código de postagem gratuita nos Correios.
A determinação de outputs através das ações executadas na WTY segue o mesmo conceito que existe nos módulo de SD.
Cenários contábeis do processo de garantia:
Um outro ponto a ser considerado na hora de criar o documento de reivindicação na WTY é com relação à escolha do cenário contábil:
- Crédito Posterior (em inglês: "post-crediting"): nesse cenário o reparo ou a substituição do produto não ocorre até que a reivindicação de garantia seja enviada ao fabricante (reembolsador). Uma vez que o prestador do serviço (solicitante) recebe autorização para execução do serviço, então o reparo é iniciado. Esse costuma ser o cenário mais comum.
- Antecipação de Crédito (em inglês: “pre-crediting”): nesse cenário o crédito para a execução do serviço é gerado antecipadamente pelo fabricante (reembolsador) e somente em um momento posterior a reivindicação é enviada pelo prestador de serviço ao reembolsador.
Criação dos documentos contábeis do processo de garantia:
Uma das etapas finais da execução da transação WTY é gerar o documento contábil para debitar o reembolsador, criando as partidas em abertos de FI, até que o reembolso seja efetuado e o documento baixado.
Se o fabricante (reembolsador) estiver controlando as solicitações através da transação WTY (supondo que ele também utilize o SAP), ao aprovar a solicitação de garantia/reembolso feita pelo prestador de serviço, ele executará uma ação para automaticamente gerar a nota de crédito e então pagar pelo serviço realizado (ou a ser realizado).
De novo, o usuário precisa escolher a ação correta na WTY para gerar os lançamentos em FI.
Dados Mestres
- Dados mestres de Garantia: utilize a transações BGM1, BGM2 e BGM3 para criar, modificar e exibir, respectivamente, o cadastro de garantias. É aqui que você define as condições de cobertura, as exclusões contratuais, os contadores e a validade para as garantias fornecidas aos seus clientes (por exemplo, até 1 ano a partir da data da compra, até 10.000 milhas, etc).
- Cadastro de preços: utilize as transações WYP1, WYP2, WYP3 para criar, modificar e exibir, respectivamente, as condições de preços para os itens da garantia. Esse cadastro deverá ser pré-acordado entre as partes, ou seja, o reembolsador (fabricante) e o prestador do serviço (solicitante do reembolso).
- Equipamento: Ao criar um equipamento, ou no momento em que realizar a venda do produto para o cliente, o fabricante ou o revendedor deverá atualizá-lo fornecendo o código da garantia previamente criado na transação BGM1, bem como a sua data de início. O equipamento geralmente é criado automaticamente no momento em que ele é fabricado e ocorre sua entrada no estoque. No momento em que ocorre a venda do equipamento para o cliente, então tem início a data de validade da garantia, que pode ser atualizada manualmente via transação IE02 ou através de algum desenvolvimento, por exemplo no momento em que o mesmo é entregue ao cliente ou que o faturamento é emitido.
IE02: Atribuição do número e data início da garantia ao equipamento
Principais configurações no SAP
A solução standard da SAP já vem com alguns modelos e é bastante customizável e flexível. Como ela visa atender todos os tipos de empresas e cenários, dificilmente você vai conseguir utilizar somente o que vem como modelo. É preciso primeiro entender bastante como o processo funciona, independente de sistema, e depois partir para o desenho da solução, pensando no fluxo de ações e documentos, quais versões seriam realmente aplicáveis, quais as ações que pretende habilitar para o usuário em cada uma das versões na WTY, e por aí vai. Utilize os modelos entregues pela SAP para criar a sua própria configuração de negócio.
Uma vez que o processo da empresa é entendido, utilize a transação OWTY para chamar a árvore que contém a maioria das entradas e opções de configuração para o processo de reivindicação de garantias.
Menu de configuração na OWTY
Como o objetivo desse post não é detalhar as configurações, segue abaixo algumas das principais configurações que você precisará fazer, dependendo do seu projeto:
- Definir tipos de reivindicação de garantia
- Definir o layout com os campos que deseja que fiquem visíveis por cenário
- Definir intervalos de numeração para os documentos de reivindicação de garantia
- Determinar esquemas de cálculo de preço
- Determinar Mensagens (outputs)
- Determinar contabilização
- Definir as ações disponíveis para o usuário, dependendo do status, da versão e do tipo de documento
- Definir o número de dias que o cliente possui para enviar o item para reparo em garantia
Automatização do fluxo de entrada e envio das reivindicações de garantia
Se o volume de reivindicações de garantia for muito alto e/ou o reembolsador ou prestador do serviço requerer alguma forma de automatização no processo de envio e recebimento da informação, muito provavelmente será necessário desenvolver algumas interfaces para que o fluxo de documentos de entrada e saída ocorram de forma automatizada.
Por exemplo, o fabricante, revendedor ou o prestador do serviço poderá já possuir um portal web onde o cliente possa solicitar o reparo em garantia do produto danificado. Ao receber essa solicitação, um serviço web/EDI poderá criar a primeira versão da reivindicação no SAP de forma automática, dispensando a presença de algum funcionário fazendo o trabalho manual.
O envio detalhado com o orçamento do trabalho a ser feito (mão de obra, peças a serem substituídas, etc) poderá ser enviado para o reembolsador (fabricante) de forma automatizada, por exemplo através de um arquivo XML, sendo enviado utilizando Idoc via EDI. O mesmo poderá acontecer com relação ao retorno da aprovação, dos respectivos ajustes ou até mesmo uma eventual recusa, enviada pelo reembolsador para o prestador de serviço, automatizando a captura da informação de entrada e criando uma nova versão da reivindicação na WTY.
Caso utilizem por exemplo o SAP C4C Service (Cloud for Customer), é possível receber as solicitações de clientes via e-mail, telefone, redes sociais (como facebook e twitter) , e após a geração de um tícket no sistema C4C, automatizar a criação da reivindicação de garantia no SAP CS (transação WTY).
Resumindo, considero uma boa solução principalmente para aquelas empresas que já utilizam o SAP e necessitam gerenciar um volume considerável de reivindicações de garantia. Afinal, ela foi pensada para facilitar a vida das empresas. Para que a solução seja mais eficiente, é preciso customizá-la de acordo com os processos da empresa, e realizar as integrações necessárias com os sistemas internos e externos, tornando-a mais automatizada.
