Régys Silveira

Por nada, marquei como resolvido.

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".

Utilizando o software gratuito da receita também acontece?

Qual UF está configurando no componente?

Veja no XML, você está informando "<tpAmb>2</tpAmb>", ou seja, tipo de ambiente homologação.

Você não está passando um valor para a tag cNF, então o monitor gera uma nova a cada processo, porque o cNF deve ser um número aleatório controlado pelo aplicativo. Basta informa a tag cNF sempre que a chave será igual.

Valor total dos impostos é somente para vendas a consumidor, o CT-e não deve informar esse valor.

Esse assunto está sendo comentado em um tópico aberto, segue o endereço: qualquer outra dúvida volte a postar que vamos tentando ajudar.

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.

Verifique os direitos de escrita no diretório, pode ser que sua aplicação não esteja conseguindo gravar o arquivo.

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

Qual é o modelo de TEF que está utilizando?