Ir para o final dos metadados
Ir para o início dos metadados

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 25 Próxima »

Data de publicação: 24/10/23

📗 Melhorias

[Agent]

 Clique para expandir/recolher

📗 2️⃣ Criptografia do novo campo de senha de usuários novos (Melhoria interna)

O campo "USU_SENHA_10" a ser utilizado no “Delphi 10”, foi inserido nos componentes da tela de usuários, assim, sempre que uma senha for alterada ou um novo usuário for criado, o campo será preenchido. Nos usuários novos desde a versão que o campo foi criado até hoje, o campo será atualizado via script (Imagem 1).

[Menu Financeiro - Receber]

 Clique para expandir/recolher

📗 2️⃣ Saldo Maior no fechamento de ordens (Melhoria interna)

Na tela “5.2.10 - Fechamento de ordens”, foi efetuada a correção em relação a criação de um título de adiantamento, quando existia apenas uma parcela paga. Sendo assim, só será gerado o título que estiver pago em sua totalidade, pois títulos que não foram pagos totalmente não deverão permitir gerar um título de adiantamento, mesmo quando o parâmetro “FN_CONTROLEEXCEDENTE” estiver configurado para “ADIANTAMENTO FINANCEIRO” (Imagens 1 e 2).

📗 2️⃣ Ajustes nas datas da baixa financeira (Melhoria interna)

Na tela “5.2.22 - Recebimento de contas” em “Baixa Financeira”, foi incluído o campo “Dt Emissão”, afim de melhorar a visualização dos resultados. Como padrão, este campo não será visível (Imagem 1).

Agora, será possível retroagir a data de lançamento “RCP_DIGITACAO” somente até a data de emissão do título “REC_EMISSAO” mais recente entre os títulos selecionados. Isso evita lançamentos com datas anteriores as emissões dos títulos (Imagem 2).

Foi feito um ajuste para utilizar a data do servidor substituindo a data local do cliente no caso de depósitos não identificados, garantindo consistência. O saldo também reflete esta mudança.

No caso de pagamento com cheque, quando o cheque for "Bom Para", a data de lançamento “RCP_DIGITACAO” não poderá ser posterior a data de vencimento “RCP_VENCIMENTO” do título. Foi Implementado um aviso para garantir a ciência disso ao registrar estes pagamentos (Imagens 3 e 4).

📗 3️⃣ Nota fiscal de devolução cancelada (SUP-83507)

Na tela “5.2.10 - Fechamento de ordens”, foram criados campos para armazenar o número da nota de devolução, que foi gerada ao incluir uma nova ocorrência do tipo devolução. Foi adicionado o campo “Nº Nota Devolução” na grade para consulta (Imagem 1).

Com esta informação salva, se for necessário cancelar a nota fiscal que está vinculada, o campo “Nota Devolução Cancelada” será atualizado para “SIM” (Imagem 2).

O campo “Nota Devolução Cancelada”, foi disponibilizado para demonstrar que a partir deste momento será possível estornar a ocorrência. Portanto com este processo, apenas permitirá estornar uma ocorrência como as outras. Onde irá excluir a ocorrência desta grade, atualizar o valor das devoluções na grade e ao clicar em confirmar, atualizar/ajustar o financeiro (Imagem 3).

Somente será permitido este processo de estornar a ocorrência de devolução cancelada, para ocorrências novas incluídas a partir desta data de liberação.
Este estorno da ocorrência, não movimentará o estoque, pois o mesmo já foi movimentado ao cancelar a nota fiscal.

📗 2️⃣ Permitir escolha de praça para utilização do "Vlr. Entrada" na digitação de ordens (SUP-75406)

Na tela “Parâmetros :: Guarani”, foi feito um ajuste para que quando o parâmetro “Lançar cobrança antes do faturamento para ordens antecipadas?” estiver optado como “NÃO”, o valor de entrada será passado entre praça 1 e praça 3. Antes, quando era feito um pedido com “Finalidade 2” e com valor de entrada, o sistema não distribuía o valor de entrada para a parte praça 3.

Parâmetro “Lançar cobrança antes do faturamento para ordens antecipadas?” optado como “NÃO” (Imagem 1).

