BigWings

Qual o .fr3?

Acho que o processo aí está errado, o tomador que nem tem CNAE de transportadora não pode emitir CTe. Pode emitir uma NFe de anulação de frete CFOP 6206 ou apenas enviar o evento de prestação de serviço em desacordo, e o emitente do CTe emite outro CTe de anulação. Verifica com o contador da empresa isso.

Eu creio que não seja possível emitir um CTe de anulação anulando um CTe emitido por terceiro.

Vejo que gerou as tags, não era o que você queria?

Troque tpCTe=0 por tpCTe=2.

No caso de NFe, não é possível. Pela regra de validação Q01-20, é obrigatório informar o grupo PIS. Não existe como informar CST de PIS em branco no componente, como você mesmo verificou o padrão é 01. O que você pode fazer é validar a informação do CST no momento de alimentar o componente: uses pcnConversao; var ok: Boolean; [...] Det.Imposto.PIS.CST := StrToCSTPIS(ok, MinhaQuery.FieldByName('CST_PIS').AsString); if not ok then raise Exception.Create('CST do PIS inválido!');

A data de saída não pode ser inferior a data de emissão. A data de emissão pode ser atrasada em até 30 dias, de acordo com o MOC, mas cada UF pode definir prazo diferente.

SVRS - 13/01/2022 ATENÇÃO: SVRS - Desativação dos protocolos TLS 1.0 e TLS 1.1 A Sefaz Virtual do Rio Grande do Sul (SVRS), para garantir o bom funcionamento do Ambiente de Autorização dos Documentos Fiscais Eletrônicos, deverá desabilitar os protocolos de comunicação mais antigos a partir do dia 11/04/2022. Esta mudança é necessária, não só pela simplificação do ambiente e aumento da segurança, como também pela inviabilidade de configuração dos protocolos de comunicação mais antigos em nova versão do sistema operacional dos servidores. Ambiente de Homologação: Conforme comunicado anterior, o ambiente de homologação dos DF-e da SVRS já está configurado da forma correta, unicamente com o Protocolo TLS versão 1.2. A configuração atual prevê também a eliminação das Cifras consideradas inseguras. Para consultar a lista de cifras aceitas atualmente, sugerimos consultar a página do “SSL Labs”, no link abaixo: https://www.ssllabs.com/ssltest/analyze.html?d=nfe-homologacao.svrs.rs.gov.br Para o ambiente de homologação de todos os DF-e, o resultado obtido será como segue: Ambiente de Produção: A partir do dia 11/04/2022, o Ambiente de Produção para a Autorização dos DF-e deverá estar configurado de forma idêntica ao Ambiente de Homologação descrito acima. Portanto, as aplicações que consomem os webservices da SVRS devem verificar se possuem o protocolo TLS 1.2 habilitado e se apresentam um conjunto de Cifras compatíveis com as Cifras aceitas pela SVRS. Caso a adaptação não seja realizada, não será possível estabelecer uma conexão segura entre a aplicação cliente da empresa e a aplicação servidor do ambiente de autorização da SVRS. Nota: Veja que a documentação técnica dos sistemas diferentes DF-e já prevê a utilização unicamente do Protocolo TLS 1.2, conforme os MOC correspondentes. Assinado por: Secretaria da Fazenda do Rio Grande do Sul Fonte: https://dfe-portal.svrs.rs.gov.br/Nfe/Avisos/2722

Isso está no manual de contingência da NFCe. O processo é igual ao que você já faz mas a NFCe nº 11 deve ser emitida em contingência offline e ter os mesmos dados da NFCe nº 10. Posteriormente você transmite a NFCe nº 11 e consulta a nº 10, se ela tiver sido autorizada você faz o cancelamento por substituição, indicando a chave da NFCe nº 11 como substituta. Se não tiver sido autorizada, inutiliza-se a numeração. O prazo para o cancelamento por substituição é 168 horas.

Tem o manual do banco com essa instrução?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Verifica as configurações SSLLib e SSLType, é preciso usar TLS 1.2. O erro de validação é por estar usando Schemas desatualizados, verifique a pasta de schemas e a configuração PathSchemas do componente.

Isso é algum erro no .dfm. Veja se algum arquivo está marcado em vermelho na pasta. Se tiver manda fazer o revert pelo Tortoise.

Quanto a parar de gerar pode ser por ele ter parado de usar o serviço, nesse caso é interrompida a geração, conforme as últimas versões da NT 2014.002. Já quanto a sequência dos NSU, você verificou que tipo de documento é o NSU 3469 e o 3545?

A versão é definida no arquivo ACBrNFSeXServicos.ini, que é compilado como res e assim embarcado na aplicação.

Como disse acima, isso deve estar na sua aplicação e não no ACBr.

Existe validação para a tag pICMSInter que deve ser 4, 7 ou 12%. Quanto à pICMSUFDest não lembro de haver validação.

Faça o teste usando o programa exemplo, se ocorrer o mesmo erro mostre aqui o passo a passo pra reproduzir. Se não ocorrer, provavelmente é algo na sua aplicação, e você vai precisar depurar o código pra descobrir. Até onde sei não tem nada no código do ACBr que salve esse arquivo temp.xml.

Já foi corrigido, atualize os fontes.

Você pode usar os webservices do AM para fazer testes e não depender da SEFAZ-MG. http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/

"Expected is one of" = é esperado um dos... ou seja você informa CEP ou latitude e longitude.

A tag vFCP nos grupos ICMS é o valor do imposto devido a UF do emitente. Se é uma operação interestadual com consumidor final deve informar o vFCP do grupo ICMSUFDEST, nesse caso o FCP é recolhido para a UF do destinatário. No ACBrNFe, além do FCP, você vai precisar informar a tag pICMSInterPart = 100 para gerar o grupo ICMSUFDEST.

Lendo o código, isso pode acontecer se você informar CEP ou coordenadas de descarregamento, mas não informar os de carregamento.

O problema ocorre no programa exemplo do componente?