DatawebDev

Muito obrigado por validar nossa alternativa de "tapa buraco", Renato! Já havia procurado por canal de suporte no portal da NFe nacional, mas não encontrei nada lá. Por fim mandei mensagem para a SEFAZ da nossa jurisdição, conforme orientado por esta página: https://www.serpro.gov.br/menu/suporte/central-de-atendimento-serpro-nfe-cte

As NFe estão com cSITNFE=1. Consultamos elas no portal, e com o certificado digital do cliente, se consegue ver o evento de manifestação, e não existe evento de cancelamento.

Boa tarde Daniel! Obrigado pela resposta. Somente em duas das diversas empresas deste cliente, e somente em 12 de milhares de NFe recebidas completas pelo DistDFe. As de uma das empresas estão manifestadas desde o início de abril, e as da outra empresa estão manifestadas desde o início de junho. O fluxo está correto, sem erro algum, os NSU foram recebidos corretamente e sequencialmente, não tem furo na sequência. Este processo funciona para todos os clientes. Mesmo nesse cliente, onde ocorreu o problema, segue funcionando. Já manifestaram e receberam XML de centenas de notas, em cada uma dessas empresas onde algumas notas manifestadas não retornaram com XML completo. O fato é que não retornou os XML completo depois da manifestação, mesmo seguindo consumindo os NSU sequencialmente, mais de mês após a manifestação. Portanto repito meus questionamentos:

Prezados, boa noite. Temos uma tarefa que é executada periodicamente, executa TACBrNFe.DistribuicaoDFePorUltNSU(), e guarda cada NSU retornado e seu documento no banco de dados da aplicação. Conforme os usuários manifestam os resumos de NFe emitidas por seus fornecedores, a tarefa vai baixando a NFe completa nos NSU retornados após as manifestações. Funciona em diversos clientes. Em um cliente específico, temos 12 NFe que vieram como resumo pelo DistDFe, foram manifestadas, mas nunca mais retornaram pelo DistDFe. Consultamos as NFe no portal da NFe, e confirmamos que estão manifestadas corretamente. Verificamos a sequência de NSU e não houve quebra de sequência no banco de dados do cliente, então não foi um caso do DistDFe ter retornado e o NSU não ter sido armazenado. Vocês já tiveram alguma experiência assim? Como resolveram? DistDFe é um serviço do ambiente nacional, correto? Sabem como fazer para obter suporte deles? Para contornar o problema, eu pensei em executar TACBrNFe.DistribuicaoDFePorChaveNFe() quando já fizer muito tempo desde a manifestação da NFe, e ainda não tiver retornado o XML da NFe completa. O que acham desta abordagem?

Muito obrigado pela resposta @Daniel InfoCotidiano! Ela já sanou a minha primeira dúvida das duas que listei. O tópico indicado foi bastante informativo. Passamos ao nosso cliente a orientação de alteração na configuração para retorno completo, mas o cliente disse que não tem essa opção para ele, e o suporte da IPM disse ao cliente que para eles não tinha como configurar. Faremos uma solução paliativa, combinando os dados do retorno reduzido com o RPS enviado. Depois de sanada a urgência do cliente, faremos contato com o suporte do IPM para tentar habilitar essa configuração. Sobre a segunda dúvida, vocês lembram de algum outro provedor que use RPS, e não retorne a NFSe completa, nem o RPS que a gerou? Seria importante eu ter isso em mente, e analisar a implementação desses provedores no ACBr, para elaborar uma solução paliativa que eu possa compatibilizar com alguma solução mais definitiva posteriormente - no caso do IPM, será com o retorno completo. Grato desde já pela atenção de todos.