Pedido com “Fidelidade 2” para 30 e 60 dias mais o valor de entrada (Imagem 2).

Foi lançado o valor de entrada dividindo entre a praça 1 e praça 3 (Imagem 3).

[Menu Manifestação do Destinatário]

 Clique para expandir/recolher

📗 2️⃣ Exibir alguns campos na grade (SUP-88159)

Na tela “16.2.1 - Manifestação do Destinatário”, na aba “Item da NFe”, foram adicionados os campos “EAN Tributável” e “Origem” do XML na grade (Imagem 1).


📘 Solicitações

[PDV]

 Clique para expandir/recolher

📘 2️⃣ Ajustes no PDV-ERP (SUP-95199)

Ocorrência 1: Estavam utilizando o F8, para importar as comandas, gerando no fim um P3, por não utilizar o SAT. Pois a função correta , é CTRL+F8.

Ocorrência 2: Na função das comandas, as operadoras estavam importando as comandas e logo após terminar a importação, estavam pressionando a função ESC e assim, ficando com o campo GRA_PEDIDO_IMPORTADO_PDV = 'S', desta forma, após isso não era mais possível importar o pedido, ficando perdido.

Ocorrência 3: As comandas estavam desaparecendo, no momento de serem importadas, quando duplicada e gerada comanda, desta forma, não era possível importar no PDV.

Solução 1: O comportamento está correto no sistema. 

Solução 2: Foi inserida uma mensagem durante a importação de comanda, para que quando o usuário operador do caixa teclar ESC no momento da importação da comanda, será exibida a seguinte mensagem: "Pré-venda/Comanda aberta. Deseja abandonar digitação?", sendo assim, se o usuário não abandonar a digitação, a venda continuará na tela. Caso abandone a digitação, a tela será liberada para o início de uma nova venda e a comanda continuará aberta, para ser importada em um outro momento.

Solução 3: Foi feito um ajuste na variável da duplicação de ordens, que mantém o mesmo número do pedido original, a ordem duplicada só deverá ter o mesmo número da ordem original se o tipo de ordem, for bonificação (Imagem 1).

Local>Tela PDV

[Menu Comuns]

 Clique para expandir/recolher

📘 1️⃣ Ordem não aparecendo as etapas em “Rastreamento de ordens” (SUP-94179)

Ocorrência: O sistema estava bloqueando inclusão/exclusão de tipos de ordens e origens na tela “Cadastro de etapas das ordens”. Não estava sendo permitida a inclusão de tipo de ordem.

Solução: Foi liberada apenas a edição dos tipos de ordens e das origens, na tela “Cadastro de etapas das ordens”, para a etapa padrão já estipulada pelo sistema (Imagem 1).

Para etapa padrão já estipulada pelo sistema, o botão “Itens” ficará bloqueado (Imagem 2).

Já para novas etapas cadastradas, estará liberado (Imagem 3).

Local>Tela 1.1.6 - Cadastro de etapas das ordens

📘 1️⃣ Inconsistência na busca por cidades (SUP-94989)

Ocorrência: Estava ocorrendo uma inconsistência ao consultar CEP por UF, Localidade e Logradouro, isso ocorria com qualquer CEP, pois o site “viacep.com.br” não aceitava os espaços entre as palavras.

Solução: Ao clicar na lupa para pesquisar CEP, o sistema enviará UF, Localidade e Logradouro para busca no “viacep.com.br” e foi colocado um comando para substituir os espaços por %20 (Imagem 1).

Local>Tela 1.1.3 - Cadastro de clientes

Local>Tela Busca de CEP por endereço

[Menu Comercial - Compras]

 Clique para expandir/recolher

📘 3️⃣ Quantidade em unidade informada no item, ultrapassando a quantidade do item na nota referenciada (SUP-95128)

Ocorrência: A restrição da quantidade em unidade informada no item, estava ultrapassando a quantidade do item na nota referenciada.

