Italo Giurizzato Junior

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.

Bom dia, Por favor não post conteúdo de arquivos. Outra coisa, sem o arquivo completo com todos os dados, não temos como lhe ajudar, pois não sabemos se você omitiu ou se não foi informado mesmo e se omitiu qual a informação que realmente esta no campo. Desculpe, mas com o arquivo que você postou não tenho como lhe ajudar.

São Carlos foi apenas um exemplo. Mas me diga onde você informa a UF de carregamento e a de descarregamento? O que vem a ser UF = PR -- Município = ABAPA na primeira imagem?

Bom dia Otavio, Se você utiliza o componente ACBrNFe basta abrir o fonte ACBrNFeUtil que esta na pasta: ...\Fontes\ACBrNFe2 e procurar pela function GetURLMG, você vai notar que as URLs para NFC-e não estão definidas. Se você souber quais são, por favor post aqui no fórum para que possamos atualizar o componente.

Bom dia Laster, Inclua a linha em negrito. (...) ACBrMDFe1.Manifestos.LoadFromFile(cArqMDFe); ACBrMDFe1.EventoMDFe.Evento.Clear; with ACBrMDFe1.EventoMDFe.Evento.Add do begin (...)

Bom dia, Quando você alimenta o componente, logo no grupo <ide> devemos informar a UFIni - Sigla da UF de Carregamento e UFFim - Sigla da UF de Descarregamento. Depois temos o grupo <infMunCarrega> onde devemos informar o código e o nome dos municípios de carregamento (limite de até 50), pois bem esses municípios tem que pertencer a UFIni. Da mesma forma também temos o grupo <infMunDescarga> onde devemos informar o código e o nome dos municípios de descarregamento (limite de até 100), pois bem esses municípios tem que pertencer a UFFim. Note que a rejeição diz: Código do Município diverge da UF de descarga do MDF-e Ou seja, os dois primeiros dígitos do código informado em cMunDescarga que se refere a UF não condiz com a sigla informada em UFFim. Em UFFim você informa MG, isso significa que a carga vai ser descarregada em Minas gerais, mas informa como cidade de descarregamento: São Carlos que fica no estado de São Paulo, isso esta errado. Se o caminhão vai fazer entrega em cidades de MG e de SP, devemos emitir 2 MDF-e. No primeiro relacionando somente a carga que vai ser descarregada em MG e o segundo relacionando somente a carga que vai ser descarregada em SP. Espero ter ajudado.