Você está aqui

24/2022 - Versão Base - 8.0.0

Últimas Versões em Publicação  

Aplicações

Cadastrada / Compatível

Data de liberação

Novo SIGILO - 8.0.0 - NÃO-PAF   16/12/2022
Novo SIGILO - 8.0.0 - PAF                           () SC     
SigServerTools - 7.10.0 8.0.0 11/11/2022
SigiloMobile - 6.20.0 8.0.0 08/07/2021
SigiloPdvMobile - 8.0.0 8.0.0 16/12/2022
SigiloModFichaMobile - 8.0.0 8.0.0 16/12/2022
SigiloEstoqueMobile - 8.0.0 8.0.0 16/12/2022

 

Clique aqui para acessar o informativo da versão anterior - 7.10.0

1. - 024/2022: NOVOS RECURSOS

 

16381: Possibilitar limitar os cartões aceitos pelo Módula PDV nas formas de pagamentos via Sitef

Casos de uso

1. Vincular determinadas bandeiras e tipos de cartão do Sitef com formas de pagamento no Módula PDV.

 

Pontos de solução

1. Criado o cadastro "Produtos Sitef p/ formas de pagamento" para vincular determinados produtos Sitef (bandeira e tipo de cartão) com formas de pagamento específicas. Assim, por exemplo, cartões do tipo "Alimentação" de uma bandeira, que passam como cartão de débito, podem ser configurados para serem aceitos somente pela forma de pagamento "TEF Alimentação".

      1. Esse cadastro estará acessível através do menu "Outros Cadastros > Configurações Sitef > Produtos Sitef p/ formas de pagamento".

      2. Através desse cadastro será possível associar produtos Sitef com formas de pagamento com operação de caixa igual à "Pagamento com Sitef".

      3. Essa associação criará um vínculo de uso exclusivo de um produto Sitef com uma forma de pagamento e vice e versa. Sendo assim, para realizar uma transação com o cartão:

           1. Será obrigatório utilizar a forma de pagamento que estiver associada ao respectivo produto Sitef (bandeira e tipo de cartão). 

           2. E a forma de pagamento aceitará única e exclusivamente os produtos Sitef que estiverem associados a ela. 

           3. Se a forma de pagamento não possuir vínculos com produtos Sitef, será mantido o comportamento atual do sistema.

      4. Para visualizar e alterar esse cadastro, o usuário deverá possuir as permissões de visualizar e alterar o cadastro de lançamentos padrões, respectivamente.

  

2. Esse cadastro também estará disponível na tela de edição do lançamento padrão através da aba "Produtos Sitef", que estará visível somente quando for um pagamento via Sitef.

      1. Nesse caso o cadastro será limitado a listar, inserir, alterar e excluir somente os registros associados ao respectivo lançamento padrão.

  

3. Ao realizar uma transação com cartão no Módula PDV via Sitef, a forma de pagamento utilizada poderá ser recusada nas seguintes situações:

      1. O produto Sitef retornado está associado a uma forma de pagamento diferente da utilizada. Nesse caso será apresentada a mensagem:

           'Transação não efetuada. 

          A forma de pagamento "<nome_forma_pgto>" não é permitida para um cartão "<nome_produto_tef>".

           Nesse caso deve ser usada a forma de pagamento "<nome_outra_forma_pgto>".'

      2. A forma de pagamento utilizada está associada a produtos Sitef diferentes do retornado. Nesse caso será apresentada a mensagem:

           'Transação não efetuada. 

          A forma de pagamento "<nome_forma_pgto>" não é permitida para um cartão "<nome_produto_tef>".

           Essa forma de pagamento aceita somente os produtos Sitef "<lista_produtos_sitef_da_forma_pagamento>".'

  

4. Movido o menu "Configuração Sitef" para ser um submenu do novo menu "Configurações Sitef". 

 

17046: Melhorar a aplicação das regras de venda para múltiplos pagamentos

Casos de uso

1. Venda de mercadorias com aplicação de regras de venda.

 

Pontos de solução

1. Melhorada a aplicação de regras de venda no Modula PDV.

 

