Painel de líderes

Após uma atualização do Windows Update nos sistemas operacionais Windows 8 a 10, vários usuários começaram a ter problemas na conexão segura com o SEFAZ.... Onde geralmente foram exibidos os erros abaixo: Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor Erro: 12169 - O certificado SSL é inválido Erro: 12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura Estes erros indicam uma falha na validação do certificado do servidor da SEFAZ, e entre as diversas causas que podem disparar este erro, podemos citar: Falta da cadeia de certificados instalado no cliente. Cadeia de certificados desatualizados. Erro no componente de validação do Windows. Erro no certificado da SEFAZ. SEFAZ enviou um certificado invalido. O problema foi confirmado pelo SEFAZ do PR, no comunicado abaixo: Para os usuários do Projeto ACBr, esse problema afetou apenas quem utiliza os componentes configurados com as bibliotecas Wincrypt ou CAPICOM pois os mesmo utilizam o sistema de validação do Windows. O problema não afetou usuários que usam a biblioteca OpenSSL. Em decorrência do problema, aplicamos um ajuste nos fontes da ACBrDFeSSL, visando ignorar erros na validação do certificado. Com isso a comunicação Segura ocorrerá normalmente... Os fontes alterados já se encontram no SVN... e excepcionalmente, efetuamos uma nova compilação do ACBrMonitorPLUS v 1.2.0.52, para os usuários do SAC Saiba mais sobre comunicação Segura do ACBr

Você está carregando o .fr3 para impressão em A4. Para impressão em bobina use o DANFeNFCe4_20.fr3.

Se não me engano foi feita uma correção para impressão em A4 que é como está saindo na imagem 2. Para impressão como na imagem 1 use: Modelo: Fortes Modo de impressão: Bobina

Após a atualização para 1.2.0.50 está funcionando corretamente. Obrigado.

Boa tarde @Italo Jurisato Junior Hoje conseguimos falar com o suporte da NFSe de Tangará da Serra - MT. Desde 31/03 eles mudaram de provedor, trocaram WebISS para RLZ. Conforme conversamos no dia 19/03 por causa das mudanças no cidades.ini, pois você fez a alteração para o RLZ, porém não haviam mudado ainda. Agora já esta no ar o novo provedor. 5107958] Nome=Tangara da Serra UF=MT Provedor=RLZ NomeURL_H=mt/tangaradaserra NomeURL_P=mt/tangaradaserra Antes estava assim : Nome=Tangara da Serra UF=MT Provedor=WebISS NomeURL_H=tangaradaserramt NomeURL_P=tangaradaserramt Dercide.

Após várias tentativas e consulta a colegas, tive entrar em contato com a SEFIN e lá me informaram que o CSC para homologação é solicitado diretamente ao orgão pelo contador, pois não possui um fomulário de solicitação pelo portal do contribuinte. Após a solicitação realizada, foi gerado um CSC para HOMOLOGAÇÃO, e consegui emitir as NFCe.

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

Se tiver dúvidas, sugiro ver o vídeo com o passo a passo emitindo uma NFe, tem um .ini exemplo:

estou tambem mandando outro exemplo ent.txt

Boa tarde, josadac. MG não está normal, foi habilitado até o modo de contingência desde semana passada, veja abaixo:

Sugiro você aumentar esse TimeOut para pelo menos 10. É o padrão que usamos atualmente para comunicação serial. Além disso, se a informação que o Daniel postou não resolver, ao invés de colocar vários sleeps a cada comando, você pode alterar a propriedade SendBytesInterval para um valor maior que zero.

Você pode usar a Tag </lf> para Pulo de Linha Crio que o problema seja Buffer Overflow, na Serial... Por favor veja explicações sobre isso.. nesse tópico: Experimente definir 8K e intervalo de 100m ACBrPosPrinter.Device.SendBytesCount := 8192 ACBrPosPrinter.Device.SendBytesInterval := 100

Estamos com o mesmo problema, e é culpa da SEFAZ de PE que não está retornando estas informações. O mais estranho é que só está acontecendo para clientes de MG...

