BigWings

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.

Por favor abra um novo tópico já que se trata de outro assunto.

Se usar a impressão via ACBrPosPrinter você pode enviar o comando de beep ou corte para a impressora. Mas com impressão via spooler fica por conta da configuração do driver da impressora no Windows mesmo.

Sim.

Tópico movido.

Tópico movido para o sub-fórum mais apropriado. Creio que terá mais sorte perguntando em um fórum voltado ao PHP.

Diferentemente do CTe modelo 57, o CTe-OS é enviado em modo síncrono, sendo assim não existe recibo nem consulta do retorno. Você pode pegar as informações retornadas diretamente de ACBrCTe.WebServices.Enviar ou do próprio conhecimento ACBrCTe.Conhecimentos.Items[0].Cte.procCTe.

Nesse arquivo falta o número do lote o que explicaria o erro de rejeição: Veja se está passando o número do lote maior que 0 no método ACBrNFe.Enviar.

É esse o erro que ainda está tento no envio? Está enviando no modo assíncrono? Configure o componente para salvar os arquivos de envio e retorno e anexe aqui o arquivo *-env-lot.xml gerado.

Aparentemente estão sendo enviados mais caracteres por linha do que a impressora suporta (42). Verifique sua rotina.

Provavelmente esse validador não suporta NFCe, pela rejeição ele sempre espera uma NFe o que não é o caso. Tente o validador da SEFAZ-RS: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx

Verifique a versão do firmware da impressora, pode ser preciso atualizá-lo pra que seja possível imprimir o QRCode.

Correção enviada para o repositório, rev. 17439.

Se vai usar a API, sim. Passe o código da lista de serviço com 4 caracteres. Você também pode carregar a tabela no componente para consulta offline.

Você conseguia emitir sem IE antes? Qual a UF do emitente? Até onde sei mesmo em homologação é preciso o emitente ter uma IE válida e estar habilitado a emitir NFe na SEFAZ.

Que saiba já foi removida a validação do cNF na geração do XML. Está com os fontes atualizados?

Se você precisou fazer essa alteração significa que ainda está passando o mesmo valor para nNF e cNF ao alimentar o componente na geração do XML. Faça o que foi sugerido, informe 0 para cNF ou use a função GerarCodigoDFe(nNF) para gerar o numero randômico, assim não precisa alterar os fontes do ACBr.

No caso dos serviços o IBPT calcula pelo código NBS (coluna tipo = 1) ou o código do serviço conforme a LC 116/03 (tipo = 2).

Tentou BOLETO.ConfigurarDados?

Se está marcando a opção "Monitorar pasta" os campos Entrada e Saída devem conter o caminho de uma pasta existente, e não de um arquivo.

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

@jaildocc favor testar com o arquivo anexo: DANFeNFCe5_00.fr3