Astrogildo82

Muito obrigado!

Boa tarde, a cidade de Pomerode passou a utilizar a versão 101 do webservice da IPM. Nos testes foi constatado que é necessário alterar também o endereço do mesmo. Segue as alterações efetuadas: [4213203] Nome=Pomerode UF=SC Provedor=IPM Versao=1.01 ProRecepcionar=https://pomerode.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe&cidade=padrao Desde já Agradeço!

Bom dia, notei agora que o problema só ocorre quando marco a opção "Deixar somente a pasta LibXX no library Path do Delphi?" no instalador ACBR.

Boa tarde, após atualização do ACBR e do Fortes Report, está dando o erro "A component named RLNFe already exists" ao tentar visualizar o danfe pelo comando "NFe.NotasFiscais.Imprimir;" e também ao tentar gerar um PDF do danfe, tanto em Retrato quanto em Paisagem. Compilando o Demo do ACBR, acontece o mesmo erro. Ambiente: * Delphi XE8; * ACBR atualizado, sem arquivos antigos remanescentes e sem arquivos em conflito; * Fortes atualizado pelo frceInstall.exe e sem arquivos antigos remanescentes. Já removi e fiz a reinstalação completa tanto do ACBR quanto do Fortes Report. Tenho outras impressões que usam o Fortes dentro do sistema e lá está OK. Alguém teria uma dica de onde possa estar o problema?

Experimenta colocar no campo usuário somente "autolagoinha" e no campo endereço você deixa completo "[email protected]" - é assim que eu uso nos meus clientes que usam contas do gmail.

Régys, só que você fez essa alteração somente na linha 235, faltando fazer na linha 223 também, pois por conta disso não está trazendo a vigencia, versão e a chave da tabela.

Adilson, nas minhas NFe complementares de ICMS/IPI/ICMSST eu sigo a lógica que minha assessoria contábil me passou: fazer a NFe complementar extamente igual a NFe a ser complementada, exceto por FinNFe = complemento desejado, IndTot = 0 e descrição do que foi complementado nas InfAdic. Destaco que o NCM "00" (que, como o André já comentou, tem que ser "00000000") na NT2014.004_v1.00_NCM_Pais_Fuso_Evento na verdade está se referindo lá apenas a serviços ou a NFe de Ajuste e as suas respectivas complementares, sendo que para NFe complementar de produtos, deve-se usar o NCM normal deles.

Bom dia, Na verdade consta sim - você está consultando no ambiente de homologação? http://hom.nfe.fazenda.gov.br/portal/consulta.aspx?tipoConsulta=completa&tipoConteudo=XbSeqxE8pl8=

Consulte pelo portal nacional da NFe que lá estará certinho. Não sei como é nas outras UFs, mas na Sefaz de MG as coisas demoram um pouco para dar certo...

Utilize a tag refECF.

Tive um problema desses em um cliente com um servidor windows server 2008, sendo que depois de formatar o servidor e instalar o windows 2003, aparentemente estava resolvido. Fizemos isso depois de inúmeras tentativas frustradas de configuração, instalação do certificado em outras máquinas, etc. Depois de alguns meses, surgiu o mesmo problema - detalhe: nas duas ocasiões o acesso ao certificado estava lento até mesmo diretamente no Internet Explorer. Descobrimos então que isso acontecia por conta do armazenamento das credenciais no windows das máquinas que teriam que usar o certificado. Nas máquinas clientes com Windows 7 é só ir no painel de controle - gerenciador de credenciais e remover todas as credenciais. Note que isso fará com que as senhas armazenadas para preenchimento automático em outros computadores/sites serão novamente solicitadas no próximo acesso. Experimentem deixar o componente como estava originalmente e fazer essa exclusão das credenciais e então reportem aqui o resultado.

Tenho o mesmo problema em SC e se deixar em branco como sugerido pelo colega Jocimar, a validação pelos Schemas (já atualizados) não aceita.

Ah sim, acabei esquecendo de comentar a questão central: nos nossos clientes não foram emitidas muitas NFe de ajuste de ICMS, mas todas as que foram geradas nesses 5 anos que o sistema emite NFe tinham item sim - tanto no XML quanto no Danfe, e nunca fomos questionados por nenhuma contabilidade e nem pela Sefaz quanto a isso.

