Issuu

Nexgen2.3

Notas - Release 129

Histórico de Alterações Aplicáveis ao sistema Nexgen

SECREL - Tecnologia e Soluções Inovadoras® | NexGEN – Toda sua gestão nas nuvens. Copyright © 2015 SECREL. – Todos os direitos reservados. Nenhuma parte deste documento pode ser copiada, reproduzida, traduzida ou transmitida por qualquer meio eletrônico ou mecânico, na sua totalidade ou em parte, sem a prévia autorização escrita da SECREL, que se reserva o direito de efetuar alterações sem aviso prévio. A SECREL não assume qualquer responsabilidade pelas consequências de quaisquer erros ou inexatidões que possam aparecer neste documento.

SECREL SOLUÇÕES DE INFORMÁTICA LTDA. Matriz: Av. Dom Luís, 500 - 20º andar - Aldeota Fortaleza - CE - 60.160-230 T: 85 3466.7000 - Brasil - www.gruposecrel.com.br

SUMÁRIO NOVIDADES

PREFÁCIO

RESUMO QUANTITATIVO

FRENTE DE LOJA

Processo: Pedido de Cliente de Venda

Processo: Recebimento de Pedidos E-commerce

Processo: Pedido de Venda Cartão Presente

Processo: Pedidos de Requisição

Processo: Separação Pedidos E-commerce

Processo: Processo de Integração Nexgen x Woocommerce

Processo: Nexgen Mobile - Interface de Pedido de Ótica

Processo: Login – Nexgen Mobile

Processo: Pedido de Venda de Cliente de Ecommerce

Processo: Nota Fiscal Faturamento e Remessa – Entrega Futura

Processo: Pedido de Venda ao Cliente – Integração SFA

ÓTICA

Processo: Pedido de Venda de Cliente de Ótica

Processo: Consulta de Ordem de Serviço

Processo: Envio de Malote, confirmação por SMS

Processo: Cadastro de Ordem de Serviços para Retificação

Processo: Geração de Malote na Loja

Processo: Ordem de Serviço Showroom

RETAGUARDA

Processo: Atualização de Protocolo (ESTOQUE)

Processo: Monitoramento Ecommerce

Processo: Manter Divergência de Protocolo

Processo: Recebimento de Pedido Contra Entrega

Processo: implementação Rest API – Mensagens WhatsApp

Processo: Devolução de Pedido de Cliente

Processo: Valores por Categorias

Processo: Emissão de Carnet

23 Página | 2

Processo: Históricos de Garantias

Processo: Digitação da Garantia

Processo: Renegociação de Títulos

Processo: Gestão de Relacionamento com Cliente

Processo: Pedido de Compra de Fornecedor

Processo: Entrada de Mercadorias do Fornecedor

Processo: Integração Conciliação de Cartão

Processo: Importação de Cupom Fiscal Eletrônico

Processo: Importação Arquivo do Fornecedor

Processo: Recebimento de Pedido de Cliente

Processo: Importação do CT-e

Processo: Emissão de Etiquetas do Produto

Processo: Manutenção de Cliente

Processo: Extrator de Dados

Processo: Implementação de recursos novos

Processo: MODIFICAÇÕES E IMPLEMENTAÇÕES

Processo: Devolução de Pedido de Cliente

Processo: Validação dos Dados

Processo: Preço de Produto por Loja

Processo: Inutilização de Cartão Presente

Processo: Gerar Arquivo para NAPP

Processo: Entrada de Mercadorias ao Fornecedor

Processo: Informações de Cartão

Processo: Gerar Arquivo para NAPP

MENSAGERIA

Processo: Nota Técnica 2020.006 - v.1.00

Processo: Envio XML Cofre Sieg – CFE/SAT

Processo: Nota Fiscal Eletrônica ao Consumidor

Processo: Emissão de Notas - NF-e e NFC-e

AJUSTES GERAIS

Processo: Log’s TomCat – MonitorPDV2.4.2

Processo: Títulos Negociados na Cobrança

34 Página | 3

Processo: Consulta Protocolos e Relatório Status dos Protocolos

Processo: Gerar Arquivos Importação Mtrix

Processo: Integrações Nexgen

Processo: Ajuste de Código Nexgen

Processo: Atualização de Ambiente.

Processo: Integração de “Preços Promocionais” Petronas SFA

Processo: Relatórios

Processo: Inserção do parâmetro ‘noLock’ nas Qry de Consulta

Processo: Estruturas de Dados

Página | 4

Efetuada implementação para ao incluir produtos novos a partir da atualização de

NOVIDADES

produtos na transação REAJF, permitir a geração do código de barras automático e incluir a opção de atualização de produtos por visão de lojas.

Pedido de Venda de Cliente Foi implementado um campo “Pedidos c/Divergência na Integração” na tela Consulta Pedido(CPEDC), sua função é listar os pedidos com erro de integração nos processos de LDB e SFA. Foi modificado também o processo de Pedidos a prazo, para que quando ocorra o erro de integração sejam enviados para “Aprovação de Crédito” o que antes não existia.

Foram implementadas as colunas nas transações: COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos, para solucionar a deficiência do pedido, com as colunas Quantidade de Itens e Dias de Atraso. Devolução de Cliente (DEVOL) foi

Comunicação Nexgen com a implementada para calcular o custo da plataforma WooCommerce, sendo assim devolução com o mesmo valor de custo o Nexgen irá enviar Categoria, Produto com Grande, Estoque e Preço, e irá receber os pedidos feitos no ecommerce para que seja feito o processo de separação e emissão de nota fiscais.

utilizado na venda original. O custo da devolução será o mesmo da venda, quando a operação fiscal de devolução for configurada para "Devolução Cliente usar Preço Custo Venda".

Interface do Nexgen Efetuada implementação para enviar dispositivos móveis, que automaticamente o xml CF-e autorizado

Foi implementada a

para

contempla o Pedido de Cliente de Venda de Ótica.

Interface do Pedido de Ótica do Nexgen Mobile as seguinte

para o email configurado na transação MSPAR, campo "Guarda de XML".

Foi implementada na

melhorias: Criação de tela simplificada para cadastro de clientes: A nova tela deverá ser utilizada em dispositivo móvel que será disponibilizado ao cliente para que ele faça seu cadastro. Paralelamente a isso o vendedor utilizará a tela de Pedido de venda de Cliente de Ótica (PEPCV) em seu tablet para gerar o pedido de venda.

Notas Simples Faturamento Remessa - Entrega Futura.

Foi implementado o sistema de tempo de vida do token de autenticação para as chamadas REST API, caso não seja configurado, o token será válido indefinidamente. Foi implementado na tela Emissão de Carnet (CARNE) para emitir também boletos através botão criado “Emitir Boleto”.

Foi implementado Relatório de Títulos Negociados na cobrança (RTCOB), filtros disponíveis (Gerado, Não gerado e Todos).

Foi implementada na tela de Valores das Categorias (VLCAT) , a opção: "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. na tela de Valores das Categorias (VLCAT) de "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja.

Na tela Renegociação de Títulos (RENEG) foi implementado campo "Juros" , para exibir o valor dos juros calculado na renegociação.

Foi implementado a função de adiantamento ao fornecedor na tabela de garantias nas

Página | 5

operações fiscais de "DEVOLUÇÃO AO FORNECEDOR DE GARANTIA".

Foram modificadas as telas CLIEN (Cadastro de Cliente),CLISP(Cadastro de Cliente Simplificada) e CLIOT(Cadastro de Cliente Ótica) com um CheckBox ao lado de cada telefone celular para indicar se o telefone está habilitado para mensagens pelo WhatsApp. Modificada também a tela (CARNE) para emitir o boleto bancário para título do tipo "CONTRATO".

PREFÁCIO Versão Nexgen 2.3.129 FRENTE DE LOJA ●

● ● ●

●

● ● ● ●

A tela de Pedido de Venda de Cliente (PEDCV ) foi implementada com a alteração para fazer uma crítica se o cliente foi alterado após a inclusão do item, essa crítica só será realizada se o parâmetro 15 estiver setado para NÃO. Caso o parâmetro citado (15 ) esteja com valor igual a “SIM” será permitido alteração do cliente após a inclusão de um item no pedido. A tela Pedido de Venda de Cliente (PEDCV) foi implementada para efetuar o recalculo da política de preço do "pedido juntando" quando for alterado o plano de venda do pedido do cliente. Efetuada implementação para adequar o processo de cartão presente para integrar com a plataforma Todo Cartões do Nexgen. A tela Pedido de Venda de Cliente (PEDCV) foi implementada para efetuar o recalculo da política de preço do "pedido juntando" quando for alterado o plano de venda do pedido do cliente. A tela Recebimento Pedido de Cliente foi implementada para realizar uma verificação de valores. A validação dos valores se dará quando estiver associada a pedido de peças, a modificação foi precisa para identificar possíveis problemas, evitando que o pedido seja recebido e permitindo fazer o seu diagnóstico. Foi implementado um campo “Pedidos c/Divergência na Integração” na tela Consulta Pedido(CPEDC), sua função é listar os pedidos com erro de integração nos processos de LDB e SFA. Foi modificado também o processo de Pedidos a prazo, para que quando ocorra o erro de integração sejam enviados para “Aprovação de Crédito” o que antes não existia. Efetuada a correção no processo de recebimento de pedido e commerce, sendo implementado um processo de validação de valores do pedido, deixando o procedimento mais intuitivo. A tela Pedido de Venda Cartão Presente (PEDCP) foi implementada para permitir usar a matrícula do vendedor no momento de uma venda de cartão presente. A rotina de pedido de requisição foi alterada para gravar os campos CD_CRED e TP_FRETE na DPEDC e TP_PRECO na DIPD corretamente. Efetuada correção no processo de separação do pedido recebido do ecommerce WOOCOMMERCE, quando usado processo de reserva de estoque. O problema ocorre quando o pedido é recebido do ecommerce WOOCOMMERCE e está sendo usado o processo de reserva, o que provocava a incorreta dedução do estoque.

Página | 6

●

● ● ● ●

● ●

● ● ● ●

Efetuada implementação da comunicação Nexgen com a plataforma WooCommerce, sendo assim o Nexgen irá enviar Categoria, Produto com Grade, Estoque e Preço, e irá receber os pedidos feitos no ecommerce para que seja feito o processo de separação e emissão de nota fiscais. Efetuada correção no processo para não validar a descrição do ambiente informado na Integrações da Loja, pois no Woocommerce não é obrigatória essa informação. Corrigida a consulta da modalidade de pagamento para não considerar modalidades inativas do momento da integração de pedidos ecommerce; Deverão ser implementadas melhorias na Integração Nexgen x Woocommerce. Integração Integração Nexgen x Woocommerce.

Foi implementada a Interface do Nexgen para dispositivos móveis, que contempla o Pedido de Cliente de Venda de Ótica. Foi implementada na Interface do Pedido de Ótica do Nexgen Mobile as seguintes melhorias: Criação de tela simplificada para cadastro de clientes: A nova tela deverá ser utilizada em dispositivo móvel que será disponibilizado ao cliente para que ele faça seu cadastro. Paralelamente a isso o vendedor utilizará a tela de Pedido de venda de Cliente de Ótica (PEDCV) em seu tablet para gerar o pedido de venda. Foram geradas as classes e atualizadas para correção do ambiente do nexgen móvel que havia parado de funcionar. Implementar o envio de preço e estoque para o E-Commerce, quando o produto já existir e for configurado para disponível para o E-commerce. O sistema não emitia Notas Simples Faturamento Remessa – Entrega Futura. Implementada a gravação da observação vinda de pedidos do SFA.