2. Agora, as regras de venda passarão a ser aplicadas para cada pagamento, não mais somente para o pagamento a principal.

      1. Ao efetuar um pagamento, o sistema aplicará a regra de venda presumindo que o restante a pagar utilizará essa forma de pagamento, mesmo se informado um valor parcial.

      2. Ao fechar a venda, a participação da aplicação de cada regra de venda nos itens será proporcional ao valor que o pagamento abateu da venda.

      3. A definição da tabela de preço por regra de venda continua exclusiva das regras aplicadas ao pagamento principal. As regras aplicadas nos pagamentos secundários apenas irão gerar desconto ou acréscimo.

      4. Para ambientes NÃO-PAF, caso exitam múltiplas regras que tentem definir o preço do produto, será utilizada a regra que definir o maior preço. Essa abordagem tem por objetivo prevenir a geração de acréscimos no item.

     5. Nas vendas com cupom fiscal, todo o desconto/acréscimo calculado para os pagamentos secundários serão aplicados como desconto/acréscimo sobre a venda.

      6. Se houver alguma recusa por parte da regra de venda ao efetuar o pagamento, como uma regra de bloqueio ou a exigência de uma condição específica, não será possível continuar com o pagamento e será exibida uma mensagem com o motivo da recusa.

      7. Se o operador retornar ao quadro de vendas com pagamentos já efetuados e vender ou cancelar itens, ao retornar para a etapa dos pagamentos, as regras de vendas serão recalculadas. Caso exista alguma diferença de valores devido a reaplicação da regra, será exibida uma mensagem informando do reajuste da venda.

      8. Ao selecionar uma forma de pagamento em dinheiro no pagamento secundário, se houver aplicação de regra de venda que altere o valor da venda, será exibida uma mensagem informando do reajuste da venda. 

     Nota: A mensagem será exibida quando for pagamento em dinheiro porque a tela de edição do pagamento não é aberta.

 

3. Caso tenha aplicação de regras de venda e mais de um pagamento que gerem troco:

      1. Se houver pagamento em dinheiro:

           1. Se o pagamento em dinheiro for maior ou igual ao troco, então o troco será descontado do pagamento em dinheiro para fins do cálculo de regras de venda.

           2. Se o troco for maior que o pagamento em dinheiro, o pagamento em dinheiro será desconsiderado para fins do cálculo de regras de venda. 

     2. Se depois de tratar o pagamento em dinheiro ainda houver troco, a venda poderá ser reajustada de acordo com os pagamentos restantes.

          1. A proporção dos pagamentos poderá mudar, alterando a participação da aplicação de cada regra de venda nos itens.

 

4. Na tela de edição do pagamento:

      1. Dependendo do valor do pagamento, poderá ser exibida uma mensagem de notificação informando sobre o valor que falta a pagar ou do troco gerado.

      2. Se o valor da venda mudar devido ao novo pagamento, as mesmas mensagens exibidas no fechamento da venda serão exibidas nessa tela e na tela de seleção de pendências, quando o pagamento baixar pendências.

 

5. Reforçando, o desconto do operador informado na tela de fechamento da venda continua sendo aplicado ao valor final da venda.

 

6. Alterado comportamento do sistema que desconsiderava o pagamento em dinheiro quando esse pagamento fosse menor que o troco. Agora, o pagamento em dinheiro será mantido na venda para fins de cálculo do troco. 

 

7. Adicionada restrição no sistema que impedirá a utilização de diferentes formas de pagamento em dinheiro. Ao tentar utilizar diferentes formas de pagamento em dinheiro, será exibida a mensagem "A forma de pagamento em dinheiro "[Nome da forma de pagamento]" não poderá ser utilizada, porque já existe uma outra forma de pagamento em dinheiro informada.

 

IMPORTANTE! Este vídeo não deve ser disponibilizado a terceiros e aos estabelecimentos, haja vista ser um material de demonstração interna de uso restrito ao Parceiro de suporte e seus colaboradores. 

 

 

17150: Aplicação de regra de venda pelo responsável da forma de pagamento

Casos de uso

1. Aplicação de regra de venda para o responsável do pagamento.

 

Pontos de solução

1. Adicionada a configuração "Usar resp. pgto na regra de venda" no lançamento padrão de pagamento que, ao vender pelo MódulaPDV, força a utilização do responsável do pagamento ao invés do cliente da venda na busca das regras para aplicar.

      1. Essa configuração poderá ser habilitada quando a "Operação de Caixa" for "Pagamento com vale".

      2. Por padrão essa configuração virá desabilitada.

 

2. Ao selecionar um pagamento que tenha essa nova configuração habilitada:

      1. Se o pagamento for informado no início da venda, até que seja exibida a tela de edição do pagamento, nenhuma regra de venda será aplicada, porque o responsável do pagamento ainda não pode ser informado.

      2. Se o pagamento preenchido na tela de fechamento da venda tiver a nova configuração habilitada:

          1. Será exibida a mensagem "Atenção: O valor a pagar será calculado na tela desse pagamento." na área de notificação.

           2. Se durante a venda dos itens foi aplicada regras de venda com alteração de valores, ao alterar a forma de pagamento no fechamento da venda em que o pagamento selecionado tiver a nova configuração habilitada, será exibida a mensagem "Atenção: Esse pagamento reinicia o subtotal para R$ [valor da venda sem regra de venda]." na área de notificação.

          3. O valor do pagamento não poderá ser informado nesse momento. O campo foi bloqueado para não mostrar valores de troco ou restante a pagar, já que o valor da venda poderá ser alterado com a aplicação das regras de venda na tela de edição do pagamento.

      3. Ao exibir a tela de edição do pagamento:

           1. As regras de venda serão aplicadas e, se o valor da venda mudar devido a alterações no pagamento, as mesmas mensagens exibidas no fechamento da venda serão exibidas nessa tela.

 

