Marcio Rossato

Boa tarde, este método ainda existe? Nâo localizei. Tentei estes: ACBrNFe1.ConsultarNFe(..); ACBrNFe1.NotasFiscais.ConsultarNFe(..); ACBrNFe1.NotasFiscais.items[0].ConsultarNFe(..); ACBrNFe1.NotasFiscais.items[0].NFe.ConsultarNFe(..); ACBrNFe1.Webservice.ConsultarNFe(..);

Bom dia, sabe me dizer se foi implementado está melhoria?

Olá, consegui solução com o pessoal da tanca mesmo. A Tanca está de parabéns sempre comprometida em ajudar a software house. Aconselho falar com eles novamente.

Acabamos de ligar na Tanca, eles informaram que nesta versão do SB só vai passar o layout 0.08, ou a gente adapta o sistema ou entrar em contato com o fale conosco da sefaz, pois informaram que " Falha na obtenção dos parametros de gestao." é problema com a sefaz.

Boa noite, depurei meu código e o problema não parece ser no meu programa, a variável pastaPDF não se altera entre uma linha e outra. As duas linhas estão em sequência no meu programa, da mesma forma que postei acima. Talvez eu tenha me expressado erroneamente, o problema surgiu após eu ter atualizado hoje os componentes, porém não é correto afirmar que começou após a última atualização, pode ser que o problema já ocorria antes. visto que já fazia alguns meses que eu não baixava o código atualizado.

Atualizei tudo antes de realizar esta publicação. Assim que possível vou verificar meu código novamente. obrigado

Bom dia pessoal, ao gerar o PDF do SAT, antes o meu código era assim: ACBrSATExtratoFortes1.PathPDF := pastaPDF; ACBrSATExtratoFortes1.NomeDocumento := chave+'.pdf'; Após a última atualização, o componente não está utilizando mais PathPDF e está salvando dentro da pasta do executável. Para contornar a situação eu passei e definir a pasta junto com o nome do documento: ACBrSATExtratoFortes1.PathPDF := pastaPDF; ACBrSATExtratoFortes1.NomeDocumento := pastaPDF + chave+'.pdf'; Isto funcionou e o pdf voltou a ser salvo no local correto. A dúvida é, a propriedade PathPDF realmente deixou de ser utilizada?

. Levei na assistência técnica e falei com a fabricante (Bematech). Como o sat não está mais na garantia, mandaram descartar e comprar outro.

Estou com mesmo problema, 2 SATs bematech rb1000 bloqueados pois a software house deixou no layout 0.06 e a sefaz estava recusando os lotes, hoje (20/02) a sefaz informou que vai voltar aceitar 0.06 porém pra ajudar esses SATs da bematech não conseguem resolver o endereço. :S

Obrigado sr Perfeito, funcionou pra perfeito pra mim também. Obrigado trigus, funcionou aqui também.

Bom dia, era um erro no meu código. o componente estava correto. Para gerar um xml sem assinar e validar, eu usei os seguintes comandos: ACBrMDFe1.Manifestos.GerarMDFe; memo1.Lines.Text := ACBrMDFe1.Manifestos.Items[0].XML; memo1.Lines.SaveToFile('c:\temp.xml'); pelo XML eu percebi que estava faltando um campo obrigatório.

Obrigado pelo retorno, o erro aparecia antes do XML ser salvo. Tive que enviar o comando para gerar o XML manualmente, e descobri o problema. Obrigado.

Estou com este problema no MDFe, quando coloca mais de uma UF no percurso.

Na verdade o seu problema não foi tratado neste tópico, pois este arquivo que você postou já está contemplado a solicitação que eu pedi, O arquivo mais atual do SVN e este que você postou, já contém a alteração que solicitei no CNAB400 e ambos estão funcionando aqui para mim. Seu problema é outro e não foi disparado nesta Issue.

