Italo Giurizzato Junior

Boa tarde a todos, Se ao solicitar o cancelamento apesar da mensagem de erro informando que o XML esta fora da estrutura, mas a nota é cancelada, conclui-se que o problema é no provedor. Favor entrar em contato com eles.

Boa tarde Valdir, Por favor leia a Nota Técnica 2014/001 que trata sobre o EPEC. Leia com muita atenção o Item 3 que consta na página 4. A atualização do XML da NF-e é realizado em um outro passo alem dos 3 que você relacionou.

Boa tarde jcanjo, No programa exemplo nas abas de configuração, quando fazemos referencia a UF destino, na verdade estamos nos referindo a UF autorizadora, realmente isso faz uma certa confusão. Pois a palavra destino não significa o destino da carga e sim o destino do XML, para onde será enviado o XML para ser autorizado. Vou fazer uma alteração no programa exemplo com o objetivo de deixar mais claro.

Boa tarde Iaster, Ao consultar a situação atual sempre vai retornar o protocolo de autorização, note que no XML de retorno dessa consulta consta os eventos vinculados a esse MDF-e. Neste caso o evento de encerramento e é ai que você vai encontrar o protocolo de encerramento.

Boa tarde Guto, Essa alteração que você postou, resolve o problema? Se sim, por favor post como anexo a unit com a respectiva alteração para que possamos realizar o merge.

Boa noite Murilo, Esse erro: 403 forbidden ocorre quando o certificado esta vencido.

Boa noite, O fragmento de XML se refere ao RPS que você gerou ou a da NFS-e retornada pelo provedor? O XML do RPS deve conter exatamente o que você informou, mas o da NFS-e, lembre-se que não é o componente que gera, apenas ele salva, uma vez que o mesmo é gerado pelo provedor e retornado.

Boa noite Iskailer, No XML da NF-e não temos mais o campo para informar o RENAVAM somente o <cilin> - cilindrada. Sendo assim o numero RENAVAM deverá ser informado no campo Observação.

Boa noite Guto, Alteração feita, por favor atualize os fontes.

Boa noite André, É interessante testar todas as funcionalidades disponibilizadas pelo provedor.

Boa noite Dangelo, Tenta conseguir com o provedor o XML completo (com as TAGs Envelope) para realizar a consulta.

Boa noite Guto, Aconselho a você estudar a solução usada no DANFSE - Quick Report, foi criado uma propriedade que nos permitir a ter um carácter de quebra de linha configurado para cada provedor.

Boa noite, Após o XML receber a assinatura digital é validado pelo validador do componente, caso ele não contenha nenhum erro é salvo na pasta ano\mês. Após o envio para SEFAZ caso este venha ser autorizado, o mesmo é atualizado recebendo o protocolo de autorização. Os XMLs que contem as mensagens de rejeição, são os de retorno da SEFAZ e só serão salvos em disco caso a propriedade: Configuracoes.Geral.Salvar contiver o valor True.

Boa noite Igor, A propriedade PathCan foi criada inicialmente para conter os XML da solicitação e de retorno da SEFAZ referente ao cancelamento. Mas isso não faz mais sentido, uma vez que já a um bom tempo o cancelamento é um evento, sendo assim o interessante agora é concentrar todos os eventos, separados por tipo.

Boa tarde Carlos, Já esta disponível.

Boa tarde Guto, Esse provedor não segue o padrão ABRASF, sendo assim se você desejar implementar fique a vontade.

Boa tarde Igor, O correto é ter o -1. Se você pesquisar nesse fonte toda vez que é passado o tipo de ambiente é desta forma.

Boa tarde Carlos, Muito obrigado pelas informações, fiz algumas alterações como você pode ver no arquivo em anexo: 20-ger-nfse-soap.xml Não tenho como testar o envio, uma vez que não possuo um certificado válido.

Boa tarde Marcelo, Muito obrigado pela colabora e desculpe pela demora. Já esta disponível. Favor atualizar os seus fontes.

Boa tarde Igor, Por favor abra a unit ACBrCTeWebServices, verifique se a linha 799 esta desta forma: infEvento.tpAmb := TpcnTipoAmbiente(FConfiguracoes.WebServices.AmbienteCodigo-1); Note que existe um menos 1, por que, o ambiente de produção é 1 e o de homologação é 2, correto? Mas o TpcnTipoAmbiente é definido da seguinte forma: TpcnTipoAmbiente = (taProducao, taHomologacao); Trata-se de um conjunto de valores que neste caso possui apenas dois, correto? Devemos lembrar que o índice do primeiro elemento é zero e não um, sendo assim isso explica o menos 1. Se configuramentos o ambiente para homologação a propriedade AmbienteCodigo vale 2, fazendo as contas 2-1 é um ou seja vai retornar o elemento de índice 1 ou seja o segundo elemento do conjunto que neste caso é taHomologacao. Concluo que o seu fonte tem alguma coisa alterada.

Boa tarde, A mensagem de rejeição é clara, o código da cidade de descarga diverge da UF de descarga. As cidades incluídas são de MG, qual é a UF informada em UFFim? Se possível post como anexo o XML do MDF-e que esta sendo rejeitado.

Boa tarde Carlos, O XML do RPS é criado pelo componente segundo a versão 2.00 do layout definido pela ABRASF. Alem disso o lote a ser enviado é submetido ao validador do componente que compara o XML com o XSD (Schema). Caso o XML contenha algum dado errado ou sua estrutura esta fora do estabelecido no XSD o componente já apresenta um erro de validação. O lote por sua vez é envelopado, ou seja, incluído dentro de um outro XML que vamos chamar de Envelope, este por sua vez é enviado para o Web Services. O componente esta gerando o seguinte Envelope em anexo: 19-ger-nfse-soap.xml Por favor de uma olha e me diga o que esta faltando ou o que esta a mais para que eu possa fazer as devidas correções. Lembrando que os dados não são reais.

Boa tarde lesf, Maravilha, vamos analisar e muito obrigado pela colaboração.

Boa tarde Igor, Por favor post como anexo o arquivo de envio e de retorno da respectiva CC-e.

Vamos as correções: Informado: [ide] cUF=DF modal=01 correto: [ide] cUF=53 modal=1 informado: [infCTe001] chCTe=53140811538486000132550010050285121050285123 SegCodBarra=0001 [infNFe000] chNFe= correto: [infCTe001001] chCTe=53140811538486000132550010050285121050285123 Observações: Procure sempre ter em mãos os manuais e notas técnicas, pois nelas temos a estrutura do XML com a descrição do campo e uma observação dele. Em cUF você informou a sigla e na Nota Técnica 2013/004 versão 1.00a do MDF-e página 93 temos que se trata do código da UF do emitente do MDF-e, portanto devemos utilizar a tabela do IBGE de código de unidades da federação. Outra coisa no grupo infCTe devemos colocar dois índices o primeiro se refere ao municipio de descarregamento e o segundo se refere ao CTe vamos a um exemplo: [DESC001] cMunDescarga= código do município 1 xMunDescarga= nome [infCTe001001] chCTe=chave do primeiro CT-e cuja carga vai ser descarregada no município 1 [infCTe001002] chCTe=chave do segundo CT-e cuja carga vai ser descarregada no município 1 [DESC002] cMunDescarga= código do município 2 xMunDescarga= nome [infCTe002001] chCTe=chave do primeiro CT-e cuja carga vai ser descarregada no município 2 Se o campo não tem informação não precisa incluir no arquivo e quando um grupo possui índice este sempre inicia em 1. Faça as correções e tente novamente.