3. Reforçando, ao vender com o PDV Mobile ou lançar um DAV, se for selecionado um pagamento com essa configuração habilitada, o sistema não aplicará regras de venda, porque não temos o responsável do pagamento para realizar a aplicação das regras. 

 

17172: Criar recurso que permita identificar responsáveis secundários da venda através do uso de leitora

Casos de uso

1. Obrigar o uso de leitora em campo extra de seleção de pessoa no lançamento financeiro.

 

Pontos de solução

1. Disponibilizada a configuração 'Obrigar o preenchimento por leitora (quando campo for seleção de pessoa).' na seção de Regras na tela de inclusão/edição de campos extras dos lançamentos padrões.

      1. A nova configuração estará habilitada somente quando, nas definições gerais do campo extra, a configuração 'Opção de Uso' estiver vazia e na configuração 'Tipo do Campo' estiver selecionada uma opção com tipo de dado base 'Seleção em Tabela' e entidade 'pessoas'. Por padrão a nova configuração estará desmarcada. 

     Nota: O campo 'Opção de Uso' deve estar vazio pois a opção 'Identificação' não é compatível com o tipo de dados 'Seleção em Tabela'.

  

2. Alteradas as telas de abertura e de fechamento de venda no Módula PDV e a tela de edição dos lançamentos financeiros, para exigir que o preenchimento seja feito via leitor/digital nos campos extras em que isto estiver configurado.

      1. Nesses campos extras não será aceito o preenchimento manual. Ao tentar preencher manualmente será mostrada a mensagem 'Para o campo "<nome_campo>" é exigido que o preenchimento seja feito por leitor/digital.' e o conteúdo do campo será apagado.

      2. Para ser aceita, a identificação informada no leitor/digital deverá ser válida para a empresa de operação.

  

3. Alterado o componente de seleção que é disponibilizado nas telas do sistema para os campos extras com tipo de dado base 'Seleção em Tabela' e entidade 'pessoas', para possibilitar a pesquisa usando as identificações vinculadas à pessoa ou os códigos de busca.

      1. A pesquisa usando os códigos de busca será possível somente quando a coluna 'Código de Busca' estiver disponível no componente de seleção. 

 

2. - 024/2022: MELHORIAS

 

16742: Ajustes na apresentação de informativos do sistema

Casos de uso

1. Identificar os recursos e correções das versões liberadas do Novo Sigilo.

2. Identificar que existem novas versões liberadas do Novo Sigilo.

 

Pontos de solução

1. Alterados alguns dos termos que eram utilizados nos subtítulos dos informativos de versões do Novo Sigilo.

      1. O termo "CF-e" foi alterado para "Empresas não sujeitas ao PAF". O termo "CF-e" estava sendo erroneamente utilizado com o conceito de recursos liberados para empresas que não possuem o ambiente PAF.

      2. O termo "Tarefas" foi alterado para "Alterações".

      3. O termo "PAF-ECF" foi alterado para "PAF". 

 

17067: Impressão de campos extras no pedido/produção do ModFicha

Casos de uso

1. Imprimir outros campos da pré-venda no pedido/produção do ModFicha.

 

Pontos de solução

1. Alterado o sistema para imprimir os campos extras, que estiverem preenchidos na pré-venda, na impressão do pedido/produção do ModFicha.

 

17159: Permitir a exclusão de contagem de estoque proveniente de captura automática por medidor de tanque

Casos de uso

1. Excluir contagem de estoque capturada automaticamente via medidor de tanque.

2. Inserir contagem de estoque de tanque via assistente padrão de contagem.

3. Alterar/excluir contagem manual de estoque de tanque.

 

Pontos de solução

1. Liberada a exclusão de contagem de estoque que estiver marcada como 'Captura Automática', para os usuários que possuírem as permissões de deleção de 'Cadastro de Lançamentos de Contagens de Estoque' e de execução de 'Lançamento de Medições de Tanques (LMC)', ambas no grupo de permissões 'Produtos'.

 

2. Alterada a inserção, edição e exclusão de contagem de estoque de tanque, que não é proveniente de captura automática, para verificar a permissão de execução de 'Lançamento de Medições de Tanques (LMC)'.

      1. Na tela do assistente de inclusão de contagem de estoque, a permissão será verificada quando o usuário for informar a contagem para um produto em um tanque.

     2. Na tela de edição da contagem, se o depósito definido for um tanque ou houve troca de depósito e o depósito anterior era um tanque, a permissão será verificada quando o usuário salvar as alterações.

      3. Na tela de exclusão da contagem, a permissão será verificada quando o usuário confirmar a exclusão.

      Nota: As permissões de inclusão, alteração e de deleção de 'Cadastro de Lançamentos de Contagens de Estoque' continuarão sendo verificadas ao exibir os botões 'Inserir', 'Alterar' e 'Excluir' na listagem de contagens de estoque, independente do tipo de depósito das contagens.

 

