01. DADOS GERAIS

Linha de Produto:Virtual Age
Segmento:Moda
Módulo:Financeiro
Função:

FGRFP037 - Envio de Compartilhamento de Dados para Boa Vista

FGRFP039 - Retorno do Compartilhamento de Dados da Boa Vista

Requisito/Story/Issue (informe o requisito relacionado) :DVAFIN-3508


02. SITUAÇÃO/REQUISITO

Foi identificado alguns problemas no envio de dados positivos para o Boa Vista, com relação a títulos abatidos ou quebrados. Junto com estas validações apresentadas pelo próprio Boa Vista, foi levantado algumas pendências no tratamento de envio e no processo de retorno dos dados.

03. SOLUÇÃO

Foi avaliado layout do Boa Vista e reaplicado o processo de envio e retorno, contendo as regras atualizadas e corretas com respeito a envio e retorno dos dados. Junto com estas implementações foi ajustado também o procedimento de envio de titulos que foram quebrados por alguma maneira, ou titilos que forma abatidos, cancelados e também títulos que foram totalmente recebidos.


Para execução e funcionamento do processo de envio e retorno de informações do Boa Vista, se faz necessário a configuração dos parâmetros abaixo:

 - TP_LAYOUT_EQUIFAXBOAVISTA → Valor 3 →  LAYOUT BOA VISTA (COMPARTI ILHAMENTO DE DADOS E NEGATIVAÇÃO)

 - DESTINO_ARQ_BOAVISTA → Neste parâmetro dever ser apontado o caminho para geração do arquivo de remessa.

 - PREFIXO_NOME_COMPARTDADO → Neste parâmetro deve ser configurado a nomenclatura do arquivo de remessa que sera gerado.

 - TP_CONFIRM_ARQPOS_BVISTA → Este parâmetro irá definir como sera o controle de retorno do processo de compartilhamento de dados positivos, explicaremos sua utilização abaixo:

     0 → Não controlar a confirmação do envio realizado, quando retornar o arquivo com extensão ".ERR", apenas fará o registro dos erros executando o componente FGRFP039.

     1 → (Efetua controle de retornos do Boa Vista) Quando retornar o arquivo com extensão ".ERR", confirmar o arquivo executando o componente FGRFP039; Quando não retornar o arquivo com extensão ".ERR", confirmar o retorno executando o componente FGRFP039 e assinalar a opção de confirmar o envio sem arquivo.

     2 → Quando gerado uma remessa, gerar um registro contendo erro proposital, para forçar o retorno de pelo menos um arquivo de erro. E o arquivo retornado com extensão ".ERR" e a confirmação sera feita através do componente FGRFP039.


Imagem 1 - Na imagem acima, como podemos observar acessamos o novo componente desenvolvido para envio de dados positivos ao Boa Vista. Detalharemos alguns dos processos padrões dentro do componente:

  • 1 - Sera utilizado para o filtro aplicado dentro do componente, informando o intervalo, o sistema fará a consulta de todos os títulos que encontram-se lançados no período. Vale alertar que este filtro obedece a data de cadastro das faturas. 
  • 2 - Serão exibidos os documentos do contas a receber para envio de dados positivos. Só serão filtrados pessoas jurídicas dentro deste processo e que não estejam com cadastro de consumidor final.
  • 3 - Nesta parte do componente será exibido dados do ultimo retorno juntamente com a sua situação.

Imagem 2 - Na imagem acima, como podemos observar efetuamos um filtro e geramos o arquivo de remessa normalmente, clicando no botão "Gerar arq. Boa Vista". 

Imagem 3 - Na  imagem acima, após geração do arquivo, efetuamos a impressão do relatório apenas para conferência dos dados enviados. Todas as informações foram enviadas ao relatório corretamente, quebrando as informações de envio por cliente.


Imagem 4 - Nas imagens acima estamos detalhando o arquivo de remessa gerado, de acordo com as informações contidas no manual do Boa Vista. 

