Painel de líderes

Boa tarde! Segui o link: https://www.projetoacbr.com.br/forum/topic/44051-erro-12175-um-ou-mais-erros-foram-encontrados-no-certificado-secure-sockets-layer-ssl-enviado-pelo-servidor/ Esse link acima me ajudou fui tentando fazer de tudo que postaram ai deu certo. Obrigado.

Geralmente este erro é causado pelos seguintes fatores. Infecção por vírus. Incompatibilidade dos drivers instalados. Falhas no hardware. Sistema operacional corrompido. Em qualquer caso, um técnico especializado poderá resolver seu problema. Já tivemos esse erro aqui e o problema era a placa de vídeo.

Problema solucionado. Inadvertidamente alguém informou um proxy. Obrigado.

Italo, esquece eu esqueci de tirar o .nfse deu certo, vou começar a listar as nfes emitidas para fazer o cancelamento e te falo se deu problema. obrigada novamente

Boa tarde Oliveira, Note que essa tag é opcional logo precisamos de um valor para dizer que ela não deve ser gerada. Sendo assim acrescentei o enumerador: prpNenhum que vale zero. Se não é para gerar a tag você deve atribuir esse valor ao respectivo campo ou um dos outros 2 disponíveis. Mesmo assim, muito obrigado por informar que estava gerando de forma errada.

Complementando a resposta do Italo: NT 2018.001 06. Serviço: Pedido de Inutilização de numeração (item 4.4 do MOC) 06.1 Leiaute do Pedido de Inutilização (Item 4.4.1 do MOC) Para as empresas (pessoa jurídica) existe a operação de Inutilização de Numeração, que registra a numeração da Nota Fiscal que foi inutilizada pela empresa. Ou seja, a empresa informa que esta numeração não será utilizada. O controle de Inutilização de Numeração não será aplicado para o emitente pessoa física. Nota: O leiaute atual do Pedido de Inutilização não prevê a informação do CPF do emitente.

O correto talvez fosse você pedir o cliente para se cadastrar. Por outro lado, talvez você queira fazer o download e disponibilizar você os arquivos para seus clientes. Talvez por FTP.

Senhores, Publicada PORTARIA SAIF Nº 033/19 que prorroga a data de obrigatoriedade de emissão do Bilhete de Passagem Eletrônico definida pelo Ajuste SINIEF 22/18, de 01 de julho de 2019 para 01 de outubro de 2019. http://www.sped.fazenda.mg.gov.br/spedmg/bpe/

Verifique o Visualizador de Eventos do Windows. Ele costuma trazer mais informações sobre as falhas do sistema.

Sua pergunta "boba" foi certeira. Na Bahia o token esta correto já no ES o meu cliente colocou o numero do certificado em vez do Token valeu.

pergunta boba.. o token está certo?

O Fato é que o SEFAZ está descontinuado esse serviço... o novo site usa um Recaptcha que nós não conseguimos interagir por programação... Até o Momento, não conhecemos um novo WebService do SEFAZ que possa fornecer gratuitamente essas consultas

Quer dizer que o XML está sem o protocolo de autorização.

Boa tarde, O verificador da Tanca guarda compatibilidade com o protocolo Gertec, é muito possível que funcione sem ajustes.

Perfeito Marcelo, Resolveu meu problema. Muito obrigado.

Boa tarde, Me recordo que houve alguma situação anterior que gerou sim esta mudança, mas em todo caso não seria mais simples sua aplicação já enviar ao componente o valor com 2 casas decimais? Att.

Boa tarde, ok, agradeço por ser de verdade, porque como nunca tinha recebido e vivo acessando de maquinas diferentes e windows diferentes também fiquei com medo de tantos fork´s que depois roubam dados etc... tipo aqueles de bancos, valeu HASA

Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Fonte:https://dfe-portal.svrs.rs.gov.br/Mdfe/Avisos/137

Boa tarde, Temos mudança sim no arquivo ACBrMDFeServiços, pois agora temos um webservice especifico para recepcionar os MDF-e que forem enviados no modo Síncrono. E acredito que teremos que ter uma opção no ACBrMonitor onde você possa configurar se deseja Modo Síncrono ou Assíncrono. Pela que andei lendo futuramente teremos somente o envio no modo Síncrono do MDF-e, visto que o envio sempre foi unitário, ou seja, sempre foi enviado somente 1 MDF-e de cada vez.

