felipetomm

Boa tarde @Gabriel Fernando Lopes. Eu gerei hoje mesmo uma NF de devolução com essas condições (icms cst 60 e vICMSSubstituto). A única coisa que tive que fazer foi atualizar o acbrmonitor (era uma versão de 2018) pois ele não estava jogando o campo no xml (eu utilizo por arquivo txt). Atualiza todo teu acbr e vê o que acontece.

Pensando que sua conexão ou o serviço da sefaz não seja restabelecido e você emita em contingência, deve-se (seguindo este novo ajuste) emitir uma NF de série 890 e nova numeração. Cada série deve ter sua numeração sequencial, sem pulos.. Como esse ajuste não entrou em vigor, o que é aconselhado fazer (ao meu ver): apenas pule a numeração, sem alterar a série, emita a nota 101 em contingência. Quando os serviços forem restabelecidos, você verifica se a nota 100 autorizou na sefaz. Caso não autorizou, inutilize a numeração, caso contrário, devolução ou cancelamento da NF 100.

Bom dia. RS Rejeitando.

890 à 899 até então são destinados para NF avulsa se não me falha a memória. Em homologação, experimente autorizar com série 900 ou superior.

Infelizmente acredito que estamos errados. Estou analisando um material da Migrate e nele o exemplo deixou bem claro que a alteração é específica para o tpEmis 9 - Contingência Offline. Edit: Na pressa, não vi que no tópico inicial já havia sido especificado o tipo de emissão offline.

Boa tarde. Caso alguém puder esclarecer, pelo que compreendo estas alterações são de uso único e exclusivo da emissão em Contingência. Emissão Offline de NFC-e não estaria na jogada, isso mesmo?

Boa tarde Felipe. Até onde eu sei, para NFC-e não existe nacional. Talvez tenhamos alguma novidade na versão 4.0 da NFCe/NFe. O que testei aqui, e funciona no mesmo modo da Sefaz Nacional, é passar o parâmetro para o campo da chave. Porém, cada sefaz pode ter seus parâmetros com nomes distintos. Se o seu caso for a Sefaz do RS, este é o link: https://www.sefaz.rs.gov.br/NFE/NFE-COM.aspx?chaveNFe= Caso contrário, deve encontrar o link da sefaz desejada e procurar o parâmetro no fonte da página (F12 e procurar o edit). Espero ter ajudado

Bom dia Edson! Acabei não voltando mais ao tópico, mas esses links funcionaram temporariamente após realizar uma consulta no dispositivo que fosse realizar novas consultas. Agora com essas alterações (do captcha principalmente), se passar o parâmetro &nfe=aquivaiachave a página já fica com o campo preenchido, bastando apenas validar o captcha. Se me lembro, isso não ocorria antes. Acredito que já facilite ao usuário, principalmente quando se trata de um dispositivo móvel, pois no nosso caso, adicionamos esse link em um qrCode, no mesmo conceito da NFC-e. Experimenta utilizar esse parâmetro que mencionei, e posta aí o resultado. O link completo ficaria assim: http://www.nfe.fazenda.gov.br/portal/consultaRecaptcha.aspx?tipoConsulta=completa&tipoConteudo=XbSeqxE8pl8=&nfe=aquivaiachave

Boa tarde Edson. Fiz o teste mas não houve diferença no meu caso. Vou testar com um volume maior de notas, complementando a colocação abaixo. Beleza @EMBarbosa, estarei fazendo esses testes com base nisso.

Acho que entendi o recado. Como mencionado pelo @BigWings, acredito que precisaremos rever algumas questões para ajustar o nosso código. @EMBarbosa, tuas colocações, em conjunto com a dos colegas, puderam esclarecer e confirmar várias questões que sempre tivemos dúvidas. Estarei retomando as alterações no nosso projeto em busca da solução. De momento, agradeço pela dedicação e pelo conhecimento compartilhado Obrigado!

Olá @BigWings. De fato, muito ouvi falar que também não havia diferença nos métodos. Porém, sempre fiquei com dúvida devido aos artigos onde cada autor defendia seus métodos de utilização. Sobre a utilização do Create(Owner), adotamos por não passar o owner no mesmo. Assim os leaks são identificados no mesmo instante pois não são destruídos. Não sei se é a melhor prática, mas foi o que acabamos adotando. PS: Já vou adiantando um pouco, pois em algum momento irá surgir essa coloção: "por que não utiliza o comando milagroso que reduz memória?". Já o utilizava inicialmente. Porém, optamos por descontinuar sua utilização, visto que o mesmo pode interferir em outros processos do S.O.

