EMBarbosa

Eu já verifiquei o seu código, mas como o Daniel postou lá no começo do tópico, suas alterações estão diferentes do código que está no SVN. Na verdade, você mesmo admitiu que não estão no padrão do ACBr: Então seria interessante verificar as alterações que foram feitas acima em conjunto com o @adriano.quintino, para verificar se resolvem seu problema.

Daniel, isso é a parte do código que o Juliomar implementou mas ainda está comentado. É a chamada da função ExecutarTransacaoSiTef('130') que está no final do método TACBrTEFAPIClassCliSiTef.Inicializar. Acho que esse código talvez deveria estar numa função que tenha a função de recuperar as transações pendentes. Mas com ajuda do @adriano.quintino, fizemos alguns testes e com alguns ajustes que vou listar abaixo parece que o código está quase tudo ok. @rodrigoogioni, pode por favor verificar o código implementado pelo Juliomar que está comentado no código atual da unit ACBrTEFAPICliSiTef com os seguintes ajustes abaixo? Temos que fazer algumas alterações nele para funcionar. Por exemplo, tem que descomentar as linhas que tratam os TipoCampo e alterar a classe de resposta pendente de TACBrTEFResp para TACBrTEFRespCliSiTef. Também ainda falta o código para cancelar as transações pendentes. Isso ainda falta fazer, mas é basicamente adicionar no final do método TACBrTEFAPIClassCliSiTef.ContinuarRequisicaoSiTef um loop para percorrer a lista fpACBrTEFAPI.RespostasTEF e cancelar as que precisam ser canceladas.

Sim, a @Juliana Tamizou pediu para eu dar um apoio a esse caso mesmo.

Só como lembrete, compartilhe conosco também as configurações de Certificado/SSL que estiver utilizando ao acontecer a falha.

Muito obrigado pelo retorno. Ótima investigação. Se você tiver alguma sugestão de alteração no código relacionado a isso por favor, compartilhe conosco.

Para entender a diferença dos métodos Síncrono e Assíncrono, veja:

Essa sugestão, vai forçar a chamada de xmlCleanupParser sempre que utilizar um ACBrXMLDocument ou destruir um componente que use o TDFeSinglibXML2... Pelo que entendi da documentação da libxml2, essa correção não deveria ser feita. Principalmente se a aplicação for multithread porque isso poderia levar a erros. Essa função deveria ser chamada só quando estiver realmente descarregando a dll para encerrar a aplicação. Aqui o link: https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html#xmlCleanupParser Abaixo o aviso deles com grifo meu: Seria muito importante para nós termos um executável mínimo que consiga reproduzir o problema.

É preciso ativar a alteração de escala e alterar a escala padrão para outro valor. O difícil é saber o valor da escala para qual deve ser alterado. Geralmente é preciso testar na máquina os valores até encontrar um que realmente funcione.

A mensagem que você recebeu na verdade foi um pouco diferente, veja (retirado do log enviado): Note que não diz "CRT diferente de 1 e 4". O que nos leva a pensar que a Sefaz e o ambiente para qual você está emitindo não deve ainda suportar esse CRT. Também pelo seu log: Quer dizer produção. E realmente, parece que o CRT 4 e suas validações ainda não estão habilitadas na produção. Acredito que esse seja o problema. Veja esse tópico, em especial o último post:

Atualização: Boa parte dos tópicos, se não todos, já estão de volta. Agradecemos ao pessoal da Invision Community. Ainda não tivemos um retorno definitivo, o que quer dizer que, por enquanto, os plugins ainda estão desativados... (sem gifs... ) Atualização da Atualização: Tivemos um retorno da equipe da Invision Community. O problema foi encontrado e resolvido aqui no nosso fórum. Mas uma correção definitiva virá numa nova versão de atualização do Fórum ainda a ser lançada.

Por favor, além de tentar o validador mencionado pelo @Diego Folieneacima, compartilhe conosco as mensagens de erro e rejeição dos dois casos. É importante termos essas mensagens de formas exatas e completas.

Apenas uma atualização 28/08/2024 14:36: A equipe do suporte da Invision Community identificou que o problema pode ser mais complicado do que parece. Ainda estão avaliando o caso com a equipe de suporte avançada. Alguns tópicos podem ter voltado mas o problema ainda não foi resolvido. Com o compromisso de manter a transparência e honestidade, assim que tivermos novidades avisamos a todos. Aproveitamos para agradecer a compreensão da comunidade ACBr. Bom trabalho pra vocês pessoal.

Nova contribuição baseada nessa. Vamos continuar em:

Apenas para confirmar, seu código também é compatível com as alterações feitas pelo @Pedro E. Braga?

Outra empresa é a MixFiscal Vira e mexe esse assunto volta aqui no fórum veja: Veja também: https://www.projetoacbr.com.br/forum/topic/27116-integracao-api-bluesoft-cosmos/

Olá pessoal, Queremos informar a todos nossa ciência de um problema recente no fórum que faz com que alguns tópicos fiquem inacessíveis. Você talvez veja uma mensagem semelhante a essa: Estamos cientes do problema e já solicitamos ajuda do "fabricante" para resolver. Durante esse período, alguns plugins estarão desabilitados. Assim que tivermos novidades, avisamos a todos.

Claro. Se está marcado como deprecated, não é para ser utilizado mais.

Olá pessoal, No nosso objetivo de sempre melhorar o código do ACBr deixá-lo mais organizado e legível, estamos fazendo algumas mudanças e achamos importantes expô-las para todos. Detectamos alguns tipos que não estão sendo mais usados por nenhum componente ou classe no código do ACBr e por isso, achamos melhor remover. Além disso, parte do que estamos fazendo no momento é migrando definições de classes e tipos e também algumas funções da unit "pcnConversao.pas" para units mais especializadas como a "pcnConversaoNFe.pas". No caso dessas funções e classes/tipos, elas não são utilizadas fora de um "componente" específico. Assim, reduzimos o escopo. Também estamos, na medida do possível, criando novas versões de funções que convertem tipos enumerados (StrToXXXX ou XXXXToStr), removendo o parâmetro "ok". Isso já acontece em muitas funções do mesmo tipo em outras áreas do projeto. Muitas vezes esse parâmetro "ok" é ignorado pelos programadores e essa situação pode causar problemas difíceis de serem diagnosticados. Não queremos incentivar esse comportamento... Abaixo uma lista dos tipos migrados e para qual unit ele foi destinado. As funções relacionadas a esses tipos foram migradas também para a unit mencionada: TpcnSituacaoEmissor - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnIndicadorEmissor - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnIndicadorContinuacao - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnSituacaoManifDest - Descontinuado e removido - Não é utilizado em nenhum componente. TpcnFormatoGravacao - Movido para unit pcnGerador TDetFormato - Movido para unit ACBrDFeReport TpcteModeloNF - Movido para unit pcnConversaoCTe TpcnIndicadorPagamento - Movido para unit pcnConversaoNFe TpcnPercentualTributos - Movido para unit pcnConversaoNFe TpcnDeterminacaoBaseIcms = Movido para unit pcnConversaoNFe TpcnDeterminacaoBaseIcmsST = Movido para unit pcnConversaoNFe TpcnMotivoDesoneracaoICMS = Movido para unit pcnConversaoNFe TpcnCstIpi - Movido para unit pcnConversaoNFe TpcnIndicadorProcesso - Movido para unit pcnConversaoNFe TpcnCRT - Movido para unit pcnConversaoNFe TpcnIndicadorTotal - Movido para unit pcnConversaoNFe TpcnECFModRef - Movido para unit pcnConversaoNFe TpcnISSQNcSitTrib - Movido para unit pcnConversaoNFe TpcnImprimeDescAcrescItem - Movido para unit pcnConversaoNFe TpcnDestinoOperacao - Movido para unit pcnConversaoNFe TpcnConsumidorFinal - Movido para unit pcnConversaoNFe TpcnPresencaComprador - Movido para unit pcnConversaoNFe TpcnFormaPagamento - Movido para unit pcnConversaoNFe TpcnBandeiraCartao - Movido para unit pcnConversaoNFe TpcnTipoViaTransp - Movido para unit pcnConversaoNFe TpcnTipoIntermedio- Movido para unit pcnConversaoNFe TpcnindISSRet - Movido para unit pcnConversaoNFe TpcnindISS - Movido para unit pcnConversaoNFe TpcnTipoAutor - Movido para unit pcnConversaoNFe As primeiras alterações foram enviadas ao SVN na revisão 34752. Bom trabalho pessoal.

Para quem quiser saber mais sobre o ACBr Pix Matera, visite: https://projetoacbr.com.br/pix/

