Versão liberada dia: 26/05/2022
Versão Intellicash: Mínima 3.1.010.000
Versão Executável: 1.4
Versão DLL: 1.4.017.000
Versão EcUpdater: 1.0.0.46
Versão IWS Notify: 1.0.5.0
Versão EcAutoUpdater: 1.0.0.3
Servidor EasyCash: 2.0.10.0
WatchDog: 1.0.0.3
IntelliCash: 3.1.010.000

Foi criado no arquivo EasyCash1.ini a seguinte configuração:

[NFCe]
IntelliFood=1

Uma vez setado, o sistema não trabalhará mais com orçamentos (DAV), somente com comandas do IntelliFood. Inclusive o botão referente ao DAV na tela de venda será trocado para COMANDA. No entanto no frente de caixa, todo o funcionamento será muito semelhante ao DAV, alterando basicamente as tabelas e procedures de origem e destino. Segue as imagens:

Durante alguns testes com importação de clientes verificou-se que ao alterar o endereço de um cliente no caixa, gerava-se no IC um IDHeader para esse cliente a fim de replicar a alteração aos demais caixas e mais diversos outros registros de clientes/funcionários/convênios desativados. Portanto, foi melhorado para exportar somente o registro modificado do referido caixa.

Foi criado no menu de configuração do CF-e as seguintes opções:

Para o cupom fiscal teremos:

Para o CCD(Comprovante de Débito e Crédito) teremos:

Na tela de reimpressão, foi criado:

Ao clicar no botão, será mostrados os cupons de venda do turno aberto ou do último turno do dia corrente. Caso não exista nenhum dos dois o botão não será mostrado. Segue a imagem:

Lembrando que para a reimpressão do CCD na tela de vendas, temos o botão ADM - TEF (F8), para acessar a seguinte tela:

Nas configurações do EasyCash foi adicionado:

Ao selecionar no recebimento uma forma que seja cartão:

Será mostrada a seguinte tela ao tentar inserir o recebimento:

Ao selecionar TEF, o sistema irá procurar no frente de caixa as formas de recebimento cujo pai é a forma selecionada na tela. Caso retorne apenas 1 única forma o sistema irá assumir a mesma, senão o sistema irá pedir para selecionar a forma TEF do frente de caixa. Uma vez executado este processo o fluxo será inicializado conforme a imagem:

É mostrado nesse caso, a opção de pagamento a vista e parcelado, conforme a imagem:

Caso selecione parcelamento a data de vencimento do frente de caixa será a mesma data de vencimento dos lançamentos efetuados para a retaguarda. Após a tela do tipo de parcelamento será mostrada a tela para informar a quantidade de parcelas:

Uma vez o processo tenha ocorrido, será impresso:

Após a confirmação do caixa na retaguarda, na parte de recebimentos deverá constar o registro que pode ser conferido acessando o botão da imagem abaixo:

Foi criada uma nova promoção a ser contabilizada no frente de caixa chamada VALOR DO CUPOM(Tipo 7). Segue a imagem:

A mesma funciona exatamente igual à promoção do DESCONTO FIXO(Tipo 6), só que os descontos só serão aplicados se o valor estabelecido para o cupom for alcançado.

Segue a imagem abaixo:

Foi retirada a rejeição 656 - Consumo indevido pelo aplicativo da empresa da tabela de rejeições críticas, logo a nota ficará em contingência e não será rejeitada. O processamento das contingências também foi revisto para forçar o status de rejeição logo na primeira tentativa de transmissão, evitando tentativas repetidas de notas que não podem ser transmitidas por motivo de rejeição. Lembrando que uma contingência setada como rejeitada (STATUS = 2) terá apenas uma tentativa de transmissão por dia.
Por fim, foi adicionado na tabela NFE_TEMPO o campo REJEITADO para permitir ao suporte identificar algum possível problema de uso indevido por motivo de rejeição que ainda possa vir a ocorrer.

Foi atualizada as formas da SEFAZ que podem ser associadas as formas de recebimento do Intellicash. Segue a imagem:

No Intellicash as novas formas podem ser selecionadas nesta tela:

Foi criada a permissão DUPLICARCUPOMDIAANTERIOR para que seja possível o usuário duplicar um cupom cancelado no dia anterior. Segue a permissão no IntelliCash:

No frente de caixa, teremos:

Alteração efetuada para respeitar a configuração do IntelliCash. No EasyCash foi criada a configuração 5508 e adicionada na interface somente para conferência. Segue:

Vale ressaltar alguns itens:

• A alteração abrange o preço por quantidade por cliente também, portanto ambos os descontos devem ser testados;
• Apesar o escopo da tarefa estar mencionando o campo vUnCom do xml, o preço por quantidade é aplicado como desconto no item, portanto não se altera o valor unitário do produto;
• O valor de desconto aplicado no cupom continua trabalhando com duas casas decimais, alterou-se somente as casas decimais utilizadas a efeito de cálculo.

Na aba de detalhamento dos itens do XML agora é possível acessar um item apenas digitando o mesmo. Segue:

Foi criada uma configuração para que seja possível imprimir o NSU das transações TEF em relatório gerencial após a finalização da venda. Segue:

Será impresso o relatório:

Foi alterada a procedure EC_EXPT_GETEASYCASH_HEADER para validar se o IDHEADER buscado no caixa não é maior do que o gerador atual do IntelliCash, efetuando a atualização imediata do mesmo, caso afirmativo.

Corrigido para não sair da tela de venda ao clicar no botão cancelar na tela de motivo de cancelamento.

Foi tratado para não setar nenhum endereço para o ID de agente 10(Consumidor) no XML.

Corrigido para que ao reativar um cupom de venda, o orçamento vinculado ao mesmo seja reinserido nas tabelas de DAV do retaguarda.

Alterado na tela de troca de usuário para que não feche o sistema caso cancele a tela de login, permanecendo o usuário logado anteriormente.

Na tela de busca do cliente foi alterado para mostrar a mensagem de AGENTE INATIVO antes da permissão de status, interrompendo o fluxo caso o mesmo esteja desativado no IntelliCash.

Alterado para que ao duplicar um cupom o preço de venda seja o de quando a venda foi realizada e não do cadastro do produto, evitando reajuste ao duplicar o cupom.

Correção efetuada para ratear corretamente o valor residual de forma que não ultrapasse o valor do item e caso não tenha nenhum item com valor maior que o resíduo, o mesmo seja dividido entre vários itens. Foi efetuada na procedure RATEARDESCACRESCSUBTOTAL a mesma correção devido a diferenças detectadas pelo suporte no rateio em alguns clientes. A procedure RATEARDESCACRESCPORFPG também foi alterada para que o os valores calculados por ela não influenciem na totalização da venda, uma vez que o processo de desconto/acréscimo por forma de pagamento utiliza-se do desconto/acréscimo no subtotal.