Versão liberada dia: 27/03/2026
Versão Intellicash: Mínima 3.1.020.000
Versão Executável: 1.5.004.000
Versão EcUpdater: 1.0.0.58
Versão IWS Notify: 1.0.7.0
Versão EcAutoUpdater: 1.0.0.3
Servidor EasyCash: 2.0.15.0
WatchDog: 1.0.0.6
IntelliCash: 3.1.020.000

Foi criada a funcionalidade para que o food transacione com TEF. Segue a imagem:

Caminho para utilizar o Vale Gás fora do menu administrativo do TEF:

Nova tela do Vale Gás:

Formas de pagamento disponíveis para seleção no Vale Gás:

Segue abaixo a tela de configuração da forma de recebimento com a nova opção:

Foi efetuado um tratamento para que seja possível efetuar o cancelamento de uma transação única proveniente do food, segue:

Validado na versão 2.0.14.1, a mensagem de que o certificado está expirado apresenta a logo antiga da IWS. O mesmo foi atualizado nesta versão:

Segundo informações de uma notícia da AFRAC, o protocolo de autorização da NFC-e, prevista na Nota Técnica 2025.002 vão aumentar de 15 para 17 dígitos. A previsão para entrar em vigor é 01/01/2026. Em análise nas nossas tabelas o campos protocolo possui o tamanho de 50 dígitos.

Para esta tarefa foi validado para que em testes o valor de um produto KG se altera com a configuração em 0 (desativada) e em 1 (ativada) não se altera, mas a SEFAZ pode rejeitar ou não. A rejeição se dá porque a SEFAZ faz o cálculo ao contrário dividindo o valor do item no cupom pelo peso e pode haver alteração de alguns centavos, por isso enviamos o valor alterado.

Foi criado a configuração para permitir a impressão da pontução da API EasyPromo no cupom de finalização. Segue:

Quando alguém enviar o json da licença para o IWB, esse dado é armazenado. Quando manda novamente a liberação para o IWB compara essa assinatura, se for diferente, o IWB manda liberar novamente. Com isso é efetuada a atualização da versão da licença. Segue:

Foi habilitado o botão de impressão para a Nota Informativa e Adicional de Entrega, segue:

Foi relatado pelo suporte que quando eles atualizam um cliente no domingo (por exemplo) e não há nenhum movimento no dia, ao iniciar o sistema no dia seguinte é emitida uma mensagem que está pendente o encerramento do dia anterior. Foi realizado o tratamento para quando não houver movimento não criar automaticamente um registro.

Criado a configuração para motivo de cancelamento quando o pagamento for feito em TEF, segue:

Será mostrada a seguinte tela:

Criado a configuração para permitir que no endereço de entrega apareça a forma de pagamento escolhida. Segue:

Na impressão, teremos:

Na retaguarda teremos:

Foi feito uma melhoria no grid, onde foram acrescentados as novas colunas para melhorar a informação, segue:

Foram adicionadas novas opções de impressão do comprovante, conforme ilustrado na imagem abaixo:

Quando os checkboxes TEF ou Carteira Digital estiverem marcados, algumas opções de impressão são reduzidas, como mostrado a seguir:

A multiplicação de produtos foi ajustada para considerar a permissão do operador como prioritária. Agora, o comportamento segue as seguintes regras:

• Se o operador possui permissão, o produto será multiplicado independentemente da configuração individual do produto.
• Se o operador não possui permissão, a multiplicação só ocorrerá se o produto permitir ser multiplicado.

Exemplos de comportamento:

✅ Operador com permissão + ✅ Produto permite → ✅ Multiplica

✅ Operador com permissão + ❌ Produto não permite → ✅ Multiplica

❌Operador sem permissão + ✅ Produto permite → ✅ Multiplica

❌ Operador sem permissão + ❌ Produto não permite → ❌ Não multiplica

A tela para o usuário será mostrada da seguinte maneira:

Foi definido de colocar um checkbox PREÇO MINIMO na tela de cupom premiado para que ao ser marcado o sistema entenda que a partir daquele preço que estiver setado no campo VALOR DO CUPOM o frente irá gerar apenas um cupom INDEPENDENTE DO VALOR FINAL DA COMPRA, segue:

Foi adicionado a possibilidade de personalizar a mensagem que irá aparecer no pinpad no caso específico da PayGo. Segue:

Para esta demanda são preenchidos os dados do cancelamento automaticamente em dois casos:

• No processo de cancelamento TEF (venda que teve um cartao TEF) o sistema entra no fluxo do TEF para realizar o cancelamento da transação. Nesse fluxo é solicitado os dados da transação, como por exemplo, o número do DOC da transação.

• No caso em que numa venda já foi transacionado parte do valor em TEF e o usuário tenta sair da tela de pagamento o sistem solicita o cancelamento dessa transação pois no caso do PayGo a transação já foi confirmada. Porém como ainda não houve a impressão não temos os dados da transação. Então é importante que esses dados já venham preenchidos na tela.

Foi solicitado que ao finalizar uma venda no sistema, que aparecesse o nome do usuário atualmente logado no cupom fiscal. Segue:

Teremos:

Foi criado o botão para teste de conectividade do TEF, segue a imagem abaixo:

Foi adicionado o campo que exibe a quantidade total de itens cancelados, considerando a soma dos itens de todos os cupons cancelados. O layout do cupom de fechamento de turno foi atualizado para contemplar essas novas informações e, para manter a padronização, o layout do cupom de encerramento de dia também foi ajustado seguindo o mesmo modelo. Segue:

Foi implementada uma melhoria no sistema para que quando a configuração estiver ativa, o relatório de caixa será sempre impresso automaticamente, mesmo que o usuário clique em Fechar ou Confirmar. Segue:

Na tela de conferência, teremos:

Estando a configuração desativada o relatório só será impresso se clicar no botão Imprimir. Segue:

Quando efetuado algum ajuste na aba de destinatário no servidor do EasyCash, agora irá aparecer as mensagens a seguir quando efetuado algum tipo de alteração:

De acordo com a NT Nota Técnica 2018.005, é necessário ter as informações do responsável técnico no XML de Venda:

Foi alterado para que no XML da NFC-e já saia o responsável técnico. Segue:

Funcionalidade de validação de inconsistências e alteração em lote adicionada conforme solicitado na tarefa. Como o frente de caixa e, consequentemente, o Servidor NFCe, não possuem uma tabela que correlaciona o CBENEF com os CSTs, foram validados os seguintes CSTs: 20,30,40,41,50,51,70,90. Desta forma se o item no XML estiver com um destes CSTs e não possuir CBNEF ou, de modo inverso, possuir CBNEF mas não estiver em um destes CSTs, o item será tratado como inconsistente e será listado para correção.

Devido a enorme gama de tags que contemplam a Reforma Tributária fica inviável adicionar todas elas naquele agrupamento simples, por isso, foi trocado para abrir o xml diretamente no navegador contemplando assim a visualização de todas as tags. Segue:

Logo, pelo XML teremos:

Foi feito a validação para impedir que mais de uma API seja ativa.

O problema relacionado ao cálculo incorreto do valor a ser pago, ao utilizar múltiplas formas de pagamento com desconto ou acréscimo, foi corrigido. Agora, independentemente da combinação escolhida, o sistema calcula corretamente o valor restante.

Quando criado um orçamento na tela de cadastro de clientes (IWS > Cadastro > Clientes > Aba Orçamento). Ao informar um caixa para finalizar diretamente, o sistema abria um pop-up no Easycash para que o cliente fosse selecionado. Este processo foi corrigido.

Foi pego em cliente que haviam sido finalizados de forma indevida dois orçamentos de consumidores distintos em um mesmo cupom e os itens do cupom final não eram os originais dos dois orçamentos. Em análise foi visto que devido uma falha foram agrupados os dois orçamentos no frente de caixa, pois o orçamento inicial já estava na tela de vendas quando o segundo foi inserido. Foi adicionada uma trava de segurança para este caso.

Foi visto que as configurações “Exibir mensagem de quantidade de itens” e “Utilizar valor unitário do cadastro do produto” ao entrar na tela de alteração estavam com a posição invertida em relação a tela anterior. Foi padronizado.

No fluxo de reimpressão de entregas, anteriormente havia o seguinte cenário:

Caso o usuário solicitasse a impressão de duas ou mais vias no encerramento da venda, ao acionarmos o fluxo de reimpressão de entregas a aplicação executava a quantidade de reimpressões da mesma via de acordo com a quantidade original de impressões solicitadas pelo usuário na venda, segue como exemplo:

• Ao encerrar uma venda foi solicitado a impressão de 2 vias: Os números 327805 e 327806. Para cada re-impressão realizada, o fluxo é acionado novamente, e caso ainda, houver reimpressão pela tela de Utilitários → Vincular ao Cupom Fiscal → Entrega esse fluxo também entra na quantidade de reimpressões… 2x cupom 327805 e 2x cupom 327806.

Foi corrigido o loop que ocorria em ambas as telas e melhorado o tratamento para respeitar a quantidade de vias e a opção de cancelamento pelo usuário.

Ao tentar agendar uma entrega para um CPF que não esteja cadastrado, o sistema estava montando a tag de entrega, porém sem o destinatário. O processo foi corrigido para não identificar entrega se o XML estiver sem os dados do destinatário. Desta forma, caso uma venda não identificada, possua entrega vinculada porém sem cadastrar o destinatário de entrega, o XML será gerado com o indPres = 1 e sem a tag de entrega, evitando rejeição. Foi adicionado também uma melhoria na tela de entrega para obrigar a digitação do CEP, facilitando o cadastro dos demais campos.

Durante a finalização da venda, foi detectado um erro relacionado ao rateio do desconto manual (aplicado via valor bruto ou porcentagem — F5 na tela de venda). Ao fazer o rateio do desconto, estava zerando o valor de um ou mais produtos, mostrando a seguinte mensagem:

Foi identificado que essa validação é antiga e impedia que um produto tivesse valor zerado nos tempos de ECF-IF. No entanto, atualmente o XML da NF-e já permite itens com valor R$0,00, o que torna essa validação desnecessária. Foi retirada esta validação.

Ao realizar uma venda no EasyPDV novo e caso tenha 2 telas no computador, ao faturar direto, a segunda tela abre e só é possível fechar a mesma com o Alt+F4. Foi realizada uma correção no processo de finalização de venda do EasyCash para quando inicia a venda no EasyPDV. Agora, mesmo quando o sistema estiver operando com duas telas ativas, a conclusão da venda não acionará aberturas indevidas de telas adicionais. Essa correção evita comportamentos inesperados na interface.