Roberto.Godinho

Realmente meu comentário pode ser desconsiderado, pra desencargo de consciência fiz um teste e autorizou a NF-e. O problema deve ser outro então. 43150988211701000110550060000004371318648137-ProcNfe.xml

Bom dia, Note que na consulta do sintegra o destinatário esta no REGIME DE APURAÇÃO MICRO EPP/SIMPLES NACIONAL, tente enviar a tag indIEDest = 2 (isento do ICMS), creio ser este o seu problema jovem. Abraço

É no trunk normal mesmo Juliomar.

Bom dia, Estava com alguns problemas em alguns clientes que tem o nome de fantasia excessivamente grande e estava excedendo a largura do papel, creio que outros já tiveram este problema. Enfim, fiz alguns ajustes de modo a permitir quebra de linha no nome da fantasia, aqui tem um exemplo de como ficou teste_danfe.pdf Estou anexando os fontes alterados, se der pra por no SVN ficaria grato. teste_danfe.pdf ACBrDANFCeFortesFr.rar

Boa Tarde zottis, O teu problema é a forma de emissão informada na chave de acesso e a informada no XML. tua chave esta assim(veja campo tpemis): uf = 41 cnpj = 150717023140000188 modelo = 65 serie = 001 numero = 000000043 tpemis = 1 <----- cnf = 00000043 cdv = 8 e aqui vc esta passando teOffline: EnviarNFe.acbrnf1.NotasFiscais.Items[0].NFe.Ide.tpEmis := teOffLine; vc terá que refazer a chave de acesso informando o tpemis correto.

Boa tarde, A ultima versão liberada do DANFeSimplificado.fr3 disponivel no SVN não esta mostrando o ReportTitle, cujo contém o código de barras e informações da NFe, o erro esta no código no próprio arquivo que verifica se há uma logo especificada e caso não houver esconde o componente. Segue pedaço do código com erro: procedure Page1OnBeforePrint(Sender: TfrxComponent); begin if <Parametros."Imagem"> = '' then begin ReportTitle1.Visible := false; end; // esconde informação do protocolo quando em contingencia if <Parametros."Contingencia_Valor"> = '' then begin Memo5.Visible := false; end; end; Notem que o componente que deve ser escondido é o PageHeader1 que contem a logo e não o ReportTitle1. Corrigi o arquivo e o estou anexando a este post. DANFeSimplificado.rar Abraço

Boa tarde, quando retorna evento de registro de CTe o componente não esta identificando o tipo do evento (610600) pois o mesmo não existe na unit pcnConversao, segue em anexo a unit alterado, se algum adm puder adicionar ao SVN ficaria grato. <resEvento xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00"> <cOrgao>91</cOrgao> <CNPJ>33683111000107</CNPJ> <chNFe>41141009610964000126550010000972021241634621</chNFe> <dhEvento>2015-01-28T15:39:49-02:00</dhEvento> <tpEvento>610600</tpEvento> <nSeqEvento>1</nSeqEvento> <xEvento>Registro de Autorização de CT-e para a NF-e</xEvento> <dhRecbto>2015-01-28T15:39:49-02:00</dhRecbto> <nProt>891150000170984</nProt> </resEvento> pcnConversao.pas

Bom dia, Percebi que muita gente está tendo problema com uso indevido, também notei que todos com o mesmo problema estão utilizando o ultNSU retornado pela consulta anterior, ou sejá, estão utilizando de forma errada as orientações da NT que diz: Notem que, quando ocorre o retorno de um lote consultado o valor retornado na tag ultNSU é equivalente ao ultimo documento retornado, ou seja, se utilizaro ultNSU pra iniciar a consutla seguinte irá gera consumo indevido. ver item 2.2 (sucessivas tentativas de busca de registros já disponibilizados anteriormente). Portanto, nas consultas subsequentes utilizar o ultNSU+1, é a forma que eu faço aqui e não gera erro. Leio todos os registros diponiveis no loop (cerca de 200), só vai ocorrer novamente se não seguir a orientação do item 2.5 do manual.

Obrigado Italo

Bom dia, Guilherme você está testando com WS de que estado? em testes aqui detectei o mesmo problema com o WS do MT, homologação não retorna nenhum registro apesar de ter emitido NF-e usando o mesmo e outros CNPJ contra o CNPJ da empresa, creio que sejá algum problema no WS de homologação pois em produção está retornando normal.

Bom dia, pois é Italo, conhecendo os contadores da pra imaginar que ninguem está fazendo isto, dos nossos clientes creio que apenas unas 20 fazem a manifestação corretamente.

Bom dia, Adicionei as URL's de consulta da NFCe para o PB e RR, se possivel gostaria que adicionassem ao SVN. ACBrNFeUtil.pas

realmente, na pressa de deixar tudo organizado antes das férias aqui não tive tempo de parar pra pensar nas possibilidades, vai ser uma mão na roda mesmo. obrigado pela dica Italo!!!

realmente tem mais informações italo, ele retorna o proc completo do evento, estou anexando 2 arquivos, um com o retorno original do ws e outro com o conteudo zip descompactado. 20150122135321-dist-dfe.rar

