A Especificação Reembolso

...

- Para os demais tipos, o analista que será encarregado da digitação do item, no Delphi no momento da análise.

- O tipo de tratamento será listado para opção, de acordo com o cadastro, conforme item acima “C”.

- Provavelmente será agrupado na parametrização os tipos de tratamento, para tanto, a tela, deve trazer a opção de tipos de tratamentos existentes para vínculo na nomenclatura que será criada para apresentação no portal.

- O analista no momento da análise, ficará encarregado de lançar o detalhamento dos honorários.

e) ANEXOS - Web e Delphi:

- Criar campos distintos para anexos em geral e para nota fiscal eletrônica, por tipo de atendimento.

- O sistema, deve exigir a inclusão de um ou outro para geração do protocolo/ finalização da inclusão do protocolo.

- E também deve permitir, uma nova inclusão, desde que a situação do reembolso permita, ou seja: Protocolado/ Devolvido quando estiver em “analise” não deverá permitir alteração via Portal.

- Sempre que inserido novos anexos, o sistema imprimirá novo Protocolo de Reembolso, atualizando os dados, gerando novo prazo para limite de pagamento, no entanto, deve ser preservado o mesmo número de protocolo, atualizando a descrição de todos os documentos.

- No Portal, Web ou Delphi os anexos, devem ficar disponíveis para consulta a qualquer momento.

- O sistema deverá permitir a inclusão de até 30 anexos.

- Estes, serão representados por “clipes”, ao clicar no ícone, deve ser possível visualizar a imagem.

- Enquanto o anexo não for aberto, através do acesso da operadora o ícone deve ficar representado pelo clips vermelho [pic 3]e após leitura verde [pic 4].

- Ao lado do nome do beneficiário em qualquer etapa do processo interno, deve haver um atalho para anexos, no entanto, deve ser diferenciada da seguinte maneira:

➔Quando houver anexos, não “lidos”, o ícone “Clips” deve ficar vermelho e com “animação”, enquanto os já lidos ficarão verde.

f) NOVA TELA – DIGITAÇÃO PORTAL:

- O processo digitado via portal, deverá ficar disponível para distribuição entre as equipes, (processo parecido com o atual em Autorização – Situação do Pedido).

- Esta tela deverá possuir filtros, por período/ tipo de atendimento/ beneficiário/contrato/data da solicitação (de/até)/ Situação do Pedido : Análise/ Deferido/ Indeferido/ Devolvido.

- Deverá permitir a visualização na tela ou extração em TXT.

- Deverá apresentar como resultado: Contagem de Pedidos/ Valor individual de cada pedido/ Valor total de todos os pedidos listados/ N. do Protocolo/ N. Recibo/ N. Nota Fiscal Eletrônica/ Data do Protocolo/ Data da Entrega do documento físico/ Situação/ Tipo de Atendimento/ Nome do Beneficiário/ Usuário/ Data Assumido por este usuário/ Atalho para anexo (clips verde/vermelho), atalho para acesso do pedido de reembolso na tela da Situação Atual.

- Sendo que quando acessado pela Web, permitirá apenas Devolução e Alteração, para análise, será necessário acessar através do Delphi (o sistema deve mencionar esta condição).

g) PEDIDO BLOQUEIO x USUÁRIO:

- Quando um pedido de reembolso estiver sobre a análise de outro usuário, o sistema, deve abrir pop-up perguntando se realmente deseja assumi-lo, processo parecido com o que temos atualmente no Pedido de Autorização.

➔Deseja Assumir o Pedido de Reembolso? Ok? Cancelar?

Ao clicar em ok, o pedido deve ser assumido pelo usuário logado.

- O pedido ainda não assumido por nenhum usuário, deve assumir automaticamente aquele que o primeiro acessar.

- Inserir em todas as telas do Processo de Reembolso e em qualquer situação (visualização interna), o campo, USUÁRIO, para que seja possível a visualização de qual usuário está com determinado pedido e ou ainda o usuário que finalizou o processo.

- Quando o processo, ainda não estiver sido assumido por ninguém, o campo deverá ficar “sem preenchimento”.

h) REGRA PARA EXCLUSÃO:

- O processo digitado via portal, deverá ser EXCLUÍDO (situação deve ser criada), automaticamente pelo sistema, após 10 dias (criar parâmetro para definição de prazo), da inclusão, quando não houver o preenchimento do campo “Data de Recepção”, utilizado para informar a data de entrega do processo físico.

- Para exclusão automática o sistema não deverá considerar o pedido que possuir anexo de Nota Fiscal Eletrônica, pois estes dispensam o processo original.

- O processo poderá ser enviado para pagamento, somente quando preenchido o campo “data de recepção” – Documento Físico. Quando não preenchido o campo, o sistema deve emitir um pop-up de alerta, no momento da autorização: “O pagamento somente será possível, após o recebimento da documentação física”.

- A regra apenas não se aplica quando se tratar Nota Fiscal Eletrônica.

- E quando o processo for excluído automaticamente ou manualmente por falta da entrega da documentação, deve emitir uma e-mail padrão para o segurado, emitindo tal alerta. (criar parâmetro para texto padrão).

- Deve haver os motivos de exclusão previamente cadastrados para opção quando exclusão manual, no entanto quando exclusão automática o sistema deve adotar sempre a opção indicada pela Marítima na Parametrização.

- O reembolso excluído deve ser listado para consulta em vermelho, no entanto, após o período de tolerância e ou seja, pedido excluído deverá ser digitado novamente, não será possível reabilitar.

- i) SITUAÇÃO: REEMBOLSO DEVOLVIDO:

- Esta condição, “devolvido”, deve ser definida pelo analista no momento da análise, Web ou Delphi – Funções já existentes.

- Ao devolver um pedido de reembolso, o sistema deve automaticamente abrir um pop-up