Como eu não trabalho com cnab 240 pra mim fica difícil de testar. Pelo que olhei aqui no código fonte parece que o ler240 tem o mesmo problema que tinha o cnab400. Está lendo os 13 dígitos como sendo o nosso número. O problema de ler os 13 dígitos, utilizando este exemplo mesmo que você enviou, o nosso número quer é 5265-5 passaria a ser 52565-X "onde x é um número qualquer calculado". O engraçado que parece ser um "erro intencional". pois no oncreate da classe é definido que o tamanho máximo é 12. fpTamanhoMaximoNossoNum := 12; Mas ao ler o retorno é alterado para 13 no começo da função, e no final antes de sair da função lerRetorno é definido novamente como 12. (Parece ser um WorkAround) Você pode postar um arquivo remessa, um de retorno ?

Boa tarde pessoal, peço desculpas se parecer um pouco rude, mas não vejo aqui uma questão de opinião. Acredito que existe o certo e o errado. Pode ser que eu e o pessoal do AcBR que aplicou a correção que eu solicitei estejamos enganados quanto a interpretação do manual, acontece . Gostaria de solicitar se possível que vocês postem aqui 2 arquivos sendo: 1 de Remessa e o outro de Retorno onde constas o mesmo título (da forma que foi a remessa e a forma que veio o retorno). Mas posso adiantar sem ver estes dois arquivos o seguinte: Acredito que vocês enviam a remessa sem informar o nosso número (pois o nosso número não é obrigatório), mas no arquivo retorno você salvam o nosso número que é preenchido aleatoriamente pelo santander. E foi por isso que você nunca perceberam que o nosso número tem 7 digitos e o ultimo é o DV. Agora para quem envia o nosso numero da remessa e depois lia no retorno, o número mudava. Por exemplo era enviado na remessa o número 14, e o retorno o numero era 140 (pois incorporava o digito). Mas para ter certeza, mais uma vez peço que enviem os arquivos de remessa e retorno aqui para sanarmos essa dúvida. Envia por favor o manual do cnab240 eu só tenho o cnab400

Bom dia, eu tenho aqui um manual é mais recente (Março de 2017). De qualquer forma, este trecho de ambos manuais estão iguais. Ocorre que o dígito verificador ocupa a última posição do nosso número, portanto o nosso número tem 7 dígitos + 1 digito verificador que são os 8 dígitos do manual. No retorno é a mais coisa, os primeiros 7 dígitos são o nosso número, e o último o digito verificador. Quanto a ler o digito do arquivo retorno ou recalcular isto é indiferente, pois independente de ler ou calcular o número deve ser sempre o mesmo. H7800 Layout CNAB 400 com registro (padrão 353) março 2017 v 2.15.pdf

Porque meu cérebro já está com "Erro Interno"

Bom dia pessoal, este assunto já foi discutido bastante ontem em outro tópico. Em resumo Nâo vai mais funcionar em windows xp e windows server 2003. Só funciona com windows 7, service pack 1 ou superior. e o windows precisa estar com todas atualizações em dia. Fazendo isso, o componente precisa estar definido como LT_TLS_1.2 e o windows marcado apenas a opção de tls 1.2 e desmarcar os demais. 4 clientes meus ontem que não estavam funcionando, atualizei o windows, resolveu.

Bom dia, mesmo problema aqui (estado de São Paulo), o cliente está com windows 7, sp 1, porém desatualizado, estou atualizando pra ver se resolve.

Boa tarde, estou com mesmo problema aqui, icmssn102 não gera as informações do imposto, acredito haver uma nota técnica detalhando isso mas olhando rapidamente não encontrei. Zerei os dados do imposto (base de calculo, aliq, etc, e passou) o Imposto do simples nacional é gerado com base no faturamento, portanto me parece ser o mais correto não ter mesmo a base de calculo preenchida nessas tags (ICMSSN...), mas não tenho certeza sobre isso. Ideal mesmo seria ver a nota técnica que fala sobre as tags, se alguém souber a NT favor postar pra gente aqui.

Parabéns pelo trabalho, até hoje também não tive mais problemas.

Voltei a usar o WinCrypt deu certo.

pEstou utilizando a unit deste post criado pelo Delcio, parece que vai evitar o problema.

Bom dia, também migrei para o libxml2 e este erro começou a aparecer em um cliente com windows7 32 bits. @fidel, colocar a dll na pasta c:\windows\system32 nao resolveu.