BigWings

Se está compilando no Delphi Rio, o suporte a httpIndy está desativado por padrão, por incompatibilidades com a nova versão. Basta alterar a propriedade Configuracoes.Geral.SSLHttpLib do componente no formulário para uma diferente de httpIndy e recompilar.

Sim.

Os schemas mais recentes do portal foram enviados ao repositório no dia 28/02/2019, com os devidos ajustes para funcionar corretamente com o ACBr (tem problemas conhecidos quando se usa os Schemas oficiais).

Com relação a validação local dos XML, ambos estão validando normalmente aqui, usando os Schemas atualizados na pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe. O componente não faz distinção na geração do XML entre homologação ou produção, nem controla em quais datas as tags devem ser geradas. A versão atual do componente está atualizada de acordo com os Schemas e a NT 2018.005 v1.10. Se a SEFAZ ainda não está aceitando o XML nessa versão (a data em produção é para 29/04/2019), o que você deve fazer é reverter os fontes do ACBr para uma versão anterior, onde a tag vICMSSubstituto não era gerada. Você pode fazer isso pela opção "Update to revision" do Tortoise, informando a revisão 16622, imediatamente anterior a esta: Revision: 16623 Author: italojjr Date: quinta-feira, 28 de fevereiro de 2019 07:24:21 Message: 28/02/2019 -- Diversos -- [*] Alterações visando atender a NT 2018/005 versão 1.10 Por: Italo Jurisato Junior ---- Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFe-change-log.txt Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeNotasFiscais.pas Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/PCNNFe/pcnNFe.pas Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/PCNNFe/pcnNFeConsts.pas Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/PCNNFe/pcnNFeR.pas Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/PCNNFe/pcnNFeW.pas

Esse XML está acusando falta de assinatura na validação. @Wladimir Isnard, note que o seu problema e o do @alex_porthal são diferentes. No caso dele está havendo falha local na validação do XML, no seu caso a SEFAZ está retornando o erro de falha no Schema. Como disse, no seu caso você deve entrar em contato com a SEFAZ e reportar o problema.

Anexe o XML por favor.

Esses campos não são gerados para o CST 10, apenas para CST 60 e CSOSN 500. Consulte a NT 2016.002 v1.61.

Basta atualizar a pasta de Schemas. Usem os schemas da pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe. Se o erro é de retorno da SEFAZ significa que ela não atualizou os Schemas do webservice. Será preciso entrar em contato e reportar o problema. Lembrando que a data prevista para entrada em produção da NT é 29/04/2019.

Realmente é estranho ter gerado o pFCPST e não ter gerado as demais tags do grupo, elas deveriam ter sido geradas mesmo com o valor zerado. Está com os fontes atualizados?

A NFe foi manifestada?

O componente não faz nenhum tipo de cálculo, você deve informar o vFCPST manuamente.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum.

Provavelmente será semelhando ao que hoje é o idCSC do contribuinte, provavelmente será preciso fazer o cadastro em cada UF que exigir essa informação, sendo sequencial por UF.

Tópico movido para o sub-fórum apropriado.

Foi essa imagem mesmo que mandou imprimir? Ela não está no formato "Bitmap monocromático".

Estou dizendo que se houve o retorno com cStat 155 quer dizer que a NFe foi cancelada. Já fez uma consulta da situação após a tentativa de cancelamento?

Acredito que tanto o DANFE em Fast quanto o em Fortes já está mostrando a denominação "CNPJ / CPF" e a máscara correta quando emitente CPF. Houve uma correção para o DANFE em Fast algumas semanas atrás quanto a isso, então certifique-se de que está com os fontes atualizados.

Anexe o XML de retorno se desejar, mas como disse basta tratar o cStat 155 como sucesso no cancelamento.

Você usa o ACBr?

Pelo que entendi o manual pede pra preencher apenas com zeros. Sendo assim não é necessário criar uma nova propriedade.

Se você pesquisar no fórum, tem alguns tópicos com esse problema. Alguns usuários tiveram sucesso apenas reinstalando o Delphi, outros não. Aqui tem uma possível solução, removendo uma chamada a uma mensagem para o Windows do código fonte do instalador. Você pode abrir e recompilar o instalador que está na pasta ACBr\Projetos\ACBrInstall_Trunk2.

Essa forma só funciona nos DANFE em Fast e Fortes. Em EscPos é preciso carregar a imagem do logo para a memória da impressora. Para o PosPrinter, para modelos compatíveis com o ppEscPosEpson, você pode usar o componente para fazer o carregamento do logo:

O cStat 155 é de sucesso e não erro. O retorno deve também conter o protocolo de cancelamento.

Provavelmente sim. Essa versão não tem suporte a scripts e causa esse tipo de problema. Para o Fast original do Delphi existem as versões BASIC no diretório Report\Obsoletos. Mas o recomendável é usar a versão comercial Enterprise do FastReport, versão 5 acima.

Tem a UF do endereço do emitente. Se tiver alguma NFe adicionada no componente sem essa informação preenchida vai ter esse erro. Como disse no post que citei, isso ocorre geralmente quando por engano você inclui uma segunda nota no componente com uma chamada extra a NotasFiscais.Add preenchendo outro dado qualquer apenas nessa segunda nota. Use o debug e veja quantas notas estão sendo enviadas no momento de chamar o método ACBrNFe.Enviar.