...
| Expandir | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
📗 1️⃣ Alíquota de ICMS no relatório de royalties (ERP-3094)Nas telas “3.3.8 - Relatório de apuração de royalties e 3.3.30 - Relatório de apuração de royalties (novo)”, foi implementada a grid de relatórios de apuração de Royalties, e os campos referentes a base de cálculo, alíquota e valor de ICMS, IPI, PIS e COFINS. A grid também foi reformulada e separada por colunas, com seus respectivos campos para melhor organização e visualização.
📘 1️⃣ Quantidade de itens alterada por um usuário sem permissão (ERP-3307)Ocorrência: A tela de reserva, estava permitindo alteração na quantidade do item mesmo não tendo permissão na digitação de ordens. Solução: Foi realizado um ajuste de permissão para alterar quantidade do item pela tela de reserva. Se não houver permissão na tela “Digitação de ordens”, não será permitido alterar a quantidade. A mesma validação será realizada na tela de “Manutenção de ordens”, ao alterar a quantidade (Imagens 1, 2 e 3).
Local>Tela 3.2.29 - Rastreamento de ordens 📘 2️⃣ Sistema permitindo o faturamento de produtos com legenda "Em Transição" (ERP-3429)Ocorrência: Ao inserir produtos através da digitação expressa (também importando arquivo CSV), o sistema estava deixando inserir produtos em transição. Solução: Foi realizado um ajuste para não permitir produto em transição na digitação expressa, ajustado também ao importar arquivo CSV.
 
 
 Local>Tela 1.1.19 - Cadastro de produtos Local>Tela 3.2.12 - Digitação de ordens 📘 1️⃣ Pedido “Em Análise” com status "Autorizado" (ERP-3397)Ocorrência: Quando era feita a alteração do desconto e do tipo de cobrança do pedido, estava alterando o status de análise para “Autorizado”. Solução: Foi feito um ajuste para que ao efetuar a alteração da cobrança de um pedido, seja refeito a análise dos crivos (Imagens 1 e 2).
Local>Tela 3.2.12 - Digitação de ordens Local>Tela 3.2.29 - Rastreamento de ordens |
...
| Expandir | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||
📗 2️⃣ Geração de financeiro automático após faturamento (ERP-3364)Na tela “Parâmetros :: Guarani” foi criado um novo parâmetro chamado “Exige geração de contas a receber a cada romaneio?”. Quando este estiver ativo e os usuários não gerarem cobranças pela tela “4.2.6 - Expedição” e tentar gerar a próxima nota, o sistema irá impedir que o faturamento seja feito enquanto não forem geradas as cobranças pendentes (Imagem 1).
Uma validação será apresentada nas telas “4.2.6 - Expedição” e “3.2.12 - Digitação de ordens” no momento do faturamento, ao selecionar a opção de “Emissão/Impressão Geral de NFs”. Caso tenham cobranças anteriormente não geradas pelo usuário que está efetuando o faturamento, o sistema irá enviar a mensagem de validação (Imagem 2).
 📗 1️⃣ Considerar empresa do título ao enviar e-mail pela tela “Manutenção de contas a receber” (ERP-3446)Na tela "5
📗 1️⃣ Considerar empresa do título ao enviar e-mail pela tela “Manutenção de contas a receber” (ERP-3446)Na tela "5.2.15 - Manutenção de contas a receber" foi inserida uma alteração nas opções de envio de e-mail, ao clicar com o botão direito no título. A mensagem que é possível montar a partir do parâmetro "Cobrança - Texto do corpo do e-mail", passará a buscar este parâmetro de acordo com a empresa do título e não pela empresa logada no momento.
Informações |
 |
| Expandir | |||||||
|---|---|---|---|---|---|---|---|
| |||||||
📘 2️⃣ Gerador de contas (ERP-3419)Ocorrência: Estava ocorrendo uma lentidão ao carregar: produtos, fornecedores e clientes na tela “Contábil - Gerador de Contas”. Solução: Foi feita uma melhoria na performance ao inserir a pesquisa de produtos, fornecedores ou clientes na grid da tela “Contábil - Gerador de Contas”, corrigindo assim a mensagem que era emitida.
 Local>Tela 9.2.7 - Contábil - Gerador de Contas |