Bom dia pessoal. Acredito que problemas relacionados com memória sejam um dos capítulos marcantes no início da carreira de desenvolvedores. Se minha colocação estiver correta, então chegou a minha vez Estou passando por uma certa dificuldade em encontrar qual a maneira ideal para realizar a liberação de memória de nossa aplicação (objetos, componentes, etc...). Vou primeiro para a descrição do nosso problema. Nossa aplicação atualmente não possuí vazamentos de memória (memory leaks). Este diria que foi o primeiro item do capítulo que nos deparamos e eventualmente corrigimos, com a utilização do FastMM4. Então, o problema que estou passando é que nosso software está apresentando um crescimento constante na alocação de memória do S.O. Ou seja, ele inicia com 50mb, e ao longo do dia, após executar determinadas operações repetidamente, se encontra com 150~170~... mb. Com isso, em determinados momentos é apresentado o erro de "Out of Memory", ocasionando uma série de outros alertas ao usuário. Num primeiro momento, chegamos a pensar que de fato ainda havia vazamentos de memória. Porém, efetuamos o encerramento natural do software em um caso onde a memória do processo chegava a 170mb, e mesmo assim, não foi apresentado nenhum vazamento de memória. Artigos pra lá, artigos pra cá, nos deparamos com diversas colocações aconselhando única e exclusivamente o FreeAndNil. Ao mesmo tempo, outras informando que o uso do FreeAndNil deve ser evitado em 99,9% das vezes em que pretendemos utilizá-lo. Como mencionei inicialmente, acredito que esta seja uma dúvida muito pertinente para a grande maioria dos desenvolvedores iniciantes (ou não), não sabendo qual a maneira mais correta e adequada para efetuar a liberação de objetos. Gostaria que cada um relatasse vivências e dores que já teve em situações desse tipo, pois acredito que apenas uma descrição bem colocada, madura e real seja o suficiente para que cada desenvolvedor possa compreender o real significado de quando usar ou não determinada chamada.

Apenas para complementar, devido ao tempo, seguem os links atualizados. Consulta Completa: https://www.nfe.fazenda.gov.br/portal/consultaCompleta.aspx?tipoConteudo=XbSeqxE8pl8=&nfe=123 Consulta Resumida: https://www.nfe.fazenda.gov.br/portal/consultaResumo.aspx?tipoConteudo=d09fwabTnLk=&nfe=123 Obrigado @William de Castro!

É somente este pacote ou os demais também?

@Ricardo Frade Mourino, estava com o mesmo caso que o seu. Mesmo tendo realizado a cópia para System32 e SysWOW64, efetuado o registro das DLLs para o System32, continuava acusando a falta da libxml2-2. Resolvi copiando as DLLs para o bin do Delphi. (c:\Program Files (x86)\Embarcadero\Studio\18.0\bin)

Função que utilizo atualmente, caso quiser tirar algum proveito. Recebe como parâmetro o Assunto, a Mensagem e um Array contendo o caminho dos anexos. Porém, conforme o @BigWings mencionou, pode ser apenas sua config de TLS. function TFuncao.EnviaEmail(const AAssunto, AMensagem: String; AAnexo: array of String): Boolean; var AMail: TACBrMail; I: Integer; begin AMail:= TACBrMail.Create(Self); with AMail do begin Host := 'smtp.dominio.com'; Port := '587'; Username := '[email protected]'; Password := 'senha_do_email'; AltBody.Add(AMensagem); Subject := AAssunto; SetSSL := False; SetTLS := True; From := '[email protected]'; FromName := 'Seu Nome'; AddAddress('[email protected]','Motorista Edivan'); for I := Low(AAnexo) to High(AAnexo) do begin if (CompareStr(AAnexo[i],'') <> 0) then begin if FileExists(AAnexo[i]) then AddAttachment(AAnexo[i]); end; end; IsHTML:= True; // UseThread:= True; end; try try AMail.Send; finally AMail.Destroy; AMail:= nil; end; except AMail.Destroy; AMail:= nil; Exit; end; end;

Boa tarde. Essa função que o @mbbortolini citou é de fato milagrosa. Já tinha conhecimento da mesma e inclusive a utilizamos em nosso sistema. Porém, não se deixem enganar! Se existe um crescimento do uso de memória pela aplicação, procurem verificar por vazamentos de memória (Memmory Leaks). Para isso, a dica do colega @Dércio Luis Zanatta cai como uma luva. Atualmente utilizamos esse pacote (FastMM4) para reportar os vazamentos de memória que a aplicação teve ao decorrer de sua execução. Ao meu ver, o fato de que o consumo de memória do aplicativo aumenta após realizar determinada chamada é normal, pois o S.O aloca novos blocos de memória para a criação de objetos. O que não vem a ser normal é um crescimento constante dessa utilização de memória mesmo após a liberação dos objetos criados.

Boa tarde @Daniel Simoes. Gostaria de ver se terias alguma posição sobre o caso. Agradeço.

