EMBarbosa

No inicializar você vai passar uma variável que vai receber uma referência de ponteiro. Essa referência você vai utilizar em todas as próximas chamadas "dessa Thread". Dá uma olhada nesse código em python criado por usuários ACBr para utilizar a ACBrLibCEP: https://github.com/base4sistemas/acbrlib-python/ Pode ajudar você a entender com funciona.

Pelo log, seu arquivo "C:\acbr2\Pacotes\Delphi\synapse\ACBr_synapse.dpk" está corrompido.

Bom dia. Só pra confirmar: 1) Estou procurando a conversa no Discord, você tem o link da úlima mensagem por favor? Assim posso ler o que já foi testado e te passado como orientação também. 2) O código está chamando NFE_Inicializar e armazenando o número retornado (ponteiro) para ser passados para as próximas chamadas dessa thread? 3) Verificou se os ponteiros não estão sendo trocados? Por exemplo thread 1 cujo ponteiro é "a" está usando o ponteiro "b" que seria da thread 2.

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.

Se mesmo mudando a configuração deles não resolve o problema, então precisaremos criar uma nova classe para tratar o retorno. Não podemos simplesmente modificar a classe atual pois ela segue o padrão do antigo "TEF_DIAL". Essa nova classe deve sobrescrever o comportamento da procedure "ConteudoToProperty" padrão que está na classe TACBrTEFDRespTXT (unit ACBrTEFDClass) ao sobrescrever a classe TACBrTEFDDial ou TACBrTEFDClassTXT. Isso vai criar um novo modelo no TEFD. Criamos uma tarefa no nosso backlog para isso: #TK-4980 Assim que tivermos um retorno avisaremos. Até lá, você pode me indicar onde conseguir a documentação mais atualizada deles?

Entendi... Chegou a verificar isso? Chegou a questionar o pessoal da SCOPE sobre alguma configuração sobre a impressão da via do estabelecimento?

Eu achei isso estranho, porque o log apresenta uma mensagem do Sitef. Veja: -- 08/01 16:37:04:127 - *** ConfiguraIntSiTefInterativoEx. EnderecoIP: 127.0.0.1 CodigoLoja: 00000000 NumeroTerminal: SE000001 Resultado: 0 ParametrosAdicionais: Essa mensagem é típica de quem configurou o componente para usar o CliSiTef... mas pode ser que você tenha inicializado os dois... verifique por favor. Você talvez tenha que fazer o debug e verificar se o evento está enviando pra impressora a via do cliente e do estabelecimento. No log, parece que as duas vias estão sendo comandadas... veja: -- 08/01 16:38:03:769 - TEF_DIAL ECFImprimeVia: trVinculado Via: 1 -- 08/01 16:38:03:778 - TEF_DIAL ComandarECF: Oper: opePulaLinhas -- 08/01 16:38:03:784 - TEF_DIAL DoExibeMsg: Oper: opmDestaqueVia Mensagem: Destaque a 1ª Via -- 08/01 16:38:03:846 - TEF_DIAL ECFImprimeVia: trVinculado Via: 2 Outra coisa que eu lembrei aqui e é necessário verificar: Você verificou se no gerenciador padrão deles ainda existe e está marcada a opção "Usar ACBr"? Veja esse tópico: Por fim, eu me lembro que o TEF da Scope/GetCard não tinha sido totalmente testado por nós. Pode ser que o componente esteja lendo as duas vias de um campo no arquivo de resposta. Mas o Tef da Scope esteja jogando em outro campo, fora do padrão do TEF_DIAL.

Qual o Gerenciador padrão que você configurou?

Que componente você está utilizando para fazer a comunicação com o Gerenciador padrão da SCOPE? Pode anexar o log dessse componente?

O que você mostra na imagem é apenas que o método "gravarValorArquivoIni()" retornou True. Como não dá pra ver o código todo, me parece que não temos garantias de que o arquivo INI que você escreveu foi exatamente o arquivo INI utilizado pela LIB. É um problema comum... Por exemplo, isso pode acontecer ao alterar uma configuração na LIB. Se você simplesmente alterar o arquivo INI manualmente, por fora dos métodos da Lib, a Lib não sabe que uma configuração foi alterada e continua com o mesmo comportamento. Outro exemplo é você preencher um arquivo INI, mas mandar para o método da Lib um arquivo INI em memória. Verifique se realmente a Lib está con a configuração da API correta.

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.

Movi para área correta. Qual a versão do PVA que está utilizando? Poderia compartilhar a mensagem de erro por favor?

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.

Olá Valdir, Se você quiser capturar durante a apresentação dos dados, você pode usar os eventos OnObtemCampo e OnExibeMenu. É justamente nesse código que os usuários vão informar os dados ao TEF.

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.

Olá pessoal! Com ajuda de nossos usuários @Agnaldo Prates e @DevCriare conseguimos atualizar nosso componente ACBrSpedFiscal que é o componente para EFD ICMS IPI para o novo layout de 2024. Os ajustes estão de acordo com o Guia Prático 3.1.6. Valeu pessoal.

Fiz mais um ajuste de compatibilidade que quase passou despercebido. Revisão 31664

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.

Boa tarde. Tentaram entrar em contato com o próprio IBPT. Talvez eles tenham alguma orientação. Visto que é sobre a API deles, parece o certo a fazer.

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.

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.

Oi Siro. Obrigado pelo esforço. Nesse caso, agora parece que você tem um ambiente limpo de duplicidades, que é o problema mais comum desse erro (99,9%)... Sendo assim, talvez o problema então não seja bem um arquivo "duplicado". Para gerar esse erro basta ter duas compilações diferentes (arquivos dcus) da mesma unit. Então, talvez seja um arquivo compilado para fins diferentes (exemplo Debug e release, ou plataformas diferentes). O seu FastReport tem separação de bpls ou dcus para debug e release? Mas mesmo se não tiver, o Delphi talvez esteja se "confundindo". Nesse caso, uma hora ele gera em release para compilar o ACBr. Mas depois, ele está gerando em debug para compilar sua aplicação. Daí geraria esse erro se o ACBr não tiver compilações diferentes ou o Delphi não estiver conseguindo recompilar os pacotes e units do ACBr. Então, outra pergunta, no ACBrInstall, você marcou a opção "Deixar somente a pasta LibXX no Library Path do Delphi"? Se a resposta for sim. Poderia reinstalar o ACBr deixando essa opção desmarcada?