Régys Silveira

O ACBr trabalha com o sistema de levantar exceções, as exceções vem com mensagens para cada situação levantada. Os homologadores já estão pedindo mensagens específicas, já existem relatos no fórum sobre isso, e também é bom sempre tratar as exceções levantadas pelo componente, afinal de contas elas são um indício de que algo não deu certo.

Basta checar a data de validade do certificado pelo próprio componente: var Certificado: ICertificate; DataVencimento: TDateTime; .... with ACBrNFe.Configuracoes do begin Certificado := Certificados.GetCertificado; DataVencimento := Certificados.DataVenc; end;[/code]

Sim, basta tratar os exceptions que o ACBr levanta, isso não é um problema. Existem aqui no fórum alguns tópicos discutindo a melhor forma de tratar isso inclusive.

Concordo com o EMBarbosa realmente esse é um problema bem conhecido do Ruby, e como disse um professor meu no passado "não existe a melhor linguagem, mas aquele que atende aos requisitos pretendidos".

Enviei uma correção para o repositório que vai valer para todos os campos decimais, essa correção que você enviou está amarrada ao campo, não seria o ideal. Faça a atualização e restaure o arquivo que você alterou que agora vai funcionar corretamente. Qualquer problema avise.

Ruby é uma linguagem muito utilizada, puramente orientada a objeto e é suportada pelos maiores servidores de hospedagem no mundo, existem servidores inclusive que hospedam somente o ruby, duvido muito que vá se descontinuada algum dia. Quanto ao Delphi, você não deve estar acompanhando a evolução da ferramenta e todo o esforço em torno dela, Delphi é uma linguagem sólida que possuiu tudo e mais alguma coisa do que as outras linguagens, mas a grande maioria dos usuários não arranha nem a casca dele em termos de uso. Grandes aplicações que são utilizadas por muitos hoje em dia são feitas em delphi vou citar uma que é o skype, existem muitas outras que pouca gente sabe que foi feita nele.

Então se já sai do banco de dados errado, então é coisa ai na tua aplicação. Você teria que verificar no banco de dados como a sua seleção retorno, se retorna certo então verifique se o componente de acesso aos dados e os tfields estão corretos.

Erro de estrutura não, mas ao menos a terceira advertência você deveria dar uma olhada, parece que foi CFOP errado na nota. Mas é isso ai mesmo, sempre alguma coisinha tem

Entendi, você diz no cliente mesmo, não ai na software house, eu entendi que se você alterasse. Bem neste caso o que eu faço e ter o controle dos MD-5 e validar, dai bloquear o app como manda a ER, ou seja, liberar somente consultas, etc, etc e mostro uma mensagem para o usuário que a cópia dele foi corrompida e deve entrar em contato para acertar isso.

O MD-5 da lista de executáveis que é impresso no cupom e também vai no laudo não muda a não ser que você altere os fontes do aplicativo ou alguns dos arquivos relacionados no arquivo com a lista. Se você precisar fazer algo que mude o MD-5, você deve enviar uma correção para o SEFAZ, que nada mais é do que tudo que envia quando você faz o cadastro, mas usando o laudo que você já tem, lembrando que o laudo deve estar dentro da validade dos 12 meses, senão você precisa reomologar. Durante o período que não é publica o MD-5 você não poderia estar com o aplicativo rodando em produção, porque se um fiscal pegar o MD-5 diferente do que está cadastrado na receita você vai ter problemas. Então o ideal e alterar o app, enviar a papelada e quando publicar atualizar o cliente com o app correto.

Advertência é até normal, só tem que tomar cuidado para não ter em excesso, advertência em excesso sempre é algo errado na forma do sistema trabalhar.

Faça o seguinte que vai funcionar: - Veja se não existe nenhum bloqueio no firewall ou antivirus; - Instale a nova cadeia de certificados; - Reinstale o aplicativo gerenciador do certificado; - Reinstale a capicom do ACBr. Fazendo isso tem funcionado onde me deu problema.

Pode ser feito assim, basta olhar no ACBr.inc que lá já tem todas as versões suportadas e respectivas constantes de compilação.

O valor da venda bruta você lê direto do ECF na hora da redução Z, os valores da soma das alíquotas deve bater com ele.

Você tentou baixar a versão mais atual do ACBrMonitor? Eu tenho ele aqui funcionando no windows 7 64bits e ele teria que funcionar no 32bits também. Baixe a versão mais atualizar pelo site: http://www.djsystem.com.br/acbr/sac/, faça o login com o seu usuário e senha e vá em "downloads", "ACBrMonitor".

Você sempre incrementa o número da nota por série, o número da série fica fixo em 900 até virar o número da nota em 999999999, dai sim você incrementa o número da série e reinicia o número da nota em 1.

Já existe uma discussão sobre esse assunto no tópico: viewtopic.php?f=6&t=5047

A série da nota deve estar em um número maior que 900 também, em consequência o número vai mudar, você deve continuar o número sempre do último emitido para a série que está utilizando.

Poste o arquivo aqui neste tópico em forma de anexo que analisaremos.

Bastaria preencher os campos com o valor passando a quantidade de casas decimais corretas, o componente já gera no formato correto. Você verificou se o valor que está passando para as propriedades está mesmo com as cadas decimais desejadas?

Configure o componente: ACBrNFe.Configuracoes.Geral.FormaEmissao := teSCAN; E preencha os seguinte dados da nota eletrônica: Ide.tpEmis := teSCAN; ide.dhCont := // data e hora da entrada em scan; ide.xJust := // texto com a justificativa do scan;

Você pode pedir informações direto pelo site: http://desenvolvedoresdaruma.com.br/home/index.php ou pelo telefone: 0800 770 3320

Você poderia postar a mensagem de erro completa e se possível um printscreen da tela?

Vá até http://www.djsystem.com.br/acbr/sac/ faça o login com o seu usuário e senha e clique em downloads. Baixe sempre a última versão mais atualizada.

Sim