Boa tarde Vinício, Note que o XML que o componente esta gerando é o de consulta a situação do lote, já o modelo que lhe passaram se refere a consulta ao lote. O componente possui um método para cada tipo de consulta.

Boa tarde Melissa, Note que agora não ocorre o erro referente a assinatura no retorno da consulta a situação. O erro de assinatura agora esta ocorrendo ao realizar a consulta ao lote. Veja bem: temos o envio e retorno do envio, consulta a situação do lote e retorno a consulta a situação, por fim temos a consulta ao lote e o seu respectivo retorno. Será necessário fazer a mesma alteração que fiz na montagem do XML da consulta a situação, só que agora no XML da consulta ao lote. Por favor, atualize novamente e faça novos testes.

compreendi! Obrigado pelo retorno

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tópico fechado por falta de retorno do usuário

Acho que isso foi implementado nas novas versões do Invision Community (anteriormente conhecido como Invision Power Board ou IPB) que é a plataforma que usamos pro fórum. Isso é uma medida de segurança a mais. Visto que se alguém tentar logar em sua conta, você será avisado. E claro que todos devem se preocupar com segurança.

Marcio, Muito obrigado, fiz de forma diferente da sua, enviei para o repositório, favor atualizar e faça novos testes.

Bom dia, Obrigada por informar, adicionado ao calendário ACBr. Tópico movido para a sessão de noticias. Att.

Bom dia Marcelo, Já enviei para o repositório a sua alteração, mais uma vez muito obrigado pela colaboração.

Bom dia, No manual CobrancaEletronicaBanrisul_pdr400_vrs14012019_ed13.pdf(Leiaute CNAB 400 Posições Padrão Febraban) A principio diz que . 157-158 e 159-160 podem ser preenchidas indiferente da ordem e não podem ser repetidas,bem como você @Juliana Tamizou mencionou acima. Obrigado pela atenção.

Bom dia Marcio, Você poderia anexar o XML de retorno de uma consulta para que possamos analisar melhor a sua alteração. Um XML quanto acha a nota e outro XML quando não acha a nota na consulta.

Bom dia. Obrigada pela contribuição, adicionada para validação. Att.

Bom dia ALA, Caso queira contribuir com o projeto basta pegar uma das Units: pnfseNFSeW_xxxx.pas copiar com o nome pnfseNFSeW_SigISS e fazer as alterações necessárias para que ela gere o XML conforme o manual. Esse é o primeiro passo. Depois é preciso alterar a unit pnfseNFSeW.pas para que ela reconheça a unit nova. Por fim iniciar os testes.

Bom dia. Esta orientação do banco condiz com o manual? É estranho pq até o momento não houveram rejeições devido a isto, além do fato de que normalmente os campos de instrução, exceto quando a informação de um completa a do outro, não precisam ter ordem certa. Att.

Bom dia. Por favor evite copiar o conteúdo do arquivo, ao invés disso, anexe o mesmo. Qual é o modelo do SAT? Att.

Bom dia. Seus fontes estão atualizados? Recentemente foi feita uma revisão nas URLs devido a mudanças em todas as SEFAZ. Att.

Bom dia. Por que você esta compilando do branches? A versão atualizada é a do Trunk. Att.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

use o pesquisar do forum que ira encontrar muita informacao. segue um link muito bom

Revisei a documentação aqui e, de fato, o vItem é calculado pelo SAT e não aparece no XML. Ele é calculado baseado no SAT baseado em qCom, vUnCom, etc. Falha minha! rs Mesmo assim, ainda enfrento o problema, mesmo com todos os campos com RoundABNT

@Juliana Tamizou obrigado pelo retorno, não vi, não olhei em Noticias. @Italo Jurisato Junior obrigado pelo post, ficou bem claro. Creio que possa ser encerrado. Abraços

Esta usando todos os INIs iguais ao do exemplo. Estou batalhando na verificação do componente. Verificando todos os processos do exemplo, mas até agora sem sucesso. A minha aplicação está na mesma maquina que foi testado o exemplo. Vou analisar novamente..

De forma semelhante ao material disponibilizado pela SEFAZ-MG, a SEFAZ-SP também publicou em seu portal a relação das regras de validação facultativas a UF da NT 2019.001 as quais a mesma exigirá. Clique aqui para visualizar a tabela publicada no portal da SEFAZ-SP.

