BigWings

Para cancelar a NFe é preciso cancelar também o MDFe, e não é possível cancelar um MDFe já encerrado. A razão pra isso é que o encerramento do MDFe indica a conclusão do transporte, como cancelar um MDFe ou NFe em que houve a circulação de mercadoria? Pela NT 2013.008 é permitido o cancelamento após o evento de operação não realizada, ou de desconhecimento da operação, desde que seja a última manifestação definitiva para a NFe. O problema nesse caso deve ser a falta de sincronização do ambiente nacional com a SEFAZ-MG que ainda não recebeu o evento de operação não realizada, impedindo o cancelamento.

Tente desativar a dependência do Indy no ACBr.inc: // Descomente a linha abaixo, se você não deseja adicionar a Dependência da INDY nos seus Projetos {.$DEFINE DFE_SEM_INDY} Devendo ficar: {$DEFINE DFE_SEM_INDY}

O ACBrIBPTax tem a implementação da API. Veja o demo do componente.

Correto... vi que tem "ImpressoraComum" e "ImpressoraECF" na lista de modelos. Mas me parece que não há o comando de abertura de gaveta implementado para a Epson. procedure TACBrGAVStrComandoProperty.GetValues(Proc: TGetStrProc); begin Proc('#027,v,#140 | Bematech') ; Proc('#254 | Daruma') ; Proc('#027,p,0,#050,#200 | Mecaf') ; Proc('#027,p,#000,#050,#200 | Schalter') ; Proc('#027,#112,#048,#050 | Zantus') ; end; Comparando com a implementação do comando de abertura de gaveta do ACBrPosPrinter para ppEscPosEpson: function TACBrEscPosEpson.ComandoGaveta(NumGaveta: Integer): AnsiString; var CharGav: AnsiChar; begin if NumGaveta > 1 then CharGav := #1 else CharGav := #0; with fpPosPrinter.ConfigGaveta do begin Result := ESC + 'p' + CharGav + AnsiChar(TempoON) + AnsiChar(TempoOFF); end; end; Por leitura dos fontes o StrComando da Mecaf é que parece compatível, mas não tenho certeza, nem como testar.

O problema com caracteres acentuados é causado por codificação incorreta. Não tenho experiência com Lazarus mas que saiba ele sabe lidar melhor que o Delphi com codificações diversas. Qual a codificação está sendo gerada para o arquivo TXT enviado para o ACBrMonitorPLUS? Nas configurações do ACBrMonitorPLUS há a opção "ANSI" para que o arquivo seja lido nessa codificação se for o caso.

O ACBrGAV não funciona quando a gaveta está conectada a uma impressora fiscal ou não fiscal, apenas quando a gaveta é conectada diretamente na porta serial. Para impressora não fiscal use o componente ACBrPosPrinter e envie o comando de abertura de gaveta. Veja o demo do componente para mais detalhes.

Nesse caso não devia estar carregando essa URL. A URL correta conforme definida no ACBrNFeServicos.ini: [NFCe_SVRS_H] [...] NfeConsultaProtocolo_4.00=https://nfce-homologacao.svrs.rs.gov.br/ws/NfeConsulta/NfeConsulta4.asmx Tente o debug.

Essa URL é de versões antigas da NFe e já foi desativada. Veja se está configurando a versão do layout do XML corretamente. ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

Está passando o "role" RDB$ADMIN ao conectar no banco com o novo usuário?

Verifique se está informando a hora e fuso horário de emissão corretamente: <dhEmi>2018-11-07T23:03:00-03:00</dhEmi> Já houve relatos no fórum de problemas com o webservice de GO com notas com emissão próxima a virada do mês, acredito que possa ser o mesmo problema, dado o fuso horário diferente do webservice ele pode estar esperando que a data de emissão seja na verdade no dia 08 nesse caso.

Faça a consulta pela chave de acesso e veja o conteúdo da tag qrCode, e compare com a URL que foi lida do QRCode impresso no DANFE.

Não, a única forma de visualizar os dados da NFCe pela chave de acesso é via consulta pública no portal NFCe no site da SEFAZ estadual.

Não. A consulta por chave traz somente os dados referentes ao protocolo de autorização de uso e informações do evento de cancelamento, se houver.

Usando o CSOSN900 todas estas tags deveriam aparecer no XML, então acredito que haja algo de errado na sua rotina.

Verifique se a pasta de Schemas e DLLs estão atualizadas.

Esses são alertas gerados pelo ACBr, na imagem não é possível ver o erro de validação real. Anexe o XML.

Na coluna 109 do segmento P deve constar o tipo de aceite "A" ou "N". No seu arquivo de remessa ele não está sendo gerado. Verifique o TXT enviado ao ACBrMonitorPLUS.

Não entendi se o problema está ocorrendo também em produção... Além de alterar para httpWinHttp, não tenho nada a sugerir.

Está testando em homologação ou produção? Que saiba GO nunca funcionou com OpenSSL em homologação.

A diferença está no campo COD_SIT que nesse arquivo foi informado como 08 - Documento Fiscal emitido com base em Regime Especial ou Norma Específica.

Agora ficou mais claro... Achei que estava sendo gerado o registro C176 no TXT, o que não é o caso. O validador está esperando o registro C176 pois foi informado o C170, que não deve ser feito em caso de NFe de emissão própria. Veja a exceção do guia prático versão 2.0..22, página 41, referente ao registro C100:

Não entendi o que validar no PVA faria diferença, mas sim, validou normalmente o txt gerado pelo demo do ACBr. Coloque um breakpoint na unit ACBrEFDBloco_C_Class.pas, no início do método: function TBloco_C.RegistroC176New: TRegistroC176; E rode o debug, se ele parar no método é porque está sendo chamada a geração do registro, basta analisar o callstack para saber qual rotina está fazendo isso.

Fiz teste com o demo do ACBr e gerou normalmente o registro C170 sem o C176. Provavelmente é algo na sua rotina que está explicitamente fazendo a geração do registro.

Evite usar essa configuração pois ela é baseada na msxml5.dll que está depreciada pela MS e segundo relatos aqui no fórum é a responsável por esse problema. Prefira usar SSLXmlSignLib = xsLibXML2.

Qual configuração SSLXmlSignLib está usando?