Bom dia Ilsouza, tem algumas coisas estranhas nesses arquivos: * o XML tem a tag ProcEmi com o valor 0 - emissão de NF-e com aplicativo do contribuinte (se for gerado no Emissor Gratuito, vai ter 3 - emissão NF-e pelo contribuinte com aplicativo fornecido pelo Fisco); * o PDF foi gerado em Rave (é só acessar as propriedades do PDF em qualquer visualizador - no Acrobat Reader é só dar ctrl-D) - o aplicativo da Receita não usa Rave, mas sim iText; * o layout do danfe está bem diferente do PDF que é gerado pelo aplicativo da Receita, com muitas diferenças nos estilos de linhas, molduras e fontes. Baseado nisso e em outras diferenças dá para dizer que nenhum dos dois arquivos veio do emissor gratuito da receita. Provavelmente quem lhe passou esses arquivos tentou fazer uma montagem bem tosca para lhe fazer acreditar que teria que ser gerado o danfe dessa forma. Para comprovar o que citei acima, é só baixar o emissor e gerar uma NFe nas mesmas condições da que você anexou e ai comparar.

Você não teria que usar a CFOP 7101 ao invés da 6101?

Você poderia mandar um xml em que está acontecendo isso? Aqui não consegui detectar esse problema.

Não pude deixar passar essa: a Sefaz de MG é craque em fazer m... Além dos vários problemas relatados aqui no fórum pelo pessoal, só eles lá mesmo para ter o dia 31 de novembro, daqui a pouco divulgam algo para o dia 31 de fevereiro. kkkkkk

Fiz a alteração proposta acima e funcionou blz aqui também. Vou deixar os fontes alterados em anexo para facilitar o merge para quem for subir para o SVN. DanfeFortes.zip

Bom dia, na verdade houve alguma mudança no FNFe.InfNFe.Id, pois antes vinha com 'NFe' + nro da chave e agora está somente o nro da chave. Percebi isso porque eu gero um PDF manualmente com o nome do arquivo usando esse campo e na sexta-feira começou a dar problema pq o nome do arquivo não saia mais nesse padrão.

Só para complementar o que o Italo disse: esse exemplo em Delphi que eles disponibilizaram mostra apenas como dar um post no "webservice" deles. A parte que realmente seria útil, que é a formação do XML, não tem nada.

Boa noite Lucas. Testei a impressão só da NFe e aparentemente está tudo OK. Só aproveitando as imagens anexas, nota-se que a impressão dos textos na vertical no Fortes fica meio distorcida (o que já acontecia antes, não tendo nada a ver com as suas alterações). Eu já fiz um teste trocando a fonte desses labels para "small fonts", o que na pré-visualização até fica melhor, mas na impressão não muda nada. Alguém teria uma outra sugestão do que poderia ser feito para melhorar isso?

Eu tive um problema parecido na minha aplicação, mas com um ambiente um pouco diferente: Delphi 2010 + Postgresql + Zeos + Windows 7. No meu caso, para aumentar o mistério, o acesso ao banco dos dados estava lento somente quando o ponteiro do mouse estava sobre a aplicação - se eu colocava o mouse na barra de tarefas do windows, a velocidade ficava normal. E isso acontecia indiferentemente com o banco de dados sendo acessado na maquina local ou em um servidor na rede. Como não encontrei nenhum relato de algo parecido nas minhas pesquisas na net, acabei resolvendo o caso usando uma "POG": fiz uma função que desativa o mouse durante os processos que demandam muitos acessos de banco na minha aplicação. Edson, você poderia testar se o teu caso é o mesmo? É só posicionar o mouse na barra de tarefas durante uma dessas lentidões - se for o mesmo problema, a diferença será bem perceptível.

Me expressei mal, não quis me referir a quantidade de elementos do conjunto. Mas o operador "in" não consegue tratar os elementos inteiros maiores que 255, talvez o delphi trate os numeros byte (0..255) como sendo um tipo enumerado que é subconjunto dos inteiros. Vai dar erro se vc tentar compilar esse codigo, porque um dos elementos é maior do que a faixa dos byte: if 1 in [1,301] then showmessage('OK'); Vai dar erro também se tiver um número negativo no conjunto, mas vai dar certo se vc fizer: if 1 in [1,255] then showmessage('OK'); Um modo "gambi" para resolver o problema das NFe confirmadas é: FNotasFiscais.Items[j].Confirmada := (AInfProt.Items[i].cStat in [100,110,205,150]) or (AInfProt.Items[i].cStat = 301) or (AInfProt.Items[i].cStat = 302); Desculpa Darlana, não havia visto a sua resposta ainda, mas é isso ai.

Na verdade isso é uma limitação do operador "IN" - ele que aceita no máximo 255 conjuntos.

Eu nem havia atentado ao fato de que poderia usar esses métodos para alterar os dados da forma que eu preciso. Obrigado!