# 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>
###

**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>