ÓTICA ●

O problema no pedido de ótica acontece porque a consulta de leitura dos produtos do pedido estava com um argumento errado e com isso não retornava todos os produtos. Após correção, o problema foi corrigido. ● Foi implementada a impressão do código da Ordem de Serviço abaixo do código de barras. ● Efetuada correção no processo de envio de SMS para InfoBip, melhorando o processo para evitar que um erro no envio do SMS para o processo da OS, melhorando também a análise do processo, efetuando mais gravações na tabela sobre a comunicação com a InfoBip. ● A tela Cadastro de Ordem de Serviço para Retificação (OSRET) foi programada para não permitir o cancelamento da OS Original. ● A tela Geração de Malote na Loja (GERLJ) foi implementada para remoção dos dados da quantidade dos produtos ao fim da sessão, corrigindo assim o problema de estoque do item armação ao gerar malote. ● Foi criado o parâmetro 1506 para determinar se o estoque reserva deverá ser movimentado juntamente com o estoque físico na geração e recepção do malote. Os produtos que serão movimentados são os produtos que não são lentes e nem serviços. Isso ocorreu se o parâmetro foi colocado para "Sim". Foi implementado o estoque mínimo ou fator na geração da OS Showroom. Foi criado o parâmetro 1505 para informar a quantidade mínima ou fator do estoque da OS Showroom.

RETAGUARDA Página | 7

● ● ● ● ●

●

● ●

● ● ● ● ● ●

A tela Atualização de Protocolo (ATEUS) foi implementada para que, nesse caso, o sistema exiba uma mensagem indicando o Lote, Protocolo, Nota e Fornecedor para direcionar o problema. A tela Atualização de Protocolo (ATUES) foi implementada para ao consultar pelo protocolo o campo quantidade convertida. Foi alterado para se comportar tanto o lote, como protocolo da mesma forma. Corrigido um problema de “NullPointerException” gerado pela atualização. A tela Manter Divergência de Protocolo(MDPTC ) foi implementada com o procedimento correto a ser seguido para exibir as pendências resolvidas. A tela Recebimento de Pedido Contra Entrega (RECEN ) foi implementada para o recebimento dos pedidos com a modalidade de contra entrega que foram faturados em qualquer caixa, e não somente no caixa de faturamento do mesmo pedido.

Implementação das chamadas REST API para verificação de cliente, consulta e geração de boleto, a ser utilizada pelo sistema de troca de mensagens por WhatsApp. Foi criado, na tela de Devolução de Venda, um cheque "Zerar Frete", que permitirá que o frete da nota de venda seja zerado, na nota de devolução quando essa não tiver o frete da venda. A tela Devolução de Pedido de Cliente (DEVOL) foi implementada com opção para possível utilizar a matrícula no campo do código do vendedor .Para que o sistema se comporte dessa maneira será preciso que o parâmetro 671 (Solicitar a Matrícula do Vendedor na Devolução) esteja setado como "SIM". Foi implementada na tela de Valores das Categorias (VLCAT) , a opção: "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. Desenvolver opção na tela de Valores das Categorias (VLCAT) de "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. Foi implementado na tela Emissão de Carnet (CARNE) para emitir também boletos através botão criado “Emitir Boleto”. Na tela Tipos de Histórico de Garantia (THGAR), foi implementada com a opção "Pagamento por Crédito Financeiro". O histórico de garantia que esteja marcado com esta opção, na tela Histórico de Garantia (HISTG) se selecionado, serão habilitados os campos: Data e Valor do Pagamento do Crédito. A tela Garantias de Produtos (GARAN) foi implementada para exibir o nome do cliente (cadastrado como fornecedor)e não o nome do cupom fiscal com vinha sendo mostrado. A tela Histórico de garantias (HISTG) foi implementada para ser possível adicionar qualquer Histórico de Garantia, também foi implementada uma notificação para datas inválidas e dados de valores do tipo de pagamento “crédito financeiro”. Deverá ser implementada uma Consulta para visualizar a associação de retorno de pagamento de garantia com o fornecedor. Esse tipo de consulta deverá executar também a subtração de contas a receber no módulo financeiro. Para facilitar os cálculos de parcelamentos e juros da renegociação foi solicitado a implementação de melhorias na tela (RENEG), para melhorar o Relatório Movimento Financeiro de Crediário (RMFIN). A tela Gestão de Relacionamento com Cliente (GECRM) foi implementada com filtro para exibir informações de mensagens cadastradas apenas da loja logada . A tela Pedido de Compra de Fornecedor (PEDCO) foi implementada para que seja possível fazer a manutenção do código do fornecedor informado errado, pois atualmente se usuário errar esse código o sistema não permite alteração.

Página | 8

● ● ● ● ●

● ●

● ● ● ●

A tela Entrada de Mercadorias do Fornecedor foi implementada para permitir importar XML de nota com mais de 10 parcelas, sendo possível a importação de até 20 parcelas. Foi efetuada correção no processo de Integração com a Conciliadora Boa Vista, de vendas recebidas com cartão POS. Foi implementada correção no processo de importação de notas e cupons para evitar a importação de notas já importadas e para permitir a importação de notas ou cupons somente na loja em que foi emitida/o. Foi efetuado ajuste da tela Importação de Cupom Fiscal Eletrônico (IMPCF) para que seja possível realizar a importação de NFe e NFC-e. A tela Atualização de Importação de Banco de Dados (REAJF), foi implementada com a função de inclusão de novos produtos a partir da atualização de produtos e geração de código de barras automático além de poder também incluir produtos por loja e por visão de Loja. Efetuada criação do parâmetro 1232 para definir quais os produtos que serão atualizados os preços na tela (REAJF).

A tela recebimento de Pedido de Cliente foi implementada para gerar Nota Fiscal Eletrônica com data de emissão que não coincide com a data do pedido. A tela Recebimento de Pedido de Cliente foi implementada para gerar na Nota Fiscal o código do cliente ao lado do nome dele. Exemplo: José da Silva – 22222. Para que o sistema se comporte dessa maneira o parâmetro 1322(Imprime código do cliente após nome na NF-e?), deverá ter configurado o valor igual "Sim". Implementado uma caixa de informação contendo o aviso de separação, para que não fosse permitida a impressão de pedido com status de reprovados no card de APROVAÇÃO DE CRÉDITOS. A tela Recebimento de Nota Fiscal eletrônica (RECNE) exibida foi implementada com solução para não exibir mais mensagem referente a comando de estrutura de dados na geração de Nota Fiscal Eletrônica. Foi efetuado um reparo na tela de Importação de CT-e(IMPCT), agregando o tratamento dos caracteres especiais (Ex.: &, ^, $) aceitáveis no documento XML que está sendo importado. Foi implementada a correção na importação de CT-e, o processo apresenta uma tag de referência que realiza a verificação dos campos da nota dentro de um grupo “InfOutros” , se a nota referida não contiver dentro desse grupo ela não retorna a série da nota que está sendo transportada e este é o motivo de não conseguir vincular o CT-e a nota emitida no sistema. Efetuada a alteração para corrigir o problema informado, o problema ocorreu por conta de uma tag nova "qrCode" que não estava mapeada no sistema. Foi restaurada a conformidade da tela, tendo em vista que o problema ocorria devido a desatualização do processo por conta do não envio de uma classe que trata uma estrutura de dados. A tela Emitir Etiquetas de Produtos (ETQPD) foi implementada com a ordenação da grid e impressão de etiquetas ordenadas por produtos. Para que a seja feita a ordenação deverá ser configurado com valor “SIM” o parâmetro 1340. Foram modificadas as telas CLIEN (Cadastro de Cliente),CLISP(Cadastro de Cliente Simplificada) e CLIOT(Cadastro de Cliente Ótica) com um CheckBox ao lado de cada telefone celular para indicar se o telefone está habilitado para mensagens WhatsApp. Modificada também a tela (CARNE) para emitir o boleto bancário para título do tipo "CONTRATO".

Página | 9

● ● ● ● ●

● ● ● ● ● ● ● ●

A tela Extrator de Dados (EXTRA) foi implementada para restringir a exibição de informações da lojas e estabelecimentos, nas Consultas Básicas e Customizadas, da loja logada. Efetuada implementação para ao incluir produtos novos a partir da atualização de produtos na transação REAJF, permitir a geração do código de barras automático e incluir a opção de atualização de produtos por visão de lojas. Foi modificada a transação: PEDCO (opções: "Arquivo SABÓ" e "Gerar Arq.Forne") para gravar a quantidade do pedido conforme é impresso no relatório do pedido de compra. Foram implementado as colunas nas transações: COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos, para solucionar a deficiência do pedido. A Devolução de Cliente (DEVOL) foi implementada para calcular o custo da devolução com o mesmo valor de custo utilizado na venda origem. O custo da devolução será o mesmo da venda, quando a operação fiscal de devolução for configurada para "Devolução Cliente usar Preço Custo Venda". Na operação fiscal foi criada a opção para permitir configurar que a devolução de cliente use o preço de custo da venda.

Foram realizados vários testes no ambiente do desenvolvimento e não foi possível simular o problema relatado na descrição da ocorrência, por isso foram liberadas as classes utilizadas nos testes. Efetuada correção na validação dos dados informados para geração da nota complementar, verificado que o erro ocorria ao efetuar uma validação no campo de "Base ICMS ST". Foi criada uma transação interna Preço por Comissão (PRCOM) para informar o percentual de comissão dos produtos por loja, essa será cessada através do botão “Comissão de produto” na tela Preço de Produto por Loja (PROLJ). A tela Inutilização de Cartão presente (INUCP) foi implementada com botão "Alterar Validade" o que permite efetuar a alteração na data de validade do cartão presente. Foi implementada a funcionalidade de download do arquivo no browser. Efetuada correção no cálculo do custo do produto para calcular o custo de acordo com a composição escolhida. Efetuada correção para quando efetuar pagamento com o tipo POS Manual, só mostrar os dados referente a Final do cartão e Venda Offline, se a loja utilizar a comunicação com a ADYEN. Efetuada a reparação do erro, corrigindo a funcionalidade já implementada de download do arquivo no browser.

MENSAGERIA ●

●

Efetuada implementação da NT2020.006 V1.00 e V1.10 que visa a implementação de uma nova tag (Indicador de intermediador/marketplace) que se destina a informar se a operação é: 0=Operação sem intermediador (em site ou plataforma própria); 1=Operação em site ou plataforma de terceiros intermediadores/marketplace). * Foi excluído o meio de pagamento "99-Outros" dos possíveis meios de pagamento para NF-e e NFC-e. Efetuada implementação para enviar automaticamente o xml CF-e autorizado para o email configurado na transação MSPAR, campo "Guarda de XML".

Página | 10

● ●

●

● ● ●

●