Eu utilizei como mencionei a cima, mas acho q descobri a razão do erro...Esses campos só vão entrar em produção 07/05/2019 ai não vai mesmo....

Boa tarde, daniel_paixao. Sugiro você a não utilizar Capicom, a mesma já está obsoleta. Tente as configurações abaixo: Funciona para A3 e A1: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsLibXml2; SSLType := LT_TLSv1_2; Somente para A1: SSLCryptLib := cryOpenSSL; SSLHttpLib := httpOpenSSL; SSLXmlSignLib := xsLibXml2; SSLType := LT_TLSv1_2 Veja também o video e anexo do tópico abaixo:

Bem lembrado... Delphi 7 e anteriores, já disparam uma assustadora janela, no Win10, acusando como aplicação obsoleta... acho que é questão de tempo que os binários gerados por essa IDE sejam também considerados binários obsoletos...

Acho que precisamos um pouco mais de informações. Dependendo de onde você está visualizando ou copiando não tem como tirar essas aspas no início e no fim. Elas estão indicando que o conteúdo é string. Se for isso, não tem como remover. Talvez seja melhor você verificar os logs do ACBrPosPrinter, tanto do demo como de sua aplicação para comparar.

autorizador em contingência para MG é o 8-SVC-SP. Ao que parece essa resposta é para a consulta de status de serviço. Porém o serviço de envio normal de MG está funcionando.

Alguns clientes meus que usam certificado A3 tiveram problemas nessa semana com o erro (Erro Interno: 12169), como não encontrei a solução aqui no acbr, estou postando onde eu encontrei a solução. http://www.nfe.go.gov.br/post/ver/232392/contribuintes-com-problemas-para-emissao-de-nf-e-e-nfc-e

Fizemos o procedimento usando certmgr.msc em duas máquinas com Windows 7 e também deu certo. Obrigado, Gilberto.

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

BigWings, Obrigada, foi realmente isso ?

Bom dia. Sem problemas, mas nestes casos você pode sempre criar um novo tópico. Att.

Bom dia, Obrigada pela informação. Att.

Bom dia! Tudo bem com vocês? O problema esta relacionado ao certificado digital. Para resolver, basta remover a cadeia de certificados da pasta/aba "Autoridades de Certificação Raiz Confiáveis". (Remover todos certificados desta pasta/aba). Em seguida , basta atualizar as cadeias de certificado utilizando o instalador anexo. Lembrando que o mesmo deve ser executado como administrador. Um abraço a todos. InstaladorCadeiaV2.exe

Sim, eu pensei que este método fosse do objeto ACBR também...

José M.S. Junior, obrigado problema resolvido.

Apenas alguns usuários conseguem efetuar o commit... Você precisaria compactar os fontes, organizando-os por pastas, e anexar nesse tópico, para analise de algum desenvolvedor com acesso ao commit

Exato.. A partir o primeiro erro de falta de retorno da sefaz por exemplo ou falha de conexão de internet, já procede para alteração automatica para emissão em contingencia, e assim emitindo normalmente em sequencial das numerações e em contingencia offline. O manual trata apenas para caso de envio e sem retorno do status da nota, fazendo assim a necessidade de liberar a venda do cliente com uma numeração seguinte para evitar que gere a mesma numeração desta que deu falha de retorno e ao transmitir a sefaz esta mesma nota, obter o retorno de duplicidade de chave de acesso com diferenca ... assim tendo a nota normal recebida na sefaz, porem o cliente possui uma nota em contingencia que nunca será autorizada na sefaz visto que o tipo de emissão é diferente daquele registrado e recebido na sefaz. Precisa tratar automaticamente a emissão da contingencia, seja manual ou por usuário a partir do primeiro caso de falha de retorno da sefaz ou falta de internet.

Não existe nenhum bloqueio por parte do webservice para emissão de NFe ou NFCe com numeração anterior a uma já autorizada, entretanto isso não é recomendável por que a SEFAZ pode suspeitar de fraude. Sugiro que entre em contato com o contador para que ele oriente o que fazer. A rejeição é apenas pela data e hora de emissão da NFCe ser superior a 5 minutos em relação a data e hora de recebimento no webservice. Configuração de fuso horário incorreto pode causar isso.

