EMBarbosa

Isso é para Pix certo?
Chegou a ver esse post?
 
Me parece que pelo menos algumas dessas funcionalidades da OpenSSL estão expostas na unit ACBrOpenSSLUtils.pas. Mas não temos nenhuma documentação sobre o uso dela.
Por favor, compare o que você precisa com o que está documentado para os PSP Itaú e Sicoob no tópico sobre PIX:
 

Por favor, verifique com a versão que saiu hoje.

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:
 

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/
 

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.

Então acredito que esse é o problema. O Delphi 7 não está conseguindo encontrar as bibliotecas de dependência.
Essa variável tem o propósito de fazer justamente isso de forma dinâmica. O problema de fazer a substituição é que você acaba perdendo a substituição automática.
Talvez isso seja uma incompatibilidade com o Delphi 7 do Windows 11. Daí seria necessário realmente fazer a substituição.
A variável em si não é necessária. Usar o path no lugar só tem consequências relacionadas a isso substituição dinâmica da variável $(Path) pelo "Path" do SO.

Tente verificar os outros registros mudando as páginas para ver se todas estão marcadas como Aguardando processamento...

Talvez você encontre uma mensagem de erro mais específica.
Fora isso... a mensagem pede para ser enviado novamente. Então nesse caso, tente enviar novamente depois de analisar as mensagens como dito acima.
Se depois disso você enviar novamente e as mensagens não mudarem,  você vai precisar de entrar em contato com o Fisco por meio do Fale Conosco ou serviço similar.

Bom dia,
Geralmente isso é um problema do lado do servidor. É basicamente o mesmo que o Erro http 500, como você pode ver no log.
Veja também esse link: https://bacen.github.io/pix-api/
Acho que a única coisa que pode ser feita é tentar o contato com eles.

Você chegou a aumentar o TimeOut?
Tente um valor como 40000 para testar.
Veja mais informações em:
 

A contribuição no tópico citado post acima foi enviada ao SVN, conforme mensagem citada abaixo:
Assim, estamos fechando essa TK-5132 até segunda ordem.
Se for necessário uma nova análise, fiquem a vontade a postarem novas mensagens.
Nota: ainda estamos aceitando contribuições para o aplicativo de exemplo. Vejam o tópico citado.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  33041.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.
Verificado. É importante lembrar que os pacotes Design Time precisam ser recompilados e reinstalados após alteração nos pacotes Run Time.

Apenas para ficar registrado, o problema foi resolvido utilizando o FastMM 4, trocando o gerenciador de memória nativo do Delphi 7.

Muito obrigado pela contribuição.
Mas achamos melhor corrigir a função. Pelo visto, ela não era usada no código do ACBr em outros lugares e estava incorreta já faz um tempo.
@ddsilva,
Subi as alterações para o SVN na Revisão  32926.
Pelo que vi está tudo certo.
Pedimos a todos o favor de atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado a todos pelo relato e sugestões de correção.

O fim do CFOP de substituição tributária, programado para 1º de abril de 2024 foi revogado pelo Ajuste SINIEF nº 29 de 2023.
Já a unificação do CST e CSOSN, prevista para entrar em operação dia 1º de abril de 2024, também foi revogada pelo Ajuste SINIEF nº 34/2023.
Fonte: documentação (nos links acima) e site SigaoFisco

Olá Renan, tudo blz?
   Isso não tem nada a ver com o problema, mas veja a seguinte informação: https://acbr.sourceforge.io/ACBrLib/CdeclouStdCallqualusar.html
   Você deve escolher o que for compatível com seu sistema e "ambiente destino" (aonde o sistema for executado).
 Essa parte do código não me parece fazer nenhuma referência ao INI. Se fizer, me desculpe, pois node.js não é minha especialidade. Mas me aponte exatamente qual linha faz isso.
 
