Italo Giurizzato Junior

Bom dia, Complementando a resposta do Juliomar, para carregar o XML da NFS-e basta usar o método LoadFromFile. Como utilizar esse método basta ver por exemplo como é carregado o XML de uma NFS-e para poder imprimir o seu DANFSE. Sei que a sua intensão não é imprimir e sim ler as informações, mas como carregar o XML, você vai saber como fazer.

Bom dia Antônio, Você trabalha com o Jorge Aguila? Pois vocês dois postaram o mesmo problema anexando o mesmo XML. Favor ver a resposta que dei a postagem dele.

Bom dia Jorge, Esse XML foi gerado pelo componente ACBrMDFe ou pela sua aplicação. Caso tenha sido gerado pela sua aplicação peço que compare ele com a NT 2020/001 versão 1.04 e verifique o que esta errado.

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.

30/03/2020 Suspensão das regras de validação da ANTT: COVID-19 Conforme resolução ANTT nº 5879/2020 o ambiente de autorização do MDF-e suspenderá as validações de cadastro do RNTRC e frota de veículos pelo prazo de 120 dias a fim de evitar rejeições indevidas nesse período de prevenção ao COVID-19.

Reinaldo, Disponha.

Reinando, Abra o TXT do log que você anexou, ultima linha: 30/03/2020 10:05:54 - ERRO: Rejeicao: O tipo do proprietario do MDF-e deve ser do tipo TAC Agregado O ACBr apresenta erro de validação e a validação ocorre antes do envio. Quem rejeita o documento é a SEFAZ, portanto foi ela que pegou a chave do MDF-e que foi informado no evento e buscou as informações sobre ele em sua base de dados e detectou esse problema. Se é a mesma coisa ou não no que diz ao TAC não sei lhe dizer, o problema é que você esta fazendo confusão com o tpTransp que se encontra dentro do grupo <ide> e tpProp que se encontra dentro do grupo <prop> que por sua vez aparece tanto dentro grupo <veicTracao> e <veicReboque>. A mensagem da Rejeição no meu entendimento esta errada, não existe proprietário do MDF-e, existe proprietário do veiculo e emitente do MDF-e. A mensagem correta deveria ser: O tipo do proprietário do veiculo deve ser do tipo TAC Agregado. Paciência, vamos que vamos. Volto a lhe pedir que informe zero em tpProp tanto do proprietário do veiculo tração quanto do veiculo reboque. A Mensagem que rejeição que você recebeu se refere a rejeição 723 que se refere a regra de validação da SEFAZ K07 que diz: Verificar se o MDF-e informado possui proprietário do veículo de tração informado com tipo de Proprietário TAC Agregado (tag: tpProp=0). Concluímos que se tpProp for diferente de zero será gerado a rejeição 723. Vide Nota Técnica 2020/001 versão 1.04 - pagina 13.

Você não alterou a configuração do componente ou alterou? A UF do emitente ainda precisa continuar sendo CE. O que muda é o tipo de emissão que não é normal e sim SVC-SP. Apesar do Junior ter te passado como é feito na NF-e o comando é parecido para o CT-e. CTe.SetFormaEmissao(nFormaEmissao) nFormaEmissao - pode ser passado os seguintes valores: 1-Normal, 4-DPEC, 5-FSDA, 7-SVCRS, 8-SVCSP No seu caso devemos executar o comando: CTe.SetFormaEmissao(8) Outra coisa o XML que você anexou o tpEmis é 7, esta errado tem que ser 8.

Boa tarde a todos, Favor atualizaram os fontes e façam novos testes.

Favor anexar o XML de envio de lote.

Boa tarde Reinaldo, Veja o seu XML do MDF-e. Note que você informou 1 em tpProp tanto para o veiculo trator quanto para o veiculo reboque. O valor 1 indica que o tipo de proprietário é TAC Independente e segundo a mensagem de rejeição diz que tem que ser TAC Agregado, portanto o valor de tpProp para ambos os veículos tem que ser 0 (zero) conforme consta no Manual do MDF-e Anexo I layout versão 3.00a - página 21 e 22.

Boa tarde, A UF do emitente se tratando de Contingência é utilizado a SVC-SP e não a de RS. Veja a minha rotina que alimenta o componente: // (AC,AL,AP,AM,BA,CE,DF,ES,GO,MA,MT,MS,MG,PA,PB,PR,PE,PI,RJ,RN,RS,RO,RR,SC,SP,SE,TO); // (12,27,16,13,29,23,53,32,52,21,51,50,31,15,25,41,26,22,33,24,43,11,14,42,35,28,17); case rgTipoEmissao.ItemIndex of 0: ACBrCTe.Configuracoes.Geral.FormaEmissao := teNormal; 1: ACBrCTe.Configuracoes.Geral.FormaEmissao := teFSDA; // Contingencia FSDA 2: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCRS else ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCSP; end;

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

Boa tarde Junior, Com apenas 1 nota no lote em ambiente de homologação a nota é processada com sucesso? Se sim, então precisamos ver o XML referente ao lote com 1 e mais de 1 nota, quem sabe tem algo que precisa ser corrigido na montagem do lote.

Boa tarde Moises, Você informou duas NF-e que foram emitidas em contingência, é preciso informar o código de barras de contingência, onde devemos informar na tag SegCodBarra. Por outro lado na terceira nota foi informado o código de barras de contingência, mas não foi informado a chave da nota.

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

Rubens, Desmarca a opção de salvar somente NF-e processada. Desta forma você terá o XML da nota que foi enviada e por algum problema não obteve o retorno. Não existe uma pasta para notas enviadas e aguardado retorno e outra com os XML das notas que estão com o protocolo de autorização, ou seja, houve o retorno da SEFAZ. Todas ficam na mesma pasta, a sua aplicação tem que ter o controle dessa situação.

Bom dia Reinaldo, É importante também anexar o XML gerado para que possamos analisar o problema. Sendo assim, favor anexar o XML do evento. Em tempo, favor anexar o arquivo INI e XML do MDF-e que esta sendo referenciado no evento.

Bom dia a todos, Alguém se habilita a implementar esse provedor para a cidade de Ponta Porã/MS?

Bom dia Eliomar, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Junior, Favor anexar o XML do Lote que esta sendo enviado. Outra coisa faça um teste com apenas um RPS para ver se ocorre o mesmo erro. Tem provedor que o ambiente de homologação esta bichado, só funciona de forma correta o de produção.

Bom dia Solivan, Muito obrigado pela colaboração, vou enviar para o repositório. Um detalhe os seus fontes estão desatualizados.

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

Bom dia Carlos, Pelo que eu entendi o provedor não deixa você simplesmente cancelar uma nota. É preciso substituir a nota "errada" por uma "correta", neste caso deve-se utilizar o SubstituirNFSe. Agora se ao tentar usar esse método esta ocorrendo um erro, é preciso solicitar ao provedor um XML de exemplo de preferencia envelopado para que possamos comparar com o que o componente esta gerado e fazer as devidas correções.