Régys Silveira

Leandro, as respostas as suas perguntas estão na Especificação de Requisitos, peço que primeiro você leia ela toda, assim fica mais fácil para você desenvolver e perguntar também. Veja o R02 é R03 são o cabeçalho e itens da redução Z, você deve gravar sempre que emitir uma, isso está na ER.

o que você está passando dentro do PathArquivo?

O ACBr não tem opção de preencher os dados adicionais automático, aqui eu fiz uma rotina que monta e adiciona manualmente.

Segue o exemplo de como referenciar notas de todos os tipos, utilize somente a que você precisa: with Ide.NFref.Add do begin refNFe := ''; //NFe Eletronica RefNF.cUF := 0; // | RefNF.AAMM := ''; // | RefNF.CNPJ := ''; // | RefNF.modelo := 1; // |- NFe Modelo 1/1A RefNF.serie := 1; // | RefNF.nNF := 0; // | RefNFP.cUF := 0; // | RefNFP.AAMM := ''; // | RefNFP.CNPJCPF := ''; // | RefNFP.IE := ''; // |- NF produtor Rural RefNFP.modelo := ''; // | RefNFP.serie := 1; // | RefNFP.nNF := 0; // | RefECF.modelo := ECFModRef2B; // | RefECF.nECF := ''; // |- Cupom Fiscal RefECF.nCOO := ''; // | end;

Você informou corretamente a tag "Emit.CRT" como simples nacional? Se sim, poste o XML para melhor análise.

Respondido em: Por favor, pergunto somente em um lugar e aguarde.

Você deve ler por nota fiscal o retorno, segue o exemplo de algumas informações, a sistemática é a mesma para as outras informações: ACBrNFe1.NotasFiscais.Items[X].NFe.Ide.nNF, ACBrNFe1.NotasFiscais.Items[X].NFe.Ide.serie, ACBrNFe1.NotasFiscais.Items[X].NFe.procNFe.chNFe, ACBrNFe1.NotasFiscais.Items[X].NFe.procNFe.nProt, ACBrNFe1.NotasFiscais.Items[X].NFe.procNFe.dhRecbto, ACBrNFe1.NotasFiscais.Items[X].XML, Onde "X" é o índice da nota que vai ser lida no loop, se você enviou somente uma nota utilize "0".

Qual UF está configurando no componente?

Obrigado pela ajuda Italo.

Verifiquei é a validação é feita sempre, e realmente está validando os 11 digitos, eu pedi ao Italo para verificar a validação pois ele tem mais conhecimento nesse processo. Mesmo alterando para 12 o tamanho, ainda o número não passa em outra validação que checa o início do documento, então é melhor verificar com calma.

Vou verificar, provavelmente a validação é feito na montagem do XML, por isso que quando validei ele passou. Vou checar.

Segue o tópico falando a respeito:

Adilson homologação de TEF não é burocracia, é segurança, ela não tem nada a ver com Paf-ECF, tem a ver com certificar que seu software não vai por exemplo bloquear um valor no cartão de um cliente. Já vi casos de empresas que não certificaram TEF e no momento da venda, fizeram a transação errado e bloquearam o valor no cartão do cliente. Lembre certificar TEF é uma coisa, homologar Paf-ECF é outra totalmente diferente, a homologação Paf-ECF com a NFC-e morre, mas a certificação TEF não vai morrer, essa é necessária, por questão de segurança para seu cliente usuário do software e do cliente dele que compra a mercadoria no estabelecimento.

Efetuei a validação desse XML aqui usando o demo do ACBrNFe e ela validou normalmente, tem certeza que os seus schemas estão todos atualizados?

Realmente, desculpe a falha.

O número da DI está com 12 caracteres, quando o correto seriam apenas 10 caracteres.

Só para deixar claro uma coisa, já que ressuscitaram esse tópico, baixar a NF-e utilizando esse tipo de software, parsers e afins não é correto, porque a nota baixada não é o XML original e não possui assinatura. O único XML baixado que é válido é aquele baixado diretamente do site da receita utilizando os botões de download ou utilizando o webservice da NF-e, pois estes são assinados e válidos. O correto seria o fornecedor enviar o XML, isso sim já está previsto em lei e é obrigação.

Com certeza vai mudar, provavelmente utilizarão a homologação de TEF não fiscal, que utiliza impressora comum. Até o momento não obtive nada mais esclarecedor, mas como já existe a possibilidade de homologar sem impressora fiscal e usando a impressora comum, provavelmente será essa a homologação adotada, é claro, isso é passível de mudança com o tempo e conforme mais estados forem aderindo ao projeto NFC-e.

Vamos primeiro esclarecer uma coisa, os eventos não possuem impressão, ela foi colocada a pedido dos colegas para fins meramente burocráticos nas empresas, não existe no manual da NF-e nada quanto a impressão de eventos, somente a impressão da própria NF-e por meio do DANFE. O único evento que "acampanha" a nota fiscal seria a carta de correção, portanto, somente esse deveria ser impresso, existe também a possibilidade de imprimir o cancelamento e provavelmente os outros eventos que virão posteriormente. A inutilização não é um evento da NF-e, ela é uma "rotina", portanto, não está ligada a uma NF-e específica nem a um conjunto de NF-es, não deve ser impresso, ele serve meramente para suprir a necessidade de cancelar um furo de numeração, por isso não foi colocada rotina para impressão dele no componente.

Desculpe mas não entendi bem porque direcionar o post a mim Quanto a correção, eu não tenho impressora sweda aqui, então não tenho como solucionar o problema já que não tenho como testar, teríamos que pedir a um dos colegas que possuem a impressora para efetuar o teste. Não sei se entendi bem, mas parece que você tem a solução, eu pediria que você então fizesse as alterações, testasse e postasse aqui, assim um dos commiters podeanalisar e subir a correção para o repositório, você estaria ajudando a todos os outros colegas e usuários do projeto.

O RecuperaXML foi retirado do core do projeto a um bom tempo (mais de 1 ano), justamente por não ser a forma correta de se obter o XML da NF-e, veja inclusive que o último post deste tópico é de 2011.

As dlls do opensll estão dentro do diretorio: <ACBr>\DLLs\OpenSSL

Via de regra, geralmente se a empresa possui Inscrição estadual de substito tributário ela vai gerar o registro. Também aquelas que compram de substituto tributário é fazem aproveitamento do imposto.

Só se existir alguma API para isso, mas acho difícil.

Rodou ele como administrador?