BigWings

Não sei o que causou a falha, só notei que são boletos diferentes. Talvez a consulta do histórico de alterações dos boletos no banco te dê alguma ideia do motivo.

Tem bastante material no link que está na primeira resposta deste tópico.

O boleto nosso número 1632 que você anexou parece ser o correto. O boleto nosso número 1633 parece ser o que o cliente tem em mãos, ele teve data de vencimento e valor alterados no CIP, mas manteve o código de barras.

Essa mensagem indica que você está usando schemas desatualizados, que não contemplam os CST do ICMS monofásico. Não foi descontinuado o CST 53. Não tem diferença de schemas entre produção e homologação, eles são usados pra validar o XML apenas. Nos Schemas da pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe tem um ajuste em relação aos schemas oficiais que você baixa do portal da NFe, é importante que você use os schemas do ACBr, caso contrário pode ter erro de validação indevido (sem relação com o erro que está tendo agora). Então, verifique novamente se a sua pasta de schemas está atualizada, e verifique a configuração do componente se está apontando para a pasta de schemas atualizada. Se quiser tirar a dúvida, valide o XML da NFe no validador da SEFAZ-RS e veja se acusa o mesmo erro: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx

Veja:

O CNPJ informado não coincide com o CNPJ do certificado usado na assinatura do evento.

Anexa aqui o arquivo *-ped-eve.xml que dá pra conferir a assinatura.

Veja qual CNPJ está informando no evento. Lembrando que o emitente do evento é o destinatário da NFe.

Parece ser uma validação indevida. Entre em contato com a SEFAZ e reporte.

ModeloININFeCompletoAlterado.ini

Carrega o XML no componente e chama o encerramento. Se não tem o XML pode baixar no portal. https://dfe-portal.svrs.rs.gov.br/Mdfe

Isso só vai te retornar os dados do protocolo de autorização do MDFe.

Origem = 4 CST = 70 Como informar depende de qual solução está usando, se é o componente, ACBrMonitor ou ACBrLib.

[Emitente] CRT=1 Altere para: [Emitente] CRT=3

As classes de alto nível, que você compila junto com o programa exemplo em C#, você pode referenciar na sua aplicação. As DLLs da ACBrLib em si, seja a versão Demo ou a Pro, são DLLs nativas do SO, portanto não podem ser referenciadas no projeto .NET, elas são instanciadas pelas classes de alto nível em tempo de execução.

O XML está sem o protocolo de autorização, possivelmente foi rejeitada, nesse caso não vai aparecer mesmo na SEFAZ. Qual foi o retorno do envio?

Recomendo a leitura do Guia Prático da EFD ICMS/IPI: http://sped.rfb.gov.br/pasta/show/1573 Nem tudo pode ser automatizado só com os arquivos XML, principalmente na parte da entrada, onde as informações são do ponto de vista do adquirente: CFOP de entrada, vinculação do item da nota com o produto interno, o valor dos créditos de ICMS e IPI...

Você está executando o instalador do ACBr para recompilar, correto?

No geral você pode usar o layout do CTe pra identificar onde informar as tags. RNTRC do emitente: infCTeNorm.rodo.RNTRC := ''; RNTRC do proprietário do veículo, se houver: infCTeNorm.rodo.veic[x].prop.RNTRC := '';

A fonte padrão é tamanho 7, e diminui pra 6 se o texto final for maior que a largura de impressão da página. Você pode comentar a linha 674 pra manter o tamanho 7, provavelmente vai ter que mexer nas margens também pra acomodar. Tamanho 8 creio ficar grande demais, mas pode fazer via código ou pelo designer do formulário.

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

No caso é uma informação ambígua, tanto pode ser o CSOSN 102 como pode ser o CST 02 com origem 1. Como o PVA foi atualizado pra incluir a nota orientativa sobre os CST de ICMS monofásico sobre combustíveis, vai gerar essa advertência. Se se tratar de um CSOSN, é só ignorar...

É dessa forma, mas a NFe tem que ter sido autorizada previamente. Quando você diz "não autorizado", qual o retorno exato? Denegado? NFe inexistente? Isso indica que você está consultando um recibo de um reenvio, onde houve a duplicidade. Se informar o número do recibo do envio onde a NFe foi autorizada, deve funcionar também.

Uma observação: no momento do envio, a SEFAZ não retorna o XML da NFe, retorna apenas o protocolo de autorização. É o ACBr quem gera o XML da nota, inicialmente a parte de dados, e depois de receber o protocolo da SEFAZ junta num XML completo com validade jurídica. Então é importante que você tenha esse XML de antes da tentativa do envio armazenado. Com ele, basta carregar o arquivo no componente e fazer a consulta do protocolo, que já terá o XML completo. Quem emite a nota é responsável pela guarda do arquivo. O DistribuicaoDFe é apenas para entregar o XML para o destinatário e outros interessados, ele não retorna documentos para o próprio emitente. Se você não tem o XML original, pode alimentar novamente o componente com os dados da venda, gerar um novo XML, e executar o método de consulta. Desde que todas as tags sejam idênticas a original (incluindo o código aleatório cNF), vai ter o XML completo.