Efetuado o tratamento na montagem do XML, para quando o produto tiver dois código GTIN associados, a geração do xml pegará apenas um para geração da nota fiscal, sendo assim não irá duplicar os itens. Efetuada correção no processo de separação do pedido recebido do ecommerce WOOCOMMERCE, quando usado processo de reserva de estoque. O problema ocorre quando o pedido é recebido do ecommerce WOOCOMMERCE e está sendo usado o processo de reserva, o que provocava a incorreta dedução do estoque. Efetuada implementação para quando o parâmetro 879 (Imprimir no DANFE da NF-e a Referência do Fornecedor principal do Produto ou Todas as Referências). Se estiver configurado com o valor "Fornecedor principal": Será impresso somente a referência do fabricante classificada como "Padrão". A tela Mensageria (MSPAR) foi programada para tratar de maneira correta caracteres “especiais”, organizando assim campos e títulos na tela. Foi implementada a função que permite a emissão de notas NFC-e e NF-e no estado do Mato Grosso do Sul. Foi efetuada a implementação de uma função que permite a emissão de notas NFC-e e NF-e no estado do Mato Grosso. Foi realizada uma implementação no sistema para não ocorrer o pedido de solicitação de notas canceladas no sistema, as quais foram delegadas pela SEFAZ. A tela

● Validações de Nota Fiscal (VNOTA) também foi programada para não exibir a mensagem “Nota cancelada no sistema e autorizada na SEFAZ”, quando uma nota estiver cancelada no sistema e denegada na SEFAZ, pois uma nota denegada não está autorizada.

AJUSTES GERAIS ● ● ● ● ● ●

● ●

Foi implementado um processo de validação em forma de exibição de registro do processo de CF-e envolvendo o log do TOMCAT que só poderá ser executado quando o parâmetro 990 estiver setado para “CFE”. Foi implementado Relatório de Títulos Negociados na cobrança (RTCOB), filtros disponíveis (Gerado, Não gerado e Todos). Foram implementados os relatórios COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos comas colunas Quantidade de Itens e Dias de Atraso. Implementar relatório Gerar Arquivos de Importação MTRIX com as seguintes modificações: Criada a tela Interações Nexgen (INTEC), onde será possível integrar pedidos do Ecommerce(somente VTEX) que não integraram no Nexgen por algum motivo excepcional. Implementado uma nova validação para ecommerce VTEX, que, no momento que um pedido é consultado na transação de recebimento de pedido, é verificado se este está cancelado no VTEX, em caso afirmativo, o pedido é automaticamente cancelado no NEXGEN é removido da fila de integração. A QryLivre foi substituída e agora há outra qry responsável por fazer a mesma tarefa que a QryLivre, mas removendo-a e não usando mais uma rotina genérica como acontecia. Geração da classe para corrigir geração "defeituosa" da 68051. Liberação de scripts da Ocorrência 63978: Criando o campo STATUS_DG na tabela GARANTÍAS para gravar o status da garantia: 'F' - Finalizada/Baixada. Foram geradas as classes e após atualização, foi corrigido erro causado pela atualização.

Página | 11

● ● ● ● ● ●

● ● ●

●

● ● ●

● ●

Efetuada correção no processo de impressão, para fechar os objetos abertos durante o processo, evitando assim que o sistema sobrecarregue e venha a ficar travado pela quantidade de objetos abertos em memória. Criada estrutura do banco de dados para correção na integração de preços promocionais na Integração de dados com o SFA Petronas. Correção da ocorrência 69104, referente a erro no valor informado no boleto devido a gravação errada na estrutura de dados em pedidos originados do SFA PETRONAS. O Relatório de Pedidos Emitidos ( RPED) será modificado para exibir no relatório as colunas: Vendedor, valor do crédito, valor do sinal, valor a receber e total faturado. O relatório não será gerado para EXCEL e PDF. O Relatório Relação de Acertos de estoque (RCOAC) foi implementado para ser gerado em formato PDF. O Relatório Analítico de Vendas por Caixa (RAVCX) foi implementado com informações de vendas realizadas com recebimento em PIX. O Relatório Lista de Pedidos de Fornecedor (RIPPED) foi implementado para ser gerado de acordo com os parâmetros informados, o de loja, fornecedor e pedido. O Relatório Itens Devolvidos do Pedido (RIDEV) foi implementado para ser gerado sem duplicação dos registros. O problema relatado na duplicidade de informações no Relatório de caixa (RANCX) foi resolvido após implementação na consulta feita na estrutura de dados.

O Relatório Comissão de Vendedores (RCVEN) foi implementado para não considerar os produtos devolvidos das operações fiscais que atualizam o estoque de garantia. Para que isso aconteça o parâmetro: "Comissão Por Categoria" deverá ser configurado com o valor “SIM” . As telas Consulta Protocolos (COPRO) e Relatório Status dos Protocolos (RSPRO) foram programadas para contar o atraso até a atualização do protocolo e não do fechamento da nota fiscal como estava implementado . O Relatório Inventário Fiscal (RLVFI) foi implementado com alteração na consulta, melhorando performance e evitando travamento do sistema. Para atender à solicitação foram realizadas as seguintes implementações: Criado Relatório de Boletos Gerados (RBNEG), para controle dos títulos enviado para cobrança bancária, esse relatório os seguintes filtros: período e tipo do boleto, e pode ser gerado por: BOLETOS GERADOS, BOLETOS PAGOS (LIQUIDADOS PELO CLIENTE), BOLETOS VENCIDOS (NÃO LIQUIDADOS PELO CLIENTE) e BOLETOS A VENCER. Relatório exibe “ Total de clientes negociados” e “Total de títulos negociados” . O Relatório Inventário Fiscal (RLVFI) foi implementado com alteração na consulta, melhorando a performance e evitando travamento do sistema. A tela Relatório de Faturamento por Categoria (RFATU) foi criada uma tela para selecionar inúmeras categorias, nela foi criado um botão que dará acesso a tela criada que possui categorias a serem selecionadas, o relatório será impresso usando essas informações, caso contrário, será impresso pegando todas as categorias, como anteriormente. O Relatório de Comissão de Vendedores (RCVEN) foi implementado para desconsiderar os valores das devoluções de cliente de operações fiscais com a opção “Garantia Devolução Cliente” marcadas na operação fiscal. Foram inseridos os parâmetros noLocks na chamada das classes Qry de Consulta para possibilitar a atualização da versão do banco de dados.

Página | 12

● ● ●

●

Foram criadas estruturas de dados para armazenar informações referentes ao processo de emissão do boleto dos títulos negociados, e também no cadastro de cliente para identificar se o celular do cliente possui o WhatsApp. Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de Ordem de Serviço Showroom. Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de devolução de cliente, para utilizar o preço de custo origem da venda. Foi criada estrutura no Banco de Dados para guardar informações de itens de pedidos que existiam campos de valores zerados. O cenário atual permite que seja salvo o percentual de desconto e o valor do desconto destes campos.

●

Página | 13

RESUMO QUANTITATIVO

CATEGORIA DAS OCORRÊNCIAS LIBERADAS

QUANTIDADE

NOVAS FUNCIONALIDADES 1

MELHORIAS DE PROCESSO2

OBRIGAÇÕES FISCAIS3

NÃO CONFORMIDADE4

TOTAL

127 1

São novas transações, novos processos ou alterações de processos já existentes, disponibilizadas no ERP através das solicitações dos clientes por PCS. São também funcionalidades disponibilizadas no ERP a critério da Fornecedora. 2

São facilidades criadas para melhorar a usabilidade do usuário nos processos já existentes no ERP ou facilidades para melhor execução dos fluxos de processos integrados. 3

São funcionalidades disponibilizadas no ERP para atendimento da Legislação Vigente aplicável ao segmento de negócio do ERP. 4

São correções de inconsistências presentes nas telas ou resultados insatisfatórios durante a execução de um processo.

Página | 14

FRENTE DE LOJA Processo: Pedido de Cliente de Venda Ocorrência: 69222 Caso: Alterar a tela Pedido de Venda de Cliente (PEDE CV ) para de acordo com parâmetro ser possível a alteração do cliente após a inclusão de uma item no pedido. Melhorias de Processos: A tela de Pedido de Venda de Cliente (PEDCV ) foi implementada com a alteração para fazer uma crítica se o cliente foi alterado após a inclusão do item, essa crítica só será realizada se o parâmetro 15 estiver setado para NÃO. Caso o parâmetro citado (15 ) esteja com valor igual a “SIM” será permitido alteração do cliente após a inclusão de um item no pedido. Ocorrência: 68853 Caso: A tela Pedido de Venda de Cliente (PEDE CV) deverá ser modificada para efetuar o recalculo da política de preço do "pedido juntando" quando for alterado o plano de venda do pedido do cliente. Melhorias de Processos: A tela Pedido de Venda de Cliente (PEDCV) foi implementada para efetuar o recalculo da política de preço do "pedido juntando" quando for alterado o plano de venda do pedido do cliente. Ocorrência: 67998 Caso: Foi solicitado a análise da documentação sobre a ativação de Cartão Presente Gift Card de “Todo Cartões” para integração com Nexgen. Melhorias de Processo: Efetuada implementação para adequar o processo de cartão presente para integrar com a plataforma Todo Cartões do Nexgen. Ocorrência: 68964 Caso: Deverá ser feita a correção no âmbito dos pedidos de vendas à vista, onde atualmente o cenário consta que após o envio pelo LDB o status do pedido fica aberto, causando problemas, onde o cliente fica aguardando a mercadoria que não se encontra no processo de logística da loja. Novas Funcionalidades: Foi implementado um campo “Pedidos c/Divergência na Integração” na tela Consulta Pedido(CPEDC), sua função é listar os pedidos com erro de integração nos processos de LDB e SFA. Foi modificado também o processo de Pedidos a prazo, para que quando ocorra o erro de integração sejam enviados para “Aprovação de Crédito” o que antes não existia. Página | 15

Processo: Recebimento Pedido de Cliente Ocorrência: 70393 Caso: Deverá ser feita a correção no sistema em relação a emissão de nota NF-e ao realizar um pedido com dois itens, o cenário atual trás os itens com seus respectivos valores de venda estão zerados. Não Conformidade: A tela Recebimento Pedido de Cliente, foi implementado para realizar uma verificação de valores. A validação dos valores se dará quando estiver associada a pedido de peças, a modificação foi precisa para identificar possíveis problemas, evitando que o pedido seja recebido e permitindo fazer o seu diagnóstico.

Processo: Recebimento de Pedidos E-commerce Ocorrência: 69926 Caso: Ao efetuar um recebimento de um pedido alguns dados executavam valores divergentes que invalidam a emissão de notas fiscais.

Não Conformidade: Efetuada a correção no processo de recebimento de pedido ecommerce, sendo implementado um processo de validação de valores do pedido, deixando o procedimento mais intuitivo.

Processo: Pedido de Venda Cartão Presente Ocorrência: 68797 Caso: A tela Pedido de Venda Cartão Presente (PEDCP) deverá ser implementada com opção, para permitir usar a matrícula do vendedor no momento de uma venda de cartão presente. Melhorias de Processos: A tela Pedido de Venda Cartão Presente (PEDCP) foi implementada para permitir usar a matrícula do vendedor no momento de uma venda de cartão presente.

Processo: Pedidos de Requisição Ocorrência: 69949 Caso: Ocorrência para resolver o problema dos pedidos de requisição gerados que não vão diretos para separação do WMS por não está com o CD_CRED e TP_FRETE gravados corretamente. Não Conformidade: A rotina de pedido de requisição foi alterada para gravar os

campos CD_CRED e TP_FRETE na DPEDC e TP_PRECO na DIPD corretamente. Página | 16

