MarcosRWeimer

Boa pergunta, foi o que o pessoal do suporte me passou, vou verificar.

Sim, no validador da receita passa normalmente

Ola! Seguinte, temos um cliente que precisa enviar os XMLs das notas para a Amazon, porem eles estão negando o mesmo por um "problema" na assinatura. XML assinado pelo ACBr (negado pela Amazon): XML assinado por um terceiro, aceito normalmente pela Amazon: Observem que os atributos da "Signature" são diferentes, se o cliente vai la e apaga o "xmlns:Signature.." a Amazon aceita o XML. Alguma sugestão de como resolver isso?

Bom dia! Vi sim, só não tive tempo para testar ainda (em um teste de 5 minutos parece estar ok), está meio corrido aqui Estava focado alterações para equiplano, agora surgiu uma para IPM mas solicitei a documentação ao suporte deles, tem um campo "novo" que não tem no ACBrNFSe nem no ACBrNFSeX, mas para justificar pedi a documentação, mas isto é outra thread

Boa Tarde Italo! Atualizei e realizei os testes, está funcionando corretamente. Desculpe pela demora em testar, estava com outros problemas aqui para resolver. Obrigado

Bom Dia Italo! Funcionou a questão da quebra de linha. Acredito que só falte validar minha alteração no ConsultaNFSePorRPS de NFSe cancelada que postei acima

Bom Dia Italo! - Segue anexo sugestão de melhoria para a ConsultaNFSePorRPS de NFS-e Cancelada. - Testei com NFS-e Cancelada e não cancelada. - Falta a questão da quebra de linha ACBrNFSeXWebservicesResponse.pas Equiplano.Provider.pas Vou fazer update e testar, estava postando a questão do ConsultaNFSeporRPS, ja testo e atualizo novamente aqui

- Esta questão da quebra de linha será tratada no componente ou na aplicação ? (Particularmente prefiro no componente assim já evita problemas para outros desenvolvedores) - Outra questão (que está ligada diretamente a esta) é a consulta de status (ConsultaNFSePorRPS) de uma NFSe cancelada, não está considerando o cancelamento no retorno. Retorno: <es:esConsultarNfsePorRpsResposta xmlns:es="http://www.equiplano.com.br/esnfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.equiplano.com.br/esnfs consultarNfsePorRpsResposta_v01.xsd"> <nfse> <nrNfse>32</nrNfse> <cdAutenticacao>F2ACDF08BDD106755D8263CB198B50CB</cdAutenticacao> <dtEmissaoNfs>2022-03-04T09:10:30</dtEmissaoNfs> <nrRps>357</nrRps> <nrEmissorRps>1</nrEmissorRps> <cancelamento> <dtCancelamento>2022-03-04T09:13:24</dtCancelamento> <dsCancelamento>TESTE CANCELAMENTO DATA/HORA CANCELAMENTO: 04/03/2022 09:11:34</dsCancelamento> </cancelamento> </nfse> </es:esConsultarNfsePorRpsResposta> Veja que é retornado o bloco de cancelamento, porem o TNFSeConsultaNFSeporRpsResponse não suporta tais campos, se não houver objeção posso tentar implementar

Essa sua idéia me fez realizar um debug mais detalhado no motivo do cancelamento e acabei encontrando uma falha. No ACBrNFSe tratava: erador.wCampo(tcStr, '#4', 'MotivoCancelamento', 01, 36, 1, MotivoCanc, ''); Gerador.wCampo(tcStr, '#4', 'MotivoCancelamento', 01, 36, 1, MotivoCanc, ''); Já no ACBrNFSeX: procedure TACBrNFSeProviderEquiplano.PrepararCancelaNFSe( Response: TNFSeCancelaNFSeResponse); Response.ArquivoEnvio := '<es:esCancelarNfseEnvio' + NameSpace + '>' + '<prestador>' + '<nrInscricaoMunicipal>' + OnlyNumber(Emitente.InscMun) + '</nrInscricaoMunicipal>' + '<cnpj>' + OnlyNumber(Emitente.CNPJ) + '</cnpj>' + '<idEntidade>' + FpCodigoCidade + '</idEntidade>' + '</prestador>' + '<nrNfse>' + Response.InfCancelamento.NumeroNFSe + '</nrNfse>' + '<dsMotivoCancelamento>' + Response.InfCancelamento.MotCancelamento + <--- AQUI '</dsMotivoCancelamento>' + '</es:esCancelarNfseEnvio>'; Apenas concatena, não removendo a quebra de linha. Removi manualmente e autorizou corretamente o cancelamento.