Boa tarde Daniel. Por um acaso estava migrando minha aplicação para OpenSSL. Abaixo os passos que realizei: 1º No componente ACBrNFe ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; 2º No arquivo ACBr.inc, localizado em Fontes\ACBrComum, ajustei as seguintes linhas, apenas removendo o ponto no início: {$DEFINE DFE_SEM_CAPICOM} {$DEFINE USE_MINGW} 3º Copiar as DLLs contidas em "C:\CaminhoACBR"\DLLs\XMLSec e "C:\CaminhoACBR"\DLLs\XMLSec\MinGW\"32 ou 64" junto com sua aplicação (Executavel), ou no path do Windows (C:\Windows\System32 para x86 e C:\Windows\SysWOW64 para x64) Testes locais funcionaram perfeitamente. Mas ainda não repliquei ao cliente.

Boa tarde Daniel. Experimenta setar essa configuração. É o que estou utilizando: NFe.Configuracoes.Geral.SSLLib := libWinCrypt;

Boa tarde. @Paulo Alexandre Hostert, estava com o mesmo caso aqui. Migrei para libWinCrypt utilizando a seguinte configuração: SSLLib := libWinCrypt; SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinINet; SSLXmlSignLib := xsMsXml; Após emitir uma NFCe a aplicação congelava/travava após 1 minuto (aproximadamente). Em debug, também estava gerando a exception da crypt32.dll. Hoje pela manhã removi todo o ACBr (apagaacbr.bat), fiz um novo diretório, atualizei e instalei novamente. Tudo normal agora. Agora estou utilizando somente a linha: SSLLib := libWinCrypt;

Boa tarde. Apenas uma sugestão. Nos testes de contingência nós realizamos o "bloqueio" do dominio no hosts ou no próprio ACBrNFeServicos.ini Meu caso no hosts é esse: 128.1.10.1 nfce-homologacao.sefazrs.rs.gov.br 128.0.0.1 nfe-homologacao.sefazrs.rs.gov.br Altere e verifique se o erro é o mesmo.

Bom dia a todos. Seguindo as orientações, criei este tópico para continuar com o assunto tratado no tópico inicial, visto que o problema aqui relatado é outro caso. O problema que encontramos acontece após a impressão do DANFCe, onde o mesmo especifica algumas configurações (ex: tamanho da pag. 29,7cm) à impressora, e tal configuração afeta as posteriores impressões do nosso sistema que ultrapassam o tamanho de uma folha A4. Esta configuração permanece até o término da aplicação. Se executarmos a mesma rotina de impressão, sem antes ter realizado a impressão de um DANFCe, nossa rotina imprime o arquivo normalmente, excedendo os 29,7cm. Descrição do nosso ambiente: Win7 64, utilizando como forma de impressão o Fortes. Impressoras utilizadas: (i)Bematech MP-4200 TH, (ii) Elgin i9 @Daniel Simoes, conforme solicitado, segue em anexo um exemplo para reproduzir o problema. Adicionei a função para impressão nos botoes "1 - Status de Serviço" e "2 - Imprimir DANFe" do ACBrNFeDemo Necessita somente adicionar a unit "mORMotReport.pas", e ajustar os caminhos que deixei na aplicação. No mais, acredito ser isso. Qualquer problema com o exemplo, fico a disposição pra corrigir e auxiliar. Grato pela atenção. PS: Um detalhe importante que deixei passar já no tópico anterior. Para impressão de documentos que excedem o tamanho padrão das impressoras (80mm x 30cm), necessitamos criar um formulario de impressão personalizado e após, especifica-lo nas configuralções da impressora. No caso, criamos um formulário com as seguintes medidas: Largura = 7,36 cm / Comprimento = 300 cm. Segue anexo uma breve descrição para esse procedimento. FelipeTomm-ImpressaoDANFCe.7z FormularioImpressao.pdf

Boa tarde Daniel, Juliomar. Desculpem a demora em responder. Estava realizando mais alguns testes. Concordo.. Acredito que o ideal mesmo, que foi nossa tentativa inicial, é verificar qual a chamada que deixa essa configuração para a aplicação. Correto. Acreditamos que seja esse o problema. Sim.. estamos utilizando o fortes. Estamos utilizando o pacote SynopsePDF, do framework mORMot para gerar os documentos (carnê de parcelas) que são impressos após o cupom. Estou preparando um material para você poder realizar os testes no seu ambiente. Assim que estiver pronto, envio aqui em anexo.

Bom dia Juliomar. Alterei e fiz testes aqui. Apenas adicionei a uses "Printers" e a linha "Printer.Create;", conforme segue abaixo: procedure TNotasFiscais.Imprimir; begin VerificarDANFE; TACBrNFe(FACBrNFe).DANFE.ImprimirDANFE(nil); Printer.Create; end; Não tenho muito conhecimento com o componente. Acredito que tal ajuste tenha um lugar mais apropriado. Esperamos que seja de ajuda. Segue anexo o arquivo com a alteração. ACBrNFeNotasFiscais.pas