Olá, foi enviada uma correção para isso na revisão 1827 no SVN. Mas tenha cuidado ao utilizar esses métodos RegistroXXXXNew. Como você descobriu, eles nem sempre avisam da herança. Prefira os métodos Bloco.RegistroXXXX.RegistroXXXX.new. Por exemplo: Bloco_C.RegistroC001.RegistroC300[n].RegistroC320.New; Assim você tem certeza que está seguindo o layout do SPED.

Vão em um pc que está FUNCIONANDO, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A clica com o botão direito, TODAS AS TAREFAS e EXPORTAR, avança ate pedir a senha. Põe num pendrive, depois vá no pc com problemas e faz a mesma coisa, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A e deleta tudo, depois de deletar é só clicar com o direito de novo na parte que ficou em branco e importar o certificado que você exportou da maquina que estava boa na hora de escolher o local para armazenar não esqueçam de colocar ele no repositório (Autoridades Certificação Raiz Confiável) e pronto, tudo funcionando de novo, testei em vários windows, 7, 10, e 2012, todos funcionaram perfeito em mais de 10 clientes diferentes. coloquei a minha Cadeia de certificados boa aí. Cadeia de Certificado, senha 123.pfx Vão em um pc que está FUNCIONANDO, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A clica com o botão direito, TODAS AS TAREFAS e EXPORTAR, avança ate pedir a senha. Põe num pendrive, depois vá no pc com problemas e faz a mesma coisa, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A e deleta tudo, depois de deletar é só clicar com o direito de novo na parte que ficou em branco e importar o certificado que você exportou da maquina que estava boa na hora de escolher o local para armazenar não esqueçam de colocar ele no repositório (Autoridades Certificação Raiz Confiável) e pronto, tudo funcionando de novo, testei em vários windows, 7, 10, e 2012, todos funcionaram perfeito em mais de 10 clientes diferentes. coloquei a minha Cadeia de certificados boa aí. Cadeia de Certificado, senha 123.pfx

Boa tarde a todos, Alguns já devem ter visto na estrutura do XML um grupo chamado autXML. O que vem a ser esse grupo? Trata-se de um grupo opcional que permite informar até 10 CNPJ ou CPF de pessoas que estão autorizadas a baixar o XML completo, pessoas estas que não figuram com atores do documento fiscal eletrônico em questão. Por exemplo: em uma NF-e temos os seguintes atores: Emitente, Destinatário e Transportador. O Emitente por ser o responsável por emitir a NF-e, tem por obrigação possuir o XML do documento e disponibilizar o mesmo para os outros dois. O Destinatário por sua vez poderá baixar o XML da NF-e através do DistribuicaoDFe já explicado nesse tópico, mas se faz necessário enviar o evento de Manifestação do Destinatário. O Transportador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Mas eu gostaria que o contador da minha empresa pudesse também baixar o XML, isso é possível? Sim, basta incluir o CNPJ ou CPF do seu contador no grupo autXML. Desta forma o Contador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Lembre-se o único que não consegue baixar o XML é o Emitente do próprio documento, os demais conseguem baixar o XML completo (assinado e com o protocolo de autorização) desde de que seja um dos atores ou faça parte da lista do grupo autXML. Até o momento somente o Destinatário da mercadoria se faz necessário enviar o evento de Manifestação do Destinatário para poder baixar o XML completo, caso contrario terá somente um XML contendo um resumo da nota. O grupo autXML esta presente nos seguintes documentos fiscais eletrônicos: NF-e / NFC-e, CT-e / CT-e OS, MDF-e e BP-e. No caso do BP-e ainda não foi disponibilizado o DistribuicaoDFe para que seja possível baixar o XML. E também não esta disponível a baixa do XML da NFC-e pelo DistribuicaoDFe. Em caso de dúvidas, favor criar um novo tópico em: https://www.projetoacbr.com.br/forum/forum/3-dúvidas-gerais-sobre-o-acbr/