Boa Tarde! Mesmo problema. Pelo vi entre o ACBrNFSe e o ACBrNFSeX a direfença está no envelope soap, porem na teoria não deveria impactar já que não é o envelope que é assinado.

Observando minha resposta anterior, testei alterando tambem no ACBrNFSeX AACBrNFSeX.SSL.SSLType := LT_TLSv1_2; AACBrNFSeX.Configuracoes.Geral.SSLHttpLib := httpOpenSSL; porem o erro (1056 - Rejeição: Assinatura - Digest difere do calculado) continua

Abaixo AACBrNFSeX.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; AACBrNFSeX.SSL.SSLXmlSignLib := xsMsXml; AACBrNFSeX.Configuracoes.Geral.SSLLib := libWinCrypt; AACBrNFSeX.Configuracoes.Certificados.DadosPFX := LCertificado.DadosPFX; AACBrNFSeX.Configuracoes.Certificados.NumeroSerie := LCertificado.NumeroSerie; AACBrNFSeX.Configuracoes.Certificados.Senha := LCertificado.Senha; AACBrNFSe.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; AACBrNFSe.SSL.SSLXmlSignLib := xsMsXml; AACBrNFSe.Configuracoes.Geral.SSLLib := libWinCrypt; AACBrNFSe.SSL.Senha := LCertificado.Senha; AACBrNFSe.SSL.NumeroSerie := LCertificado.NumeroSerie; AACBrNFSe.SSL.DadosPFX := LCertificado.DadosPFX; AAcBrNFSe.SSL.SSLType := LT_TLSv1_2; AAcBrNFSe.Configuracoes.Geral.SSLHttpLib := httpOpenSSL;

Bom dia Italo! Testei aqui novamente mas sem sucesso. Anexo envio e retorno capturados diretamente do AService.Envio e do AService.Retorno dentro da procedure TACBrNFSeXProvider.CancelaNFSe envio.xml retorno.xml

Boa Tarde Italo! Anexo envio e retorno capturadas direto das variáveis FPEnvelopeSoap (envio) e FPRetornoWS (retorno) do cancelamento que ocorre corretamente no ACBrNFSe (dentro do ACBrDFeWebService na versão anterior do componente) envio_acbrnfse.xml retorno_acbrnfse.xml

Boa Tarde Italo! Acabei atualizar e testar aqui, está ok. Obrigado

Boa Tarde Italo! Sem sucesso. Anexo XMLs capturados diretamente do AService.Envio e do AService.Retorno dentro da procedure TACBrNFSeXProvider.CancelaNFSe envio.html retorno.html

Ola! Ao tentar cancelar ocorre a rejeição do Digest difere do calculado, passei algumas horas debugando mas não obtive sucesso. Estou fazendo o cancelamento usando de base o exemplo do ACBrNFSeX LInfCancelamento := TInfCancelamento.Create; try LInfCancelamento.NumeroNFSe := IntToStr(LNumNota); LInfCancelamento.SerieNFSe := LSerie; LInfCancelamento.ChaveNFSe := LcdAut; LInfCancelamento.MotCancelamento := LxMotivo; LInfCancelamento.NumeroLote := IntToStr(ANotaId); LInfCancelamento.NumeroRps := LNumRPS; //LInfCancelamento.SerieRps := LSerie; //LInfCancelamento.ValorNFSe := StrToFloatDef(ValNFSe, 0); //LInfCancelamento.CodVerificacao := CodVerif; // Codigo de Cancelamento // 1 - Erro de emissão // 2 - Serviço não concluido // 3 - RPS Cancelado na Emissão if LACBrNFSeX.Configuracoes.Geral.Provedor in [proCoplan, proWebISS] then begin LInfCancelamento.NumeroNFSe := FormatFloat('0000', YearOf(LDataEmissao)) + FormatFloat('00000000000', LNumNota); LInfCancelamento.CodCancelamento := '2'; end else LInfCancelamento.CodCancelamento := '1'; LACBrNFSeX.CancelarNFSe(LInfCancelamento); finally LInfCancelamento.Free; end; e o retorno (LACBrNFSeX.WebService.CancelaNFSe.Erros): 1056 - Rejeição: Assinatura - Digest difere do calculado