Processo: Separação Pedidos E-commerce Ocorrência: 70252 Caso: Na Separação do Pedido criado através do e-commerce, o sistema está informando que o produto está com saldo insuficiente, porém o produto está disponível através do e-commerce. Não Conformidade: Efetuada correção no processo de separação do pedido recebido do ecommerce WOOCOMMERCE, quando usado processo de reserva de estoque. O problema ocorre quando o pedido é recebido do ecommerce WOOCOMMERCE e está sendo usado o processo de reserva, o que provocava a incorreta dedução do estoque.

Processo: Processo de Integração Nexgen x Woocomerce Ocorrência: 68995 Caso: Desenvolver a Integração Nexgen com a plataforma Woocommerce, considerando que cliente usa grade de produto. Novas Funcionalidades: Efetuada implementação da comunicação Nexgen com a plataforma WooCommerce, sendo assim o Nexgen irá enviar Categoria, Produto com Grade, Estoque e Preço, e irá receber os pedidos feitos no ecommerce para que seja feito o processo de separação e emissão de nota fiscais. Ocorrência: 68718 Caso: Foi verificado que o produto não está subindo para o site, o produto está ficando com o status de pendente na tela Monitoramento Ecommerce (MECOM). Não Conformidade: Efetuada correção no processo para não validar a descrição do ambiente informado na Integração da Loja, pois no Woocommerce não é obrigatória essa informação. Ocorrência: 69655 Caso: Erro na Integração Nexgen x Woocommerce sistema não estar integrando pedidos da plataforma Woocommerce, exibe mensagem de erro: 346 - atenção! o sistema nexgen não possui DTIPV relacionada a modalidade de pagamento! Não Conformidade: Corrigida a consulta da modalidade de pagamento para não considerar modalidades inativas do momento da integração de pedidos ecommerce; Ocorrência: 70145 Caso: Deverão ser implementadas melhorias na Integração Nexgen x Woocommerce.

Página | 17

Melhorias de Processos: Efetuada alterações do processo de integração com o ecommerce Woocommerce: Proibir a alteração de pedidos integrados do ecommerce; Permitir informar o setor para o produto que estava sem um setor relacionado e foi vinculado a um pedido: Permitir a separação do pedido quando o tipo de loja for igual a 'LOJA' e estiver marcado a flag 'Loja vende no ecommerce': Alterado para quando for selecionado o tipo de entrega ' retirada no local' não será necessário informar uma transportadora. Ocorrência: 69846 Caso: Implementação Integração Nexgen x Woocommerce. Melhorias de Processos: Efetuada alterações do processo de integração com Woocommerce, para enviar para o ecommerce a referência interna do Nexgen, para quando consultar o site, ser possível fazer uma relação do produto no site com o produto no Nexgen através do código interno.

Processo: Nexgen Mobile - Interface de Pedido de Ótica Ocorrência: 67436 Caso: Criar interface do pedido de ótica para uso em dispositivos móveis. Novas Funcionalidades: Foi implementada a Interface do Nexgen para dispositivos móveis, que contempla o Pedido de Cliente de Venda de Ótica. Ocorrência: 68051 Caso: Criar na Interface do Pedido de Ótica do Nexgen Mobile o processo de Receita Digital. Novas Funcionalidades: Foi implementada na Interface do Pedido de Ótica do Nexgen Mobile as seguintes melhorias: Criação de tela simplificada para cadastro de clientes: A nova tela deverá ser utilizada em dispositivo móvel que será disponibilizado ao cliente para que ele faça seu cadastro. Paralelamente a isso o vendedor utilizará a tela de Pedido de venda de Cliente de Ótica (PEDCV) em seu tablet para gerar o pedido de venda. Os Botões da Tela são : “Incluir” utilizado para gerar o código do cliente no cadastro; “Finalizar cadastro” utilizado para gravar no código do cliente os outros dados restantes; “Consultar” utilizado para consultar um cliente quando o campo de CPF estiver preenchido.

Processo: Login – Nexgen Mobile Ocorrência: 69108

Página | 18

Caso: Após atualização de patch que liberou classes com parâmetro de noLock, o ambiente do Nexgen móvel parou de funcionar. Não Conformidade: Foram geradas as classes e atualizadas para correção do ambiente do Nexgen móvel que havia parado de funcionar.

Processo: Pedido de Venda de Cliente de Ecommerce Ocorrência: 69819 Caso: Implementar o envio de preço e estoque para o E-Commerce, quando o produto já existir e for configurado para disponível para o E-commerce. Melhorias de Processos: A tela Cadastro de Produtos (PRODU) foi implementada para enviar para o E-Commerce preço e estoque, quando o produto for configurado para “Disponível para E-commerce” . Esta situação ocorre quando o produto já existe no cadastro e foi modificado para disponível para o E-Commerce. Para ativar o produto para disponível para o E-Commerce, acesse a tela Cadastro de Produtos (PRODU) e clique no botão "Parâmetros".

Processo: Nota Fiscal Faturamento e Remessa – Entrega Futura Ocorrência: 66095 Caso: O sistema não emitia Notas Simples Faturamento Remessa – Entrega Futura. Novas Funcionalidades: O sistema foi implementado para emitir Notas Simples Faturamento e Remessa - Entrega Futura. Para isso, foram criadas as seguintes opções: Na tela Estados (ESTAD) campo para indicar a observação que deverá sair na nota de Simples Faturamento, pois muda de acordo com o estado; Na tela de Operação Fiscal (OPFIS) foram programados os campos de CFOP Simples Fat.Remessa Interno e Externo que indicará os CFOP’s das notas de Simples Faturamento e Remessa - Entrega Futura de acordo com Norma Técnica, também foi criado no novo campo que será utilizado para indicar a nova Natureza da Nota de Simples Faturamento. Como melhorias também foi implementado na tela Consulta Nota Fiscal de Saída (CNFSD) um tipo de nota = "Simples Faturamento", caso se selecionado esta opção, serão exibidas as notas emitidas de Simples Faturamento. Por fim na tela Relação Geral das Saídas (RGSAI) também teve inserido um tipo de nota = "Simples Faturamento", caso se selecionado esta opção, serão listadas as notas emitidas de Simples Faturamento.

Página | 19

Processo: Pedido de Venda ao Cliente – Integração SFA Ocorrência: 69779 Caso: Existe uma inconsistência na transação de Pedidos de Venda ao Cliente (PEDCV), ao realizar uma venda deve-se cadastrar uma observação de SFA nas informações do pedido e atualmente essas observações não estão sendo gravadas no sistema Nexgen. Melhorias de Processos: Implementada a gravação da observação vinda de pedidos do SFA.

ÓTICA Processo: Pedido de Venda de Cliente de Ótica Ocorrência: 69683 Caso: Em alguns pedidos de óticas, a lente não está sendo impressa no pedido sendo impressa apenas na Ordem de Serviço. Não Conformidade: O problema no pedido de ótica acontece porque a consulta de leitura dos produtos do pedido estava com um argumento errado e com isso não retornava todos os produtos. Após correção, o problema foi corrigido.

Processo: Consulta de Ordem de Serviço Ocorrência: 70288 Caso: Ao ser impressa agora abaixo do código de barras, encontra-se o número da OS como solicitado. Melhorias de Processo: Foi implementada a impressão do código da Ordem de Serviço abaixo do código de barras.

Processo: Envio de Malote, confirmação por SMS Ocorrência: 70022 Caso: Foi cometido um erro no recebimento do malote, no envio do SMS, este erro foi corrigido e melhorado, possibilitando ao cliente não passar mais por evitação de envio. Foi feito também uma melhoria na análise do processo, que agora efetua mais gravações na tabela sobre a comunicação com a InfoBip. Melhorias de Processo: Efetuada correção no processo de envio de SMS para InfoBip, melhorando o processo para evitar que um erro no envio do SMS para o Página | 20

processo da OS, melhorando também a análise do processo, efetuando mais gravações na tabela sobre a comunicação com a InfoBip.

Processo: Cadastro de Ordem de Serviços para Retificação Ocorrência: 67800 Caso: A tela Cadastro de Ordem de Serviço para Retificação (OSRET) estava permitido cancelar a OS Original. Não Conformidade: A tela Cadastro de Ordem de Serviço para Retificação (OSRET) foi programada para não permitir o cancelamento da OS Original.

Processo: Geração de Malote na Loja Ocorrência: 68434 Caso: A tela Geração de Malote na Loja (GERLJ) está apresentando um erro intermitente ao gerar malote, que contém item do tipo armação, com estoque na conta disponível, porém o sistema informa que não há. Não Conformidade: A tela Geração de Malote na Loja (GERLJ) foi implementada para remoção dos dados da quantidade dos produtos ao fim da sessão, corrigindo assim o problema de estoque do item armação ao gerar malote.

Ocorrência: 68373 Caso: Na geração e recebimento do malote o sistema só movimentava o estoque físico dos produtos da OS. Melhorias de Processos: Foi criado o parâmetro 1506 para determinar se o estoque reserva deverá ser movimentado juntamente com o estoque físico na geração e recepção do malote. Os produtos que serão movimentados são os produtos que não são lentes e nem serviços. Isso ocorreu se o parâmetro foi colocado para "Sim".

Processo: Ordem de Serviço Showroom Ocorrência: 69101 Caso: Deverá ser as seguintes melhorias no processo de Ordem de Serviço Showroom. Estoque mínimo ou fator na geração da O.S e quando estoque disponível for menor que o da OS Showroom, ela será alterada para uma OS do Fluxo Normal. O sistema deverá tratar automaticamente e separadamente os malotes abertos que são de OS Showroom. Melhorias de Processos: Foi implementado o estoque mínimo ou fator na geração da OS Showroom. Foi criado o parâmetro 1505 para informar a quantidade mínima ou fator do estoque da OS Showroom. Esse parâmetro informado será subtraído do Página | 21

estoque disponível das armações da OS Showroom no laboratório. E quando o estoque disponível for menor que o da OS Showroom, ela será alterada para uma OS do Fluxo Normal. Também, foi alterado o processo de geração de malote para o sistema que trata automaticamente e separadamente os malotes abertos que são de OS Showroom e que não são para a mesma loja.

RETAGUARDA Processo: Atualização de Protocolo (ESTOQUE) Ocorrência: 69475 Caso: A tela Atualização de Protocolo (ATUES) está exibindo mensagem de erro na hora de atualizar o lote. Não Conformidade: A tela Atualização de Protocolo (ATUES) foi implementada para que, nesse caso, o sistema exiba uma mensagem indicando o Lote, Protocolo, Nota e Fornecedor para direcionar o problema. Ocorrência: 69420 Caso: A tela Atualização de Protocolo (ATUES) não está exibindo a quantidade convertida, conforme a tabela de importação do coletor. Não Conformidade: A tela Atualização de Protocolo (ATUES) foi implementada para ao consultar pelo protocolo o campo quantidade convertida. Foi alterado para se comportar tanto o lote, como protocolo da mesma forma.

Processo: Monitoramento Ecommerce Ocorrência: 69634 Caso: Pendências de comunicação, e os itens não estão sendo importados para a plataforma ecommerce MAGENTO. Não Conformidade: Corrigido um problema de “NullPointerException” gerado pela atualização.

