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.

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

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, Ricardo_Vetor. Segue o arquivo. ER_PAF_ECF_versão_02_06.pdf

Italo, deu super certo, não sei nem como agradecer. só me tira uma duvida pfv como que recupero esse valor 3519071442297900010956000000000000268-nfse ? muito obrigada Melissa [RESOLVIDO]

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.

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

Bom dia Joabe, Se não me falha a memória se tratando de Produtor Rural não é possível inutilizar numero ou faixa de números. Dai o erro retornado pela SEFAZ. Aproveitando: Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr com o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada?

Bom dia, favor atualizar os fontes.

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

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. Oque exatamente você procura? 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.

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

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

Ficar atento ao repassar nosso numero para o componente, pois pode haver problema com soma de DV e cortes por posição. Vi que o nosso numero seu está formatado. Atente para isso.

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.

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.

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?

Bom dia Lucas, Você configurou o proxy no programa exemplo? Se sim, a rede possui um proxy instalado? Se não tem, não se deve configurar o proxy.

Caro Carlos Alberto, primeiramente, qual banco você usa. No meu caso eu uso o Firebird 2.1 e persisto o XML da NFe no banco por dois motivos. Se o seu sistema funcionar em rede, os xml's ficaram fragmentados pela empresa e em caso de formatação das máquinas ou demais danos os mesmos podem ser perdidos. Neu caso eu uso um campo blob e logo apos o envio da nota set XML para um MEMO e a minha função que gera SQL persiste esta informação. O fato de gravar o XML adiantou a minha vida por que o usuário poderá utilizá-lo de qualquer estação em que estiver logado e simplesmente o carrego para imprimir danfe, cancelar, exportar, etc. Isto é o que eu faço, mas como eu faço pode não ser útil para você por que talves os componentes que você usa para persistir em banco pode ser diferentes dos meus, a geração do sql etc. Espero ter dado uma luz.