BigWings

Em vez desses comandos, use apenas: ACBrNFe.EnviarEvento(nLote); Assim o XML já é gerado com o número do lote e assinado, duas das coisas que estão faltando no seu XML.

Na instalação pelo ACBrInstall_Trunk2.exe ocorre erro? Ou apenas na compilação do seu projeto? Veja se não tem fontes do ACBr em outro local.

Não entendi o que você quis dizer com "aumentar o prazo". O prazo pra envio da NFCe emitida em contingência é de 24 horas a partir da emissão, isso é definido por legislação. Após as 24 horas ainda é possível enviar as NFCe, elas ainda serão autorizadas com o cStat 150 - Autorizado fora do prazo, mas a SEFAZ pode vir a cobrar explicações sobre o motivo do atraso.

Pelo que vejo nos fontes o modo RAW: passa pelo spooler de impressão do Windows, precisa que ela esteja instalada como impressora do Windows. O modo USB: precisa da DLL do fabricante da impressora (implementado para Epson e Elgin).

No seu caso a UF está exigindo a informação do ICMS-ST cobrado anteriormente em operação com não consumidor final. Então você deve informar esses valores no XML ao usar CST 60 ou CSOSN 500 com emitente dessa UF. A nova propriedade que foi criada serve apenas para forçar a geração da tag vICMSSubstituto mesmo quando o valor dela seja 0. Talvez você queira configurar como fgtSempre para não ter a rejeição. As demais tags do grupo já deveriam ter sido geradas no XML independentemente do valor zerado... está com os fontes atualizados?

No arquivo de retorno do dia seguinte não tem a confirmação ou rejeição do registro do boleto?

Leia o tópico abaixo:

A tag rodo.CIOT é de versão anterior do layout do MDFe (1.00), mantido por compatibilidade, não é mais usada na geração de um MDFe.

Tente refazer a instalação marcando a opção de apagar arquivos antigos.

Que saiba não existe empecilho. Você pode usar por exemplo o modo RAW. ACBrPosPrinter1.Porta := 'RAW:Nome da impressora no Windows';

Você deve usar o software da impressora para limpar ou trocar a imagem que está servindo de logo.

Você pode cancelar ou encerrar o MDFe apenas com a chave e o protocolo de autorização. Tem exemplo de encerramento no demo do componente, o cancelamento é da mesma forma.

Acho que você pode alterar seguramente essa linha para mPrevisao.Visible := False; Não sei o motivo de haver essa marca d'água no DAMDFE, nem o que ver a ser um MDFe "previsão"... ela provavelmente pode ser removida. Fez teste usando o DAMDFe_Retrato.fr3 com FR4?

A maioria dos .fr3 do repositório é baseado no FastReport 5 em diante. Sugiro que atualize a sua licença do mesmo.

Você diz estar usando o CST 20 mas no trecho de código está usando CSOSN 900. Não existe tag vICMSDeson para o CSOSN 900 de acordo com o layout da NFe. Por isso mesmo que informe o valor para a propriedade no componente ele não será gerado no XML.

Significa que já existe nota com essa numeração transmitida para a SEFAZ mas com o código numérico diferente do que você está tentando consultar. Veja que a verificação é com o código numérico já armazenado em banco de dados da SEFAZ. Como diz a observação da regra, se está usando o certificado digital do próprio emitente da nota você deve receber na mensagem de retorno a chave correta da NFe com essa numeração. De posse dessa chave você pode baixar o XML e comparar com o XML atual para ver se a diferença é apenas no código numérico, ou é outra NFe completamente diferente.

A propriedade está em TACBrTitulo e não no componente de impressão. Usando o exemplo do demo do componente com a sua implementação, seria algo assim: procedure TfrmDemo.btnIncluiBoletoClick(Sender: TObject); var Titulo: TACBrTitulo; begin doCarregaBeneficiario; Titulo := dm.ACBrBoleto.CriarTituloNaLista; with Titulo do begin Vencimento := StrToDate(edtVencimento.Text); DataDocumento := StrToDate(edtDataDoc.Text); [...] Detalhamento.LoadFromFile('.\carta_boleto.rtf'); E na impressão carregar essa propriedade Detalhamento. Seria melhor ter a funcionalidade completa para ser enviado para o repositório.

Enviado ao repositório, rev. 17460. Obrigado @JeannyPaiva pela contribuição.

Sim, o modo assíncrono ainda estará disponível para o modelo 57, mas você terá opção de usar o modo síncrono também pra esse modelo.

O código de retorno de "Erro não catalogado" indica um problema com a SEFAZ. Você deve entrar em contato com a mesma e reportar o problema. A SEFAZ da UF em questão já implementou o envio de evento de comprovante de entrega?

Acredito que isso esteja sendo feito do seu lado. No código do ACBr não existe essa condição.

As alternativas para para o formulário de segurança são a contingência SVC que só é ativada quando a SEFAZ tem problemas no ambiente normal, e a contingência EPEC, onde o emitente precisa transmitir o evento prévio de emissão em contingência para que a mercadoria possa circular. Por ambas dependerem de conexão com Internet do lado do emitente, ao contrário da contingência FS-DA, acredito que a primeira seja mais usada. A contingência EPEC pode ser útil quando usando conexões limitadas como um roteador 3G já que o XML do evento tem tamanho reduzido em comparação com a NFe completa.

Existe na classe TACBrTitulo uma propriedade Detalhamento do tipo TStrings. Você acha que consegue fazer essa implementação usando essa propriedade em vez de carregar um arquivo com nome fixo do disco? Assim mantém-se compatibilidade com a impressão em FortesReport. Vi que fez alteração também no carregamento do logo do banco, qual a necessidade dessa alteração?

No código do componente, não tem. Basta a tag ter o valor preenchido. Sugiro uma revisão/debug da sua rotina.

São conflitos de atualização que o Tortoise SVN insere ao atualizar os fontes, quando havia alterações locais feitas na sua cópia dos fontes com as alterações aplicadas no repositório. Você pode analisar e resolver as diferenças pela função "Resolve" no menu to Tortoise SVN.