---
# System prepended metadata

title: Termino de seguro com restituição

---

# 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
- Qual o sistema que vai ser o responsável para estimular essa restituição?
- 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? 
- Como isso pode ser reportado para **Guidewire**?

## Sugestões

#### Agendar um Job / Worker para data de termino.

Agendar um Job interno ou usar o **scheduler-service** no momento em que é realizado o endosso esse job vai ser executado alguns dias antes da data de cobrança do último mês do seguro, quando executado vai verificar se ainda existe valor a ser restituido com base em um cálculo de pro rata, se for valido ele vai emitir o evento para restituição.

#### **Fluxo**

```
01 - Executa step que verifica se cabe nas parcelas.
02 - Executa um service que agenda o Job de restituição.
03 - No dia agendado validamos se ainda tem restituição se sim sobe o evento.
04 - Enviar comunicações para coletar os dados bancarios.
05 - O usuário recebe e acessa um pagina de comunicações enviando os dados bancarios.
06 - O message gateway recebe e publica um evento com os dados.
07 - Ouvimos o evento e montamos o payload para Guidewire.
08 - A Guidewire retorna o IDLG do pagamento.
09 - Ouvimos e persistimos o IDLG atrelado ao número da apolice.
10 - A Guidewire retorna a confirmação do pagamento.
```


**Prós** 
* Implementação relativamente simples.
* Implementação desacoplada em relação ao codigo do endosso.
    
**Contras**
* Existe o cenário onde o cron (sistema que enfilera os jobs) cai e não conseguimos os dados de volta?
* Baixa rastreabilidade pois em caso de falha não é trivial aferir se o Job foi executado ou não executado.

##

#### Verificação de restituição recorrente

Implementar uma cron com uma recorrência diaria consultando as últimas parcelas com saldo negativo com data de vencimento para aquele dia.

**Fluxo**

```
01 - Executa step que verifica se cabe nas parcelas.
02 - Diariamente consultamos todas as parcelas para o dia corrente.
03 - Com uma validação de negocios subimos um evento.
04 - Enviamos comunicações para coletar os dados bancarios.
05 - O usuário recebe uma comunicação e envia os dados bancarios.
06 - O message gateway recebe e publica um evento com os dados.
07 - Ouvimos o evento e montamos o payload para guidewire.
08 - A guidewire retorna o IDLG do pagamento.
09 - Ouvimos o IDLG e atrelamos o número da apolice a entidade já existente.
10 - A guidewire retorna a confirmação do pagamento.
```

**Prós**
- Mais robusto pois se o cron (sistema que enfilera os jobs) cair os dados não seram perdidos.
- Conseguimos representar e encontrar bem essas entidades de restituição agendada no sistema ou manipular facilmente os agendamentos de restituição.

**Contras**
- Um fluxo novo para billing.

       