📙 Nome e número da mudança

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

📗 3️⃣ Inserida paginação ao exportar produtos para planilha Excel.

Na tela “1.1.19 - Cadastro de produtos”, foi adicionada a paginação na exportação do arquivo “CSV”. A partir de agora ele será trabalhado em cada página de forma separada, ou seja, gerará o arquivo página por página, o que limitará o espaço ocupado na memória. Sendo assim, ao iniciar o processo de exportação será fechada a consulta de produtos, liberando os “mb” utilizados inicialmente. E ao finalizar o processo de exportação será fechada a consulta de exportação, liberando os “mb” que estavam sendo utilizados, desta forma, fará com que o processo de exportação ocorra normalmente (Imagem 1).

📗 3️⃣ Ajustes Diversos PCP Engenharia - Ajustar numeração NFS-e e Busca de Chaves sem uso da Lupa.

Nas telas que possuem os campos “Plano financeiro” e “Centro de custo”, foram feitas alterações. Agora, será possível digitar o código destes campos.

• Campo “Plano financeiro”.

📗 2️⃣ Cálculo do estoque na sugestão de compra.

Na tela “2.2.11 - Sugestão de Compra”, foram feitas alterações para que ao pesquisar o produto para gerar a sugestão de compra e configurar o campo "Estoque und compra" com “NÃO”, será realizado o cálculo dos totalizadores "Estoque Atual", "Comprado", "Vendido" e "Saldo" (Imagem 1).

📗 2️⃣ Inconsistência ao clicar na lupa de “Rateio Padrão Centro de Custo”.

Na tela “2.2.8 - Manutenção das ordens de compra”, foi feito um ajuste para que somente seja aberta a tela quando estiver sendo inserida/alterada alguma ordem de compra, assim como acontece com alguns outros campos desta mesma tela, como “Cobrança”, “Classificação Gastos”, entre outros (Imagem 1).

📗 2️⃣ Totalizador de coluna na tela “Entrada de notas fiscais”.

Na tela “2.2.4 - Entrada de notas fiscais”, foi implementado um totalizador para a coluna “Valor total” pertencente à grade das notas consultadas (Imagem 1).

📗 3️⃣ Validação “Tipo de Ordem x Classificação de Gastos”.

Na tela “2.2.8 - Manutenção das ordens de compra” em (pedido de compra), foi implementada uma validação entre a “Classificação de gastos e Tipo de ordem do pedido de compra”, que irá operar mediante algumas configurações e configurações.

• Para que o sistema faça a validação entre a “Classificação de gastos e Tipo de ordem do pedido de compra”, deverão seguir algumas “Condições”:

📗 2️⃣ Customização na tela “Emissão de Ordens”.

Na tela "3.2.14 - Emissão de Ordens", foram incluídas duas colunas na grade:

• "Prazo médio": Esta coluna fornecerá informações sobre o prazo médio relacionado a cada ordem;

• "Condição de venda": Esta coluna indicará a condição de venda associada a cada ordem (Imagens 1 e 2).

📗 2️⃣ Ao gerar nota de reentrada pela tela “Fechamento de Ordens”, a quantidade devolvida na nota original (NFI_QUANTIDADE_DEV) duplicava.

Na tela "4.1.1 - Cadastro de notas fiscais”, foi feito um ajuste para que quando a nota de reentrada, gerada através da exclusão de uma digitação de ordem (Cancelamento), for pesquisada e salva, não seja duplicado o campo “NFI_QUANTIDADE_DEV” da tabela “NFITENS”, referente à nota vinculada à digitação de ordem que foi cancelada, originando a nota de reentrada (Imagens 1 e 2).

📗 2️⃣ Ao gerar nota de reentrada pela tela “Fechamento de Ordens”, a quantidade devolvida na nota original (NFI_QUANTIDADE_DEV) duplicava.

Na tela "4.1.1 - Cadastro de notas fiscais”, foi feito um ajuste para que quando a nota de reentrada, gerada através da exclusão de uma digitação de ordem (Cancelamento), for pesquisada e salva, não seja duplicado o campo “NFI_QUANTIDADE_DEV” da tabela “NFITENS”, referente à nota vinculada à digitação de ordem que foi cancelada, originando a nota de reentrada (Imagens 1 e 2).

📗 1️⃣ Não permitindo cidade com mais de 30 caracteres.

Na tela "3.5.7 - Guarani móvel - Android - importação de dados”, foi feito um ajuste no recebimento pelo “Integrador WS” de pedidos de clientes. Agora, no campo “Cidade”, ao inserir uma nomenclatura que possuir mais de 30 caracteres, serão desconsiderados os caracteres que ultrapassarem esta quantidade limite (Imagem 1).

📗 1️⃣ Liberação de ordens em massa.

Na tela “5.2.16 - Liberação de ordens”, foi implementada uma opção para liberação das ordens em massa. Nesta tela, foi adicionada a aba “Desbloqueio de crivos em massa”.

📗 3️⃣ Centro de custo para conta de juros passivos.

Na tela “Contas a pagar”, foi adicionada uma opção para informar o plano financeiro e centro de custo na aba “Dados adicionais” (Imagem 1).

📗 3️⃣ Tela “Lançamentos a pagar” informando emissão incorretamente.

Nas telas “6.2.6 - Lançamentos a pagar, 6.2.1 - Autorização de pagamentos e 6.2.7 - Pagamento de contas”, foi adicionado o campo “Data emissão da NF”.

📘 2️⃣ Mensagem na tela de transmissão de NF PDV

