Painel de líderes

Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. 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. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.

Tudo resolvido. Obrigado pela orientação. Gostaria apenas de acrescentar, para quem tenha o mesmo problema ou semelhante, que, antes de reinstalar o ACBr, é necessário remover os pacotes do Delphi (menu componentes) que se refiram ao ACBr e, após a reinstalação, executar o arquivo apagar ACBr do diretório ACBr.

Boa tarde! R: Você pode criar no seu sistema um recurso que ao receber o retorno do status 109 - Serviço paralisado sem previsão ou 108 - Serviço paralisado momentaneamente (curto prazo) ou ainda sem comunicação e nestes casos aplicar a ativação do modo contingência. R: Pode enviar o comando status e ao receber a resposta no arquivo de retorno, exibir as linhas que interessam para o operador. Estude o arquivo e você verá como é composto o retorno. Porém vale ressaltar o cuidado com o status, não fique enviando comando de status antes de cada emissão de NF que você pode se enquadrar no "Consumo indevido", pois ao enviar um comando para emissão de um documento, deve ser analisado o retorno deste comando. Para mim continua confuso o que você está tentando expor. - O arquivo TXT é deve ser criado pela sua aplicação, o ACBrMonitorPLUS apenas lê o arquivo e gera o XML e prossegue com os comandos de envio ou criarenviar que após gerar o XML já envia. - Pode ainda você gerar o XML e apenas validar e transmitir pelo ACBrMonitorPLUS. - Quando você diz "componente" para nós significa usar os módulos do ACBr incorporado em seu sistema se você programa na linguagem Delphi e não usar o aplicativo ACBrMonitorPLUS que permite então que seja utilizado em qualquer linguagem. Lembrando ainda que está em desenvolvimento uma DLL que também poderá ser aplicada em outras linguagens sem haver a necessidade do programa ACBrMonitorPLUS.

Bom dia! O correto é você se informar em cada UF em que desejar usar o seu sistema. Muitas exigem sim que exista o cadastramento da Software House como fornecedor de software para emissão de documentos fiscais eletrônicos. É o caso por exemplo do Para, Paraná, Santa Catarina, São Paulo para SAT etc. Em alguns vão te disponibilizar link e você faz online, outros como o caso do Paraná, mesmo fazendo o preenchimento online, será necessário assinar e encaminhar um termo de responsabilidade técnica pelo correio a Curitiba e após análise, vão liberar e cadastrar o teu software com um código, que será usado quando estiver preenchendo a ficha do emissor do documento fiscal (teu cliente). Após isto, você terá que reconhecer (eletronicamente) cada cliente que preencher a ficha de "Pedido de emissor de documentos fiscais eletrônicos") que usarem o código do teu sistema como fornecedor. Não sei os outros estados como funciona, mas tem características particulares, por isto é bom se informar na Unidade da Federação que você deseja operar.

Bom dia, Acho que esse vídeo pode ajudar a sanar algumas dúvidas:

Boa tarde! Eu penso que o sinal de = não esteja atrapalhando, pois conforme pode ser visto na figura em anexo a carta está registrada e o sinal de "=" bem interpretado. Porém não conseguir detectar o erro. Talvez seja interessante preencher os parâmetros (pelo menos para teste) como impressora e colocar o sinal delimitador (aspas) entre as opções do comando. Ex.: NFE.ImprimirEventoPDF("D:\NFe\EVENTOS\57270480000128\NFe\..." , "D:\NFe\Transm\57270480000128\NFe\...") Outro detalhe que observei que parece não localizar seus arquivos. Dê uma revisada nos patch´s (caminhos) dos arquivos.

Bom dia. Tudo bem..amigo.. Vou falar da minha experiencia. Quando eu gero ent.txt, ja coloco o nome que me interessa, tipo : ent_nota e assim. .ela me retorna sai_nota.. esse ent_nota.txt é eliminado quando retornar sai_nota.txt , no meu caso como queria ficar com a copia, ja jogo em outro diretorio somente de txt gerados. Eu como sou de outra Linguaguem - Windev - eu uso o AcbrMonitorPlus. e acho muito bom, pois ele ja esta totalmente pronto e com executavel. Depois que ele transmite , ele vai jogando os xml nas pastas e meses devidos. Quanto a usar exe ou componente, depende muito do tempo que tem para desenvolver.. ver qual melhor voce se adpate.