Prezados, boa noite. Temos um cliente em Santa Rosa/RS, e estamos com um problema no processamento do retorno da NFSe autorizada. Esse município está configurado para usar o provedor IPM v1.00 no ACBrNFSeXServicos.ini. O XML retornado pela prefeitura não segue o mesmo layout esperado pelo método TNFSeR_IPM.LerXmlNfse, e por causa disso, não conseguimos carregá-lo posteriormente para impressão do DANFSE. Em anexo um exemplo de arquivos XML de envio e resposta de uma autorização de NFSe (dados das empresas foram substituídos por falsos). Observe que o XML de retorno não contém os dados do RPS, então não se pode imprimir a NFSe baseado somente nele. Nosso ERP tem uma rotina de impressão de DANFSE própria, sem usar os reports do ACBr, e que usa somente o "XML da NFSe" retornado pelo provedor, para imprimir o documento auxiliar. O XML é carregado no ACBrNFSeX - que usa o método LerXml do provedor - e então o relatório usa o objeto que foi desseralizado em ACBrNFSeX.NotasFiscais[0].NFSe, gerando a impressão através da leitura das properties de TNfse. Funciona nos padrões ABRASF e nos provedores com layouts próprios que já precisamos implantar em clientes. Tenho duas dúvidas para o pessoal que mantém o ACBrNFSeX: O método TNFSeR_IPM.LerXmlNfse foi baseado em uma outra versão do provedor? Ou é o IPM que está retornando de forma inesperada na cidade de Santa Rosa/RS? Essa abordagem que usamos, onde a impressão se baseia na desserialização do XML retornado pela prefeitura - e consequentemente, que o XML contenha todos os dados da NFSe - pode ser problemática em outros provedores com layout próprio, além do IPM? Vocês tem alguma sugestão, além de precisar armazenar todos os dados do DANFSE de forma normalizada no banco de dados? Grato desde já pela ajuda! 190652-lista-nfse-ger.xml 190652-ger-nfse.xml

Prezados, na alteração que propus, as units não foram adicionadas nos pacotes DCL*.pas (design time), e sim nos pacotes que estes dependem (requires). Esse design pattern é usado em outros pacotes do projeto, e foi por isso que segui. Exceto pela unit ACBr*Reg, as demais units ficam no contains do pacote ACBr_*.dpk, e a única unit no contains do pacote DCLACBr_*.dpk é a ACBr*Reg. O pacote ACBr_*.dpk fica no requires do pacote DCLACBr_*.dpk, e assim o pacote de design time tem acesso as demais units que estão no contains do pacote que não é de design time.

Uses e contains são coisas diferentes. A unit ACBrTEFAndroid não pode estar no contains de dois packages, mas pode estar no uses de diversas outras units. O package DCLACBr_TEFD depende (requires) do package ACBr_TEFD, e a unit ACBrTEFDReg contida (contains) no DCLACBr_TEFD usa (uses) uma unit contida (contains) no package ACBr_TEFD. Podem ser pacotes que já estão em desuso, mas estão quebrando nosso processo de build aqui. Estamos migrando para o Delphi Rio, e a compilação do ACBr tranca por causa desses dois pacotes. Com as correções do primeiro comentário, o ACBr compila no nosso ambiente.

Obrigado pela resposta Juliomar. Entendo que os componentes já estejam descontinuados ou defasados, mas se seus códigos fonte ainda fazem parte do repositório, deveríamos deixá-los compilando, certo? Abaixo a linha de comando que utilizei para reproduzir o problema com o pacote ACBr_NFSe, e em anexo o resultado com o erro. Acontece o mesmo com o outro pacote. Depois que adicionei as units que faltavam, nos arquivos DPK adicionados na abertura do tópico, os erros foram resolvidos. C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\dcc32.exe ACBr_NFSe.dpk -$D- -$L- -$Y- -B -Z -DRELEASE -LEC:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl -LNC:\Users\Public\Documents\Embarcadero\Studio\20.0\Dcp -N0C:\Projetos\Components\ACBr\library\Win32 -IC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -UC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -RC:\Projetos\Components\ACBr\Fontes\ACBrComum;C:\Projetos\Components\ACBr\Fontes\ACBrDiversos;C:\Projetos\Components\ACBr\Fontes\ACBrOpenSSL;C:\Projetos\Components\ACBr\Fontes\ACBrSerial;C:\Projetos\Components\ACBr\Fontes\ACBrTCP;C:\Projetos\Components\ACBr\Fontes\Terceiros\CodeGear;C:\Projetos\Components\ACBr\Fontes\Terceiros\GZIPUtils;C:\Projetos\Components\ACBr\Fontes\Terceiros\json4delphi\src;C:\Projetos\Components\ACBr\Fontes\Terceiros\JsonDataObjects\Source -NSSystem;System.Win;WinAPI;Vcl;Vcl.Imaging;Vcl.Samples;Vcl.Shell;Data;Data.Win;DataSnap;Xml;Soap;VCLTee;FIBX;Bde;Web dcc32_output_acbr.txt

Faltou incluir algumas units em ACBr_NFSe.dpk e ACBr_TEFD.dpk. Compilador de linha de comando do Delphi Rio reclamou que não as encontrava. Em anexo os arquivos DPK corrigidos. Favor incorporar as alterações no SVN para podermos concluir a atualização do ACBr aqui no ambiente de dev. ACBr_NFSe.dpk ACBr_TEFD.dpk