A princípio, me parece que você está utilizando um mesmo arquivo escrito anteriormente. O arquivo .INI deve ter sido salvo no HD e, é claro, reiniciar a máquina por si só não vai apagar o conteúdo dele.
Verifique no seu código onde você passa o arquivo .INI qual o caminho. Daí veja se o arquivo já não está salvo no HD.
 

Olá,
   Essa parece ser uma dúvida mais contábil e operacional dos sistemas do fisco e como tal, recomendamos fortemente que consulte um contador de confiança que atue nessa área.
   Ainda assim, não sei se entendi direito sua dúvida. Se entendi direito, basta emitir as guias no DCTFWeb normalmente.
   Me parece que é o caso do exemplo no Guia Rápido do DCTFWeb disponibilizado nesse link aqui.
   Se for esse o caso, mesmo que as guias apareçam separadamente não haveria problema já que os lançamentos estão corretos.
   Por outro lado, se os lançamentos ficaram incorretos, talvez precise fazer alguma retificação. Daí é necessário verificar o manual do DCTFWeb e o documento perguntas frequentes para verificar as orientações.

Vocês estão equivocados. A última versão é a versão 5.1.0. Segue o print do link que enviamos pra vocês.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi essas alterações para o SVN na Revisão  31699.
Essas alterações não enviei ao SVN. Porque esses campos nos registros M100 e M500 podem ser nulos e podem ser zero.
Então precisamos das funções VDFILL ou VLFILL para tratar o caso dos campos nulos mas não são zero.
Você pode até reparar que o tratamento da função VDFILL e DFILL para máscara de decimais é o mesmo e só muda o tratamento para campo "nulo".
Além disso, eu fiz um teste aqui usando o exemplo do ACBrSpedPisCofins e o código funcionou normalmente. Veja na imagem:

 

Desculpe se eu não entendi bem... Fica a vontade pra me mostrar sempre o que eu não tiver entendido. 👍
Ahh certo, você tem razão nos nomes do evento do componente. Na verdade, usei os nomes que são correspondentes a esses na classe interna porque são estes que estão no log.
Veja esse trecho por exemplo na linha 1244 do log21122023.txt que você compartilhou:
21/12/23 09:22:02:667 - OnObtemCampo 21/12/23 09:22:10:687 - Resposta: 150124, Valido: False, Cancelado: False 21/12/23 09:22:10:687 - PW_iAddParam( PWINFO_48900, 150124 )  
Hmm.... talvez tenha sido mais isso que não entendi direito...
Você não disse que o usuário digitou isso? Ele digita os valores em um form que você cria e mostra ao chamar nos eventos que mencionamos.
Então você poderia capturar eles ali, naquele evento ou no form. Como no log acima...
Não?
 
Ahh quando for assim, é bom você mencionar logo no início do tópico. Assim a gente já direciona pra quem pediu, ou mesmo quando for outra pessoa que vá continuar, ela pode ir no Discord e pegar o contexto da conversa.
Por exemplo, é o que eu vou fazer agora, ir lá ler todas as suas mensagens.

Bom dia.
Tudo sempre deve estar no mesmo ambiente. Os ambientes diferentes não se "comunicam".
Então, se você está fazendo alguma coisa em homologação, via de regra, tudo deve ser feito no ambiente de homologação.
Por exemplo, se vai acionar um evento relacionado a uma NFe já emitida, esse evento deve estar no mesmo ambiente que a NF-e. Senão você vai receber um erro dizendo que a NF-e não existe.

