Diego Foliene

Hmm, pode estar ai a questão. Consegue fazer um teste debugando? Se sim, por favor, coloque um break-point no local indicado pelo print e veja se ele atende a condição para gerar a seção no INI.

Bom dia! O problema está na forma como você está montando o seu arquivo INI. O arquivo INI é tem um formato de seções, onde cada seção tem um título e seus respectivos campos. Vamos pegar a seção do produto 01 em seu arquivo: [ICMS001] CST=10 Origem=0 [impostoDevol001] pDevol=9.75 vIPIDevol=24.49 pRedBC=1.0000 vBC=251.16 pICMS=18.00 vICMS=45.21 pMVAST=42.00 pRedBCST=0.0000 vBCST=391.42 pICMSST=18.00 vICMSST=25.25 ModalidadeST=4 Neste trecho tem duas seções. A seção [ICMS001] que tem somente os campos CST e Origem e a seção [impostoDevol001] que tem os demais campos. Isso está errado. Boa parte dos campos da seção [impostoDevol001] na verdade fazer parte da seção [ICMS001]; Por favor, tente assim: [ICMS001] CST=10 Origem=0 pRedBC=1.0000 vBC=251.16 pICMS=18.00 vICMS=45.21 pMVAST=42.00 pRedBCST=0.0000 vBCST=391.42 pICMSST=18.00 vICMSST=25.25 ModalidadeST=4 [impostoDevol001] pDevol=9.75 vIPIDevol=24.49

Bom dia! Por favor, você utiliza as classes direto do SVN ou Nuget? As classes estão atualizadas e em dia com o SVN ou o Nuget está utilizando a última versão do pacote disponível? Fiz um teste com o exemplo disponível para C# e a versão mais recente da Lib. Alterei na rotina AlimentarDados() produto.PIS.CST = CSTPIS.pis49; produto.COFINS.CST = CSTCofins.cof49; E o XML gerado respeitou a informação criando o arquivo com o valor: <PIS> <PISSN> <CST>49</CST> </PISSN> </PIS> <COFINS> <COFINSSN> <CST>49</CST> </COFINSSN> </COFINS> Quando você faz uso das classes de alto nível, no momento de comunicar com a Lib, elas criam para você um arquivo .INI para ser enviado a Lib. Você pode ver isso no final da rotina AlimentarDados do exemplo. return CFe.ToString(); Em meu teste, o mesmo ficou desta forma nas seções do PIX e do CONFINS: [PIS001] CST=49 vBC=0 pPIS=0 qBCProd=0 vAliqProd=0 vPIS=0 [COFINS001] CST=49 vBC=0 pCOFINS=0 qBCProd=0 vAliqProd=0 vCOFINS=0 Por favor, veja como está ficando no seu. Se ele estiver ficando com um valor diferente de 01, por favor, se possível disponibilize o mesmo na íntegra para que possa fazer um teste em meu ambiente.

Muito obrigado. De fato, testando aqui realmente o A4 se comportou de maneira diferente, vamos analisar a questão na TK mencionada anteriormente. Qualquer novidade reportamos aqui.

Por favor, como você está configurando a impressão? Nos testes que fiz em meu ambiente utilizando o programa exemplo, apenas carregando o XML que disponibilizou e usando o método de imprimir o impresso ficou desta forma: Apenas depois que configurei desta forma antes de chamar o método de impressão: ACBrNFe1.DANFe.ImprimeTributos := trbSeparadamente; ACBrNFe1.DANFe.vTribFed := ACBrNFe1.NotasFiscais[0].NFe.Total.ICMSTot.vTotTrib; ACBrNFe1.DANFe.vTribEst := ACBrNFe1.NotasFiscais[0].NFe.Total.ICMSTot.vICMS; Que o resultado ficou assim: De qualquer forma, foi criada a #TK-6029 para análise do caso e parecer por parte da equipe de consultores.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia. Estou verificando junto aos demais consultores.

Por favor, seus fontes estão atualizados e em dia com o SVN? Qual é o motor de relatórios que está utilizando, Fortes ou Fast? Fiz alguns testes com seu arquivo, mas tanto no EscPos, no A4 com Fortes e no Fast foi mostrado valor 0,37, que foi lido da tag vTotTrib.

Boa tarde! Por favor, pode fornecer mais informações? Você está utilizando as classes de alto nível para preencher a classe de cupom ou está alimentando diretamente via INI? Pode disponibilizar o log gerado pela Lib para análise? Se julgar que o mesmo tenha dados sensíveis e não possa ser disponibilizado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Boa tarde! Por favor, veja se as informações no tópico abaixo lhe são úteis:

Boa tarde @Fox_Desenvolvimento. Você está enviando a nota de forma síncrona para o ambiente de produção em São Paulo. NFe.CriarEnviarNFe(cIniNFe,nLote,[bImprimeDANFE],[bSincrono],[cImpressora],[bMostrarPreview],[nNumCopias], [bImprimirPDF]) NFe.CriarEnviarNFe( <cIniNFe>: "Conteúdo do seu Arquivo INI", <nLote>:, <bImprimirDANFe>:, <bSincrono>: 1) O ambiente de produção da São Paulo não permite envio síncrono em produção, somente em homologação. Altere o parâmetro do <bSincrono> para 0 e faça um novo teste.