Solução: foi feito um ajuste e quando uma nota de reentrada for gerada a partir da exclusão da "Digitação de ordens" e a mesma nota de reentrada é inserida por meio da tela "Cadastro de notas fiscais", o sistema não aplicará nenhuma restrição, desde que a quantidade de cada produto na nota de reentrada seja igual à quantidade de cada produto na "Digitação de ordens" que estará sendo referenciada na nota de reentrada.

Nota de reentrada (Imagem 1).

Local>Tela 4.1.1 - Cadastro de notas fiscais

📘 1️⃣ Entrada de notas dando diferença quando importado o pedido e XML (SUP-94274/SUP-94649)

Ocorrência: Estava ocorrendo uma diferença entre o valor do pedido e do XML.

Solução: Foi realizado um ajuste no cálculo do campo “Valor Pedido” na tela “Entrada de notas fiscais”, para que sejam acumulados os valores no campo correto.

Entrada de notas fiscais com importação do XML na base do cliente, onde será possível verificar seu ajuste (Imagem 1).

Local>Tela 2.2.4 - Entrada de notas fiscais

📘 1️⃣ Inconsistência ao realizar pesquisa (SUP-957050)

Ocorrência: Estava ocorrendo uma inconsistência ao pesquisar a sugestão de carregamento na expedição, isso ocorria quando clicava na pesquisa por cliente.

Solução: Foi feito um ajuste no parâmetro referente ao filtro, para que seja filtrado por cliente devidamente (Imagem 1).

Local>Tela 4.2.6 - Expedição

[Menu Comercial - Vendas]

 Clique para expandir/recolher

📘 3️⃣ Desconto aplicado no item não acatou na porcentagem de comissão do representante (SUP-95121)

Ocorrência: Ao aplicar um desconto em um item que estava na tabela de preço, e o comissionamento desta tabela ter uma política de desconto, estava sendo ultrapassada a faixa de desconto da comissão do representante. O percentual de comissão do representante não estava sendo alterado no pedido.

Solução: Foi feita uma correção para que ao informar um desconto diretamente no item, se este desconto se aplicar na faixa de comissionamento, o percentual de desconto do representante será alterado normalmente.

Valor unitário do item na tabela de preço (Imagem 1).

Comissionamento que está unido a tabela de preço. Política de comissionamento relacionada ao desconto, onde a comissão do representante é de 9% e diminuirá para 4% ao aplicar 30,00 de desconto no item (Imagem 2).

Valor da comissão vendendo o item a valor de tabela, onde a comissão normal é de 9% (Imagem 3).

Pedido onde será aplicado o desconto no item. Com este ajuste, seguirá o acerto no percentual de comissão do representante (Imagem 4).

Após ter aplicado o desconto no item, o percentual de comissão foi alterado normalmente de 9% para 4% (Imagem 5).

Local>Tela 3.2.22 - Manutenção de tabelas de preços
Local>Tela 3.2.20 - Manutenção de comissionamento
Local>Tela 3.2.12 - Digitação de ordens

📘 1️⃣ Local de estoque incorreto (SUP-94819)

Ocorrência: Ao importar um pedido “praça 3” pela tela “Guarani móvel - Android - importação de dados” com configuração de seleção automática de estoque para dividir ordens por locais de estoque, o local de estoque estava apresentando inconsistências.

Solução: Foi realizado um ajuste no local de estoque do item ao importar pedido pela tela “Guarani móvel - Android - importação de dados” com configuração de seleção automática de estoque para dividir ordens por locais de estoque.

Importação do pedido (Imagens 1 e 2).

Local>Tela 3.5.7 - Guarani móvel - Android - importação de dados
Local>Tela 3.2.12 - Digitação de ordens

📘 2️⃣ Rejeição: Falha no Schema XML do lote de NFe (SUP-95091)


Ocorrência: Estava sendo apresentada uma rejeição de nota ao transmitir NF-e a SEFAZ, com a quantidade incorreta de casas decimais em relação a quantidade do lote e que possuísse lote rastreável.

Solução: Foi corrigida a quantidade de casas decimais referentes a quantidade de lote. A SEFAZ exige que a quantidade de casas decimais após a virgula seja de três casas, no que se refere a quantidade de lote.

Digitação de ordem com lote e sua respectiva quantidade (Imagem 1).

