Painel de líderes

Meu arquivo estava realmente desatualizado. Baixei novamente e inclui nele o QR-Code. Neste arquivo apenas inclui a informação do QR-Code, pois foi a minha necessidade imediata para disponibilizar para os clientes. Estou verificando as demais alterações para alterar os outros modelos. DAMDFe_Retrato.fr3

Pelos testes que fiz está tudo certo. Enviado ao repositório, rev. 17329. Obrigado @JeannyPaiva pela contribuição.

Na impressão da NF-e, nos dados dos produtos / serviços, de acordo com a quantidade de registros as linha são coloridas com cores alternadas. porém o campo estava sendo pintado ultrapassando a largura máxima do "detail". segue o print do erro: Para correção desse problema realizei algumas modificações nos arquivos (ACBrNFeDANFeRLRetrato.pas, ACBrNFeDANFeRLRetrato.dfm), segue imagem: Não sei se já foi feito alguma correção nesse sentido, mas estou anexando os arquivos com minhas alterações. Obrigado. ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.pas

A resposta rápida pra esse caso seria usar o CFOP 6929. Mas é contraintuitivo emitir uma NFCe para uma mercadoria que vai ser destinada a outro estado, já que a NFCe destina-se a venda a consumidor final, presencial. Se a venda foi realmente presencial pode ser emitida NFe com CFOP 5929, idDest = 1 (interna), mesmo com endereço do destinatário sendo de fora do estado, desde que também seja informado operação presencial (indPres = 1) e sem frete (modFrete = 9). Também é preciso ver se a UF em questão (do emitente) permite o uso do CFOP 5929/6929 referenciando uma NFCe.

Testei o XML anexado e validou normal: https://dfe-portal.svrs.rs.gov.br/Mdfe/ValidadorXML

Boa tarde Quem conseguiria baixar os XMLs seriam os envolvidos na NFe (Destinatário, Transportador, Contador se o CNPJ estiver devidamente informado no XML) utilizando os métodos de DistribuicaoDFe (Apenas NFe). Se você é o Emitente não conseguirá baixar os XMLs via WebService, pois a SEFAZ considera que obrigatoriamente precisa guardar os XMLs autorizados. Se não for a situação acima só baixando pelo site mesmo, utilizando a chave...

Correção no repositório, rev. 17327. Para MDFe não existe EPEC ou FSDA, apenas a contingência com tpEmis = 2. Favor atualizar os fontes e testar novamente.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17326. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Não temos nada desenvolvido ainda nesse sentido... Talvez algum usuário do fórum tenha alguma experiência.

A função HexToAscii da unit pcnAuxiliar apresenta um erro de conversão ao tentar converter uma string inválida. '$ 2' is not a valid integer value Este erro ocorre na impressão de notas com caracteres inválidos na tag infCpl. Segue possível correção para análise. pcnAuxiliar.pas

Mudei a estrutura do DANFE de cancelamento do fast report para ficar igual ao do DANFE Cancelando do FortReport dessa forma a economia de papel EventosNFCe.fr3

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

Fiz da mesma forma que os amigos acima, o caminhão não era da empresa então não informei a rntrc do modal, apenas a dos veiculo e a mensagem parou.

eu estava procurando a palavra sucesso no resultado. Quando leiaute 0.07 no equipamento, ele retorna a palavra sucesso, porem quando 0.08 no equipamento e vc usa 0.07, essa palavra nao retorna e sim Alerta: Versao de leiaute......Mudei para buscar o CodigodeRetorno=6000 obrigado

Boa tarde. Desculpe a demora e responder. Só agora a tarde consegui entrar aqui. O CSOSN a ser utilizado é o 101, ou seja, é a correlação com a CST 10 da empresa normal. No teu caso, sendo indústria e o destino é outra unidade da federação, há que se ficar atento às regras da legislação destino. Pelo relato e as rejeições não é possível fazer uma análise mais profunda, isso seria possível olhando o .xml, mas, pelo código 600 me parece que há inconsistência na somatória da BC-ICMS dos itens com o total informado na BC-ICMS da nota. Se tiver o .xml fica mais fácil. No caso do CFOP deve ser utilizado o 6107 mesmo.

Significa que no XML a data/hora de emissão está superior à data/hora do webservice. Então verifique o relógio e fuso horário da máquina se estão corretos.

Boa tarde, @Italo Jurisato Junior Eu fiz uma alteração confome essa postagem, que estava ocorrendo na Ginfes: Após isso consegui obter o retorno da prefeitura, no caso realmente não é permitido cancelar somente realizar a substituição: O prazo limite para realizar essa solicitacao por meio do sistema de NFS-e encerrou-se (vide Portaria 47 de dez/2017). Agradeço a atenção!

