EMBarbosa

Vamos continuar em:
 

Já está no Trunk2. Mas o componente foi renomeado de ACBrCNAB para ACBrPagFor.

Boa tarde.
A alteração do XML provavelmente é devido a alguma inconsistência.
Poderia por favor verificar se os valores dos campos informados estão de acordo com as orientações desse tópico abaixo?
 

Olá @Light System Software,
Por favor, sempre crie um tópico novo para uma dúvida nova conforme as regras. Veja neste link aqui, em especial a "2.2 - Permaneça no assunto".  
Dessa vez, eu dividi o tópico para você. Sobre sua dúvida:
Veja os campos (nessa ordem):
NFSe.IBSCBS.finNFSe NFSe.IBSCBS.indFinal NFSe.IBSCBS.IndOpeOne

Boa tarde.
Não... A solução ACBr (seja Lib, Monitor ou componente) verifica as configurações do município e do provedor.
Com base nessas configurações ela gera o XML que por sua vez deve atender aos schemas.
Isso depende do modelo que eles vão utilizar. Se é um modelo próprio então depende de ajustes. A vantagem é que no momento que ajustamos para um município, geralmente fica tudo certo para todos os outros municípios que utilizam o mesmo provedor e modelo. Como o @Diego Foliene mencionou antes, os ajustes já estão sendo feitos para vários provedores. Na verdade pelo tópico que você linkou no início, os ajustes parecem já terem sido feitos.
Vocês não precisariam adicionar porque, no tópico que você citou já tem os schemas. Assim, os schemas vão ser disponibilizados juntamente com a Lib. Então quando eles estiverem disponíveis na Lib vocês podem usá-los.
Dito tudo isso, uma coisa vocês precisam ajustar. A emissão do lado de vocês precisará seguir o novo modelo. 
Nesse sentido, veja se esse tópico ajuda:
https://www.projetoacbr.com.br/forum/topic/88289-em-01012026-a-sua-aplicação-de-emissão-de-nfs-e-pode-parar/
 

Você precisa verificar o manual e passar a configuração de fonte para o componente. No programa exemplo ilustra como fazer isso.
O segundo parâmetro da função `ImprimirTexto` é a fonte. Veja a imagem abaixo:

Subi suas alterações para o SVN na Revisão  42926.
Pelo que vi está tudo certo.
Favor testar e reportar qualquer problema.
Obrigado. 

Subi suas alterações para o SVN na Revisão  42927.
Pelo que vi está tudo certo.
Favor testar e reportar qualquer problema.
Obrigado. 

Muito obrigado pelo relato.
Enviamos uma correção para o problema ao SVN.

Tópico fechado por falta de retorno do usuário

Tópico fechado por falta de retorno do usuário

Me parece que já foi respondido no Discord e esse tópico acabou ficando perdido.
De qualquer forma...
Na verdade, esse parâmetro serve quando você já tem a resposta da consulta DFe. Então não basta você ter o XML da consulta, precisaria ter o XML de retorno da Consulta.
Na maior parte das vezes, a Lib não trabalha apenas com transmissão de requisições. Acho que esse tipo de uso não foi previsto...
Podemos pensar em implementar no futuro.

Subi suas alterações para o SVN na Revisão  40488.
Pelo que vi está tudo certo.
Favor testar e reportar qualquer problema.
Obrigado. 

Claro.
Muito obrigado.
Subi suas alterações para o SVN na Revisão  40255.
Pelo que vi está tudo certo.
Favor testar e reportar qualquer problema.
Mais uma vez, Obrigado.

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

Muito obrigado pela contribuição.
Fiz a implementação baseada nela, mas com algumas modifiações. Notei que seus arquivos parecem bem desatualizados.
Subi as alterações para o SVN na Revisão  37551.
Pelo que vi está tudo certo, mas queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

@Onclick A alteração para os valores 15 e 75 já estão no SVN desde 10/2024.
Mas de acordo com o site do Sintegra, também deveriam ser incluídos os 76, 77, 78 e 79. Adicionei isso.
Vejam: https://www.sintegra.gov.br/Cad_Estados/cad_PA.html
Revisão SVN 73222

Muito obrigado pela contribuição.
Fiz a implementação baseada nela. Mas fiz uma alteração para garantir que se alguém estiver utilizando um arquivo anterior em cache continue conseguindo ler os dados.
Acredito ter coberto todos os pontos, mas por favor, queira atualizar, testar e reportar qualquer problema.
Subi as alterações para o SVN na Revisão  37224.
Mais uma vez obrigado.

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.

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.

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.
 

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:

 

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.