2.32.01 ________________________
(OS 50196) - Foi localizada a causa dos produtos estarem alterando o preço automaticamente, o que ocorria era o seguinte cenário; O cliente utiliza uma configuração na precificação que seria "Atualizar preço de venda automaticamente ao lançar a nota fiscal com valor de venda atual" . Ou seja, com essa configuração marcada no momento que o usuário entrar com a NF ela será precificada automaticamente, porém o seu valor de venda não é alterado. Assim deveria funcionar quando fosse excluísa uma precificação, mas isso estava sendo processado incorretamente. Com isso foi criado um fluxo que funcionará da seguinte maneira; quando colaborador lançar uma NF de Entrada será salvo na precificação um valor na coluna TipoPrecificacao, coluna essa que foi criada nova também para esse cenário. Ela será salvo de acordo com o bit que está na configuração geral, que no caso dessa que mencionamos será salvo como Tipo 3. Quando o usuário for excluir a precificação caso ela esteja com o TipoPrecificacao = 3 os valores referente a venda não poderão ser retornados. Pois hoje qual excluo uma precificação ela volta os valores e de acordo com a ultima precificação lançada. Então esse cenário trata essa situação. Pois como ele entrou com a NF precificando sem alterar valor de venda a exclusão deve funcionar da mesma forma.
(OS 49553) - Ajuste de query do fechamento de caixa pois quando realizada uma NF de devolução para cliente gerando crédito para ele no faturamento, o sistema virava o documento para faturado igual a “Sim”, porém o registro não ficava sendo barrado no fechamento de caixa.
(OS 49316) - Ajustado no modelo de boleto, na cessão de Juros, a label do campo onde se informa o jutos, informando ao usuário que se trata de uma porcentagem e não valor. Tratado também sobre quando o boleto estiver marcado para ativar boleto hibrido, quando é assim ele vai sozinho para a API da tecnospeed, não depende de incluir em remessa, e nisso o boleto não estava virando o status para Bo_incluidoemremessa, agora ele vira pra Sim essa coluna no banco.
(OS 48243) - Foi implementada uma configuração no sistema, no terminal, na guia Documentos de Saída – Nota Fiscal, chamada “Travar lançamento de Nota Fiscal de Saída com data retroativa”. Com essa opção ativada, caso o colaborador tente lançar uma Nota Fiscal informando uma data anterior, o sistema exibirá uma mensagem e bloqueará a operação.
2.32.02 ________________________
(OS 50143) - Realizado tratativa para quando a configuração geral "Não permitir realizar quitação recebimento sem Caixa DAV" estiver marcado, no momento de quitar um contas a receber o campo de data ficará habilitado. Porém caso o colaborador informe uma data retroativa na qual o caixa não esteja aberto será barrado. Informando uma mensagem especificando o caixa.
2.32.05 ________________________
(OS 50657) - Ajustes na quitação de pagamento para não levar em conta a configuração geral “Não permitir quitação de recebimento sem caixa DAV” dentro de Financeiro, assim ao realizar uma quitação de pagamento a data de quitação fica sempre aberta independe da configuração geral.
(OS 50655) - Ajustes na geração do SPED contribuições e SPED fiscal solucionando erros relacionados a unidade de medida e alíquotas de PIS/COFINS e também na conta contábil. Estavam ocasionando falta de informações na geração das escriturações.
(OS 50630) - O gerador do Sintegra apresentava erro ao gerar os dados de ICMS para empresas do Simples Nacional em algumas notas específicas. Foi identificado que o problema estava relacionado à sincronização dos dados dos registros tipo 50 e tipo 54. Ajustado.
(OS 50603) - Foram identificados vários problemas na geração do SPED devido à falta de integridade dos dados, especialmente no cadastro de unidades de medida. Foi realizada a correção no gerador.
(OS 50415, #004536) - Ajustado agravação da NFS-e, para gravar o codigo NBS e serviço nacional no campo correto na base de dados.
2.32.06 ________________________
(OS 50691) - No formulário de mobile, na guia “Ocorrência de Produção”, foram inseridas as seguintes configurações:
Ao termino da ocorrência solicitar finalização de jornada
Registrar trabalhando
Registrar Intervalo
Registrar Tempo Improdutivo
Registrar Deslocamento
2.32.08 ________________________
(OS 50497) - Ajustado a NF de saída gerada pela transferência de estoque para que gere corretamente as informações de IBS/CBS no XML corrigindo o erro na transmissão da NF.
(OS 50473) - Foi realizada uma melhoria na tela de suprimento e sangria, tanto na NFC-e quanto no formulário do Hermes. Na grid, o nome da loja não estava sendo exibido corretamente, pois estava cortado e utilizava um modelo antigo. Esse problema foi corrigido, garantindo a visualização completa das informações. Além disso, foi implementada uma melhoria na usabilidade: ao editar um registro de suprimento ou sangria, ao fechar a tela, o sistema manterá destacado em azul claro o registro que foi recentemente alterado.
(OS 50448) - Foram realizadas melhorias no relatório de Relação de Estoque 2. Anteriormente, ao exportar os resultados para Excel, era criada uma nova coluna contendo apenas o nome dos estoques. Esse comportamento foi ajustado para que a sigla do estoque seja concatenada, indicando a qual estoque pertence cada quantidade. Também foram feitas correções no relatório, pois ao gerar com filtros de grupo e subgrupo ocorria um erro no banco de dados. Além disso, foi removida a coluna Valor Total do filtro na listagem de estoque por valor de produto e valor total.
(OS 50398) - Implementado no terminal, na guia de ECF/NFC-e, guia Geral, a busca de plano e subplanos de Suprimento e Sangria por CFG, deixando de ser por lista.
(OS 50386) - Foi tratado no relatório de Faturamento por Vendedor, que na impressão agora irá mostrar o Totalizador por Tipo cliente, no rodapé do relatório terá o total de Pessoa Física, Jurídica e Produtor Rural separados no relatório.
(OS 50301) - Foi desenvolvido um bloqueio para impedir a inclusão de um novo contrato de financiamento com um número interno já cadastrado no sistema. Caso o colaborador tente utilizar um número duplicado, o sistema não permitirá o salvamento. Essa validação também se aplica na edição: ao tentar alterar um contrato para um número já existente, o sistema exibirá uma mensagem e bloqueará a operação.
(OS 50297) - Foi realizada a correção da consulta executada na inicialização do sistema, responsável por buscar as Notas Fiscais que estavam em digitação. Essa consulta era utilizada para exibição na guia de notificações, porém estava mal indexada e possuía uma ordenação desnecessária, o que impactava o desempenho. Foram feitos ajustes para tornar o processo de login mais rápido. Também foi corrigida a lentidão ao editar contas a pagar. O problema ocorria porque a consulta não filtrava pelo código da parcela que estava sendo editada, fazendo com que o sistema percorresse toda a tabela de rateio competencia, o que causava demora na abertura do formulário.
(OS 49505, #004475, #351629) - No CFG de processo interno não estava tratado pra fazer a leitura dos valores na Tipo Origem 11 e 12. Tratativa realizado no CFG na qual agora contém valor mostrando na coluna, Que seria aluguel de máquinas e recebimento suprimento.
(OS 49579, #004486, #353066) - Ajustes nos botões da tela de cotação pois estavam cortando ou não sendo exibidos dependendo da resolução da tela do monitor do usuário.
2.32.10 ________________________
(OS 50681) - Ao realizar uma importação de DAV na NFCe estara ocorrendo um RunTime se algum item do DAV não possuísse os campos relacionados ao CST por não se utilizar na loja por exemplo. Corrigido para informar uma crítica e não o erro.
(OS 50671) - Ajustes no lançamento de suprimento e sangria para ir para o Relatório de Fechamento de caixa com a data informada no lançamento do suprimento e sangria. Antes, independente da data digitada a movimentação do relatório levava em conta a data do sistema e não a data digitada pelo usuário.
(OS 50664) - No relatório de Extrato de contas, foi desenvolvido a exportação para Excel.
(OS 50652) - Ao ativar um novo Período Gerencial, o sistema executava automaticamente o processo de replicação dos Limites de Autorização de Funcionários do período anterior para o novo período. Durante esse processo, os funcionários que possuíam Limite de Autorização configurado com o tipo Por Sub Plano tinham seus registros de sub planos duplicados incorretamente. Por exemplo, um funcionário que possuía os sub planos A, B e C no período anterior, ao ter seu limite replicado para o novo período, recebia os sub planos A, A, B, B e C, C — ou seja, cada sub plano era inserido duas vezes. Ajustado.
(OS 50612) - Ajustado a duplicação de grupo fiscal estadual para ao duplicar deixar a loja aberta para edição. Ao salvar o novo registro e editar ela já virá travada.
(OS 50578) - Inserido no grupo fiscal referente a tributação PIS/COFINS uma guia "Observação" onde ao inserir um item na NF com esse grupo fiscal, essa observação vai para a nota.
(OS 49195) - Implementado no modelo de DAV, na guia Página 2 uma nova configuração "Manter por padrão Todos no filtro de loja no localizar DAV. Onde se estiver marcado, ao localizar um DAV (F8) vai vir por padrão no campo de loja a opção de todas as lojas.
2.32.12 ________________________
(OS 50759) - Implementado no carregamento do DAV quando for do tipo contrato de fornecimento a validação de estoque conforme já funciona nos outros tipos obedecendo a configuração geral.
(OS 50320) - Foi realizada uma correção no sistema para que, ao lançar um DAV vinculado a uma Ordem de Serviço com a configuração de transferência para estoque de reserva habilitada, a movimentação de estoque seja efetuada automaticamente, seguindo o mesmo comportamento já aplicado no processo padrão de DAV.
(OS 50416) - Foi desenvolvido uma configuração no cadastro da LOJA na guia de Precificação. Configuração se chama "Processar crédito de ICMS para produtos que o tipo do item seja "Mercadoria para Revenda". Essa configuração quando estiver marcada o calculo do Crédito ICMS no momento de gerar precificação passará por alterações, pois ele irá pegar o valor ICMS do Item + o valor do Simples dividido pelo valor total do produto multiplicado por 100 para chegar no resultado do percentual, Depois o crédito ICMS assumirá o valor do percentual multiplicado por -1 resultando em um valor negativado. Mas para isso a configuração no cadastro da loja deverá estar marcada e o produto ser do tipo Mercadoria para Revenda
(OS 50579) - Devido aos padrões de precificação utilizados para empresas de regime tributário do Simples Nacional e tributação normal, alguns parâmetros de cálculo e reflexo da formação de custo, custo médio, custo comercial e preço de venda precisaram passar por ajustes.
Empresas de regime de tributação normal, ou seja, Lucro Real ou Lucro Presumido, basicamente devem manter o padrão de precificação da versão anterior, onde, ao realizar a entrada da nota fiscal, os dados referentes ao preço de custo do produto são atualizados exclusivamente pela nota fiscal de entrada.
Para este mesmo caso, foi acrescentada uma parametrização onde o sistema passa a verificar o ICMS da nota fiscal de entrada, de forma a transferir automaticamente o valor do ICMS de entrada como crédito do produto para sua formação de preço de custo na interface de precificação.
Porém, devido à maior flexibilização tributária para empresas do Simples Nacional, onde o tributo não necessariamente é cobrado sobre o valor do ativo da empresa, a forma de precificação de custo foi alterada.
A empresa do regime tributário Simples Nacional passa a ter a condição de replicar seus dados de custo para todas as empresas cadastradas no sistema, seguindo as regras de replicação de venda.
Para que estes novos recursos sejam acionados, devem ser observados os seguintes parâmetros criados no cadastro da empresa:
• Realizar atualização de custo de outra loja seguindo a parametrização da precificação:
Quando esta opção estiver marcada, a loja passará a receber os custos de outra loja seguindo a regra de precificação, observando que ambas obrigatoriamente deverão estar enquadradas no regime do Simples Nacional.• Gerar crédito de ICMS para produtos de mercadoria para revenda:
Quando esta opção estiver marcada como “Sim”, ao ser detectado um produto classificado como mercadoria para revenda que possua ICMS, o percentual do ICMS será transferido automaticamente como crédito de ICMS para formação do custo da mercadoria.Vale lembrar que esta parametrização somente é permitida para empresas de regime tributário normal, pois apenas estas podem se apropriar de crédito de ICMS.
(OS 50829, #004543, #370687)- Durante a análise da necessidade apresentada, foi identificada a oportunidade de tornar o processo de elaboração de cotações mais seguro e aderente à estrutura organizacional das empresas cadastradas no sistema.
Para atender essa necessidade, foi desenvolvida uma nova configuração localizada em Almoxarifado > Suprimentos, denominada "Usar apenas setores vinculados à empresa informada na cotação".
Quando essa configuração estiver habilitada, o sistema passará a considerar a empresa selecionada na cotação como critério para carregamento dos setores disponíveis. Dessa forma, ao acessar o formulário de cotação, serão exibidos apenas os setores que possuem vínculo com a empresa informada no documento.
Antes dessa implementação, o sistema poderia apresentar setores sem relação direta com a empresa selecionada, o que aumentava o risco de seleção incorreta e poderia gerar inconsistências operacionais durante o processo de cotação.
Com a nova funcionalidade, o sistema passa a:
Filtrar automaticamente os setores de acordo com a empresa informada na cotação;
Exibir apenas setores efetivamente vinculados à empresa selecionada;
Reduzir a possibilidade de erros de seleção;
Garantir maior consistência nas informações utilizadas no processo de compras e suprimentos;
Facilitar a utilização da rotina pelos usuários, apresentando apenas opções válidas para o contexto da operação.
2.32.15 ________________________
(OS 51085) -Foi identificado que, no caso de notas fiscais de saída de emissão própria com destaque de frete, o gerador do Sintegra não estava considerando corretamente o valor do frete na geração das informações. Foi realizado o ajuste necessário e a geração do arquivo Sintegra foi corrigida para considerar adequadamente o valor destacado de frete nas notas fiscais.
2.32.16 ________________________
(OS 51062) -No processo de importação de um DAV na NF de Cliente (modelo novo), o campo “Tipo de Operação” estava sendo apresentado incorretamente apenas como “Tipo de Venda”. Foi realizada a correção para que o tipo de operação exibido no corpo da nota fiscal passe a respeitar corretamente o tipo de NF selecionado no momento da importação do DAV
(OS 51063) - Foi realizada a correção para que, no momento da inclusão do produto na NF-e, os campos de NCM sejam preenchidos corretamente na guia “Geral” da edição do produto. Anteriormente, o sistema estava informando incorretamente o código referente à chave primária interna da base de dados, ao invés do código NCM correspondente ao produto.
2.32.17 ________________________
(OS 51003, #004574, #378445) - Foi identificado que o problema ocorria devido à existência de notas fiscais com os campos XML/PDF nulos na base de dados. Como o sistema não estava preparado para tratar campos nulos nessa situação, acabava gerando o erro de RunTime durante o processamento.
Foram realizados os ajustes necessários para tratamento dessas ocorrências, garantindo que o sistema valide corretamente os campos antes da execução do processo.
2.32.21 ________________________
(OS 50986) - Durante a análise da solicitação, foram identificadas e corrigidas melhorias relacionadas ao processo de precificação, abrangendo o cálculo do crédito de ICMS, a impressão de relatórios e a precificação realizada diretamente pelo cadastro de produtos.
A primeira correção refere-se ao cálculo do crédito de ICMS durante a precificação de Notas Fiscais. Foi identificado que, ao processar os produtos, o sistema não reinicializava corretamente a variável responsável pelo cálculo do crédito de ICMS a cada novo item. Como consequência, o valor de crédito calculado para o primeiro produto era acumulado nos produtos seguintes, gerando um efeito cascata. Esse comportamento fazia com que os custos e os valores de precificação dos itens posteriores fossem calculados de forma incorreta.
Para solucionar essa situação, a rotina de cálculo foi ajustada para que cada produto seja processado de forma independente, considerando exclusivamente o seu respectivo crédito de ICMS. Com essa alteração, a composição dos custos e da precificação passa a refletir corretamente as informações tributárias de cada item, eliminando o acúmulo indevido de valores.
Além dessa correção, foi implementado o fluxo de impressão de relatório na tela de precificação, permitindo a emissão das informações processadas durante a rotina. Essa funcionalidade foi desenvolvida conforme os requisitos definidos e apresentados durante o alinhamento realizado com a equipe responsável.
Também foi corrigido o processo de precificação executado diretamente pelo cadastro de produtos. Foi identificado que, quando o produto ainda não possuía uma precificação cadastrada, o campo "Preço de Fábrica" era apresentado com valor zerado, o que poderia comprometer a correta formação dos preços.
Para esse cenário, foi implementada uma regra de tratamento que verifica a existência do preço de fábrica. Caso essa informação não esteja disponível, o sistema passa a utilizar automaticamente o preço de custo do produto como referência, garantindo a continuidade do processo de precificação e evitando a apresentação de valores zerados.
Com as melhorias implementadas, o processo de precificação tornou-se mais confiável e consistente, assegurando o cálculo correto do crédito de ICMS para cada produto, disponibilizando a impressão de relatórios da precificação e garantindo o correto preenchimento das informações utilizadas na formação dos preços, mesmo quando o produto ainda não possuir uma precificação previamente cadastrada.
(OS 51169) - Foi realizada a atualização do componente responsável pela emissão e transmissão de boletos bancários, com o objetivo de manter o sistema compatível com as versões mais recentes disponibilizadas pelo fornecedor da tecnologia.
Esse componente é utilizado na comunicação entre o sistema e as instituições financeiras, sendo responsável pelo processamento do envio das informações dos boletos ao banco, garantindo a correta integração para registro e demais operações relacionadas à cobrança bancária.
A atualização foi realizada utilizando a versão mais recente disponibilizada pela TecnoSpeed, empresa responsável pelo fornecimento e manutenção desse componente. Esse procedimento é importante para acompanhar as evoluções da tecnologia, manter a compatibilidade com os padrões bancários vigentes e assegurar maior estabilidade e confiabilidade no processo de transmissão dos boletos.
Após a atualização, o componente passou a operar integrado à versão atual do sistema, proporcionando um processo de comunicação mais seguro e preparado para atender às exigências atuais das instituições financeiras.
Com essa melhoria, o sistema permanece atualizado com as tecnologias disponibilizadas pela TecnoSpeed, contribuindo para a continuidade das operações de emissão e envio de boletos, além de reduzir a possibilidade de incompatibilidades decorrentes de alterações nos padrões de integração bancária.
2.32.22 ________________________
(OS 50143) - Durante a análise da solicitação, foi identificado que a regra relacionada à configuração "Não permitir realizar quitação de recebimento sem Caixa DAV" não estava sendo aplicada conforme o comportamento esperado, em razão de uma inconsistência que aparentemente ocorreu durante transições e atualizações anteriores do sistema. Diante disso, foi realizada uma revisão e adequação da funcionalidade para garantir o correto funcionamento da regra.
Com a correção implementada, quando a configuração "Não permitir realizar quitação de recebimento sem Caixa DAV" estiver habilitada, o campo de data da quitação permanecerá disponível para edição pelo usuário, permitindo informar uma data diferente da data atual. Entretanto, caso seja informada uma data retroativa, o sistema passará a validar se existe um caixa aberto correspondente à data informada.
Caso não exista caixa aberto para a data selecionada, a quitação será bloqueada e o sistema apresentará uma mensagem informativa ao usuário, indicando qual caixa deverá estar aberto para que a operação seja realizada.
Importante destacar que essa validação se aplica exclusivamente às movimentações vinculadas ao Caixa DAV. Para recebimentos e contas que não utilizam o Caixa DAV (contas não vinculadas ao caixa do sistema), a quitação continuará sendo permitida normalmente, inclusive com datas retroativas, sem a necessidade da existência de um caixa aberto.
Dessa forma, o processo passa a oferecer maior controle sobre as movimentações financeiras vinculadas ao caixa, mantendo ao mesmo tempo a flexibilidade necessária para os demais tipos de recebimento.
(OS 50835) - Durante a análise da ocorrência, identificamos que havia um comportamento indevido na transição entre os formulários de Nota Fiscal de Saída e Nota Fiscal de Entrada. Esse comportamento era causado pela permanência de informações temporárias em memória, fazendo com que determinadas configurações de uma tela influenciassem visualmente a outra.
O principal impacto identificado estava relacionado à configuração de cálculo dos produtos, especificamente na opção de cálculo por Valor Total ou Valor Unitário. Embora essa configuração seja exclusiva da Nota Fiscal de Entrada, ao acessar ou editar uma Nota Fiscal de Saída o sistema podia apresentar alterações visuais indevidas nessa opção, mesmo sem qualquer modificação efetiva gravada no banco de dados.
É importante destacar que o problema afetava apenas a exibição das informações na tela, não comprometendo os dados armazenados na base de dados. Entretanto, essa situação poderia gerar dúvidas e inconsistências visuais durante a utilização do sistema.
Para solucionar definitivamente a ocorrência, foram realizadas as seguintes adequações:
Bloqueio do campo de seleção relacionado ao cálculo dos produtos na Nota Fiscal de Saída, impedindo alterações ou interações indevidas em uma configuração que não pertence a esse processo.
Implementação do recarregamento automático das configurações diretamente do banco de dados sempre que uma Nota Fiscal de Entrada for aberta para edição, garantindo que as informações exibidas reflitam exatamente os dados gravados no sistema.
Ajuste no controle interno de memória da aplicação para evitar que informações utilizadas em uma tela interfiram no comportamento de outras rotinas.
Definição de que, durante a inclusão ou edição de Notas Fiscais de Saída, as opções relacionadas ao cálculo por "Valor Total do Produto" permanecerão bloqueadas, respeitando as regras de negócio do sistema.
Com essas correções, foi garantida a integridade das informações apresentadas ao usuário, eliminando a interferência entre os formulários de Nota Fiscal de Entrada e Saída e assegurando que cada processo utilize exclusivamente suas próprias configurações.
(OS 50878) -Durante a análise da ocorrência, foi identificado que o formulário de cadastro/configuração de terminais estava aplicando validações obrigatórias relacionadas à NFC-e (Nota Fiscal de Consumidor Eletrônica) para todos os tipos de terminal, independentemente da finalidade para a qual o terminal havia sido configurado.
Com isso, mesmo quando o terminal era cadastrado para utilização em operações que não envolviam NFC-e, o sistema continuava exigindo o preenchimento de informações específicas desse modelo fiscal, como, por exemplo, os dados referentes ao Talão de Documento Fiscal e demais configurações exclusivas da NFC-e. Essa situação poderia dificultar o cadastro e a manutenção de terminais que não utilizam esse tipo de documento fiscal.
Para corrigir o comportamento, foi realizado um ajuste nas validações do formulário, fazendo com que o sistema passe a analisar o tipo de terminal configurado antes de exigir determinadas informações.
A partir da correção, quando o terminal estiver configurado com um tipo diferente de NFC-e, os campos e validações exclusivos desse modelo fiscal não serão mais obrigatórios. Já para terminais configurados para emissão de NFC-e, as validações permanecem ativas normalmente, garantindo o correto preenchimento das informações necessárias para a operação.
(OS 51009)- Foram realizados testes para identificar a origem da divergência apresentada nos cálculos relacionados ao frete.
Durante a investigação, foi constatado que a função responsável pelo cálculo do frete não estava considerando corretamente os valores dos impostos informados no formulário de inclusão dos produtos. Em razão disso, os resultados apresentados pelo sistema poderiam divergir do esperado em determinadas situações.
O comportamento era percebido principalmente nos cenários em que o usuário informava um percentual para que o sistema calculasse automaticamente o valor total do frete, bem como na operação inversa, quando era informado o valor total e o sistema precisava calcular o percentual correspondente. Nesses casos, a ausência da consideração dos impostos na fórmula de cálculo gerava inconsistências nos valores apresentados.
Para corrigir a situação, foi realizado um ajuste na rotina de cálculo, adequando seu funcionamento ao mesmo padrão já utilizado no processo de Pedido de Compra, que contempla corretamente todos os componentes necessários para a composição dos valores.
Com a correção implementada, os cálculos passam a considerar adequadamente os impostos informados no produto, garantindo maior precisão e consistência tanto na conversão de percentual para valor total do frete quanto na conversão de valor total para percentual, mantendo o comportamento alinhado às demais rotinas do sistema
(OS 51073)- Durante a análise da ocorrência, foi identificado que a rotina responsável por localizar os clientes para execução do processo estava utilizando uma consulta (SQL) que continha uma condição importante desativada/comentada. Como consequência, determinados clientes deixavam de ser localizados corretamente pelo sistema, impedindo o funcionamento esperado da rotina.
Após a identificação da causa, foi realizado o ajuste na consulta para restabelecer a regra de busca adequada, garantindo que os clientes sejam encontrados corretamente durante o processamento.
Além disso, foi implementada uma melhoria na rotina de quitação de boletos relacionada ao controle de bloqueio de clientes. A partir dessa adequação, quando um boleto for quitado para um cliente que esteja com o cadastro desativado, o sistema realizará automaticamente a reativação desse cadastro, desde que esteja habilitada a configuração "Bloquear ao iniciar o sistema", localizada em Configurações Gerais > Financeiro.
Com essa alteração, o sistema passa a manter maior consistência entre a situação financeira do cliente e o status do seu cadastro. Dessa forma, ao regularizar um débito por meio da quitação de um boleto, o cliente poderá ser reativado automaticamente, eliminando a necessidade de intervenção manual e tornando o processo mais ágil e seguro.
Em resumo, foram realizados dois ajustes:
Correção da rotina de localização de clientes, que não estava encontrando determinados registros devido a uma condição desativada na consulta.
Implementação da reativação automática do cadastro de clientes bloqueados após a quitação de boletos, respeitando as configurações financeiras definidas no sistema.
(OS 49721)- Durante a análise da solicitação, foi identificado que o sistema já possuía uma regra de segurança para impedir a exclusão de precificações quando existisse uma precificação posterior relacionada aos mesmos produtos. Essa validação é necessária para preservar a integridade das informações e evitar inconsistências nos históricos de precificação.
Nessas situações, ao tentar excluir uma precificação com status "Precificado", o sistema apresentava a mensagem informando que existiam itens vinculados a uma precificação posterior, impedindo a exclusão do registro. Entretanto, a mensagem exibida não informava quais produtos ou qual precificação estavam causando o bloqueio, o que dificultava a identificação da origem do problema e exigia análises manuais por parte do usuário.
Para tornar o processo mais transparente e facilitar a identificação das pendências, foi realizada uma melhoria na rotina de crítica de dados da exclusão de precificações.
A partir desta atualização, foi incluída a coluna Código do Produto na grade do formulário de crítica. Dessa forma, quando uma tentativa de exclusão for bloqueada devido à existência de uma precificação posterior para o mesmo produto, o sistema exibirá uma janela informando de forma detalhada:
O código da precificação posterior que está impedindo a exclusão;
O código do produto envolvido na validação;
Os registros responsáveis pelo bloqueio da operação.
Com essa melhoria, o usuário passa a ter informações suficientes para identificar rapidamente a relação entre as precificações, reduzindo o tempo gasto em análises e tornando o processo de correção muito mais simples e eficiente.
A alteração não modifica as regras de validação já existentes, apenas aprimora a apresentação das informações, oferecendo maior clareza e facilidade na identificação dos motivos que impedem a exclusão de uma precificação.
(OS 50846)- Antes da correção, foi identificado que, ao importar um DAV (Documento Auxiliar de Venda) para uma Nota Fiscal de Saída, o sistema não estava preenchendo automaticamente o campo CST (Código de Situação Tributária) dos produtos. Nesses casos, o CST era carregado em branco e somente era calculado após o usuário acessar a edição do produto e realizar uma nova gravação.
Após análise da rotina, verificou-se que o cálculo dos tributos estava sendo executado apenas em um momento posterior ao carregamento dos produtos na nota fiscal. Dessa forma, mesmo quando o produto possuía todas as configurações fiscais corretamente cadastradas em seu grupo fiscal, as informações tributárias não eram processadas durante a importação do DAV.
Para solucionar a situação, foi realizado um ajuste no fluxo de importação. A partir desta correção, o sistema passa a executar automaticamente o cálculo dos tributos antes que os produtos sejam carregados na grade da Nota Fiscal. Com isso, todas as informações fiscais necessárias, incluindo o CST, são processadas e preenchidas corretamente já no momento da importação.
Além disso, o comportamento da importação de DAV foi padronizado para seguir a mesma lógica já utilizada na importação de Notas Fiscais, garantindo maior consistência entre os processos e evitando a necessidade de intervenções manuais para atualização das informações tributárias.
Com a implementação realizada, os produtos passam a ser importados com o CST corretamente preenchido, desde que estejam devidamente configurados em seus respectivos grupos fiscais, proporcionando maior segurança fiscal, agilidade operacional e conformidade no processo de emissão das notas fiscais.
(OS 50849)- Durante a análise da ocorrência, foi identificado que, ao tentar realizar a quitação de determinados títulos no módulo de Contas a Pagar, o sistema apresentava a mensagem "Não é possível quitar com valor zerado", mesmo quando o título possuía valor corretamente informado.
Após investigação da rotina, foi constatado que o problema não estava relacionado ao valor do lançamento, mas sim à forma como o sistema localizava o registro durante o processo de quitação. A consulta utilizada para buscar as informações do Contas a Pagar realizava uma validação obrigatória com o cadastro de fornecedor. Como o título em questão havia sido cadastrado sem vínculo com um fornecedor, o sistema não conseguia localizar corretamente o registro para prosseguir com a quitação.
Como consequência dessa falha na localização do título, o sistema retornava uma mensagem incorreta informando que o valor estava zerado, quando na realidade o problema estava relacionado à ausência do fornecedor vinculado ao lançamento.
Para solucionar a situação, foi realizada uma adequação na consulta utilizada pela rotina de quitação. A partir desse ajuste, o sistema passa a localizar corretamente os registros de Contas a Pagar independentemente da existência de um fornecedor vinculado ao título.
Com a correção implementada, a quitação pode ser realizada normalmente para lançamentos que não possuam fornecedor associado, eliminando a mensagem indevida e garantindo o correto funcionamento da rotina financeira.
Essa melhoria proporciona maior flexibilidade para os cenários em que o controle financeiro é realizado sem a obrigatoriedade de vinculação de fornecedores, mantendo a integridade e a confiabilidade das operações de quitação.
(OS 50952)- Durante a análise da ocorrência, foi identificado que o formulário de Nota Fiscal não estava considerando corretamente as configurações do terminal selecionado no documento no momento da inclusão dos estoques.
O comportamento observado era que, ao incluir produtos na Nota Fiscal, o sistema utilizava sempre as configurações de estoque vinculadas ao terminal do usuário logado, independentemente do terminal selecionado na própria nota. Dessa forma, mesmo quando o colaborador alterava o terminal do documento, as informações de estoque continuavam sendo carregadas com base no terminal originalmente associado ao usuário.
Como consequência, os estoques exibidos e utilizados na operação poderiam não corresponder às configurações do terminal efetivamente selecionado na Nota Fiscal, gerando divergências operacionais e dificultando o correto controle dos movimentos de estoque.
Para corrigir essa situação, foi realizada uma adequação na rotina do formulário de Nota Fiscal. A partir da implementação, o sistema passa a validar e utilizar as configurações do terminal informado diretamente no documento, em vez de considerar exclusivamente o terminal do usuário logado.
Além disso, foi ajustado o processo de atualização das informações para que, sempre que houver alteração do terminal na Nota Fiscal, o sistema recarregue automaticamente as configurações e os estoques vinculados ao novo terminal selecionado. Dessa forma, todas as informações apresentadas passam a refletir corretamente os parâmetros definidos para o terminal escolhido na operação.
Com essa correção, o comportamento da Nota Fiscal torna-se mais consistente e aderente às regras de negócio, garantindo que os estoques e demais configurações sejam carregados de acordo com o terminal efetivamente utilizado no documento, independentemente do terminal associado ao usuário que está realizando a operação.
(OS 51117)- Durante a análise da solicitação, foi identificada uma necessidade de aprimoramento no processo de consulta das NFC-e emitidas em contingência.
Anteriormente, quando uma NFC-e era transmitida em modo de contingência e posteriormente autorizada pela SEFAZ, o sistema mantinha armazenado apenas o XML gerado durante a emissão em contingência. Dessa forma, mesmo após a autorização definitiva do documento fiscal, o XML não era atualizado automaticamente para a versão oficial autorizada pela SEFAZ, o que poderia ocasionar divergências entre o documento armazenado no sistema e o documento efetivamente autorizado pelo órgão fiscal.
Para solucionar essa situação, foi implementada uma nova funcionalidade na rotina Consultar Chave de Contingência.
A partir desta atualização, ao acessar essa opção, o sistema apresenta um novo formulário que permite realizar a consulta de duas maneiras:
Consultar apenas a Nota Fiscal atualmente selecionada;
Consultar todas as NFC-e de um período informado pelo usuário.
Durante a execução da consulta, o sistema verifica junto à SEFAZ a situação das NFC-e emitidas em contingência. Caso seja identificado que a nota já foi autorizada, o sistema realiza automaticamente a atualização do XML armazenado, substituindo o XML de contingência pelo XML oficial autorizado pela SEFAZ.
Com essa implementação, os documentos fiscais passam a permanecer sincronizados com as informações oficiais disponibilizadas pela SEFAZ, garantindo maior integridade dos arquivos XML, maior segurança nas consultas futuras e conformidade das informações fiscais armazenadas no sistema.
Essa melhoria também proporciona mais praticidade ao usuário, eliminando a necessidade de atualizações manuais dos XMLs e permitindo que a regularização das NFC-e autorizadas após a contingência seja realizada de forma simples e centralizada pela própria rotina de consulta.