| Expandir | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
📘 2️⃣ Gerador de contas 📗 2️⃣ Razão Contábil - O saldo do período não bate com total dos créditos (ERP-3419)Ocorrência: Estava ocorrendo uma lentidão ao carregar: produtos, fornecedores e clientes na tela “Contábil - Gerador de Contas”. Solução: Foi feita uma melhoria na performance ao inserir a pesquisa de produtos, fornecedores ou clientes na grid da tela “Contábil - Gerador de Contas”, corrigindo assim a mensagem que era emitida.
Local>Tela 9.2.7 - Contábil - Gerador de Contas | ||||||||||
| Expandir | ||||||||||
| ||||||||||
Exemplo: O lote 1298 possui o ID 354350 com 4 partidas e as partidas estão ordenadas do maior para o menor, gerando assim a diferença no saldo, pois o saldo é montado seguindo a ordenação: “Conta, Data Lançamento, ID e Partida”, entretanto no relatório a ordenação não continha o campo “Partida”. |
| Informações |
|---|
Razão após ajuste de ordenação (Imagem 1). |
Ajustes implementados:
| Informações |
|---|
Implementada a correção de valores negativos, para ficarem entre parênteses (Imagem 2). |
| Informações |
|---|
Implementada a correção do saldo anterior, para exibir o saldo sequencialmente, ou seja, o último saldo da página anterior (Imagem 3). |
Local>Tela 9.3.1 - Contábil - Relatórios contábeis
| title | FISCAL |
|---|
📘 2️⃣ SPED Fiscal - Quantidade de linhas do bloco zero informada não confere com a esperada pelo sistema (ERP-3415)
Ocorrência: Havia uma inconsistência ao validar o arquivo SPED.
Solução: Foi feito um ajuste na geração do registro “0450”, para que seja feita a inserção inicial de um valor de referência.
Com o intuito de melhorar a experiência do usuário:
Após feita a correção da inconsistência causada pelo registro “0450” e gerar o SPED, foram apresentadas imprecisões relacionadas aos blocos:
0150: Cliente com código de município da nota fiscal zerada/inválida ou casos em que o registro era zero “0” continham espaçamentos em branco.
0200: Produtos com cedilha (ç/Ç) ocasionavam quebra nos registros do SPED Fiscal.
Todas as inconsistências citadas foram ajustadas para o correto funcionamento dos blocos.
Local>Tela 10.2.16 - Sped fiscal
📘 2️⃣ Geração do arquivo CAT 42 (ERP-3443)
Ocorrência: O arquivo CAT 42 estava sendo indeferido pela SEFAZ. Registro “0150” repetia o participante, mesmo já existindo participante com o mesmo código.
Solução: Foi realizado um ajuste no registro “0150” da CAT 42, para que não repita o participante quando este for pessoa física.
| Informações |
|---|
Arquivo gerado após ajuste com clientes do tipo pessoa física (Imagem 1). |
Local>Tela 10.2.20 - Geração dos arquivos do CAT 42/20183454)
Na tela “9.3.1 - Contábil - Relatórios contábeis”, foi implementada a correção referente a ordenação do “Relatório contábil - razão”, para que as linhas com saldos não fiquem invertidas fazendo com que o saldo final saia com inconsistências.
Exemplo: O lote 1298 possui o ID 354350 com 4 partidas e as partidas estão ordenadas do maior para o menor, gerando assim a diferença no saldo, pois o saldo é montado seguindo a ordenação: “Conta, Data Lançamento, ID e Partida”, entretanto no relatório a ordenação não continha o campo “Partida”. |
| Informações |
|---|
Razão após ajuste de ordenação (Imagem 1). |
Ajustes implementados: |
| Informações |
|---|
Implementada a correção de valores negativos, para ficarem entre parênteses (Imagem 2). |
| Informações |
|---|
Implementada a correção do saldo anterior, para exibir o saldo sequencialmente, ou seja, o último saldo da página anterior (Imagem 3). |
Local>Tela 9.3.1 - Contábil - Relatórios contábeis
| Expandir | |||||
|---|---|---|---|---|---|
| |||||
📘 2️⃣ SPED Fiscal - Quantidade de linhas do bloco zero informada não confere com a esperada pelo sistema (ERP-3415)Ocorrência: Havia uma inconsistência ao validar o arquivo SPED. Solução: Foi feito um ajuste na geração do registro “0450”, para que seja feita a inserção inicial de um valor de referência.
Local>Tela 10.2.16 - Sped fiscal 📘 2️⃣ Geração do arquivo CAT 42 (ERP-3443)Ocorrência: O arquivo CAT 42 estava sendo indeferido pela SEFAZ. Registro “0150” repetia o participante, mesmo já existindo participante com o mesmo código. Solução: Foi realizado um ajuste no registro “0150” da CAT 42, para que não repita o participante quando este for pessoa física.
Local>Tela 10.2.20 - Geração dos arquivos do CAT 42/2018 📗 1️⃣ Unidade de venda diferente no lote x produto, na validação de XML (ERP-2947)
Na tela “3.2.12 - Digitação de ordens”, foi feita uma alteração na atribuição de quantidade (qLote), quando o produto for vendido por embalagem ao invés de unitário, desta forma, foi alterada a somatória da quantidade de lote (qLote) igualando a quantidade comercializada (qCom), através da divisão de lotes pelo fator de venda do produto ao gerar nota fiscal eletrônica, com produtos que contenham rastro por lotes (Imagens 1 e 2).
|
| Expandir | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||
📘 2️⃣ Manifestação do destinatário com inconsistências (ERP-3398)Ocorrência: A “Manifestação do Destinatário” estava com inconsistências, não realizava alteração dos status da Nota Fiscal eletrônica na SEFAZ, apenas mudava o status dentro do sistema. O serviço de manifestação automática tentava realizar a ciência da Nota Fiscal eletrônica, mas era retornada a inconsistência “578 - Motivo: Rejeição: A data do evento não pode ser maior que a data do processamento“, entretanto esta inconsistência não era externada pelo Guarani. O tratamento de rejeição não verificava os status de forma correta, o que ocasionava na alteração dos status dentro do sistema, exibindo uma falsa ciência da operação. Solução: Foi implementado um registro das operações realizadas pelo serviço de manifestação, utilizando o arquivo que já existia dentro da pasta do executável “GuaraniServicos.log”, neste arquivo ficará salvo todas as ações realizadas pelo “Guarani Serviços”. Também foi melhorado o tratamento de rejeição retornado pela Sefaz, alterando o status apenas quando obtiver sucesso. Implementações realizadas dentro do Guarani:
As ocorrências serão um histórico das ações realizadas, dessa forma ficará sempre visível se uma operação obteve sucesso ou falha ao ser realizada. O tratamento da inconsistência da operação foi corrigido alterando o status do registro dentro do sistema, apenas quando obtiver sucesso na operação realizada seguindo o manual da Nota Fiscal eletrônica (Arquivo 1).
 Alterações realizadas no “GuaraniServicos”:Foi identificado que em algumas ocasiões o “GuaraniServicos” realizava uma consulta com um intervalo menor do que de uma hora, mesmo estando configurado para consultar a cada hora. Neste caso faltava alguns segundos para completar o intervalo de uma hora, desta forma era retornada a inconsistência de consumo indevido.
Foi adicionado mais dois minutos a consulta para que não retorne a inconsistência de consumo indevido, sendo assim, as consultas serão realizadas com uma hora e dois minutos de intervalo. Também foi identificado que era gerado consumo indevido pelo último “NSU”, informado não ser o último “NSU” na SEFAZ, as inconsistências retornadas são parecidas, mas com causas diferentes.
“Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1(uma) hora))”. Visto que o usuário poderá acessar o site da SEFAZ e realizar uma consulta alterando o último “NSU” ou utilizar algum outro aplicativo para fazer a manifestação, o sistema conseguirá se recuperar desta inconsistência obtendo o último “Número Sequencial Único” da SEFAZ e atualizando este na base de dados.
Local>Tela 16.2.1 - Manifestação do Destinatário |
...