Era dll mesmo, problema resolvido. É que tinha uma outra pessoa fazendo a instalação e jurando de pé junto que tudo tava rodando até uns instantes, fizemos a reinstalação e deu tudo certo. Obrigado.

O erro indica um erro de leitura do XML. O teu XML tem quebras de linha, remova as quebras de linha do XML e tente de novo.

E ae @fernandesdouglas, muito obrigado pela resposta, vou aplicar esses procedimentos no cliente e verificar se resolve o problema.

Fiz a alteração na classe ACBrMDFe.pas conforme exemplo da ACBrBPe.pas e deu certo.. transmitiu corretamente. Anexo estou enviando a classe para validação e commit. ACBrMDFe.pas

OK. Vou verificar, muito obrigado.

Boa tarde a todos, hoje tive o mesmo problema aqui na Empresa onde trabalho. Um cliente estava tentando transmitir um MDF-e e estava dando rejeição 687. Aqui na empresa não estavamos sabendo destas novas regras para MDF-e, e baseado na mensagem da rejeição fui pesquisar sobre esse codigo RNTRC da ANTT, e achei um link que dá para pesquisar o proprietário do veiculo que possui este registro na ANTT, o link é https://consultapublica.antt.gov.br/Site/ConsultaRNTRC.aspx/ConsultaPublica/ Então ao pesquisar, descobri que o caminhão que iria fazer o transporte não era de nosso Cliente, e sim de uma Transportadora Terceirizada. Sendo assim procurei alguma coisa relacionada no manual do MDF-e descrobri as tags do grupo veicTracao.Prop. (Digo descobri, pois nunca tinha mexido com MDF-e, apenas NF-e). Então o que fiz foi preencher as seguintes tag abaixo quando o Caminhão é de Terceiros, e consegui transmitir sem nenhum problema. with rodo.veicTracao.prop do begin RNTRC := MinhaQuery.FieldByName('ANTT_VEICULO').AsString; xNome := MinhaQuery.FieldByName('NOME_PROPRIETARIO').AsString; CNPJCPF :=MinhaQuery.FieldByName('CNPJ_CPF_PROPRIETARIO').AsString; UF := MinhaQuery.FieldByName('UF_PROPRIETARIO').AsString; end; Espero ter ajudado! Atenciosamente, Fabrício Medeiros

boa tarde ai esta o modelo. ent__CriarMDFe.txt ent__CriarEnviarMDFe.txt 43190728740763000198580010000001541000003851-mdfe.xml

Parece que você manteve as suas alterações. Como eu mencionei, eu fiz alterações no arquivo. Por favor, faça um revert no arquivo ACBrValidador.pas.

Bom dia. O ACBr possui o componente ACBrSPED, o qual faz a geração do mesmo e tem inclusive o demo. Porem você postou no tópico do ACBrMonitor, o qual não tem este recurso implementado. Att.

Olá, Também estava com essa mensagem. Consegui enviar informando a tag de redução de base de cálculo (Imposto.ICMS.pRedBC) e a tag com o código do benefício fiscal (Prod.cBenef). Nesse teu caso como o percentual de diferimento é 100% acho que o valor do ICMS deverá ser zero, mas não tenho certeza.

Certo. Muito obrigado.

@BigWings, erro meu, você está certo. Eu citei que havia feito conforme o DANFCe em EscPos mas está diferente. O EscPos gera o valor a pagar com o vNF. Alterei para ficar igual. A ideia é justamente essa, deixar igual ao EscPos, que busca o valor da tag, em vez de fazer conta e correr risco de deixar a soma diferente do XML. Anexei com essa alteração. Obrigado. ACBrNFeDANFEFRDM.pas

Obrigado pelo interesse em contribuir. Não me pareceu correto ignorar descontos e acréscimo no valor a pagar. O mais correto seria usar a tag vNF como valor a pagar, da mesma forma como é feito no DANFE em EscPos. A soma de vProd + vServ seria o valor total.

Se você implementar a geração da tag no demo do ACBrNFe ocorre o mesmo problema?

O emissor gratuito de MDFe foi descontinuado pela SEFAZ em outubro do ano passado, conforme aviso na página da SEFAZ-SP: http://mdfe.fazenda.sp.gov.br/ Ele não é mais compatível com o layout em vigor desde o dia 15/07/2019. Você deve procurar outra aplicação. PS: Separei o post em um novo tópico por não ter relação com o assunto onde foi postado originalmente.