Mapa Fiscal do Projeto ACBr - Situação das Técnologias Fiscais do varejo Como os desenvolvedores que atuam com emissão de documentos fiscais a nível nacional já perceberam a um bom tempo, cada estado tem autonomia para definir sua própria tecnologia fiscal, ou seja, tem seu próprio RCIMS. Portanto, temos uma grande variedade de tecnologias fiscais em vigor, o que torna o trabalho de produzir softwares que atendam a todas essa tecnologias e legislações, um trabalho bastante complexo. Pensando em criar uma facilidade aos desenvolvedores, de forma que seja fácil visualizar quais UFs utilizam quais tecnologias, estamos lançando o Mapa Fiscal do Projeto ACBr, que pode ser acessando clicando-se aqui. Temos uma série de mapas, descrevendo a situação atual de cada UF, de acordo com a Tecnologia Fiscal. O clique no Mapa, deverá direcionar para um tópico em nosso fórum, com informações detalhadas de cada UF Com isto a Sw.House terá informações de forma clara e objetiva, que poderão auxiliar na tomada de decisões quanto a prioridade de desenvolvimento de sua Aplicação Comercial. Mapa 1: Tecnologias Fiscais em Vigor Este mapa demonstra através de seu esquema de cores, quais os documentos fiscais então em vigor para cada UF brasileira, assim como quais UFs permanecem exigindo o PAF-ECF. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_tecnologias_fiscais Mapa 2: Status da NFCe Situação das UFs que Aceitam; Não aceitam; Aceitam com restrições, ou estão em Implantação. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_nfce Mapa 3: Status do ECF Situação do ECF (Emissor de Cupom Fiscal): demonstrando onde o ECF ainda é Valido e Permitido a Lacração, Onde está em Fase de Transição e Onde seu Uso está Proibido. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_ecf Mapa 4: Exigência do Grupo Responsável Técnico Situação da exigência das informações referentes ao Grupo Responsável Técnico para os DFs: demonstrando as UFs que exigirão as informações Completas (Inclusive o CSRT), aquelas que exigem as informações de forma Parcial (CNPJ, etc...) e aquelas que Não Exigem. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_ecf Responsabilidade pelas informações Estamos disponibilizando esses mapas como uma ferramenta ao auxílio da comunidade que se formou ao redor do projeto ACBr. Esses mapas representam nosso atual entendimento do cenário nacional e pode diferir da realidade em algum momento. Estamos desejosos de manter essa nova ferramenta sempre atualizada. Mas não podemos nos responsabilizar por informações incorretas caso aconteçam. Como pode imaginar, é um trabalho enorme manter tanta informação devidamente atualizada. Cada UF tem sua peculiaridade e autonomia para mudar sua legislação sem prévio aviso. Por isso queremos contar com a ajuda de todos os usuários para nos reportar qualquer incorreção ou mudanças na legislação. Se notar alguma informação desatualizada ou incorreta, por favor, nos avise.

Felipe, Informando ai que nesta configuração voltou a funcionar, na contingencia, com certeza era alguma instabilidade na internet do meu cliente.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Pode fechar este tópico. Eu tinha entendido errado alguns detalhes da Distribuição DFe e agora está tudo OK.

Bom dia, mathlopes. Veja o link abaixo: http://www.sped.fazenda.mg.gov.br/spedmg/cte/Carta-de-Correcao/