Eu não tenho certeza o que seja. Deveríamos ter alguma mensagem de erro ali mesmo no log... Vê a mensagem logo na frente da linha que você destacou? Está em branco... Essa parte é bem estranha e realmente, na minha opinião é o que deve gerar os erros na sequência. Mas simplesmente um erro da SEFAZ é muito pouco provável. Acho que teríamos muitos relatos de problemas nesse caso, porque erros da SEFAZ é algo muito comum. Eu não imaginei que fizesse isso propositalmente. Pensei em algo como um "Garbage Collector", ou algum dispositivo da sua infra, como o OOM Killer do Linux... Por isso perguntei qual o ambiente e backend que você utiliza.

Tem alguma coisa que acontece que faz você pensar isso? Não conseguimos. Pelo menos ainda não... Qual é o ambiente que está sendo executado? Pode descrever melhor seu backend? Será que não tem algo que poderia afetar a limpeza da memória? Pelo log, o Access violation acontece justamente quando acontece essa pausa de 10 minutos. Depois disso ele é repetido várias vezes até que você reinicie a Lib ou aplicação. 16/07/24 07:16:50:378 - NFE_StatusServico 16/07/24 07:16:50:394 - Travar 16/07/24 07:16:50:753 - MoverStringParaPChar. StrLen:206, BufLen:256 16/07/24 07:16:50:753 - SetRetorno(0, [Status] CStat=107 CUF=31 DhRecbto=16/07/2024 07:16:58 DhRetorno=16/07/2024 07:16:58 Msg=Serviço em Operação TMed=1 VerAplic=W-1.5.24 Versao=4.00 XMotivo=Serviço em Operação XObs= tpAmb=1 ) 16/07/24 07:16:50:769 - Destravar 16/07/24 07:26:41:306 - NFE_StatusServico 16/07/24 07:26:41:306 - Travar 16/07/24 07:26:41:322 - Destravar 16/07/24 07:26:41:338 - LIB_UltimoRetorno 16/07/24 07:26:41:338 - MoverStringParaPChar. StrLen:0, BufLen:256 16/07/24 07:26:41:353 - Codigo:-10, Mensagem: 16/07/24 07:35:40:521 - NFE_LimparLista 16/07/24 07:35:40:521 - Travar 16/07/24 07:35:40:537 - SetRetorno(0, 0 NFe(s) Carregada(s)) 16/07/24 07:35:40:553 - Destravar 16/07/24 07:35:40:568 - NFE_CarregarINI(xxxxxxxxxxxxxxxxxxxx ) 16/07/24 07:35:40:568 - Travar 16/07/24 07:35:40:584 - SetRetorno(0, 1 NFe(s) Carregada(s)) 16/07/24 07:35:40:600 - Destravar 16/07/24 07:35:40:615 - NFe_Enviar(1, Sincrono ) 16/07/24 07:35:40:615 - Travar 16/07/24 07:35:40:631 - NFe_Enviar, Limpando Resp 16/07/24 07:35:40:631 - Destravar 16/07/24 07:35:40:646 - SetRetorno(-10, Access violation) 16/07/24 07:35:40:646 - LIB_UltimoRetorno 16/07/24 07:35:40:662 - MoverStringParaPChar. StrLen:16, BufLen:256 16/07/24 07:35:40:678 - Codigo:-10, Mensagem:Access violation 16/07/24 07:35:51:794 - NFE_LimparLista 16/07/24 07:35:51:794 - Travar 16/07/24 07:35:51:808 - SetRetorno(0, 0 NFe(s) Carregada(s)) 16/07/24 07:35:51:820 - Destravar

Surgiram ainda algumas dúvidas sobre como essa nova portaria afeta a legislação anterior e como fica o cenário SAT/NFC-e em SP principalmente para quem quer utilizar NFC-e. Bem, parece que o seguinte aviso do próprio portal da fazenda de SP esclarece: Fonte: https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/Sobre.aspx

Olá pessoal, Queremos informar brevemente que foi criado um novo método chamado LerStatusImpressoraFormatado. Uma versão para a ACBrLibPosPrinter e também uma versão para o ACBrMonitorPlus no objeto ESCPOS. Esse método pode ser útil para quem prefere uma leitura de forma diferente dos dados e as anteriores (principalmente da Lib) não era satisfatória. A documentação explica melhor o retorno. Como sempre nos deem seu feedback aqui no Fórum ou Discord. Até a próxima!

Veja também: https://portal.fazenda.sp.gov.br/Noticias/Paginas/Sefaz-SP-permite-a-emissão-de-Notas-Fiscais-Eletrônicas-em-contingência-offline.aspx

Isso indica mais uma vez que a sefaz está com problemas no site dela, principalmente no novo. Como dito antes, é necessário entrar em contato com eles para entender o motivo do problema. Talvez fazendo isso eles corrijam.