BigWings

Não existe evento de manifestação para MDFe. Eles são exclusivos para NFe.

Basicamente o mesmo erro, mas do lado da SEFAZ agora. Está exigindo o vICMSSubstituto sendo que ele é opcional no layout, desde a NT 2018.004 v.1.20. Validando o XML pelo validador da SEFAZ-RS não ocorre problema: O ACBr tem a configuração ForcarGerarTagRejeicao938 que você pode tentar usar para forçar a geração da tag vICMSSubstituto.

Experimente desativar o anti-vírus. Por estar baixando um binário executável, pode ser que o ele esteja interferindo no processo e bloqueando a operação.

Para NFe de emissão própria, pode-se obter apenas os eventos de Cancelamento, Carta de Correção e EPEC, pelo método ACBrNFe.Consultar. É facultado à UF, entretanto, retornar a lista completa de eventos, coisa que nenhuma UF faz, até onde sei.

O correto é 1 sim, mas isso vai contra o que está sendo gerado no XML. Como disse, é preciso debugar.

Você deve conseguir obter os eventos de manifestação emitidos por terceiros, para as NFe de emissão própria. Os eventos de manifestação de emissão própria, para as NFe de terceiros destinadas, não são retornadas pelo método DistribuicaoDFe. O webservice também não retorna a situação atual da manifestação de uma NFe destinada.

A única coisa que me chamou atenção no trecho de código é você estar manipulando dois objetos ACBrNFe na mesma rotina, um na classe FrmA003Hk e outro na classe TFrmM005HK. Fora isso não identifiquei o que possa estar causando o problema, será necessário debugar. Tente analisar o valor de ACBrNFe.EventoNFe.Evento.Count antes da chamada ao método ACBrNFe.EnviarEvento. O demo do componente tem um exemplo de cancelamento funcionando.

Você está enviando dois eventos no seu arquivo 0-ped-eve.xml, um deles não tem justificativa, por isso o erro de schema. Provavelmente é algo errado na sua rotina, e está chamando o método ACBrNFe.EventoNFe.Evento.Add mais de uma vez, ou faltando chamar ACBrNFe.EventoNFe.Evento.Clear antes de iniciar a rotina de cancelamento.

Um erro comum é a justificativa menor que 15 caracteres. Mas precisa conferir o XML gerado pra tentar identificar o problema. Configure o componente pra gravar os arquivos de envio e retorno e anexe aqui o *-ped-can.xml e *-ped-can-soap.xml.

Você pode configurar a porta como "RAW:Nome da impressora no Windows", mas não tenho certeza se a gaveta funciona dessa forma.

Tem algum decreto ou norma técnica para essa proibição? Foi entregue um documento fiscal inválido para o consumidor. A empresa vai ter que se explicar. Em contingência não há rejeição por data e hora atrasada, o correto é transmitir como contingência e não no modo normal. O melhor é seguir a legislação.

Esse parece um erro de validação local e não retorno da SEFAZ. A mensagem está exigindo o preenchimento do vICMSSubstituto, pelos schemas atualmente o campo vICMSSubstituto é opcional no layout, então o erro não deveria acontecer. Veja se sua pasta de Schemas está atualizada.

Fiz confusão com a pergunta mas a resposta é a mesma... Verificar se existe essa opção pelo driver da impressora. Caso contrário terá que implementar via PosPrinter mesmo...

O ACBrNFeDANFCeFortes usa o spooler do Windows para impressão, então o controle fica a cargo do driver de impressora instalado. Veja se nas preferências de impressão da impressora do Windows existe a opção de corte após a impressão.

O nosso número mostrado na impressão do boleto é "formatado", incluindo informações como código do convênio e dígito verificado, não necessariamente é o nosso número usado no cálculo da linha digitável. Consulte o manual do banco.

A configuração só tem efeito quando CST 60 ou CSOSN 500 e não é operação com consumidor final (tag: indFinal = 0).

A maioria dos relatos é de sucesso ao gerar a tag vICMSSubstituto zerada quando configurada a opção ForcarGerarTagRejeicao938, e gerando o XML com a tag indFinal = 0 (não consumidor final). O problema de não gerar a tag pode ser por algo errado com os fontes ou instalação, algum .pas ou .dcu antigos do ACBr no path de compilação. É preciso então verificar se não há fontes antigos em algum lugar do disco que o Delphi esteja encontrando, usar o debug ajuda. Se preferirem podem tentar contratar uma consultoria: https://www.projetoacbr.com.br/forum/companies/category/2-consultores/

@bilogyn Obrigado por compartilhar, mas evite colar trechos grandes de código no corpo da mensagem. Use a opção de anexar arquivos.

Anexe o arquivo modificado.

Tem razão. Fiz teste com o Delphi Rio e realmente não foram adicionados os paths para plataforma Windows 64 bits. Nesse caso creio que teria que ser adicionado manualmente mesmo.

O instalador não compila os pacotes em 64 bits. É necessário não marcar a opção LibXX para que sejam adicionados no library path os caminhos para os fontes do ACBr, para serem usados na compilação de cada projeto.

Cada município contrata sistemas que implementam a NFSe cada um a sua maneira, apesar de haver um padrão nacional e uma tentativa de implantação da NFSe Nacional ainda capengando. Alguns não exigem nem o certificado digital, podendo a comunicação ser feita via usuário e senha, ou hash de acesso. Se o município em questão permite o uso do eCPF e está implementado no ACBr, provavelmente a resposta é sim.

Não tem substituto pra ele. Você pode usar a versão para a licença comercial do FastReports ou a versão em Fortes. Foi movido para a pasta Obsoletos por não receber mais contribuições, e pode estar defasado.

O enumerado está declarado na unit pcnConversao.pas e a mesma referenciada normalmente na unit ACBrNFeConfiguracoes.pas. Como ACBrInstall_Trunk2.exe compilou normalmente, é algo no seu projeto, pode ser que tenha algum .pas ou .dcu antigo do ACBr no path de compilação dele. Você usa Delphi ou Lazarus? O ACBrInstall_Trunk2.exe serve apenas para o Delphi e você está compilando o ACBrMonitorPLUS no Lazarus... No Lazarus você fez o rebuild após a atualização dos fontes? Idem ao acima.