Produtor Rural Pessoa Física: A SEF/MG voltará a exigir regra de validação da NF-e e NFA-e a partir de 8/4/2019 "A Secretaria de Estado de Fazenda de Minas Gerais (SEF/MG) informa aos Produtores Rurais Pessoa Física que a partir de 8 de abril de 2019 voltará a validar a regra que exige que o CPF informado na emissão da Nota Fiscal Eletrônica (NF-e) ou Nota Fiscal Avulsa Eletrônica (NFA-e), seja o mesmo CPF máster identificado no SIARE ou seja o CPF considerado como responsável pela Inscrição Estadual (IE). Caso os Produtores Rurais Pessoa Física que participem de sociedade de economia familiar informem outro CPF que não o indicado como CPF máster na SEF/MG na emissão da NF-e/NFA-e receberão, como retorno da transmissão, a rejeição 622 “Rejeição: IE emitente não vinculada ao CPF". Nos casos em que estes Produtores Rurais Pessoa Física constarem como destinatário, caso seus fornecedores informem no campo de destinatário outro CPF que não o indicado como CPF máster na SEF/MG na emissão da NF-e/NFA-e, receberão, como retorno da transmissão, a rejeição 624 “Rejeição: IE Destinatário não vinculada ao CPF". A definição das regras e a legislação relativa a estas validações estão tipificadas nas páginas 260 e 263 do Manual de Orientação Contribuinte versão 6.0 e no inciso II do artigo 11-B do Anexo V do RICMS/MG." http://www.fazenda.mg.gov.br/noticias/2019.04.01_Validacao_ProdutorRural.html

Boa pergunta. Qual o XML de retorno?

Bom dia Galera consegui resolver tanto no A1 quanto no A3. 1) Faça o download do arquivo: http://redeicp.blob.core.windows.net/downloads/InstaladorCadeiaV2.exe 2) Pressione as teclas Windows + R (ou Iniciar > Executar); 3) Digite certlm.msc e clique OK, na mensagem de confirmação clique em Sim; 4) Na janela que abrir, no menu esquerdo selecione a pasta “Autoridades de Certificação Raiz Confiáveis” depois selecione a pasta “Certificados”; 5) Do lado direito, selecione todos os certificados (CTRL+A) e delete. Na mensagem de confirmação, clique em Sim; 6) Novamente do lado esquerdo selecione a pasta “Autoridades de Certificação Raiz de Terceiros” depois selecione a pasta “Certificados”; 7) Do lado direito, selecione todos os certificados (CTRL+A) e delete. Na mensagem de confirmação, clique em Sim; 8) Abra o arquivo baixado no início e clique em Instalar para reinstalar os certificados.

Bom dia, Problema resolvido. Grato.

bom dia quatarollo, Isso mesmo, se o emissor for de SP não terá a tag: <infRespTec>, conforme o mapa fiscal atual: https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico , e se o emissor for do PR exigirar a tag: <infRespTec> observando o prazo 07/05/2019 e assim por diante. Você tem que se orientar com base no mapa fiscal. Porém a princípio nenhum estado que estiver obrigado a informa a teg:<infRespTec> a SEFAZ não irá fazer a validação do hashCSRT nesse momento só no futuro ainda não divulgado. Att.

Segue anexo os fontes: Como tinha dito, o projeto segue os padrões disponibilizados, porém, não há nenhum tipo de validador ou algo do tipo. Espero ter contribuido!BrLDCPR.rar

Bom dia. Até agora este campo nunca foi solicitado seu preenchimento, para mim parece mais ser algo preenchido manualmente se necessário.. Oque exatamente é esta informação que você está tentando inserir? Att,

Obrigado Juliana! Irei fazer as correções e o teste junto ao banco.

Boa tarde. Como você realizou os testes? Não consegui reproduzir esta situação. Verifique se configurou corretamente a propriedade Convenio. Att.

Boa tarde. Conforme pode ser observado nas postagens deste tópico, o grupo Responsável Técnico será exigido a partir de 07/05-19 somente para algumas UFs e ainda assim sem os dados relativos ao IDSCRT, as demais não tem data definida para iniciar a obrigatoriedade nem deste grupos. Acompanhe nosso Mapa Fiscal para ver a situação em todas as UFs. https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico Att.

Acho que não me expressei corretamente. Postei junto pois também utilizava o evento ACBrMDFe1.EventoMDFe.GetNamePath no enviar evento de Inclusão de motorista e com a atualização do ACBR também estou tendo problemas, então estou mudando o sistema para adequar a retirado do recurso. Neste processo de adequação fui procurar os exemplos do ACBR e verifiquei que não consta o envio/impressão do evento inclusão de motorista. Me desculpem pelo mal entendido.

Bom dia Atualize os fontes e reinstale os componentes, as opções default de margens deste componente já foram ajustadas.