Versão GNFe: 2.0.14.4 <sem alteração>
Versão DLL: 2.0.29 <Valores Unitários com 10 casas decimais>
Versão UDF: <Sem Alteração>
Versão EnterpriseServer: 3.1.0.15 <Sem Alteração>
Versão EnterpriseServer_EC: 4.3.8742.40558
Versão EnterpriseServer_ISA: 4.2.0.0
Versão Scanntech: 1.1.0.0 <correções nos travamentos>
Versão Sincronizador: 1.0.0.1 <Melhorias no Cadastro de Vendedores>
Versão Sincronizador_Mercafácil: 2.0.0.0
Versão EasyCash: 1.5.002.004
Versão EasyCheckOut: 1.0.3.0
Versão EasyPDV: 3.0.0.15
Versão EasyPDV_New: 2.1.1.0
Versão NFeDestinada: 3.4.8620.61063
Versão Intellifood: 1.8.0.0
Versão IWB_SERVER: 1.0.0.5
Versão EasyWatchDog_Enterprise_EC: 1.0.0.5
Versão Sincronizador Área Central: 1.0.0.2
Versão IntelliStock Android 1.0.4.1
IMPORTANTE
Para atualizar um cliente da versão 3.0.136.XXX para a versão 3.0.137.XXX é preciso tomar alguns cuidados antes de executar a atualização:
De acordo com nota técnica 2019.001, alguns estados optaram por exigir o código de benefício fiscal nas NF-e(modelo 55) e NFC-e(modelo 65).
Se você usa um código de tributação com benefício fiscal (CST), vai ser obrigatório informar o código desse benefício (cBenef) na nota.
Se essa informação estiver faltando, a nota fiscal será rejeitada:
No caso do estado de Santa Catarina essa exigência passa a valer a partir de 5 de Maio de 2025.
No cadastro de produto foi incluído um campo chamado “CBenef” dentro da aba “Impostos”.
Esse campo só será habilitado se a empresa emitente estiver no estado exigente do CBenef(GO, PR, RJ, RS e SC):
Cada estado disponibiliza de uma tabela própria, então só serão exibidos os códigos mediante ao CST que exige código. Os códigos possuem 8 dígitos e cada estado coloca como prefixo a sigla de sua UF.
Esses códigos serão exportados para o frente de caixa e o frente de caixa também irá fazer os devidos tratamentos.
Importante: As CSTs que exigem o Cbenef são: “00,10,60 ou 90”
Na versão 3.1.18.0, ao abrir uma nota com muitos itens e associada a um pedido, igualmente grante, havia lentidão no carregamento da tela e na troca de linha entre um item e outro. Acontecia que o evento de mudança da linha estava executando uma atualização no banco de dados. Essa atualização foi removida interrompendo a lentidão. Ocorre que agora a atualização de status dos itens associados uns com os outros achotece somente no carregamento do produtos.
Algumas vezes acontece do arquivo xml que os coletores enviam para o sistema estar com a validade do produto inválida (ex.: 31092026, 30022027), apesar de haverem tratamentos para evitar a digitação dessas datas nos coletores. Acontece que ao tentar iserir essa informação no banco de dados ocorre o erro na conversão do texto para o tipo data, assim, a excessão impeda a continuidade de inserção dos itens sequintes ao inválido.
Foi criado um tratamento para validar a data do produto e aplicar o ajuste para o último dia do mês indicado na data inválida. Esta correção aconteceu no procedimento de importação de arquivo do IC e, mais importante, no servidor do ISA (versão 1.0.4.2) que, ao receber os dados do coletor, insere as coletas diretamente no banco de dados do sistema.
Essa correção permite que o procedimento de inserção de produtos não seja interrompido em caso de equivoco na coleta de validade.
No ISA um log é gerado para informar a alteração de datas quando há ocorrência de erro:
Validade inválida para o item 00000078908901: 31/09/2027 -> 30/09/2027
Como visto é apresentado o item com data incorreta, a data incorreta e o ajuste aplicado.
No IC a mesma coisa acontece porém um diálogo aparece para informar o ocorrido.