📙 Mudanças
[Menu Comuns]
📙 2️⃣ Ajustar o campo "Desconto Válido até o vencimento” (SUP-87639)
Na tela “1.1.3 - Cadastro de clientes” na aba “Comercial”, foi alterada a posição do campo “Desconto válido até o vencimento”, que agora passará a ficar localizado em “Informações Comerciais”, no final na lista (Imagem 1).
O campo “Desconto válido até o vencimento” ficava desabilitado quando eram selecionadas as opções de tipos de contrato:
|
Agora foram retirados os bloqueios para ficarem habilitadas todas as opções de tipo de contrato, para o campo “Desconto válido até o vencimento” (Imagem 2).
[Menu Fiscal]
📙 1️⃣ Frete não era somado na base de PIS/COFINS na entrada de notas quando produto era insumo (SUP-88823)
Na tela “2.2.4 - Entrada de Notas Fiscais”, foi alterado para considerar os campos “Frete + Seguro + Desp. Acessórias + IPI Devolvido + FCP ST”, na Base de PIS/COFINS. Sendo assim, acessando a tela foram inserindas as informações de impostos no item (Imagem 1).
Ao adicionar o valor de Frete, o campo de Base PIS será atualizado, pois o sistema estará somando o valor de frete na Base de PIS corretamente (Imagem 2).
Inserindo um valor de Seguro, ele será somado ao valor de Base PIS (Imagem 3).
Inserindo um valor de Despesas Acessórias, ele estará sendo somado ao valor de Base PIS (Imagem 4).
Inserindo um valor de IPI Devolvido ele será somado ao valor de Base PIS (Imagem 5).
📗 Melhorias
[Integrador SysPDV]
📗 2️⃣ Cabeçalho com diferença dos itens
O SysPDV com a Saurus, passou a enviar informações no registro 01(um), além das já previstas inicialmente. O sincronizador comparará as linhas do registro 01(um), pois é comum a duplicação de itens num pedido PDV e quando é totalmente igual, gerará um contador de linha para itemizar e diferenciar por algo. Desta forma, as informações posteriores a coluna 648 (um registro deles para controlar os envios), acabam diferenciando a linha e ignorando o item duplicado, pois é considerado como já importado e não entrará no banco do sincronizador. Sendo assim, o “Sincronizador SysPDV” irá considerar até a coluna 648, mantendo o comportamento e permitindo que o arquivo possua o histórico necessário (Imagem1).
[Integrador B2B]
📗 2️⃣ Cockpit de configurações do B2UD no integrador (SUP-70843)
No Integrador B2B, foram inseridas as informações necessárias para que ele seja independente de configurações realizadas no Guarani ERP. A tela “3.2.45 - Configuração Integração B2UD” foi “repassada” ao Integrador como “Integração De/Para”. Sendo assim, o botão do configurações foi alterado para “Configurações Gerais”. Dentro deles, a opção “Banco de Dados” será onde “insere/altera”, as informações dos “bancos de dados, e-mails, tempo de sincronização e usuários” para editar scripts (Imagem 1).
A opção “Integração De/Para” é na verdade a tela “3.2.45 - Configuração Integração B2UD” do Guarani ERP, no Integrador. Não haverá informações nesse primeiro momento, pois ainda não existem dados advindos do ERP do usuário (Imagem 2).
Os scripts foram subdividos em 4(quatro) grupos: | |
|---|---|
| os SELECTs que buscam a informação no ERP do cliente para alimentar as tabelas do Integrador; |
| os INSERTs/UPDATEs que, junto aos SELECTs acima, gravam a informação no banco do Integrador. Para essa conexão acontecer, a quantidade e ordem dos campos do SELECT devem ser IGUAIS aos de seus respectivos INSERTs; |
| são os SELECTs que já existiam no Integrador, porém adaptados para, agora, buscar das próprias tabelas de configurações do integrador e, não mais do ERP; |
| são os INSERTs dos dados que descem da loja (clientes, pedidos, itens). Todas as ligações com as tabelas ICC do ERP foram removidas, substituídas por parâmetros que buscam as configurações do próprio integrador (Imagem 3). |
Caso queiram utilizar o script já montado para o Guarani ERP, basta clicar em “Query padrão” e “Todos”. Esses scripts foram montados para esse propósito e foram baseados no que é carregado na tela “3.2.45 - Configuração Integração B2UD” do Guarani ERP e nos antigos scripts que buscavam do ERP para enviar os dados para a loja. Todos os scripts possuem o parâmetro “ULTIMA_SINC”, que no Guarani ERP, busca dos campos de “lastupdate”. Porém, nem todas as tabelas possuem esse campo e nesses casos, os dados sempre serão recarregados (Imagem 4).
O agendamento foi modificado e agora será “Carga Manual”. O agendamento que já possuía, virou submenu e não teve nenhuma alteração. Já o “Carga (ERP x Integrador)” será uma tela nova para inserção de informações nas novas tabelas de configuração criadas no Integrador (Imagem 5).
O primeiro passo na criação das configurações da interação é executar o script de empresas. A tela possui um campo para informar a empresa, mas nessa primeira carga, ainda não existirá. Ou seja, basta acessar a tela e clicar em “Atualizar Empresas”. Lembrando que o script “ICC_EMPRESAS”, do menu “Exportações (ERP x Integrador)” já deverá ter conteúdo (Imagem 6). Desta forma, a mensagem de sucesso será exibida (Imagem 7).
Será possível criar a integração em “Configurações Gerais (De/Para)”, deverá clicar em “Hab. Config.” e assim conseguirá incluir a nova integração. E a “Senha Guarani” será requisitada (Imagem 8).
Utilizando o botão “Incluir”, será possível selecionar a empresa desejada, optando o “Ativo” como “SIM” e na sequência em “Salvar” (Imagem 9).
Nesse momento, deverá inserir as informações da loja para a empresa a ser cadastrada, pois esses dados serão necessários para os próximos passos (Imagem 10).
Antes de preencher as configurações da aba “Configurações De/Para”, uma carga completa ou dos itens necessários, deve ser gerada do Guarani ERP para o Integrador.
Na tela “Carga de Dados” para carga manual, a caixa de seleção apresentará a empresa automaticamente, em caso exista apenas uma cadastrada na integração, pois quando houver mais de uma, o campo ficará em aberto para escolha do usuário. Caso seja a primeira verificação de fluxo, a opção “Atualizar Todos” pode ser utilizada. Caso uma inconsistência na autenticação seja apresentada, reinicie o Integrador. Essa inconsistência só aparecerá após inserir as informações da URL e Token, nas próximas não será mais apresentada. Dependendo da massa de dados, poderá ser uma operação um pouco demorada (Imagem 11).
Utilizando a opção “Atualizar Todos”, ocorrerão duas inconsistências e gerações de log “Produtos” e/ou “Preços”. Nesse momento, esse comportamento é normal, uma vez que não existe tabela de preços nas configurações gerais (Imagem 12).
Com as informações de configurações necessárias preenchidas, será possível definir as configurações gerais da integração, de mesmo modo da aba “Configuração Geral” da tela “3.2.45 - Configuração Integração B2UD” do Guarani ERP, incluindo estoques a serem enviados e cobranças de cartão (Imagem 13).
A guia “Integrações” é onde o usuário irá inserir as informações que deverão estar na integração. A primeira alimentação do Integrador é apenas para trazer as informações. A escolha do que irá subir ainda é manual, da mesma forma que acontece na tela “3.2.45 - Configuração Integração B2UD” do Guarani ERP (Imagem 14).
Em “Incluir” será possível buscar os dados alimentados na carga manual. A lista com as informações é apresentada com os dados incluídos pela carga anterior. Ao clicar “Ok” ou “Salvar”, os conteúdos irão persistir com as informações e isso mesmo pode ser feito em todas as abas (Imagem 15). A atualização em massa ficou no botão direito da seleção dos registros (Imagem 16). Marcando o que se deseja alterar e salvando, a tela será fechada e o “Salvar” pode ser pressionado para persistir as informações (Imagem 17).
A tela “Desenvolvedor”, agora possui uma caixa de seleção da empresa para escolher de qual enviar um script, puxar um pedido ou qualquer outra funcionalidade multiempresa (Imagem 18). Os envios para a loja devem acontecer normalmente, assim como os pedidos, ou seja, via cargas manuais ou serviços, com uma empresa ou com várias.
Considerações Finais |
|---|
|
|
|
[Integrador E-Commerce]
📗 3️⃣ Criar abatimento para Frete - Koncili (SUP-87079)
No “Integrador E-Commerce” foi criada uma configuração a nível de cobrança, para definir quando considerar apenas uma parcela de pagamento, mesmo que o cliente tenha feito, por exemplo em (10) dez vezes. Pois a “Koncili”, para alguns canais repassa o valor de uma vez só, visto que já passou o cartão e pagou toda a compra.
Em “Configurações Gerais” na aba de cobrança, foi inserida a nova coluna “Somente Primeiro Prazo” que quando optada como “SIM”, ignorará os demais prazos (60, 90…) (Imagem 1).
Com isso, o pedido terá apenas um prazo e consequentemente, o título também. Sendo assim, ficará a nível de “Cobrança”, para estar no mesmo nível dos “Prazos” (Imagem 2).
Ao ignorar um registro, colocando na fila e para não fazer no mesmo momento, apenas a operação de banco será realizada, uma vez que a informação de importação da “Koncili” (com sucesso), será enviada assim que o registro for inserido no integrador, desta forma, essa operação ficou mais rápida.
A conciliação só funcionará a partir de pedidos com data superior à atualização do “Integrador ECommerce”; entretanto, manualmente será possível alterar os prazos antes de faturar o pedido, gerando apenas uma parcela.
[Menu comuns]
📗 3️⃣ Alteração em “Cadastro de clientes” (SUP-80344)
Na tela “1.1.3 - Cadastro de clientes“, no campo “Datas pré definidas para vencimento” foram inseridos todos os dias para serem utilizados, de 01 a 31 conforme o mês (Imagem 1).
Na tela “3.2.12 - Digitação de ordens”, o comportamento deste campo continuará sendo o mesmo. Ou seja, o usuário poderá selecionar nenhum, um ou vários dias para vencimentos. Observando que quando a data for dia 31 e o mês não tiver esta data, o sistema considerará o último dia do mês para os vencimentos (Imagem 2).
Ao alterar a data de vencimento da parcela, caso não seja o dia que cadastrado no “Cadastro de clientes”, o sistema apresentará uma validação e considerará o vencimento mais próximo do cadastro, conforme a data digitada (Imagem 3).
Através da tela “Expedição”, ao gerar o contas a receber serão apresentados todos os prazos definidos, conforme o cadastro na “Digitação de ordens” (Imagem 4).
Na tela “5.2.15 - Manutenção de contas a receber”, apresentará os prazos e datas que foram informadas na “Digitação de ordens” e ao alterar os prazos e datas, mostrará uma validação para considerar a data mais próxima conforme definida no “Cadastro de clientes” (Imagens 5 e 6).
Na tela “5.2.10 - Fechamento de ordens” terá o mesmo comportamento (Imagem 7).
Quando houver uma situação em que a data de vencimento da primeira parcela da ordem já foi ultrapassada e a ordem ainda não foi faturada, foi inserida uma validação para o usuário para que os prazos sejam recalculados (Imagem 8).
Faturamento e a validação que não pode prosseguir (Imagens 9 e 10).
Ao selecionar a opção “Manutenção nesta ordem” e remover as informações do conferente e data (Imagens 11 e 12).
Na tela “Digitação de ordens” permitirá alterar a data de vencimento e assim podendo fazer o faturamento normalmente (Imagens 13 e 14).
Uma outra opção é ajustar o prazo antes do faturamento, basta clicar no botão “Encerrar“ na “Digitação de ordens” e assim os prazos serão ajustados automaticamente (Imagens 15 e 16).
Na tela “Atualização Massa Digitaçao Ordem”, foi inserida uma validação para não permitir informar um prazo fixo com data inferior a data atual (Imagem 17).
[Menu comercial - Compras]
📗 3️⃣ Configurações para regras quanto a política de margem de contribuição
Na tela “3.2.48 - Configurações para regras quanto a política de margem de contribuição”, foi feita a inserção de validação no campo validade, que anteriormente ficava em branco (Imagem 1).
[Menu Comercial - Vendas]
📗 3️⃣ Divergências no relatório gerado pela tela "Relatório de Faturamento Gerenciais" (SUP-85307)
Na tela “3.3.29 - Relatórios de Faturamentos Gerenciais”, foram adicionadas colunas pertinentes ao grid de faturamento detalhado, ou seja, as colunas: ID Cliente, UF, Tipo de Ordem ('Descrição'), ID Representante, Representante, ID Supervisor, Supervisor e Usuário digitador (Imagem 1).
Nas telas “5.2.10 - Fechamento de ordens e 2.2.4 - Entradas de notas fiscais”, foi realizada a correção de visualização de notas de devolução parciais (Imagem 2).
No Relatórios de Faturamentos Gerenciais apresenta as duas notas, tanto de venda quanto de devolução (Imagem 3).
📗 2️⃣ Emitir uma mensagem para fazer a movimentação de produtos
Na tela “3.2.12 - Digitação de ordens“ foi adicionado um novo comportamento. Ao inserir um novo item, será verificado se o produto deste item, possui vínculo com algum bem da tela “22.2.1 - Controle de Ativo Imobilizado“. Caso não tenha nenhum vínculo, nada será feito, seguirá o comportamento que sempre existiu, mas caso tenha vínculo com algum bem que não esteja baixado, será exibida na tela uma mensagem e a aba “Bens do item” será exibida simultaneamente (Imagens 1 e 2).
Na tela “4.2.6 - Expedição”, foi adicionada uma nova validação antes de confirmar o pedido. Lembrando que essa validação já existe e verifica várias situações, o que foi adicionado é uma nova validação quanto aos vínculos de bens na ordem, ao clicar em “Conf. Fat”. (Imagens 3 e 4).
📗 3️⃣ Inconsistência ao fazer alteração da descrição de um Layout que foi criado
Na tela “Cadastro de Layouts para integração de dados com fornecedores”, foi inserido para que se clicar para alterar a descrição e gravar, que seja apresentada uma validação de que não é possível alterar. Para o botão excluir, será da mesma forma clicando em excluir se houver dependências não permitirá (Imagens 1 e 2).
Foi feita uma correção para que ao clicar em alterar e depois cancelar, que limpe todas as informaçãoes do cadastro na tela (Imagens 3 e 4).
📗 2️⃣ Notas referenciadas em campo de uma nota apenas
Na tela “3.2.12 - Digitação de ordens”, foi adicionada numa opção para visualização de notas referenciadas, na tela “Digitação de ordens”, sendo assim, quando selecionada mais de uma NF referenciada, será possível visualizar o número e informações da nota fiscal.
Acessando a tela de “Digitação de ordens” inserindo uma ordem de “Devolução”, ao vincular o produto será exibida a informação para Referenciar NF (Imagem 1).
Clicando na opção de “Referenciar NF”, será possível escolher o tipo de nota fiscal (Imagem 2).
Após escolher a opção “NF Própria”, será exibida uma listagem com notas de saídas para serem vinculadas de acordo com o item (Imagem 3).
É possível selecionar mais de uma nota fiscal e sendo assim conseguimos visualizar essa opção (Imagem 4).
📗 3️⃣ Ajustando “Fator de conversão” em relação a margem de contribuição
Foi adicionado um novo campo na tabela “GRADE”, para armazenar o fator de conversão em formato percentual, para usar em ordens classificadas em tipos de ordem que gera preço em tempo real. Sendo assim, foi feito um DML (organização) para popular este campo para todas as ordens do tipo que gera preço em tempo real. O cálculo para a conversão de fator para percentual usa a seguinte fórmula:
Percentual = (Fator * 100) - 100 |
Na ordem serão salvas ambas as informações, ou seja, o campo GRA_FATORCONVERSAO é o que sempre existiu e gravará o fator. Este continuará sendo usado para o legado, ou seja, todas as ordens que não são do tipo que gera preço em tempo real. E o novo campo GRA_FATORCONVERSAO_MC irá gravar a informação do fator de conversão em formato percentual, para ser utilizado para as ordens do tipo que geram preço em tempo real. Dessa forma, os cálculos da “Margem de Contribuição” com preços sugeridos em tempo real, voltarão a bater com os cálculos da planilha.
Como já é sabido, os percentuais de tabela do cliente e do representante, são desembutidos para o cálculo da margem de contribuição. Isso quer dizer que, no momento que o sistema buscar o fator de conversão, caso esteja configurado para usar um desses percentuais, ou mesmo os dois juntos, eles estarão contidos no fator de conversão salvo na grade. Contudo, no momento em que é feito o cálculo da margem de contribuição, esses percentuais serão desembutidos. Logo, como eles não são considerados para o cálculo da margem, na planilha nem precisam ser informados (Imagens 1 e 2).
Ao lançar uma ordem para um cliente, lembrando que o percentual do representante é 0(zero), não será considerado para este caso, mas poderá ser utilizado, pois segue o mesmo comportamento do percentual de cliente (Imagem 3).
Observando os campos que salvam o fator de conversão, teremos a seguinte informação (Imagem 4).
O GRA_FATORCONVERSAO primeiramente encontrou o valor de 1,039 na condição de venda. Depois embutiu do percentual de tabela do cliente, que é de -13,9. Usando a seguinte fórmula:
fator = 1,039; |
O cálculo do percentual é um pouco mais simples, segue a fórmula:
fator_mc = 3,9; |
Esses são os valores que ficam salvos na ordem referentes ao fator de conversão. Contudo no cálculo da margem de contribuição, é preciso fazer o processo inverso para desembutir o percentual do cliente, neste exemplo. Então, voltaria a ter os valores de 1,039 para o fator e 3,9% para o percentual.
Os cálculos realizados no momento de calcular a margem para desembutir o percentual do cliente, lembrando que os mesmos cálculos se aplicam para o percentual do representante. Quando o tipo de ordem NÃO gera preço em tempo real, será usada essa fórmula:
FATOR = 0,8946; |
Quando o tipo de ordem gera preço em tempo real, que é o nosso exemplo, irá usa a seguinte fórmula para desembutir o percentual de tabela do cliente.
FATOR_MC = -10; |
Comparando o relatório de “Margem de Contribuição” com o “Cálculo da planilha”, teremos a seguinte situação (Imagem 5).
O que era o esperado, sobre o fator de conversão somente da condição de venda, visto que os percentuais de tabela do cliente e do representante, são desembutidos ao calcular a margem de contribuição. Este ajuste teve apenas alteração nas procedures do banco de dados.
[Manu Financeiro - Receber]
📗 2️⃣ Tratativa de mensagem de erro
Na tela “5.1.7 - Cadastro de contas correntes”, foi feita uma tratativa na mensagem de erro, mostrando que existem dependências e por isso o registro não pode ser excluído.
Clicando em excluir será apresentada a mensagem da impossibilidade de exclusão (Imagem 1).
Clicando em “SIM” será apresentada a mensagem original do sistema (Imagem 2).
[Menu WMS]
📗 3️⃣ Criada a aba na etiqueta têxtil e automatização impressão (SUP-81462)
Na tela “1.1.3 - Cadastro de clientes”, foi acrescentado um campo chamado “RUC” para cadastro na aba "Dados Gerais" em “Documentação”. Este é um campo de texto que permite até 20 caracteres. Também foi adicionada uma barra de rolagem no grupo documentação, para que fosse possível incluir o novo campo (Imagem 1).
No “Cadastro de Material - Composição Insumo”, será acessado a partir do “Cadastro de produtos” nas “Opções” em “Têxtil”. Neste cadastro serão inseridos os materiais que irão formar a composição do produto conforme informado na aba “Têxtil em Composição”. No cadastro, foi criada a possibilidade de informar o material em outros idiomas, onde o idioma deve estar previamente definido a partir do cadastro de idiomas (Imagem 2).
Os idiomas que forem cadastrados nos materiais, serão mostrados tanto na aba “Composição” quando no campo da aba “Geral” (Imagens 3 e 4).
Na tela “8.2.7 - Revisão de peças em fabricação”, foi criado um botão chamado "Visualizar pedidos" no menu opções, que irá mostrar os pedidos que estiverem associados a ordem de fabricação em revisão (Imagens 5 e 6).
Foi criada uma nova opção no combo "Opção etiqueta" chamada "IMPRIMIR COM CLIENTE", esta opção terá o mesmo comportamento da opção "IMPRIMIR", porém o campo "Cliente" ficará habilitado para que um cliente seja informado e os dados deste fiquem disponíveis para customização na etiqueta gerada. Caso a ordem de fabricação tenha somente um cliente associado, esse já virá como lembrança ao carregar a ordem na tela, podendo ser alterado normalmente caso seja necessário. |
As informações do cliente não serão inseridas na etiqueta da versão, somente estarão disponíveis para customização (Imagens 7 e 8).
Na etiqueta, as informações dos materiais da composição que estiverem em outro idioma, já sairão normalmente na etiqueta. Assim como a descrição do produto, caso tenha o seu cadastro em outro idioma (Imagem 9).
[Menu PCP]
📗 2️⃣ Alteração de dados "livre" na tela de ferramentas de fabricação (SUP-79815)
Na tela “8.1.2 - Cadastro de ferramentas de fabricação”, foi inserida a coluna peso na grid, para poder alterar diretamente na grid (Imagem 1).
Sistema permitirá fazer qualquer alteração em todas as colunas diretamente na grid (Imagens 2 e 3).
A adição do item na grid, respeitará o grupo de permissões (Imagens 4 e 5).
A exclusão do item na grid, respeitará o grupo de permissões (Imagens 6 e 7).
A alteração do item na grid, respeitará o grupo de permissões (Imagens 8 e 9).
Coluna “Qtd Colaboradores”, permitirá duas casas decimais (Imagem 10).
📗 2️⃣ Criada a coluna para informar “Turno” e implementação para apontamentos de revisão de peças(SUP-81670)
Na tela de apontamento “Revisão de Peças - Defeitos”, foi adicionada a coluna “Turno” por meio da qual possibilitará o apontamento do turno responsável pelo defeito (Imagens 1 e 2).
Na tela “8.2.7 - Revisão de peças em Fabricação” foi adicionada a coluna “Turnos Defeitos” ao grid inferior, onde serão exibidos os nomes dos turnos aos quais os defeitos apontados para a peça gerada pertencem (Imagem 3).
Na tela “8.2.9 - Controle de Ordem de Fabricação por Ferramenta”, foi adicionada a funcionalidade de apontamento de defeitos (Imagens 4 e 5).
Na tela “8.2.9 - Controle de Ordem de Fabricação por Ferramenta”, foram adicionadas as colunas “Defeitos Qtde e Turnos Defeitos” ao bloco [Apontamentos], da mesma forma que na tela “8.2.7 - Revisão de peças em Fabricação (Imagem 6).
O apontamento de feito feito na tela “8.2.9 - Controle de Ordem de Fabricação por Ferramenta” será apresentado na coluna “Turno Defeitos (Ferramenta)” da tela “8.2.7 - Revisão de peças em Fabricação” (Imagem 7).
Na tela “8.1.11 - Cadastro de Defeitos”, foi adicionado o campo “Tipo”, por meio do qual o usuário poderá determinar o tipo do defeito quando a tela for acessada diretamente do “Principal” (Imagem 8).
Na aba “Consulta”, quando a tela for acessada diretamente a partir do “Principal”, passará a exibir todos os defeitos cadastrados, diferentemente de quando acessada por intermédio de outras telas (Imagem 9).
📗 3️⃣ Ordens de produção vinculadas (OP pai x OP filha)
Foi feita uma alteração para que sejam consideradas as ordens em aberto, tanto produzindo o semiacabado quanto acabado em aberto que irá consumir. Esta opção irá considerar o estoque físico disponível, a quantidade em fabricação e a soma da necessidade de todos os outros dependentes com OF em aberto.
Segue o Exemplo: Necessidade da ordem atual: 300 Qtde a produzir = 150 - ( 50 +100) = 0
Obs: Nesse caso, para atender a necessidade do semiacabado será necessário produzir os 300 da ordem atual. |
|---|
Estoque físico e em Fabricação (Imagem 1).
Necessidade dos dependentes (Imagem 2).
Semiacabado à produzir (Imagem 3).
[Menu Ativo Imobilizado]
📗 2️⃣ Permitir informar a quantidade suficiente de bens de acordo com a quantidade do item de compra
Na tela “22.2.1 - Controle de Ativo Imobilizado”, foi ajustado no registro que verifica os bens disponíveis para vincular no item do pedido de compra. Desta forma, na aba consulta podemos notar que os bens “ITEM 01 e ITEM 02”, estão vinculados ao produto cujo o código é 300 (Imagem 1).
Na tela “2.2.8 - Manutenção das ordens de compra” é inserido o item 300 e em seguida realizado o vínculo com os bens “ITEM 01 e ITEM 02”; ao tentar inserir um terceiro “ITEM” o sistema emite um alerta de que não é possível a sua inserção (Imagem 2).
Após realizar a “Digitação de ordem”, acessando a tela “22.2.1 - Controle de Ativo Imobilizado” será possível verificar as informações de cada “ITEM” na aba “Mvto Entrada” (Imagens 3 e 4).
📘 Solicitações
[PDV]
📘 3️⃣ Inconsistência na movimentação de Caixas (SUP-94441)
Ocorrência: A devolução de mercadoria não estava sendo exibida no fechamento de caixa e os pedidos estavam alterando a fidelidade, após importação de comanda.
Solução: Foi ajustada na tela de conferência de caixa, para exibir e deduzir as devoluções de mercadorias realizadas no PDV e no ERP (Imagens 1 e 2).
Foi realizado um ajuste na importação da comanda do PDV de pedidos gerados, a partir da duplicação de ordens do ERP, para que seja mantida a fidelidade original do pedido (Imagens 3 e 4).
Local>Tela 5.2.21 - PDV Retaguarda - conferência de caixa
Local>Tela 3.2.12 - Digitação de ordens
[Manu Comuns]
📘 1️⃣ Cadastro de produtos alteração da embalagem (SUP-89977)
Ocorrência: Impossibilidade de alterar a embalagem do produto mesmo não existindo nenhum pedido em aberto com unidade de venda em embalagem.
Solução: Foi realizado um ajuste para ser permitido alterar a embalagem do produto caso não exista nenhum pedido em aberto cuja unidade de venda, seja em embalagem (Imagens 1, 2 e 3).
Local>Tela 3.2.12 - Digitação de ordens
Local>Tela Cadastro de Produtos
[Menu Comercial - Compras]
📘 1️⃣ Estoque no pedido de compras (SUP-89765)
Ocorrência: Estoque cadastrado no tipo de ordem só aparecia na “Manutenção de ordens de compra” depois que inseria pelo menos um item na gride.
Solução: Foi realizado um ajuste inserir um item pela opção “(+)” na tela “Manutenção das ordens de compra” e buscar o local de estoque configurado no “Cadastro de tipos de ordens” (Imagens 1 e 2).
Local>Tela 1.1.23 - Cadastro de tipos de ordens
Local>Tela 2.2.8 - Manutenção das ordens de compra
📘 2️⃣ Importação de XML de devolução (SUP-89754)
Ocorrência: Estavam ocorrendo inconsistências ao importar XML com vários produtos e várias chaves referenciadas.
Solução: Foi realizado um ajuste na busca por informações de IPI da nota de saída, ao realizar entrada de nota de devolução (Imagem 1).
Local>Tela 2.2.4 - Entrada de notas fiscais
[Menu Comercial - Vendas]
📘 2️⃣ Sistema não respeitando a tabela de preços selecionada para criar a “Ordem de remessa” (SUP-89889)
Ocorrência: Ao selecionar uma tabela de preços, para criar uma ordem através da da tela “Transferência entre locais de estoque”, o sistema estava validando o valor de custo na planilha, não respeitando a tabela de preços selecionada.
Solução: Foi realizado um ajuste para que o sistema respeite a tabela de preços selecionada na criação de uma ordem, através da tela “Transferência entre locais de estoque”, desta forma, não será necessário validar o valor de custo na planilha. Caso o produto não exista na tabela selecionada, então será validado e utilizado o valor de custo na planilha.
Efetuada a transferência entre locais de estoque, selecionando uma tabela de preços (Imagem 1).
Crianda uma ordem do tipo retorno (Imagem 2).
A ordem foi criada respeitando a tabela de preços, que foi selecionada na “Transferência entre locais de estoque” (Imagem 3).
Local>Tela 3.2.12 - Digitação de ordens
Local>Tela 3.2.22 - Manutenção de tabelas de preços
Local>Tela 2.4.5 - Transferência entre locais de estoque
[Menu Faturamento]
📘 1️⃣ Impossibilidade de criar um novo romaneio
Ocorrência: Esta ocorrendo um bloqueio inadequado, pois deveria ser possível a transferência para novo romaneio independentemente do status do romaneio de origem.
Solução: Foi feito um ajuste, onde pode ser criado um novo romaneio à partir de um romaneio aberto ou fechado; e onde há a possibilidade da transferência de pedidos entre romaneios já fechados (Imagem 1).
Local>Tela 4.2.6 - Expedição
[Menu WMS]
📘 2️⃣ Inconsistência no inventário WMS rotativo por endereço (SUP-90147)
Ocorrência: O inventário rotativo por endereço, não estava zerando o estoque de alguns produtos não lidos no endereço.
Solução: Foi corrigido para considerar o valor absoluto ao calcular, assim zerando corretamente os itens não lidos (Imagens 1, 2 e 3).
Local>Tela 7.2.6 - WMS - Mapa do depósito
[Menu Contábil]
📘 2️⃣ Título receber não integrado porém gerando Id Contábil na tabela Recpar (SUP-89858)
Ocorrência: Ao tentar realizar a integração dos títulos a receber pela tela “Contábil - Integração”, faltavam informações de cadastro. Após realizar a integração e buscar integrar novamente, a integração do dia ocorria, porém, não trazia o registro.
Solução: Foi ajustado para que quando houver uma regra contábil configurada com a classificação “Recebido/Pago” e informada a conta de crédito, esta regra tenha o mesmo comportamento de uma regra configurada com a classificação “Original”, integrando normalmente (Imagem 1).
[Menu Fiscal]
📘 2️⃣ Registro 1601 do SPED trazendo dados da fidelidade (3)três (SUP-85333)
Ocorrência: Quando o recebimento de um boleto praça (3) três, era recebido como boleto praça (1) um e desta forma, estavam sendo listados no relatório do “Sped fiscal”.
Solução: Agora, a consulta para preenchimento do bloco 1601 considerará apenas os títulos praça (1) um.
Geração do arquivo Sped fiscal (Imagem 1).
Totalizador sendo listados somente os recebimentos e títulos praça (1) um (Imagem 2).
Local>Tela 10.2.16 - Sped fiscal
Índice:
Legendas dos tipos de tickets | Legendas da criticidade do ticket | ||||
?? Mudança | 📗 Melhoria | ?? Solicitação | 1️⃣ Relevante | 2️⃣ Importante | 3️⃣ Muito importante |
Feedback |
|---|
Qual é o seu nível geral de satisfação com essas notas de versão? |