Desculpa não ter deixado claro, mas eu ocultei propositalmente. O XML da NFSe foi retornado corretamente na propriedade do JSON. Retorna vazio, como descrito aqui: Estamos com outro problema agora, onde a NFSe retorna ISSQN em homologação, e não retorna em produção, mesmo com os DPS sendo preenchidos com os mesmos valores nos dois ambientes. Não quero misturar esse problema aqui no tópico do retorno vazio, e preferiria tentar o suporte do Ambiente Nacional antes de abrir outro tópico para tratar disso - nem vejo como algo relacionado ao ACBrNFSeX. Alguém poderia me passar os canais de suporte ao desenvolvedor do Ambiente Nacional? Busquei no site oficial, mas não encontrei. Quero ver com eles o problema deste tópico aqui, e o outro problema de retornar ISSQN somente em homologação.

As rotinas de emissão são idênticas, só mudou a série e número de DPS (homologação) usados nos sistemas. No ambiente que conseguia emitir, era usada a série 6, e numeração começando de zero. No ambiente que não conseguia emitir (resposta sem erro nem XML), era usada a série 1, e a numeração continuava com a sequência usada em produção pelo cliente. Aparentemente, o DPS de número 1702 deste cliente está com algum problema no serviço do ambiente nacional em homologação. Incrementamos para o próximo número de DPS (1703) e conseguimos retomar as emissões. Abaixo a resposta da emissão do DPS 1703, contendo os mesmos valores dos campos do DPS 1702: { "tipoAmbiente": 2, "versaoAplicativo": "SefinNac_Pre_1.0.0", "dataHoraProcessamento": "2023-12-18T19:55:47.1381257-03:00", "idDps": "NFS43149022211111111111111000000000000623120123893478", "chaveAcesso": "43149022211111111111111000000000000623120123893478", "nfseXmlGZipB64": "[...]", "alertas": null } Assim como fiz anteriormente, editei o idDPS e a chave de acesso da mensagem para ocultar o CNPJ do emissor. Como fazemos para investigar o problema desse DPS com o suporte do Ambiente Nacional de NFSe?

Desculpem pela demora na resposta. @Daniel InfoCotidiano e @Diego Foliene muito obrigado pelas respostas! Fiz a consulta por DPS, e retornou o erro abaixo: Erro na NFSe: Código: X999 Descrição: Erro de Conexão: Erro Interno: 0 Erro HTTP: 500 URL: https://sefin.producaorestrita.nfse.gov.br/SefinNacional/dps/431490221111111111111100001000000000001702 WebService retornou um XML vazio. Assim como fiz anteriormente, editei o idDPS da mensagem para ocultar o CNPJ do emissor. Enquanto investigava esse problema, consegui emitir NFSe com o mesmo emissor, mas usando nosso sistema de testes de integração. Agora estou comparando ambos os sistemas para identificar a diferença (usam a mesma versão do ACBr), e descobrir em qual situação que o DPS é enviado pelo ACBrNFSeX, e retorna sem erros e sem NFSe. Atualizo aqui quando descobrir.

Prezados, boa noite. Estamos testando emissão de NFSe em homologação, no ambiente nacional, para Porto Alegre/RS. Trecho do ACBrNFSeXServicos.ini: [4314902] Nome=Porto Alegre UF=RS Provedor=PadraoNacional Nas primeiras tentativas, a API retornou alguns erros de preenchimento do DPS, que corrigimos. Agora está retornando sem erros, mas também sem NFSe, como se pode ver no arquivo 305354-lista-nfse-ger.json em anexo, ou no seu conteúdo abaixo: { "tipoAmbiente": 2, "versaoAplicativo": "SefinNac_Pre_1.0.0", "dataHoraProcessamento": "2023-12-14T19:28:56.39864-03:00", "idDPS": "DPS431490221111111111111100001000000000001702", "erros": [] } Anexo também o XML do DPS. Em ambos os anexos, editei informações sensíveis do emitente/prestador e do tomador. Já viram esse problema no ambiente nacional? Poderiam nos ajudar? 305354-lista-nfse-ger.json 17021-rps.xml

Funcionou! Muito obrigado Italo! Desculpe a demora na resposta aqui, mas encontrei um problema no tratamento de retorno de "lote em processamento" desse provedor, testando envio assíncrono de lote de RPS. Não consegui entender o problema exatamente, mas parece que a resposta da consulta de situação está retornando sucesso, mesmo quando retorna com erros - situação que deveria ser tratada como insucesso, pelo código do provedor. Analisarei detalhadamente esse caso da resposta, e se o problema for no provedor, eu tento corrigir e abro um novo tópico específico.

