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:

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.

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

Use o ACBrNFeDANFeRL1, vai resolver.

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:

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.

Ressucitando este tópico para enfatizar a resposta de nosso amigo, que realmente salvou a pele passando o conhecimento adequado sobre o caso, pois eu, como analista e desenvolvedor intermediário, estava quebrando a cabeça por usar as DLLs 64 bits em um Sistema Operacional 64 bits, mas a aplicação compilada em 32bits.

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

Era problema no WS mesmo, acabou de voltar a funcionar.

Boa tarde, Esta alteração consta no manual? 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.

Você pode usar o ambiente disponibilizado pelo AM para testes. http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/

Fiz a atualização e reintalação do ACBr, agora não aparece mais nada impresso e também não vem essa tag, enfim o problema foi resolvido. Obrigado.

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

Por favor verifique esse tópico. Sempre que tiver dúvidas, pesquise por palavras (ex: rejeição 938 ou vICMSSubstituto) que poderá encontrar tópicos já respondidos. Verifique sempre o tópico da Base de Conhecimentos https://www.projetoacbr.com.br/forum/forum/72-base-de-conhecimento/

Você pode utilizar o ACBrMonitor Plus e gerar as notas por meio de troca de arquivos? Veja esse vídeo:

Não... Você teria que ler o código e analisar como é feito pra implementar um novo componente ou classe.

Boa tarde Sandro, O Manual do BPe, você tem essa informação não só do passageiro bem como de todas as informações que compõe o XML. No Manual você a estrutura completa do XML e a informação se aquele campo é obrigatório ou não. Manual BPe Anexo I Leiaute v1.00b.pdf

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.

Obrigado pessoal deu certinho abs

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

Problema Resolvido com a atualização do componente ACBR, Update e reinstalação. Obrigado.

Obrigado amigo.

Entendi, muito obrigado! Pode colocar como: RESOLVIDO.

Bom dia O método está correto, porém a SEFAZ não prevê a Inutilização para NF-e de Produtor Rural, simplesmente você pula a numeração. Pode ver isso na NT de especificação sobre Emissão de NFe com CPF.

Desculpa, não havia visto que já tinha sido respondido, podem desconsiderar, obrigado.

Boa tarde Antônio, Se a propriedade de configuração: Configuracoes.Arquivos.IniServicos estiver vazia ao compilar a sua aplicação o arquivo ACBrNFeServicos.Res será incorporado ao EXE da sua aplicação. Desta forma você não precisa distribuir junto com a sua aplicação o arquivo ACBrNFeServicos.ini

Prezado Italo: Tudo resolvido. Pelo que concluí, o problema estava no schema. Obrigado!

Boa tarde Romano, Favor atualizar os fontes e iniciar os testes com o programa exemplo. Note que fiz alterações nos arquivos: Cidades.ini e Coplan.ini

@Mauro Jose Conte, a data do SST é diferente da data do início do eSocial, mesmo na base de teste existe também a questão do faseamento, nos meus testes coloquei o início da maneira que o eSocial informou no portal. 2019-03, não sei se antes disso irá funcionar, porém essa foi a data que passou a funcionar estes eventos na base de teste. Tenta dessa maneira que dará certo.

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

Revolucione a impressão de relatórios na sua aplicação, usando o ACBrPosPrinter... Provavelmente você precisa enviar um comando de Reset para a Impressora... isso pode ser feito com a Tag <zerar> do ACBrPosPrinter

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

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

Boa tarde Júlio, Se você for de Pelotas, sugiro que você abra os XMLs: 844-rec.xml (retorno do envio), 01746519201946-con-lot.xml (consulta ao lote) e 01746519201946-lista-nfse.xml (retorno da consulta), através de um navegador, imprima e mostre pessoalmente para essa analista. Não esqueça de imprimir um Print da tela do site que mostra que a respectiva nota foi processada com sucesso. Caso não seja possível conversar com ela pessoalmente, envie esses arquivos por e-mail. Deixe claro que até uma certa data esta funcionando sem nenhum problema, depois começou a apresentar essa mensagem ao consultar o lote.