Italo Giurizzato Junior

Almeida, Normalmente o erro 403 tem haver com o certificado que pode estar vencido ou só serve para assinar e não para consumir o Web Services.

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

Jemison, Experimente aumentar o valor da propriedade TimeOut.

Heber, Ao ADD os RPS ao componente pela segunda vez em diante você esta limpado a lista com o Clear? Fiz um teste gerando um lote com 10 RPS. Foi gerado e assinado sem nenhum problema. O envio só não foi feito pelo simples fato de eu estar usando um certificado vencido.

Boa tarde Walter, Enviei para o repositório Branches algumas alterações. Mas pela mensagem de erro da impressão que ele não esta conseguindo encontrar o arquivo ACBrANeServicos.Res, isso é estranho pois esse arquivo existe e esta junto com os fontes do componente.

Boa tarde Felipe, Por favor faça todos os testes, envio, consulta e cancelamento e nos de um retorno para que possamos incluir a Tecnos como mais um provedor que esta funcionando 100%.

Boa tarde Cristiane, Favor entrar em contato com eles a fim de saber se seguem o padrão ABRASF ou não. Solicitar os schemas (arquivos XSD) bem como XMLs de exemplos de: envio, consulta, etc. Se for padrão ABRASF a implementação é rápida, caso contrario teremos que saber qual layout ele segue, neste caso a implementação vai demorar ou até mesmo não ocorrer, tudo depende como funciona esse provedor.

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.