Sim, salvando direto pela ConsultaNFSePorRPS grava corretamente, pois lá na procedure TACBrNFSeXProvider.SalvarXmlNfse(aNota: TNotaFiscal) grava usando aNota.XmlNfse, ou seja, o xml da NFSe em si. coisa que no GravarXML não faz. Porem aqui por questões internas o caminho, nome do arquivo e configurações são dependentes de alguns fatores, por isso utilizamos o GravarXML.

Italo Infelizmente não funcionou, a sua alteração (no LerXml) foi mais ou menos como havia pensado em fazer aqui, porem faltou aqui: unit ACBrNFSeXNotasFiscais function TNotaFiscal.GravarXML(const NomeArquivo: String; const PathArquivo: String): Boolean; begin if EstaVazio(FXmlRps) then GerarXML; FNomeArqRps := CalcularNomeArquivoCompleto(NomeArquivo, PathArquivo); Result := TACBrNFSeX(FACBrNFSe).Gravar(FNomeArqRps, FXmlRps); <-- aqui considera o XML do RPS para salvar, o FXmlNfse está com o XML da NFSe corretamente end;

Bom dia! Se não carrego o XML do RPS ai ocorre "Argument out of range" quando vai obter a nota para gravar: function TNotasFiscais.GetItem(Index: integer): TNotaFiscal; begin Result := TNotaFiscal(inherited Items[Index]); <---AQUI end; P.S. Parâmetro para gerar o XML está ativo.

Acabei de testar.. mesmo resultado:

Suspeito que o problema esteja aqui: - Como pode ver no "LerXML" está sempre considerando que leu o XML da NFSe, mas pode ter lido o XML do RPS (ConsultaNFSePorRPS vai ler o xml do rps e não da nfse, até por que não tem ele ainda) - No "GravarXML" sempre está gravando o FXmlRps, ou seja, nunca grava a NFSe. Este impacto foi da alteração que acabou mudando os nomes das propriedades

Boa Tarde Italo! Acabei de atualizar os fontes e reinstalar, houve alguma outra alteração que impactou. O ANota.XmlRps está igual ao ANota.XmlNfse. debug no delphi: XML Antes (esquerda) e agora (direita)

Ola! Simulação: - carregar e emitir NFSe (retorno lote em processamento) - consultar NFSe por RPS - Retorno: autorizado/nfse - descarregar o xml do componente (fechar o sistema) - Carregar o xml da NFSe - Por padrão a opção GerarXML é marcada então carregar o xml e tenta gerar o XML novamente, ai ocorre o erro de conversion from integer. Causa: - Quando carrega o XML da NFSe (TNFSeR_Equiplano.LerXMLNfse) não carrega os dados do(s) serviço(s), deixando o "ItemListaServico" em branco (vazio) causando o erro de conversão na hora de gerar o xml. Solução/Correção: - Incluido "LerListaServico" para carregar os dados do(s) serviço(s) - Não tem impacto negativo pois dentro da própria procedure "LerListaServico" valida se existe ou não o node "listaServicos" Correção: anexo arquivo com a alteração. Equiplano.LerXml.pas

Ola! Simulação: - Alimento o componente - LACBrNFSeX.Emitir(IntToStr(ALote)); - LACBrNFSeX.NotasFiscais.Items[0].GravarXML(ExtractFileName(LCaminhoSalvar), ExtractFilePath(LCaminhoSalvar)); - retorno do provedor: 1604 - Esse lote está aguardando processamento. - Descarrego a nota do componente (fecho o sistema) - LACBrNFSeX.NotasFiscais.LoadFromFile(LCaminho); - LACBrNFSeX.ConsultarNFSeporRps(IntToStr(ALote), ASerie, '', ''); - LACBrNFSeX.NotasFiscais.Items[0].GravarXML(ExtractFileName(LCaminho), ExtractFilePath(LCaminho)); Problema: Neste momento (salvar o xml) salva o XML da resposta da ConsultaNFSePorRPS, quando deveria montar o xml da NFSe (equiplano não retorna a nota), verificando o codigo encontrei onde deveria montar, porem só considera o XML do RPS assinado, que não é o que está acontecendo. No meu ponto de vista a correção tem de ser esta (Equiplano.Provider.pas): Anexo possível correção Possível pois não tenho certeza deste ponto, pois no próprio Equiplano.Provider no "Configuracao" está setando True para assinar o LoteRps, talvez minha visão esteja equivocada e o problema está no gravar o xml, debugando não consegui identificar o ponto onde deveria ter assinado ou não o LoteRps. Equiplano.Provider.pas