Bom dia @jeaanca eu sigo esses passos quando ocorre esses tipos de erros e sempre resolve. 1º Encerre sua aplicação. 2° Vá em executar, digite, certlm.msc, para abrir a interface de certificados. 3° Remova todos os certificados de "Autoridade de Certificação de Raiz Confiáveis". 4° Faça o download desse arquivo ( https://s3-sa-east-1.amazonaws.com/shared-www.validcertificadora.com.br/InstaladorCadeias_1.0.2.0.exe ) 5° Execute como Administrador o InstaladorCadeias_1.0.2.0.exe. 6º Clique em Instalar, e aguarde até que o processo seja finalizado. 7° Teste novamente a comunicação com a SEFAZ. Caso ainda não funcione, vá em opções da internet, na aba avançadas, desabilite as configurações: - Avisar quando houver incompatibilidade de endereços de certificado. - Verificar revogação de certificados do servidor. - Verificar se há certificados revogados do fornecedor. Salve, reinicie a máquina, e teste novamente.

No momento não tive nenhum relato. Sugiro você entrar em contato com eles.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Fiz algumas alterações porque o arquivo parecia que não estava atualizado e porque o tipo enumerado estava sendo adicionado no meio. Sempre é melhor adicionar no final. Subi as alterações para o SVN na Revisão 17325. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde Luiz, Antes o componente vinha com o valor padrão fgtNunca para a propriedade GerarInfMDFeSupl, agora ela vem com o valor fgtSempre como padrão. Isso explica não ser necessário incluir a respectiva linha. Alias essa propriedade vai ser removida do componente até o final deste mês.

Boa tarde Eduardo, Não estamos mais utilizando o array: TpcnTpEventoString.

Boa tarde, Realmente, creio que acabei confundindo seu tópico com outro, será enviado nos próximos dias. Att.

De fato, É uma boa notícia. segue link: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/ajuste-sinief-11-19

Boa tarde a todos, O componente ACBrCTe tem uma propriedade de configuração chamada: GerarInfCTeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfCTeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfCTeSupl. O valor padrão é fgtNunca, mas a partir do dia 22/07/2019 para realizar testes no ambiente de homologação essa propriedade deve estar com o valor fgtSomenteHomologacao. E a partir do dia 26/08/2019 para o envio em ambiente de produção a propriedade devera esta com o valor fgtSomenteProducao ou fgtSempre. Quando se tornar obrigatório em ambos ambientes iremos remover essa propriedade de configuração do componente.

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.

Boa tarde a todos, O componente ACBrMDFe tem uma propriedade de configuração chamada: GerarInfMDFeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfMDFeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfMDFeSupl. Essa propriedade em breve vai deixar de existir, uma vez que a exigência em ambos os ambientes já foi ativada pela SEFAZ.

Bom dia, Que bom que deu certo, mas seria interessante compartilhar a resolução também. Att.

Boa tarde. Obrigado @everson.turossi e @BigWings pelas respostas. Para não ter que criar uma outra cópia do arquivo .fr3 eu segui a dica do Everson. Eu estava configurando errado a propriedade Modelo, estava preenchendo com 'ppEscEpsonP2'. Depois dessa configuração a impressão saiu perfeita, do jeito que eu precisava. Obrigado pela atenção.

O modelo da impressora está configurado corretamente? ACBrNFeDANFeESCPOS1.PosPrinter.Modelo := ppEscPosEpson;

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

Boa tarde. Utilizo a ECFVirtualNFCe para a emissão de NFC-e, e no evento QuandoFecharDocumento valido a internet para colocar em contingência ou não. Porem quando passar por este evento e tem internet mais quando transmitir der erro de internet, não consigo colocar em contingencia. Tentei tratar no evento NFCETransmitError do AcbrNFe mais não consegui. Alguém sabe como lidar com isso?

Tenho um aplicativo paf e utilizo ACBrECFVirtualNFCe para emitir NFCe. Estou implementando tef e quando executo o comando "ACBrPosPrinter.LerStatusImpressora" para verificar o status da impressora antes de imprimir o TEF, da erro de comunicação. --------------------------- Debugger Exception Notification --------------------------- Project PAFMIDAS.exe raised exception class ESynaSerError with message 'Communication error 9997: Timeout during operation'. --------------------------- Break Continue Help --------------------------- O erro é porquê o componente ACBrECF esta utilizando a impressora na porta COM. Qual a melhor forma para fazer esta verificação da impressora?

Marquei a propriedade "ControlePorta" e um Sleep(1000) antes de LerStatusImpressora e funcionou. Obrigado Daniel.

Boa tarde. Recomendo a leitura do manual do banco para entender melhor a montagem da linha digitável. svn.code.sf.net/p/acbr/code/tools/Bancos Att.