Processo: Manter Divergência de Protocolo Ocorrência: 69586 Caso: A tela Manter Divergência de Protocolo(MDPTC ) está exibindo os as pendências resolvidas ainda como pendentes. Não Conformidade: A tela Manter Divergência de Protocolo(MDPTC ) foi implementada com o procedimento correto a ser seguido para exibir as pendências resolvidas.

Página | 22

Processo: Recebimento de Pedido Contra Entrega Ocorrência: 69335 Caso: Alterar a tela Recebimento de Pedido Contra Entrega (RECEN ) para que esta transação possa fazer o recebimento dos pedidos com a modalidade de contra entrega que foram faturados em qualquer caixa, e não somente no caixa de faturamento do mesmo pedido. Melhorias de Processos: A tela Recebimento de Pedido Contra Entrega (RECEN ) foi implementada para o recebimento dos pedidos com a modalidade de contra entrega que foram faturados em qualquer caixa, e não somente no caixa de faturamento do mesmo pedido.

Processo: implementação Rest API – Mensagens WhatsApp Ocorrência: 68948 Caso: Implementação das chamadas REST API para verificação de cliente, consulta e geração de boleto, a ser utilizada pelo sistema de troca de mensagens por WhatsApp. Novas Funcionalidades: Foi implementado o sistema de tempo de vida do token de autenticação para as chamadas REST API, caso não seja configurado, o token será válido indefinidamente. A configuração é realizada somente a nível de banco, no campo DSEPG.AUTENTICACAO_VALIDADE, que deve ser preenchido com um valor numérico inteiro correspondente ao número de dias de vida do TOKEN; - Também foi implementado um serviço para limpeza do diretório de download dos boletos gerados para o processo, para evitar acúmulo de arquivos, que apaga arquivos com mais de dois dias de criação e roda no início do Tomcat e a cada 16 horas; - Os novos parâmetros 621 e 622 devem ser configurados para o correto funcionamento do processo de geração e download dos boletos. -- O parâmetro 621 deve ser configurado com o caminho do diretório local onde serão gravados os arquivos de boletos para o download; -- O parâmetro 622 deve ser configurado com o endereço externo de rede que aponta para o diretório configurado no parâmetro 621 a fim de realizar os downloads dos arquivos de boletos. - ATENÇÃO, o diretor do parâmetro 621 deve estar num contexto e local diferente do Nexgen, por motivos de SEGURANÇA E PERFORMANCE !!!

Processo: Devolução de Pedido de Cliente Ocorrência: 68798 Caso: Quando ia fazer a devolução de uma venda que teve frete, o sistema sempre considerava o rateio do frete dos itens que estavam sendo devolvidos e nem sempre as notas

Página | 23

de devoluções possuíam frete, o que gerava uma divergência entre a nota física e a nota existente no sistema. Melhorias de Processos: Foi criado, na tela de Devolução de Venda, um cheque "Zerar Frete", que permitirá que o frete da nota de venda seja zerado, na nota de devolução quando essa não tiver o frete da venda. O frete poderá ser zerado para nota toda, quando a devolução é emitida pela própria loja com base na nota de venda ou para nota toda ou para alguns itens quando for dada entrada na devolução emitida pelo cliente.

Ocorrência: 68459 Caso: A tela Devolução de Pedido de Cliente (DEVOL) deverá ser implementada com a opção para ser possível utilizar a matrícula no campo do código do vendedor . Melhorias de Processo: A tela Devolução de Pedido de Cliente (DEVOL) foi implementada com opção para possível utilizar a matrícula no campo do código do vendedor .Para que o sistema se comporte dessa maneira será preciso que o parâmetro 671 (Solicitar a Matrícula do Vendedor na Devolução) esteja setado como "SIM".

Processo: Valores por Categorias Ocorrência: 69527 Caso: Desenvolver opção na tela de Valores das Categorias (VLCAT) de "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. Novas Funcionalidades: Foi implementada na tela de Valores das Categorias (VLCAT) , a opção: "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. Ocorrência: 69532 Caso: Desenvolver opção na tela de Valores das Categorias (VLCAT) de "Desconto Máximo", para definir o percentual máximo de desconto da categoria para cada loja. Novas Funcionalidades: Foram implementadas as seguintes melhorias: Na transação: VLCAT-Valores das Categorias: a) Criados campos para informar a Premiação em valor ou percentual a nível de categoria; b) Criado opção: "Premiação por Loja", para informar a Premiação em valor ou percentual da categoria por loja. Também na tela Produto na Loja (PROLJ), criado opção: "Premiação Loja", para informar a Premiação em valor ou percentual. Na tela Comissão de Vendedores (RCVEN), foi criado parâmetro: Realizada alterações nas estruturas de dados para alocar informações, "Exibir Premiação". Caso este parâmetro seja selecionado será exibidos os valores da premiação.

Processo: Emissão de Carnet Ocorrência: 69814 Página | 24

Caso: Desenvolver a tela Emissão de Carnê (CARNE) para emitir também boletos. Novas Funcionalidades: Foi implementado na tela Emissão de Carnê (CARNE) para emitir também boletos através botão criado “Emitir Boleto”.

Processo: Históricos de Garantias Ocorrência: 69610 Caso: A tela Histórico de Garantia (HISTG) quando usuário informar o histórico de pagamento por crédito financeiro, sistema deverá exigir o valor e a data desse pagamento. Melhorias de Processos: Na tela Tipos de Histórico de Garantia (THGAR), foi implementada com a opção "Pagamento por Crédito Financeiro". O histórico de garantia que esteja marcado com esta opção, na tela Histórico de Garantia (HISTG) se selecionado, serão habilitados os campos: Data e Valor do Pagamento do Crédito. Ocorrência: 69609 Caso: A tela Garantias de Produtos (GARAN) deverá passar a exibir o nome do cliente (cadastrado como fornecedor)e não o nome do cupom fiscal Melhorias de Processos: A tela Garantias de Produtos (GARAN) foi implementada para exibir o nome do cliente (cadastrado como fornecedor)e não o nome do cupom fiscal com vinha sendo mostrado. Ocorrência: 63978 Caso: Deverão ser implementados novos recursos no sistema para facilitar o mapeamento dos relatórios na tela Relatório de Garantias por Período( RGAPE). Novas Funcionalidades: Para atender à solicitação foram realizadas as seguintes implementações: à Na tela Tipos de Histórico de Pagamento (THGAR), foi implementado campo "Histórico de Encerramento da DG", caso o histórico esteja com este campo marcado, irá sinalizar que este histórico é de "Encerramento/Finalização da DG". à Na tela Garantia de Produtos (GARAN), selecionada a partir da tela Histórico de Garantias (HISTG), foi implementado que na "inclusão do histórico", caso o "HISTÓRICO" selecionado esteja marcado como "Histórico de Encerramento da DG", a DG(garantia) será atualizado o status como "Fechada". Após a DG ser encerrada não será permitida a inclusão de novos históricos, caso o usuário tente incluir um novo histórico será exibida a mensagem "Garantia já Finalizada". À tela Relatório de Garantias por Período( RGAPE), foi adicionado um parâmetro: “Status da DG”, com as opções: Todas/Abertas/Fechadas-Baixadas. Também foi acrescentado as colunas: Status DG , Último Histórico e Doc.Dev.Forne. Página | 25

Ocorrência: 70220 Caso: A tela Histórico de garantias (HISTG) não está permitindo a inclusão de um novo histórico de garantia. Não Conformidade: A tela Histórico de garantias (HISTG) foi implementada para ser possível adicionar qualquer Histórico de Garantia, também foi implementada uma notificação para datas inválidas e dados de valores do tipo de pagamento “crédito financeiro”.

Processo: Digitação da Garantia Ocorrência: 69590 Caso: Deverá ser implementada uma Consulta para visualizar a associação de retorno de pagamento de garantia com o fornecedor. Esse tipo de consulta deverá executar também a subtração de contas a receber no módulo financeiro. Novas Funcionalidades: Foi implementado a função de adiantamento ao fornecedor na tabela de garantias, isso fará com que o processo de devolução do produto seja atualizado. Nas operações fiscais de "DEVOLUÇÃO AO FORNECEDOR DE GARANTIA", que no cenário atual estão selecionados os campos: "Movimenta Histórico Garantia" e "Gerar Crédito e Devolução". Caso estes campos estejam marcados, será associado na emissão da nota fiscal a número do adiantamento gerado a garantia do produto. Nas operações fiscais de "ENTRADA DE MERCADORIA DE GARANTIA" com o campo: "Movimenta Histórico Garantia" selecionado, será realizado os processos de atualizar o saldo do adiantamento do fornecedor e gerar baixa do adiantamento com base no valor do produto.

Processo: Renegociação de Títulos Ocorrência: 68281 Caso: Para facilitar os cálculos de parcelamentos e juros da renegociação foi solicitado a implementação de melhorias na tela (RENEG), para melhorar o Relatório Movimento Financeiro de Crediário (RMFIN). Novas Funcionalidades: Na tela Renegociação de Títulos (RENEG) foi implementado campo "Juros" , para exibir o valor dos juros calculado na Renegociação.

Processo: Gestão de Relacionamento com Cliente Ocorrência: 69034

Página | 26

Caso: A tela Gestão de Relacionamento com Cliente (GECRM) deverá ser implementada com filtro para exibir informações de mensagens cadastradas apenas da loja logada . Melhorias de Processos: A tela Gestão de Relacionamento com Cliente (GECRM) foi implementada com filtro para exibir informações de mensagens cadastradas apenas da loja logada .

Processo: Pedido de Compra de Fornecedor Ocorrência: 69828 Caso: A tela Pedido de Compra de Fornecedor (PEDCO) deverá ser implementada para que seja possível fazer a manutenção do código do fornecedor informado errado, pois atualmente se usuário errar esse código o sistema não permite alteração. Melhorias de Processos: A tela Pedido de Compra de Fornecedor (PEDCO) foi implementada para que seja possível fazer a manutenção do código do fornecedor informado errado, pois atualmente se usuário errar esse código o sistema não permite alteração.

Processo: Entrada de Mercadorias do Fornecedor Ocorrência: 696918 Caso: A tela Entrada de Mercadorias do Fornecedor importar XML de nota fiscal com mais de 10 parcelas.

não estava permitindo

Melhorias de Processos: A tela Entrada de Mercadorias do Fornecedor foi implementada para permitir importar XML de nota com mais de 10 parcelas, sendo possível a importação de até 20 parcelas.

Processo: Integração Conciliação de Cartão Ocorrência: 68923 Caso: Ocorria inconformidade ao executar a tela Integração Conciliação de Cartão (INTCC). Não Conformidade: Foi efetuada correção no processo de Integração com a Conciliadora Boa Vista, de vendas recebidas com cartão POS.

Processo: Importação de Cupom Fiscal Eletrônico Ocorrência: 70119 Página | 27

Caso: A tela Importação de Cupom Fiscal Eletrônico (IMPCF) estava permitindo a importação de cupons e notas que já haviam sido importados. Não Conformidade: Foi implementada correção no processo de importação de notas e cupons para evitar a importação de notas já importadas e para permitir a importação de notas ou cupons somente na loja em que foi emitida/o. Ocorrência: 69767 Caso: Ajustar a tela Importação de Cupom Fiscal Eletrônico (IMPCF) para que seja possível realizar a importação de NFe e NFC-e. Melhorias de Processos: Foi efetuado ajuste da tela Importação de Cupom Fiscal Eletrônico (IMPCF) para que seja possível realizar a importação de NFe e NFC-e.