17165: Permitir atualizar/editar os dados de responsável nas vendas com pagamento TicketLog

Casos de uso

1. Utilizar um pagamento com a operação de caixa 'Pagamento com Sitef TicketLog' no Módula PDV.

2. Alterar os dados de cliente de um DF-e que utilizou a forma de pagamento Sitef TicketLog.

 

Pontos de solução

1. Agora, ao realizar um pagamento com Sitef TicketLog, se a consulta realizada na TicketLog retornar dados de um cliente que está cadastrado no sistema, serão utilizados os dados do cadastro desse cliente no preenchimento dos dados da venda e não os dados retornados pela TicketLog.

  Nota: Foi observado algumas vezes que os dados de cliente retornados pela TicketLog estavam desatualizados, gerando rejeição por causa de inscrição estadual inválida. Assim, será dado preferência para os dados do cadastro de cliente que está no Novo Sigilo.

 

2. Se ocorrer algum erro na emissão do DF-e, referente a uma venda que teve os dados de cliente preenchidos pelo retorno da TicketLog, o sistema permitirá atualizar ou alterar alguns desses dados, conforme as seguintes regras e situações:

      1. Se for um cliente cadastrado, os dados do cliente serão atualizados com os dados do cadastro desse cliente ao abrir a tela de edição do lançamento financeiro. Não será permitido alterar o cliente.

      2. Se for um cliente não cadastrado, os campos dos dados de cliente serão habilitados para edição na tela de edição do lançamento financeiro, com exceção dos campos responsável e CPF/CNPJ.

      Nota: Reforçando que esse DF-e poderá ser uma venda com NF-e ou uma NF-e em substituição a doc. de venda (somente para substituição de cupom fiscal). 

 

17170: Atualização das DLLs da CliSitef para produção no instalador do Módula PDV

Casos de uso

1. Instalar ou atualizar o Módula PDV.

 

Pontos de solução

1. Atualizadas as DLLs do CliSitef para produção no instalador do Módula PDV.

 

17182: Validar a config. "Tipo de documento fiscal" do cadastro de cliente nas vendas com aplicações mobile

Casos de uso

1. Informar um cliente cadastrado na venda.

 

Pontos de solução

1. Alterado o sistema para respeitar a configuração de venda "Tipo de documento fiscal" disponível no cadastro de cliente, quando a venda for realizada pelas aplicações PDV Mobile e POSSitef.

 

2. Agora, ao informar um cliente cadastrado nas aplicações mobile, será validada essa configuração. Caso o tipo de documento da venda não seja compatível com o configurado, será apresentada a mensagem abaixo e o cliente não será definido na venda:

 'O cliente "<nome_cliente>" aceita somente tipo de venda igual a "<tipo_documento_fiscal>".'

 

3. Antecipada a validação que impede a emissão de NFC-e e CF-e para a própria empresa de sistema, pois somente era validada durante a emissão do documento fiscal no servidor. Agora, será realizada ao informar o cliente, tanto nas aplicações mobile como no Módula PDV e, em caso de rejeição, será apresentada a mensagem:

 'Não é permitido emitir <modelo_doc_fiscal> para a própria empresa (CNPJ: <cnpj_empresa>)

 

17185: Melhorias e ajustes na função de refazer a última venda

Casos de uso

1. Refazer venda no Módula PDV

 

Pontos de solução

1. Alterado comportamento ao refazer venda aberta com cupom fiscal onde, após selecionar uma nova venda com cupom fiscal, o sistema mostrava indevidamente a mensagem "Existe um documento aberto no ECF (COO=<número COO>) que não está relacionado a uma operação aberta no sistema. Deseja CANCELAR o documento somente no ecf para liberar o uso do mesmo?". Agora, o sistema cancelará a venda atual e recriará a nova venda sem mostrar essa mensagem.

  

2. Ao refazer a última venda, o sistema agora aceita que essa venda esteja cancelada.

     1. Item que foi cancelado não será registrado na nova venda.

     2. Caso essa venda possua algum abastecimento registrado, o mesmo não será registrado na nova venda e o operador será avisado por uma destas mensagens:

           1. No caso de cupom fiscal: "Os abastecimentos encontrados na venda origem com cupom fiscal, que está cancelada, não podem ser registrados na nova venda devido à regra do PAF-ECF."

          2. Para demais casos: "Os abastecimentos encontrados na venda origem, que está cancelada, não foram registrados na nova venda. Caso necessário, selecione os abastecimentos para baixá-los novamente.".

  

3. Os itens cancelados de vendas abertas que vieram de ficha não serão mais registrados em nova venda no caso de refazer venda com cupom fiscal.

 

4. Corrigido erro ao refazer a venda com itens tributados, onde a nova venda era com cupom fiscal. Ao tentar registrar o item no ECF, ocorria erro porque a alíquota não estava definida. 

 

17186: Alterações na integração com a TicketLog e liberação para o PAF-ECF

