Italo Giurizzato Junior

Bom dia Anderson, Não entendi o motivo de você esta executando esse comando dentro da pasta System32.

Boa tarde Renato, Essa mudança é só para a cidade de Ponta Porâ/MS ou são para todas as cidades atendidas pelo provedor ISSNet?

Boa tarde Hugo, Favor entrar em contato com a prefeitura para saber com exatidão se o webservice da mesma espera receber o XML segundo esse manual ou se espera receber o XML segundo a versão 1 do layout da ABRASF. Até onde sei Salvador possui um webservice próprio que foi construído com base na versão 1 do layout da ABRASF.

Boa tarde Gabriel, Favor atualizar todos os fontes de todas as pastas e reinstale os componentes. Note que fiz uma alteração em vários arquivos INI de provedores.

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

Boa tarde Sergio, Entendi, já passei para o administrador do fórum fazer a alteração, muito obrigado.

Boa tarde Fabio, E quais seriam esses 3 parâmetros? Chegou abrir o XML de consulta para ver se o componente não os coloca de forma automática?

Boa tarde Anderson, Após alterar o arquivo ACBrBPeServicos.ini você executou o BAT chamado Compila_RES ?

Bom dia Moreira, Acredito ter encontrado o problema, ainda hoje estarei enviando uma possível correção para o repositório.

Bom dia Mariana, Você não esta usando o componente ACBrNFSe para emitir a nota para o provedor Betha?

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

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

Bom dia Fabio, A rejeição é clara, a nota que você esta consulta não consta na base de dados da SEFAZ, ou seja, ela nem sequer foi enviada, se foi, foi rejeitada por conter alguma informação incorreta.

Bom dia Gabriel, Você poderia anexar esses XMLs para que possamos analisar? Na versão antiga da aplicação cujo cancelamento funciona, estava sendo usado o Capicom ou WinCrypt? E a nova versão o que usa?

Bom dia, Que cabeçalho você se refere, é a tag <mdfeProc>? Se sim, é obvio que não gerou, pelo simples fato do MDF-e não ter sido autorizado. Porque ele não foi autorizado? Não foi autorizado por existir uma pendencia. E a pendencia esta informada no arquivo (*-pro-rec.xml) que acusa a existência de um outro MDF-e que não foi encerrado. Entendeu?

Bom dia Gustavo, O método EnviarEvento não requer que você tenha carregado previamente o XML do CT-e. Trata-se de apenas uma alternativa para obter alguns dados, como chave, CNPJ e numero do Protocolo. Em qual unit ao debugar não passa pelo teste no que você se refere ao tpEvento?

Boa tarde Dercide, É preciso fazer mais testes para saber se foi um problema momentâneo ou não.

Boa tarde Rafael, Esse arquivo ExemplosXML.rar foi baixando do site da Pronim? Se sim, gostaria de saber se eles utilizam o ACBr para realizar testes. Pois os nomes dos XMLs são exatamente os mesmos usados pelo ACBrNFSe. ? Se o XML de exemplo é o que esta sendo usado agora para a cidade de Soledade/RS então a versão é a 2.02 Sendo assim no arquivo Cidades.ini será necessário mudar de Pronim para Pronimv2. E no arquivo Pronimv2.ini devemos incluir as URLs de homologação e de produção da cidade em questão. Favor entrar em contato com o provedor ou com a prefeitura e solicitar as URL de homologação e de produção.

Boa tarde Barrys, Favor entrar em contato com o provedor e pergunte a eles o que vem a ser essa mensagem. Pois não estou entendendo o que vem a ser: Setor Cadastrado.

Boa tarde Rubens, Se tratando do e-Social e Reinf, infelizmente não funciona se o certificado não for instalado dessa forma. Em vez de instalar o certificado no Windows e informar o numero de série do mesmo ao componente, experimente passar o caminho mais o nome do FPX e a senha do mesmo para o componente. E existe a opção de ler o conteúdo do Certificado salvo no banco de dados e passar juntamente com a senha do mesmo para o componente. Configuracoes.Certificados.ArquivoPFX := <caminho+nome do arquivo PFX> ou Configuracoes.Certificados.DadosPFX := <conteúdo do certificado lido do banco de dados> ou Configuracoes.Certificados.NumeroSerie := <numero de serie do certificado instalado no Windows> Para as duas primeiras opções configurar a senha também: Configuracoes.Certificados.Senha := <senha do certificado> Lembrando que as duas primeiras só funciona para certificado A1.

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.

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.