BigWings

Esse XML foi gerado pelo ACBr?

Veja o MOC versão 6, páginas 146 a 148, pra um esboço atualizado do que o Kiko postou. - Emissão normal e SVC-XX: Mensagem "Consulta de autenticidade no portal nacional (...) ou no site da SEFAZ autorizadora" e protocolo de autorização de uso da NF-e. - Emissão FS e FS-DA: Segundo código de barras e sua representação numérica abaixo dele, com o título "DADOS DA NF-E" - Emissão EPEC: Mensagem "Consulta de autenticidade no portal da NF-e" (sem menção à SEFAZ) e protocolo de autorização do EPEC abaixo.

Sim, apenas FS ou FS-DA deve sair o segundo código de barras, mas há outros campos que precisam ser tratados.

Não copie o conteúdo, ANEXE o arquivo XML.

Apenas complementando, emissão em SVC-AN e SVC-RS seguem o mesmo padrão da emissão normal e há a terceira forma que é a emissão por EPEC. https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=URCYvjVMIzI= Páginas 146 a 148.

Atente para a diferença entre Emitente e Remetente, como o Italo postou acima. No DANFE aparecerá 1-DEST/REM como manda o Manual (e não Emit/Dest como você disse - se está aparecendo assim poste um PDF para verificarem). Os dados do Destinatário / Remetente estão explícitos na nota.

Debugue e veja o valor de ACBrNFe1.NotasFiscais.Count antes do comando ACBrNFe1.Enviar.

Provavelmente você adicionou mais de uma nota no componente. A validação acusa apenas um erro na primeira nota, quando você corrige, acusa muitos erros na segunda.

Não há garantia que o ValidarRegrasDeNegocio funcione 100%. Pode ser que havia alguma diferença na soma dos valores que o ACBr apontou mas a SEFAZ resolveu ignorar. Poste o XML para análisarmos.

É obrigatório informar o CSOSN caso use o regime Simples Nacional (CRT=1). O segundo erro indica uma nota adicionada ao ACBrNFe sem nenhum preenchimento, até o número da nota está 0. Algum erro no seu código, com certeza.

Sim, tirando as propriedades da seção published o erro não acontece em tempo de design, mas continua aparecendo em runtime. PS: Pra ficar claro, a exceção em runtime só acontece se for chamada alguma das propriedades PreparedReport, sem associar o componente ACBrNFe.

Até onde sei a informação foi removida dos dois modelos de DANFE, mas não uso o Monitor então vamos aguardar mais alguém pra lhe ajudar. Seria interessante postar a versão do Monitor que está usando e os PDF dos DANFE.

Exatamente, para esse caso o CST correto é o 70.

Bom dia, Fiz uma correção no ACBrNFeDANFeFR para evitar o erro 'Propriedade ACBrNFe não assinalada' em tempo de design. Passos para reprodução: 1-Abra o projeto ACBrNFe_Demo 2-Insira um componente ACBrNFeDANFeFR 3-Configure nele a propriedade FastFile 4-Tente salvar ou mesmo fechar o projeto sem salvar, vai ocorrer a exceção. Como as propriedades estão na seção published, no momento da gravação o Delphi tenta acessar as propriedades PreparedReport, o que chama a PrepareReport, que dispara a exceção quando o ACBrNFe não está configurado para o DANFeFR. Resolvi movendo as três propriedades PreparedReport da seção published para a public, segue anexo. ACBrNFeDANFEFR.pas

Informando o CST 10, que não permite redução de base de cálculo, o ACBr ignora a tag. Para informar redução e ST, use o CST 70.

Está usando impressão EscPos ou Fortes?

Esse XML está validando normalmente tanto no validador da SEFAZ RS quando no demo do ACBr.

Porque não simplesmente usar o arquivo DANFENFCe3_50.fr3? O boletim da SEFAZ faz menção ao Manual de Especificações Técnicas do DANFE NFC-e e QR Code (versão 4.1), o ACBr ainda não está adaptado para essa versão do Manual, que ainda não é obrigatória, mas já está adaptado a versão 3.5, basta usar esse arquivo, onde a observação já foi removida, e há outras modificações. O manual 3.5 já é obrigatório há um tempo, mas a versão em Fast está em arquivo separado.

Tudo depende de como está sendo gerado no XML. O correto é gerar a hora local -03:00, por causa do horário de verão. Saindo do horário de verão, hora local -04:00. Manaus não tem horário de verão.

Bom dia, Fiz uma alteração para obter o número do protocolo de cancelamento para o provedor Agili. Segue anexo. pnfsCancNfseResposta.pas

Então o problema não é no cancelamento e sim na emissão da nota. Abra um novo tópico, poste o XML enviado com fuso -04:00 com horário de verão e a mensagem de rejeição.

Horário de verão marcado? Aqui uso desta forma.

Você postou os XML de retorno do webservice, neles vai constar a hora e fuso do servidor do webservice. Veja qual hora e fuso está sendo gerado nos arquivos de envio, e se a hora do PC está correta. Uma diferença de minutos na hora já pode causar rejeição. A opção de horário de verão também causa problemas, caso o Windows do PC esteja desatualizado, a hora pode mudar indevidamente. Estou em RO, fuso -04:00, sem horário de verão, usando SVRS, sem nenhum problema.

Componente do ACBr. Veja o demo no diretório ACBr\Exemplos\ACBrSerial\ACBrPosPrinter. A função chama OpenPrinter, StartDocPrinter, StartPagePrinter pra cada linha a ser impressa. Bem pouco eficiente. Talvez você devesse mandar o texto todo de uma vez só, num StringList por exemplo, ou modificar a função para abrir a tarefa de impressão uma vez só, fazer todas as chamadas a WritePrinter necessárias, e encerrar com o EndPagePrinter, EndDocPrinter e ClosePrinter.

Me parece que cada chamada a WriteRawStringToPrinter cria uma nova tarefa de impressão no Windows, então é até natural que haja uma pausa. Porque não usa o ACBrPosPrinter? Basta configurar o driver pra criar a porta serial e configurar o PosPrinter com o modelo ppEscEpson e ela funciona 100%.