Casos de uso

1. Utilizar um pagamento com a operação de caixa 'Pagamento com Sitef TicketLog' no Módula PDV.

 

Pontos de solução

1. Liberada a utilização da forma de pagamento com a operação de caixa 'Pagamento com Sitef TicketLog' para vendas com cupom fiscal.

      1. A liberação contempla a grande maioria dos ECF em uso, exceto aqueles que identificam o cliente somente no início da venda, como Bematech MP-4000. Nesse caso não será permitida a utilização dessa forma de pagamento devido às complexidades para emissão de NF-e em substituição a cupom fiscal com combustíveis do PAF-ECF.

      2. No caso de venda com cupom fiscal que possui recolha de nota da TicketLog, será emitida uma NF-e em substituição ao cupom fiscal. Posteriormente, essa NF-e será enviada automaticamente para a TicketLog pelo SigServer, conforme documentado na tarefa 16660.

  

2. Agora, ao realizar um pagamento com Sitef TicketLog, a consulta que é realizada na TicketLog para obter os dados do cliente para preenchimento na venda, será realizada antes da confirmação da transação TEF. Sendo assim, o sistema recusará o pagamento se ocorrer a seguinte situação:

      1. Se a consulta retornar dados de cliente e ocorrer uma divergência de valor na venda, devido à aplicação de regras de venda ao definir o cliente retornado pela TicketLog. Nessa situação será apresentada a mensagem:

      "O pagamento não será confirmado porque houve divergência de valor ao aplicar as regras de venda para o cliente retornado pela TicketLog (<nome> e CNPJ <cnpj>).

     Informe esse cliente para tentar pagar novamente com TicketLog."

 

17191: Permitir a inclusão de produtos do tipo "kit" através do Ficha Mobile

Casos de uso

1. Operar pré-vendas através do Ficha Mobile.

 

Pontos de solução

1. Ajustado o Ficha Mobile para permitir registrar itens através de um produto do tipo "kit" na pré-venda. Reforçando que na pré-venda ficam registrados os itens da composição do "kit" e não o produto do tipo "kit". 

 

17200: Atualização da tabela de CFOP do sistema

Casos de uso

1. Emitir DF-e.

2. Registro de operação fiscal.

 

Pontos de solução

1. Atualizada a tabela de CFOP do sistema conforme o Ajuste SINIEF Nº 3, de 7 de Abril de 2022. 

 

17206: Atualização da Tabela do CEST

Casos de uso

1. Incluir/alterar cadastro de produto.

 

Pontos de solução

1. Atualizada a tabela de CEST do sistema. 

 

17208: Identificar desconto ou acréscimo na venda retornado pela administradora de cartão

Casos de uso

1. Identificar que houve desconto/acréscimo na venda retornado pela administradora de cartão.

 

Pontos de solução

1. Alterado o sistema para quando detectar um desconto ou acréscimo na venda, retornado pela administradora de cartão, esse valor possa ser identificado ao visualizar o lançamento financeiro da venda.

 

2. Agora, quando ocorrer essa situação, ao visualizar a venda pela tela do lançamento financeiro, na aba dos lançamentos de produtos, será apresentado um rodapé logo abaixo dos itens, onde poderão ser apresentadas as seguintes informações (conforme o retorno da transação de cartão):

      "Valor desc. TEF: R$ <valor_desconto_tef>."

     "Valor taxa serviço TEF: R$ <valor_taxa_servico_tef>.

 

17216: Alterações no layout da EFD ICMS/IPI para 2023

Casos de uso

1. Gerar a EFD ICMS/IPI

 

Pontos de solução

1. Ao gerar a EFD ICMS/IPI, se a data final for a partir de 01 de janeiro de 2023, a versão do leiaute informada no registro de abertura (0000) será 1.16 (código de leiaute = 017).

 

17224: Alterações no Bloco X do PAF-ECF para 2023

Casos de uso

1. Atender os requisitos do bloco X do PAF-ECF conforme Ato DIAT 46/2022 e Ato DIAT 55/2022.

 

Pontos de solução

1. Reativada a geração e o envio do arquivo de estoque do Bloco X do PAF-ECF. Esse envio ocorrerá uma única vez por ano conforme consta no Ato DIAT nº 017/2017. 

 

