Régys Silveira

Seu certificado é um e-NFe?

Verifique a questão do horário de verão, usuários tem relatado problemas com isso, windows não atualizados saíram do horário de verão antes do dia determinado.

Vou te responder o mesmo do outro post: Você está propondo uma correção? Seu arquivo está totalmente diferente do arquivo que está no repositório do Trunk2 atualizado. Não entendi qual é a correção nem o que está propondo, você precisa dar detalhes do que fez para que possamos analisar e verificar.

Você está propondo uma correção? Seu arquivo está totalmente diferente do arquivo que está no repositório do Trunk2 atualizado. Não entendi qual é a correção nem o que está propondo, você precisa dar detalhes do que fez para que possamos analisar e verificar.

Você não preenche, ela é retornada no XML autorizado, ou seja, quem preenche é o webservice ao autorizar a nota.

Você pegou o arquivo .fr3 diretamente do seu repositório ACBr? Você alterou o arquivo? Seu ACBr está atualizado? Recompilou todos os pacotes que você utiliza usando o ACBrInstall_Trunk2?

Ele compara a raiz do CNPJ, qual é o CNPJ do certificado é qual é o CNPJ do emitente?

O problema do FastReport ao meu ver é que você não instalou o driver de spooler correto da impressora.

Você precisa alterar o horário do computador manualmente, alguns computadores saíram do horário de verão antes do prazo.

Você tem um exemplo, não lembro como era isso?

Estão utilizando o Trunk2 e a versão do arquivo .fr3 que está no repositório?

Você tem que sempre ter em mente o seguinte: 1. AnsiString é a String antiga dos Delphis não Unicode, na maioria dos casos é desnecessário utilizá-la, mas isso vai depender do seu código. 2. Em Unicode cada caracter é representado por 2 bytes, um para o caracter e outro para a página de códigos, por isso em alguns casos corta ou um loop não lê toda a string, mais uma vez, depende da forma como foi implementado o método. 3. Um livro bom para entender o Unicode é o: "Recursos Avançados do Delphi", ele possui 1 capítulo inteiro somente sobre Unicode. Segue outros links sobre o assunto: http://blog.marcocantu.com/blog/d2009_whitepaper1.html https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf https://www.embarcadero.com/images/pdf/Delphi-Unicode181213.pdf

Tente começar pelo Google: https://www.google.com.br/search?client=opera&q=nota+fiscal+eletronica+para+fora+do+pais&sourceid=opera&ie=UTF-8&oe=UTF-8 Mas o ideal é verificar com o contador do seu cliente tudo que é necessário.

Você está utilizando o componente ACBr ou está fazendo manual? A mensagem é clara a tag CPF não é esperada, ele espera a tag CNPJ, isso porque a referencia é a nota nota fiscal e para tal ele precisa dos dados da nota e emitente, não destinatário.

Você está utilizando Fortes e diretamente no componente correto? Se sim, você precisa aumentar manualmente o tamanho do form e da folha do fortes alterar o que precisa e depois retornar, ele não cria as barras de rolagem como os outros, ele é bem parecido com o quickreport nesse quesito edição do layout.

Talvez o discador da TIM esteja enviando as mensagens como MMS e não SMS, pois o SMS tem o limite de 160 caracteres.

@João Carlos Almeida Prado se tudo correr bem, dentro de alguns anos tudo será NFC-e ou SAT ai essa bagunceira acaba, ao menos a do Paf-ECF, até também eles inventam outras tantas para nos preocuparmos

1- Possui o campo COO nas informações da redução. ACBr não tem Realmente não tem, acabei de subir a correção adicionando, passou batido aqui e acabei não vendo, desculpe. 2- Os valores possuem ponto decimal, no ACBr nenhum campo numerico possui Veja no manual é verá que não existem pontos decimais para campos numéricos, está na documentação (veja: 2.8. Coluna ‘Dec’). 3- Os campos quantidade são INTEIROS, estou homologando RESTAURANTE, e preciso de quantidade real pois vendo por quilo, e as gramas são fracionarias. Relativo a quantidades a documentação não possui cassas decimais, tanto para redução quanto para estoque, portanto, é inteiro, se a documentação está errada então deveria existir um adendo corrigindo ela, até onde sei não existe, o componente segue a documentação. Observação pessoal: Eu acho que a documentação está errada em alguns pontos, inclusive o exemplo que vem na documentação está fora da estrutura que está na própria documentação, fora que este arquivo ainda não possui forma de envio definida por nenhum estado até o momento, eu acho que ainda virão muitas alterações nele. Este é mais um exemplo do tipo de coisa que temos que trabalhar no dia-a-dia, eles inventam mais e mais arquivos, sem nenhum acordo entre estado e desenvolvedores e sem ao menos uma validação do que é ou não correto, fora que na maioria das vezes eles preferem mudar o padrão. Com certeza na próxima ER teremos diversas alterações nesse bloco.

A inutilização como os outros eventos não possui layout oficial de impressão, para os os eventos normais criamos um layout próprio e que foi disponibilizado. Você poderia tentar utilizar o mesmo procedimento de impressão de um evento normal (correção, cancelamento, etc), mas não sei se ficaria como você precisa. Não é comum imprimir a inutilização.

Realmente, é necessário validar isso mesmo, adicionado ao repositório, obrigado pela contribuição.

Este projeto já foi descontinuado do ACBr tem uns 2 ou 3 anos e não faz parte do core de componentes, o pessoal que usava inclusive criou um repositório sourceforge e continuaram o trabalho por conta própria.

Anexe o log para que possamos verificar como você está fazendo, por favor.

Clayton, Eu pedi ao Juliomar para fazer a implementação porque estou correndo com algumas coisas pessoais e não consegui parar para fazer está alteração, ele vai seguir com a implementação.

Não tem nada errado no componente, já homologuei 2 paf-ECFs e muito outros usuários do ACBr também. O componente foi todo feito seguindo a especificação do Bloco X é validado antes de ser liberado por homologadores de Paf-ECF habilitados e de instituições reconhecidas, você com certeza não leu a documentação: Se você ler a documentação verá que todo campo numérico é informado sem "." e "," então "4,50" será igual a "450" no arquivo em qualquer campo do tipo numérico, respeitando a quantidade de decimais, existem um exemplo bem detalhado na documentação. Verá também que todo o campo de quantidade é do tipo numérico sem decimais, portanto, um inteiro, sim existem produtos fracionados e provavelmente a documentação possui um erro, mas temos que seguir a documentação, se no futuro ela for alterada o componente será alterado. Em anexo segue a legislação atualizada. Por favor nas próximas vezes tente ser um pouco mais tranquilo na sua forma de escrever, o componente é uma iniciativa open-source e várias pessoas participam dele ajudando com seu tempo livre e conhecimento, não é algo que você chega mandando e cobrando e sendo assim incisivo dessa forma. BLOCO X.pdf

Você tem que usar o ACBrDFe é não o ACBrNFe para assinar.