Versão 1.4.014.000

Versão liberada dia: 11/05/2021
Versão Intellicash: Mínima 3.1.007.000
Versão Executável: 1.4
Versão DLL: 1.4.014.000
Versão EcUpdater: 1.0.0.43
Versão IWS Notify: 1.0.5.0
Versão EcAutoUpdater: 1.0.0.3
Servidor EasyCash: 2.0.7.0
WatchDog: 1.0.0.3
IntelliCash: 3.1.007.000

Foi adicionado nas configurações do sistema a opção de poder configurar os dias que serão enviados para o banco de backup, conforme a imagem:

Baseado na documentação oficial de Minas Gerais NFCe - Perguntas Frequentes, foi adicionado no EasyCash o sistema de frete atrelado ao processo de entrega. Nas configurações foi criado:

Na tela de entrega durante o processo de venda, teremos:

Na tela de fechamento será mostrado:

Foi adicionado uma configuração para o sistema em que no aviso para efetivar a sangria o operador ignore somente 3 vezes, em seguida será bloqueado o fluxo e poderá ser liberado o caixa para passar venda apenas sobre duas condições:

• Usuário com permissão(DESBLOQUEARALERTASANGRIA)
• Efetuando a sangria

Segue:

Após o fechamento do cupom e na abertura da tela de venda será mostrado:

Foi criado no EasyCash a opção de poder doar parte do troco para alguma instituição filantrópica. Para isso deve-se configurar:

Com isso, ao finalizar o cupom com troco, será mostrado:

O valor doado irá ser enviado como um suprimento para a retaguarda. Segue:

Foi adicionado para que o EasyCash abra a gaveta baseado-se na forma de pagamento. Para isso, foi enviado preenchido todas as formas na tela de configuração, conforme a imagem abaixo:

Foi criada uma configuração para que na tela de digitação das formas de pagamento o usuário possa preencher somente a forma DINHEIRO e as outras assume o valor do sistema. Segue:

Foi alterada a exportação do EasyCash para a retaguarda para que seja enviado o CFOP do momento da venda e não do cadastro, uma vez que este último pode ser alterado.

Foi alterado para que o comprovante da carteira digital seja impresso após o cupom fiscal. Foi alterado para que o COO siga a ordem em que as impressões ocorrem, afim de minimizar possíveis equívocos.

Foi alterado para que apartir desta versão seja adicionado as alterações da versão 1.20. Pode-se acessar as alterações em Nota Técnica 2020.006 - v.1.20 - Publicada em 16/03/2021 - Republicada em 17/03/2021.

Apartir desta versão dentro do GSS será enviado os arquivos RTM utilizados no frente de caixa. Esses arquivos serão copiados pelo frente de caixa para a pasta RTM do diretório principal de instalação. Foi adicionado também para copiar o executável novo do servidor do EasyCash para a pasta padrão de instalação facilitando o processo de atualização.

Após identificar um cliente no início da venda foi destravado para que seja possível fechar a mesma no modo de pagamento CLIENTES utilizando outro CPF.

Foi verificado as procedures de cálculo de rateio e todas agora utilizam o mesmo processo conforme descrito no Diario Oficial, Nº 207, s. 1, p76, quinta-feira, 27 de outubro de 2011.

Devido a quebra de caixa o operador pode ficar em mãos com um valor superior ao que o sistema apresenta. Agora, mediante permissão é possível retirar este valor do sistema.

A validação do saldo está vinculada a configuração PERMITEVNDBLOQFUNC. No caso da mesma estar setada o sistema irá entrar para efetuar a validação do saldo. Foi alterado para que nesta validação seja testado o acesso a retaguarda, com isso caso perca a conexão o loop é interrompido não tendo que aguardar finalizar todo o processo.

Foi alterado para que na tela de transmissão pendente seja possível alterar o registro 401 e 403 para -1. Com isso o sistema deverá processar novamente o registro ao clicar no botão Processar.

Foi alterado para que ao invés de gerar o número do lote do modo

Seja gerado do seguinte modo:

E o número do gerador NEWNUMLOTE será validado para não exceder 999999. Caso exceda o sistema irá gravar em log que o mesmo está sendo reiniciado e irá efetuar a operação.

Conforme solicitado pelo pessoal da DMCard foi alterado para que os seguintes campos sejam enviados com informações do programa de pontuação do EasyCash. Segue:

Foi adicionado para que ao abrir o servidor do EasyCash seja validado se existe uma versão mais recente do arquivo de schemas. Esta validação ocorrerá uma única vez baseado na existência do registro ATUALIZAÇÃO DE SCHEMAS no banco de dados.

Foram efetuados testes para validar os comandos utilizados durante o processo de backup e restore automáticos e de recálculo de índices.

Melhoria efetuada na validação interna de do John referente ao controle de processamento de NFC-e feita por meio de uma lista. Esse tratamento já existia, porém não estava sendo validado no início do processo de transmissão da NFCe, ficando este a cargo de uma validação no banco de dados, porém o problema se já justamente pelo fato do acesso ao banco de dados estar demorando muito (uso excessivo do HD) por algum outro fator externo ao sistema.

Foi corrigido para que o sistema não entenda o GTIN-8 (antigo EAN-8) e o GTIN-12 (antigo UPC) como sendo inválidos e os mesmos possam ser enviados normalmente no XML da venda.

Foi corrigido para que o sistema permita efetuar corretamente o fechamento de um orçamento com forma sugerida cheque a prazo parcelada.

No sistema, ao inserir um item na tela de venda, valida-se se o mesmo não faz parte de uma promoção especial e se possui as condições necessárias para que ela seja aplicada. Acontece que, como o item vendido fazia parte de duas promoções especiais, o sistema validava somente uma delas, por isso não estava sendo aplicado. Foi corrigido para validar todas as promoções relacionadas ao item vendido.

Foi verificado que quando se exclui um item, o produto que assumia a posição do item assumia também o seu valor de desconto, podendo um item com desconto sair sem o desconto ou um item sem desconto sair com desconto. Logo, foi corrigido as procedures do sistema para que isso não mais ocorra.

Foi tratado para que caso a informação referente ao filtro do DAV da tela principal esteja vazia o sistema automaticamente tente o próximo se disponível. Exemplo:

• Filtro em Número → Número vazio com Código Interno → Sistema tenta o código interno se a configuração estiver marcada
• Filtro em Código Interno → Código interno vazio com Número → Sistema tenta o número automaticamente independente de configuração

Foi adicionado algumas mensagens informativas para o usuário para facilitar a detecção do problema.

Foi corrigido para que o acréscimo dado no plano de pagamento da retaguarda seja computado corretamente no DAV. Segue:

Foi verificado que ao associar um DAV a um cliente que possui desconto por cliente, o frente apresentava erro de tag do xml vazia. Foi corrigido para que este caso não mais aconteça.