2. Adicionada as opções "Gerar ao FISCO-REDUÇÃO Z" e "Gerar ao FISCO-ESTOQUE" no "MENU FISCAL" do PAF-ECF.

      1. A opção "Gerar ao FISCO-REDUÇÃO Z" solicitará um período e um local para salvar os arquivos gerados.

           1. Serão gerados os arquivos de todos os ECFs do estabelecimento que tiverem realizado reduções Z no período selecionado.

           2. O nome do arquivo gerado terá o seguinte formato: "Redução Z DDMMAAAA_CodECF_CRZ", onde DDMMAAAA será substituído pela data de movimento da Redução Z, CodECF pelo código do ECF no sistema e CRZ pelo número da redução Z. O código do ECF e CRZ no nome do arquivo não estavam previstos no Ato DIAT e foram colocados por orientação do fisco, via CAF, para resolver conflito de nome de arquivo por ECF diferentes e mais de uma redução Z na mesma data de movimento num mesmo ECF.

      2. A opção "Gerar ao FISCO-ESTOQUE" apresentará as opções listadas abaixo e todas solicitarão um local para salvar o arquivo gerado.

           1. A opção "ESTOQUE ANO ANTERIOR" utilizará o último dia do ano anterior como data de referência para gerar o arquivo.

           2. As opções "ESTOQUE MUDANÇA DE TRIBUTAÇÃO", "ESTOQUE SUSPENSÃO OU BAIXA DE I.E" e "ESTOQUE MUDANÇA DE REGIME", solicitarão uma data de referência para gerar o arquivo.

           3. A opção "ESTOQUE ATUAL" utilizará a data atual como data de referência para gerar o arquivo.

           4. O nome do arquivo gerado terá o seguinte formato: "Estoque de Mercadorias AAAA", onde AAAA será substituído pelo ano da data de referência utilizada. 

 

17236: Permitir baixar abastecimento de bico do "Sem Parar" como aferição quando o tipo de pgto tem erro

Casos de uso

1. Registrar aferição para abastecimento capturado da bomba.

2. Venda de abastecimento que obriga o pagamento via Sem Parar.

 

Pontos de solução

1. Alterações e melhorias no registro de aferição a partir de um abastecimento capturado da bomba:

      1. Alterada a seleção de abastecimentos para o registro de aferição, para permitir que seja baixado um abastecimento que ficou com o tipo de pagamento como 'Erro', quando foi consultado no Sem Parar.

     2. Removido o botão 'Vender com Dinheiro (Ctrl+D)' da tela de seleção de abastecimentos para o registro de aferição, visto que não se trata de contexto de venda. 

  

2. Corrigido o erro 'Não há transação no evento.' que ocorria ao tentar vender um abastecimento que exigisse o pagamento via Sem Parar quando a venda ainda não havia sido aberta. 

 

17239: Não imprimir a tag infAdProd nos DANFE da NFC-e e NF-e Simplificado

Casos de uso

1. Emitir o DANFE NFC-e.

2. Emitir o DANFE Simplificado.

 

Pontos de solução

1. Ajustados os leiautes do DANFE NFC-e e do DANFE Simplificado para não mostrar os dados constantes na tag InfAdProd do produto no XML da nota, conforme a solicitação do Fisco. 

 

3. - 024/2022: CORREÇÕES

 

17171: Ambiente em homologação não está conseguindo ativar a licença do PAF-ECF

Casos de uso

1. Gerar autorização do Novo Sigilo para ambiente PAF-ECF em SC.

 

Solution Points

1. Corrigido o problema que não está sendo possível ativar a licença de uso do sistema Novo Sigilo de uma empresa com ambiente PAF-ECF em SC.

      1. O problema passou a ocorrer a partir da versão 7.8.0 quando os dados do arquivo 'ListaAutorizacaoMD5.txt', que contém os parâmetros do PAF-ECF, passaram a não ser mais enviados se a empresa não possui um ECF ativo. Nesse caso, na ativação de uma nova licença de uso no ambiente PAF-ECF, normalmente não existem ECFs ativos.

 

2. Para resolver o problema foi habilitado o campo de seleção 'PAF-ECF' da tela de autorização da licença de uso quando o ambiente estiver em homologação em SC, permitindo ao técnico habilitar ou desabilitar o PAF-ECF.

      1. Ao habilitar o PAF-ECF serão carregados os dados do arquivo 'ListaAutorizacaoMD5.txt' que estiver junto ao servidor.

 

3. Ajustado o comportamento ao solicitar a autorização da licença de uso para um cadastro de empresa com setor no ambiente PAF-ECF em SC.

      1. Nessa situação estava permitindo sair do PAF-ECF indevidamente, porque os ECFs ativos normalmente estão associados somente ao cadastro principal da empresa.

      2. Agora, nessa situação, será considerado o cadastro principal da empresa, ou seja, se o cadastro da empresa sem setor possui ECFs ativos. 

 

17174: Erro no processo de atualização automática do ModEstoque devido falta de uma pasta de log

Casos de uso

1. Atualização automática do ModEstoque.

 

Pontos de solução

1. Corrigido o erro "Error creating log file:  O sistema não pode encontrar o caminho especificado." que ocorria na atualização automática do ModEstoque quando a pasta "AppData\Local\ModEstoque\log" não existia.

  Nota: O problema poderia ocorrer com outras aplicações clientes do Novo SIGILO, se a respectiva pasta de logs não existisse. 

 

17207: "AV" no processamento de lote após nota ser rejeitada por duplicidade gerando várias inconsistências

Casos de uso

1. Realizar venda de mercadorias com NFC-e.

2. Emissão de NF-e

 