Boa noite Italo. Bem lembrado! Me recordo desse tratamento em alguns provedores. Testei a tua solução e funcionou, segue em anexo. Muito obrigado pela solução! Dessa forma já atende a nossa necessidade, então se puderem incorporar no SVN, agradecemos. Betha.GravarXml.pas

Prezados, boa noite. O serializador XML do ACBrNFSeX, para o provedor Betha, não gera as tags Aliquota, BaseCalculo e ValorIss, quando o valor destas é zero. Por causa disso, os RPS nessa situação são rejeitados com a mensagem de retorno abaixo: <MensagemRetorno> <Codigo>E163</Codigo> <Mensagem>Alíquota não informada para retenção do ISSQN no Simples Nacional.</Mensagem> <Correcao>Informe um percentual de acordo com o enquadramento na tabela de alíquota do simples nacional.</Correcao> </MensagemRetorno> Para não impactar todos os municípios que usam Betha, criei params para configurar a geração das tags somente no município que precisar. Alterei TNFSeW_Betha.Configuracao, para tratar três valores para o param GerarTag: Aliquota, BaseCalculo e ValorIss. Depois incluí esse GerarTag no Params do ACBrNFSeXServicos.ini do município: Params=GerarTag:Aliquota,BaseCalculo,ValorIss Em anexo os dois arquivos alterados. Poderiam incorporar as alterações no SVN, por gentileza? Betha.GravarXml.pas ACBrNFSeXServicos.ini

Bom dia Daniel! Tua dica resolveu o problema, muito obrigado! Testei com o ACBrNFe_Exemplo, que assim como a minha aplicação, usa o valor padrão de 1000ms na propriedade TACBrNFe.Configuracoes.WebServices.IntervaloTentativas. Aumentei para os 5s recomendados na postagem do Diego, e em conjunto com as outras propriedades da postagem, não aconteceu mais o "erro" de Lote em processamento. Bom dia Diego! Muito obrigado pelas orientações e pela postagem do dia 17 de fevereiro, muito esclarecedora!

Prezados, boa noite. Usando o ACBrNFe_Exemplo, eu tentei autorizar uma NFe em homologação na SEFAZ GO, com envio assíncrono, pelo botão Criar e Enviar. Retornou o erro Lote em processamento (cStat 105). Depois de alguns minutos eu consultei o lote novamente, pelo botão Consultar Recibo Lote, e retornou o lote processado (cStat 104) - e rejeitado, mas não deve ser relevante para esse problema. Em anexo os arquivos XML de comunicação, da criação e envio, e também da consulta posterior. Tenho o mesmo problema na nossa aplicação que usa o ACBrNFe, no ambiente de homologação de Goiás. Já passaram por esse problema?

Obrigado pela resposta Renato. Sim, SSLType continua com LT_TLSv1_2, como na primeira imagem. Testei agora com timeout de 30k e deu o mesmo erro de falha no handshake. Em nenhuma máquina daqui eu consigo comunicar com a SEFAZ-GO usando o certificado digital desse cliente com a OpenSSL (independente da versão). Na máquina de dev (Win8.1) eu não consigo comunicar com a SEFAZ-GO nem usando WinCrypt (crypt32.dll v6.3.9600.16431). Mas em máquina com Win10 eu consigo comunicar usando a WinCrypt (crypt32.dll v10.0.19041.2486) e com esse certificado digital do cliente. Aguardarei a permissão do cliente para que possa enviar o certificado digital ao Daniel, para investigarmos esse problema do cert. com OpenSSL.

Testei com a versão 1.1.1.20 do OpenSSL, mas o resultado foi o mesmo. Muito obrigado pela ajuda Daniel! Pedirei permissão para o nosso cliente, dono do certificado, e ele permitindo, já te envio por mensagem privada.

Daniel, o problema persiste no teu ACBrNFe_Exemplo. As DLL do OpenSSL que acompanham ele são da mesma versão (1.1.1.10) que eu estava usando.

Muito obrigado Daniel! Testarei agora mesmo, e reporto resultado em seguida.

Oi Daniel. A versão do OpenSSL é a 1.1.1j distribuída pelo ACBr. Está na minha primeira imagem, e última resposta nesse tópico. De onde posso pegar essa 1.1.1o que tu estás usando? Foi compilada por ti mesmo?

Obrigado pela resposta Juliomar. A versão do OpenSSL é a mais recente das 1.1.1 disponível no repo do ACBr: 1.1.1j, conforme aparece nas imagens da postagem original. Testei também com a 1.0.2.21 e o erro foi o mesmo.