Italo Giurizzato Junior

Boa tarde Jemison, Primeiramente você não envia um lote de NFS-e e sim de RPS. O provedor valida os RPS enviados e caso estejam OK eles serão convertidos em NFS-e e retornados para você. Cada RPS tem que ter um numero sequencial, sendo assim ao enviar o primeiro lote com 3 RPS estes deverão ter os números: 1, 2 e 3, quando for enviar o segundo lote contendo 5 RPS (por exemplo) os seus números serão: 4, 5, 6, 7 e 8. Alguns provedores exigem que o numero do lote também seja sequencial sendo assim no exemplo acima o primeiro Lote terá como numero o valor 1 o segundo 2 e assim por diante. Caso algum RPS não seja validado pelo provedor, ou seja, contem alguma informação errada sempre é informado o numero do RPS. Espero ter ajudado.

Bom dia Adriano, Essa alteração proposta por você para pular linha de forma correta tem que ser feita no arquivo 4R.INI ? Se sim, por favor anexar o mesmo alterado para que possamos avaliar. Muito obrigado pelos testes e informação que o componente esta funcionando 100% com o provedor 4R.

Boa tarde Almeida, A TAG ConsultaLote que você se refere na página 39 do manual não seria ConsultaLoteRequest ? Se sim essa é a TAG principal do corpo note que dentro dela temos as TAGs VersaoSchema e MensagemXML. Dentro desta última devemos colocar a mensagem XML conforme a estrutura mostrada no item III da página 38. Mas segundo o schema: PedidoConsultaLote_v01 temos que colocar essa estrutura dentro do grupo PedidoConsultaLote, veja: <xs:element name="PedidoConsultaLote"> <xs:annotation> <xs:documentation>Schema utilizado para PEDIDO de consultas de Lote.</xs:documentation> Perante o manual e schemas que temos a geração do pedido de consulta ao lote enviado esta em conformidade.

Boa tarde Heber, A sua aplicação esta configurada para Capicom ou OpenSSL? Pois acabei de realizar um teste usando o Capicom, o XML referente ao envio do lote contendo 2 RPS, foi gerado e assinado sem nenhum problema.

Boa tarde a todos, É preciso "debugar" para saber com qual valor as variáveis: TagEndDocElement e ConteudoXML possuem ao chegar na linha: I := PosLast(TagEndDocElement, ConteudoXML); A partir dai tentar descobrir o ponto onde é alterado ou gerado o nome da TAG de forma errada.

Bom dia Walter, Você chegou a configurar o componente com libCapicomDelphiSoap. Pois esta configuração se utiliza do HTTPReqResp.

Bom dia Dorneles, Favor anexar o INI corrigido.

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

Boa tarde Léo, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Adilson, Precisamos se os parâmetros das funções envolvidas estão recebendo a informação correta, acredito que coisa esteja faltando ou o XML do RPS esta sendo passado de forma truncado provocando a falha na assinatura.

Boa tarde Fernando, O componente não gera o XML da NFS-e, apenas gera o XML do RPS e assina se assim o provedor exige. O XML da NFS-e é gerado e retornado pelo provedor, se o mesmo não vem assinado é pelo simples fato do provedor não incluir no mesmo a assinatura. Quanto ao erro ele aparece ao tentar carregar o XML da NFS-e para ser impresso? Se sim será necessário "debugar" para descobrir o exato momento onde isso ocorre.

Boa tarde Humberto, Tem provedores que há necessidade de se fazer um cadastro para emitir NFS-e via site e um outro para emitir via Web Services.

Bom dia Valdir, Abra o arquivo Fiorilli.INI com o bloco de notas e altere o valor de UseCertificado de 1 para 0 e faça novos testes.

Bom dia Marcelo, Mesmo configurando essas 3 propriedades o erro continua?

Bom dia Diogo, Então podemos incluir o DBSeller na galeria dos provedores funcionando 100% no Trunk2.

Bom dia Fernando, Se a prefeitura diz que os RPS recepcionados ficam na fila aguardando o processamento e o tempo de espera chega a 5 minutos, quem tem que resolver isso é o provedor e não nós.

Bom dia Márcio, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Diogo, Maravilha, estamos caminhando, vamos ver se consigamos fechar com chave de ouro. Por favor atualize mais uma vez e realize novos testes.

Marcelo, Você configurou os dados do Emitente? Vide o programa exemplo.

Boa tarde Marcelo, O componente esta configurado para realizar a consulta do lote após o envio?

Bom dia Larry, No caso da NFS-e a validação é sempre por lote, não existe a validação individual do RPS. E a validação é feita de forma automática pelo pelos métodos de envio: Enviar, Gerar e EnviarSincrono. Foi feito desta forma pois temos provedores que não disponibilizaram os seus schemas para realizar a validação.

Bom dia Marcos, O emitente da NFS-e é o próprio prestador, sendo assim você deve configurar os dados do emitente. Vide o programa exemplo.

Bom dia Almeida, Pela mensagem de erro diz que a TAG PedidoConsultaLote não era esperado. Precisamos recorrer ao manual para saber se o nome da TAG esta correto, ou se a posição que a mesma foi incluída no XML esta correto.

Bom dia Marcelo, Favor atualizar todos os fontes de todas as pastas.

Bom dia Diogo, Muito obrigado pela colaboração. Favor atualizar os seus fontes em especial os arquivos INI pois eles estão desatualizados.