A SEFAZ-MG publicou em seu portal de notícias links com a documentação descrevendo quais regras facultativas a UF serão exigidas no esta de MG. Se desejar, veja documento anexo,, ou acesse o link da noticia no portal da SEFAZ-MG, clicando aqui. Att. NT-2019-Regras.pdf

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

E quando terceiros prestam serviço de manutenção? Quem é o responsável técnico? Dúvidas assim podem surgir quando fixamos na mente mais a ideia de um "representante da classe de programação" perante a lei do que na ideia de um responsável pelo sistema. Talvez isso aconteça porque o termo usado é "responsável técnico". Logo nos vem a mente um engenheiro responsável pela obra e tal... Mas veja bem, a ideia do responsável técnico, é ter uma "pessoa" para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor do DF-e. Como dito antes, suponha que o software emissor tentou retransmitir a mesma NF-e com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o mesmo XML que já sabia era rejeitado, isso por 70 mil vezes. Nesse caso, quem a SEFAZ deveria contatar? Pensar nesses termos, nos ajuda a entender o motivo das tags Responsável Técnico e assim saber como preencher. Vamos a dois exemplos, com base nas perguntas desse link: Imagine uma microempresa, distribuidora de produtos de limpeza, que para emitir a notas fiscais, paga a um programador fazer as alterações nos fontes de um sistema emissor. Esse programador é pessoa física. Como fica esta situação? Não se engane. A resposta depende mais do tipo do vínculo entre eles e menos de o programador ser uma pessoa física. A questão que deve ser respondida é: Quem é o responsável pelo software? Quem a SEFAZ deve contatar caso queira falar sobre o sistema? Isso vai depender de cada caso e talvez de cada UF. Responder algumas perguntas podem ajudar a resolver a questão: Atualmente, o sistema é da ME distribuidora de produtos de limpeza? O programador é chamado como um terceirizado ou mesmo como funcionário temporário da empresa, não tendo de fato vínculo com o sistema? Por exemplo, ele pode ser substituído por outro programador? (Note, não importa aqui o conhecimento interno do sistema...) Se a resposta a essas perguntas for sim então, a menos que algo diferente esteja em contrato, o responsável técnico é a empresa distribuidora de produtos de limpeza.  Ela contrata outra pessoa para dar manutenção mas, ainda assim, ela é responsável, porque o sistema é dela. No PAF-ECF, chamávamos isso de "sistema próprio". Quer dizer próprio da empresa. Não é um sistema que ela aluga. Caso alguma resposta para as perguntas for não, então, provavelmente, o responsável técnico é o programador. Será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ. No caso da empresa ter uma pessoa que saiba programação e faça estas alterações mas não é programador registrado e sim diretor ou gerente ADM, como fica? Nesse caso, sem dúvida, o responsável técnico é a própria empresa. Ela tem um sistema próprio, desenvolvido internamente para emitir os DF-e. Não importa se quem faz as alterações é um programador ou o contínuo da empresa. O importante é quem é responsável perante a SEFAZ e, nesse caso, é claro que a SEFAZ não vai querer saber quem deu manutenção no sistema. Quando ela precisar falar com um responsável, ela vai querer contatar diretamente a empresa. Afinal de contas, se a empresa não quisesse isso ela teria contratado um sistema de alguém ao invés de permitir um funcionário (ou sobrinho do dono) criar o sistema.

Bom dia Daniel, Você utilizou o componente ACBrCIOT que se encontra no Branches? Se sim, foi necessário fazer algum ajuste? Se sim, poderia anexar aqui as units que você alterou para poder realizar o envio para o Webservices do e-Frete?

Boa tarde, Os provedores que seguem a versão 1 do ABRASF só tem implementado em seus Web Services o Serviço Enviar, logo os outros 2 não tem como usar. Por outro lado os provedores que seguem a versão 2 do ABRASF costuma ter os 3 métodos. Já os provedores que não seguem a ABRASF, é preciso abrir o arquivo INI do mesmo para saber o que esta disponível. Qual é a diferença entre eles? Enviar -> permite enviar um lote com até 50 RPS e o modo de envio é assíncrono. EnviarSincrono -> permite enviar um lote com até 50 RPS e o mode de envio é síncrono Gerar -> permite enviar somente UM RPS, tem uns 2 ou 3 provedores que permitem o envio de até 3 RPS através desse método.