Processo: Importação Arquivo do Fornecedor Ocorrência: 69685 Caso: Deverá ser implementada uma função onde seja possível realizar o cadastro de produto por meio da importação de planilhas eletrônicas disponibilizadas pelos fornecedores , os códigos de barras devem importar os dados a partir dessas planilhas. Pede-se que essa funcionalidade cadastre o produto com o código sequencial e seja possível cadastrar e gerar o código de barras. Também deverá reajustar preços por lojas e por visão de lojas. Melhorias de Processos: A tela Atualização de Importação de Banco de Dados (REAJF), foi implementada com a função de inclusão de novos produtos a partir da atualização de produtos e geração de código de barras automático além de poder também incluir produtos por loja e por visão de Loja. Efetuada criação do parâmetro 1232 para definir quais os produtos que serão atualizados os preços na tela (REAJF).

Processo: Recebimento de Pedido de Cliente Ocorrência: 69447 Caso: A tela Recebimento de Pedido de Cliente ao receber um pedido e gerar Nota Fiscal Eletrônica está gravando da data de emissão que não coincide com a data do pedido. Não Conformidade: A tela recebimento de Pedido de Cliente foi implementada para gerar Nota Fiscal Eletrônica com data de emissão que não coincide com a data do pedido. Ocorrência: 69966

Página | 28

Caso: A tela Recebimento de Pedido de Cliente deverá ser implementada para gerar na Nota Fiscal o código do cliente ao lado do nome dele. Exemplo: José da Silva 22222 Melhorias de Processos: A tela Recebimento de Pedido de Cliente foi implementada para gerar na Nota Fiscal o código do cliente ao lado do nome dele. Exemplo: José da Silva – 22222. Para que o sistema se comporte dessa maneira o parâmetro 1322(Imprime código do cliente após nome na NF-e?), deverá ter configurado o valor igual "Sim". Ocorrência: 68698 Caso: Deverá ser implementada uma funcionalidade que permita informar o status de aprovado/reprovado no âmbito do recebimento de pedido. Atualmente o cenário permite que pedido reprovados passe pela separação e conferência, mas para o faturamento. Novas Funcionalidade: Implementado uma caixa de informação contendo o aviso de separação, para que não fosse permitido a impressão de pedido com status de reprovados no card de APROVAÇÃO DE CRÉDITOS. Ocorrência: 70221 Caso: A tela Recebimento de Nota Fiscal eletrônica (RECNE) exibe mensagem de erro ao gerar nota fiscal eletrônica . Não Conformidade: A tela Recebimento de Nota Fiscal eletrônica (RECNE) exibe foi implementada com solução para não exibir mais mensagem referente a comando de estrutura de dados na geração de Nota Fiscal Eletrônica.

Processo: Importação do CT-e Ocorrência: 70045 Caso: Não é possível realizar a importação de uma nota CT-e, ao realizar essa importação é executada uma mensagem de erro. Melhorias de Processo: Foi efetuado um reparo na tela de Importação de CT-e(IMPCT), agregando o tratamento dos caracteres especiais (Ex.:\, ^, $) aceitáveis no documento XML que está sendo importado. Ocorrência: 70366 Caso: Está ocorrendo uma não conformidade na Importação de CT-e (IMPCT), o XML gerado importa dados inexistentes na loja referida Melhorias de Processo: Foi implementada a correção na importação de CT-e, o processo apresenta uma tag de referência que realiza a verificação dos campos da nota dentro de um grupo “InfOutros” , se a nota referida não contiver dentro desse Página | 29

grupo ela não retorna a série da nota que está sendo transportada e este é o motivo de não conseguir vincular o CT-e a nota emitida no sistema. Ocorrência: 70366 Caso: Está ocorrendo uma não conformidade na Importação de CT-e (IMPCT), sistema apresenta a "Problema ao Efetuar a Importação do CT-e, favor contactar a Secrel". Não Conformidade: Efetuada a alteração para corrigir o problema informado, o problema ocorreu por conta de uma tag nova "qrCodCTe" que não estava mapeada no sistema.

Processo: Emissão de Etiquetas do Produto Ocorrência: 70347 Caso: Ao emitir uma etiqueta de um produto com filtro selecionando Nota Fiscal de Entrada o sistema emite uma mensagem de erro impossibilitando assim a emissão. Não Conformidade: Foi restaurada a conformidade da tela, tendo em vista que o problema ocorria devido a desatualização do processo por conta do não envio de uma classe que trata uma estrutura de dados. Ocorrência: 69287 Caso: A tela Emitir Etiquetas de Produtos (ETQPD) etiquetas e produtos são exibidos desordenados no grid da tela. Melhorias de Processos: A tela Emitir Etiquetas de Produtos (ETQPD) foi implementada com a ordenação da grid e impressão de etiquetas ordenadas por produtos. Para que a seja feita a ordenação deverá ser configurado com valor “SIM” o parâmetro 1340.

Processo: Manutenção de Cliente Ocorrência: 69541 Caso: Solicitação de implementação de ajustes no NEXADM e NEXGEN para a geração de boletos. Novas Funcionalidades: Foram modificadas as telas CLIEN (Cadastro de Cliente),CLISP(Cadastro de Cliente Simplificada) e CLIOT(Cadastro de Cliente Ótica) com um CheckBox ao lado de cada telefone celular para indicar se o telefone está habilitado para mensagens WhatsApp. Modificada também a tela (CARNE) para emitir o boleto bancário para título do tipo "CONTRATO".

Página | 30

Processo: Extrator de Dados Ocorrência: 68435 Caso: A tela Extrator de Dados (EXTRA) está permitindo a consulta de outros estabelecimentos, o correto é o extrator somente mostrar as lojas referente ao estabelecimento logado. Não Conformidade: A tela Extrator de Dados (EXTRA) foi implementada para restringir a exibição de informações das lojas e estabelecimentos, nas Consultas Básicas e Customizadas, da loja logada.

Processo: Implementação de recursos novos Ocorrência: 69685 Caso: Implementação de inclusão de novos produtos após as atualizações da transação REAJ. O sistema agora permite a criação dos códigos de barras de forma automática, a mesma, agora também inclui a opção de atualização de produtos por visualização de lojas. Novas Funcionalidades: Efetuada implementação para ao incluir produtos novos a partir da atualização de produtos na transação REAJF, permitir a geração do código de barras automático e incluir a opção de atualização de produtos por visão de lojas.

Processo: MODIFICAÇÕES E IMPLEMENTAÇÕES Ocorrência: 68170 Caso: A quantidade informada no arquivo pdf (MENU Gerar arq. Forne.) agora está de acordo com os dados da planilha gerada pelo MENU Arquivo SABÓ, que considera a quantidade do produto de acordo com o fator 2 (multiplicador), no cadastro do produto. Melhorias de Processo: Foi modificada a transação: PEDCO (opções: "Arquivo SABÓ" e "Gerar Arq.Forne") para gravar a quantidade do pedido conforme é impresso no relatório do pedido de compra. Ocorrência: 69157 Caso: Foi acrescido novos recursos nas transações: COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos para que o cliente possa obter as informações solicitadas na descrição da ocorrência. Novas Funcionalidades: Foram implementadas as colunas nas transações: COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos, para solucionar a deficiência do pedido.

Processo: Devolução de Pedido de Cliente Ocorrência: 69455 Página | 31

Caso: A Devolução de Cliente (DEVOL) utilizava o preço de custo da devolução, com base no custo calculado na última entrada de mercadoria ou o custo informado na tela Produtos por Loja (PROLJ). Novas Funcionalidades: A Devolução de Cliente (DEVOL) foi implementada para calcular o custo da devolução com o mesmo valor de custo utilizado na venda original. O custo da devolução será o mesmo da venda, quando a operação fiscal de devolução for configurada para "Devolução Cliente usar Preço Custo Venda". Na operação fiscal foi criada a opção para permitir configurar que a devolução de cliente use o preço de custo da venda. Ocorrência: 69418 Caso: Em ambiente de teste o Produto exibido na PDCV não se comportou da maneira que o solicitante descreveu, ou seja, o percentual de desconto referente a política de preço foi omitido de acordo com o processo do pedido. Não Conformidades: Foram realizados vários testes no ambiente do desenvolvimento e não foi possível simular o problema relatado na descrição da ocorrência, por isso serão liberadas as classes utilizadas nos testes.

Processo: Validação dos Dados Ocorrência: 70038 Caso: Ajuste no campo de “Base ICMS ST” pois quando digitava os dados dessa nota o sistema estava dando erro quando. Mas o campo foi validado, o que ocasionava isto era a validação deste campo citado acima. Melhorias de Processos: Efetuada correção na validação dos dados informados para geração da nota complementar, verificando que o erro ocorreu ao efetuar uma validação no campo de "Base ICMS ST".

Processo: Preço de Produto por Loja Ocorrência: 69529 Caso: Solicitamos que seja criada tela para informar comissão de preço de produto por loja. Melhorias de Processos: Foi criada uma transação interna Preço por Comissão (PRCOM) para informar o percentual de comissão dos produtos por loja, essa será acessada através do botão “Comissão de produto” na tela Preço de Produto por Loja (PROJ).

Processo: Inutilização de Cartão Presente Ocorrência: 68779

Página | 32

Caso: Solicitamos que na tela Inutilização de Cartão presente (INUCP) seja possível fazer alteração do vencimento do cartão presente. Melhorias de Processos: A tela Inutilização de Cartão presente (INUCP) foi implementada com botão "Alterar Validade" o que permite efetuar a alteração na data de validade do cartão presente.

Processo: Gerar Arquivo para NAPP Ocorrência: 69004 Caso: Deverá ser implementado sistema NEXGEN, para receber as informações de vendas e restabelecer as coletas. O objetivo dessa ação é manter a coleta automática e diária, facilitando as informações entre a rede, o shopping e o lojista. Além de contribuir com informações necessárias para possíveis ações de marketing dentro do shopping. Melhorias de Processos: Foi implementado a funcionalidade de download do arquivo no browser.

Processo: Entrada de Mercadorias ao Fornecedor Ocorrência: 68986 Caso: Quando efetuada a Entrada de Mercadorias ao Fornecedor com notas de conta com ICMS ST Complementar, sistema está calculando o custo do produto de maneira indevida. Não Conformidade: Efetuada correção no cálculo do custo do produto para calcular o custo de acordo com a composição escolhida.

Processo: Informações de Cartão Ocorrência: 69597 Caso: Corrigir a pop-up Informações de Cartão (INFCA )para só exibir as informações solicitadas pela integração Adyen quando estiver habilitado o uso da Adyen. Não Conformidade: Efetuada correção para quando efetuar pagamento com o tipo POS Manual, só mostrar os dados referente a Final do cartão e Venda Offline, se a loja utilizar a comunicação com a ADYEN.

Processo: Gerar Arquivo para NAPP Ocorrência: 70465 Caso: Foi detectado pelo desenvolvimento um erro no sistema, no qual o cliente não conseguiria gerar e nem baixar arquivos de NAPP diretamente do browser. Página | 33

Não Conformidade: Efetuada a reparação do erro, corrigindo a funcionalidade já implementada de download do arquivo no browser.