Pontos de solução

1. Corrigido o erro de "Access violation" que poderia ocorrer na emissão de NF-e e NFC-e, quando houvesse perda de conexão com a Sefaz e o sistema tentasse reenviar uma nota que já foi autorizada pela Sefaz.

 

17209: Erro ao gravar registro de perda de comunicação no ModPosto em ambiente PAF

Casos de uso

1. No ambiente PAF-NFC-e e PAF-ECF:

     1. Perda de comunicação com bicos;

     2. Retorno de comunicação com bicos.

 

Pontos de solução

1. Correção do erro "UNIQUE constraint failed...", que poderia ocorrer na identificação de perda prolongada de comunicação do PAF, caso ocorresse queda de luz ou parada abrupta do ModPostoServer logo após um retorno de comunicação e, ao reiniciar o ModPostoServer, a comunicação com o bico estivesse novamente perdida. Além disso, o mesmo erro poderia acontecer, na perda ou retorno de comunicação, caso a data/hora do computador voltasse, o que também foi corrigido.

 

2. Em ambiente com PAF-NFC-e, o bloqueio de bicos por perda prolongada de comunicação do PAF foi retirado, pois não se aplica.

 

3. Correções para ambiente PAF-ECF:

      1. Corrigido o retorno automático de comunicação de bico onde, após uma perda prolongada de comunicação do PAF-ECF, o bloqueio por perda de comunicação prolongada do PAF-ECF, caso configurado, tinha grande chance de não ser removido, bloqueando os bicos.

      2. Corrigido o bloqueio por perda de comunicação prolongada do PAF-ECF, que não estava sendo aplicado imediatamente quando uma perda de comunicação prolongada era identificada.

       3. Corrigida a hora da perda de comunicação prolongada do PAF-ECF, que poderia ficar anterior ao início do ModPostoServer, no caso da comunicação ter sido perdida e o ModPostoServer parado e reiniciado posteriormente. 

 

17219: Hash MD5 inválido no campo 'validador' na solicitação para o SemParar

Casos de uso

1. Consultar um abastecimento no webservice do Sem Parar.

 

Pontos de solução

1. Corrigido o preenchimento do campo 'validador', na solicitação enviada pelo ModPosto ao webservice do Sem Parar, que estava impedindo o Sem Parar de conseguir verificar corretamente o abastecimento solicitado, fazendo com que a forma de pagamento permitida para os abastecimentos ficasse com erro ou incorreta.

 

17221: Botão "Salvar" fica desabilitado na tela p/ informar o vendedor exigido no item ao baixar pré-venda

Casos de uso

1. Baixa de pré-venda com itens que obrigam o vendedor.

 

Pontos de solução

1. Corrigida a tela de edição do lançamento de produto que é mostrada, durante a baixa de pré-venda no Módula PDV, para os itens sem vendedor preenchido e que exigem essa informação, pois o botão 'Salvar' ficava desabilitado quando a tela era aberta com um vendedor já sugerido.

 

17223: "Cód. tipo evento financeiro (Cód=99) não foi localizado" ao cancelar NF-e em subst. no Módula PDV

Casos de uso

1. Cancelamento de NF-e emitida em substituição a documento de venda no Módula PDV

 

Pontos de solução

1. Corrigido erro "Cód. tipo evento financeiro (Cód. = 99) não foi localizado." ao tentar cancelar uma NF-e emitida em substituição a documento de venda através da opção 22 do menu do Módula PDV. 

 

17229: Ajustes e correção de problemas para homologação com o 'Sem Parar'

Casos de uso

1. Consultar um abastecimento no webservice do Sem Parar.

 

Pontos de solução

1. Corrigida formatação da mensagem de consulta enviada pelo ModPosto ao webservice do Sem Parar, para a qual o Sem Parar respondia com o erro 99, fazendo com que a forma de pagamento permitida para os abastecimentos ficasse como 'Erro' ou incorreta.

 

2. Corrigido o processamento, no ModPosto, da resposta recebida do webservice do Sem Parar, que estava gerando o erro "nsuTerminal retornado na resposta () do Sem Parar é diferente do enviado na solicitação...", quando o abastecimento não pertencia ao Sem Parar ou quando a resposta recebida informava algum erro, escondendo o erro original e dificultando a análise de problemas.

 

3. Retirada a validação do número de solicitação das mensagens ao Sem Parar (nsuTerminal), devido a ele não devolver esse número, o que gerava erro na comunicação. 

 

17232: Sistema gera AV ao tentar usar um PDV PAF NFC-e para posto sem ModPosto configurado

Casos de uso

1. Realizar venda no Módula PDV em ambiente PAF-NFC-e.

 

Pontos de solução

1. Melhorada a mensagem de erro do fechamento diário de encerrantes do PAF-NFC-e no Módula PDV, que pode ser mostrada ao iniciar uma venda com uma empresa que é posto de combustível, quando não há um ModPosto configurado ou não há conexão com o ModPosto. 

 

