# Termino de seguro com restituição Restituir o valor do valor dos itens não utilizados no termino do seguro (dia da última cobrança), esse valor só existe quando o segurado faz um endosso e temos um valor a ser restituido que não cabe como desconto nas parcelas seguintes até a data de termino do seguro. ## Requisitos - A comunicação deve ser na data de vencimento da sua útima parcela. - Deve estar disponivel simultaneamente com a parcela de ajuste. - Restituição deve ser feita somente na conta do segurado. ## Dúvidas ###### Solucionadas - Qual o sistema que vai ser o responsável para estimular essa restituição? <small>*R: Billing.*</small> - Como vamos representar essa restituição no billing? <small>*R: Como a última parcela no plano, junção valor **negativo e status**.*</small> - O que vai estimular esse processo de restituição? <small>*R: Um cron diario.*</small> - Como isso pode ser reportado para **Guidewire**? <small>*R: De forma similar ao reembolso do fluxo cancelamento.*</small> ###### Não solucionadas - Qual o número de tentativas para capturar os dados bancarios do segurado? - Qual o espaço de tempo entre uma comunicação e outra? - Quais meios de comunicação devemos usar fora o email? - Implementar esse form no app mobile ou vamos usar uma pagina responsiva? - Qual o procedimento quando não conseguirmos os dados bancarios? ## Fluxo #### Verificação de restituição recorrente <small>Implementar uma cron com uma recorrência diaria em billing consultando os planos com um installment com status indicador de restituição por termino de vigência, quando encontrado o billing estimula o web_app para registrar uma entidade que vai controlar a regua de comunicação com o usuário, feita essa comunicação que leva ao formulario de preenchimento dos dados bancarios o web_app vai estimular a Guide Wire para executar a restituição com tais dados bancarios quando a executação feito isso para acompanhar o status dessa restituição a GuideWire enviara um evento com o IDLG e posteriormente um delta, caso o delta indique falha entramos no looping para coletar os dados e tentar novamente.</small> ### ![](https://i.imgur.com/KMYPelz.png) **Task's** **Billing - Trigger de devolução :: P** Na data correta, deve ser lançado um evento para iniciar o processo de tentativa de devolução. <small> *Dependencia de Negocio: Será enviado no dia de vencimento da parcela ou X dias antes?* </small> ## **WebApp - Régua de comunicação e token de segurança :: G** Ouvir o evento e então agendar todos os e-mails definidos para a régua de comunicação de tentativa de devolução A régua de e-mails deve respeitar o status do installment negativo da assinatura, para evitar envio de e-mail caso os dados já tenham sido enviados. Os e-mails de solicitação devem possuir um token único que permitem o acesso à tela. <small> *Dependencia Tecnica: Checar o funcionamento de friends e renovação.*</small> ## **Notifier - Implementar os e-mails de solicitação :: M** Criação do corpo dos e-mails, caso seja outro layout de e-mail ainda não montado, essa tarefa será maior que "G". <small>*Dependência Técnica: UX*</small> ## **WebApp - Montagem da tela de dados bancários :: G** Apenas front-end <small>*Dependência Técnica: UX*</small> ## **WebApp / Billing - Integração com GW e dados bancários :: M** Implementar o fluxo de envio dos dados bancários para a guidewire e atualizar o status da parcela negativa no billing. <small>*Dependência Técnica: Conseguir o modelo de payload que a Guide Wire espera.*</small> ## **Billing - Gerenciamento de pedidos de devolução no Billing :: M** Ouvir eventos da GuideWire e gerenciar status de devolução no billing. <small>*Dependência Técnica: Um modelo de contrato da Guide Wire.*</small> ## **WebApp - Agendamento da régua de comunicação de retentativa :: P** Agendar todos os eventos do fluxo de retentativa. <small>Dependência de Negocios: Qual a frequencia e intervalo da regua de comunicação e em caso de falha ou seja nenhuma tentativa deu certo?</small> ## **WebApp / Notifier - Envio dos e-mails e tela de retentativa :: M** Criação do corpo dos e-mails e montar a tela para uma nova tentativa, caso a tela seja muito diferente da primeira tentativa, essa tarefa será maior. <small>*Dependência Técnica: UX*</small>