Italo, eu acho que achei o erro no xml, o modelo não foi preenchido como 57 Eu acho que isto ira resolver o problema. Peço desculpas por tomar o seu tempo!

Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf

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

Boa tarde. Vejam que foi enviada uma contribuição para este caso, a mesma está na lista para análise. https://www.projetoacbr.com.br/forum/topic/51515-negativação-serasa-banco-do-brasil-cnab-240/ Att.

Boa tarde, Resolvido, o que faltava aqui era eu testar antes se haviam rejeições, fiz assim: if ACBrBoleto1.ListadeBoletos.Objects.MotivoRejeicaoComando.Count > 0 then Obrigado pelas sugestões.

A versão da NFC-e está em 3.10, mude para 4.00 e tenta emitir novamente!

Use o ACBrNFeDANFeRL1, vai resolver.

Obrigado por reportar. Fechando o tópico e para nova dúvida abra novo tópico.

Olá senhores, Problema resolvido, obrigado!

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

Boa tarde, Favor atualizar os fontes e refaça os testes.

Rode novamente o ACBrInstall... isso deve atualizar todas as BPLs e DCUs

Isso acontece pois você está passando para o campo cNF o mesmo valor de nNF. De uma olhada para mais detalhes:

Bom dia, LIDERNetwork. Veja o tópico abaixo, talvez possa te ajudar:

Bom dia Favor atualizar para última versão 1.2.0.65

Aqui você tem um vídeo e algum material de apoio... em uma palestra feita pelo @EMBarbosa...

O AcbrMonitor é bem simples, ele vai cuidar de toda a comunicação com o sefaz. Mas, você tem que fornecer o arquivo com as informações da nota, e é ai que você vai gastar algum tempo. Sugiro que pegue um arquivo .ini(que é o arquivo com as informações da nota) mais parecido com o caso especifico que você vai trabalhar(Procure no fórum, sempre tem), e comece a implementar as regras de negocio a partir dele.

Resolvido!! Era apenas um questão de configuração na versão do QRcode, depois que mudei para veqr200 deu tudo certo. Obrigado.

Boa tarde Eliezer, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Adilson, O DANFSE é gerado com base no XML da NFS-e e não no XML do RPS. Lembre-se sempre disso. Até hoje não entendi o porque a ABRASF fez essa mercadoria. Devemos gerar o XML do RPS enviar para o webservice e este retornar o XML na NFS-e. O RPS não é a nota antes do envio e sim um Recibo, já a NFS-e é a nota e como dito acima o DANFSE é impresso com base no conteúdo do XML da NFS-e.

Boa tarde a todos, Já esta disponível no repositório tanto o programa exemplo quanto os fontes do componente ACBrANe com a implementação para averbar carga através da seguradora ELT. Peço a todos que atualizem os fontes e façam testes com a ATM (para ver se não alterei nada que comprometa o seu funcionamento) e ELT. O componente já esta conseguindo consumir o webservice da ELT mas não sei se o envio dos dados estão da forma esperada por eles. Talvez seja necessário ainda fazer alguns ajustes. No programa exemplo tem um campo para escolher a seguradora.

Você mesmo pode incluir a cidade no arquivo ini do provedor. Só seguir igual as demais cidades estão destacadas. Acontece comigo, quando alguns clientes precisam emitir a NFS-e, porém a cidade não tem no arquivo ini, eu simplesmente acrescento elas.

Eu fiz este tratamento de tamanho na tentativa de garantir o tamanho correto... porque já faz um pá de dias que estou penando nesta rotina. Vou retirar e ver o que acontece. Obrigado ao amigo que falou que dá para abrir com o notepad, eu não tinha experimentado isto.

Poste parte do código, onde faz o envio da NFC-e. Esse erro ocorre, normalmente, quando você cria um "loop", e não consegue acessar um objeto referenciado. Ex: Você tenta acessar a NF-e 5 do componente ACBrNFe, porém no mesmo, só contém 4 notas. Estranho que você disse que em sistema operacional 64 bits funciona, mas mesmo assim poste parte do código para tentar analisar se há algo de errado.

