EMBarbosa

Ao fazer uma GNRe existem vários campos a serem preenchidos. Mas além desses também há campos extras que podem ser exigidos ou não pela UF. Como saber o que preencher? Observação: Não estamos falando de quais valores vão nos campos, quer dizer, o que colocar nos campos. Isso é trabalho do contador da empresa ou da própria UF definir. Mas sim de quais campos preencher... Infelizmente, não temos essa informação de maneira definitiva. Se estiver disponível, você poderia usar o método GnreConfigUF para uma receita específica. Mas o próprio manual tem o seguinte detalhe: E online, você pode ter uma ideia seguindo com os seguintes passos (imagens na sequência): Entre no portal GNRe e vá em Automação clique em Manual para Preenchimento do XML de Lote clique em Regras de preenchimento Selecione a UF e a Receita desejada. Verifique os dados exigidos no formulário apresentado.

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.

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

Me parece que você também fez modificações no arquivo OpenSSLExt.pas e não o colocou aqui. Ou talvez você esteja utilizando outra versão... poderia disponibilizar? Eu não encontrei o SslMethodTLSV1_3 citado na linha 480 da unit ACBrDFeOpenSSL.pas.

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.

Para fins históricos: Primeiro commit SVN no Source Forge foi em 2009-03-11: https://sourceforge.net/p/acbr/code/1/ (Caso saia do ar link https://web.archive.org/web/20240214150911/https://sourceforge.net/p/acbr/code/1/) Nele consta a primeira versão lançada (0.01a) de um componente ACBr (ACBrECF e ACBrCalculadora): Caso saia do ar, link no WayBack Machine: https://web.archive.org/web/20150801052647/https://www.devmedia.com.br/forum/classe-para-acesso-direto-a-ecf-em-linux-windows/229474

Juan, Você usa algum compactador ou encryptador no seu software? Por exemplo: ASPack, UPX, Armadillo, ou algo similar? Você faz algum tratamento diferente após gerar o executável pelo Delphi? Você modifica alguma opção do projeto? Se você copiar o arquivo, "RedesPayGo.txt" para a pasta do seu executável, o problema continua acontecendo? OBS.: Esse arqruivo está no SVN do ACBr no seguinte caminho: "ACBr\Fontes\ACBrTEFD"

Olá pessoal, Queremos informar que implementamos mais um gerenciador padrão de troca de arquivos no ACBrTEFD, o gpTefDialScopeGetcard. Você pode utilizar agora esse modelo para implementar o TEF que se comunica com o gerenciador padrão da GetCard ou Scope por troca de arquivos. O modelo é muito semelhante ao PayGo por troca de arquivos, mas tivemos que criar uma nova classe para evitar conflitos com alguns recursos que não existem. A princípio está tudo funcionando, mas como sempre, aproveitem, testem e nos reportem qualquer problema. Bom trabalho por aí!!!

Olá pessoal, informamos que o ACBrNFCom já está no ACBrInstall.

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.

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.

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:

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.

Acabamos de ter a confirmação desse problema pela Receita: https://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=MIrogWJTf2w=

Tentou enviar outra mensagem? Por exemplo uma mensagem vazia?

@CrasH, @Tiago Domingues Carneiro, @Dor_poa, e outros Subi no SVN uma correção. Deve estar tudo ok agora.