Régys Silveira

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?

Basicamente é isso ai que o Carlos falou, a limitação não existe, mas nosso amiguinho compilador encherga Quando você monta um string o compilador entende como uma grande constante, fazendo picado ele divide em várias menores.

Anexe o arquivo alterado por favor.

Você está misturando as coisas, ShortString é que é limitada a 255 caracteres, em delphi o tipo string tem o tamanho de: ~2^30 characters (4 bytes to 2GB) basicamente o limite dela é limitado pela memória se for menos de 2GB e não por tamanho.

Complementando o Italo, lembre que a carta de correção é cumulativa para a nota, a ultima sempre sobrepõe todas as outras, portanto, deve conter sempre todas as correções até o momento. Como você deseja fazer 5 correções o correto seria fazer as 5 todas em uma mesma CC-e e não fazer 5 em sequencia.

Vá na aba Diretórios do ACBrNFeMonitor e sete a marcação: "Salvar NFe pelo campo Data de Emissão" que ele vai usar a data de emissão ao invés da data atual.

Não existe um documento desse tipo, porque geralmente o pessoal utiliza o fórum, ele está cheio de dicas, só usando a busca já vai achar várias coisas interessantes.