O arquivo destinatário ("MG22843710000116211 1905N01D.001"), parece que está incompleto mesmo. Veja o conteúdo: 66259110000261ISENTO 00000000 00 00360 38930000 12 20190509211 000000001 929E54F4C44D3857748F1E529498E44E Não tem dados de razão social, endereço, código de município, etc... Você precisa verificar se no seu banco de dados esses dados existem e depois se estão sendo informados ao componente. Uma coisa que notei agora no seu código é que você está usando funções para colocar espaços a direita. Como aqui: Não é necessário fazer isso. O componente já faz os tratamentos de tamanhos de campos na hora de gerar os arquivos.

Boa tarde, Esta alteração consta no manual? Att.

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

Nestes link existe a documentação e um passo a passo feito pelo @Italo Jurisato Junior

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

Provavelmente você não configurou corretamente o componente, ou as propriedades da DFeSSL... Por favor estude o Demo... Esse vídeo lhe informará tudo que precisa saber sobre a DFeSSL

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

O grupo é informado no comando de envio... https://acbr.sourceforge.io/ACBrMonitor/eSocialEnviareSocial.html Sucesso

Lembro que a msxml5.dll já foi descontinuada pela Microsoft, e tem problemas graves quando usando certificado A3, então não é recomendado o uso para esse tipo de certificado. O ideal seria fazer funcionar com a LibXml2.

Boa tarde a todos, Para quem não sabe os Manuais e Notas Técnicas não é exclusividade do ACBr, eles são de domínio publico, logo qualquer um pode ter acesso a essa documentação gratuitamente. Onde eu os encontro? Se tratando de NF-e e NFC-e temos o Portal Nacional da NF-e na aba Documentos encontramos os Manuais, Notas Técnicas, Schemas e Diversos. CT-e e CT-e OS temos o Portal Nacional do CT-e na aba Documentos encontramos os Manuais, Notas Técnicas, Schemas e Diversos. Temos também o Portal dos Documentos Fiscais Eletrônicos - SVRS esse portal encontramos Manuais, Notas Técnicas e Schemas dos seguintes tipos de documentos fiscais: NF-e, NFC-e, CT-e, CT-e OS, MDF-e, BP-e, NF3-e (Nota Fiscal de Energia Elétrica Eletrônica) e ONE (Operador Nacional dos Estados). Esse portal é da SVRS - SEFAZ-Virtual do Rio Grande do Sul e promete manter principalmente os Manuais sempre atualizados, diferente dos Portais Nacionais da NF-e e CT-e que chega a demorar 2 anos para atualizar os Manuais. Nos obrigando sempre a consultar o Manual e diversas Notas Técnicas para saber como devemos implementar. Hoje estou me baseando somente nos Manuais do Portal da SVRS. Todos esses Manuais e Notas Técnicas e vários outros, estão disponíveis em nossa biblioteca que pode ser acessada clicando aqui. É possível também criar uma nova pasta (ACBrTools por exemplo) e configurar o tortoise para baixar tudo o que temos. A URL de configuração do tortoise é a mesma, basta trocar o Trunk2 por Tools no final da URL. E boa leitura a todos.

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.

Bom dia Cicero, Favor atualizar todos os fontes de todas as pastas novamente. Reinstale a suíte através do ACBrInstall_Trunk com a opção Apagar arquivos antigos marcada.

Bom dia Na Versão atualizada do ACBrMonitor, obterá a documentação completa de todos os métodos do componente BPe, bastará passar os dados para o Monitor...

Conexões Socket não funcionam dessa maneira... você somente saberá que a conexão não está mais disponível, quando tentar enviar algum comando e receber um Erro... Você poderia implementar um pooling de tempos em tempos para checar se o terminal está on-line

Bom dia Dercide, Já ocorreu relato anteriores de problemas com esse campo, pois mesmo se tratando da mesma versão de layout, alguns validadores só aceitam se o valor estiver em branco e outros validam com valor 0. A indicação é que informe "0" neste campo se tiver problemas... Veja este tópico:

Muito bem observado. Muito obrigado.

Que bom que resolveu. Mas o ideal é postar a forma como solucionou o problema. Este fórum é usado como base de conhecimento e pesquisa por muitas pessoas na internet.

Olá! gostaria de agradecer a todos que colaboram. NFE foi enviada agora. a nfe tem que ser 0 = entrada. grato a todos .