Italo Giurizzato Junior

Bom dia Bruno, A diferença entre eles é que o "soap" contem a estrutura completa, ou seja, o seu conteúdo é exatamente o que o provedor recebe, logo ele esta recebendo com o usuário e senha. Você esta usando o programa exemplo para enviar? Se sim, qual é a exata mensagem de erro? É salvo algum arquivo de retorno?

Bom dia Fábio, Maravilha.vou incluir o provedor EGoverneISS na lista de provedores que estão funcionando 100%.

Bom dia, Analisando o seu XML notei que se tratado de um CT-e Modal Rodoviário - Lotação. Neste caso devemos informar os dados do veículo e do motorista. Notei que você informou 2 veículos, em ambos você diz que são de tração, como assim? Um tem que ser de tração e o outro reboque. Outra coisa você diz que o veículo é próprio, neste caso ele é de propriedade do emitente do CT-e, ou seja da transportadora. Neste caso não devemos informar o proprietário do veiculo, pelo simples fato ele ser do emitente do CT-e. No DACTE quando se tratar do modal rodoviário devemos imprimir o RNTRC da Empresa (transportadora). Se for lotação devemos imprimir os dados do Veiculo,tais como Tipo, placa, UF e RNTRC. O RNTRC referente ao veiculo será o da transportadora a não ser que o veiculo seja de terceiros, ai devemos informar os dados do terceiro (proprietário do veiculo) e um desses dados é o RNTRC. A impressão do DACTE conforme a figura que você anexou esta correto, porque você informou no XML que o veiculo é próprio, ou seja, da transportadora. O teu XML que esta errado, não condiz com a realidade, primeiro por informar 2 veículos de tração, segundo por informar o proprietário do veiculo, sendo que o mesmo é da transportadora. E o CNPJ do proprietário do veiculo informado no XML se refere ao remetente da carga, como assim?

Bom dia, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Edson, É preciso comparar o XML do RPS que anteriormente era processado e o de agora, para sabermos o que mudou. Depois ver o que precisa ser corrigido no DANFSE para que os valores sejam impressos da forma correta. No caso do DANFSE temos que lembrar que ele é usado pelos demais provedores, logo temos que tomar o cuidado de corrigir para um provedor e gerar um efeito colateral para os demais.

Boa noite Doni, Para efetuar o cancelamento de um CT-e não há necessidade do XML do mesmo, uma vez que o cancelamento é um evento. No que diz respeito a consulta o XML é interessante para que o componente seja capaz de atualizar o mesmo caso este não tenha o protocolo de autorização. Caso o XML não seja carregado ao efetuar a consulta, a atualização não será realizada, apenas o retorno com o status atual do CT-e será salvo em disco. A mensagem de URL não definida para o TCTeConsulta esta muito estranho.

Walter, Até hoje não vi nenhuma utilidade para o grupo <infUnidTransp>. Aconselho você ter em mãos o Manual do MDF-e versão 1.00a em mãos para saber quais são os campos obrigatórios e os que são opcionais. O grupo <infUnidTransp> é opcional.

Boa noite a todos, Página 103 do Manual do MDF-e versão 1.00a - a quantidade máxima do grupo <infNFe> é de 4000 (4 mil).

Walter, Peso total transportado é uma coisa, quantidade (peso) rateada é outra. Suponha que a carga total é formada por 3 CT-e com os seguintes pesos 300 Kg, 250 Kg e 400 Kg. Logo o peso total é de 950 Kg, que devemos informar em qCarga. Como temos 3 CT-e informados no MDF-e, caso você deseje informar os campos de infUnidTrans, por exemplo qtdRat de cada CT-e informado, você deve informar o peso de cada um deles. A somatória dos qtdRat será igual a qCarga.

Boa tarde Edson, Faça uma cópia dos seus fontes e depois atualize eles, noite que os seus fontes não estão sincronizados com o que esta no repositório. Por fim verifique a necessidade de suas alterações, caso seja necessário faça, e anexo os fontes alterados.

Boa tarde Bruno, Usando o programa exemplo, aba Web Services você esta informando o Senha e Usuário (os dois campos abaixo do quadro Proxy)?

Boa tarde Elazar, Favor atualizar os fontes e testar novamente.

Boa tarde Walter, O valor máximo aceito pela TAG qtdRat é 999.99 e você esta passando o valor: 14204.00

Bom dia Vanderlei, Use o programa exemplo ele gera o XML para você.

Bom dia Edvilson, Você esta vendo o bloco referente a leitura do RPS e não da NFSe. case LayoutXML of loABRASFv1: Result := LerNFSe_ABRASF_V1; loABRASFv2: Result := LerNFSe_ABRASF_V2; loEL: Result := False; // Falta implementar loEGoverneISS: Result := False; // Falta implementar loEquiplano: Result := LerNFSe_Equiplano; loGoverna: Result := LerNFSe_Governa; loInfisc: Result := LerNFSe_Infisc; loISSDSF: Result := LerNFSe_ISSDSF; loCONAM: Result := LerNFSe_CONAM; loAgili: Result := LerNFSe_Agili; else Result := False; end;

