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