MENSAGERIA Processo: Nota Técnica 2020.006 - v.1.00 Ocorrência: 69083 Caso: Nota Técnica 2020.006 - v.1.00 - Publicada em 24/09/2020 - Republicada em 28/09/20. Divulga a criação/alteração de campos e regras de validação envolvendo intermediador e agenciador de transação comercial. Obrigações Fiscais: Efetuada implementação da NT2020.006 V1.00 e V1.10 que visa a implementação de uma nova tag (Indicador de intermediador/marketplace) que se destina a informar se a operação é: 0=Operação sem intermediador (em site ou plataforma própria); 1=Operação em site ou plataforma de terceiros intermediadores/marketplace). * Foi excluído o meio de pagamento "99-Outros" dos possíveis meios de pagamento para NF-e e NFC-e.

Processo: Envio XML Cofre Sieg – CFE/SAT Ocorrência: 69538 Caso: Desenvolver operação da Mensageria ( MSPAR) para enviar as notas automaticamente para o “COFRE SIEG” o XML das notas CFE/SAT - MF-E. Novas Funcionalidades: Efetuada implementação para enviar automaticamente o xml CF-e autorizado para o email configurado na transação MSPAR, campo "Guarda de XML". Ocorrência: 68366 Caso: XML da nota não está sendo gerado em conformidade quando o produto tiver dois código GTIN associados. Não Conformidade: Efetuado o tratamento na montagem do XML, para quando o produto tiver dois código GTIN associados, a geração do xml pegará apenas um para geração da nota fiscal, sendo assim não irá duplicar os itens. Ocorrência: 70252 Caso: Foi identificamos que os produtos de pedidos criados através do e-commerce estavam ficando com status de reservado, porém o sistema não está identificando que o produto pertence ao pedido criado. Para isso foi realizada a correção no processo de separação do pedido. Melhorias de Processos: Efetuada correção no processo de separação do pedido recebido do ecommerce WOOCOMMERCE, quando usado processo de reserva de Página | 34

estoque. O problema ocorre quando o pedido é recebido do ecommerce WOOCOMMERCE e está sendo usado o processo de reserva, o que provocava a incorreta dedução do estoque.

Processo: Nota Fiscal Eletrônica ao Consumidor Ocorrência: 68191 Caso: Na Fiscal Eletrônica do tipo NFC-e está sendo impresso somente um código de fabricante, é para ser impresso todos os códigos de fabricantes possíveis na mesma linha. Não Conformidade: Efetuada implementação para quando o parâmetro 879 (Imprimir no DANFE da NF-e a Referência do Fornecedor principal do Produto ou Todas as Referências). Se estiver configurado com o valor "Fornecedor principal": Será impresso somente a referência do fabricante classificada como "Padrão". Se estiver configurado com o valor "Fabricantes", será impresso no danfe NFC-e, todas as referências, iniciando pela referência classificada como "Padrão" do fabricante para o produto vendido. O PROCESSO IMPLEMENTADO NESTA OCORRÊNCIA ATENDE APENAS AO MODELO "65" - NFC-e. Ocorrência: 70384 Caso: A tela Mensageria (MSPAR) não estava tratando alguns caracteres “especiais”, desorganizando assim campos e títulos na tela. Não Conformidade: A tela Mensageria (MSPAR) foi programada para tratar de maneira correta caracteres “especiais”, organizando assim campos e títulos na tela.

Processo: Emissão de Notas - NF-e e NFC-e Ocorrência: 70587 Caso: Deve-se habilitar a importação de notas fiscais do tipo NFC-e e NF-e da Mensageria, especificamente no cliente do estado do Mato Grosso do Sul. Nova Funcionalidades: Foi implementada a função que permite a emissão de notas NFC-e e NF-e no estado do Mato Grosso do Sul. Ocorrência: 70588 Caso: Deve-se habilitar também a importação de notas fiscais do tipo NFC-e e NF-e da Mensageria, especificamente no cliente do estado do Mato Grosso. Nova Funcionalidades: Foi efetuada a implementação de uma função que permite a emissão de notas NFC-e e NF-e no estado do Mato Grosso. Página | 35

Processo: Validações de Nota Fiscal Ocorrência: 70361 Caso: O sistema encontra-se mostrando notas denegadas com notas pendentes de inutilização, ou seja, o cenário atual executa as notas que já foram denegadas ou canceladas, fazendo com que as notas já inutilizadas fiquem como denegadas a inutilizar. Melhorias de Processos: Foi realizada uma implementação no sistema para não ocorrer o pedido de solicitação de notas canceladas no sistema, as quais foram delegadas pela SEFAZ. A tela Validações de Nota Fiscal (VNOTA) também foi programada para não exibir a mensagem “Nota cancelada no sistema e autorizada na SEFAZ”, quando uma nota estiver cancelada no sistema e denegada na SEFAZ, pois uma nota denegada não está autorizada.

AJUSTES GERAIS Processo: Log’s TomCat – MonitorPDV2.4.2 Ocorrência: 68216 Caso: Retirar traços do log do Tomcat inseridos pelo monitor, no processo de emissão de CF-e e comunicação Socket servidor x monitor. O trace será inserido no Log do Tomcat se o parâmetro 990 estiver configurado com o conteúdo 'CFE'. Melhorias de Processo: Foi implementado um processo de validação em forma de exibição de registro do processo de CF-e envolvendo o log do TOMCAT que só poderá ser executado quando o parâmetro 990 estiver setado para “CFE”.

Processo: Títulos Negociados na Cobrança Ocorrência: 69813 Caso: Desenvolver relatório de títulos gerados na emissão de Carnet. Novas Funcionalidades: Foi implementado Relatório de Títulos Negociados na cobrança (RTCOB), filtros disponíveis (Gerado, Não gerado e Todos).

Processo: Consulta Protocolos

Protocolos

Relatório

Status

dos

Ocorrência: 69157 Caso: Implementar os relatórios COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos comas colunas Quantidade de Itens e Dias de Atraso.

Página | 36

Novas Funcionalidades: Foram implementados os relatórios COPRO-Consulta Protocolos e RSPRO-Relatório Status dos Protocolos com as colunas Quantidade de Itens e Dias de Atraso.

Processo: Gerar Arquivos Importação Mtrix Ocorrência: 66537 Caso: Implementar relatório Gerar Arquivos de Importação MTRIX com as seguintes modificações: Arquivo "Força de Vendas": O layout do arquivo informa que cada linha determinar na posição 230, mas isso não está ocorrendo, a linha está terminando ao terminar o nome do vendedor. A colunas "código do gerente" e "código do supervisor" estão indo zeradas, as colunas "nome do gerente" e "nome do supervisor" estão indo em brando, Tâmara da Mtrix informou que caso não haja gerente e supervisor cadastrados devem ser enviados nesses campos códigos e nomes fictícios (Ex: código: 001 - Nome: SÒCIO PROPRIETARIO), ela solicita que a geração do arquivo força de vendas seja alterada para contemplar essas modificações solicitadas, embora a situação do código e nome fictícios não esteja informada no layout. Arquivo Vendas: Em algumas linhas o código do vendedor está indo com valor zero, deve ser identificado o motivo e ser feita a correção da geração. Em algumas linhas, no campo identificação do cliente que inicia na posição 016 o CNPJ do ponto de venda é igual ao CNPJ do fornecedor. A Mtrix não lê as informações de devolução da distribuidora para a Henkel...somente as movimentações da distribuidora entre os pontos de venda, deve ser identificado se as notas de devolução para a Henkel estão sendo enviadas e caso sim deve ser corrigido a geração do arquivo para não enviar. Em algumas linhas o campo código do produto (posição inicial 062) está iniciando com 0(zero), deve preencher o campo com o EAN13, DUN14 ou SKU (poderão ser enviados código interno no caso de montagem de kit, na ausência de cadastro do EAN13 ou se o mesmo EAN13 for comercializado de formas diferentes), o campo é alfanumérico e deve ser feito o ajuste da geração. Não Conformidade: Foram implementadas as modificações solicitadas, ficando somente pendente o caso do código do produto com zeros à esquerda, essa informação já vem do cadastro de código de barras do produto que está cadastrado com zero à esquerda.

Processo: Integrações Nexgen Ocorrência: 69429 Caso: Deverá ser implementada uma tela no Nexgen para informar o número do pedido e-commerce da loja e-commerce ou da loja que vende no e-commerce para uma integração de pedido independente do status que esse pedido esteja no VTEX. Melhorias de Processo: Criada a tela Interações Nexgen (INTEC), onde será possível integrar pedidos do Ecommerce(somente VTEX) que não integraram no Nexgen por algum motivo excepcional. Página | 37

Ocorrência: 69428 Caso: Deverá ser implementada implementado uma nova validação para ecommerce VTEX, que, no momento que um pedido é consultado na transação de recebimento de pedido, é verificado se este está cancelado no VTEX, em caso afirmativo, o pedido é automaticamente cancelado no NEXGEN é removido da fila de integração. Melhorias de Processo: Implementado uma nova validação para ecommerce VTEX, que, no momento que um pedido é consultado na transação de recebimento de pedido, é verificado se este está cancelado no VTEX, em caso afirmativo, o pedido é automaticamente cancelado no NEXGEN é removido da fila de integração.

Processo: Ajuste de Código Nexgen Ocorrência: 68512 Caso: Extinguir a QryLivre implementando uma nova qry (PagLoginDinamica). Não conformidade: A QryLivre foi substituída e agora há outra qry responsável por fazer a mesma tarefa que a QryLivre, mas removendo-a e não usando mais uma rotina genérica como acontecia. Ocorrência: 69947 Caso: Extinguir a QryLivre implementando uma nova qry de consulta para login no sistema (PagLoginDinamica). Não conformidade: Geração da classe para corrigir geração "defeituosa" da 68051. Ocorrência: 70281 Caso: A ocorrência 63978 estava com débito por causa da ausência dos scripts para isso uma nova ocorrência foi criada para ser atualizada no banco. Melhorias de Processos: Liberação de scripts da Ocorrência 63978: Criando o campo STATUS_DG na tabela GARANTÍAS para gravar o status da garantia: 'F' Finalizada/Baixada.

Processo: Atualização de Ambiente. Ocorrência: 69257 Caso: Erro de classes na atualização das versões 110 e 127. Não Conformidade: Foram geradas as classes e após atualização, foi corrigido erro causado pela atualização. Ocorrência: 69880 Caso: Verificar “quedas” do sistema que estão acontecendo várias vezes no durante o dia, após atualização. Página | 38

Não Conformidade: Efetuada correção no processo de impressão, para fechar os objetos abertos durante o processo, evitando assim que o sistema sobrecarregue e venha a ficar travado pela quantidade de objetos abertos em memória.

Processo: Integração de “Preços Promocionais” Petronas SFA Ocorrência: 68634 Caso: Correção na integração de preços promocionais na Integração de dados com o SFA Petronas. Não Conformidade: Criada estrutura do banco de dados para correção na integração de preços promocionais na Integração de dados com o SFA Petronas. Ocorrência: 68366 Caso: Problema em alguns pedidos gerados pelo SFA da PETRONAS, os boletos ficam com os valores a maior que o gerado. Não Conformidade: Correção da ocorrência 69104, referente a erro no valor informado no boleto devido a gravação errada na estrutura de dados em pedidos originados do SFA PETRONAS.