Imagem 5 - Na imagem acima, ao acessar o componente FGRFP037 novamente, clicamos no botão "Ultimo envio", veja que o sistema carregou novamente e corretamente as informações que acabamos de gerar para envio de dados positivos. Se observarmos o painel informativo de ultimo envio, a situação do ultimo envio encontra-se "Gerado para envio".

Imagem 6 - Na imagem acima, efetuamos o detalhamento do log de geração de arquivo clicando no botão "Log geração arq.", veja que já foi gravado log do ultimo envio que efetuamos.

Imagem 7 - Na imagem acima, efetuamos o teste gerando novamente o ultimo envio que efetuamos, clicando no botão "Gerar arq. últ. envio". O arquivo foi gerado corretamente.

Imagem 8 - Na imagem acima, como podemos observar ao tentar efetuar um novo envio e efetuar um novo filtro o sistema exibe a mensagem que precisamos confirmar o ultimo envio. Isto porque o nosso parâmetro 

"TP_CONFIRM_ARQPOS_BVISTA" esta configurado com 1.

Imagem 9 - Na imagem acima, efetuamos o acesso ao novo componente FGRFP039, veja que dentro do componente agora existe um checkBox onde o usuário pode marcar para confirmação do retorno sem erros.  Ao marcar o campo o botão confirmar é habilitado para confirmação, ou o usuário pode pesquisar o arquivo de retorno e processa-lo também.

Imagem 10 - Na imagem acima, como não temos o arquivo de retorno, marcamos o checkBox e confirmamos o ultimo envio.

Imagem 11 - Na imagem acima como podemos observar ao acessar agora o componente FGRFP037, vemos que foi liberado o filtro para um próximo envio. Veja que no frame de log do último envio, foi atualizado a situação do ultimo envio.

Imagem 1 -  Na imagem acima, efetuamos um envio de três faturas (8191,8192 e 8193) do cliente 22226. Para cada fatura enviada efetuaremos um procedimento diferente após o envio. Veja que o arquivo foi gerado corretamente.

  - Efetuamos o recebimento da fatura 8191 através do componente FCRFP002.

  - Efetuamos a quebra da fatura 8192 em três parcelas.

  - Efetuamos o canelamento da fatura 8193.

Imagem 2 - Na imagem acima, depois de confirmado o envio efetuado anteriormente, iremos efetuar um novo envio de dados positivos, e filtramos o período em que ocorreu toda movimentação mencionada acima.  Em amarelo temos a fatura 8191 que foi recebida e esta sendo enviada a data de pagamento desta fatura. Logo abaixo temos o registro de exclusão da fatura 8192 que foi quebrada, e as parcelas geradas a partir da quebra estão sendo enviadas como mencionado em vermelho. Em azul selecionamos a fatura 8193 que foi cancelada, e esta sendo enviada a exclusão dela.

Imagem 3 - Na imagem cima, veja que o arquivo foi gerado com sucesso.

Imagem 4 - Na imagem acima, temos a visualização do arquivo gerado, contendo os registros de envio. Veja que constam dois registros com tipo "B"(Exclusão), relacionados a fatura 8192 e 8193. Para a fatura quebrada é enviado uma data de pagamento da mesma, ja que ela foi baixada como quebra. Ja para o registro canelado é enviado somente o tipo de envio "B". Arquivo foi gerado corretamente.

Imagem 1 - Na imagem acima, efetuamos um novo envio de remessa contendo a fatura 72219 do cliente 22229 no valor de 200,00.

Imagem 2 - Na imagem acima, como podemos observar depois de enviada a fatura, efetuamos um abatimento total na fatura. Veja que ela foi baixada com tipo de baixa "Baixa por abatimento total".

Imagem 3 - Na imagem acima, depois de efetuado o abatimento, vemos que ao tentar realizar um novo envio, o sistema considerou o pagamento da fatura por abatimento total e esta enviando a baixa dela como paga.

Imagem 4 -  Na imagem acima, vemos que o arquivo foi gerado corretamente.

Imagem 5 - Na imagem acima, veja que o arquivo foi gerado com a data de pagamento e o valor total de pagamento sendo enviado.



<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>