Boa tarde. O arquivo é gerado no mesmo local da pasta onde definiu para salvar os demais XMLs. A propriedade é: ACBrNFe.WebServices.Consulta.RetNFeDFe

Boa tarde. Você mencionou anteriormente que o Delphi está configurado ANSI. Por favor, coloque um break-point no local indicado pelo print e veja como fica o conteúdo da variável Texto. Em meus testes, na linha 3574, o conteúdo de Texto está: <xCorrecao>Correção a ser considerada, texto livre. A correção mais recente substitui as anteriores.</xCorrecao> Na linha 3575, depois de passar pela função ConverteXMLtoUTF8 ele fica: <xCorrecao>Correção a ser considerada, texto livre. A correção mais recente substitui as anteriores.</xCorrecao> O que no meu entendimento, faz sentido, visto que a paginação de código da minha IDE está como ANSI. Outro teste também que reforça isso. No momento de gravação do arquivo, faça um teste e salve um arquivo dessa forma: var LXMLAnsi: String; begin LXML := 'Recebe o conteúdo da propriedade normalmente como já é feito'; //Faz o processo de gravação que já executa atualmente. LXMLAnsi := UTF8ToNativeString(LXML); FACBrNFe.Gravar('Caminho+NomeArquivo', LXMLAnsi, '', False); end; Em meu ambiente, o LXMLAnsi ficou com o valor: <xCorrecao>Correção a ser considerada, texto livre. A correção mais recente substitui as anteriores.</xCorrecao> Se tento abrir o arquivo gerado com o conteúdo dele no navegador, o mesmo fica com a visualização quebrada e no notepad++ fica desta forma com a codificação em UTF-8: Se eu mudar a codificação para ANSI:

Bom dia! Complementando o pedido do meu amigo @Júlio Cavalcanti, por favor, disponibilize o XML que está utilizando para que possamos realizar teste em nosso ambiente. Se julgar que o mesmo tenha dados sensíveis e não possa ser enviado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Bom dia! Por favor, coloque um break-point no local indicado pelo print e verifique se a API do PSP está devolvendo estas informações. A resposta da API do PSP inalterada pelo ACBr vai estar na variável "RespostaHttp".

Bom dia! Foi criada a #TK-6023 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada neste tópico.

Bom dia! Criada a #TK-6022 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será disponibilizada no tópico.

Bom dia! Por favor, veja as informações expostas neste tópico:

Bom dia @douglaswf ! Se você consultar a nota carregando o XML ao invés de pela chave, o ACBr vai montar um arquivo -NFeDFe.xml para você com as informações do protocolo de autorização e também do evento de cancelamento.

Bom dia @melk. O XML que você gera e envia para o web service é o XML do RPS. O webservice recebe este XML do RPS e se tudo estiver certo, ele converte em uma NFS-e e o próprio webservice gera o XML da NFS-e e devolve ele para você. Se você não está enviando está informação no RPS, mas o XML da NFS-e que é devolvido está vindo com está informação, então é o web service do provedor que está adicionando ela no momento em que gera a NFS-e. Por isso é preciso que você entre em contato para questionar, verificar, por exemplo, se na base de dados do WS não tem esse TLog| ou TBair| na informação. Não sei se entendi a pergunta, mas se sua dúvida é como fazer modificações no layout, você vai abrir os arquivos ACBrNFSeXDANFSeRL e ACBrNFSeXDANFSeRLRetrato que há na pasta do fontes, vai modificar o RLRetrato como desejar e reinstalar o ACBr para que as modificações surtam efeito.

Boa tarde! Vou verificar o que pode ser feito junto a equipe de consultores.

Boa tarde. Você informou anteriormente que utiliza o método Gravar nativo do componente. Por favor: Verifique qual é o conteúdo de LIsUTF8 no momento em que é feita a gravação. Grave um arquivo passando o valor true e um arquivo passando o valor false para a parâmetro IsUTF8 do método Gravar. Coloque as dlls deste LINK na pasta do executável durante seus testes. Confirme por favor, qual é o valor que definiu nas configurações: ACBrNFe.Configuracoes.Geral.SSLLib. ACBrNFe1.Configuracoes.Geral.SSLCryptLib. ACBrNFe1.Configuracoes.Geral.SSLHttpLib. ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib.

Boa tarde @Vagner S Oliveira! Optei por separar em um tópico novo, pois o anterior estava começando a ficar extenso e o tema das mensagens começou a divergir do problema original. Conferindo no log da respectiva unit, essa alteração foi feita na revision 34652 com a seguinte mensagem de Log: A mesma foi feita para visando sanar o problema apresentado no tópico abaixo: Criada a #TK-6012 para análise do caso e parecer por parte da equipe de consultores.

Bom dia! Combinado, ficamos no aguardo de um feedback.

Olá pessoal! No dia 24/09/2024 foi publicado o Ato Diat Nº058/2024 alterando o artigo 5º do Ato Diat original do tópico, dando a ele a seguinte redação: Na prática, isso posterga a obrigatoriedade da informação destes campos para 01/01/2025, tornando opcional a informação dos mesmos até a referida data.