Processo: Relatórios Ocorrência: 68321 Caso: Criação de relatório para visão financeira de pedido recebidos com sinal, para verificar esses pedidos, os montantes recebidos e o que falta receber. Melhorias de Processos: O Relatório de Pedidos Emitidos ( RPED) será modificado para exibir no relatório as colunas: Vendedor, valor do crédito, valor do sinal, valor a receber e total faturado. O relatório não será gerado para EXCEL e PDF. Ocorrência: 59129 Caso: O Relatório Relação de Acertos de estoque (RCOAC) não era gerado em formato PDF. Melhorias de Processo: O Relatório Relação de Acertos de estoque (RCOAC) foi implementado para ser gerado em formato PDF. Ocorrência: 69337 Caso: O Relatório Analítico de Vendas por Caixa (RAVCX) deverá implementar as informações de vendas realizadas com recebimento em PIX.

Página | 39

Melhorias de Processos: O Relatório Analítico de Vendas por Caixa (RAVCX) foi implementado com informações de vendas realizadas com recebimento em PIX. Ocorrência: 69598 Caso: O Relatório Lista de Pedidos de Fornecedor (RLPED) está sendo gerado em "branco" independente da forma de "impressão" escolhida. Melhorias de Processos: O Relatório Lista de Pedidos de Fornecedor (RLPED) foi implementado para ser gerado de acordo com os parâmetros informados, o de loja, fornecedor e pedido. Ocorrência: 68139 Caso: O Relatório Itens Devolvidos do Pedido (RIDEV) estava sendo gerado com duplicidade de registros. Melhorias de Processos: O Relatório Itens Devolvidos do Pedido (RIDEV) foi implementado para ser gerado sem duplicação dos registros. Ocorrência: 69538 Caso: Ao gerar uma venda no “POS” em modalidades de recebimentos diferentes(DÉBITO/CRÉDITO), o sistema está exibindo várias informações duplicadas no Relatório de Caixa (RANCX). Não Conformidade: O problema relatado na duplicidade de informações no Relatório de caixa (RANCX) foi resolvido após implementação na consulta feita na estrutura de dados. Ocorrência: 68767 Caso: O Relatório da Comissão de Vendedores (RCVEN) deverá ter programado parâmetro não considerar os produtos devolvidos das operações fiscais que atualizam o estoque de garantia. Melhorias de Processos: O Relatório Comissão de Vendedores (RCVEN) foi implementado para não considerar os produtos devolvidos das operações fiscais que atualizam o estoque de garantia. Para que isso aconteça o parâmetro: "Comissão Por Categoria" deverá ser configurado com o valor “SIM” . Ocorrência: 69157 Caso: As telas Consulta Protocolos (COPRO) e Relatório Status dos Protocolos (RSPRO) deverão tratar a contagem do atraso de maneira a ser contado até a atualização do protocolo e não do fechamento da nota fiscal como estava implementado . Não Conformidade: As telas Consulta Protocolos (COPRO) e Relatório Status dos Protocolos (RSPRO) foram programadas para contar o atraso até a atualização do protocolo e não do fechamento da nota fiscal como estava implementado . Página | 40

Ocorrência: 69664 Caso: O Relatório Inventário Fiscal (RLVFI) estava demorando a ser gerado, causando travamento do sistema Não Conformidade O Relatório Inventário Fiscal (RLVFI) foi implementado com alteração na consulta, melhorando performance e evitando travamento do sistema. Ocorrência: 69996 Caso: Deverá ser implementado relatório de emissão de boletos com as seguintes informações atualizadas diariamente: número de clientes que negociaram com boleto; boletos gerados; boletos pagos (liquidados pelo cliente); boletos vencidos (não liquidados pelo cliente) e a vencer. Novas Funcionalidades: Para atender à solicitação foram realizadas as seguintes implementações: Criado Relatório de Boletos Gerados (RBNEG), para controle dos títulos enviado para cobrança bancária, esse relatório os seguintes filtros: período e tipo do boleto, e pode ser gerado por: BOLETOS GERADOS, BOLETOS PAGOS (LIQUIDADOS PELO CLIENTE), BOLETOS VENCIDOS (NÃO LIQUIDADOS PELO CLIENTE) e BOLETOS A VENCER. Relatório exibe “ Total de clientes negociados” e “Total de títulos negociados” . Ocorrência: 69664 Caso: O Relatório Inventário Fiscal (RLVFI) estava demorando a ser gerado, causando travamento do sistema Não Conformidade: O Relatório Inventário Fiscal (RLVFI) foi implementado com alteração na consulta, melhorando performance e evitando travamento do sistema. Ocorrência: 67725 Caso: A tela Relatório de Faturamento por Categoria (RFATU) deverá ser implementada para ser permitido ao usuário selecionar inúmeras categorias. Novas Funcionalidades: A tela Relatório de Faturamento por Categoria (RFATU) foi criada uma tela para selecionar inúmeras categorias, nela foi criado um botão que dará acesso a tela criada que possui categorias a serem selecionadas, o relatório será impresso usando essas informações, caso contrário, será impresso pegando todas as categorias, como anteriormente. Ocorrência: 69766 Caso: O Relatório de Comissão de Vendedores (RCVEN) deve ser alterado para desconsiderar os valores das devoluções de cliente de operações fiscais com a opção “Garantia Devolução Cliente” marcadas na operação fiscal.

Página | 41

Melhorias de Processos: O Relatório de Comissão de Vendedores (RCVEN) foi implementado para desconsiderar os valores das devoluções de cliente de operações fiscais com a opção “Garantia Devolução Cliente” marcadas na operação fiscal.

Processo: Inserção do parâmetro ‘noLock’ nas Qry de Consulta Ocorrências: 68060; 68053; 68041; 67370; 68058; 68075; 68037; 68096; 68101; 67371; 68023; 68114; 68338 Caso: Inserir noLocks nas classes Qry de Consulta e alterar em suas respectivas classes dependentes Dao(s) e Rul(s) para correção de versão no banco de dados. Melhorias de Processo: Foram inseridos os parâmetros noLocks na chamada das classes Qry de Consulta para possibilitar a atualização da versão do banco de dados.

Processo: Estruturas de Dados Ocorrências: 69458 Caso: Criar estruturas de dados para armazenar informações referentes ao processo de emissão do boleto e identificação de celular de clientes. Melhorias de Processo: Foram criadas estruturas de dados para armazenar informações referentes ao processo de emissão do boleto dos títulos negociados, e também no cadastro de cliente para identificar se o celular do cliente possui o WhatsApp. Ocorrência: 69687 Caso: Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de Ordem de Serviço Showroom. Melhorias de Processos: Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de Ordem de Serviço Showroom. Ocorrência: 69684 Caso: Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de devolução de clientes, para utilizar o preço de custo original da venda. Melhorias de Processos: Criadas estruturas de banco de dados para armazenamento de informações a serem utilizadas no processo de devolução de clientes, para utilizar o preço de custo de origem da venda. Ocorrência: 69751 Caso: Criar estruturas no Banco de Dados necessárias para geração dos dados para envio e retorno de informações do Ecommerce. Página | 42

Melhorias de Processo: Foram criadas estruturas no Banco de Dados necessárias para geração dos dados para envio e retorno de informações do Ecommerce. Ocorrência: 69834 Caso: Criar estruturas no Banco de Dados necessárias para geração da data de criação de um token de validação para comunicação REST API. Melhorias de Processo: Foram criadas estruturas no Banco de Dados necessárias para geração da data de criação de um token de validação para comunicação REST API. Ocorrência: 69888 Caso: Criar estrutura no Banco de Dados para guardar informações do fone da praça de cobrança que será utilizado no campo "Instruções" do boleto bancário. Também foi liberada criação de estrutura para contemplar a nota técnica de notas fiscais. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações no fone da praça de cobrança que será utilizado no campo "Instruções" do boleto bancário. Também foi liberada criação de estrutura para contemplar a nota técnica de notas fiscais. Ocorrência: 69980 Caso: Criar estrutura no Banco de Dados para guardar informações na tabela de GARANTÍAS para gravar data e valor do pagamento que serão exibidos na tela de Garantia. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações de GARANTÍAS para gravar data e valor do pagamento que serão exibidos na tela de Garantia. Ocorrência: 70075 Caso: Criar estrutura no Banco de Dados para guardar informações no processo de Histórico de Garantias. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações no processo de Histórico de Garantias. Ocorrência: 70149 Caso: Criar estrutura no Banco de Dados para guardar informações no processo de Cobrança – carência de dias na quarentena. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações no processo de Cobrança - carência de dias na quarentena. Ocorrência: 70322

Página | 43

Caso: Criar estruturas de dados para armazenar informações de fornecedor, frete e preço referentes a pedidos. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações de fornecedor, frete e preço referentes a pedidos. Ocorrência: 70352 Caso: Criar estruturas de dados para armazenar informações de produtos não Petronas que devem integrar para o SFA. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações de produtos não Petronas que devem integrar para o SFA. Ocorrência: 70415 Caso: Criar estrutura no Banco de Dados para guardar informações no processo que gera nota fiscal de brinde para produtos que não são revendidos pela empresa. Melhorias de Processo: Foi criada estrutura no Banco de Dados para guardar informações no processo que gera nota fiscal de brinde para produtos que não são revendidos pela empresa. Ocorrência: 70061 Caso: Criar estrutura no Banco de Dados para associar um produto(serviço) a seu respectivo CNAE. Melhorias de Processo: Foi criada estrutura no Banco de Dados para associar um produto(serviço) a seu respectivo CNAE. Ocorrência: 70459 Caso: Criar estrutura no Banco de Dados para estruturar dados da API do mercado Pago para adequação fiscal. Melhorias de Processo: Foi criada estrutura no Banco de Dados para satisfazer a solicitação do cliente de atualizar dados da API de mercado Pago. Ocorrência: 70469 Caso: Criar estrutura no Banco de Dados para associar alguns campos ausentes (Usuário Logado) na tabela Cabeçalho de Inventário, para um controle de acesso e organização de status. Melhorias de Processo: Foi criada estrutura no Banco de Dados para associar alguns campos ausentes (Usuário Logado) na tabela Cabeçalho de Inventário, para um controle de acesso. Ocorrência: 70478

Página | 44

Caso: Criar estrutura no Banco de Dados para registrar o número do adiantamento que foi gerado na tela de devolução ao fornecedor. Melhorias de Processo: Foi criada estrutura no Banco de Dados para registrar o número do adiantamento que foi gerado na tela de devolução ao fornecedor. Ocorrência: 70569 Caso: Criar estrutura no Banco de Dados para associar alguns campos ausentes na implementação da NT 2020.006 V.1.20, para um controle de acesso e organização de status. Melhorias de Processo: Foi criada estrutura no Banco de Dados para associar alguns campos necessários para implementar as mudanças da NT 2020.006 V.1.20. Ocorrência: 70647 Caso: Criar estrutura no banco para viabilizar a utilização do processo de unificação de boletos. Melhorias de Processos: Foi criado novas estruturas no banco de dados que serão utilizados no processo de unificação de boletos. Ocorrência: 70732 Caso: Criar estrutura no Banco de Dados para guardar informações de percentual e valores de descontos atribuídos a itens do pedido que possuem valores zerados ao ato do recebimento. Melhorias de Processos: Foi criada estrutura no Banco de Dados para guardar informações de itens de pedidos que existiam campos de valores zerados. O cenário atual permite que seja salvo o percentual de desconto e o valor do desconto destes campos.

Página | 45