2.34.00 ________________________
(51805) Foi desenvolvido um novo relatório para listagem das contas a receber e das contas a pagar, permitindo que as duas informações sejam apresentadas de forma integrada em um mesmo relatório. Com essa alteração, o usuário terá uma visão mais completa das movimentações financeiras, facilitando a consulta e o acompanhamento dos valores a receber e das obrigações a pagar.
Para a implementação, foram realizados ajustes nas queries utilizadas pelo relatório, além de alterações na classe responsável pelo processamento das informações. Também foram aplicadas melhorias de otimização, buscando tornar a geração do relatório mais eficiente e reduzir o tempo de processamento, principalmente durante consultas com maior volume de dados.
Além disso, foi realizada a integração desta funcionalidade com a feature relacionada à Reforma Tributária, garantindo que as alterações desenvolvidas estejam alinhadas às demais atualizações do sistema e possam trabalhar de forma integrada.
No momento, a implementação encontra-se concluída e aguardando os testes e a validação do setor de Qualidade. Após a realização dos testes, caso não sejam identificadas inconsistências, a funcionalidade poderá seguir para as próximas etapas de disponibilização.
(52145) Foi realizada a análise da solicitação encaminhada por Jean, que será avaliada pela área de engenharia para definição da melhor forma de desenvolvimento. As alterações contemplam melhorias tanto no Tipo de Serviço de Contrato quanto no Layout de Importação de NFS-e.
Foi incluído o novo campo Número da Obra na aba Outras Informações da Nota Fiscal de Serviço de saída, localizado ao lado do campo Número Lote. Esse campo aceita até 30 caracteres, podendo conter letras e números (exemplo: OBRA-001 ou OB 2026/15), e seu preenchimento é opcional.
Além disso, o layout de importação de NFS-e passou a aceitar três novas colunas opcionais: Número da Obra, Mão de Obra e Equipamento. Caso não sejam preenchidas, o sistema mantém o cálculo automático pelo percentual cadastrado no Tipo de Serviço. Se preenchidas manualmente, passam a substituir o cálculo automático. Importante destacar que, ao informar apenas um dos dois valores (Mão de Obra ou Equipamento), o sistema ajusta automaticamente o outro para que a soma corresponda ao valor da nota. Como esses valores impactam diretamente o cálculo de impostos (INSS e ISSQN), o preenchimento manual deve ser utilizado apenas quando necessário.
Por fim, no cadastro de Tipo de Serviço de Contrato foi incluído o novo botão de fórmula Número da Obra, que permite que essa informação seja exibida automaticamente na descrição da nota fiscal, da mesma forma que já ocorre com Código do Pedido, Conformidade e Município.
Essas melhorias foram desenvolvidas para oferecer maior controle e flexibilidade no preenchimento das informações.
(51835) Foi registrada e implementada a sugestão de melhoria apresentada por Felipe referente à nota fiscal de saída. A necessidade identificada foi a inclusão de um novo campo denominado Faturada dentro do CFG da NF de Saída.
Esse campo foi acrescentado com o objetivo de simplificar a conferência das informações fiscais, permitindo que o usuário tenha uma visualização mais clara e direta sobre o status de faturamento da nota. A melhoria também contribui para otimizar o tempo de execução dos comandos SQL no banco de dados, já que a busca e conferência passam a ser realizadas de forma mais eficiente e organizada.
Com essa alteração, o sistema passa a oferecer maior praticidade e confiabilidade no processo de conferência das notas fiscais de saída, reduzindo retrabalho e garantindo que os dados estejam sempre acessíveis de maneira ágil.
(51849) Conforme definido na OS, foi realizada a melhoria no relatório de extrato de cliente. A alteração consistiu em adicionar o campo Valor Total ao relatório, permitindo que os valores sejam exibidos de forma consolidada.
Além disso, foi implementada a funcionalidade de totalização no final do relatório, garantindo que o somatório dos valores seja apresentado automaticamente ao término da listagem. Essa melhoria facilita a conferência e análise dos dados, oferecendo maior clareza e precisão nas informações financeiras apresentadas.
Projeto 001273 - Gestão Atlanta Sistemas ( Adequações no GSA)
Foi realizada uma análise e implementação de adequações no GSA – Gestão de Serviços da Atlanta Sistemas, com o objetivo de aprimorar o acompanhamento das Ordens de Serviço (OS), projetos, horas trabalhadas, custos e andamento das atividades.
Entre as principais melhorias realizadas, destacam-se:
Aprimoramento do acompanhamento das Ordens de Serviço, permitindo registrar o tempo de permanência de cada OS nos setores pelos quais ela passa e identificar situações em que o prazo de permanência foi ultrapassado.
Inclusão de informações de projeto nas Ordens de Serviço, possibilitando relacionar a OS ao projeto, requisito e previsão de entrega.
Controle de custos das execuções, considerando o custo da hora do funcionário e a quantidade de horas trabalhadas, permitindo obter o custo total de cada execução.
Inclusão de informações de software, módulo e interface durante a execução das OS, facilitando a identificação do local relacionado ao atendimento.
Melhoria das regras de encerramento das OS, impedindo a conclusão quando não houver serviço ou execução registrada, bem como quando existir uma execução ainda em andamento.
Criação de recursos para acompanhamento de projetos, permitindo visualizar informações como contrato, projeto, cliente, previsão, última ação, dias de atraso, percentual de conclusão e horas previstas e realizadas.
Criação de painel para gestão das horas dos funcionários, possibilitando consultar as horas realizadas e os respectivos custos por período e setor, além de apresentar informações de forma gráfica para facilitar a análise.
Aprimoramento do Kanban, permitindo identificar e filtrar as Ordens de Serviço que estão acima do limite de permanência definido para cada setor.
Criação do Painel de Gestão de Serviços, reunindo informações das OS em andamento, atrasos, distribuição por setor, cliente e status.
Aprimoramento do acompanhamento dos projetos em execução, permitindo consultar as etapas, períodos, quantidade prevista e realizada, atrasos, percentual de conclusão e registros das execuções realizadas.
Controle de acesso às informações financeiras, garantindo que dados como valores negociados e custos dos projetos sejam apresentados somente aos usuários que possuírem a devida permissão.
Disponibilização dos recursos também no ATL-Gestor, seguindo os mesmos conceitos de gestão de horas e acompanhamento de serviços implementados no ambiente WEB.
Foram realizados ainda ajustes e correções no cálculo do horário de encerramento das execuções e na busca de configurações das Ordens de Serviço.
Documentação do projeto 001273:
Projeto 001273 - Gestão Atlanta Sistemas.docx
2.34.01 ________________________
(52065)Foi desenvolvida uma melhoria no processo de cancelamento de notas fiscais, trazendo maior flexibilidade e controle para os usuários.
Foi criado um formulário de seleção entre as opções Cancelamento Prefeitura e Cancelamento Parcial, exibido apenas quando a configuração correspondente está ativa. O fluxo de cancelamento já existente foi mantido sem alterações para a opção Prefeitura, garantindo que o processo tradicional continue funcionando normalmente.
A novidade está na implementação da rotina de cancelamento parcial, que executa todos os efeitos já previstos no sistema crédito ao cliente, quitação de contas a receber, estorno de impostos e rateio contábil porém sem emitir o cancelamento à prefeitura. Nesse caso, a nota passa a receber o novo status “Cancelamento Parcial”.
Também foi criada uma rotina específica para regularizar notas já parcialmente canceladas: quando essas notas forem canceladas novamente, o sistema não reexecutará os efeitos financeiros, apenas emitirá o cancelamento à prefeitura e atualizará o status para “Cancelada”. A rotina de consulta de status recebeu o mesmo tratamento, evitando duplicidade de lançamentos.
Além disso, foram ajustados os controles de tela (botões e exibição de status) para contemplar o novo status, e preparados os pontos de impressão e geração de PDF da NFS-e para suportar um layout específico, que será desenvolvido em etapa posterior.
Durante os testes, foram corrigidas duas inconsistências identificadas nos relatórios: uma falha de tradução de status em view de banco de dados e uma filtragem que impedia que notas parcialmente canceladas fossem localizadas na exportação de PDF em lote. Por fim, foi incluída a opção de filtro para notas parcialmente canceladas nos dois relatórios de NFS-e do sistema.
2.34.03 ________________________
(51647) Foi analisado o processo de inclusão de créditos na conta corrente do cliente. Atualmente, o sistema permite que seja registrado um crédito indicando que o cliente deixou um valor disponível para futura quitação de débitos. No entanto, esse crédito não exige obrigatoriamente o registro em uma conta bancária do sistema, o que abre margem para possíveis inconsistências ou fraudes.
Diante disso, foram definidos pontos de atenção e ajustes necessários. O mesmo cenário será aplicado também para casos de pagamento antecipado a fornecedores, onde igualmente será obrigatório o registro da movimentação na conta correspondente.
No caso específico de crédito de cliente, deve-se observar que o valor do crédito precisa aparecer como recebimento no fechamento de caixa da conta em que o crédito foi incluído, sempre que se tratar de uma conta do tipo caixa. Essa medida garante maior transparência e segurança, evitando brechas e assegurando que todas as movimentações financeiras fiquem devidamente registradas e conciliadas.
Com isso, o sistema passa a oferecer maior controle e confiabilidade tanto nos registros de créditos de clientes quanto nos pagamentos antecipados a fornecedores, fortalecendo a integridade das informações financeiras.
(51802) Foi analisado o comportamento do sistema em relação às operações de análise de giro e às funcionalidades de transferência e cálculo de quantidade de compra.
Identificou-se que, ao entrar em uma análise de giro já gravada ou durante a inclusão de uma nova, quando o usuário adiciona uma transferência pelo botão da coluna correspondente e salva, a quantidade transferida não é atualizada imediatamente na coluna. Para que o valor seja refletido corretamente, é necessário gravar a análise de giro e depois reabrir para edição, momento em que a quantidade a transferir passa a ser exibida. Esse ajuste foi mapeado para garantir maior consistência e usabilidade no processo.
Outro ponto importante é que a quantidade a comprar não deve ser calculada automaticamente pelo sistema. A decisão foi de manter esse campo em branco, permitindo que o valor seja inserido exclusivamente pelo usuário. Dessa forma, evita-se que o sistema sugira ou imponha cálculos que possam não refletir a realidade operacional, dando maior autonomia e precisão ao preenchimento manual.
Essas melhorias foram implementadas com o objetivo de assegurar maior controle, transparência e confiabilidade nas operações de análise de giro, reduzindo retrabalho e garantindo que os dados registrados correspondam fielmente às necessidades do usuário.
(51819) Foi realizado um teste na base de dados localizada no servidor Oracle da Atlanta. O teste consistiu na importação da nota de saída para a empresa , utilizando o DAV do Pedido. Esse documento contém 63 linhas e já possuía a configuração do grupo fiscal dos produtos devidamente ajustada.
A importação foi concluída em 1 minuto e 2 segundos, tempo considerado elevado para esse volume de dados. Ressalta-se que, no servidor do cliente, o processamento tende a ser ainda mais lento, o que reforça a necessidade de otimização.
Após a primeira homologação, verificou-se que não houve ganho de velocidade suficiente. Por esse motivo, o processo foi encaminhado novamente para a área de engenharia, que irá investigar se é possível melhorar ainda mais o desempenho da importação.
No início da revisão, o tempo registrado para a importação foi de 1 minuto e 8 segundos (01:08:83), demonstrando que ainda há espaço para ajustes e melhorias.
Com isso, o objetivo é garantir maior eficiência e rapidez no processamento de documentos, reduzindo o tempo de espera e aumentando a produtividade do sistema.
(51982) Foi analisada a situação relatada em relação ao processo de ativação automática de cliente após o retorno de boleto. Conforme observado, as resoluções anteriores ainda não surtiram o efeito esperado: o sistema realiza a ativação do cliente, mas logo em seguida essa informação se perde, não permanecendo registrada como deveria.
Essa inconsistência foi confirmada por meio da análise dos logs do sistema, onde é possível verificar que o processo de ativação ocorre corretamente em um primeiro momento, mas não se mantém ativo posteriormente.
Diante disso, foram iniciadas novas verificações para identificar a causa raiz do problema e avaliar ajustes adicionais necessários para garantir que a ativação automática funcione de forma estável e definitiva.
O objetivo é assegurar que, sempre que houver retorno de boleto, o cliente seja ativado corretamente e essa informação permaneça válida no sistema, eliminando falhas e garantindo maior confiabilidade no processo.
(51795) Foi realizada uma avaliação detalhada no sistema em relação às consultas que envolvem notas fiscais (NF) e NFC-e. Identificou-se que algumas queries de busca, especialmente aquelas que utilizam o operador contiver em colunas como número ou outras informações, estão causando lentidão significativa, variando entre 1 e 2 minutos. Esse tempo de resposta elevado gera travamento das tabelas e impacta diretamente o funcionamento dos caixas.
Constatou-se que filtros aplicados para agrupar CFOP, período de data, nome de cliente ou mesmo número/código (quando utilizado o contiver) também resultam em lentidão. Além disso, os CFGs que são abertos para buscar NF ou NFC-e durante a importação em documentos fiscais sofrem com o mesmo problema.
Para resolver essa situação, foi definido que será necessário adotar uma nova forma de filtro no CFG, impedindo que o usuário utilize comandos SQL que causem lentidão. O plano de ação estabelecido é o seguinte:
Criar uma configuração geral com a descrição “Aplicar pré-filtro em busca de produto”.
Com essa configuração, ao acionar a busca no CFG, a opção de contiver não estará mais disponível.
Ao acionar o filtro, o sistema deverá carregar interfaces específicas para cada formulário, onde o filtro será pré-estabelecido e aplicado ao CFG através das chaves, gerando um filtro avançado. Esse ponto será discutido em conjunto com Valdécio para definição da melhor implementação.
Inicialmente, esse recurso será aplicado nos seguintes documentos: Nota Fiscal de Entrada, Nota Fiscal de Saída, Nota Fiscal de Devolução de Cliente, Nota Fiscal de Devolução de Fornecedor e NFC-e.
Com essas medidas, o objetivo é eliminar os gargalos de desempenho, reduzir o tempo de resposta das consultas e garantir maior estabilidade e eficiência no uso do sistema, especialmente nos processos que envolvem movimentação de notas fiscais e operações de caixa.
(51774) Foi registrada a sugestão de melhoria apresentada por Felipe referente à tela de importação de documento fiscal dentro de NF (seja de saída, entrada ou outras), incluindo NF-e e NFC-e.
A necessidade identificada é que, ao acessar essa tela, o CFG seja exibido ordenado de forma decrescente, garantindo que os registros mais recentes apareçam primeiro. Além disso, quando o usuário alterar a opção de busca para Número do Documento, essa configuração deve permanecer fixa, mantendo a mesma forma de busca em todas as consultas subsequentes.
Essa melhoria tem como objetivo otimizar o tempo de execução dos comandos SQL no banco de dados, reduzindo a sobrecarga e evitando lentidão nas operações de importação de documentos fiscais. Com a ordenação decrescente e a padronização da busca por número do documento, o sistema passa a oferecer maior eficiência, praticidade e confiabilidade no processo de importação.
(51975) Foi identificado um erro na nota fiscal de saída modelo novo. O problema ocorre porque a subNF está gravando o valor “-00” no campo de código de enquadramento legal, o que acaba gerando inconsistências e erros na geração do SPED.
Na análise comparativa, verificou-se que no modelo antigo de NF o sistema grava esse campo como vazio, não ocasionando falhas. Além disso, foi constatado que no grupo fiscal vinculado ao produto o campo também está vazio, o que reforça que o comportamento incorreto está restrito ao modelo novo de nota fiscal.
Foram coletados prints em anexo para evidenciar o problema e apoiar a investigação. A correção será direcionada para que o sistema mantenha o mesmo padrão do modelo antigo, evitando gravações indevidas e garantindo que o SPED seja gerado corretamente, sem erros de enquadramento legal.
2.34.04 ________________________
(52448) Foi realizado um ajuste no processo de inclusão de clientes e fornecedores. Durante os testes, verificou-se que, quando a configuração geral para validar CPF/CNPJ ao iniciar o cadastro está marcada, é necessário que o sistema identifique corretamente se o cadastro corresponde a pessoa física ou jurídica.
O atendimento consistiu em revisar esse comportamento e aplicar a correção para que, ao iniciar o cadastro, seja feita a seleção adequada entre pessoa física ou jurídica. Dessa forma, o sistema passa a validar o CPF ou CNPJ de acordo com o tipo escolhido, evitando inconsistências e garantindo maior confiabilidade nas informações registradas.
Esse ajuste assegura que o processo de inclusão de clientes e fornecedores esteja alinhado com as regras de validação tributária e cadastral, proporcionando maior precisão e segurança nos dados.
2.34.06 ________________________
(52424) Foi realizada uma análise detalhada para identificar a causa do encerramento inesperado da sessão durante a utilização do sistema. Inicialmente, foram executados diversos testes e identificado um possível fator que poderia estar ocasionando o problema. No entanto, mesmo após a realização desse primeiro ajuste, o comportamento persistiu, sendo necessário aprofundar a investigação.
Ao longo das análises, foram reproduzidos diferentes cenários até que o problema fosse isolado em um fluxo específico, relacionado à importação de XML e à entrada da Nota Fiscal com geração da precificação. Durante esse atendimento, também foi prestado suporte ao colaborador Anderson, que enfrentava dificuldades na transmissão de um documento fiscal de entrada.
Com a continuidade dos testes, foi identificado que a origem do erro estava na execução da Class_Initialize, que estava interrompendo o SetComponentes, ocasionando o fechamento da sessão do usuário após a geração da Nota Fiscal.
Após a identificação da causa raiz, foi realizada a correção necessária para tratar esse comportamento. Com o ajuste implementado, o processo de importação do XML e geração da Nota Fiscal passou a ser executado normalmente, sem que a sessão do usuário fosse encerrada de forma inesperada.
(52431) Durante o atendimento, foram realizados esclarecimentos e ajustes relacionados à configuração e ao preenchimento dos campos da Reforma Tributária de IBS e CBS nas Notas Fiscais de Entrada.
Inicialmente, foi repassado ao cliente o procedimento para realizar o cadastro do Grupo Fiscal de IBS e CBS, utilizando como apoio os vídeos disponibilizados, com o objetivo de orientar corretamente a configuração necessária no sistema.
Também foi realizado o envio da Nota Fiscal para validação do cenário apresentado. Foi identificado que, ao emitir uma NF de Entrada com transmissão própria, os campos referentes à redução de IBS/CBS permaneciam zerados, ocasionando erro durante a transmissão.
Na análise do processo, foi identificado que, quando o colaborador utilizava a opção “Produto complementar” na guia de produtos da NF, o produto era gravado na tabela SUBNF com o código do produto igual a 0. Dessa forma, o sistema não conseguia localizar a tributação correspondente de IBS/CBS para esse item, fazendo com que os campos da Reforma Tributária não fossem preenchidos corretamente.
Para solucionar o problema, foi realizada uma tratativa no processo da NF de Entrada com transmissão própria. A partir do ajuste, quando o produto estiver nesse cenário de “Produto complementar”, o sistema passará a considerar e buscar a tributação padrão de IBS/CBS, permitindo que os campos relacionados à Reforma Tributária sejam preenchidos corretamente.
Dessa forma, o atendimento contemplou tanto a orientação ao cliente quanto o ajuste necessário no sistema para corrigir a identificação da tributação de IBS/CBS nas NF de Entrada, evitando que os campos permaneçam zerados e ocasionem erros na transmissão da nota.
(52467) Foi realizado o ajuste no sistema de orçamento do Zeus, adequando o funcionamento para o cenário da Atlanta e realizando as correções necessárias no fluxo de utilização. Durante o atendimento, foi dado andamento às correções identificadas, com o objetivo de garantir que o processo de orçamento ocorra de forma mais adequada e alinhada às necessidades apresentadas.
Também foi criada uma nova notificação para os casos em que um orçamento é aprovado, porém ainda não possui um projeto indicado ou vinculado. Essa notificação tem como finalidade alertar os responsáveis sobre a situação, permitindo que a pendência seja identificada e tratada de forma mais rápida, evitando que um orçamento aprovado permaneça sem o devido direcionamento para um projeto.
Dessa forma, o atendimento envolveu a criação da OS, os ajustes no sistema de orçamento do Zeus para atender à Atlanta e aos serviços administrativos, o andamento das correções necessárias e a implementação da notificação para identificar orçamentos aprovados que ainda não possuem um projeto indicado.
(52493) Durante o atendimento, foi realizada uma análise detalhada para identificar a causa de um faturamento que aparentava estar sendo gerado em duplicidade. Para isso, foram avaliados os logs e os registros diretamente na base de dados.
Após a análise, foi identificado que os faturamentos haviam sido gerados em períodos distintos, indicando que não se tratava de uma duplicação realizada pelo sistema no mesmo momento. O cenário identificado ocorreu porque o primeiro faturamento foi processado corretamente, porém, possivelmente devido a uma queda de conexão ou alguma interrupção durante o processo, o documento não teve o campo “Faturada” alterado para “Sim”.
Como o documento permaneceu registrado como não faturado, ele voltou a ser apresentado ao usuário como disponível para faturamento. Dessa forma, o usuário, sem visualizar a informação de que o faturamento já havia sido processado, realizou novamente a operação, ocasionando a geração de um segundo faturamento.
Para evitar que esse cenário volte a ocorrer, foi realizada uma tratativa no processo de faturamento. Antes de permitir um novo faturamento, o sistema passará a verificar se o documento já possui faturamento registrado. Caso seja identificado que o faturamento já foi realizado, o sistema impedirá uma nova geração, evitando possíveis duplicidades.
Também foi realizado um ajuste específico para o cenário de faturamento de Nota Fiscal da série D. Caso ocorra uma queda de conexão durante o faturamento e algumas linhas sejam inseridas no processo, mas o campo “Faturada” permaneça como “Não” na base de dados, ao tentar alterar o documento e salvá-lo, o sistema apresentará uma mensagem ao usuário, alertando sobre a situação para evitar que o procedimento seja realizado novamente de forma indevida.
Além disso, durante o atendimento, foi prestado auxílio ao colaborador Cícero em relação ao processo de transmissão de documento MDF-e, dando o suporte necessário para a correta execução do procedimento.
Dessa forma, o atendimento contemplou a investigação da causa do faturamento aparentemente duplicado, a identificação da falha relacionada à atualização do status do documento, a implementação de uma validação preventiva contra novos faturamentos indevidos e o suporte ao processo de transmissão do MDF-e.
(52508) Durante o atendimento, foram realizadas as correções descritas na Ordem de Serviço, relacionadas ao cálculo do crédito de PIS e COFINS na precificação gerada a partir de uma Nota Fiscal de Entrada.
Foi ajustado o comportamento do sistema no Cadastro da Loja, na guia “Formação de custo e preço de venda”, onde foi criada a nova configuração “Gerar crédito de PIS e Cofins para produtos de mercadoria para revenda”.
Essa configuração permite definir, por loja, se o sistema deverá considerar ou não o crédito de PIS e COFINS na geração da precificação. Quando a opção estiver marcada como “Sim”, ao salvar uma Nota Fiscal de Entrada e gerar a respectiva precificação, o sistema irá somar as alíquotas de PIS e COFINS e utilizar esse valor no campo “Crédito de PIS e Cofins” da precificação.
Quando a configuração estiver marcada como “Não”, o sistema não deverá considerar esses créditos e o campo “Crédito de PIS e Cofins” permanecerá zerado na precificação.
Durante a validação, foi identificado e corrigido o comportamento em que, mesmo com a nova configuração definida como “Não”, o crédito de PIS/COFINS não estava sendo zerado corretamente na precificação. Após a correção, o sistema passou a respeitar a configuração definida no cadastro da loja.
Dessa forma, o processo de geração da precificação passa a considerar corretamente a configuração definida para cada loja, garantindo que o crédito de PIS e COFINS seja calculado ou desconsiderado conforme a opção selecionada.
Para a documentação da alteração, deverão ser incluídos prints das telas de configuração da loja e da precificação, demonstrando o comportamento do sistema conforme a opção selecionada.
(51762) Durante o atendimento, foi realizado contato telefônico com o cliente Junior , que relatou uma situação relacionada à conversão de um orçamento realizado pelo Mobile para um DAV de Venda.
Segundo o cliente, ao realizar um orçamento pelo Mobile com determinada quantidade de produtos e posteriormente convertê-lo em um DAV de Venda, o sistema não estava destacando quando o estoque disponível era insuficiente para atender à quantidade solicitada. Em versões anteriores do sistema, essa situação era sinalizada de forma mais evidente, com um aviso em destaque na cor vermelha, permitindo que o usuário identificasse rapidamente quais produtos não possuíam estoque suficiente.
Diante do cenário relatado, foi realizada uma análise e efetuado um ajuste no módulo de DAV para melhorar a identificação visual desses produtos. Quando o DAV possui como origem um orçamento do Mobile e a quantidade disponível em estoque for inferior à quantidade solicitada no orçamento, a linha do respectivo produto passa a ser apresentada em uma coloração laranja mais escura e destacada.
Esse ajuste tem como objetivo facilitar a visualização e chamar a atenção do usuário para os itens que possuem quantidade em estoque inferior à quantidade solicitada no orçamento, permitindo que a divergência seja identificada rapidamente durante a conferência do DAV.
Dessa forma, o processo de conversão do orçamento Mobile para o DAV de Venda passou a contar com um destaque visual específico para os produtos que apresentam insuficiência de estoque, tornando a informação mais clara e facilitando a tomada de decisão pelo usuário.
(51880, #004642, #S/N) Durante o atendimento, foi realizada a implementação dos campos de KM e Sulco no CFG (configuração) do menu de Transferência de Pneus, conforme solicitado.
Além da inclusão dos novos campos, foi realizado o ajuste na View responsável pela apresentação dessas informações, garantindo que os campos sejam exibidos corretamente no CFG e estejam disponíveis para utilização no processo de transferência de pneus.
Após a implementação e os ajustes realizados, o processo encontra-se em fase de testes, com o objetivo de validar o correto funcionamento dos novos campos e garantir que as informações de KM e Sulco sejam apresentadas e utilizadas adequadamente no sistema.
Dessa forma, a alteração contempla tanto a disponibilização dos campos no CFG quanto a adequação da apresentação das informações na tela de configuração da transferência de pneus.
(52446) Foi realizada uma análise referente ao comportamento das buscas em formulários. Durante a correção aplicada para padronizar o tipo de busca em formulários específicos, foi identificado que essa alteração acabou gerando conflito em outros formulários do sistema.
Para solucionar, foram feitos ajustes nas estruturas de alguns CFGs, de forma que o sistema agora grava a posição do tipo de busca utilizada mesmo após o fechamento da tela. Assim, quando o usuário realiza uma busca utilizando, por exemplo, o critério “contiver”, essa configuração permanece registrada e será mantida na próxima vez que o usuário abrir a busca, garantindo maior consistência e praticidade no uso.
O atendimento consistiu em identificar o impacto da correção anterior, ajustar as estruturas necessárias e validar que o comportamento esperado manter o tipo de busca selecionado está funcionando corretamente em todos os formulários.
(52328) Foi realizada uma análise sobre o comportamento do sistema durante a gravação de informações relacionadas ao CFOP e ao plano de pagamento. Durante os testes, foi identificado que o CFOP estava ocasionando erro de SQL no momento da gravação. Esse problema foi corrigido, garantindo que o processo seja concluído sem falhas e que os dados sejam registrados corretamente.
Além disso, foi ajustado o plano de pagamento para que o campo correspondente seja gravado de forma adequada no banco de dados. Com essa correção, as informações passam a ser armazenadas de maneira íntegra e consistente, evitando inconsistências futuras e assegurando maior confiabilidade nos registros.
O atendimento consistiu em identificar os pontos de falha, aplicar as correções necessárias e validar que tanto o CFOP quanto o plano de pagamento estão funcionando conforme esperado, proporcionando maior estabilidade e precisão ao sistema.
(51849) - Foi realizada uma melhoria no extrato de cliente, especificamente no botão de impressão. Foi criada uma nova opção de relatório chamada Apuração de Valores, disponível como última alternativa dentro do menu de impressão.
Esse relatório foi desenvolvido para apresentar de forma clara e objetiva os dados mais relevantes, facilitando a análise das informações financeiras. Nele são exibidos os seguintes valores principais: valor total, desconto aplicado, acréscimo e valor final.
Com essa implementação, o extrato de cliente passa a oferecer uma visão resumida e direta dos pontos mais importantes da movimentação, tornando a consulta mais prática e transparente. O atendimento consistiu em criar esse relatório adicional, validar sua funcionalidade e garantir que os valores apresentados estejam corretos e alinhados às necessidades de acompanhamento.
(51786) - Foi realizado um conjunto de testes para validar o comportamento do sistema em operações de transferência e emissão de notas fiscais. Durante os testes, foi feita uma transferência e, ao importar essa movimentação para uma nota fiscal, foi observado que o sistema gerou corretamente o registro de estoque no histórico do produto vinculado à NF-e.
Esse procedimento permitiu confirmar que o processo de integração entre a transferência e a nota fiscal está funcionando conforme esperado, garantindo que o estoque seja atualizado e registrado no histórico do produto de forma consistente.
O atendimento consistiu em executar os testes necessários, validar o resultado e assegurar que o estoque seja devidamente refletido no histórico do produto quando a operação é importada para a NF-e, proporcionando maior confiabilidade no controle das movimentações.
(51825) - Foi realizada uma análise no processo de lançamento de conhecimento de transporte de entrada. Durante os testes, foi identificado que, ao efetuar o faturamento, ocorria um erro de SQL na gravação das informações.
Para corrigir esse comportamento, foram aplicados ajustes específicos no procedimento de lançamento, garantindo que o faturamento seja concluído sem falhas e que os dados sejam gravados corretamente no banco de dados.
O atendimento consistiu em identificar o ponto de falha, aplicar a correção necessária e validar o funcionamento após os ajustes. Com isso, o sistema passa a registrar o conhecimento de transporte de entrada de forma estável e confiável, evitando erros de SQL e assegurando maior integridade nas operações.
(52433)- Foi identificado um problema durante a realização de vendas via TEF utilizando dois cartões, no qual o sistema apresentava um erro de execução (Run-time) e, em algumas situações, ocorria um travamento da operação quando o cliente digitava a senha incorretamente ou quando o cartão não possuía saldo/limite suficiente.
Para solucionar a situação, foram realizados ajustes no processo de pagamento, especialmente no fluxo de vendas realizadas com dois cartões. O tratamento foi aprimorado para evitar que o sistema apresentasse o erro de Run-time durante o processamento da segunda forma de pagamento.
Com a correção, o processo de venda via TEF passa a ter um comportamento mais estável, permitindo o processamento de pagamentos com dois cartões sem a ocorrência do Run-time, inclusive proporcionando um tratamento mais adequado para situações de senha incorreta ou insuficiência de saldo/limite, evitando o travamento do sistema.
(52130) Realizamos uma análise completa no código-fonte e implementamos melhorias significativas no módulo financeiro de devoluções, atendendo tanto às necessidades operacionais de devolução de fornecedores quanto aos ajustes validados pelo setor de qualidade.
Anteriormente, o sistema permitia devolução em dinheiro apenas para operações de clientes, enquanto a devolução de fornecedor ficava restrita à geração de crédito. Com o novo desenvolvimento, o fluxo foi totalmente reestruturado e ampliado:
Três formas de devolução na mesma tela A tela de faturamento da devolução agora aceita três modalidades: Crédito em conta corrente, Dinheiro e PIX. Elas podem ser utilizadas simultaneamente no mesmo faturamento (por exemplo, recebendo uma parte via PIX e registrando o restante como crédito). O sistema valida a soma exata das formas de pagamento com o total do documento, bloqueando o salvamento caso haja divergência. Vale ressaltar que a opção de PIX é exclusiva para devoluções de fornecedor, mantendo-se para devoluções de cliente as opções de crédito e dinheiro.
Contas bancárias distintas para Dinheiro e PIX Para evitar lançamentos em contas incorretas quando ambas as modalidades forem combinadas, a tela passa a contar com campos específicos: um campo para Conta Dinheiro (listando as contas bancárias gerais) e outro para Conta Pix (filtrando apenas as contas devidamente habilitadas para recebimento via PIX).
Sentido correto dos lançamentos financeiros O fluxo financeiro foi parametrizado para registrar a operação no sentido adequado de cada cenário: enquanto na devolução de cliente o valor sai da empresa para o cliente, na devolução de fornecedor o recurso entra na conta da empresa, refletindo de imediato e de forma correta no saldo bancário.
Visualização completa na grade de parcelas Na devolução de fornecedor, os registros de dinheiro e PIX agora passam a ser exibidos na visualização de parcelas do faturamento, trazendo total paridade com o que já ocorria na devolução de clientes.
Estorno integral em caso de exclusão Ao excluir um faturamento de devolução de fornecedor, o sistema agora desfaz automaticamente as movimentações bancárias e restaura os saldos das contas envolvidas (dinheiro e/ou PIX), eliminando a necessidade de conciliações manuais.
Novo campo Valor Restante para conferência em tempo real Adicionamos o campo Valor Restante ao lado do valor total da nota. Ele calcula dinamicamente quanto ainda falta preencher à medida que as quantias são digitadas, ficando negativo caso o total ultrapasse o montante da devolução, garantindo mais agilidade e precisão ao operador.
Validação de campos obrigatórios Para assegurar a integridade fiscal e contábil, foram corrigidas brechas que permitiam gravações parciais. Passa a ser obrigatório o preenchimento de Plano, Sub-Plano, Forma de Pagamento, Empresa/Setor e Conta sempre que houver valor informado. A Conta Pix passa a ser exigida obrigatoriamente quando houver uso do PIX. Ressaltamos que a obrigatoriedade de Plano e Sub-Plano passa a vigorar também para devoluções de cliente, sendo recomendada a conferência desse fluxo pelas equipes operacionais durante o período de homologação.
Todos os apontamentos levantados pela equipe de qualidade foram devidamente corrigidos e os testes foram concluídos com sucesso.