Muito obrigado pelas contribuições.
Não enviei ao SVN a remoção do campo MUN do registro 1400. Esse campo continua no layout.
A diferença pelo que parece, é que agora pode se informar o registro sem esse campo, de acordo com o que a UF decidir.
Assim, adicionei uma validação para adicionar o campo apenas se estiver preenchido.
---
@DevCriare
Muito obrigado pelas contribuições que enviou no Discord. Juntei com as alterações acima para fazer o merge.
Algumas alterações propostas eu não enviei ao SVN.
Por exemplo: Não me parece correta a alteração para não gerar os registros C855 C895 no layout "vlVersao116".
Note que a possível obrigatoriedade em 2024, não implica em impossibilidade de informar em 2023.
Isso também acontece com o registro 0221, cujo manual diz o seguinte: (grifo meu indicando a possibilidade de informar o registro em 203)
Se vocês não concordarem por algum motivo, por favor, esclareçam seu raciocínio.
---
Além de outras alterações que eu fiz no código, também fiz o seguinte que pode ser útil pra vocês analisarem:
- Alteração nas funções StrToTpResido, TpResidoToStr, CodVerToStr e StrToCodVer para um modelo de conversão de enumerado que é recomendado no código ACBr atualmente.
- Remoção de with em funções que mexi;
----
Mais uma vez obrigado a todos pelas contribuições.
Fiz a implementação baseadas nelas.
Subi as alterações para o SVN na Revisão  31662.
Pelo que vi está tudo certo.
Queiram por favor atualizar, testar e reportar qualquer problema.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  31581.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.
 

Muito possível ser um erro no servidor, tentando processar o seu pedido duas vezes.
Me parece que você vai precisar entrar em contato com o provedor da prefeitura e reportar o caso. Talvez eles tenham mais informações.

Fora erros no servidor do Fisco, geralmente isso acontece por haver diferença apenas do cNF.
Verifique se não tem alguma nota já enviada mas com um cNF diferente.

Olá...
vou responder suas mensagens em ordem cronológica. Mesmo que não sejam as dúvidas atuais, podem ajudar outras pessoas no futuro ou te dar alguma ideia...
 
Se estiver usando um conversor USB/serial, ou emulador USB/serial, geralmente esse problema é levantado por um driver defeituoso.
Você pode ver isso no seguinte tópico:
Também já vi ocorrer quando há problema no cabo ou conectores.
Esses são os problemas mais comuns.
---
Esse erro, como você pode imaginar, é porque algum programa já está acessando a porta (possivelmente o Hercules). Só um aplicativo pode ter acesso a uma porta serial por vez.
Quando o segundo aplicativo "pede" o acesso à porta, o sistema operacional (nesse caso o Windows) retorna esse erro informando que o acesso foi negado.
----
Mais uma vez, geralmente isso indica problema no driver, dispositivo conversor USB/Serial como na resposta do Rubinho aqui:
---
Isso é o esperado... "Monitorar a Balança" é um sistema de fazer a leitura automaticamente. É útil em alguns casos onde a aplicação quer fazer vários pesos seguidos, mas prefere delegar ao componente essas leituras.
Se "Monitorar a Balança" não estiver habilitado o ACBrBal só faz a leitura de peso via o comando "LerPeso". Esse comando envia uma solicitação de peso para a Balança(caso necessário), lê e depois interpreta o retorno.
-----
Esses comandos são de "limpeza" da comunicação com a porta serial.
Documentação:
-> IOCTL_SERIAL_PURGE
-> IOCTL_SERIAL_CLR_RTS
-> IOCTL_SERIAL_CLR_DTR
Apesar de ser um pouco baixo nível, não deveriam causar nenhum problema na comunicação.
Na verdade, para comunicação serial usamos a Synapse. A Synapse, (e por conseguinte nosso código), nem vai a tão baixo nível assim já que faz chamadas a API do Windows.
Então, se esse tipo de mensagem gerasse algum problema, nós teríamos vários relatos sobre isso com todo tipo de balança que suportamos e não somente com a Urano POP S.
Tente utilizar outros dispositivos conversão USB/Serial.
Eles costumam ser muito baratos e talvez o problema seja justamente esse.
Infelizmente, a maioria desses dispositivos no mercado não são tão confiáveis.
 
Se houvesse detectado outras comunicações ou envio de bytes diferentes. Talvez poderíamos atribuir ao ACBr o problema. Mas não parece ser o caso.