Versão liberada dia: 18/10/2021
Versão Intellicash: Mínima 3.1.008.001
Versão Executável: 1.4
Versão DLL: 1.4.015.002
Versão EcUpdater: 1.0.0.45
Versão IWS Notify: 1.0.5.0
Versão EcAutoUpdater: 1.0.0.3
Servidor EasyCash: 2.0.8.1
WatchDog: 1.0.0.3
IntelliCash: 3.1.008.001
Apartir desta versão, foi adicionado na retaguarda a seguinte opção:
Apartir dessas opções, pode-se processar as pendências no caixa, não sendo mais necessário acessar o referido caixa para efetuar a manutenção. Nesta tela também, foi adicionado para que seja possível excluir um registro pendente, caso o mesmo apresente problema na transmissão. Um exemplo disso é cliente com o CPF bloqueado na plataforma de integração. Segue:
No frente de caixa também, a mensagem que informa que temos pendência para as integrações foram melhoradas conforme abaixo:
No frente de caixa no menu de relatórios foi acrescentado a seguinte opção:
Ao clicar no relatório, podemos acessar o seguinte relatório:
Surgiu a necessidade de se fazer venda com tributação diferenciada em caso de bases multiempresas com regimes diferentes. Por exemplo, na mesma base de dados possui uma empresa do tipo INDUSTRIA como Simples Nacional e outra empresa com o tipo PADARIA com o regime Lucro Presumido e nesse caso quando o item A for vendido na empresa INDUSTRIA deve ser emitido o cupom fiscal como TRIBUTADO a 7% e quando vendido na PADARIA o cupom fiscal deve sair como Substituição Tributária - ST. Atualmente como o cadastro permite apenas uma tributação por produto a solução para atender esse caso seria a criação de tributação padrão para cupom fiscal. Então a partir da versão 3.1.015.002 passa ser possível a criação de tributação padrão para a operação VENDA EM CUPOM FISCAL.
Na tela de troca de mercadoria, os componentes de inserção de dados foram realocados permitindo uma melhor disposição entre os mesmos. Segue:
Para o caso de venda que foi gerada apartir de um orçamento, foi realizado o tratamento para o programa de pontuação com o objetivo de tratar no fechamento do cupom o referido desconto. Segue:
Foi tratado para que quando a configuração “Não destacar acréscimo de item no DANFE” estiver setada, na segunda via o acréscimo não será mostrado.
Foi adicionada uma validação do status do último cupom emitido antes de permitir abrir a tela de orçamento(CTRL + F9). É validado se foi transmitido e se foi impresso corrigindo automaticamente o status do cupom no frente de caixa evitando assim sobrecarregar um cupom com dois orçamentos diferentes.
Quando se coloca um banco vazio em um caixa sem renomear o banco AM$FRENTE, há uma grande possibilidade dos novos IDs colidirem com os existentes no banco de backup, fazendo com que os dados antigos sejam perdidos. Foi criado uma rotina de validação para que o sistema seja capaz de retomar a sequência do NEWIDGERAL, baseando-se no maior ID registrado no AM$FRENTE.
Quando se coloca um banco novo e manda carregar as formas de pagamento do IntelliCash, são criados IDs novos internamente. Ao fechar um turno, o sistema atualiza o banco AM$FRENTE com esses novos IDs formas de pagamento, fazendo com que a tabela AM$CUPOM_MOVCX perca completamente a referência das formas de pagamento, inviabilizando uma restauração precisa dos dados financeiros. Foi realizado uma melhoria para que ao mandar carregar as formas de pagamento em um banco novo, o EasyCash consulte o AM$FRENTE antes de obter as formas do IntelliCash, mantendo assim sempre os mesmos IDs.
Apartir desta versão o EasyCash irá utilizar as seguintes telas para comunicação com o operador de caixa:
Apartir desta versão, foi realizado duas novas alterações para o banco de backup do EasyCash, são elas:
- Foi adicionado o sistema de auditoria em um banco de dados separado(EC$AUDITORIA), evitando ser movido o mesmo para o AM$FRENTE no fechamento do turno;
- O banco do AM$FRENTE e do novo sistema de auditoria deve ser criado anualmente, sendo o do ano anterior mantido na pasta como histórico.
Quando um cupom entra em contingência, duplica-se o registro deste cupom e dos respectivos itens. Por regra, este novo cupom terá seu número COO acrescido em 1 e o número de NFCe subtraído em 1 em relação ao cupom de origem, a fim de manter a correção da venda transmitida sempre com o cupom original. No entanto, se houver uma quebra nessa sequência em decorrência de suporte ou alguma contenção interna de falha, por exemplo, o sistema não conseguia correlacionar o vínculo entre os dois cupons. Foi criado uma correspondência entre os cupons ao registrar a ocorrência no banco.