BigWings

Para uso com o ACBr o ideal é usar a pasta de Schemas disponível no repositório. https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/Schemas/NFe

Depois de atualizar os fontes, você reinstalou os componente pelo ACBrInstall_Trunk2.exe? Se não fez, tente fazer isso, de preferência marcando a opção para apagar os arquivos antigos. Já que a correção pra esse problema foi nos fontes e não apenas no fr3.

Testei pelo demo do componente e a consulta executou normalmente para o RS, sem alteração do fonte. Isso acontece porque na pesquisa pelo arquivo de schema o ACBr não encontra um arquivo "consCad_v4.00.xsd", já que o existente na pasta de schemas é o "consCad_v2.00.xsd" sendo assim ele altera a versão automaticamente. Então não entendo o que pode estar acontecendo do seu lado... por acaso você tem um arquivo "consCad_v4.00.xsd" na pasta de Schemas?

Pode ser que a SEFAZ só tenha começado a validar agora a obrigatoriedade do CEST. No validador do RS também não identifica rejeição por falta do CEST. A última versão da NT 2015.003 dava como 01/04/2018 o início da obrigatoriedade, mas encontrei várias notícias segundo as quais houve aviso no portal que havia sido postergado essa data, até que fosse emitida nova Nota Técnica, mas não encontrei nova data. Lembrando que segundo a legislação a informação do CEST é obrigatória, apenas a validação pela SEFAZ não seria aplicada.

Existe com a versão 1.00, com a mesma URL, ou seja o ACBr vai encontrar do mesmo jeito. Essa URL é do serviço de download de NFe, no ambiente nacional ele já foi desativado há anos em prol do DistribuicaoDFe. Não sei dizer se no CE ele ainda funciona, mesmo se funcionar, não tem relação com a autorização e possível duplicidade de notas. Até porque no caso da NFCe a transmissão é feita pelo "Integrador" da SEFAZ...

Pela imagem não vai fazer qualquer diferença usar um arquivo ou o outro.

Veja que a alteração que o Italo subiu é referente ao DACTE em Fortes Report. Para Fast Report ainda não foi feita a alteração para esconder o campo ICMS-ST.

Não é possível emitir NFe sem itens. O usual em nota complementar é informar um item denominado "COMPLEMENTO DE ICMS", por exemplo.

Enviei correção para o repositório para contornar esse problema, rev. 18479. Favor atualizar os fontes, testar novamente e reportar qualquer problema.

Pela imagem você trocou a configuração SSLLib para Capicom. Por isso o erro de 'Schema inválido' deixou de ocorrer na validação do XML. Apesar de não ter mais o erro, usar Capicom não é mais recomandado por estar defasado, já foi abandonado pela Microsoft, e tem relatos no fórum de problemas graves com certificados A3.

Retornar a chave de acesso correta na mensagem de rejeição depende da SEFAZ. Se não me engano o único requisito pra isso é usar o mesmo certificado digital do emitente para fazer também a transmissão. Isso está nas normas técnicas, mas aparentemente nem todas seguem.

Estranho, a URL não parece ter relação com esse erro. Não precisou substituir os schemas ou alterar as configurações SSLLib?

Você precisa descobrir qual a chave correta a que se refere a NFe com essa numeração. Pode ser gerada chave diferente para a mesma numeração de NFe caso você informe o campo cNF, data de emissão ou tipo de emissão diferente do já autorizado pela SEFAZ. A SEFAZ deveria retornar a chave correta na resposta com a rejeição 539, mas pelo log que você anexou, ela não está fazendo isso.

Salve o arquivo anexo na pasta de Schemas do provedor ISSNET, substituindo o existente, e teste novamente. tipos_simples.xsd

A imagem que postei se refere sim ao DACTE. No caso esse layout é do evento EPEC para CTe que contém o campo vICMSST, e como a coluna "Ocor." indica, ele não é obrigatório. De qualquer forma, é estranho existir o campo vICMSST no layout do EPEC para CTe e não existir essa tag no layout do próprio CTe. Os CST aceitos pelo CTe são o 00, 20, 40, 41, 51, 60, e 90. Pelo que o layout indica, não é permitido destaque de ICMS-ST no CTe, que se existissem estaria nos CST 10, 30, 70... Sabe algo sobre isto @Italo Jurisato Junior?

Segundo o manual, está correto informar o valor nessa coluna: O que não é necessária é a coluna ICMS ST, ela não é usada pelo DANFE DACTE em Fast Report.

Pode anexar o XML?

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

Ao abrir tópico veja se não está na área reservada ao SAC. No fórum aberto você deve conseguir abrir tópicos sem problemas. Pelos webservices usados pelo ACBr não é possível. Algumas SEFAZ disponibilizam esse serviço pelo seu respectivo portal.

Aparentemente a diferença está no número da parcela. Se você imprime o boleto com a parcela 002, está informando 2 também na remessa?

Esse XML não é válido, não passa na validação pelos Schemas. Pra saber o motivo é preciso o XML original.

Essa função chama a SetRoundMode da unit Math. Ela altera globalmente a forma como são calculados os arredondamentos, então aparentemente é algo com o Fortes Report, quando o modo está configurado como rmDown ou rmUp. Foi o que descobri nos testes. Chamando SetRondMode(rmNearest); antes de executar o método de impressão ou geração do PDF deve resolver. Ou alterando a função RoundTo5 para voltar ao modo anterior: var rm: TRoundingMode; [...] rm := GetRoundMode; try xDecimais := Copy(xValor, p + 1, Length(xValor)); if Length(xDecimais) > nCasas then begin if xDecimais[nCasas + 1] >= '5' then SetRoundMode(rmUP) else SetRoundMode(rmNearest); end; nValor := RoundTo(Valor, Casas); finally SetRoundMode(rm); end;

Não precisa fazer nada diferente, apenas imprimir as dezenas CASO sejam retornadas no protocolo. Não creio que a SEFAZ vá gerar dezenas em notas de entrada, provavelmente apenas em notas de venda para consumidor final. Mas que saiba até agora a mesma não publicou nenhum decreto ou instrução sobre em que situações vão ser retornadas as dezenas ou não, apenas implantou o sistema e avisou por email. O que se sabe até agora: - Só são retornadas para pessoa física (CPF) - Tem um valor mínimo para que as dezenas sejam geradas.

@acg.net Enviei ajuste para o DANFeNFCe5_00.fr3 imprimir os descontos e acréscimos por item, rev. 18446. Favor atualizar os fontes e testar novamente.

Basta o XML carregado ter o protocolo de autorização.