2.36.00 ________________________
(53061) Foi realizada uma análise no relatório "Comparativo de Venda de Produtos por Lojas", após ser identificada uma divergência na apresentação das vendas realizadas por meio de DAV.
Durante a análise, verificamos que o relatório não estava considerando corretamente o modelo do DAV na consulta das informações. Isso ocorria devido a um critério de relacionamento entre os dados que não estava devidamente vinculado, fazendo com que algumas informações relacionadas às vendas por DAV não fossem apresentadas corretamente no relatório.
Para corrigir o comportamento, foi realizado um ajuste na estrutura de consulta do relatório, acrescentando o critério necessário para relacionar corretamente as informações do DAV, SubDAV e seu respectivo modelo. O ajuste também foi realizado tomando como referência os critérios utilizados no relatório "Movimentação de Saída de Produto por Cliente", garantindo maior consistência entre os relatórios.
Após a correção, o relatório passa a considerar corretamente as vendas realizadas por DAV, permitindo que as informações sejam apresentadas de acordo com os critérios definidos para a movimentação dos produtos por loja.
A correção foi realizada pelo suporte após a liberação da hotfix necessária para aplicação do ajuste.
(53095) Inicialmente, atuamos na investigação da indisponibilidade de determinados documentos fiscais (XML) que não estavam sendo retornados durante as consultas no sistema. Durante as checagens com o parceiro integrador (TecnoSpeed) e as validações nos portais oficiais, foram respeitados os intervalos de contingência e as janelas de consulta estipuladas pelas regras fiscais.
Aprofundando a análise técnica por meio das notas normativas da SEFAZ sobre o método de distribuição de documentos fiscais, identificamos a causa raiz da inconsistência: o sistema estava consultando valores de NSU (Número Sequencial Único) de forma estática, o que gerava repetição na busca dos mesmos registros e impedia o avanço para a localização das novas notas disponibilizadas.
Para resolver a situação em definitivo, aplicamos as seguintes melhorias na estrutura do sistema:
Criação de novos campos de controle nas tabelas de empresa e loja para registrar de maneira automática o último NSU consultado e processado.
Reestruturação do fluxo de consulta para que as requisições passem a buscar sequencialmente apenas os novos documentos fiscais pendentes, garantindo continuidade e conformidade com o padrão da SEFAZ.
Realização de testes práticos de validação diretamente na base, obtendo êxito imediato com o retorno de mais de 50 documentos fiscais que antes se encontravam retidos.
Adicionalmente, neste mesmo período de atendimento foram prestados apoios técnicos internos complementares:
Suporte na verificação do cálculo de saldo do fechamento de caixa para adequação em tarefa personalizada.
Alinhamento de rotinas referente aos documentos de Nota Fiscal de Serviço (Engelmig) e verificação das diretrizes de ponto de acesso vinculadas a demandas em andamento.
Com esses ajustes, a sincronização e o download dos XMLs de documentos fiscais passam a operar normalmente e de forma contínua.
2.36.02 ________________________
(53630) Foi realizada uma análise após ser identificado um erro na transmissão de notas fiscais que possuíam produtos complementares. Durante a verificação, constatamos que, nesses casos, os produtos complementares não estavam tendo os tributos de IBS e CBS calculados corretamente.
A situação ocorria porque os produtos complementares eram registrados internamente com código de produto igual a 0, fazendo com que o sistema não identificasse corretamente o grupo fiscal correspondente para realizar o cálculo dos tributos.
Para solucionar o problema, foi realizado um ajuste no sistema para que, quando essa situação ocorrer, seja considerado o grupo fiscal padrão para o cálculo dos tributos de IBS e CBS dos produtos complementares.
Após a atualização do sistema e aplicação da correção, o comportamento foi normalizado e as notas fiscais puderam ser transmitidas corretamente.
2.36.03 ________________________
(53167) Foi identificado que, ao realizar a importação de um DAV para uma nova Nota Fiscal, o sistema não permitia a inclusão de clientes que estivessem com o cadastro desativado.
No processo utilizado pela Sema, entretanto, um cliente com cadastro desativado ainda pode realizar compras, desde que a operação seja realizada à vista. Esse comportamento já era permitido no processo de emissão da Nota Fiscal antiga, sendo necessário adequar a nova Nota Fiscal para seguir a mesma regra.
Dessa forma, foi realizado um ajuste no sistema para permitir a importação de DAVs vinculados a clientes com cadastro desativado na emissão da NF-e.
Com a alteração, a nova Nota Fiscal passa a respeitar a regra já utilizada pela Sema, permitindo a continuidade da operação à vista mesmo quando o cliente estiver com o cadastro desativado.
(52509) Foi realizada uma análise no relatório de Listagem de Contas a Receber, após ser identificado que os valores apresentados no campo de totalização estavam sendo cortados quando ultrapassavam determinada quantidade de caracteres. A inconsistência ocorria especificamente no campo de valores, enquanto os demais campos do relatório permaneciam sendo apresentados normalmente, mesmo quando possuíam mais caracteres.
Para solucionar a situação, foi realizado um ajuste no tamanho do campo destinado à apresentação dos valores no totalizador do relatório, permitindo que números maiores sejam exibidos integralmente.
Após o ajuste, foram realizados novos testes no relatório e confirmado que o campo passou a comportar corretamente os valores, sem que as informações sejam cortadas durante a visualização ou impressão.
Além dessa correção, a OS também contemplou outros ajustes e análises. Foi realizada uma adequação no relatório de Lucratividade para o Cícero, pois a logo da empresa não estava sendo apresentada corretamente em um dos layouts utilizados.
Também foi realizado um processo de análise e depuração no DAV relacionado à Ordem de Serviço, com o objetivo de compreender o funcionamento e a sequência do processo, permitindo uma avaliação mais precisa para futuras correções ou melhorias relacionadas à rotina.
(52799) Inicialmente, avaliou-se a possibilidade de disponibilizar a edição manual do campo de percentual do DIFAL diretamente na nota fiscal, sem depender exclusivamente do grupo fiscal. No entanto, após uma verificação aprofundada da transmissão e das regras fiscais vigentes, identificamos os impactos técnicos dessa mudança e constatamos que o percentual em questão não diz respeito à base de cálculo do DIFAL, mas sim à partilha interestadual do ICMS, que por determinação legal está fixada em 100% desde o ano de 2019.
Para garantir conformidade fiscal e segurança sem gerar impacto negativo nas regras já consolidadas do grupo fiscal, direcionamos a correção da seguinte forma:
Foi aplicada uma tratativa no sistema para que, nos casos em que o produto não possua grupo fiscal vinculado, o percentual de partilha seja preenchido automaticamente com 100%.
Elaboramos um roteiro de validação completo para a equipe de qualidade, o qual foi devidamente anexado à ordem de serviço.
Efetuamos testes práticos de lançamento de documentos fiscais simulando produtos sem grupo fiscal em operações com movimentação de DIFAL, confirmando que a alíquota de partilha agora é carregada e preenchida corretamente conforme esperado.
Com esse ajuste, a transmissão ocorre de forma adequada e automatizada, assegurando a correta apuração dos tributos.
(52944) Atendendo à necessidade de maior flexibilidade na consulta financeira, desenvolvemos um novo parâmetro de configuração para o controle do intervalo de datas. Anteriormente, a filtragem do contas a receber possuía um limite fixo de até 90 dias; com essa nova configuração geral, passa a ser possível definir e expandir o período limite de dias para consulta de acordo com as necessidades operacionais da sua empresa.
As seguintes etapas fizeram parte deste processo:
Desenvolvimento do parâmetro de controle e alinhamento interno da estrutura de configuração para garantir total aderência ao fluxo de trabalho.
Elaboração de um roteiro de validação específico para a ordem de serviço.
Realização de testes práticos de filtragem nas telas de contas a receber e contas a pagar, confirmando que os filtros agora respeitam com precisão o novo limite configurado globalmente.
O recurso foi validado com sucesso e encontra-se pronto para utilização.
(53137) Inicialmente, atuamos no ajuste pontual dos valores de um DAV específico, efetuando o saneamento do item tanto no sistema quanto na base de dados, permitindo a exclusão correta e a liberação das quantidades que haviam ficado retidas.
Após essa etapa inicial, o cenário foi aprofundado junto à equipe de engenharia para identificar a origem do comportamento. Durante a investigação, constatou-se que, ao realizar a importação de DAVs do tipo Pré-venda para um documento fiscal, o sistema estava carregando itens que já se encontravam cancelados no subdav. Essa inconsistência também afetava a rotina de impressão do DAV, gerando divergência no totalizador por considerar valores de itens que já haviam sido cancelados.
Diante disso, aplicamos as seguintes melhorias estruturais no sistema:
Correção no fluxo de importação do DAV: agora, ao importar um DAV do tipo Pré-venda para o documento fiscal, produtos previamente cancelados são totalmente desconsiderados e não integram a emissão.
Tratativa na rotina de impressão do DAV: os relatórios e impressões foram ajustados para que o somatório considere estritamente os produtos ativos, eliminando divergências de valores causadas por itens cancelados.
Testes práticos em emissões com DIFAL: foram conduzidos testes complementares no módulo fiscal simulando operações com alíquota de DIFAL, onde confirmamos que os dados da partilha foram gerados e salvos com sucesso no documento fiscal, operando conforme esperado.
Adicionalmente, parte da carga horária desta ordem de serviço foi dedicada ao apoio técnico interno em rotinas de transmissão de Nota Fiscal de Serviço (Engelmig), atuando no alinhamento de novas regras de checagem e validação dos processos desse módulo.
Com essas intervenções, o fluxo do DAV e a emissão dos documentos fiscais voltam a operar com estabilidade e total consistência de dados.
2.36.04 ________________________
(53167) Foi identificado um comportamento na tela de emissão da Nota Fiscal que ocorria durante a importação de um DAV. Após realizar a importação, alguns elementos do formulário eram afetados, fazendo com que o layout da tela apresentasse inconsistências e, em determinadas situações, ficasse em branco.
Durante a análise, verificamos que, ao trocar de uma aba para outra dentro da própria Nota Fiscal, a tela era recarregada e voltava a apresentar as informações corretamente. Porém, esse comportamento não era o esperado e poderia dificultar a utilização do processo pelo usuário.
Dessa forma, foi realizado um ajuste no formulário da Nota Fiscal para corrigir o comportamento dos componentes após a importação de um DAV.
Após a aplicação do ajuste, foram realizados testes de importação do DAV no documento fiscal e a tela foi recarregada corretamente, mantendo o layout e as informações apresentadas conforme o esperado.
(53251) Foi realizada uma correção para garantir que, no momento da baixa/quitação de um título, os parâmetros carreguem automaticamente a mesma empresa/loja vinculada ao lançamento de origem.
Após a implementação, foram realizados testes práticos no fluxo financeiro, confirmando que a seleção da loja agora é mantida de forma correta e automática durante todo o processo de quitação.
(52632) Foi implementada a tag de valor atacado e ajustada a regra de apresentação: agora, quando o modelo de DAV configurado estiver definido para utilizar essa condição, o preço a prazo no atacado será carregado e exibido diretamente no card do produto.
Com esse ajuste, a visualização dos valores passa a refletir com exatidão a regra comercial selecionada no modelo de DAV, trazendo mais agilidade e precisão no momento da consulta.
(52843) Identificamos e atuamos na correção de um erro em tempo de execução (runtime) que ocorria no módulo Zeus durante o processo de inclusão de proprietário de veículo.
Durante a bateria de validações e testes práticos, nossa equipe também detectou uma inconsistência pontual no comportamento de navegação entre campos (ordem do tabindex) no componente de preenchimento do CNPJ. Esse detalhe de usabilidade foi devidamente corrigido para garantir uma navegação fluida e sem falhas na tela.
No momento, estamos finalizando a geração do pacote de compilação geral contendo essas correções na versão atualizada da funcionalidade para realizar a checagem e homologação final.
Assim que essa validação for concluída, retornaremos com a confirmação da liberação.