Bom dia Ricardo, No grupo <vPrest> temos os campos: vTPrest (Valor Total da Prestação do Serviço) e vRec (Valor a Receber). Pela interpretação dos nomes dos campos o vTPrest é valor total a ser cobrando pelo serviço, por exemplo R$ 100,00, já vRec é o valor ainda a ser recebido, vamos a alguns exemplos: Supondo que o serviço de transporte vai ficar em R$ 100,00 logo o vTPrest é igual a 100. Só vou pagar quando o transporte for finalizado, logo vRec é igual a 100. Caso a transportadora opte por gerar uma fatura desse valor ou até mesmo dividir em 2x essas informações devem constar nos grupos <fat> e <dup>. Por outro lado se eu deixar pago o serviço, os valores serão: vTPrest = 100 e vRec = 0 pois a transportadora não tem nada a Receber, o serviço já esta pago. Posso também pagar metade antes e a outra metade quando o serviço for concluído, neste caso os valores serão: vTPrest = 100 e vRec = 50. Novamente a transportadora poderá lançar esses R$ 50,00 a receber em uma fatura e neste caso informar nos grupos já descritos acima. Resumindo, no meu entendimento se o valor de vRec for diferente de zero e a transportadora for gerar uma fatura de cobrança, ela deve informa-la no XML do CT-e nos grupos <fat> e <dup>.

Bom dia Elazar, Favor atualizar os fontes, pois detectei um código que estava acrescentando uma nota vazia a mais na lista de notas retornadas pelo provedor. Repita os testes com os fontes alterados.

Bom dia, Entre em contato com o provedor e diga que a URL que esta sendo usada consta no WSDL do web services e mesmo assim não funciona. Precisamos saber com exatidão qual é a URL para os ambientes de homologação e produção bem como os SoapAction usados para cada serviço (Envio, consulta, cancelamento, ...).

Bom dia, O componente Gera o XML do RPS e neste com a propriedade ativada acredito que não é para conter vogais acentuadas e cedilha. Por outro lado o XML da NFS-e (o que você anexou) é gerado pelo provedor, o componente apenas o obtêm pelo retorno e salva em disco. Sendo assim a propriedade não atua nesse processo. Sendo assim, se o provedor gerar o XML da NFS-e com palavras acentuadas, estas vão estar presentes e o componente não vai altera-las.

Bom dia Souza, Você notou que o programa exemplo possui 3 botões de envio, correto? Pois bem, notou que em cada um deles o método utilizado é diferente? Pelos testes percebeu que somente 1 deles funciona para o provedor Ginfes. Os outros 2 se utilizam de métodos de envio que o Ginfes não disponibilizou em seus Web Services, sendo assim não podemos utiliza-los. O programa exemplo possui uma procedure chamada AlimentaComponente, e dentro desta existe um ADD logo no inicio, que tem como finalidade de adicionar um RPS a lista. Se eu executar o AlimentaComponente 10 vezes e em cada uma delas passar os dados um RPS diferente, você concorda que vou estar adicionando 10 RPS a lista? Todos os provedores (incluindo o Ginfes) que utilizam o método Enviar para transmitir os RPS para o Web Service, aceitam um Lote com até 50 RPS. Podemos então concluir que, se eu adicionar 10 RPS a lista e depois executar o Enviar, estarei enviando os 10 RPS de uma unica vez, você concorda?

Bom dia Felipe, O erro de divergência de DigestValue só ocorre quando o XML é gerado e assinado novamente com algum dado alterado. Vamos a um exemplo: O XML foi gerado, assinado e enviado para a SEFAZ, esta por sua vez recebeu processou, gerou o protocolo de autorização, mas por algum motivo na conexão o protocolo não foi retornado. Quando usamos o LoadFromFile sem o segundo parâmetro, ocorre a leitura dos dados que estão no XML, mas um novo é gerado e assinado. Ao realizar a leitura e uma nova geração, pode ocorrer a alteração de alguma informação, por exemplo conversão de algum carácter especial, isso já é o suficiente para que um novo DigestValue seja gerado ao ser realizada a assinatura. Ao executar o Método Consultar, o componente compara o DigestValue do XML com o que vem com o protocolo, se for diferente o erro é apresentado. Se isso esta ocorrendo é interessante baixar o XML do site e passar um pente fino por todas as TAGs em busca da informação diferente. Desta forma podemos descobrir se existe algum Bug no componente.

Walter, No grupo <tot> temos as tags: cUnid e qCarga, onde cUnit pode receber os valores uKG ou uTON, por outro lado qCarga tem um tamanho de 11,4 Se a carga total for de 20 Toneladas, você deve alimentar o componente da seguinte forma: tot.cUnid := uTON; tot.qCarga := 20;

Boa noite Jhon lenon, No seu caso o programa é a impressão do DAMDFE que precisa ser corrigido.

Boa noite Elazar, Você poderia anexar o XML de retorno de cada etapa?

Boa noite Walter, O peso que você se refere é da carga Total ou do Rateio? No meu entendimento se a qtdRat for expresso em peso, temos então até 999,99 Kg ou 999,99 Ton