Painel de líderes

Voltando aqui para dizer que foi identificado o problema! A cliente mudou a UF de destino para emissão de NFC-e, dai dava o erro! Custamos achar esse problema, não imaginávamos que alguém poderia ter alterado!

Consegui puxar... Muito Obrigado Segue o que foi feito: var Logo: TStringStream; Logo := TStringStream.Create(TBlobField(DM.qAuxADO.FieldByName('IMAGEM')).AsString); try DM.ACBrNFe.DANFE.Logo := Logo.DataString; finally Logo.Free; end; end;

Caro sr. @DOCFABIO temos app para integração em parceria, meu zap é 19.9.9658.0055

Bom dia, Criada a TK-4645 para avaliação. Obrigado pela contribuição.

Meu contato Adhelmar Rondon Júnior WhatsApp +55 (11)93710-4384

Boa tarde Diego, Já esta no SVN.

Boa tarde, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Criada a TK-4644 para avaliação. Obrigado pela contribuição.

Olá Pessoal, O nosso amigo @Fabiano Oliveira de Castro incluiu o código abaixo na procedure que alimenta o componente com os dados do serviço prestado e com isso resolveu esse erro. if OptanteSN = osnOptanteMEEPP then begin Servico.Valores.totTrib.indTotTrib := indSim; Servico.Valores.totTrib.pTotTribSN := 2.01; end; O valor atribuído em pTotTribSN pode ser diferente de uma cidade para outra.

Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/