Italo Giurizzato Junior

Boa tarde Junior, Não entendi o que você fez para obter esse retorno com as rejeições.

Bom dia Sandro, O componente esta gerando o Json abaixo: {"xml": "%s", "usuario": "%s", "senha": "%s"} Note que é passado o conteúdo do XML ao campo xml, o usuário e a senha. A não ser que esteja faltando mais alguma coisa nesse Json.

Bom dia, No meu entendimento é impossível o provedor Giss usar as mesmas URLs do webservice do provedor Ginfes. Vendo os XMLs notei que ao retornar a situação do processamento do lote consta o valor 3, ou seja, o lote foi processado com falhas. Ao consultar o lote para obter a lista de rejeições é retornado a seguinte mensagem: <Mensagem>[result returns more than one elements; nested exception is javax.persistence.NonUniqueResultException: result returns more than one elements]</Mensagem> Traduzindo temos: resultado retorna mais de um elemento; a exceção aninhada é javax.persistence.NonUniqueResultException: o resultado retorna mais de um elemento Tentei entrar em contato com o provedor Giss e até o momento não tive retorno, questionei eles a respeito das URLs. O meu conselho é fazer com que os seus clientes protocolem uma reclamação na prefeitura. Quanto mais contribuinte reclamarem na prefeitura mais rápido o problema vai ser sanado.

Bom dia Valter, A sua alteração não esta correta, pois fazer uma alteração na unit ACBrNFSeXGravarXml_ABRASFv2 pode gerar um efeito colateral para outros provedores. O correto é incluir a linha: FormatoItemListaServico := filsSemFormatacao; Na procedure Configuracao da unit ISSe.GravarXml uma vez que a cidade de Maringá/PR é atendida pelo provedor ISSe.

Primeiramente: A Configuração do ambiente de produção é a mesma a de homologação, não faz sentido você ter configurações uma para cada ambiente e também são as mesmas para todos os serviços disponibilizados pela SEFAZ. Se você utiliza certificado A1, te aconselho usar o libOpenSSL em vez do libWinCrypt, pois com o OpenSSL a sua aplicação não depende de versão e atualização do Windows. Quanto a usar o método ConsultarCadastro do componente ACBrNFe não vejo nenhum problema, inclusive tenho na minha aplicação uma tela para fazer essa consulta.

Voltando o assunto referente ao MD5. Fiz um teste usando a senha: 123456789 Da forma que esta hoje no componente : LowerCase(AsciiToHex(MD5(Emitente.WSSenha))) Tive o seguinte valor: 25f9e794323b453885f5181f1b624d0b Usando somente a sua função tive o seguinte valor: 25f9e794323b453885f5181f1b624d0b Ou seja em ambos o resultado foi o mesmo. Fiz um outro teste colocando na senha letras, dígitos e o símbolo "@" e resultado também foi o mesmo.

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

Bom dia, Fiz alguns ajustes, favor atualizar os fontes e faça novos testes. Esse provedor não retorna no XML o numero do protocolo, isso explica o porque do campo Protocolo estar vazio.

Bom dia, Deleta o ACBrInstall_Trunk2.exe e atualize novamente. Essa versão é antiga.

Eliezer, Te respondi no privado. Para que todos saibam o provedor esta gerando o XML da NFS-e de forma errada.

Bom dia, Pelo erro você configurou o componente para usar o SSL v3, hoje as SEFAZ se utilizam do TLS 1.2 Atribua o valor TL_TLSv1_2 a propriedade SSLType.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, E por que você quer usar o Capicom? Os provedores estão adotando a criptografia TLS 1.2 que não é suportada pela Capicom. Qual é dificuldade em configurar a sua aplicação para usar o WinCrypt?

Bom dia Joas, Se esta ocorrendo erro na leitura do retorno eu preciso desse retorno e do erro para analisar e fazer as correções.

Bom dia Eliezer, O XML da NFS-e é gerado pelo webservice, se no XML esta aparecendo o telefone e e-mail do tomador dentro do grupo prestador, então o problema é no webservice do provedor. Se possível anexe os XMLs gerados para que eu possa analisar.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde ALA, Já inclui na minha lista de tarefas.

Rene, Você atualizou os fontes e fez novos testes? Eu fiz algumas alterações que devem resolver o problema.

Boa tarde Valdir, Você chegou a abrir esses arquivos? Note que além do arquivo de envio do lote, tem o arquivo referente a consulta a situação do lote e o referente a consulta ao lote. O provedor ISSCuritiba segue a versão 1 do layout da ABRASF, sendo assim após o envio do lote se faz necessário consulta a situação do lote, se a situação for 3 ou 4 devemos consultar o lote para obter as rejeições ou os XMLs das NFS-e. Se esta gerando todos esses arquivos isso significa que o componente esta realizando essas consultas de forma automática. Você pode até desligar esse comportamento do componente atribuindo o valor False a propriedade de configuração: ConsultaLoteAposEnvio, mas você vai ter que fazer essas consultas depois via código. Para diminuir um pouco essa quantidade de arquivos você também atribuir o valor False a propriedade de configuração: Configuracoes.WebServices.Salvar Mas enquanto você esta em uma fase de testes é melhor deixar do jeito que esta.

Favor atualizar os fontes e faça novos testes. Fiz uma alteração no tratamento do retorno do Consultar Lote.

Boa tarde Rene, Favor atualizar os fontes e faça novos testes.

Rene, Favor atualizar os fontes e faça novos testes. Note que atualizei também os schemas.

Boa tarde, Favor atualizar os fontes e faça novos testes. Note que atualizei também os schemas do provedor.

Boa tarde, Estamos trabalhando para simplificar e unificara os retornos. Muito obrigado pelos XMLs vou analisar eles.

Boa tarde Sandro, Temos mais relatos desse problema. No arquivo gerado para se enviado para o webservice já conferi e nele consta o XML da nota, usuário e senha. Não entendi porque esse provedor retorna essa mensagem. Por favor entre em contato com o provedor e tenta descobrir o que esta ocorrendo.