Jump to content

DatawebDev

Membros Pro
  • Posts

    8
  • Joined

  • Last visited

Everything posted by DatawebDev

  1. Boa tarde Victor. Esse XML foi extraído dos XML de comunicação com o web service, gerado pelo ACBr. Fomos nós quem salvamos em utf8-bom. Nas primeiras tentativas de carga do XML, salvamos com charset win1252, e depois utf8 (sem BOM), mas o método TNotasFiscais.LoadFromFile dava um erro de "charset desconhecido" em inglês, que esquecemos de capturar para relatar. Por fim testamos com charset utf8-bom, e então o método LoadFromFile parou de reclamar de charset explicitamente. Estávamos testando com ACBrTrunk2 atualizado até segunda-feira 27/03 (r25068). Atualizei os componentes do ACBr aqui, e consegui carregar os arquivos com charset win1252 e utf8, sem nenhum erro. Muito obrigado pela ajuda!
  2. Ao tentar carregar XML de NFSe no componente, ocorre o erro Start tag expected, '<' not found. Consegui reproduzir no ACBrNFSeX_Exemplo, ao carregar o XML em anexo para Imprimir DANFSe. nfse.xml Poderiam me ajudar por gentileza?
  3. Olá Italo! Desculpe a demora na resposta, só agora consegui testar as alterações. Consegui emitir NFSe pelo método GerarNFSe do provedor, usando a última versão do ACBrNFSeX. Muito obrigado pela correção! Porém precisei atualizar a URL de homologação no ACBrNFSeXServicos.ini. Peguei a URL atualizada no manual da prefeitura do Rio de Janeiro/RJ. Nova URL: https://notacariocahom.rio.gov.br/WSNacional/nfse.asmx Poderia atualizar nos fontes por gentileza?
  4. Em nenhuma situação, nem na minha aplicação, e nem no TEFAPIDemo. Isso definitivamente seria um erro. Mais uma evidência de que deve ter sido um bug/estado errado no backend DEMO do Pay&Go, conforme sugerido por ti. Sair do evento, sem resolver a pendência, foi uma forma que encontrei para reproduzir o estado que eu tinha ao abrir o tópico. Não é a forma como funciona minha aplicação e nem o TEFAPIDemo. Outra forma de reproduzir seria: efetuar um pagamento; deixar ele pendente; fechar a aplicação; apagar o diretório de trabalho do componente; iniciar a aplicação; componente não terá mais seus backups, para detectar a pendência, e não chamará QuandoDetectarTransacaoPendente durante a inicialização. Não quis testar assim para não perder o diretório de trabalho. Posso sim, só vou demorar a ter tempo pra fazer isso.
  5. Tentei reproduzir o problema no TEFAPIDemo, mas precisei alterar ele demais para que chegasse no estado de pendência do meu problema. Consegui reproduzir na minha aplicação, de forma consistente. O problema ocorre quando a pendência não é resolvida no evento QuandoDetectarTransacaoPendente, disparado no método Inicializar, e em seguida se chama o método LimparRespostasTEF. Mas o meu estado de erro original, que motivou a abertura esse tópico, não parece ter sido causado pela minha aplicação, e sim por algum estado de pendência errado no ambiente de testes do Pay&Go. Um detalhe que indica estado diferente no backend do Pay&Go é que, enquanto estava no estado de pendência, e tentávamos realizar um pagamento, o Pay&Go não retornava a rede autorizadora DEMO, que sempre usamos. Retornava somente ITI e REDE, como se pode ver nos logs da primeira postagem do tópico. Depois de desfeita a transação pendente, voltou a retornar a autorizadora DEMO, e segue retornando. Enquanto tentava reproduzir o problema no TEFAPIDemo, vi que o parâmetro MsgErro, do evento QuandoDetectarTransacaoPendente, retorna o NSU da transação pendente no backend do Pay&Go. Com isso, mais o tratamento que fizemos para desfazer esse tipo de pendência, e mais a explicação sobre o método LimparRespostasTEF e o ambiente de homologação, podemos encerrar esse tópico. Muito obrigado pela ajuda.
  6. Obrigado pela resposta rápida @Daniel Simoes. Havia testado com a revision 24534 do SVN, e agora atualizei para a revision 24639 e testei novamente. Mesmo resultado. Sendo uma situação que só ocorre em homologação, tratarei esses casos na aplicação, desfazendo as transações pendentes desse tipo. Sobre essa dúvida: Esse estado de pendência pode ter sido causado por chamarmos LimparRespostasTEF() depois de chamar Inicializar()?
  7. Usamos o ACBrTEFAPI sem confirmação automática, em uma nova aplicação nossa, ainda em fase de desenvolvimento. Ao tentar autorizar um pagamento em cartão de crédito, componente solicita seleção da Rede Autorizadora, depois pede cartão e senha. Em seguida o Pay&Go retorna TRANSACAO PENDENTE. Implementamos um tratamento de pendências no evento QuandoDetectarTransacaoPendente. Nossa aplicação espera que, durante a inicialização do componente, esse evento seja disparado, caso exista alguma transação pendente. Nesse caso, o componente inicializa, não detecta pendência (não dispara evento), e então aplicação prossegue com a autorização de pagamento. Depois do retorno de TRANSACAO PENDENTE do Pay&Go, componente dispara o evento QuandoDetectarTransacaoPendente, mas o parâmetro RespostaTEF, passado pelo evento, vem vazio. Em anexo o trecho do nosso event handler (TForm1.ACBrTEFAPI1QuandoDetectarTransacaoPendente.pas), escrevendo os dados de RespostaTEF para um arquivo texto, e o arquivo texto contendo os dados de RespostaTEF (dadostransacao.txt). Pelo que parece, o componente não conseguiu manter seu estado de "transação pendente" sincronizado com o Pay&Go, ou o ambiente de teste do Pay&Go está com algum problema, reportando pendência inexistente. Componente só dispararia o evento QuandoDetectarTransacaoPendente, na sua inicialização, quando tiver esse estado de pendência em seus arquivos temporários, correto? Método LimparRespostasTEF() limpa esse estado? Seguindo ACBrTEFAPI_Demo, estamos chamando LimparRespostasTEF() depois do método Inicializar(). Deveríamos fazer isso? Queria saber se esse estado de "pendência no Pay&Go", que não é detectada na inicialização do ACBrTEFAPI, é um bug no ambiente de testes do Pay&Go, ou se devemos tratar esse caso em produção. Se for para tratar, como devemos fazer? Com RespostaTEF retornando vazio, não temos como decidir se a transação deve ser confirmada ou desfeita. Deveríamos desfazer sempre? Em anexo os logs presentes nos diretórios de trabalho do componente e da PGWebLib.dll. Testei com a revision 24534 do ACBr (de 06/02/2022), e PGWebLib.dll v4.1.15.1 . Aplicação feita no Delphi 10.4. TForm1.ACBrTEFAPI1QuandoDetectarTransacaoPendente.pas dadostransacao.txt ACBRTEFAPI.log comms_220216.log ppsers_220216.log
  8. Ao tentar emitir NFSe na prefeitura do Rio de Janeiro/RJ, usando ACBrNFSeX, encontramos dois erros: Serialização da alíquota de ISS ao enviar lote de RPS Web service espera que a alíquota seja uma fração de 1, mas o componente coloca em percentual, ao serializar o TNFSe para XML. Por causa disso, web service retorna erro E928: O valor da alíquota informada para o Código do Serviço Prestado (120801) deve ser superior(ou igual) a 2,00% e inferior (ou igual) a 5,00%. Corrigi esse erro, editando a unit ISSRio.GravarXml.pas. Em anexo a unit editada, e arquivos XML contendo exemplos de como estava antes da correção, e como ficou após. XML inválido em relação ao XSD do web service da prefeitura, ao gerar NFSe Mesmo com a solução do problema anterior no formato da alíquta, método GerarNFSe retorna o erro E160: The element 'Rps' in namespace 'http://notacarioca.rio.gov.br/WSNacional/XSD/1/nfse_pcrj_v01.xsd' has invalid child element 'InfRps' in namespace 'http://notacarioca.rio.gov.br/WSNacional/XSD/1/nfse_p. Testei com e sem a alteração que fiz para a alíquota. Para tentar resolver o problema, baixei a documentação de integração do site da prefeitura, e comparei o XML de exemplo do GerarNFSeEnvio com o gerado pelo componente (imagem abaixo). Notei que os namespaces estavam diferentes, além do XML do exemplo estar assinado, e o gerado pelo componente não estava assinado. Em anexo os arquivos XML gerados pelo componente, e o de exemplo. Tentei corrigir esse problema, mas não consegui. Poderiam me ajudar com esse erro no GerarNFSe? ISSRio.GravarXml.pas ACBrNFSeX-ISSRio-BugAliquotaIss.zip ACBrNFSeX-ISSRio-BugGerarNFSe.zip
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.