DOCUMENTAÇÃO EM ANDAMENTO ⚠️
Esta nota de versão é apenas uma prévia da versão ERP.
Observe que os manuais do usuário, instalação e a mídia FTP não foram atualizados.
Além disso, informamos que as correções e implementações descritas aqui podem ser alteradas, excluídas ou adicionadas a qualquer momento.
Liberamos com antecedência para ajudar nossos clientes a planejarem a atualização do sistema.
📙 Mudanças
[Nome do menu]
📗 Melhorias
[Integrador AFV]
📗 2️⃣ Melhoria ao acessar arquivos do servidor.
SUP-75663/SUP-76881/SUP-82686/SUP-96933/SUP-97258
No “Integrador AFV”, foi feita uma melhoria para que quando ocorrer a inconsistência, o sistema reinicie e abra novamente o integrador. Poderá ser definido se a aplicação será reiniciada automaticamente através do campo “BLA_REINICIA” da tabela “BLACKLIST”.
Por padrão, estará optado como “NÃO”. Para que a aplicação seja reiniciada automaticamente quando ocorrer qualquer inconsistência relacionada à memória, basta optar por “S” nas duas opções apontadas (Imagens 1 e 2).
[Integrador e-commerce]
📗 2️⃣ Integração com “Lexos” no e-commerce.
SUP-93425
O “Integrador e-commerce”, agora possui a plataforma “Lexos” disponível para integração dos pedidos feitos através do e-commerce para o Guarani ERP (Imagem 1).
Para configurar a integração com a “Lexos” no “Integrador E-commerce”, serão necessários os dados:
URL Integração: api.lexos.com.br;
Usuário: E-mail para a autenticação (api.lexos.com.br/Autenticacao);
Senha: Senha para a autenticação (api.lexos.com.br/Autenticacao);
Code: Primeiro token disponibilizado com o usuário e senha da autenticação;
Chave de Integração: Token disponibilizado pela Lexos, disponível no painel do usuário;
Refresh Token: Campo de preenchimento automático que controla os tokens de atualização, para realizar novas requisições.
Autenticação
Com o code da URL copiado, será necessário colar no campo “Code”, nas configurações do integrador. A “Chave de Integração” também deverá ser inserida (a própria “Lexos” localiza esta informação, caso o usuário não encontre no painel). O campo “Refresh Token” será o único a não ser preenchido inicialmente (Imagem 2).
Ao testar pela primeira vez, o “Integrador e-commerce” preencherá o campo “Refresh Token”, que será atualizado automaticamente em toda chamada na integração (Imagem 3).
Catálogo |
O “Integrador e-commerce”, possui cinco chamadas para cadastramento de catálogo da “Lexos”, sendo elas:
|
Da mesma forma que das demais integrações, as informações “De > Para” deverão ser inseridas. Apenas uma tabela de preço foi disponibilizada neste momento, pois isso dependerá de uma condição específica do usuário que utilizará a integração. O status para importação no integrador, neste momento deverá ser “Todos” e para o ERP vazio. Além disso, deverão ser inseridos os estoques e usuários de cancelamento. As demais informações serão necessárias, com o início da chegada dos pedidos (Imagem 4).
Os arquivos (payload) ficarão na pasta “Response”, da instalação do integrador, nas pastas do nome do “endpoint da API” (Imagem 5).
Como exemplo, será enviada uma carga individual de produto (da mesma maneira que as demais integrações) (Imagem 6).
|
Informações comuns, como: “descrição, valor unitário, estoque AFV”. As informações sobre medidas e especificações (Imagem 7).
|
|
Pedidos
Na carga manual buscando “todos” ou “serviço”, o integrador utilizará o método “ObterLista”. Esse método responde com resumos dos pedidos, à partir de uma data atribuída (o LastUpdate). Nesse arquivo deverá constar: PaginaAtual, TotalPaginas, TotalRegistros, Pedidos, Data, AtualizadoEm e PedidoStatus.
Os arquivos de “payload” da requisição ficarão na pasta “…\Response\OBTERLISTA”. Assim, o integrador percorrerá os resumos, para capturar a informação completa do pedido, disponibilizada no método “ObterPorId”. PedidoId, PedidoERPId, Codigo, Data, Status, Desconto, Acrescimo, Frete, FreteCusto, SubTotal, Total, TipoFrete, EntregasStatus, ClienteCpfcnpj, ClienteNome, ClienteNomeFantasia, ClienteDataNascimento, ClienteSexo, ClienteRg, Observacao, CodigoRastreio, CodigoPlataforma, Plataforma, Canal, LojaId, PedidoStatusERPId, UpdatedOn, CodigoLojaErpExterno, PedidoCampanhaView, Contatos, Nome, Telefone, Email, Enderecos, TipoEndereco, Endereco, Bairro, Cidade, Uf, Pais, Cep, Numero e Complemento.
Os arquivos de “payload” da requisição, ficarão na pasta “…\Response\OBTERPORID”. Este será o pedido que será gravado na tabela “Pedidos” do integrador, assim como posteriormente no Guarani ERP. Todas as associações possíveis foram realizadas; ao homologar, mais informações podem ser encontradas e/ou alteradas, em relação aos campos da Lexos com os da Guarani.
Ao realizar uma carga com todos os pedidos, o integrador percorrerá a lista citada e gravará os pedidos disponíveis nela (Imagem 8).
Neste ponto, os logs de “De > Para” serão exibidos (por se tratar de uma integração nova), como cidades, cobranças, etc (Imagem 9).
O processo comum será de inserção normal, assim como nos outros E-commerces (Imagens 10, 11 e 12).
Quando os “De > Para” estiverem informados devidamente, os pedidos subirão para o Guarani ERP (Imagem 13).
Na importação de pedidos específicos, o “endpoint” utilizado será o “ObterPorCodigo”, (número do pedido na plataforma da “Lexos”). Para estes pedidos, o “payload” ficará na pasta “…\Response\OBTERPORCODIGO” (apenas manuais). Ao pesquisar, o pedido será exibido normalmente (Imagens 14, 15, 16 e 17).
📘 Solicitações
[Menu Comercial - Vendas]
📘 3️⃣ Inconsistência na tela “Digitação de ordens”.
SUP-101667
Ocorrência: Estava sendo apresentada uma inconsistência quando era referenciada uma nota na opção manual na tela “Digitação de ordens” e as informações não eram preenchidas.
Solução: Foi criada uma validação para que caso o usuário não informe uma nota, não sejam salvos valores em memória e será validado ao clicar no botão gravar se existe uma nota informada, caso não exista será validado ao usuário para que seja informada.
Referenciar NF Manual (Imagem 1).
Produto sem NF Referenciada (Imagem 2).
Validação ao tentar gravar o item sem referenciar a NF (Imagem 3).
Local>Tela 3.2.12 - Digitação de ordens
[Menu Faturamento]
📘 3️⃣ Inconsistência ao indicar contingência em nota fiscal.
SUP-101646
Ocorrência: Estava sendo apresentada uma inconsistência ao indicar contingência em nota fiscal.
Solução: Foi feito um ajuste no tipo de código de barras para nota de contingência, alterado de “Code128C para Code128” (Imagens 1, 2, 3 e 4).
Local>Tela Emissão Notas fiscais eletrônicas
Local>Tela Emissão de notas fiscais em contingência (Formulário de segurança)
Local>Tela de impressão DANFE
📘 2️⃣ Inconsistência no código de barras ao enviar nota fiscal por e-mail.
SUP-101419
Ocorrência: Estava sendo apresentada uma inconsistência no código de barras ao enviar nota fiscal por e-mail. Foi verificado que ao gerar o PDF da nota, a propriedade “AutoSize” estava configurada para “Verdadeiro”, dessa forma ao gerar o PDF o código de barras ficava distorcido.
Solução: Foi alterada a opção “AutoSize” para “Falso” e preenchido o espaço total que ficava disponível.
Ao clicar em “Reimprimir DANFE” (Imagem 1).
Ao optar por “Ferramentas” e restaurar ambos os “Layouts da DANFE” (Imagem 2).
Após clicar em “Exportar para PDF” (Imagem 2).
O PDF estará com os dados corretos (Imagem 4).
Local>Tela 4.2.8 - Manutenção de notas fiscais eletrônicas
Local>Tela de impressão DANFE
[Menu Financeiro - Receber]
📘 3️⃣ Inconsistência ao alterar carteira, cobrança e vencimento.
SUP-101335
Ocorrência: Estava sendo apresentada uma inconsistência ao alterar o tipo de cobrança de um título que estivesse com o vencimento prorrogado e passado pela tela de liberação/prorrogação de títulos.
Solução: Foi realizado um ajuste na passagem do campo “Tipo”, para ser o valor original do título ao ser aberto para edição e ao ser salvo no banco de dados com o novo campo “Tipo”, a chave estrangeira atualizará em cascata o registro na tabela “REC_ABAT_PRORROGACAO”.
Título antes de prorrogar o vencimento (Imagem 1).
Prorrogando vencimento do título (Imagem 2).
Liberada a permissão para alterar vencimento de título na tela “Liberação de descontos e prorrogação de títulos” (Imagem 3).
Alterado o tipo do título após prorrogação do vencimento. Tipo da cobrança alterado normalmente (Imagem 4).
Tela “Manutenção de contas a receber” com o tipo da cobrança alterado logo após ter alterado o vencimento do título (Imagem 5).
📘 3️⃣ Filtros da consulta de títulos no “Lançamentos a receber”.
SUP-101334
Ocorrência: Ao fazer vendas no módulo “PDV/Frente de Caixa”, em seguida na tela “Manutenção de contas a receber” e puxar estas vendas nos filtros exclusivos juntamente com pesquisa de cliente, estas vendas não eram apresentadas.
Solução: Foi feita uma correção e agora será possível utilizar os filtros exclusivos, pesquisando com o número dos pedidos do “PDV”, juntamente com a pesquisa de clientes.
Vendas feitas pelo “PDV/Frente de Caixa”, onde é gravado um número de pedido (Imagem 1).
Número de pedido advindo do campo documento e continuará a pesquisar por número de documento (Imagem 2).
No campo ordem sem cliente, o sistema também continuará a pesquisar devidamente (Imagem 3).
Efetuada a correção onde o número do pedido e nome de cliente, estão sendo pesquisados devidamente quando usado em combinação com os filtros exclusivos (Imagem 4).
Com a pesquisa funcionando devidamente com os filtros exclusivos: cliente X empresa X filtros (Imagem 5).
Um exemplo utilizando o filtro: cliente X empesa X campo, o número de documento e o pedido; serão apresentados normalmente, desta forma, comprovando que a pesquisa está funcionando devidamente (Imagem 6).
Local>Tela 5.2.15 - Manutenção de contas a receber
Local>Tela PDV/Frente de Caixa
[Menu WMS]
📘 3️⃣ Reabertura de pedidos entregues.
SUP-101092
Ocorrência: O sistema permitia reabrir pedidos já entregues, que já passaram pelo fechamento de ordens.
Solução: Foi criado um bloqueio para não ser permitido reabrir pedidos já entregues (fechamento de ordens) (Imagens 1, 2 e 3).
Local>Tela 3.2.29 - Rastreamento de ordens
Local>Tela Coletor
Local>Tela Painel de controle da conferência de mercadorias
[Menu MDF-e/CT-e]
📘 3️⃣ Sequencial do CTE não sendo considerado ao gerar um novo CTE.
SUP-101936
Ocorrência: Na tela “Cadastro de CT-e”, o sistema pede para gravar duas vezes a inclusão do CTE, caso salvar a primeira vez e posteriormente clicar em “cancelar”, quando gerar um novo CTE o sequencial pula para o próximo e desconsidera o sequencial anterior.
Solução: Foi criado um bloqueio para não ser permitido reabrir pedidos já entregues (fechamento de ordens) (Imagens 1, 2 e 3).
Local>Tela 11.1.2 - Cadastro de CT-e
Índice:
Feedback |
|---|
Qual é o seu nível geral de satisfação com essas notas de versão? |
Legendas dos tipos de tickets | Legendas da criticidade do ticket | ||||
?? Mudança | 📗 Melhoria | ?? Solicitação | 1️⃣ Relevante | 2️⃣ Importante | 3️⃣ Muito importante |
Informações técnicas | |
|---|---|
Banco: | |
Coletor: |
