Italo Giurizzato Junior

Bom dia, Que cabeçalho? Esse MDF-e da imagem foi envido, mas foi rejeitado pelo simples fato de existir um outro MDF-e conforme consta no arquivo de retorno (*-pro-rec.xml) que não foi encerrado. Logo esse MDF-e não foi autorizado, consequentemente o XML assinado não recebe o grupo referente ao protocolo de autorização, portanto fica sem a tag <mdfeProc>. Onde esta o problema nisso? Nenhum. Enquanto você não enviar o evento de encerramento do MDF-e 35181113296533000104580010000001181000000011, você não vai conseguir emitir autorizar esse MDF-e da imagem. O MDF-e não encerrado é de numero 118 (coloquei em negrito na chave) e o que você enviou e foi rejeitado é de numero 125. Pode ser que existam outros que não foram encerrados entre o 118 e 125.

Bom dia Luiz, A rotina atual esta da seguinte forma: if ((CTe.Imp.infTribFed.vPIS > 0) or (CTe.Imp.infTribFed.vCOFINS > 0) or (CTe.Imp.infTribFed.vIR > 0) or ((CTe.Imp.infTribFed.vINSS > 0) or (InformarINSS = 1)) or (CTe.Imp.infTribFed.vCSLL > 0)) then begin Gerador.wGrupo('infTribFed', '#125'); No XML que foi autorizado pela SEFAZ o valor de vPIS é 0.08 portanto maior que zero e vCOFINS é 0.02 portanto maior que zero. Isso faz com que as duas condições em negrito sejam verdadeiras, logo o grupo <infTribFed> deve ser gerado no XML. Favor atualizar todos os fontes de todas as pastas, reinstalar os componentes e faça novos testes.

Bom dia Werner, Favor atualizar os fontes e faça novos testes.

Bom dia Tairone, É o que eu sempre digo, tem contador que só sabe contar história e nada mais. Acesse o Portal Nacional da NF-e e baixe a versão 6.0 do Manual da NF-e. Depois procure a estrutura do XML mais precisamente o grupo de tributação referente ao ICMS cujo CSOSN é 101 e 102 (páginas 204 e 205). Veja quais são os campos que são gerados quando é 101 e quando é 102. Depois mostre para essa contadora de história, quem sabe ela aprende um pouco. Um detalhe importante, no DANFE só pode ser impresso o que consta no XML. Página 136: 7.1 Campos do DANFE Os campos do DANFE deverão representar o conteúdo das respectivas TAG XML da NF-e, quando conhecidos no momento da solicitação de autorização de uso. Não poderão ser impressas informações que não constem do arquivo da NF-e.

Boa tarde Sergio, Onde devemos editar e alterar o endereço do Portal do MDF-e? Desculpe não entendi.

Boa tarde ALA, Até onde sei se o contribuinte é de MG ao emitir a NF-e, esta deve ser enviada para SEFAZ-MG, correto? Se a SEFAZ-MG esta parada ele pode enviar a nota para a SEFAZ Virtual de Contingência do RS, desta forma a NF-e vai ser autorizada e o XML vai conter o numero do protocolo. Por outro lado não importa qual seja a UF do contribuinte, o MDF-e sempre vai ser enviado para a SEFAZ-RS

Boa tarde a todos, Neste caso o grupo <percurso> não se faz necessário uma vez que a UF de origem é vizinha da UF de destino. Só devemos informar o percurso quando o caminho tem que passar por um ou mais Estados que estão no meio do caminho entre a UF de origem e destino. Por exemplo UF origem = São Paulo, Destino = Mato Grosso, neste caso o caminhão tem que passar por Mato Grosso do Sul. No Percurso devemos neste exemplo informar somente a UF de Mato Grosso do Sul. O problema é outro, o MDF-e que foi anexado não foi autorizado pelo simples fato de existir um MDF-e que não foi encerrado. Por favor abra o arquivo: 359000464203839-pro-rec.xml Rejeição: Existe MDF-e não encerrado há mais de 30 dias para o emitente [chMDFe Não Encerrada:35181113296533000104580010000001181000000011][NroProtocolo:935180029067468] A chave em negrito é a chave do MDF-e que não foi encerrado. Enquanto esse MDF-e não for encerrado você não vai conseguir autorizar nenhum outro MDF-e.