17233: Tratamento para o campo nome_produto_tef quando CliSitef retornar 00000 no código da bandeira

Casos de uso

1. Realizar pagamento com cartão através da CliSitef.

 

Pontos de solução

1. Corrigido o problema do campo "nome produto TEF" ficar com a informação "Band. Sitef: 00000" no lançamento de pagamento com alguns cartões específicos via CliSitef, como cartões Softnex e Qualidade.

 Nota: O campo "nome produto TEF" é utilizado pelo sistema para tentar definir a conta de débito do pagamento. Se essa informação não estiver correta, o sistema não realiza essa definição.

 

2. Agora, nessa situação, o sistema utilizará o campo "Nome da instituição", retornado na transação de cartão, para definir o conteúdo do campo "nome produto TEF".

 

17234: Módula PDV escolhe a forma de pagamento aleatoriamente na recarga de celular com pagamento TEF

Casos de uso

1. Recargas com pagamento em cartão ou cheque.

 

Pontos de solução

1. Corrigido o problema que ao realizar uma recarga (celular ou outros produtos) com pagamento em cartão ou cheque, o Módula PDV estava selecionando automaticamente a forma de pagamento sem um critério definido, ou seja, poderia selecionar uma forma de pagamento que seria de uso exclusivo para uma determinada situação.

  

2. Agora, o sistema tentará localizar as formas de pagamento compatíveis com o retorno da transação TEF.

     1. Primeiro o sistema verificará se existe uma associação entre o produto Sitef retornado na transação TEF e uma forma de pagamento. Se existir, o sistema tentará utilizar essa forma de pagamento.

          Reforçando: as formas de pagamento que possuem associação com produtos Sitef são de uso exclusivo com os seus respectivos produtos Sitef. Sendo assim, essas formas de pagamento não serão apresentadas para o operador selecionar na recarga.

     2. Se não existir, o sistema tentará localizar formas de pagamento com Sitef que possuam o tipo de transação permitida compatível com o retorno da transação TEF e que não possuam associação com produtos Sitef.

           1. Assim, por exemplo, para um pagamento com cartão de débito, o sistema tentará localizar formas de pagamento com Sitef configuradas com o tipo de transação permitida igual a débito. Caso não localize por esse critério, tentará localizar formas de pagamento com Sitef configuradas com o tipo de transação permitida igual a todas. Para pagamento com cartão de crédito, será feito tratamento similar, porém tentando localizar inicialmente formas de pagamento configuradas com o tipo de transação permitida igual a crédito ou crédito à vista.

      3. Se o sistema localizar mais de uma forma de pagamento compatível com o retorno da transação TEF, será apresentada a lista com essas formas de pagamento para o operador selecionar a desejada.

  

3. Se o sistema não encontrar uma forma de pagamento compatível com o retorno da transação TEF, será apresentada a mensagem abaixo e a transação da recarga não será confirmada:

      'Não foi localizada uma forma de pagamento compatível com o pagamento realizado (Operação de caixa: <descrição operação de caixa> e Tipo transação cartão: <descrição tipo transação cartão>).'

      Ex: 'Não foi localizada uma forma de pagamento compatível com o pagamento realizado (Operação de caixa: Pagamento com SiTEF e Tipo transação cartão: Débito).'

  

4. Dica: Pode-se cadastrar, no tipo do evento financeiro de recarga, lançamentos padrões de pagamento como 'Proibido'.

      1. Esse recurso permitirá restringir mais especificamente quais as formas de pagamento que o sistema poderá selecionar automaticamente na recarga. 

 

17242: O PDV não aplica regra de tabela para um produto quando registrado como o primeiro item da venda

Casos de uso

1. Venda de mercadorias com regra de venda de tabela para um produto.

 

Pontos de solução

1. Corrigido o problema que não aplicava corretamente a regra de venda do tipo tabela vinculada a um produto, quando esse produto era registrado como primeiro item da venda. Agora, o preço praticado será conforme a tabela da regra.

 

17241: Produção automática está ajustando as contagens dos insumos indevidamente

Casos de uso

1. Executar a produção automática de produtos compostos de forma automática pelo servidor ou comandada manualmente pela retaguarda.

 

Pontos de solução

1. Corrigido o problema da produção automática de produtos compostos ajustar as contagens de insumos indevidamente, pois esse ajuste já é antecipado no registro dessas contagens.

      1. Reforçando que a produção manual de produtos compostos mantêm o comportamento, ou seja, poderá ajustar as contagens realizadas.

 

2. Ajustada a hora de operação dos lançamentos de produção automática de produtos compostos, que ficava com hora 00:00:00.

     1. Agora, quando a data de movimento da produção for diferente da data atual, será definida a hora de operação com 23:59:59 (a data de operação já era definida com a data de movimento).

     2. Reforçando que, se a produção automática for comandada manualmente para o dia corrente, a data/hora de operação continuará sendo definida com a data/hora corrente.