Régys Silveira

Veja o demo do ACBrTEFD, na implementação dos eventos.

Veja se a propriedade "ACBrECF.ReTentar" está True.

O que pode estar errado é a versão do webservice, a máquina do lado deve estar utilizando a versão 2.0 ainda e nova que está dando errado está na 2.0.1, alguns estados estão passando por isso realmente, a versão nova não estar estável.

Conforme pode ser visto aqui: http://www.nfe.fazenda.gov.br/portal/di ... euqr8PQBY= e aqui: http://hom.nfe.fazenda.gov.br/portal/di ... euqr8PQBY= Os webservices da Bahia não estão funcionando corretamente, provavelmente é algo lá mesmo.

A mensagem é somente isso?

ABCr atualizado? Schemas atualizados?

Já existe um tópico tratando dessa dúvida aqui no fórum, por favor utilize a busca search.php.

O status já é a resposta, você enviou uma correção para uma nota com o CNPJ do emitente diferente do que está na carta de correção.

O ACBrECF se estiver ligado a um componente ACBrEAD utiliza ele para assinar, dessa forma utiliza também os eventos do ACBrEAD para obter as chaves, caso você não tenha ligado o ACBrECF a um componente ACBrEAD, o ACBrECF cria um EAD interno para assinar e usa seus próprios eventos para obter as chaves. Dependendo da forma que estiver fazendo procure os eventos OnChavePrivada e onChavePublica para alterar as chaves.

o ecfSweda e para compatibilizar com ECFs mais antigo, use preferencialmente o ecfSwedaSTX.

Baixe a versão acertada em: https://sourceforge.net/projects/acbr/files/

Utilize este link search.php que vai encontrar o que precisa, já existem diversos posts abertos e tratando sobre esse assunto específico.

Utilize o método "NotaUtil.ChaveAcesso" disponível na unit ACBrNFeUtil, para gerar a chave de acesso novamente, você vai precisar ter o código aleatório gerado no momento da emissão da NFe.

Erro 999 - não catalogado geralmente é erro de implementação no webservice, esse código de erro serve para qualquer coisa não tratada pelo webservice.

A segunda opção foi feita especificamente para o menu fiscal, gerando ou imprimindo as informações como o menu LMFC pede.

Em contato com a sweda eles não conseguirão responder se o comando para o contador existe ou não, no manual não existe, então fiz uma implementação genérica para ler ele da Leitura X que vai funcionar com outras impressoras que também não possuem o retorno, peço que testem e retornem o feedback. Para Daruma, Bematech e protocolo FiscNET está 100% utilizando o comando próprio. Para Sweda e outras está lendo da leitura X e em meus testes os valores retornados bateram. Qualquer coisa diferente postem.

A sim, correto, ta vendo são coisas que eles vão acertando, devagarinho mas vão

Colocar o MD5 do aplicativo no campo reservado ao fisco é somente para o fisco saber qual aplicativo emitiu aquela NF-e, veja, no futuro eles vão cruzar diversas informações, o SPED está ai para mostrar isso, ano que vem começa o SPED Social (Folha de pagamento), eles vão amarrar tudo, logo logo, até 2015 eu imagino que vai ser bem complicado sonegar, ou ao menos vai ficar muito difícil fazer isso.

Existem ferramentas na internet para isso, aprendi a conhecê-las em minha pós-graduação em segurança da informação. Uma busca rápida no google lhe ajuda. Quanto aos requisitos e roteiros, concordo plenamente que existem coisas estranhas a nós programadores que eles pedem no roteiro, mas se estão lá tem um motivo, e julgar se é certo ou errado não vai fazê-los mudar de ideia, cabe a nós somente implementar e fazer funcionar como pedem, mas levantar as questões é bom, porque assim se gera a discussão e gerando a discussão pontos são levantados, e eles vão vendo isso e acertando, devagarinho mas vão .

Agora eu volto a pergunta a você, tem certeza mesmo que o seu banco de dados é inviolável? eu conheço forma de obter acesso administrador a praticamente todos os BDs do mercado hoje, comercial ou não comercial. Como você tem certeza que está barrado? e se não estiver, não seria o caso de evidenciar isso?

Igor, segue a mesma lógica do que havíamos conversado no outro post, o que o estado quer é poder validar, veja no componente ACBrAAC, se você mecher no arquivo ele acusa ele como inválido, esse é o ponto, invalidar a ação do usuário, não bloquear isso. O que o estado considera é que qualquer coisa feita dentro do banco de dados é mais simples de ser manipulada, só isso.

Não, você precisa ter o cadastro na UF, aqui nos fizemos a inscrição no estado e nos cadastramos como emissores voluntários, assim podemos utilizar o ambiente de homologação, não mudou nada em termos fiscais.

O diretório ACBr\Fontes\Synalist está no library path?

Ele vai tentar acessar e procurar formas de fazer isso, eles já tem uma ideia de quais podem e quais não podem, o postgress por exemplo é um banco que possui gerenciador de acesso e senha então não vão aceitar isso, mas uma aplicação que possua banco de dados próprio inacessível de qualquer forma que não seja a aplicação que a utiliza, essa sim vai ter uma observação no laudo e os testes serão pulados. Eu já vi isso acontecer com aplicativos cobol usando bases de dados próprias e até em delphi mesmo, mas o programador criou toda a estrutura de dados em formato próprio inacessível por fora da aplicação.

Por enquanto o correto é somente o Paf-ECF, aceito na grande maioria das UFs, saber se o NFC-e ou o SAT vão ser o padrão ainda é cedo.