Italo, poderia passar as alterações que você efetuou? Quanto ao procEvento eu não tratei esta situação em especifico, apenas adicionei o seguinte: if (oLeitorInfZip.rExtrai(1, 'resEvento') <> '') or (oLeitorInfZip.rExtrai(1, 'procEventoNFe') <> '') then <<<-------------- begin ... end; Esta solução apenas identifica e lê o conteudo do procEvento, já que possui as mesmas tags do resEvento, mas seria bom já tratar assim como você esta fazendo com o procNFe de modo que possa salvar o XML corretamente.

Italo, não sei se você identificou isto também mas, no retorno, tem a possibilidade de vir o procEventoNFe ao invés do resEvento, não sei qual o criterio pra vir assim, se depende de WS ou não, mas seria bom já tratar esta situação tb.

você esta utilizando a unit original postada pelo Matheus? se sim, no post passei a correção necessária assim que você a publicou, agora, se estiver utilizando a que eu enviei (que inclusive é a mesma que a do Matheus, apenas melhorei alguns quesitos) já é outro caso, ai terei que verificar.

Boa tarde Guilherme, o que ocorre é que o que esta sendo descompactado não é o conteudo do objeto Leitor mas sim o valor que está sendo armazenado na propriedade InfZip, sendo assim, quando o leitor tenta extrair o grupo resNFe do xml retornado ele irá encontrar o conteudo ainda compactado e não identificará a devida TAG, no post acima do seu está uma unit alterada pra atender este requisito, você pode usa-la ou basear-se nela pra fazer a leitura do retorno.

realmente a NT não diz nada quanto a isto e também não consegui identificar qual o criterio pra retornar o xml completo Edit: segue a unit com a implementação para leitura do procNFe quando retornado pela consulta. pcnRetDistDFeInt.pas

estive efetuando alguns testes aqui no PR e percebi que retorna o xml da NF-e completo na consulta, ou seja, ao invés de vir a tag resNFe retorna nfeProc, neste caso terá que ser tratado pra ler as informações desta tag também senão o componente ficara vazio, creio eu que poderá ser lido as informações e armazenado nas mesmas propriedades onde é armazenada o resumo da NFe.

bom dia, ocorreu o mesmo erro aqui e verifiquei que não esta lendo o campo docZip, para corrigir basta substituir na linha 300 da unit pcnRetDistDFeInt StrAux := Leitor.rCampo(tcStr, 'docZip'); por por StrAux := RetornarConteudoEntre(Leitor.Grupo, '>', '</docZip'); abraço.

UP... Alguem poderia verificar e adicionar ao SVN por gentileza?

Bom dia, Implementado e homologado junto a rodocrédito o boleto e arquivos remessa e retorno tipo 400 para o Secrede. segue email de homologação e arquivos fontes alterados, se alguem puder adicionar ao svn do ACBrBoletos seria bom. arquivos.rar

Bom dia, Estou com um problema em um notebook quando tento enviar uma NFC-e na versão 3.10. O erro ocorre quando verifica se é versão 3.10 para assim gerar a tag vICMSDeson, comparando o valor armazenado na propriedade (NFe.infNFe.versao >= 3.10), ou seja, a propriedade NFe.infNFe.versao contem o valor '3,1' mas quando compara ambos o valor não bate. Segundo um artigo que estive lendo, ele aconselha usar funções como "SameValue" pra comparar valores e não faze-los diretamente. http://rvelthuis.de/articles/articles-floats.html Outra coisa que notei é que este erro só ocorre em determinadas maquinas. por exemplo, em um PC com win7 x64 funciona normalmente, já em um notebook com mesma versão de SO ocorre este erro. Gostaria de saber se alguem já passou por situações como esta e como devo proceder pra corrigi-lo. Desde já grato!!

não juaumkiko, no caso ocorrido nem esta sendo impresso a danfe, apenas esta sendo gerado o preview em tela. Pelo que entendi o rave procura a impressora padrão do windows e "coleta" o tamanho da pagina, neste caso o preview sai correto, no entanto, como mencionado acima, se não houver nenhuma impressora instalada no windows ele pega um tamanho de pagina padrão e quando vai gerar o danfe ele entra em loop adicionando pagina após entrar no metodo ImprimirItens(); nos testes que executei aqui acontece isso mesmo tendo apenas 1 item pois quando entra no metodo, mais especificamente no codigo abaixo(ver codigo 1), o (YPos+(aFontHeigth*QtdeMin)) é sempre mair FLastItens. CÒDIGO 1: //Testa se a quantidade de linhas a ser impressa //ultrapassará o final do quadro dos itens, //e caso aconteça, cria uma nova página if (YPos+(aFontHeigth*QtdeMin))>FLastItens then begin Break; end else if FDetIndex>0 then begin MoveTo(PosX,YPos+0.1-aFontHeigth); LineTo(FLastX,YPos+0.1-aFontHeigth); end; assim, mesmo imprimindo apenas 1 linha ele excede o tamanho do quadro de itens e não imprime o item, cria uma nova pagina (ver codigo 2) e o processo se repete gerando milhares de paginas até exceder a memória e dar pau de vez. CODIGO 2 while not ((IsPrintAllProd) and (IsPrintAllInfCpl)) do begin //Paisagem linha 1443, Retrato linha 1409 if not bInicio then NewPage; ImprimirItens(MontarPagina); bInicio:=False; end;