Emissão da nota fiscal em homologação, referente a ordem (Imagem 2).

Arquivo XML, exibindo que a etiqueta “qLote” possui a quantidade 0.300, ou seja, três casas decimais após a vírgula (Imagem 3).

Local>Tela 3.2.12 - Digitação de ordens
Local>Tela 4.2.5 - Emissão de notas fiscais eletrônicas (NF-e)
Local>Tela Arquivo XLM

📘 1️⃣ Inconsistência na pesquisa de clientes pela tela “Digitação de ordens” (SUP-95312)

Ocorrência: Estava sendo apresentada uma inconsistência na tela “Consulta de Clientes” ao realizar uma pesquisa sem nenhum filtro, que ocorria na busca pelos campos "Roteiro - Última Visita" e "Roteiro - Próxima Visita".

Solução: Os campos “Roteiro — Última Visita” e “Roteiro — Próxima Visita” somente entrarão no “SELECT” e serão preenchidos na grade quando algum representante for selecionado no filtro, seguindo o comportamento de todos os campos do grupo “Roteiro -”.

Sem representante (Imagem 1).

Com representante (Imagem 2).

Foi feita uma alteração visual para que os campos não fiquem desalinhados. O campo “Limite Disponível”, utilizado somente no “Telemarketing” antes ficava invisível na tela, foi alterado para que fique desabilitado.

Antes (Imagem 3).

Depois (Imagem 4).

Local>Tela 1.2.0 - Consulta de Clientes

[Menu Contábil]

 Clique para expandir/recolher

📘 3️⃣ Lançamentos feitos na agenda contábil, não aparecendo no lançamento (SUP-947720)

Ocorrência: Lançamento que eram feitos pela tela “Contábil - Agenda Lançamentos”, não apareciam na tela “Contábil - Manutenção Serviço Automático da Agenda”.

Solução: Foi feito um ajuste para que ao passar a data para verificar se deve ser realizado lançamento, o sistema estará considerando o último dia do mês da data informada e não da data atual.

Lançamento realizado com parcelas pela tela “Contábil - Agenda Lançamentos” (Imagem 1).

As parcelas exibidas na tela “Manutenção Serviço Automático da Agenda (Imagem 2).

Local>Tela 9.2.10 - Contábil - Agenda de Lançamentos

Local>Tela 9.2.11 - Contábil - Manutenção Serviço Automático da Agenda

📘 3️⃣ Períodos não aparecem na tela “Contábil - Integração” (SUP-95294)

Ocorrência: Os períodos não estavam sendo exibidos na tela “Contábil - Integração” depois de integrados, tendo que ser modicados pelo banco de dados e não eram apresentados na tabela “CONTABIL_INTEGRADO”.

Solução: Foi alterada a transação do procedimento dos últimos 10 acessos para uma transação independente, desta forma não impactará na transação principal do Guarani. Também foi realizada a mesma alteração no procedimento “LogSimplificado”, que tem por objetivo capturar qualquer exceção do software que não foi tratada e salvar no banco de dados, que também realizava “commit” na transação principal, desta forma foi alterado para que o “LogSimplificado” também possua uma transação independente (Imagem 1).

Local>Tela 9.2.1 - Contábil - Integração

[Menu Telemarketing]

 Clique para expandir/recolher

📘 2️⃣ Inconsistências na tela “Telemarketing - Operação” (SUP-94925)

Ocorrência: A tela "Telemarketing - Operação" estava apresentando inconsistências em relação ao tempo dos atendimentos e ao tentar parar e finalizar uma operação.

Solução: Foi inserido um bloqueio, para que seja necessária a atualização da operação que foi alterada por outro usuário (Imagem 1).

Local>Tela 14.2.1 - Telemarketing - Operação


Índice:

Legendas dos tipos de tickets
Legendas da criticidade do ticket
?? Mudança
📗 Melhoria
?? Solicitação
1️⃣ Relevante
2️⃣ Importante
3️⃣ Muito importante

Feedback

Qual é o seu nível geral de satisfação com essas notas de versão?

Clique aqui para responder

  • Sem rótulos