Ocorrência: Uma inconsistência estava ocorrendo ao transmitir ou tentar abrir, uma nota com observação de cliente SUFRAMA no PDV. Esta inconsistência estava ocorrendo por conta do campo observação da base legal que vinha preenchida do cadastro de clientes, desta forma, a base legal não era levada para emissão de notas fiscais no PDV e ainda apresentava a inconsistência ao tentar emitir uma nota fiscal.
Solução: Foi feito um ajuste nos campos observações na emissão de nota fiscal feita direto pelo PDV, aumentando o campo observação e levando o preenchimento da base legal, para a emissão da nota no PDV (Imagens 1, 2 e 3).

📘 1️⃣ Filtro por número de requisição de compra não funcionando.

Ocorrência: A inconsistência estava ocorrendo devido a forma com que os filtros foram criados, considerando o conteúdo digitado como texto ao enviar para a consulta no banco. Desta forma, o filtro por número de requisição de compra, não estava funcionando.

Solução: Foi feita uma correção para considerar o código digitado, como inteiro (Imagem 1).

📘 1️⃣ Inconsistência ao utilizar o relatório na tela “3.3.18 - Relatório de vendas (feirinha)”.

Ocorrência: Estava sendo apresentada uma inconsistência ao gerar o relatório de vendas com produtos de feirinha. Era comparado o produto escolhido na consulta “pro_referencia” (produto escolhido na tela) com “pro_codigo” (consulta no banco), gerando uma inconsistência caso houvesse alguma letra no produto da referência escolhida.

Solução: Foi feito um ajuste para que seja utilizado o código do produto para realizar a consulta (pro_codigo escolhido X pro_codigo no banco) (Imagem 1).

📘 1️⃣ Relatório Royalties.

Ocorrência: Na listagem de itens a serem processados na tela “Relatório de apuração de royalties” estavam sendo repetidos, somente os produtos que continham código de barras adicionais

Solução: Foi corrigido para que a consulta seja pelo código de barras adicional, desta forma, o produto não irá se repetir independente da quantidade de códigos adicionais que existam.

📘 Em “Manutenção de ordens”, não era permitido alocar peças de quantidades exatas.

Ocorrência: A quantidade de volumes do pedido não estava atualizando, quando alocava peças na pela “Manutenção de ordens”, pois o processo de alocação de peças ocorria à partir da opção “Alterar quantidade”.

Solução: Foi corrigido para sempre rodar a procedure, caso exista peça alocada no pedido, independente se houve alteração na quantidade.

📘 2️⃣ Sistema validando estoque incorretamente ao faturar romaneio.

Ocorrência: Ao realizar o faturamento, o sistema validava o estoque incorretamente. Este comportamento ocorria quando o parâmetro para checkout estava optado como “ANTES DO FATURAMENTO” e o romaneio possuía ordens com configurações diferentes em seus tipos (exemplo: tipo de ordem que integrava checkout e tipo de ordem que não integrava checkout).

Solução: Foi realizado um ajuste na verificação do estoque ao confirmar o faturamento. Serão validadas as ordens quando o checkout não for antes do faturamento, ou quando o checkout for antes do faturamento, mas o tipo de ordem não integrar checkout. Também foi inserido um log de operações para exibir as ordens em que o tipo de ordem estará optado como “NÃO” movimentar estoque (Imagem 1).

📘 2️⃣ Inconsistência ao importar DI.

Ocorrência: Estava ocorrendo uma inconsistência ao importar a DI, quando associada com pedido de compra.

Solução: Foi feito um ajuste para realizar os cálculos, apenas dos itens que constam no pedido de compra que foi utilizado na importação da DI.

📘 2️⃣ Impressão de boletos não considerando a quantidade de cópias escolhidas.

Ocorrência: Ao realizar a impressão de boletos, a quantidade de cópias optadas não estava sendo considerada, devido a instância do componente ser criada duas vezes, mas somente na segunda o boleto era enviado efetivamente para a impressão, ficando a primeira instância responsável por recuperar as configurações optadas.

Solução: Foi feito um ajuste para que seja considerada a quantidade de cópias optada no processo de impressão do boleto (Imagens 1, 2 e 3).

📘 2️⃣ Ao selecionar títulos para junção, o sistema apresentava uma mensagem de falha.

Ocorrência: Estava ocorrendo uma inconsistência, ao realizar a junção de títulos na tela “Lançamentos a pagar”.

Solução: Foi feito um ajuste para verificar se o objeto existe e criá-lo se necessário antes de utilizar. Desta forma, ao fazer a junção de títulos não ocorrerá mais a mensagem de falha de segmentação (Imagens 1 e 2).

📘 2️⃣ Cadastro de CT-e - “Size Mismatch - Field MENSAGEM size is too small for data”.

Ocorrência: Ao transmitir CT-e estava sendo apresentada uma inconsistência, tag “<prodPred> -Produto Predominante” ultrapassando o limite de caracteres permitidos (60).

Solução: Foi realizado um ajuste, para limitar a tag “<proPred> - Produto Predominante” com 60 caracteres na transmissão do CT-e.

📘 2️⃣ Inconsistência ao consultar NF-e na “Sefaz” em “Manifestação do destinatário”.

Ocorrência: Ao consultar NF-e estava sendo apresentada uma mensagem de inconsistência, mesmo quando a consulta era realizada normalmente.

Solução: Foi adicionada uma melhoria no retorno da consulta por NSU, para que ao identificar novos documentos, a mensagem apresentada na grade seja de sucesso, uma vez que existem dois tipos de consultas no serviço (consulta por último NSU e consulta por NSU), em qualquer uma das duas que apresentar sucesso ao retornar documentos, a mensagem será condizente com o sucesso da consulta.