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 criado o botão para impressão do rascunho e a possibidade de usar comandos de impressão para melhor fortação.

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