Boa tarde Luiz, Caso tenha, favor anexar o XML que foi recusado e o que foi autorizado pela SEFAZ para que possamos fazer os ajustes necessários.

Boa tarde Werner, Acredito ter corrigido o problema, ainda hoje estarei enviando para o repositório.

Bom dia Delfino, Vamos analisar o problema e acredito que ainda hoje estaremos enviando para o repositório a correção.

Bom dia Gabriel, Estamos analisando o problema. Você esta usando o Capicom o WinCrypt?

Bom dia Dercide, Em qual momento ocorreu esse erro? Esta estranho, pois o XML com o pedido de cancelamento foi gerado e assinado e o XML de retorno foi salvo.

Bom dia Daniel, Se tratando de NFS-e precisamos tomar cuidado. Temos o XML do RPS e da NFS-e, é este último que devemos carregar para poder imprimir o DANFSE no papel ou gerar o seu PDF através do método ImprimirPDF. Utilize o programa exemplo para realizar os testes. Ao clicar no botão Imprimir ou PDF selecione o XML referente a NFS-e.

Bom dia Maiquel, Seria interessante testar com outra cidade que também usa o provedor Pronim. Pois essa configuração pode ser especifica para a cidade Feliz/RS.

Bom dia, O componente esta configurado para usar o Capicom ou WinCrypt?

Bom dia Danilo, Você esta configurando o componente com o Capicom ou WinCrypt? Se for com Capicom favor testar com WinCrypt.

Bom dia Barrys, Você esta tentando enviar o RPS através do método Gerar, tente através do método Enviar e depois pelo EnviarSincrono.

Bom dia Márcio, Muito obrigado pela correção, ainda hoje estarei enviando para o repositório.

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

Bom dia Marcos, Eu me refiro ao arquivo INI que contem os dados da nota e não o arquivo INI referente a configuração do Monitor.

Boa tarde Marcos, Se você configura o Monitor para a versão 4.00 da NF-e e o XML é gerado segundo a versão 3.10 isso significa que no seu arquivo INI você deve estar colocando o valor 3.10 no campo Versao.

Boa tarde Kelly, Mais uma vez muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde BS, Os arquivos que você anexou se refere ao ambiente de homologação que conforme dito esta funcionando sem nenhum problema. Sendo assim eles não vão ajudar em nada, uma vez que o problema é no ambiente de produção.

Boa tarde a todos, Primeiramente, o evento de Prestação de Serviço em Desacordo se refere ao CT-e e não a NF-e. Segundo, no CT-e temos o Remetente e o Destinatário da Carga a principio um desses dois é o tomador do serviço. Conforme consta no Manual do CT-e versão 3.00 página 30, o respectivo evento deve ser enviado pelo Tomador. Portanto quem vai enviar o evento de Prestação de Serviço em Desacordo é o Tomador que pode ser o Remetente ou o Destinatário da Carga. Gustavo, acho que a sua rotina pode ser simplificada. ACBrCTe.EventoCTe.Evento.Clear; ACBrCTe.EventoCTe.Evento.Add; ACBrCTe.EventoCTe.Evento[0].infevento.chCTe := ChaveCTe; ACBrCTe.EventoCTe.Evento[0].infevento.CNPJ := emitente.cnpj_cpf; ACBrCTe.EventoCTe.Evento[0].infevento.dhEvento := now; ACBrCTe.EventoCTe.Evento[0].infevento.nSeqEvento := NumeroEvento; ACBrCTe.EventoCTe.Evento[0].infevento.tpEvento := tePrestDesacordo; ACBrCTe.EventoCTe.Evento[0].infevento.detEvento.xOBS := ObsDesacordo; ACBrCTe.EnviarEvento(NumeroEvento); ACBrCTe.EventoCTe.GerarXML; Agora é só testar.

É capaz do contador confundir Manifesto de Documentos Fiscais Eletrônicos com Manifestação do Destinatário.