Italo Giurizzato Junior

Bom dia Rubens, Eu não vejo o que melhoraria na segurança se o nome do atributo é id ou Id. Agora, se o valor do atributo ID em vez de ser apenas 123 e passar a ser RPS123 ou Rps123 ou rps123 e este valor ser utilizado na assinatura ai eu concordo que segurança será mais fraca ou mais forte dependendo do valor atribuído ao atributo ID. Outra coisa, no ACBrNFSe para o provedor Salvador temos: Identificador=id portanto o atributo ID esta todo minúsculo. O valor do ID do RPS é: proSalvador: FNFSe.InfID.ID := 'RPS' + OnlyNumber(FNFSe.IdentificacaoRps.Numero); Note que o valor é alfanumérico, a duvida agora é o literal "RPS" tem que ser todo minúsculo? O valor do ID do Lote é: proSalvador: IdLote := 'Lote' + NumeroLote; Note que o valor é alfanumérico, a duvida agora é o literal "Lote" tem que ser todo minúsculo?

Agora deixa, da próxima vez, assuntos diferentes, tópicos diferentes. Muito obrigado pela compreensão.

Bom dia, Quando é o componente que gera o XML o provedor é definido através da informação do código IBGE da cidade. Mas ao ler um XML de um RPS ou NFSe como posso garantir que o mesmo se refere a uma determinada cidade? A minha cidade é Araraquara, mas estou lendo o XML de NFS-e (para imprimir o DANFSE) emitido por uma empresa de Ibaté. Araraquara é atendida pelo provedor Ginfes (segue a versão 1 do layout da ABRASF), já Ibaté é Fiorilli (segue a versão 2). Dai o motivo de descobrir o provedor pelo XML que esta sendo lido.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Rodrigo, Muito obrigado pela colaboração, fiz uma pequena alteração, ainda hoje estarei enviando para o repositório. Favor atualizar os fontes e repita os testes.

Bom dia ALA, Por favor vamos seguir as regras do fórum, assuntos diferentes tópicos diferentes, não misture os assuntos.

Bom dia Marcos, Com essa alteração o envio de um lote com 1 ou mais RPS foi processado com sucesso? Qual método foi utilizado para o envio (Enviar ou EnviarSincrono)?

Bom dia Everto, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Esse XML esta errado, pois segundo o manual o grupo <ideServSaude> fica dentro do grupo <aso> logo após o grupo <exames> Favor montar corretamente o XML e faça novos testes.

Bom dia Paulo, Realmente o IE informado no grupo <rem> se refere ao CNPJ também informado no mesmo grupo. Favor entrar em contato com a SEFAZ e questionar sobre esse problema, uma vez que ao realizar uma consulta desse CNPJ através do Webservice Consultar Cadastro disponibilizado pela própria SEFAZ retorna exatamente o IE que esta sendo informado no XML.

Bom dia Everto, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Arce, No componente o nome da tag usada na consulta é numeroReciboFechamento, vamos aguardar a publicação de uma Nota Técnica que define o nome correto a ser utilizado.

Bom dia, Você poderia anexar a unit alterada para que possamos analisar a sua proposta de correção?

Bom dia, Favor atualizar os fontes e faça novos testes.

Boa tarde Gean, A Manifestação do Destinatário é um evento, na verdade 4 eventos. * teManifDestCiencia ==> Este evento diz que o Destinatário tem Ciência da Operação, ou seja, esta informando a SEFAZ que realmente comprou o produto. * teManifDestDesconhecimento ==> Este evento diz que o Destinatário Desconhece a Operação, ou seja, esta informando a SEFAZ que não comprou o produto. * teManifDestConfirmacao ==> Este evento diz que o Destinatário Confirma a Operação, ou seja, esta informando a SEFAZ que recebeu o produto. * teManifDestOperNaoRealizada ==> Este evento diz que o Destinatário Não Confirma a Operação, ou seja, esta informando a SEFAZ que não recebeu o produto (neste caso se faz necessário uma justificativa). Gostaria de saber qual é a sua duvida, uma vez que a passagem das informações para o componente é semelhante a da carta de correção ou do cancelamento, uma vez que estes também são eventos.

Bom dia Wagner, O que não esta funcionando é o envio da Carta de Correção do CT-e, correto? Por outro lado o Cancelamento do CT-e esta tudo OK, correto? Na página 30 do Manual do CT-e versão 3.00 temos uma tabela de eventos. No primeiro quadro são os eventos enviados pelo Emitente do CT-e. Nesse quadro temos 5 eventos, sendo apenas 1 (EPEC) é enviando para a SVC - SEFAZ-Virtual de Contingência, os demais são enviados para a SEFAZ-Autorizadora, que no seu caso é SEFAZ-SP. Os 4 eventos que são enviados para a SEFAZ-Autorizadora são: CC-e, Cancelamento, Registros do Multimodal e Informações da GTV. Se o envio do evento de Cancelamento esta funcionado, o de CC-e também deveria funcionar uma vez que vão para o mesmo webservice. Você poderia anexar o XML do evento de CC-e para que possamos analisar?

Bom dia, Favor anexar o XML do evento para que eu possa fazer um teste usando o programa exemplo.

Bom dia Anderson, Como esta a configuração referente ao Certificado e WebServices no programa exemplo?

Bom dia Rodrigo, Muito obrigado pelo Schema, já fiz a alteração no componente para que ele gere a tag <InscricaoEstadual> quando o provedor for Coplan. Ainda hoje estarei enviando para o repositório.

Bom dia Leonard, No programa exemplo você também esta usando o EnviarSincrono? Se no programa exemplo funciona e na sua aplicação não, então "debuga" a sua rotina que configura o componente, pode ter alguma coisa errada nela.

Bom dia Roberson, Muito obrigado pela colaboração, não se faz necessário colocar o IF fiz diferente, ainda hoje estarei enviando para o repositório.

Bom dia Cesar, Desde já muito obrigado pela colaboração, vamos aguarde que algum moderador com experiência em Fortes Report possa avaliar a sua colaboração, estando tudo OK com certeza será enviada para o repositório.

Bom dia ALA, Se os dados da nota estão no índice 1 em vez de zero isso significa que esta faltando alguma informação no XML de retorno que faz com que ele não encontre o RPS que já esta na lista (índice zero) e acaba ADD mais um item na lista e coloca os dados nesse novo índice. Normalmente no XML da NFS-e tem que constar o Numero e Série do RPS para que seja possível fazer a comparação com o RPS carregado ao realizar a consulta. Se no XML da NFS-e não for retornado por exemplo a Série do RPS, ao procurar na lista não vai achar e consequentemente vai colocar os dados da nota em um novo elemento, dai o motivo de você esta encontrando as informações desejadas no índice 1. Favor anexar o XML do RPS a ser consultado e o XML de retorno da consulta.

Bom dia Rubens, Tome como base o programa exemplo, nele após o envio é mostrado como ler o retorno. Vide a rotina do botão [Enviar].